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

111–120 of 205 posts

Re: Some notes on using esbuild

#111

Post by ceronman »

What a fantastic post! I rarely do frontend web development. Perhaps only once every year or two. I don't follow frontend development much, and every single time I need to write some javascript the preferred tech stack of the day is completely different. There are so many tools, so many different ways of doing things. It's completely overwhelming.

So I end up doing the same thing the author was doing: just use tags. If I need a library I try to download a minified version of it and put it in a script tag. This is usually good enough for me as I typically use JS for very small things. “pretend it’s 2005”. It works and if something breaks I know how to solve it.

For the kind of JS projects that I work on, learning the tooling can easily take 3X the time I need to write the project itself. I know that there are several meta-tools that will automatically configure all other tools for you, but I really dislike them. They usually end up downloading half of the entire internet, and when you move an inch from their preferred defaults everything becomes a nightmare.

Esbuild seems like the perfect tool for people like me. It's simple, fast and it allows me to import things in JS! I'm definitely going to look at it next time I'm writing some frontend code.

Re: Some notes on using esbuild

#112

Post by have_faith »

cxr wrote: post #102

> there are 2 standards (CommonJS and ES6 modules), and that require is CommonJS and import is ES6 modules Kind of, but not really. There are JavaScript modules as defined by the ECMAScript standard and implemented in Web browsers and anyone else who cares about implementing the spec, and then there is NodeJS, which has its own way of doing things, along with people who refuse to give it up and insist on dragging tho…

Using ES mudules everywhere seems to be picking up steam recently. It is annoying jumping between frontend files and backend files in the same project using different module systems.

I think in about 6 months not touching common js modules from front-to-back for a whole project will be viable without major quirks.

Re: Some notes on using esbuild

#113

Post by jrochkind1 »

loevborg wrote: post #54
cuu508 wrote: post #19

Earlier quoted context omitted.

Addressed in TFA: > But I stopped using those tools and went back to my old system because I don’t understand what those vue-cli-service and vite are doing and I didn’t feel confident that I could fix them when they break. So I’d rather stick to a setup that I actually understand.

She's doing things the right way here - applying the beginner's mindset, trying to understand things rather than cargo-culting by copy-pasting magical incantations from github. There's just so much incidental complexity in JS tooling, and her instinct to steer clear of that insanity by using Unix tools like esbuild is spot on.

I am fairly good at avoiding cargo culting and only using things I understand. I am uncomfortable developing any other way.

With JS build tools, I eventually gave up and accepted being uncomfortable.

(And to be clear, we're talking "levels of abstraction" here. Or interface/implementation. I don't need/want to understand the implementation of the tools/libraries I use. I need/want to understand how they work at the "interface" level, the mental model for what they offer and how to make them do what I want, and what choices are available on what axes. I normally achieve this. With webpacker, I give up and just copy and paste magic phrases).

Re: Some notes on using esbuild

#114

Post by cxr »

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.

I'm very sympathetic to Julia's confusion and your yarn/npm frustration. But consider whether those libraries themselves might also be part of the complexity that are not worth the cost. Julia's trying to use Vue. Vue (and Webpack, and Babel, and the entirety of NPM) nominally exists because it's supposed to improve the developer experience. If instead it contributes negatively in other ways and you have to spend so much time wading through the tangled mess that it confronts you with, what's the point?

Ignoring the nullified value proposition, there are other reasons besides (like security) to reject what the NodeJS/NPM world considers standard practice.

Re: Some notes on using esbuild

#115

Post by merrywhether »

marcus_cemes wrote: post #28

