36 ms·

To me what’s interesting is that ESBuild (which is a Go based JavaScript bundler) has come out of nowhere in a relatively short period of time, and it’s basical

To me what’s interesting is that ESBuild (which is a Go based JavaScript bundler) has come out of nowhere in a relatively short period of time, and it’s basically already better than any of the existing JS JS bundlers. Not just faster: it also has a radically simpler UI.

dntrkv 6y ago
That makes perfect sense though. Older projects have a ton of baggage that they carry through all of the revisions. New-comers to the space can learn from the mistakes of previous approaches and also utilize the latest and greatest paradigms to solve the problem without worrying about backwards compatibility.
- ch4s3 6y ago
  They usually have fewer features as well, and not having to support features with weird edge cases always helps.
fn1 6y ago
That is because it is NOT written in JavaScript. I have written JS since 1997 and kept up with ES6 and so on over the years. Used it in frontend until now. The JavaScript-ecosystem just isn't very productive [1] for multiple reasons. The language is untyped. You have no multi-threading. It's hard to debug. You have to spend many brain-cycles on learning Browser-problems, which muddles your understanding of the language. The web-way of: we can fix it and everyone will reload the browser, leads to a "don't care" attitude. For web/backend this is approachable, though still not good. For build-systems this is terrible. Why? Because if a bug shows up in a build-system you stop a million developers from being productive. The bug won't get fixed right away, most will just work around it, use different plugins, copy/paste yet another webpack config etc. Plus JavaScript tends makes people realized what FP is, and they all start putting functions in their functions and making everything modular and plugin-able. (See high-order-components in React). While this can be nice, it leads to even more confusing bugs. Writing plugin-architectures is hard in any language. Writing it in JavaScript is a recipe for disaster. Hence the modern JS-ecosystem. [1] Google: nullpointerexception -> 4.360.000 results Google: undefined is not a function -> 800.000.000 results
- eurleif 6y ago
  > Google: nullpointerexception -> 4.360.000 results > Google: undefined is not a function -> 800.000.000 results You didn't put quotation marks around the second, and the first has no spaces, so this is not a fair comparison. "undefined is not a function" with the quotation marks has 449,000 results.
  - fn1 6y ago
    Right, thank you.
  - dimitropoulos 6y ago
    see above, but this basically this is inaccurate. I don't doubt that there are many results for "undefined is not a function", but I feel quite confident saying there aren't anywhere near 449,000. If you ask google for just 111 of them, you'll get "In order to show you the most relevant results, we have omitted some entries very similar to the 110 already displayed."
- dimitropoulos 6y ago
  please please please do not use google's results as an indication of really anything at all. Don't take my word for it, do this test: search something, like the name of someone you know that's not famous. You'll find that google will reports tens of thousands (or millions! lol) of results. But click through 10 or 15 pages. You'll soon find that many of the pages have almost nothing at all to do with what you searched (and may not even contain any word from the phrase!), but that if you get far enough, maybe 300 results or so in, you'll see that when google runs out of results it will magically just update to show the real number, which is often just a few dozen for a search like the one I described.
sibeliuss 6y ago
> It’s basically already better than any of the existing JS JS bundlers This statement assumes that there's basic feature parity between ESBuild and tools like webpack, which is straight up false.
- regularfry 6y ago
  And that assumes that more features is necessarily better, which is also false.
  - sibeliuss 6y ago
    I think it's more a misunderstanding of the domain. Bundlers are not all about speed.
thiht 6y ago
This is because it doesn't do anything yet. I look forward to the day it's usable in production, but today is not the day. And don't forget Parcel which also have the simplest possible UI.
- RobertKerans 6y ago
  This categorically not true. It does exactly the thing it's supposed to do. Yes, it is best that potential users wait for now, but that isn't because it "doesn't do anything". What it _doesn't_ do currently is provide an API which would allow it to be plugged in a similar way to Webpack (not exactly the same, as the deliberate aim is not to cover every usecase, as Webpack allows). This is a requirement for wider adoption as a competitor (rather than just as the module bundling step). Plus the tree shaking needs work, though I think that is less important than has sometimes been made out. Parcel may have a simple API for simple things, but it's extremely slow and generally suffers from exactly the same issues outlined by OP.

