Live data from Hacker News

Show HN: A simple website for my JavaScript bundler

fjbundler.com

11–20 of 23 posts

Re: Show HN: A simple website for my JavaScript bundler

#11

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 possi…

> 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.

Re: Show HN: A simple website for my JavaScript bundler

#12

Earlier quoted context omitted.

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…

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…

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

Re: Show HN: A simple website for my JavaScript bundler

#13
post #12

Earlier quoted context omitted.

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…

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

Re: Show HN: A simple website for my JavaScript bundler

#14
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.

Re: Show HN: A simple website for my JavaScript bundler

#15

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 possi…

> 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.

Re: Show HN: A simple website for my JavaScript bundler

#16

Earlier quoted context omitted.

> 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.

Re: Show HN: A simple website for my JavaScript bundler

#17

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!

Re: Show HN: A simple website for my JavaScript bundler

#18

Earlier quoted context omitted.

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.

Re: Show HN: A simple website for my JavaScript bundler

#19

Earlier quoted context omitted.

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.

Re: Show HN: A simple website for my JavaScript bundler

#20

Earlier quoted context omitted.

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…

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…

> 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.

Post reply on HN