Stack Overflow Stats Reveal 'the Brutal Lifecycle of JavaScript Frameworks' (stackoverflow.blog)
A developer on the Internal Tools team at Stack Overflow reveals some new statistics from their 'Trends' tool:
JavaScript UI frameworks and libraries work in cycles. Every six months or so, a new one pops up, claiming that it has revolutionized UI development. Thousands of developers adopt it into their new projects, blog posts are written, Stack Overflow questions are asked and answered, and then a newer (and even more revolutionary) framework pops up to usurp the throne...
There appears to be a quick ascent, as the framework gains popularity and then a slightly less quick but steady decline as developers adopt newer technologies. These lifecycles only last a couple of years. Starting around 2011, there seems to be major adoption of a couple of competing frameworks: Backbone, Knockout, and Ember. Questions about these tags appear to grow until around 2013 and have been in steady decline since, at about the same time as AngularJS started growing. The latest startup is the Vue.js framework, which has shown quick adoption, as it is one of the fastest growing tags on Stack Overflow. Only time can tell how long this growth will last.
"Let's be honest," the post concludes. "The size of a developer community certainly counts; it contributes to a thriving open source environment, and makes it easier to find help on Stack Overflow."
There appears to be a quick ascent, as the framework gains popularity and then a slightly less quick but steady decline as developers adopt newer technologies. These lifecycles only last a couple of years. Starting around 2011, there seems to be major adoption of a couple of competing frameworks: Backbone, Knockout, and Ember. Questions about these tags appear to grow until around 2013 and have been in steady decline since, at about the same time as AngularJS started growing. The latest startup is the Vue.js framework, which has shown quick adoption, as it is one of the fastest growing tags on Stack Overflow. Only time can tell how long this growth will last.
"Let's be honest," the post concludes. "The size of a developer community certainly counts; it contributes to a thriving open source environment, and makes it easier to find help on Stack Overflow."
What happens if you need to patch or upgrade in a few years? Like for security? Do you have to rely on unsupported frameworks or throw everything away and start over? How does it work?
Remember, companies pay huge licensing fees exactly for support.
putting the 'B' in LGBTQ+
There is so much wrong about Javascript revealed here that I think we have to question its use going forwards.
The language itself is a great start to programming websites but the need for frameworks, which become "flavours of the month" that makes support so much more difficult as time goes on and the framework goes out of favour resulting in companies scrambling to find people with the skills to maintain them (sort of a short term Cobol analog). This gets worse when you realize that most web page developers don't know how to code and are using published features of the frameworks or example snippets on things like Stack Overflow.
What about security of the various frameworks and ensuring they don't do anything nefarious. I guess the extreme examples would be collecting customer data and running cryptocurrency miners on end-users webpages - but I'm sure there are a lot of more minor security issues that can be hidden in these frameworks.
Finally, I have to wonder about the maintainability of all these frameworks. On one hand, I guess frameworks with issues get identified by the community quickly and are abandoned (but, going back to the previous point, companies have to spend more money because their developers aren't competent to move the page to different frameworks).
I'm not sure I see a solution for these problems. Maybe WebAssembly will be the ultimate solution (with tested and supported libraries that web developers can use and rely on) but I'm hoping that W3C and other groups are looking ahead to the next generation of web development tools.
Mimetics Inc. Twitter
Exactly this. The problem with Angular and all the other libraries is that they're trying to solve the problems of 'simple' libraries like jQuery but then end up even more complex or break all sorts of convention and expectation trying very hard not to become jQuery, and then you get a new library trying to solve whatever problem is in that library.
What you need in a framework (regardless of language) is not complexity (trying to do "everything") but simplicity. If the framework is dictating how your application should work/flow/represent the data, you're going to run in a situation sooner or later where your framework doesn't quite fit your problem and then you'll spend an eternity trying to make it work and you'll end up writing most of your code in the native language anyway.
Custom electronics and digital signage for your business: www.evcircuits.com
As the fastest and leanest framework
As a once Delphi programmer, that is one reason I like the combination of JavaScript/TypeScript, the Mithril vdom https://mithril.js.org/ (which uses a "HyperScript"-like API to define HTML via code), and Tachyons http://tachyons.io/ for embedded CSS where each class defines the CSS effect (e.g. "underline") -- along with a simplified Flux-like one-way data flow architecture. Although people could swap out Mithril and Tachyons for similar systems to get a similar effect.
Sadly, for my day job I am stuck using Angular, which is a my-way-or-the-highway framework with a lot of questionable design choices leading to excessive complexity and difficult debugging.
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
I started using Vue this year. I evaluated React but I just couldn't enjoy the JSX syntax. Angular 2 had just come out and I found it to be far too obtuse, too far from "the metal." I briefly experimented with Riot, but it was losing IE11 compatibility too fast.
Vue hit the sweet spot for me -- the ramp-up was easy, the code and API have a small but powerful footprint, it works well either interpreted in-browser or compiled via webpack, the Chrome dev tools are great, and I didn't have to learn the entire ecosystem (Vue, Vuex, Axios, etc.) to become productive. Coding single-file components reminds me of the good old days of writing server-side ASP.NET controls -- markup and script are separate, the lifestyle is simple to grok. The framework just does one thing--it handles the DOM update/manipulation details, allowing me to focus on behavior and state. I also like that the vast majority of my Vue code isn't really "vue," it's just plain HTML and JavaScript, so whatever comes next (web components, etc.), the transition will be much less painful than if I were using a more opinionated framework.
Yes; thus Rich Hickey's talk on "Simple made Easy": https://www.infoq.com/presenta...
"Rich Hickey emphasizes simplicity's virtues over easiness, showing that while many choose easiness they may end up with complexity, and the better way is to choose easiness along the simplicity path."
I agree on Angular having a lot of "accidental complexity".
I've also run into the "leaky abstraction" issue you reference, like with the Dojo Toolkit and Dijit -- where I ended up spending large amount of time trying to understand why Dijits behaved unexpectedly and to make kludgy workarounds. People hope some frameworks will spare them from learning details of CSS and JavaScript, but in the end, edge cases and bugs mean you still need to learn all that -- as well as an arbitrary framework with its own quirks.
I much prefer the combination of using JavaScript/TypeScript with Mithril/HyperScript, Tachyons, and a Flux-like one-way-data-flow architecture. You need to know JavaScript and CSS somewhat well to use those libraries -- but they are simple enough that they rarely do unexpected things, require long debugging sessions, or get in the way of doing anything advanced that you want to do. Those libraries are not perfect -- just a lot better than something like Angular (which I have to deal with for my day job; see also my related comment below). And those libraries are simple enough that any reasonably good developer could maintain them on their own if absolutely required.
One of the reasons such libraries don't as much attention as they should is precisely because they are so reliable and simple to use. Unlike Angular, neither Mithril or Tachyons *requires* thousands of StackOverflow questions to learn how to use it, debug it, or upgrade it. In a way, picking libraries based on numbers of SO questions or blog posts on it is kind of like picking a car based on how many complaints are filed against the manufacturer with the Better Business Bureau. That's not a 100% valid comparison -- but there is more truth there than one might think at first.
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
try{
// Try something wrong here
}
catch(e){
var xcb="http://stackoverflow.com/search?q=[js]+"+e.message;
window.open(xcb, '_blank');
}
// https://github.com/gautamkrishnar/tcso/blob/master/javascript/tcso.js