dntrkv 6y ago

That makes perfect sense though. Older projects have a ton of baggage that they carry through all of the revisions. New-comers to the space can learn from the mistakes of previous approaches and also utilize the latest and greatest paradigms to solve the problem without worrying about backwards compatibility.

ch4s3 6y ago
They usually have fewer features as well, and not having to support features with weird edge cases always helps.

fn1 6y ago

That is because it is NOT written in JavaScript. I have written JS since 1997 and kept up with ES6 and so on over the years. Used it in frontend until now. The JavaScript-ecosystem just isn't very productive [1] for multiple reasons. The language is untyped. You have no multi-threading. It's hard to debug. You have to spend many brain-cycles on learning Browser-problems, which muddles your understanding of the language. The web-way of: we can fix it and everyone will reload the browser, leads to a "don't care" attitude. For web/backend this is approachable, though still not good. For build-systems this is terrible. Why? Because if a bug shows up in a build-system you stop a million developers from being productive. The bug won't get fixed right away, most will just work around it, use different plugins, copy/paste yet another webpack config etc. Plus JavaScript tends makes people realized what FP is, and they all start putting functions in their functions and making everything modular and plugin-able. (See high-order-components in React). While this can be nice, it leads to even more confusing bugs. Writing plugin-architectures is hard in any language. Writing it in JavaScript is a recipe for disaster. Hence the modern JS-ecosystem. [1] Google: nullpointerexception -> 4.360.000 results Google: undefined is not a function -> 800.000.000 results

eurleif 6y ago
> Google: nullpointerexception -> 4.360.000 results > Google: undefined is not a function -> 800.000.000 results You didn't put quotation marks around the second, and the first has no spaces, so this is not a fair comparison. "undefined is not a function" with the quotation marks has 449,000 results.
- fn1 6y ago
  Right, thank you.
- dimitropoulos 6y ago
  see above, but this basically this is inaccurate. I don't doubt that there are many results for "undefined is not a function", but I feel quite confident saying there aren't anywhere near 449,000. If you ask google for just 111 of them, you'll get "In order to show you the most relevant results, we have omitted some entries very similar to the 110 already displayed."
dimitropoulos 6y ago
please please please do not use google's results as an indication of really anything at all. Don't take my word for it, do this test: search something, like the name of someone you know that's not famous. You'll find that google will reports tens of thousands (or millions! lol) of results. But click through 10 or 15 pages. You'll soon find that many of the pages have almost nothing at all to do with what you searched (and may not even contain any word from the phrase!), but that if you get far enough, maybe 300 results or so in, you'll see that when google runs out of results it will magically just update to show the real number, which is often just a few dozen for a search like the one I described.

sibeliuss 6y ago

> It’s basically already better than any of the existing JS JS bundlers This statement assumes that there's basic feature parity between ESBuild and tools like webpack, which is straight up false.

regularfry 6y ago
And that assumes that more features is necessarily better, which is also false.
- sibeliuss 6y ago
  I think it's more a misunderstanding of the domain. Bundlers are not all about speed.

thiht 6y ago

This is because it doesn't do anything yet. I look forward to the day it's usable in production, but today is not the day. And don't forget Parcel which also have the simplest possible UI.

RobertKerans 6y ago
This categorically not true. It does exactly the thing it's supposed to do. Yes, it is best that potential users wait for now, but that isn't because it "doesn't do anything". What it _doesn't_ do currently is provide an API which would allow it to be plugged in a similar way to Webpack (not exactly the same, as the deliberate aim is not to cover every usecase, as Webpack allows). This is a requirement for wider adoption as a competitor (rather than just as the module bundling step). Plus the tree shaking needs work, though I think that is less important than has sometimes been made out. Parcel may have a simple API for simple things, but it's extremely slow and generally suffers from exactly the same issues outlined by OP.