- People are starting to feel burned out and alienated by the pace of change
- The answer might be to eschew monolithic frameworks in favour of microlibraries
The tl;dr doesn’t do it justice thought. His analysis of the costs of the churn rate are really perceptive and you really should read the article.
Let me emphatically say that this was a great article.
I’d like to specifically address his 3rd point though. Here he says that “the answer might be” but in his piece he speaks specifically about how this is already happening. How developers are looking more and more for specific libraries that do one thing well, then putting a bunch of those things together to create their frameworks, and he specifically recommends this tactic.
Rather than give my opinion of the wisdom of doing this – which I may do in a different blog post – I will instead challenge the idea that this particular way of doing things is getting more popular, and will continue to get more popular. I in fact believe that people have done this same thing for a long time, in fact, Backbone was the most popular front end framework for a long time, and it was arguably a library and not a framework, which means that anyone doing backbone was building their own framework – albeit generally they were all hand-built pieces.
From what I’ve seen, this method for building front end sites has gotten much less popular in the last few years, and although with React we’re seeing a small bit of a resurgence here, in general, most people aren’t doing this, and I find it hard to believe that it will gain any real popularity, for one simple reason: the vast majority of web developers aren’t high profile bloggers who are driven to rethink everything they do, and the vast majority of dev shops aren’t tolerant to this type of behavior. They want to get a tool they think is good enough, and get going building their product.
Monolithic frameworks appeal to these types of companies and developers. You don’t have to spend time analyzing the 10 different pieces of the framework you will need, and evaluating 5 different options for each piece (a grand total of 50 different analyses). With monolithic frameworks you get to choose from 5 different options, and you probably eliminated 2 of them due to bias right off the bat leaving 2 or 3 true options to consider.
This is how most dev shops operate, and how most developers like to operate, which directly relates back to the original author’s first point. The churn rate is problematic. Developers realize this and are bothered innately by it. They like learning new things, but they also like getting good at something (see Daniel Pink’s work on motivation, specifically the point on mastery). If the churn is high and they’re changing things all the time then they can’t get good at something. But if you can spend 3 or 4 years working on the same framework, you can get really good at it. So surprisingly his first point is actually contrary to his third point.
Now I won’t pass judgement on this behavior, but I’ve worked at 19 different jobs in my career, and interacted with hundreds of developers, and from what I’ve seen this is how most developers operate.