Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Esbuild – An extremely fast JavaScript bundler

esbuild.github.io

Post reply on HN
Print view View original

241–250 of 288 posts

Re: Esbuild – An extremely fast JavaScript bundler

#241

Post by pineconewarrior »

kureikain wrote: post #6

esbuild is fast but it has a lot of place you have to figure out yourself and get into your way of doing thing. 1. dev server: you have to write a bit of code for this server to act as webpack dev server 2. scss: need to install plugin, and plugin cannot use from command line then you need to write a bit of JavaScript 3. global function: if you do `process.env` now you need to inject into build script 4. node package…

How is the SCSS performance? I've tried just about every trick in the book in an attempt to get our bootstrap-based SCSS projects to compile faster, and I'm at my wits end with it.

Any chance you can share your config?

Re: Esbuild – An extremely fast JavaScript bundler

#242

Post by dgritsko »

brundolf wrote: post #234
theptip wrote: post #216

Earlier quoted context omitted.

Remember when all of these points applied to webpack, when it was the “single simple fast tool” to replace everyone’s grunt scripts? It seems there’s a feature treadmill at work here where projects inexorably bloat as they get popular. But we tried “compose tools in the Unix way” with grunt too, and that led to spaghetti scripts, unique to each project, that were hard to reason about. I wonder if there is a middle wa…

Something a lot of people don’t appreciate is that the past ten years have been an anomaly for JavaScript. They’ve been very tumultuous because there was a ton of evolving that suddenly needed to happen. And I think we’re nearing the end. Babel was necessary because core syntaxes were changing so fast. Webpack’s sprawling nature was needed because there were so many alternate dialects, module systems to support, etc.…

This is a great point. A "Cambrian explosion" the likes of which the JS ecosystem experienced over the last 10-15 years will slow down eventually. Curious to hear whether other folks agree or not.

Re: Esbuild – An extremely fast JavaScript bundler

#243

Post by pineconewarrior »

horsawlarway wrote: post #168
whoisthemachine wrote: post #158

Earlier quoted context omitted.

I felt the same, the industry's shift away from the gulp way of doing things was a real loss.

I feel like Gulp sort of shot itself in the foot. As someone who liked Gulp (SOOO much more than Grunt/Browserify) the transition from v3 to v4 felt really, really bad. Lots of unknowns around release timing, poor community support for the new version, "beta" tags sticking around forever long after it should have been released, maintainer turnover, etc... It was enough at the time to get me to jump to Webpack, since…

You're right about the community being mostly dead. There are a lot of bugs and performance issues in the underlying libraries, and Gulp's developers have not been able to get the upstream updates integrated.

I just redid our Grunt stuff in Gulp. It was painful - difficult to find up-to-date information, and the result was not that great. I expected a much greater SCSS compilation performance increase compared to FS-based tooling. Maybe I'm doing something wrong.

