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

Esbuild 0.9

github.com

Post reply on HN
Print view View original

51–60 of 123 posts

Re: Esbuild 0.9

#51

Post by madjam002 »

nicoburns wrote: post #43
madjam002 wrote: post #42

Earlier quoted context omitted.

Amazing stuff, I was thinking of doing pretty much exactly this this morning. Out of interest, if you’re bundling with Esbuild before running, how do you cope with native dependencies?

We don't use esbuild's "bundle" (--bundle) option, which means that our files get processed one-by-one and end up as separate files in the `dist` directory that we output to and that dependencies aren't processed at all and are just `required` like normal by our transpiled code. Our build command (in a bash script file to avoid string escaping issues) is: find src -type f \( -name '*.js' -o -name '*.ts' -o -name '*.s…

Thanks for sharing, I’ve just given it a go with one of my larger projects and WOW!! Typescript incremental compilation was taking around 2 seconds on every save, then Nodemon would restart etc.

I’ve plugged in Esbuild, I have used bundle mode though to see what it’s like, it works fine if I external all of my node modules, it builds in 0.23 seconds (approx 350 source files in my project).

Nodemon now watches for TS file changes and exec’s the esbuild on every start.

Thank you for the pointer to this as this will be a much needed productivity boost!

I’ll try bundling some node modules when I have some time but it will take more work as I use Yarn PnP (I’ve found a plug-in so will definitely try that)

Re: Esbuild 0.9

#52

Post by nperez »

izelnakri wrote: post #39
lhorie wrote: post #25

Earlier quoted context omitted.

He said in the past that he's not interested in implementing HMR[0] [0] https://github.com/evanw/esbuild/issues/97

I'm actually very happy that esbuild doesnt have HMR by default. Despite the fact that most frontend devs loving/hyping HMR, I prefer live-reloads more because it refetches data/makes network calls and run my route hooks without any additional step. This is particularly important when you run your application tests in the browser(thats better than running app tests in CI btw) and change these test files constantly. T…

I’ve been a f/e dev for around a decade and I don’t trust HMR. I end up refreshing manually anyway just so I know I’m not seeing issues that don’t exist due to event bindings not refreshing properly, or app state getting messed up between loads. It’s fine for styling, but worries me when there’s too much complexity involved

Re: Esbuild 0.9

#53

Post by teryyy »

Scramblejams wrote: post #44
qbasic_forever wrote: post #37

The JS & frontend world is _seriously fun_ right now. If you blew it all off as a quagmire of complexity, sketchy engineering, treadmill of tools, etc... it's time to re-evaluate everything. I have more fun and feel more productive working on modern frontend stuff with tools like esbuild than any other GUI programming I've done in 30 years.

Yep, I tried front-end way back and hated it. Can you mention some other tech that should be covered in my re-evaluation?

TailwindCSS, Svelte, and Snowpack are probably worth a shot, all pretty much bleeding edge

Re: Esbuild 0.9

#54

Post by [deleted] »

earthboundkid wrote: post #26
picardo wrote: post #16

Earlier quoted context omitted.

esbuild can be a good alternative to Webpack in some cases, but Webpack solves a lot of edge cases well. For example, just today I debugged an issue where a library had used `require` in an ES module instead of `import`, and that broke the build with esbuild. So I had to fork the library to fix that issue. Webpack handles that case without problems. I can think of at least a few cases like that where Webpack works be…

> Webpack solves a lot of edge cases well I would quibble with the word "solves". Webpack is a tool building tool. With Webpack, you can build a tool to solve your edge case problem, as long as you're willing to spend a lot of time and dig through random Github issues for your dependencies. Webpack itself however does basically nothing.

[deleted]

Re: Esbuild 0.9

#55

Post by protoduction »

Scramblejams wrote: post #44
qbasic_forever wrote: post #37

The JS & frontend world is _seriously fun_ right now. If you blew it all off as a quagmire of complexity, sketchy engineering, treadmill of tools, etc... it's time to re-evaluate everything. I have more fun and feel more productive working on modern frontend stuff with tools like esbuild than any other GUI programming I've done in 30 years.

Yep, I tried front-end way back and hated it. Can you mention some other tech that should be covered in my re-evaluation?

I'm really biased as I am building it myself: Starboard Notebook puts literate programming into the browser without a lot of magic.

It's amazing what browsers can do these days without any build step!

[0]: https://starboard.gg

Re: Esbuild 0.9

#56

Post by jmondi »

I really really wish this supported experimental decorators with reflection metadata so we could use this in our Angular and NestJS apps.

Re: Esbuild 0.9

#58

Post by lame88 »

qbasic_forever wrote: post #37

The JS & frontend world is _seriously fun_ right now. If you blew it all off as a quagmire of complexity, sketchy engineering, treadmill of tools, etc... it's time to re-evaluate everything. I have more fun and feel more productive working on modern frontend stuff with tools like esbuild than any other GUI programming I've done in 30 years.

Every time I am unfortunate enough to do something front-end it's just as bad as I remember.

Edit: professionally, that is; when I do front-end related stuff for myself, it's fine, but they are small and I keep things simple - vanilla JS where needed, etc.

Re: Esbuild 0.9

#59

Post by AltruisticGapHN »

nperez wrote: post #52
izelnakri wrote: post #39

Earlier quoted context omitted.

I'm actually very happy that esbuild doesnt have HMR by default. Despite the fact that most frontend devs loving/hyping HMR, I prefer live-reloads more because it refetches data/makes network calls and run my route hooks without any additional step. This is particularly important when you run your application tests in the browser(thats better than running app tests in CI btw) and change these test files constantly. T…

I’ve been a f/e dev for around a decade and I don’t trust HMR. I end up refreshing manually anyway just so I know I’m not seeing issues that don’t exist due to event bindings not refreshing properly, or app state getting messed up between loads. It’s fine for styling, but worries me when there’s too much complexity involved

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

Re: Esbuild 0.9

#60

Post by qbasic_forever »

Scramblejams wrote: post #44
qbasic_forever wrote: post #37

The JS & frontend world is _seriously fun_ right now. If you blew it all off as a quagmire of complexity, sketchy engineering, treadmill of tools, etc... it's time to re-evaluate everything. I have more fun and feel more productive working on modern frontend stuff with tools like esbuild than any other GUI programming I've done in 30 years.

Yep, I tried front-end way back and hated it. Can you mention some other tech that should be covered in my re-evaluation?

React & next.js are worth evaluating. It's a super powerful full stack with everything from server side rendered data (REST APIs even) all the way to complete client-side SPAs, all using the same react components. It's a slick little swiss-army knife that can make anything from a basic blog with markdown content, to a static marketing page, to a full client-first PWA experience. There is sadly almost nothing else really like it right now.

MDX is another neat step, it's markdown + react components and fits in very well with next.js: https://github.com/hashicorp/next-mdx-remote

Vue, and Svelte to just get an idea of what other components systems are like. They're all equally capable and just have different tradeoffs and styles. Keep an eye on Svelte in particular as its next.js-like system (SvelteKit) is working on a major revamp to be serverless-first and is quite interesting. Once you learn one component system it's easy to switch between them all--they're all cribbing and building on top of each other's ideas. The whole space is innovating in a great way.

Web components are good to learn and compare to component frameworks above. It's still a changing space but points to a nice future where we can all just publish and share components.

Post reply on HN