5 ms·
It is not really a brutal lifecycle at all, to be honest. Everyone loves a good rant about how fast the JS frameworks burn out, but it is not frameworks that b
by Sawamara 9y ago
It is not really a brutal lifecycle at all, to be honest.
Everyone loves a good rant about how fast the JS frameworks burn out, but it is not frameworks that burn out, but rather:
In the 8+ years since Iphone/Android duo made a HUGE change in how we consume web content, we went from:
- Having static resolution for websites to dynamically changing site resolutions
- Having static HTML renders with some dynamic bits sprinkled over to full-blown SPA-s because of a variety of reasons*
- Having major new JavaScript versions and INSANE amounts of Javascript engine speedups that allow things that were unimaginable 8+ years ago
- Having gone from "nothing" to a CPU-based <canvas> to a full OpenGL ES-implementation, full GPU-based (<webGL>),
- Had went from procedural code to semi-class based systems towards functional towards functional reactive programming systems
And I could go on and on and on and on.
The DOM api matured during these years. The renderers got replaced. Their performance altered dramatically. Layouts went from "JUST USE TABLES" towards CSS, then towards Compile-to-css alternatives, etc. Single-core event systems got SharedArrayBuffers, webWorkers, we got from callbacks to promises, towards async/await. And do not get me started on almost getting observables properly.
The web has seen more transformations in terms of what is an "app" or a "website" in 8-10 years than ANY OTHER area in programming. It is only natural that widely different tasks need widely different tools to work with.
- webDevSucks 9y ago> And I could go on and on and on and on. True, it's enough to say "websites became big and slow". Additionally you can say "now we are after cross-platform native apps - set money aside for a device upgrade".
- Klathmon 9y ago(heads up, you need have a blank space between lines in HN to render them on different lines) I completely agree. Many people claim the web is overly complex, but then go back into the C++ world where you need a build tool to build your makefile which builds your project using cross compilation on a handful of platforms. I like to remind people that 10 years ago Android didn't exist, streaming video was still only just becoming a thing, and the iPhone had just been released and wouldn't have an "app store" for another 6 months. There have been several massive changes to the web and to computers and how we use them in that time. It only makes sense that we will use different frameworks and paradigms to create applications.
- Sawamara 9y agoThank you! Oh, now that you mention it: just a few years ago, web streaming was not possible without using either flash or (maybe?) silverlight or something else because it was not implemented yet. Youtube crashed my pc regulary during the hd4850 end-days due to driver crashes. Node was not even a thing yet, let alone Electron/NWJS....
- sjellis 9y ago"The web has seen more transformations in terms of what is an "app" or a "website" in 8-10 years than ANY OTHER area in programming. It is only natural that widely different tasks need widely different tools to work with." These frameworks are not as different, though, so I don't that's the driving force. I think that the implicit argument of the article is that although new frameworks emerge, almost none of them get a large enough ecosystem or amount of adoption to become entrenched. The other thing that the author hints at is that there is a relationship between server-side platforms and choice of JS framework. Ember got a small lift because it was co-designed by one of the best and most well-known Rails developers, but Rails people seem to have gone to React, and Angular seems to have been adopted by the C# community to the point that Microsoft and Google run joint events. Thus newcomer JS frameworks are less likely to get enough adoption to stick around, because server-side frameworks now have implicit default JS frameworks.