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

Some notes on using esbuild

jvns.ca

Post reply on HN
Print view View original

81–90 of 205 posts

Re: Some notes on using esbuild

#81

Post by drenvuk »

Bellend wrote: post #51

> “webpack” which I will not try to explain much because I don’t understand it, I think it’s a system with a million plugins that does a million things Is webpack really considered such a difficult beast? I was an early adopter of TypeScript so I think I started with grunt, then gulp, then finally webpack 3, 4 and now 5. I mean it's not my main job or anything, and I don't really enjoy configuring things but spending…

“Ah you think darkness is your ally? You merely adopted the dark. I was born in it, molded by it. I didn't see the light until I was already a man"

Sorry for this, but I find the parallels a bit funny.

Re: Some notes on using esbuild

#82

Post by Griffinsauce »

phist_mcgee wrote: post #38
swyx wrote: post #7

Julia is one of my favorite examples of learning in public as a developer. Her technical chops are unquestioned so when she says things like "I have no idea what import does" it really drives home how much the JS community has to do to bring along the rest of the developer population who just wants to make web stuff occasionally without going to JS Build Tool University. I love this and maybe it would be great for so…

Can you link which Julia you are speaking about?

You might want to click the article link..

Re: Some notes on using esbuild

#83

Post by mkl »

madeofpalk wrote: post #75
mkl wrote: post #60

Earlier quoted context omitted.

It's holding JavaScript to its own higher standard: is dead simple, and trivial to understand and get working. NPM, import, etc. seem mindbogglingly complex in comparison, with an enormous number of ways to do each thing, most of which require at least one build step just doesn't, and enormous numbers of third party dependencies, and if you go away for a few months and come back, there are good odds things will be di…

still works. Feel free to keep using it.

I do, but it's not well supported by a lot of packages. I dig around manually for URLs on unpkg and other JS CDNs, but most libraries' instructions just say "run npm ... or yarn ...". Maybe that complexity's worth it, but understanding what's going on is a barrier for me to use it, just like Julia describes.

Re: Some notes on using esbuild

#84

Post by badthingfactory »

swyx wrote: post #7

Julia is one of my favorite examples of learning in public as a developer. Her technical chops are unquestioned so when she says things like "I have no idea what import does" it really drives home how much the JS community has to do to bring along the rest of the developer population who just wants to make web stuff occasionally without going to JS Build Tool University. I love this and maybe it would be great for so…

My primary frustration with frontend development is that I have gone to JS Build Tool University... Roughly 10 times now. I'm not sure I've ever set up two separate frontends the same way. Even when I avoid the shiny new tools and stick with crusty slow webpack, there's a new version that behaves entirely different than the previous version. I'm enjoying the speed and simplicity of ESBuild.

Re: Some notes on using esbuild

#85

Post by smt88 »

maccolgan wrote: post #74
smt88 wrote: post #52

Earlier quoted context omitted.

Import in JavaScript is significantly more varied and complex than import in any other language I know about. There are multiple historical module systems, various official and unofficial syntaxes, and also the require keyword. It is an absolute mess. I don't know anyone who understands all of the various flavors.

You're saying Java & Maven/Gradle are simpler than even Nodejs or ESM workflows?

Maven and Gradle are build tools, similar to esbuild.

I was talking about import in JavaScript itself, not build tools or package managers.

Within the actual language, there isn't a universal syntax just to use a package. In Java, there is.

Re: Some notes on using esbuild

#86

Post by Bellend »

morelisp wrote: post #66
Bellend wrote: post #51

> “webpack” which I will not try to explain much because I don’t understand it, I think it’s a system with a million plugins that does a million things Is webpack really considered such a difficult beast? I was an early adopter of TypeScript so I think I started with grunt, then gulp, then finally webpack 3, 4 and now 5. I mean it's not my main job or anything, and I don't really enjoy configuring things but spending…

> I have a couple of files, one for local one for production. About 50-70 lines each I don't think you realize how hellish this sounds. I haven't had >100 lines of build configuration in any other environment since my configure.in/Makefile.am days, and even that was more transferable to other tools than Webpack, which is only good for Webpacking.

What would be the alternative in todays projects? Like typescript and scss need compiled, then there are builds which are minified with source maps vs local which isn't, then people want browserlist and scss linting and so on. I don't see how configuration can be escaped but I would be happy to have a path forward to change that if I knew how.

Re: Some notes on using esbuild

#87

Post by smt88 »

KptMarchewa wrote: post #73
smt88 wrote: post #52

Earlier quoted context omitted.

Import in JavaScript is significantly more varied and complex than import in any other language I know about. There are multiple historical module systems, various official and unofficial syntaxes, and also the require keyword. It is an absolute mess. I don't know anyone who understands all of the various flavors.

Python?

I think you may be referring to package management rather than the import syntax of the language.

Re: Some notes on using esbuild

#88

Post by dmitriid »

oefrha wrote: post #44
dmitriid wrote: post #41

Earlier quoted context omitted.

Yeah, it looks like rolling our own esbuild commands might be the way to go because "just switch to vite already" doesn't work, does it?

If you can roll your own esbuild commands to build your codebase without change, good for you. Once you’ve done that, good luck figuring out a dev server with HMR, since esbuild certainly doesn’t offer that.

> Once you’ve done that, good luck figuring out a dev server with HMR, since esbuild certainly doesn’t offer that.

Because vite does, and "just go with vite", right?

Re: Some notes on using esbuild

#89

Post by llimllib »

Bellend wrote: post #51

> “webpack” which I will not try to explain much because I don’t understand it, I think it’s a system with a million plugins that does a million things Is webpack really considered such a difficult beast? I was an early adopter of TypeScript so I think I started with grunt, then gulp, then finally webpack 3, 4 and now 5. I mean it's not my main job or anything, and I don't really enjoy configuring things but spending…

> Is webpack really considered such a difficult beast

For whatever it's worth, I'm the sort of person who writes makefiles for fun, and I regularly work with the build systems of go, C, rust, java, ruby, python, and javascript.

webpack is easily the most complicated, slow, frightening build system I have ever encountered and I will go far out of my way to avoid it.

Re: Some notes on using esbuild

#90

Post by Bellend »

hsn915 wrote: post #80
Bellend wrote: post #51

> “webpack” which I will not try to explain much because I don’t understand it, I think it’s a system with a million plugins that does a million things Is webpack really considered such a difficult beast? I was an early adopter of TypeScript so I think I started with grunt, then gulp, then finally webpack 3, 4 and now 5. I mean it's not my main job or anything, and I don't really enjoy configuring things but spending…

The problem with webpack, beside being very slow, is it's based on config files. Config files are brittle and very hard to understand. Spending several days sifting through the webpack docs and maintaining 70 lines of config files sounds like a nightmare. Now, for esbuild, I have more lines than that for the build script, but the thing is, it's just code. The configuration part is about 10 lines. The other stuff is j…

The reason I moved away from gulp (v3?) at the time was because I considered configuration (especially an intellisense configuration) really simple as opposed to the god awful pipable javascript files gulp went for.

Not sure how much that plays to my strengths though because everything I have ever used has json file configurations or object file configurations.

Anyway I am definitely going to kick some tires on ESBuild, but I will just wait a while so thanks for some additional insight.

Post reply on HN