My Reaction to React

My feeling on the subject of "framework churn" and "tool fatigue" in the JS world is that it stems from the general self-deprecating nature of front-end developers.

For years, if you did a lot of work in JS, you were constantly being told to switch to a "real" language, that you "shouldn't reinvent the wheel", that you weren't a "real" developer. I think, for a lot of people who got into programming web sites through non-CS paths, that perception that JS wasn't "really programming" was helpful at first, to make it seem more accessible, but it is now hurting people. I've been working in JS (and other languages) for 20 years now. I've heard it all. First, JS wasn't C. Then, it wasn't Java. Then, it wasn't C#, or PHP. It was "too high level". It "couldn't perform". Nowadays, people want to call it "too low level", whatever that means. I don't think it's a great language, no, but the web as a platform has a lot of advantages that are extremely attractive to small teams (which I think are the vast majority of teams).

Beginners don't understand what is going on with their code. It's a mystery why it works at all. If you can trust yourself to build anything, then it doesn't really matter what framework you choose, or really if you even choose a framework. You know you can never truly get stuck in a corner, because you can always write another program to get yourself out of it in some way. But beginners--and not-quite-beginners in JS who have been indoctrinated into thinking they are perpetual beginners--lack that confidence.

Because of this, such people are fearful of striking their own path. They want to swim with the school--safety in numbers. But there isn't any one school, so when multiple frameworks are out, and you never know which your Snr. Dev is going to choose at your next job (and you're constantly fearful that your lack of skill will be recognized and you'll be booted), you start to worry about ever being able to keep up.

And it might seem like a paradox--why would any such people start a new framework project when they lack basic confidence in their own skills?--but I think this is why there are so many frameworks that have risen to the level of awareness in the popular conscience. There are a few people who have crossed the line into confidence, but they don't yet know that their surface syntax doesn't really make them any different than the others, and then the mass of unconfident people amplify the importance of the project beyond what it maybe should deserve, because of the worry that they might be missing out on some important information that will come up on a job interview in the near future. It used to be you didn't need to have intimate knowledge of your future employer's framework before you walked in the door, they just expected that you had applicable experience and would be able to learn it as you went.

If you're starting a project now, you don't need a JS framework. I see a lot of people thinking way too far ahead. For the vast majority of projects, they aren't Facebook. You don't need a framework to make a simple activity feed. I see very small code bases worried about continuous integration and automated build servers. Nobody can just play with code anymore. Everyone is thinking about "scalability" and "hiring" and "doing a startup". That's ostensibly why we are here on HN, but HN--contrary to popular belief--is not the be-all, end-all of the internet. I think this is also a contributing factor to tool fatigue. People are so afraid of "reinventing the wheel" that they aren't willing to just play around with code. They can't tolerate it for themselves and they can't tolerate it in others (because they fear it will become yet another thing they think they will have to learn). But playing and making your own framework is how you learn to evaluate the plethora of frameworks and throw away 90% of them for being trivially easy to implement on your own.

So what is the solution? A lot of people are doubling-down on the "don't reinvent the wheel" trope. I think that's stupidly close-minded and will lead to such people getting left behind in the coming Singularity. Even if the literal "singularity" never happens, the pace of technological development is not going to slow down just because you're uncomfortable with it. The only surviving strategy is to learn how to cope with the rapid change of the market. And you do that by learning the core concepts to the point that you are completely capable of "reinventing the wheel" whenever you damn well please.

It seems that what is happening with javascript frameworks is what has happened with python web frameworks, which have become splintered thereby dividing the community's mind share.

When I was first looking at python frameworks, I had to spend a not insignificant amount of time evaluating the various frameworks before deciding which one to hitch my wagon to. Had I decided on Ruby over Python, the choice would have been easy given the clear dominance of Rails.

I have limited time to learn new tools since coding is not my primary focus, and one thing that is holding me back from learning a javascript framework is trying to decide which one to dedicate my time to. They all have pros and cons, and I hope a dominant framework emerges soon, and the bulk of the community rallies around it to make it better and better.

Obligatory: https://xkcd.com/927/

Some frameworks let you stand on the shoulders of giants; others are kind of like being stood on by giants. Many of the Javascript frameworks I've seen seen -- especially those written by people who prefer Java to Javascript -- seem to be in the latter category.

Let's be clear, manually updating the DOM is as optimized as you can possibly be. Virtual-DOM isn't somehow magically more efficient than direct, imperative manipulation of the DOM. Virtual-DOM diffing was created to try to emulate the effect of refreshing the entire page every time state changes like we did with stateless web applications but do it in a relatively performant way.

Every (large, meant for production at scale) application needs a framework. That doesn't mean it should be someone else's framework. And while there are certainly "giants" on whose shoulders a developer can stand, in the JavaScript ecosystem in particular, a lot of frameworks feature shockingly bad code or untested patterns.

So, be careful, avoid magic, let your software express requirements, and then choose a tool accordingly.