Spent the last few months migrating to Vite. The Javascript ecosystem is exhausting and exhilarating all at the same time

No telling how many sides the next iteration of the wheel may have but one thing's for certain: That one will be the ultimate version.

Well at least Vite does not lock you in the Next.js eco-system, so it's something ¯\_(ツ)_/¯.

Overall the community is starting to embrace better languages for tooling, primarily Rust with some Go and Zig sprinkled in. Eventually I think we will hit a point where there will be a defacto dev tool that can take a web app and package it however you want, deploy it wherever you want, and do it very quickly. Some would argue those exist now, but until it can be done literally everywhere, painlessly, I would contend we aren't there yet. It's probably more likely something like WASM/WASI takes over before then honestly.

What I hate about javascript fatigue is that there's never enough time for something to mature before it gets replaced. Documentation always covers the basic scenarios and never any edge cases. Sooner or later you end up trying to find a solution in a github issue 20 pages down.

I think webpack is a special exception. It somehow revised the whole 5 major version and still don't get a proper plugin development document at all, not even basic one. You don't even have a flow graph that tells you events happen in which order. Everyone either Google and copy paste random example or reading the source by themselves.

It always amazed me that such a big project can just live without docs.

that's the only thing agile people got from the manifesto

an excuse not to write docs, ever

it's endemic in the majority of companies I've seen in the last 10 years

hopefully tooling (eg. docs.rs mostly automatically generated and pleasant to use) will help in the long term

Sigh another one? I thought Vite was the new thing.

Sigh? I think the speed improvement is awesome.

It is awesome to see so much innovation, but it can be exhausting to keep up.

I'm quite alright with new tooling every six months when the new thing is orders of magnitude faster. If people want to compete to make my job as a frontend dev easier and faster, that is just fine.

Ideally we could learn how to make the existing tools better/faster and create software that can evolve rather than re-writing everything from scratch every six months.

I suspect at some point we hit the limit of the language performance. I can't imagine JavaScript beating Rust when both are written well.

There was many years before people started trying to replace Webpack.

True but webpack itself had a ton of churn and made practically no effort to maintain backwards compatibility causing a ton of work with each major update.

Hmm, I am using it since v2 and I disagree, it was not so bad. I saw a lot of people had overcomplicated configs that could be simplified a lot, I guess those had some problems upgrading... But mine never had much problems (and not just because my needs were simple...), I just removed some options when going to v4 and that's about it.

I think the issue starts when xyz new tool requires you to write code specific to that thing, which is something I avoid as much as possible. IMO they should strive to stay out of the way as much as possible and just bundle/optimize/tree-shake and not worry about extending JS as a language or nodejs as a runtime or doubling as a build tool or a filewatcher or a development server etc etc (see the UNIX philosophy 'do one thing well'), even at the expense of less optimal/fast builds. As soon as you start doing stuff like importing your images into your javascript so your bundler can do compiler tricks, you're painting yourself into the corner.

One recent offering I enjoyed working with was esbuild, as I could use it's CLI as part of my existing build system incrementally instead of planning my whole system around it.

There's a few facets to consider:

1. Does code written a particular way?

2. Does it need to be configured?

3. Does it conflict with other tooling?

4. Does it have limitations that are too restrictive?

5. Does it cause bugs/issues that are difficult to resolve?

The ideal tool just does its thing, doesn't need any code written or configuration, works no matter what other tooling you're using, has no limitations, and will never itself cause a bug.

That might not be realistic to do 100%, but I think it's what all tools should be aiming for.

>On an application with 3,000 modules, Turbopack takes 1.8 seconds to boot up, while Vite takes 11.4 seconds.

How many apps are dealing with 3,000+ modules?

At the pace the javascript ecosystem is going, by next year it will be almost all of them. Create react app for a new default project pulls in 1400 packages, 300 MB in size, just to put a hello world page on a screen. That nobody thinks this is absolutely bonkers drives me absolutely bonkers.

Plenty of people think it's bonkers and the informed frontend perspective is to not use CRA anymore: https://www.youtube.com/watch?v=7m14f0ZzMyY

Informed developers don't use CRA anymore.