Show HN: A simple website for my JavaScript bundler
fjbundler.com
Show HN: A simple website for my JavaScript bundler
1–10 of 23 posts
Re: Show HN: A simple website for my JavaScript bundler
#2Nothing 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.
Re: Show HN: A simple website for my JavaScript bundler
#3It'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.
Re: Show HN: A simple website for my JavaScript bundler
#4A good idea, webpack is annoying sometimes
Re: Show HN: A simple website for my JavaScript bundler
#5Well 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!)
Re: Show HN: A simple website for my JavaScript bundler
#6Nothing 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…
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.
Re: Show HN: A simple website for my JavaScript bundler
#7Well 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
Re: Show HN: A simple website for my JavaScript bundler
#8It'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
Re: Show HN: A simple website for my JavaScript bundler
#9Nothing 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'm planning to make the typescript support an optional feature, so that one could integrate something else.
We will see.
Anyhow, appreciate your feedback.
Re: Show HN: A simple website for my JavaScript bundler
#10Nothing 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…
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 converts it to something that works everywhere.