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

91–100 of 123 posts

Re: Esbuild 0.9

#91

Post by christophilus »

EMM_386 wrote: post #50
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.

I agree. I was a web developer in the 90s when stuff was primitive, ugly and difficult. I switched to desktop .Net development in 2001 did that for almost 15 years. Since then I have been back on the web. I am full-stack so I find myself switching between front-end and back-end frequently. I am enjoying my time more in the world of TypeScript, VS Code, and Angular than I am writing the back-end REST APIs in .Net Core…

My career sounds much like yours, and my conclusions are the same. Typescript is a decent language. The tooling is excellent. The old footguns are mostly behind us. It’s definitely a completely new ballgame vs the old hackery I used to have to endure.

Re: Esbuild 0.9

#92

Post by stefan_ »

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.

Drag&drop building UI in Visual Whatever was plenty productive, hell they even had what the kids today call server rendering, and if it didn't look right I could always press F5 and see the result right there.

Re: Esbuild 0.9

#93

Post by christophilus »

AbuAssar wrote: post #6

esbuild makes it pretty clear that writing the JS ecosystem in JS is a bad choice*. now we need to rewrite tsc/babel/npm/eslint/etc... in a language that compile down to native binary that is also cross platform (like go or rust), to gain the same performance improvements across the entire JS tool-chain. * based on the benchmark on their landing page.

I don’t think so. I’d bet that a JS solution that followed esbuild’s architecture would be in the same order of magnitude of performance.

Now, you could argue that JS encourages complex, inefficient abstractions and over engineering and Go encourages the opposite. That, I’d believe.

Re: Esbuild 0.9

#94

Post by tony »

For those relying on babel - what are the options?

One thing I haven't seen yet is support for SCSS and CSS Modules. It looks like projects on those would need to switch to emotion+styled-components or styled-system, which would be a big move.

If anyone uses relay, I started an issue here about using it with next-gen bundlers like esbuild: https://github.com/facebook/relay/issues/3319

For those who don't know, relay is a graphql system by facebook. It seems dependent on babel (to my knowledge?) Two developments on this front:

1. @sciyoshi built an esbuild proof of concept for relay: https://gist.github.com/sciyoshi/34e5865f2523848f0d60b4cdd49...

2. Meanwhile, the compiler has been being quietly rewritten in rust: https://github.com/facebook/relay/tree/master/compiler. They're also claiming that it will include type generation.

Re: Esbuild 0.9

#95

Post by Waterluvian »

privatenumber wrote: post #62

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

Re: Esbuild 0.9

#97

Post by 1_player »

qbasic_forever wrote: post #82
1_player wrote: post #79

Earlier quoted context omitted.

The problem with front end development is that it's all bleeding edge and nothing that's stable and is improved for more than one hype cycle. Suggesting more bleeding edge tech is not a good argument to demonstrate that front end development got better. In my experience, it changed, it improved on many aspects, but it's still a pile of unstable crap running on the power of hype and over-enthusiastic junior engineers.

I get your frustration (and shared it a year ago), but you're really doing something like react a disservice by dismissing it like that as just hype. On the contrary react has evolved significantly over the years, introducing things like JSX (templating HTML + JS in the same file, now standard in every other component system), build tooling like create-react-app (zero config tooling, now standard in every JS build to…

I am not dismissing it. I appreciate what React is doing, and it is indeed revolutionary.

My point is that there has been a lot of evolution and improvement, but developer sanity is one of the few things that have just gone worse.

It is dishonest to look only at the bright side of modern frontend coding and forgetting the node_modules nightmare, the incredibly obtuse language, the slow compilation times, the myriad of CSS frameworks that are invented because CSS is an absolute pain in the arse for modern design, etc., the fact that every JS tool either is core to the whole circus and is maintained by a stressed out, underpaid person in the middle of nowhere, or has a minimum of 5k Github issues and a major version released every 3 months, and every time you get a problem you're told "haven't you tried the new alpha release of the big rewrite we've just started?".

It is absolute madness, not just frustrating. But yeah, React is cool.

Re: Esbuild 0.9

#98

Post by jakub_g »

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

IIRC, HMR in webpack has an issue when you add/remove/possibly reorder imports in JS; the imports are cached in memory by their index (or something like this), so when you remove a fifth import, suddenly the previously-sixth import statement will refer to the wrong module after HMR.

Took me a good while to understand the issue is with HMR and not my code. I restart the dev server many times a day just to be sure or when things inevitably explode.

Re: Esbuild 0.9

#99

Post by wdb »

searchableguy wrote: post #81
wdb wrote: post #48

Earlier quoted context omitted.

Yes, but a bunch of the Typescript support is closed sourced . No idea, if that's important for you.

Type checker, yes. I don't think esbuild comes with a built-in typechecker either. Is there anything else I am missing?

I was referring to swc

Re: Esbuild 0.9

#100

Post by jakub_g »

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.

"webpack does basically nothing"

https://bundlers.tooling.report/

webpack: 43.5/48

rollup: 40.5/48

parcel: 31.5/48

Post reply on HN