201–210 of 215 posts
Rspack (ByteDance) just shipped 1.0. There's Farm too. This is from Ant Group. Major influx of build tools all built in Rust, made in China. Turbopack is supposed to be coming, as a total rebuild of bundling. Rolldown seems solid, as a Rust roll-up redo.
I'm not a web developer, though I still develop web apps regularly. What exactly is the point of a bundler in the rapid development cycle? If you want your web app to load up fast, it's better if you only need to redownload the parts that actually changed, so you're better off not bundling them.
Earlier quoted context omitted.
When you say dead code elimination, do you mean if I import some huge library just to use a single function, the bindler will shimmy things about so only the single function is being included in package and not the big library? If so, that's amazingly helpful, I'm mostly over in python data land and I wish that existed for applications, although admittedly there's less need.
Yes, exactly. Pulling a huge npm dependency is usually not a problem if they didn't go out of their way to make it super hard to analyze at build time. This is tree shaking though, dead code elimination means it will find code that isn't used at all and remove it - for example you might have if (DEV) {...}, and DEV is static false at build time, the whole if is removed. So first it performs dead code elimination, the…
Makes me wonder why some js bundles are still so big, am I over hyping what dead code elimination and tree shaking might achieve? Do some teams just not use it?
Either way, I've come away from my question with a pretty big reading list. This is exactly what I love about HN.
Earlier quoted context omitted.
Yes, exactly. Pulling a huge npm dependency is usually not a problem if they didn't go out of their way to make it super hard to analyze at build time. This is tree shaking though, dead code elimination means it will find code that isn't used at all and remove it - for example you might have if (DEV) {...}, and DEV is static false at build time, the whole if is removed. So first it performs dead code elimination, the…
That's very cool! I already knew that this was something compilers did, but somehow never even considered you might do the same for an interpreted language like js. Makes me wonder why some js bundles are still so big, am I over hyping what dead code elimination and tree shaking might achieve? Do some teams just not use it? Either way, I've come away from my question with a pretty big reading list. This is exactly wh…
Some bundles may still be big if teams don't use it, and some libraries are not structured in a way that facilitates dead code elimination.
Consider libraries that use `class`, such as moment.js, all functionality is made available as methods on the Moment class. If you only use 1 method, you still have to bring in the whole class. Whereas if a library is structured as free functions and you only use one, then only that gets included and the rest is eliminated.
How does it compare to esbuild or swc? Its good we have alternatives, and im still mentally scarred from the javascript ecosystem, where almost everything is slow and buggy. But when you compare to an already native tool (like esbuild) you start getting diminishing returns.
SWC doesn't bundle at all. Esbuild is a pretty good bundler but works well only if your code and dependencies use ESM, it's not as good as other options with CommonJS.
I cannot attest to that. We are using Esbuild plus CJS at $DAYJOB no problem. Why would that be an issue?
Earlier quoted context omitted.
SWC doesn't bundle at all. Esbuild is a pretty good bundler but works well only if your code and dependencies use ESM, it's not as good as other options with CommonJS.
> Esbuild [...] works well only if your code and dependencies use ESM I cannot attest to that. We are using Esbuild plus CJS at $DAYJOB no problem. Why would that be an issue?
Earlier quoted context omitted.
esbuild is written in Go, which has similar "probably quite fast and easy to install" properties to Rust. Compare that to the expected experience if it was written in C++ or JavaScript or Python or Java or ... All of those are either likely to be slow or painful to use.
To be fair, you can package a modern Java app into a single executable [1], without the entire JRE shipped inside. Few people do that though. [1]: https://www.graalvm.org/latest/reference-manual/native-image...
How small is that compared to the JRE? Also I guess this means the program cannot load arbitrary classes?
Earlier quoted context omitted.
All of these are lessons learned from previous iterations. Also, some of these were probably in development for a while. If you're close to finishing a product, do you just stop and abandon months of work just because a challenger appeared? I wouldn't! Especially if you think you're doing something better than the competition I've managed to cut down build times from ~1min (sometimes up to 3, but I couldn't even tell…
I've abandoned lots of projects when a worthy competitor appeared. They can take the burden of maintenance, yes please.
I'm sure people tied up in the roll-up ecosystem think the same about Vite and rolldown!
All these do things subtly differently in ways they think is the correct way. Maybe one will come on top or maybe something else comes along and integrates lessons from both and that eventually wins and all meintence moves there eventually.
The JS ecosystem is complex (for better or worse), and bundling for it isn't a simple as people believe. So it makes sense there's multiple things trying to tackle the same problem!
Earlier quoted context omitted.
I fully agree with you, and want to add: JS/TS due to it's accessibility is one of the largest eco systems. Hell, whether you are or aren't a devekoper you're part of it through using a browser. People often scoff at complexity in frontend projects, but they need to handle various types of accessibility, internationalisation, routing and state including storage of those, due to its popularity it's also very frequentl…
> People often scoff at complexity in frontend projects The complexity is there because everyone is trying to reinvent everything. > accessibility, internationalisation, routing and state including storage of those Do multi-pages apps and most of these are really trivial due to the amount of solutions that exists. > There's various authentication and authorization standards That's also more of a server concerns than…
Earlier quoted context omitted.
I fully agree with you, and want to add: JS/TS due to it's accessibility is one of the largest eco systems. Hell, whether you are or aren't a devekoper you're part of it through using a browser. People often scoff at complexity in frontend projects, but they need to handle various types of accessibility, internationalisation, routing and state including storage of those, due to its popularity it's also very frequentl…
> People often scoff at complexity in frontend projects The complexity is there because everyone is trying to reinvent everything. > accessibility, internationalisation, routing and state including storage of those Do multi-pages apps and most of these are really trivial due to the amount of solutions that exists. > There's various authentication and authorization standards That's also more of a server concerns than…
> The complexity is there because everyone is trying to reinvent everything.
That's not just JS. That's literally everywhere. People reinvent ideas in every codebase I've seen. Sometimes it's a boon, sometimes it's a detriment. But again, not something that's unique to JS.
> Do multi-pages apps and most of these are really trivial due to the amount of solutions that exists.
None of these are trivial, even with existing solutions. They're only trivial for trivial cases. Like, I'm sure we both understand people aren't building to-do demos.
> It isn't the old IE days
Probably happened accidently, but it kinda misconstructs what I'm saying. There are issues between renderin engines and variety in how much/quickly they adopt some features. Hell, you still need code branches just for Safari in some cases becaus of how it handles things like private browsing.
> Build a desktop app.
You're trading one world of complexity for another world of complexity (or I guess we could say it's trading one set of platform quirks for a larger set of platform quirks)
> Because it's like watching Sisyphus pushing the stone up again and again. The same problem is being solved again and again and if you want to use the latest, you have to redo everything.
I understand where you're coming from, but just because Svelte was released it doesn't make React (and spin-offs) or Vue less relevant. You're not force to use them.
Regarding the bundling topic, again you're not forced to awirch to a different bundler if you're happy with your existing one, or the project isn't at a scale where it matters.
I think the pressure is internal, not external.