It's strange that they are comparing output size without passing --minify to esbuild. Why compare the size of the debuggable output?

And if you care about output size, you would also need to pass --define:process.env.NODE_ENV=\"production\" to esbuild since the benchmarks include React, and you don't want to bundle both the debug and release versions of React at the same time.

Thanks for the tip, will make sure to fix this

I noticed you changed this to "dev" instead of "production". Just letting you know that this will select the development build of React instead of the production build, which is not optimized for size and will lead to a bigger output file.

Good luck with your project!

Yes, this is because Im building it in "dev" for FJB as well. The circumstances should be equal for all benchmarks.

Ah I see, no worries. I assumed you were trying to compare against a production build since that's what "parcel build" does.

Right, I'll have to fix this too

Nothing below is meant as criticism just an acknowledgment of the complexity of the space. I wish you all the luck!

> Most bundlers allows you to select an output format of the code, such as: "CommonJS", "AMD", "System", "UMD", "ES6", "ES2015" or "ESNext" FJB does not implement this concept. Instead, FJB adapts the code automatically through static analysis. FJB aims to generate code that works everywhere (when possible). A bundler should be smart enough so that the developer can focus on other things. :brain:

That sounds nice. In practice other tools that make similar promises end up being a big ball of incompatibility and config and plugins. I hope this won’t happen here!

> TypeScript support (currently unstable and under development)

IMO this is make or break for any tool I’d consider and I’ve had enough trouble with ESBuild and SWC which don’t even warn about incompatibilities that I’m wary.

That output format thing is just weird. It hand-waves rather than describing what it actually does (“adapts the code automatically through static analysis” is vapid), and a large part of what I can only presume it is describing is flatly impossible: you can’t output something compatible with both ECMAScript Modules and CommonJS, for example, because they’re syntactically incompatible.

I do know that I dislike things that try to support CommonJS or AMD or just dropping things into global variables, because I will only ever want it in one way, but it’s wasting a few hundred bytes of code supporting the others. But I am zealous for dead code removal to a degree that most aren’t.

What I mean with "adapts the code through static analysis" is:

1. Finds dead code and removes it 2. It converts nodejs code that isn't compatible with the browser into browser code 2. It converts JS code that isn't compatible with nodejs to nodejs code

It tries to always make things work both in nodejs and browser js.

One example is the optional chain syntax which doesn't work in nodejs but works in the browser. FJB converts it to something that works everywhere.

> 2. It converts nodejs code that isn't compatible with the browser into browser code 2. It converts JS code that isn't compatible with nodejs to nodejs code

I’m not sure what that lot means. Are you talking about converting CommonJS to… I dunno, ECMAScript Modules? and vice versa? And there’s plenty that’s available in the NodeJS or web environments that’s simply unavailable in the other, e.g. the "http" and "https" modules from NodeJS and the fetch() global in the web, and you often can’t translate between the two at all, and even if you can, it’d be decidedly messy.

Output format is almost orthogonal to what I understand you to be talking about. In the terms of other bundling stuff, you seem to be talking more about features of Babel rather than features of webpack/Rollup, and if so, then output format is completely orthogonal.

Optional chaining's in Node as of v14.5.

Sure, but it was just an example of what kind of things FJB is doing to the code

> I’ve had enough trouble with ESBuild and SWC which don’t even warn about incompatibilities that I’m wary.

We're just in process of integrating ESBuild for stripping TypeScript types at work. I'd be interested to hear more about these incompatibilities you've encountered.

In one case it complained about the opening brace of a props spread on a JSX expression. In another case it complained about an unexpected question token with no line number so I couldn’t find what the issue was. In both cases they were perfectly valid TypeScript according to tsc and VSCode. For that usage I just gave up. It’s working well for me in other projects/contexts though.

It would be great if you could file these as bugs against esbuild! Sounds like these should be easy to fix.

It would be great and in the one case I will when I have space to come back to it, since I could isolate it. In the other case idk what to file other than “open source project I contribute to has a file with a question mark that your compiler doesn’t like”.

Both would be good to file. I’m happy to investigate myself if you don’t have the time.

One thing to be aware of is that some other tools that integrate esbuild do so incorrectly. For example, the 3rd-party integration of esbuild into Webpack mis-configures esbuild in a way that causes issues with JSX: https://github.com/privatenumber/esbuild-loader/pull/107. This isn’t a problem with esbuild itself.

I'm planning to make the typescript support an optional feature, so that one could integrate something else.

We will see.

Anyhow, appreciate your feedback.

Parcel started out with nearly the exact same message "don't get in the user's way." Unfortunately, that project like every other bundler, found that mission untenable the more the project and userbase grew. These projects invariably start with the intention of taking care of the author's use case (and there's nothing wrong with that) but neglect larger ecosystem needs. That results in these kinds of bundlers being niche (see: Fastpack).

It all boils down to the need for complex builds to handle complex assets, and having to deal with the CommonJS format hell scape. (~90% of issues posted for Webpack and Rollup concern CommonJS format and Node-flavored module resolution) Once those two ecosystem concerns begin to be met, bundlers start getting in the user's way, because they have to.

ESBuild has legs, and may avoid a lot of the pitfalls, but only time will tell - it's very promising. None of this is to dissuade the author, or any potential users, from trying this new bundler out. However, over the last 8 years or so I've seen these kinds of promises many times. This is a situation in which the big players (Rollup, Webpack, et al) are complex where they are, because they have to be.

Well done! Noticed some 404 links on the docs page you might want to take a look at.

(cool to see your project on HN frontpage, Sebastian!)

Hey!! Great to see you here ;)

Yes that docs page is actually auto generated from the github README, and it doesn't convert the links to anything appropriate

A good idea, webpack is annoying sometimes