Show HN: A simple website for my JavaScript bundler

by ianertson • 5 years ago

55 22 5 years ago

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.

chrismorgan2• 5 years ago

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.

ianertson7• 5 years ago

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.

ianertson7• 5 years ago

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.

nicoburns• 5 years ago

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.

eyelidlessness3• 5 years ago

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.

constexpr5• 5 years ago

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.

ianertson7• 5 years ago

Thanks for the tip, will make sure to fix this

constexpr5• 5 years ago

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!

darepublic• 5 years ago

A good idea, webpack is annoying sometimes

carlbarrdahl• 5 years ago

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!)

ianertson7• 5 years ago

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

andrew_• 5 years ago

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.

Show HN: A simple website for my JavaScript bundler

Related Stories