Some notes on using esbuild • Hacker News Board

Re: Some notes on using esbuild

#171

Post by 3np » Tue, Nov 16, 2021, 6:44 PM UTC

cube2222 wrote: post #132

3np wrote: post #50

Earlier quoted context omitted.

I think it's more that depending on your point in time, build process and environment, `import` has changed meaning every couple of years. I consider myself having deeper knowledge about JS and node than any other language, having spent more total time in it than anything else (except maybe bash). I have a clearer understanding of what import/require really does in most other languages. The flow-chart complexity and…

> (I do find go's repository-based approach quite frustrating to work with when forking dependencies but at least it's straight-forward) If I understand your point correctly, then that's a non-issue since modules are here. In the go.mod file you have the current module name, and all imports of yourself will use the current repository, instead of calling the original. So you fork the repository, but keep the original…

Straight-forward these days indeed.

https://golang.org/doc/modules/managing-dependencies#unpubli...

I still find the whole gopath/gomodules thing unfortunate but it is what it is at this point (and frankly that’s a bit out scope since we’re talking imports here.. if we’re talking about the state of packaging then JS absolutely has competition; e.g. https://xkcd.com/1987/)

Re: Some notes on using esbuild

#172

Post by elevader » Tue, Nov 16, 2021, 6:51 PM UTC

morelisp wrote: post #150

elevader wrote: post #145

Earlier quoted context omitted.

> There is no problem JS transpilers+bundlers tackled that earlier compiler writers had not tackled, better, before. I'm not sure what I am supposed to do with that statement/answer? It's obviously very easy to just assume that every js developer must be an idiot but that is hardly a fruitful discussion to have. > What does "plaintext source code" or "over the wire" do to distinguish this from "compiling a binary tar…

> I can ship it and the binary will work In this scenario, the binary is your ES3 or ES5 or what have you. Compiling Go to an x86 ABI, Rust to the same x86 ABI, C to the same x86 ABI, etc. is an analogous problem to "shipping dozens of plaintext source code files over the wire that then might get executed in an environment you have no control over". It's harder , by order of magnitude and on every axis, than compilin…

I'm not trying to argue that it is harder, just different in some ways and ignoring that for the sake of "javascript bad" isn' going to change the point that there are challenges involved. Nevertheless I understand your pint a lot better now, thanks for the explanation. I think we are both on the same page that the JS ecosystem overall is not in a good shape. But, you know, maybe THIS wave of new shiny tools is finally solving the issues once and for all (not holding my breath though...)

Re: Some notes on using esbuild

#173

Post by mat0 » Tue, Nov 16, 2021, 6:52 PM UTC

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

Re: Some notes on using esbuild

#174

Post by throw_m239339 » Tue, Nov 16, 2021, 6:59 PM UTC

Joeri wrote: post #70

I’ve gotten so tired of the near infinite complexity of the angular / react / webpack / typescript / sass projects at work that for my home projects I’m now exploring no build tool solutions. Modern browsers are now so powerful that a lot of the things we needed build tools for no longer apply: - http/2 multiplexing has made it unnecessary to limit the number of script or css files loaded at once. Faster connections…

> - vue and preact are designed to be used without build tools. An app deployed as a static site can use hash routing to need no builds and no server-side router.

So is React. JSX and React are 2 different things. But honestly, React without JSX is a pain to write.

Minification and hashing for secure script embedding are still needed, but it could provided directly by a server middleware, depending on the language one uses.

IMHO Typescript is still something useful.

Re: Some notes on using esbuild

#175

Post by mst » Tue, Nov 16, 2021, 6:59 PM UTC

mkl wrote: post #83

madeofpalk wrote: post #75

Earlier quoted context omitted.

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.

So far as I can tell, unpkg sources directly from npm so you don't so much dig around as 'construct the URL you want'.

I may simply have got lucky so far with that but it's worked really nicely for me for quick things where I don't care about bundling.

Re: Some notes on using esbuild

#176

Post by mst » Tue, Nov 16, 2021, 7:03 PM UTC

mynegation wrote: post #146

modeless wrote: post #139

Earlier quoted context omitted.

You really prefer autotools or CMake to esbuild just because they are older and don't change as much? I will take esbuild over CMake every day of the week and twice on Sunday. C++ build tools are an abject disaster. (And CMake does change anyway)

Not your parent commenter. I worked both with CMake/autotools and Java build tools (not esbuild specifically) and the point (which I agree with) is - yes - C/C++ build tools are complicated, but once you set it up it just runs most of the time without any problem. With things like webpack you are always one upgrade away from things breaking down in spectacular fashion, and the troubleshooting involves hunting github…

Somebody once described configuring fvwm2 (which is still my WM of choice, and indeed was theirs at the time of writing) as "like training a brain damaged hyena."

The thing is, as the same somebody noted, that then it stays trained.

To quote from upthread, "the same insane for 30 years" is in and of itself a huge feature that makes up for quite a lot of insane.

Re: Some notes on using esbuild

#177

Post by morelisp » Tue, Nov 16, 2021, 7:08 PM UTC

colejohnson66 wrote: post #142

akitzmiller wrote: post #118

I know it's just piling on at this point, but I've been doing a lot of software builds and deployment over the last 20 years, mostly in a scientific computing context. Nothing I've dealt with is as bad as JavaScript. I've generated and hacked dozens of autotools builds and written m4 macros of my own; I've hacked CMake builds; written RPM spec files; fixed Rcpp package installs; written and modified innumerable Makef…

You'd really take autotools and M4 over some other build system? This honestly reads like a "get off my lawn. The old days were better" post.

One advantage of autotools is that at least a lot of the skills are transferable. Shell scripts and Makefiles (and OK, M4 isn't so popular these days, but it was for a reasonably long time) are things I can learn and use everywhere, not just this project, not just C projects, not even just development.

I don't learn any transferable skills writing Webpack or Babel config. They don't even necessarily transfer to the next generation of the same tool.

I would also take a stable autotools over an unstable autotools, and I consider most of JS-land roughly equal in usability to unstable autotools. Autotools was also not that bad on the happy path where you were targeting, say, the top five POSIX systems over ten years - and maybe you didn't even need it at all, if you didn't need the performance from distinguishing each platform's best supported fd polling variant. Vs. JS, which is still bad even if you're only targeting evergreen browsers, because maybe you're stuck trying to integrate CSS modules with TypeScript or something. That kind of problem simply doesn't exist in autotools world.

Re: Some notes on using esbuild

#178

Post by cxr » Tue, Nov 16, 2021, 7:09 PM UTC

smt88 wrote: post #151

cxr wrote: post #144

Earlier quoted context omitted.

I'm not misunderstanding. (The difference between parastandard tech like package managers vs base-level stuff in e.g. the language itself was actually the point of my message, so I understand the distinction.) You're saying that unlike Java, JS at the language level doesn't have imports, but what you're saying is untrue. It's entirely possible that the projects you're most familiar with aren't using them, but the Jav…

Yes, I know JavaScript has native modules at the language level, but they are not universally supported. Most importantly, there can't/won't be a breaking change for the previous iterations of module import, so we will continue to have many different ways to import. It's not an issue of whether JS has a "blessed" way of doing it (and it didn't even have that for a long time). It's that there's more than 3 ways to do…

You wrote, "I was talking about import in JavaScript itself, not build tools or package managers," and keep mentioning things like "the import syntax of the language", so this feels like retconning.

The confounding details you bring up are entirely the result of that idiosyncratic tooling. JS itself has `import`, thus there is no problem of the sort that you describe—at least not as you've described it. (I.e., this isn't to say that there are no problems, only that the way that your characterization of the problem as being one with "JS itself" doesn't match the problem that actually exists.)

To say it again, if you see a problem with JS, that's because you're elevating the parastandard stuff to a higher level than it deserves. If you're able to meaningfully separate "Java" from "Maven and Gradle" in your mind, then you should be able to do the same with "JS" and the NodeJS derpitude.

Re: Some notes on using esbuild

#179

Post by mst » Tue, Nov 16, 2021, 7:10 PM UTC

rglover wrote: post #140

maxfurman wrote: post #137

Earlier quoted context omitted.

The "early in its lifecycle" part is the source of GP's worry. esbuild _seems_ great now, but based on the history of JS tooling, who knows what will happen in a year or two. Look at the recent example of the JS community's multi-year embrace and then rejection of Webpack. I would be nervous about migrating too.

I share a similar fear (generally speaking), but in this particular case I think the risk is worth it because the cost of setup is next to zero and the speed of the thing is unreal. If something catastrophic happens with the project years down the road, at most I'll have spent a few hours getting it wired up (worth it considering the positive impact it's had on my productivity). It's not the usual JS personality scre…

Plus if the author is keeping to go versioning standards they'll probably also keep to go compatibility aesthetics which bodes well for the future.

It's still a risk, but in this case one I suspect I'll also take next time I need to add a build step to a JS project.

Re: Some notes on using esbuild

#180

Post by morelisp » Tue, Nov 16, 2021, 7:15 PM UTC

throwaway894345 wrote: post #167

morelisp wrote: post #150

Earlier quoted context omitted.

> I can ship it and the binary will work In this scenario, the binary is your ES3 or ES5 or what have you. Compiling Go to an x86 ABI, Rust to the same x86 ABI, C to the same x86 ABI, etc. is an analogous problem to "shipping dozens of plaintext source code files over the wire that then might get executed in an environment you have no control over". It's harder , by order of magnitude and on every axis, than compilin…

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.