5 ms·
I have an opinion, and its sure to be one that will get heavily down voted here but here it goes anyways. Javascript and it's ecosystem is changing so rapidly
by rubicon33 4y ago
I have an opinion, and its sure to be one that will get heavily down voted here but here it goes anyways.
Javascript and it's ecosystem is changing so rapidly for one simple reason: Javascript and it's ecosystem is easy.
You heard me correctly. Javascript despite it's eccentricities is a simple, easy to use language. HTML, CSS, JS is a simple (relatively) easy to get into stack.
This leaves an enormous pool of developers who are hungry to make their mark in the world, and with technical skills that frankly outpace the simple world of web development. So they start building abstractions. Abstractions are fun to build, prove the builders competency, and often do provide some benefit to their end user.
The story of Vue.js (and Vite) is more or less this (there's a documentary on YT, go watch it). They were working at Google on experimental web projects in vanilla JS. Decided they wanted to build things people actually use. Decided a view framework for JavaScript would leverage their skillset and be of use to the community. Had the technical ability to throw vanilla JS around with ease. From this, comes a framework.
- happytoexplain 4y ago"This will get downvoted by this audience" is a self-fulfilling prophecy.
- maneesh 4y agoAs of 22:52 CET it's the top rated comment on this post. I've seen "this will get me down voted" at the top of a post's comments countless times but not once at the bottom.
- noduerme 4y agoAs someone who's written custom mvc's in vanilla js/ts on an as-needed basis since long before vue or react were a thing, I agree completely. The reason I've never tried to formalize my frameworks into something for the community is that I don't need another full time job, and don't have any desire to hear the moaning and abuse that inevitably comes when you open source a tool you think will speed up development. I.e. everyone has an opinion. I don't use frameworks because I don't like my codebase sliding out from under me, when I have projects in production for over 10 years that just need occasional new features. The froth of frameworks and keeping up with them seems to be maximally important to devs looking for office jobs... once you freelance and have time to roll your own, it's just kinda the same routine over and over. I feel bad for folks who have to spend such an inordinate amount of time just learning and working around new tooling. In the end if you spend the time writing it yourself you end up with a better understanding of its strengths and weaknesses. You never need to consult Stack overflow to find out how to deal with your own MVC stack.
- paulryanrogers 4y agoIf you built it, yes. For everyone else, no. Bespoke systems inevitably become their own custom frameworks. And knowledge of them doesn't transfer as well. This isn't always a bad thing. It offers maximum control and possibly shallower dependency trees. Personal job security as well. At the cost of slower onboarding. The older I get the more bog-stanadard and boring I prefer for solutions that I use or build.
- woojoo666 4y agoAnd this is a great thing actually. Easy and accessible means good UX. Look at how Apple designs their products. You need a gentle learning curve. But while it starts easy, Javascript can be as hard as you want it to be, with a very high skill cap (eg going from optimizing your website to building a framework that generalizes those optimizations).
- rk06 4y agoWhile that does explain why there are so many js frameworks, on top of my head react, angular, Vue, Aurelia, solid, svelte, mithril, ember, marko etc, it does not explain why ecosystem has not stabilised by now. That is because js and it’s ecosystem itself is ever changing and improving itself, this makes yesterday’s trade off invalid today. This results in newer improvements requiring a fresh start (churn) or breaking changes For eg: ESM support in evergreen browsers can’t be leveraged without libraries producing ESM build which requires changes, and in some cases breaking changes. React hooks created a paradigm shift, which while innovative, made existing code legacy.