Technological progress is both exhilarating and terrifying thing. And by the looks of it, it just keeps on progressing faster and faster. This has lead to an idea of technological singularity. As singularity is reached, technology develops so fast humans can't keep up with the progress anymore. It feels like something similar is happening with front-end development right now.
This is a topic I've had to ponder about for a presentation known as Frontend in 2015 - Clear the Decks. I believe the term "clear the decks" gets to the gist of it. Embrace change.
As Gerald Yeo put it, we're experiencing an explosion of frameworks - a big bang. We've gone from literally nothing to an amazing amount of alternatives. Add libraries, such as React, to that and you end up with a massive ecosystem.
npm alone has over 180k packages to give you a sense of scale. By this rate it will reach million packages by 2020 as it keeps growing faster and faster. Of course the growth comes with problems of its own. How do you find the good packages and know which ones are maintained well?
From the perspective of a developer this means it's impossible to keep up with the development. Even as a book author I have trouble keeping up. I can only imagine how difficult it is for normal developers that have their hands full keeping the boat from sinking.
This all ties to the concept of the hype cycle. In the context of JavaScript that's something we're experiencing constantly. Each framework and new technique goes through the cycle. After initial excitement you will face the reality. Eventually the situation will stabilize and, of course, something new will come along. To quote Teletubbies, "Again-Again"!
As new solutions become available, they can learn from the earlier efforts. For instance, you can see the influence of React in Angular 2.0 and other up and coming frameworks. Eventually the most powerful ideas make it to the standards (i.e. Web Components). In turn this allows libraries and frameworks to collaborate.
No matter what solution you are using, there's always room for collaboration. Even though we might choose our "side" and prefer some specific stack, the world is never black and white. I believe this is the reason why shared, lower level constructs, such as ones enabled by Web Components, are so important.
Ideally Web Components will make it possible to work across boundaries. Instead of having separate bindings of Bootstrap per framework, it would be more beneficial to have canonical bindings which to consume. Hopefully the world moves into that direction.
Interestingly Angular 2.0 can consume Web Components already and I can only hope others will follow the suit. Anything we can do to enable collaboration across boundaries is worth it. npm has shown that already but we can go further than that.
The future is already here — it's just not very evenly distributed. - William Gibson
There's no telling what the world will look like in a year. It's easier to look back and see how antiquated things were. Progress happens so gradually it can be difficult to realize it. Some bleeding edge developers are already experiencing the future while mainstream is behind in many ways. Of course sticking to the bleeding edge implies a certain amount of pain.
It is hard to prepare for the future as so many things are possible. When it comes to software architecture it may be a good idea to design for change. As new winds blow, you may want to rethink your approach. As a result the architecture has to live. Web development is organic by definition. It is grown, not built.
As I put it in my presentation slides subtitle, prepare to clear the decks. It's hard to avoid that in web development. If you are prepared for change, you can deal with it better.
In some ways front-end development is very frustrating. It is particularly difficult for perfectionists. As you get bombarded by new, shiny things, it can be easy to feel inadequate.
Looking through job requirements doesn't do any favors either. There are simply so many matters to master. And as they say, jack of all trades is a master of none. At the same time you should master something to stand out at least a little bit.
This is one of the reasons why I wrote my book. I wanted to go through a slice of interesting technologies. Besides being useful for me personally, I believe the material saves some effort on your part. It is important to be aware of some of the available technologies if nothing else.
An important part of front-end development is knowing what you don't know. You don't have to be an absolute master at everything. There simply isn't enough time for that. Instead, build around your strengths and stay curious.
Big thanks to Daniel Lemire for inspiration. I also appreciate the feedback from Martin Brochhaus and Gerald Yeo that pushed me to write this post.