I'd switch to something like ESBuild and leave SCSS for dead, but it's not an option for me yet :(

Re: Esbuild – An extremely fast JavaScript bundler

#244

Post by pineconewarrior »

towndrunk wrote: post #175

Does esbuild support scss directly yet? I see on the site it mentions css. This is an important limitation for me.

Same! I am struggling with SCSS tooling. SCSS/SASS itself even seems like it is in dire need of maintenance and direction.

Personally I'd rather not use it at this point, but it's not viable yet

Re: Esbuild – An extremely fast JavaScript bundler

#245

Post by xeromal »

maga wrote: post #110

Often overlooked things when discussing esbuild here: 1. It's not just a faster replacement for a single %tool_name% in your build chain: for the vast majority of cases, it's the whole "chain" in a single cli command if you're doing it right. That is, you don't just stick it inside, say, webpack as a faster replacement for babel (although you can). No, you look carefully through your webpack configs and its myriad of…

Has anyone given you crap for your username? I know you had the username long before MAGA became a popular word in the american lexicon, but I'm still curious!

Re: Esbuild – An extremely fast JavaScript bundler

#246

Post by xeromal »

ZephyrBlu wrote: post #152
depr wrote: post #140

Earlier quoted context omitted.

Perhaps that is what makes them '10x developers': a great familiarity with their toolset and a deep understanding of the problems they are solving. In this sense I don't think it's bad to idolize them, as familiarity and understanding are achievable by many people, and they could all become a '10x developer'.

The thing is that people tend to appear to think it's black magic rather than familiarity with a toolset and a deep understanding of the problem.

That's not all it is. Some people are just better than others. No matter how hard every tries to be the best football or basketball player, only an extremely small set of people even have the chance to make it. There are physical traits they'll never have and mental fortitude to use those traits. You can't grow yourself to 7 ft tall and you never will be able to. What makes you think the brain is any different.

Re: Esbuild – An extremely fast JavaScript bundler

#247

Post by kureikain »

pineconewarrior wrote: post #241
kureikain wrote: post #6

esbuild is fast but it has a lot of place you have to figure out yourself and get into your way of doing thing. 1. dev server: you have to write a bit of code for this server to act as webpack dev server 2. scss: need to install plugin, and plugin cannot use from command line then you need to write a bit of JavaScript 3. global function: if you do `process.env` now you need to inject into build script 4. node package…

How is the SCSS performance? I've tried just about every trick in the book in an attempt to get our bootstrap-based SCSS projects to compile faster, and I'm at my wits end with it. Any chance you can share your config?

My project is small and it's amazing fast to me as well. It's basically just outsource its job to another cli. I used esbuild-plugin-sass

This is the gist https://gist.github.com/v9n/c40a6ad2078d09dd86117924b415b7fb

As far as I know, esbuild has no intention to integrate with CSS and will outsorce it to plugin.

I used

Re: Esbuild – An extremely fast JavaScript bundler

#248

Post by jscambrian »

dgritsko wrote: post #242
brundolf wrote: post #234

Earlier quoted context omitted.

Something a lot of people don’t appreciate is that the past ten years have been an anomaly for JavaScript. They’ve been very tumultuous because there was a ton of evolving that suddenly needed to happen. And I think we’re nearing the end. Babel was necessary because core syntaxes were changing so fast. Webpack’s sprawling nature was needed because there were so many alternate dialects, module systems to support, etc.…

This is a great point. A "Cambrian explosion" the likes of which the JS ecosystem experienced over the last 10-15 years will slow down eventually. Curious to hear whether other folks agree or not.

I survived the JavaScript Cambrian explosion and all I got was a disenchantment with computer programming

Re: Esbuild – An extremely fast JavaScript bundler

#249

Post by Rapzid »

antihero wrote: post #148
maga wrote: post #110

Often overlooked things when discussing esbuild here: 1. It's not just a faster replacement for a single %tool_name% in your build chain: for the vast majority of cases, it's the whole "chain" in a single cli command if you're doing it right. That is, you don't just stick it inside, say, webpack as a faster replacement for babel (although you can). No, you look carefully through your webpack configs and its myriad of…

We're using Vite and enjoying it, would you say much of Vite could be replaced with pure esbuild? I guess Vite provides a nice development experience but is built on esbuild.

There is a short paragraph adressing this on the "Why Vite" page: https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuil...

I'm also a huge fan of HMR, and esbuild in the past has been anti-HMR.

Re: Esbuild – An extremely fast JavaScript bundler

#250

Post by maga »

xeromal wrote: post #245
maga wrote: post #110

Often overlooked things when discussing esbuild here: 1. It's not just a faster replacement for a single %tool_name% in your build chain: for the vast majority of cases, it's the whole "chain" in a single cli command if you're doing it right. That is, you don't just stick it inside, say, webpack as a faster replacement for babel (although you can). No, you look carefully through your webpack configs and its myriad of…

Has anyone given you crap for your username? I know you had the username long before MAGA became a popular word in the american lexicon, but I'm still curious!

Yeah, the funny part is that I have never even been to US of A let alone having anything in common with the said movement. No, to be honest, I don't recall anyone mentioning it here on HN or GitHub. I don't use other social media, though, I guess it would be more of an issue there. However, I was wrongly suspended on Twitter once despite not posting (or even "liking") anything the whole decade of being there. I just used the account for OAuth subscription, one day it stopped working, I had to write a letter and wait for manual "unsuspension.

I chose my now "nom de plume" way back in zeros for its seeming originality and simplicity, when compared to my rather common and unwieldy "real" Polish name.

Post reply on HN