I find it fascinating that there are people still using script tags. I have personally become so tied to npm and typescript that it feels that I'm programming in a completely different language and ecosystem, with a build process and IDE-like type checking and linting, a more procedural data-oriented C-like paradigm. I've never touched the old JS guts, `module.exports`,the prototype chain, ... Babel (and later TypeSc…

The big difference is Rust and Go are new and learned from their predecessors. If they live long enough, they too will become complicated (well maybe not Go since it’s central design paradigm is simplicity) and seem crusty compared to newer counterparts. Java started simple, but has grown and “forked” and now there’s Kotlin or Scala etc. All that variation was because Java was successful and people wanted to use it but in a slightly different way. JavaScript is the same: people keep evolving it _because_ it is so popular.

Re: Some notes on using esbuild

#116

Post by jrochkind1 »

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…

> It's not like the previous tooling was really any easier to deal with.

If you really understood the previous tooling, that probably explains why you have the mental models in place to understand what webpacker is doing with increasing automation. Say, if you were using babel without webpacker already.

For people who skipped that or came to JS in webpacker era (myself included), it's hard to understand what is going on. the universe of what webpacker does seems inconsistent and random and involves concepts underlying concepts underlying concepts where it seems like you need to understand the mysterious base to understand what the top-level tool is doing before forgetting it and letting the tool do it for you.

But webpacker isn't just insane, it is what it is for a reason, involving solving specific problems that were in existence in previous ways of doing things. If you had those problems personally... it's a lot easier to make sense of it.

I assume/sense. I don't know this from personal experience with webpacker... but it's a familiar sort of situation with software development technology.

Re: Some notes on using esbuild

#117

Post by smt88 »

cxr wrote: post #108
smt88 wrote: post #85

Earlier quoted context omitted.

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.

> Within the actual language, there isn't a universal syntax just to use a package. There is. The issue is one of mindset. You recognize Maven and Gradle as belonging to a sort of "parastandard" set of technology, offering proprietary (albeit free/open source) glimpses of how one could conceivably solve the set of problems that they're meant to be used for, but when it comes to JS, you're elevating the parastandard s…

I think you're misunderstanding what I'm saying. You're still talking about package managers and build systems. I'm talking only about syntax. TypeScript, NPM, esbuild, Gradle, and Maven are completely separate from what I'm talking about.

Re: Some notes on using esbuild

#118

Post by akitzmiller »

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 Makefiles; setup Tomcat webapps; and use Python for most of my daily work. I've even hacked around with Boost's build thing.

Complexity is not the issue with JavaScript. Stability is the problem.

Most devs do not want to "know" build systems. You want it to work most of the time and when it doesn't, you want to be able to find the answer to a problem. You want that knowledge to accumulate over time so that the answer you found the last time still works.

Autotools is an insane system, but it's been the same insane for 30 years.

Currently using vue-cli with Vue 2 and Vuetify, a configuration depending on a lot of precisely pinned versions to get functional. There is a pile of deprecated library warnings during the lengthy build process that I have no idea how long it will take me to address. Could be a couple of hours, could be several days, could be impossible.

Would like to try Vite or esbuild because God knows we could use the speed up, but after investing a couple of weeks to figure out the precise balance of versions that will work and propagating to our 8 or 9 applications, where are we going to be next year? I saw a Tweet yesterday about vite on swc. Is that going to be the winner?

I half wish Richard Stallman would take over. How desperate is that?

Re: Some notes on using esbuild

#119

Post by morelisp »

Bellend wrote: post #86
morelisp wrote: post #66

Earlier quoted context omitted.

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

Oh no, I agree it's absolutely too late for existing projects. Good sense needed to prevail at least 4-5 years ago, but who wanted to deal with being seen as "elitist" or "gatekeeping" for daring to suggest the entire ecosystem made no sense?

Re: Some notes on using esbuild

#120

Post by morelisp »

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?

Python's packaging infrastructure is a mess, but the even the _environment_ surrounding import, let alone the module semantics, largely hasn't changed since the introduction of venv.

For all the other failings of the Python 3 migration, the Python community strongly and rightly rejected 2to3 which would've eventually produced a babelesque mess if continued.

Post reply on HN