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

181–190 of 205 posts

Re: Some notes on using esbuild

#181

Post by mst »

istjohn wrote: post #109

TIL strace[1] exists. What a handy tool! 1. https://jvns.ca/blog/2021/04/03/what-problems-do-people-solv...

"Introduction people to strace" is one of the most effective ways I've found to improve their debugging experience.

It's glorious.

In case it's handy, the two options I find myself telling people about most often are: '-f' to keep tracing across forks, and '-s' to increase the number of characters of strings that get shown when you're trying to debug complete reads/writes.

(filtering for specific syscalls and stuff is also really neat but most of the time I just throw a full strace into a file and chop it up with my usual unixy tools from there)

Re: Some notes on using esbuild

#182

Post by mst »

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.

Re: Some notes on using esbuild

#183

Post by mhink »

ComputerGuru wrote: post #126
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…

> just use Vite[1] already I’ve been told that about jspm, webpack, parcel, snowpack, babel w/ rollup, browserify, and God only knows how many others. Don’t you guys get tired of all this churn?

Not really.

The fact of the matter is, most of these projects came along for justifiable reasons, and represent some improvements over the existing tech: speed, ease of configuration, better dev experience, better use of platform features, and so on. I'll certainly grant that there's an aspect of chasing the new shiny here, but among the senior FE folks I know, the costs of migration are always being weighed against the actual benefits you get.

Additionally, the cost of adoption/migration is very often a high-priority concern by the people writing these libraries. The pendulum is swinging back from configuration to convention.

With regards to the pace: it mainly has to do with the fact that the Web-as-application-platform has only come into its own in the past 10-15 years or so (i.e. since the death of Flash.) The tooling is just now catching up. Another HUGE factor is the growing adoption of TypeScript- for the past several years, TypeScript tooling and existing JS build/bundle systems have gradually adapted to each other, which has driven change. (Trust me: trying to figure out how to set up TypeScript compilation under webpack was confusing and miserable for a long time.)

If you're just glancing into front-end OSS every once in awhile, or if you're not heavily using the features available in these tools, you might not notice or value these improvements. And that's perfectly OK- you can certainly continue to use whatever's comfortable for you. But there's more here than meets the eye.

Re: Some notes on using esbuild

#184

Post by mkl »

cxr wrote: post #114
mkl wrote: post #83

Earlier quoted context omitted.

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…

I mainly use big standalone ones that provide enough to be worth it, and far more than I'd build myself. Things like MathJax, JSXGraph, Plotly, and D3 when I properly learn it. Not coincidentally, those aren't too hard to use without NPM.

Re: Some notes on using esbuild

#185

Post by js2 »

jpgvm wrote: post #110
eitland wrote: post #92

Earlier quoted context omitted.

I've been poking fun at JS for a long time (friendly though, I'm consistently amazed at what those people manage to do with little more than straws and duct tape ;-) Just be glad Gradle hasn't entered the JS scene yet: With JS there is at least some standards now: both Angular and React at least has some systems for getting things running in a standard way and keeping it somewhat aligned. With Gradle however I haven'…

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 suggestion to re-run the possibly very long build with -info or -debug. At that point, instead of not having enough output, you're usually drowned in megabytes of irrelevant messages.

Not a fan of all the magic behavior at all.

Re: Some notes on using esbuild

#186

Post by modeless »

ehutch79 wrote: post #159
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)

I think you missed the point. Churn is a real problem. Even if the tools are improving, it does need to be balanced against stability. They admited autotools was insane. but it was a consistent well know insanity. Things are getting better. but js has definitely had more churn, and reinvented more wheels than anything else i know of.

I think you missed my point. Churn is obviously less desirable in the abstract, but the state of C++ build tools in particular is deplorable and the lack of churn doesn't come close to compensating for how terrible it is.

Re: Some notes on using esbuild

#187

Post by [deleted] »

hobofan wrote: post #65
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…

> It's holding JavaScript to its own higher standard: is dead simple, and trivial to understand and get working. The most simple example is almost never a representative example that can be used as a standard to hold the whole language to. In the same vein, one could say: "See how easy it is to build a C program with `gcc main.c`? Why should I have to figure out how to use make?". And the answer is simple: Most proje…

[deleted]

Re: Some notes on using esbuild

#188

Post by tomnipotent »

christophilus wrote: post #68
joshuacc wrote: post #59

Earlier quoted context omitted.

1. It’s much faster. 2. It won’t catch type errors. Regarding #2, I assume that things are set up so that type errors are caught in some other way, such as in CI or in a precommit hook.

What I do is run esbuild and tsc (with no emit) in parallel in watch mode. That way, I get fast rebuilds and iterations, but still eventually see the errors spit out. My code editor catches 90% of the errors, but it’s definitely nice to have tsc catch the rest earlier than the CI process.

> My code editor catches 90% of the errors

With or without strict mode enabled?

Re: Some notes on using esbuild

#189

Post by jrochkind1 »

bredren wrote: post #162
jrochkind1 wrote: post #116

Earlier quoted context omitted.

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

> 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 think this a big issue for non-js / frontend people, particularly in the python webdev community. People don't know the story of front end and the user demand for refined interface…

Hm, I didn't mean to be talking about an "anti-everything on frontend attitude"!

Re: Some notes on using esbuild

#190

Post by andrei_says_ »

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?

Post reply on HN