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

121–130 of 205 posts

Re: Some notes on using esbuild

#121

Post by jsmith45 »

Semaphor wrote: post #14
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…

> The fact you can't do "import vue from 'Vue';" with esbuild You misunderstood, they say this is exactly how it works. But they wanted a specific build instead of the default one of vue (the one with the runtime compiler, not default because it has performance penalties).

It could be argued the default was wrong (when originally chosen).

If you don't have the runtime compiler, then that means either you: 1. handwrote the the compiled templates, which is rather unlikely, or 2. you are using additional tooling to precompile.

If you are using additional tooling to precompile then that tooling ought to handle aliasing to the runtime only version, (or if not using a cli style tool, the instructions for setting up the bundler to use a loader should include setting up the alias).

However it is probably too late to fix things, since existing projects will assume the default is the compiler-less runtime, and would perform worse if things were changed, since existing projects would not have the new alias to run-time only version in place.

Re: Some notes on using esbuild

#122

Post by elevader »

throwaway894345 wrote: post #99
hobofan wrote: post #65

Earlier quoted context omitted.

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

C also lacks a sane build system, so if you’re trying to make the point that JS isn’t so bad, comparing it with C isn’t the way to go. Consider that no other language needs a bundler with all of the weird stuff it supports. You might argue that it’s good that JS supports all of these things and that’s fine, but what you’re really saying is complexity is good which is also fine but incompatible with the “JS is no more…

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 it does actually solve some problems.

Re: Some notes on using esbuild

#123

Post by toastercat »

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…

If you're already familiar with JavaScript, it takes about a day's worth of Node.js API knowledge to write your own build scripts with esbuild.

I think Julia had the right attitude. Instead of taking the leap of faith with a popular tool that you don't understand, instead, choose a smaller, focused tool that you can understand. As you build your application, you can more clearly and organically identify your painpoints, and then you re-evaluate if a more complex tool would be a better fit.

I think going the other way around (as you seem to suggest) is a common mistake made by many entering the JS dev world.

EDIT: For the record, I use Vite, esbuild, and rollup across several projects.

Re: Some notes on using esbuild

#124

Post by dangerbird2 »

ricardobeat wrote: post #24
hsn915 wrote: post #20

Earlier quoted context omitted.

I don't understand the point of vite. I tried using it and the "build" took over 30 seconds. esbuilds takes less than 1 second for the same project. > esbuild is not featureful enough for a lot of production use cases What makes you say that? I keep hearing people say this, but I haven't run into any problem that make esbuild not ready for production.

ESBuild doesn't transpile your code down to ES5. If you're using any ES6 features - default params, template literals, arrow functions, let/const, spread, etc, your cut-off for browser support will be ~2017 (= no support for IE 11). swc ( https://swc.rs ) does transpilation and it's as fast as esbuild. Setup is slightly more complex. I'm hoping esbuild will add ES5 transforms at some point, would much rather have a G…

I love swc, it's close to a drop-in replacement for babel, but with a native executable and doesn't download half of the internet in JavaScript dependencies. You can use your existing build system, but get substantial speedups over using babel.

[1] https://parceljs.org/

Re: Some notes on using esbuild

#125

Post by pitaj »

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…

> Gzipping removes the need for minification.

_need_ is a strong word. You don't _need_ gripping either. Both minifying and gzipping still provide substantial benefits.

> Any npm package can be loaded as script tags or through direct es6 module import from unpkg.com

This prevents tree-shaking and dead code elimination.

Re: Some notes on using esbuild

#126

Post by ComputerGuru »

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?

Re: Some notes on using esbuild

#127

Post by conradfr »

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…

At some point in my life I contemplated giving up on frontend because of Webpack.

I guess it's better since version 4, but when you need to change/update your build script, you brace yourself.

To be fair I use esbuild on a Phoenix project right now and some things are not really that much clear on how to do them.

Like yesterday I wanted to put eslint in the "watched" build process, and I'm still not sure how I would do that.

At least it's fast...

Re: Some notes on using esbuild

#128

Post by recursive »

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…

How are you getting native ES modules to import from file:? When I try that, I get a cross-origin error. No two file: urls seem to be the same origin.

Re: Some notes on using esbuild

#129

Post by ComputerGuru »

nicoburns wrote: post #26
ricardobeat wrote: post #24

Earlier quoted context omitted.

ESBuild doesn't transpile your code down to ES5. If you're using any ES6 features - default params, template literals, arrow functions, let/const, spread, etc, your cut-off for browser support will be ~2017 (= no support for IE 11). swc ( https://swc.rs ) does transpilation and it's as fast as esbuild. Setup is slightly more complex. I'm hoping esbuild will add ES5 transforms at some point, would much rather have a G…

Plain esbuild is perfect for adding typescript support to node.js projects. We literally just run ’esbuild && node dist/run.js’

What about web projects, though? Isn’t that what the discussion is about (script tags and all)? Node projects aren’t too bad because you don’t need anything beyond local fs module resolution.

Re: Some notes on using esbuild

#130

Post by ComputerGuru »

dmitriid wrote: post #40
lhnz wrote: post #27

Earlier quoted context omitted.

The sane option would be to use a codemod to rewrite your code to not need bespoke tooling configurations. You are locking yourself into legacy tooling.

> The sane option would be to use a codemod to rewrite your code to not need bespoke tooling configurations. 1. Absolute paths are not "bespoke tooling config", it's a tsconfig setting 2. Requiring some code to be served from a specific url is not "bespoke tooling config", it's a requirement for quite a few projects 3. Forcing someone to mindlessly and absolutely needlessly re-write thousands of import statements isn…

> Forcing someone to mindlessly and absolutely needlessly re-write thousands of import statements isn't really a solution

This is how progress is measured in the web world. The impact of your code/project/patch is measured by how many lines have to be rewritten to adopt it. The higher the number, the better your web wizardry rank is.

Post reply on HN