The constant iteration and revolution of basic front-end web dev makes me happy to be a mobile dev.
Maybe plastering a power strip into a wall rather than doing proper electrical work is a better metaphor. Everybody knows it’s a bad idea, but someone made a thing that automatically provisions and deploys new strips, and someone made a thing that plugs stuff in, and someone made a thing that mixes and applies plaster which was replaced by a drywall thing but we still call it plaster, and someone else made a thing that does it in 10 rooms at once…
That said, this seems like a bigger step towards simplifying both the development process AND the toolchain. It only works in newer browsers so it doesn't immediately work for all use cases, but it's good enough for some. We're quickly approaching the point where browser-native implementations of more recent, better designed scripting features are widespread enough to rely on. That should both simplify and stabilize front-end web development for quite some time.
But it’s wonderfully healthy for an environment to be so alive and full of innovation.
Bazaar vs. Cathedral and whatnot. It’s easier for some to just be prescribed a specific SDK.
I think it's an obvious truth that too little innovation/choice is bad. I don't think you'll find any arguments there!
Is there a point where too much of it becomes harmful? For close to ten years now, I feel that experienced and inexperienced devs alike have been confused and repulsed by the utter state of constant wheel-reinvention in the frontend space.
(Perhaps to my own detriment, I've focused on backend work because I'm waiting for the front-end situation to stabilize. Which of course may never happen. Maybe "full-stack dev" is something that will wind up in the history bin next to "webmaster")
It’s easier for some to just be prescribed a specific SDK.
I think the situation with backend frameworks is sort of what many would like to see. Django, Rails, Express, etc. No shortage of choice and there is innovation. Yet I don't think anybody would call it chaotic. For me that is a happy middle ground.
I thought that for sure, by 2017 or so, we'd have seen a relatively long lived consensus winner like we saw during jQuery's reign.
Instead, it's just been constant roiling.
The roiling is hard to understand because it's not like the other parts of the stack are really mutating that quickly. Backend dev practices/technologies and browser capabilities are not evolving or roiling at anywhere close to this rate. This sort of churn would have made sense during say 1997-2002 when the entire stack was being invented and reinvented and the basic idea of browsers themselves were changing rapidly.
According to the latest Stack Overflow survey[0], the most popular is React, which hasn't been the top for the last 7 years. And I wouldn't call jQuery the obvious choice before that, as it's been consistently fading in popularity.
https://insights.stackoverflow.com/survey/2021#most-popular-...
Is this actually better than Webpack and esbuild/Parcel/Rollup/whatever that came before it? Or is it just another opinionated way of packaging stuff up that's faster because it doesn't support 10% of the feature set the other tools do yet?
Looking at the "Why Vite" page, most of the blurbs are basically saying "Existing tools are slow". Well, I bet those existing tools are probably capable of doing 10x of what Vite can do currently. And how much faster IS Vite when bundling a large project? Nothing on that, only some charts with lines saying that they do it differently. They say 10-100x speedup on "prebundling", but if that part of the build is only a small portion of the overall build it might be negligible. Also, they say it's faster because Go. Well I kind of like the dogfooding of all the build tools for JS being written in JS - why introduce a whole new ecosystem here?
Not trying to be a naysayer here, I'm just asking why mindshare should be devoted to yet another project that looks like reinvention of the wheel and starting the cycle anew again when we could instead contribute mindshare to existing mature projects - the reasoning given on the site doesn't seem to be very compelling.
You might find this answer helpful, about Rome which is like Vite but in Rust rather than Go [0], crucially:
> This justification -- Rome should be written in JS otherwise Rome users are less likely to contribute -- irresponsibly focuses on a secondary goal of the project, at the cost of the primary goal, which is to be a end-to-end toolchain for one of the most popular languages in the world.
Speed matters. It is not a sideline consideration, it should be one of the main considerations, over and above a tool being in the same language. In fact, many say that rewriting JS tools in non-JS faster languages will be the future [1].
[0] https://news.ycombinator.com/item?id=28609474
[1] https://leerob.io/blog/rust#the-future-of-javascript-tooling (https://news.ycombinator.com/item?id=29192088)
Complaining about bad frontend tooling would be more appropriate to do in a thread that's not about a tool that practically solves it.
Instead of complaining about other tools, these people who don't know what Vite is should be curious and asking what it is, or what it has that's new. That is easy to find out.
> Well, I bet those existing tools are probably capable of doing 10x of what Vite can do currently.
Good luck with your bet.
Js is an ever changing mass of stuff. I feel bad for frontend guys for this reason. Always writing for a language that does not even exist... always changing how you shove it all together.
Even worse as soon as you put a foot down and pick something you are behind.
It is exhausting even to watch much less to be in it.
It took me about an hour to figure out nothing I tried to set up worked because I had installed Vue 3 and mostly everything else was still on Vue 2.
Reminds me of Angular 2 rewriting their router every 6 weeks - to the point that they just moved on to calling it Angular 3 at release to rid themselves of the information on StackOverflow that was in a constant state of deprecation.