261–270 of 288 posts
Well, I spent few days to move large vue.js codebase from webpack 4 to Vite (esbuild). You know what? It isn’t as fast as that benchmarks shows us, even buggy and laggy. So upgraded to webpack 5 with caching to filesystem (I bet no one know) and it became even faster than Vite! I’m happy.
Earlier quoted context omitted.
This is a great point. A "Cambrian explosion" the likes of which the JS ecosystem experienced over the last 10-15 years will slow down eventually. Curious to hear whether other folks agree or not.
I survived the JavaScript Cambrian explosion and all I got was a disenchantment with computer programming
How does esbuild compare to Bun, snowpack, Vite, and any other JS bundles? In performance, reliability, and extra features?
"Snowpack already uses esbuild internally as our default single-file builder for JavaScript, TypeScript and JSX files."
https://www.snowpack.dev/posts/2021-01-13-snowpack-3-0#built...
Earlier quoted context omitted.
Remember when all of these points applied to webpack, when it was the “single simple fast tool” to replace everyone’s grunt scripts? It seems there’s a feature treadmill at work here where projects inexorably bloat as they get popular. But we tried “compose tools in the Unix way” with grunt too, and that led to spaghetti scripts, unique to each project, that were hard to reason about. I wonder if there is a middle wa…
Something a lot of people don’t appreciate is that the past ten years have been an anomaly for JavaScript. They’ve been very tumultuous because there was a ton of evolving that suddenly needed to happen. And I think we’re nearing the end. Babel was necessary because core syntaxes were changing so fast. Webpack’s sprawling nature was needed because there were so many alternate dialects, module systems to support, etc.…
Maybe things are going to calm down a bit? I could believe it. But I just don't see the churn stopping. The browser-as-OS is going to keep getting new features, which JS must bind to. And some users are going to use old browsers that don't support them. So the runtime is inexorably fragmented, vs. say a server-side environment where you mostly write code for a well-known runtime that you get to define.
And what about when everybody starts using wasm to compile other languages into JS? Another explosion of tooling and changes to how we do web development is just round the corner.
Regardless of whether we're coming to the end of it, I think it's more specific than just "growing pains" though - it's not just that we're fixing issues, it's that we're repeatedly throwing away old tools in favor of smaller, more-focused new tools, that then in turn grow in scope over time.
I'm not even mad at all this; I think it's a fundamental part of how software languages and communities make progress; there's no real path for a language/tool/framework to get _smaller_, so they either increase in scope or stay the same, with the latter being quite rare, and both options giving a path for some other thing to supersede them.
I just think it's most pronounced in the JS ecosystem, and find it amusing that we've come full circle on so many of these points, again - although I believe with genuine improvements on the previous iterations. (So more like a spiral; the same location in some dimensions, but with a higher elevation.)
Does esbuild support scss directly yet? I see on the site it mentions css. This is an important limitation for me.
[1] https://github.com/glromeo/esbuild-sass-plugin
[2] https://hexdocs.pm/phoenix/asset_management.html#esbuild-plu...
Maybe it'll help someone, one difference from the plugin doc was using:
const { sassPlugin } = require("esbuild-sass-plugin");
Instead of:
import { sassPlugin } from "esbuild-sass-plugin";
After all, it would not be Javascript without some import syntax shenanigan ;)
I've been trying to figure out how to build JS projects with the evolving tools (grunt => gulp => webpack => parcel => back to webpack) for years. I stumbled on esbuild and thought why not. Within about 15 minutes, I had solved pretty much all our build issues. Admittedly, our use case was simple-- we needed to transpile React-flavored TS to a npm package. In about 6 lines of code, I had a working bundle. There were…
We switched to an esbuild/vite/rollup stack mid year and had the same experience, it's black magic compared to web pack et al
That's old news or? For complex projects moving to esbuild from say Webpack is not necessarily easy.
Earlier quoted context omitted.
Something a lot of people don’t appreciate is that the past ten years have been an anomaly for JavaScript. They’ve been very tumultuous because there was a ton of evolving that suddenly needed to happen. And I think we’re nearing the end. Babel was necessary because core syntaxes were changing so fast. Webpack’s sprawling nature was needed because there were so many alternate dialects, module systems to support, etc.…
I take your point, but I think you could fairly say that JS has been going through growing pains since its inception 25 years ago. It's always been a fast-moving, inconsistently-implemented language. (E.g. Netscape / Mozilla vs. IE support for browser features). Maybe things are going to calm down a bit? I could believe it. But I just don't see the churn stopping. The browser-as-OS is going to keep getting new featur…
I would say this is a far off possibility. The need to write WASM code rarely surfaces for the average SPA, and really seems like its more applicable to games or sites with heavy processing needs.
For better or worse, it's going to be JS/TS for a long while yet.
Earlier quoted context omitted.
If you take the perspective that some people are "just better" than others, why are we idolizing these people? Being born with high intelligence and favourable traits is not an achievement.
> If you take the perspective that some people are "just better" than others, why are we idolizing these people? Good question. Take it up with the people wearing jersey's with Lebron James' and Aaron Rodgers' names on them.
Earlier quoted context omitted.
Remember when all of these points applied to webpack, when it was the “single simple fast tool” to replace everyone’s grunt scripts? It seems there’s a feature treadmill at work here where projects inexorably bloat as they get popular. But we tried “compose tools in the Unix way” with grunt too, and that led to spaghetti scripts, unique to each project, that were hard to reason about. I wonder if there is a middle wa…
ESBuild’s author and docs[1] are quite clear about its future scope: > [… a list of features that are already done…] > After that point, I will consider esbuild to be relatively complete. I'm planning for esbuild to reach a mostly stable state and then stop accumulating more features. This will involve saying "no" to requests for adding major features to esbuild itself. I don't think esbuild should become an all-in-o…
I think by the time we even care about the performance of a plugin being "golang" fast, we will have rome built in rust.
Rome will be the full kit and caboodle at native speeds (bundler, tree shaking compiler, linter, type checker, etc...), whereas esbuild will be the rome-lite for when you just want to bundle some code and have it done.