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

191–200 of 205 posts

Re: Some notes on using esbuild

#191

Post by throwaway894345 »

morelisp wrote: post #180
throwaway894345 wrote: post #167

Earlier quoted context omitted.

I tend to agree with the overall thrust of your argument and the conclusion you're driving toward, but it's at least interesting to note that the distribution model of the web puts unique pressure on tools to ship dramatically smaller payloads. In Go or Rust, we ship debug symbols in production builds by default (or whatever it is which give us stack traces on panic), but in JS sourcemaps typically aren't shipped in…

> the C build ecosystem is quite a lot worse than the JS ecosystem Other than module packaging (and that's admittedly a big "other than"), I don't agree. Esbuild is the first tool I used that's even close to e.g. Make in comprehensibility (~ ease of use x flexibility x ability to debug when something goes wrong). That's a pretty low bar, and I don't know how long esbuild will stay that way.

Agree to disagree I guess. I don't want to go to bat for JS, but I've done more than my share of C and C++ and Make, CMake, Autotools, etc are just fucking nuts, and that's ignoring the fact that they completely punt on package management. JS is painful by the standards of modern programming languages, but C and C++ are on the next level.

"Stockholm Syndrome" is the only way I can rationalize people vouching for C or C++ (or JS, to a significantly-lesser-but-still-not-negligible extent) build tooling.

Re: Some notes on using esbuild

#192

Post by elevader »

throwaway894345 wrote: post #165
elevader wrote: post #122

Earlier quoted context omitted.

Most languages also don't really have to worry about shipping dozens of plaintext source code files over the wire that then might get executed in an environment you have no control over that doesn't actually support the code you wrote (There are still people running old IE versions and loosing 1% of customers might be really costly at scale). I'm not saying that the current ecosystem isn't an overly complex mess but…

I empathize with the unique difficulties of the web and I don't doubt that the complexity solves for real problems (e.g., old IE versions); however, I take issue with treating all problems as equal irrespective of how niche those problems are. The C and C++ folks make the same kind of argument to justify their abusive build systems--if the build systems made sane assumptions, then it would exclude certain niche use c…

Webpack sure has problems (for example speed) but most of the more niche things that people do aren't actually supported by it but implemented through the plugin system, at which point any category of niche/sane kind of flies out of the window. If you enable people to do weird things people will do weird and maybe unwise things. The best solution might be to take notes of how people tend to develop js stuff nowadays, scrap javascript completely and use something completely new that doesn't have the issues of javascript. But that seems rather unrealistic at this point.

Re: Some notes on using esbuild

#193

Post by andrei_says_ »

andrei_says_ wrote: post #190
oefrha wrote: post #16

If you're going to have a build step at all, instead of hand rolling your build commands and configs, just use Vite[1] already. It uses esbuild for development and rollup for production (since esbuild is not featureful enough for a lot of production use cases), you get instantaneous startup, hot module replacement, static asset imports, etc. for free. It's from Evan You, the creator of Vue, but it also supports React…

I’d love to. Would you help me set it up to process SCSS with dart-sass and load stimulusjs controllers as well as possibly jquery and some other packages in conjunction with 11ty, middlemanapp or rails? All I need is processing of scss and mostly vanilla js. Is this possible?

I just discovered that vite uses js to paste your css in the html?! So no way to use unless I let it also process the html files?

Re: Some notes on using esbuild

#194

Post by onion2k »

mst wrote: post #182
onion2k wrote: post #13

I can't decide if the root cause of this problem is in esbuild or in Vue. The fact you can't do "import vue from 'Vue';" with esbuild means either it's module resolver is terrible, or Vue is doing something super-weird with the way it bundles artifacts. Either way, something is seriously wrong. FWIW, "import react from 'React';" works fine with esbuild with no config, so I'm inclined to think this is a problem in Vue…

That doesn't seem like a good comparison because what was missing in her case was the Vue equivalent of the JSX compile phase.

esbuild works with jsx out of the box. Most of the examples in the docs are jsx.

Re: Some notes on using esbuild

#195

Post by jpgvm »

js2 wrote: post #185
jpgvm wrote: post #110

Earlier quoted context omitted.

Gradle is capable of very powerful things so on larger projects there is generally a project specific Gradle dialect in play and I can understand why this frustrates newcomers but it's an important capability for large projects and monorepos. I would say most small projects (especially OSS) tend to stick to a simple subset of Gradle even if it's multiproject build etc. The amount of churn in the JS build tool space e…

> The amount of churn in the JS build tool space easily outstrips any one time learning you need to do to surpass the Gradle knowledge cliff. Android Gradle Plugin: here, hold my beer. https://developer.android.com/studio/releases/gradle-plugin?... I find working with Gradle infuriating. It's layers upon layers of magic. When something breaks, you get a baroque error message, a usually useless stack trace, and a sugg…

This is what I was referring to the knowledge cliff.

Gradle is incomprehensible until it isn't. It has a very steep but short learning curve and understanding is completely binary. It's very unfortunate but it is how it is.

I still take it over the JS stuff but I do acknowledge it's shortcomings. I also don't do Android development so I don't know if it's particularly bad there.

Re: Some notes on using esbuild

#196

Post by pastage »

hsn915 wrote: post #30

> problem 1: libraries that tell you to npm install them Agreed. I wish `npm install` was just some option for those who wanted it. But no! Somehow it became the defacto standard and everyone just expects everyone else to already be onboard. I got onboard reluctently because that's the only way to use the libraries I cared about. > problem 2: I don’t understand frontend build tools Absolute and total agreement. I can…

Unix tools should do something well in CLI, and be transparent enough to deconstruct the command into series of commands if it is a complex process. Piping is not always practical (see make).

Your definition of a unix tool is a strange one.

Re: Some notes on using esbuild

#197

Post by franciscop »

ricardobeat wrote: post #53
franciscop wrote: post #18

I've recently being helping a friend who is starting with Node.js, and I strongly recommended him (and anyone else getting started now) to use all `import` instead of `require`. I would say it takes a bit more of work because the tutorials are normally written on commonJS (require), but otherwise it's just a different kind of work. Both of them have their peculiarities and issues, and CommonJS might also bite you big…

> CommonJS might also bite you big time In which ways? I’ve always found CommonJS to be extremely unsurprising. What will bite you is the tooling built to interoperate with ESM.

In the way that some libraries have been updated to be ESM-only, so if you follow a tutorial to-the-letter and then try to require() that library it'll fail with a cryptic error message (at least for new users).

Re: Some notes on using esbuild

#198

Post by franciscop »

merrywhether wrote: post #106
franciscop wrote: post #18

I've recently being helping a friend who is starting with Node.js, and I strongly recommended him (and anyone else getting started now) to use all `import` instead of `require`. I would say it takes a bit more of work because the tutorials are normally written on commonJS (require), but otherwise it's just a different kind of work. Both of them have their peculiarities and issues, and CommonJS might also bite you big…

FWIW, you can replace __dirname with information from import.meta (and 2 lines of JS). It’s not quite as automagic but can yield the exact same info. You’re also right that it might just be a code-smell in general though.

Yeah, I've had 2 layers of deception there. You think it might be those 2-3 lines from the popular StackOverflow answer, but after hunting a bug for a while I realized that it was url-encoding that space in the path name and saying "directory doesn't exist" when in the console it was obviously correct.

Drove me crazy until I realized in the full path there was, early in the path, a single "%20" and my JS senses told me it doesn't make sense for spaces to be url-encoded in paths.

Re: Some notes on using esbuild

#199

Post by gkfasdfasdf »

mat0 wrote: post #173
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…

Mmm, this article is all you need to understand the current state of modern js: https://peterxjang.com/blog/modern-javascript-explained-for-...

Good article for a beginner like myself, however since it was written in 2017 I wonder if it needs a follow up.

Re: Some notes on using esbuild

#200

Post by myfavoritedog »

egeozcan wrote: post #15

As a developer who is in this ecosystem so long that it makes me shrug when I think about it, I loved the humble writing style and loved the fact that she could teach me a thing or two. Being able to say "I don't know how this works" requires a lot of experience too, not just confidence. Especially in an interview, people saying "I don't know anything about what you asked", depending on the requirements, can end the…

If only more people in all walks of life these days started from a perspective of humility at what they don't know, then were really super careful to avoid giving the impression that they knew more than they did.

Sadly... social media, media, law, politics, and even science are all about overstating what should be said with lots of caveats about lack of knowledge.

Post reply on HN