I just use the very large subset of JavaScript supported natively by all major JS engines and avoid a transpiler entirely. Infinity times faster. That's subset is ES9/ES2018. https://wwwperiodictable.surge.sh/
Esbuild 0.9
101–110 of 123 posts
Re: Esbuild 0.9
#102Re: Esbuild 0.9
#103esbuild has flipped the JS community on its head. Not only as an impressive JS bundler, but through all the next gen tooling esbuild is powering. For example, you can now speed up your Webpack build with esbuild by replacing babel-loader/ts-loader/Terser: https://github.com/privatenumber/esbuild-loader (It also blows my mind that Evan is the CTO is Figma. How is he so productive!?)
> (It also blows my mind that Evan is the CTO is Figma. How is he so productive!?) When Evan first joined Figma, he saw how much time the engineers spent on waiting for webpack and fighting JS configuration files. Then one time, during an outage, the developers tried to push a fix but the build was failing because babel-deduplicate-int had changed their API interface but only did a minor version bump when published t…
Yeah that's a red flag "all work stops while executive does x then all processes must change to revolve around x"
Re: Esbuild 0.9
#104Earlier quoted context omitted.
That and the fact that unless you have two monitors often as you save the refresh happens out of view, when you’re not seeing the page, so you lose the immediate visual feedback of what actually changes. When you make minute touches to a design it’s annoying. When I hit F5 myself I can look at exactly what I’m interested and see if it shifted some pixels, if the font size is a bit better or worse...
> unless you have two monitors Or have your editor and browser window tiled next to each other? Given how often FE development dabbles with design, using at least one decently sized monitor seems requisite. And aren't FEers generally tweaking design in the DOM via a browser's developer tools when they're not sure what they want yet, copying back over into source once the design is finalized? Seems downright unpleasan…
It's often much faster to make the change in the code directly than in the dev tools. For instance, I can very quickly apply a LESS mixin to an element, which would require knowing and making those specific changes to the raw CSS via the browser. The same goes for pretty much anything that's more than a one-value change.
Re: Esbuild 0.9
#105How does Esbuild achieve such insane differences in speed?
It is written in go and compiled. Go is responsible for high parallelism. The fact it is compiled is an advantage over javascript-based bundlers because they are re-compiled every time you start building the source code (did I get that right?).
partially. we should not overstate the impact of Go. if you read his design principles doc, he also prioritized parallelization and minimizing JS AST passes. those are surely at least as important as language choice.
Re: Esbuild 0.9
#106Earlier quoted context omitted.
> (It also blows my mind that Evan is the CTO is Figma. How is he so productive!?) When Evan first joined Figma, he saw how much time the engineers spent on waiting for webpack and fighting JS configuration files. Then one time, during an outage, the developers tried to push a fix but the build was failing because babel-deduplicate-int had changed their API interface but only did a minor version bump when published t…
Yeah that's a red flag "all work stops while executive does x then all processes must change to revolve around x"
It worked out ok for linux and git.
Re: Esbuild 0.9
#107esbuild has flipped the JS community on its head. Not only as an impressive JS bundler, but through all the next gen tooling esbuild is powering. For example, you can now speed up your Webpack build with esbuild by replacing babel-loader/ts-loader/Terser: https://github.com/privatenumber/esbuild-loader (It also blows my mind that Evan is the CTO is Figma. How is he so productive!?)
> (It also blows my mind that Evan is the CTO is Figma. How is he so productive!?) When Evan first joined Figma, he saw how much time the engineers spent on waiting for webpack and fighting JS configuration files. Then one time, during an outage, the developers tried to push a fix but the build was failing because babel-deduplicate-int had changed their API interface but only did a minor version bump when published t…
> (This is all fictional, of course)
Haha, you really had me going with that first paragraph. Felt so real.
Re: Esbuild 0.9
#108I just use the very large subset of JavaScript supported natively by all major JS engines and avoid a transpiler entirely. Infinity times faster. That's subset is ES9/ES2018. https://wwwperiodictable.surge.sh/
Good for you. Now try getting a job with that on your resume.
Re: Esbuild 0.9
#109An extremely fast JavaScript bundler and minifier
esbuild.github.io/
Re: Esbuild 0.9
#110esbuild has flipped the JS community on its head. Not only as an impressive JS bundler, but through all the next gen tooling esbuild is powering. For example, you can now speed up your Webpack build with esbuild by replacing babel-loader/ts-loader/Terser: https://github.com/privatenumber/esbuild-loader (It also blows my mind that Evan is the CTO is Figma. How is he so productive!?)
Is this pretty much a drop in replacement for babel-loader or does it lack certain features? Edit: Kind of. It was really simple to switch over and build. But the optimizer example actually makes my output much larger than the webpack default settings. Also it can't seem to handle the "implicitly assume I have React in scope for each JSX file." It felt maybe twice as fast, but not 10-100x to really game change my dev…
We switched two weeks ago and the drop was a bit more than half the total time we had with Webpack in development and a bit bigger drop in production builds.
Our bundle got noticeably smaller, but we chalked that up to esbuild not polyfilling for as early a target as we had been with babel-loader.