Live data from Hacker News

Esbuild – An extremely fast JavaScript bundler

esbuild.github.io

281–288 of 288 posts

Re: Esbuild – An extremely fast JavaScript bundler

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

No more than people think making it to the Olympics is "black magic".

Re: Esbuild – An extremely fast JavaScript bundler

#282
post #277

Earlier quoted context omitted.

>when everybody starts using wasm I would say this is a far off possibility. The need to write WASM code rarely surfaces for the average SPA, and really seems like its more applicable to games or sites with heavy processing needs. For better or worse, it's going to be JS/TS for a long while yet.

I avoided this fact for years, running from JS/TS for “better languages”. After a stint with Haskell I’ve decided the grass isn’t that much greener so just accepting that JS is what it is - one of the worlds most popular languages which can run in most places and therefore worth learning.

I'm curious, what turned you away from Haskell?

Re: Esbuild – An extremely fast JavaScript bundler

#285

Earlier quoted context omitted.

Indeed, the best build chain is no build chain at all. I've been ridiculed at work for not using node, npm, web pack etc -- but I'm not spending 20% of my time on tooling issues.

I'm interested to know who you know spends 20% of their time on tooling issues... I use node, npm and webpack pretty regularly (albeit parcel has mostly replaced webpack for me) and other than setting up some npm scripts and a tsconfig to output the right js for my node version at the start of a project, I barely interact with them.

I think it's more like 80% of time at the start of any project, and then trickles down to no time, then up to 80% again when there's a new feature/config/incompatibility with tooling. In larger projects and in orgs, you often have legacy choices that you have to deal with, that you can't remove or spend time replacing.

Re: Esbuild – An extremely fast JavaScript bundler

#286
post #113

You know you are getting old when you watch the arrival of the fourth JavaScript build tool of your career. I still remember when everyone was waving goodbye to Gulp in favour of Webpack. Webpack was going to save us all from the hell of massive convoluted gulp.js files. Fast forward five years and it's the same mess it was supposed to avoid. Slow, bloated and confusing. I just switched to esbuild on our main project…

I have not done web development. Please forgive my ignorance. How is this different from Angular and React?

Re: Esbuild – An extremely fast JavaScript bundler

#287
post #38
post #8

What I need is a similar speedup for my Typescript and eslint checks. Bundling isn’t my main issue.

> Bundling isn’t my main issue. This. Bundling, and even barreling, have pretty much been solved problems for a while. Right now I feel that unit test frameworks, linters, and type checkers are by far the main bottlenecks in the development workflow.

Yeah, Jest is the slowest thing in my build pipeline.

Re: Esbuild – An extremely fast JavaScript bundler

#288

Earlier quoted context omitted.

I'm interested to know who you know spends 20% of their time on tooling issues... I use node, npm and webpack pretty regularly (albeit parcel has mostly replaced webpack for me) and other than setting up some npm scripts and a tsconfig to output the right js for my node version at the start of a project, I barely interact with them.

I think it's more like 80% of time at the start of any project, and then trickles down to no time, then up to 80% again when there's a new feature/config/incompatibility with tooling. In larger projects and in orgs, you often have legacy choices that you have to deal with, that you can't remove or spend time replacing.

With all due respect, that measurement doesn't make a lot of sense! I spend 100% of my time waiting for my editor to open at the start of the day :)
Post reply on HN