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

131–140 of 205 posts

Re: Some notes on using esbuild

#131

Post by jsmith45 »

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…

To my knowledge what node implements is nearly a superset of CommonJS. It is true that a pure CommonJS implementation cannot handle many node packages due to additional features that node has added to the module descriptor, or due to use of node specific built-in packages/globals/extra properties on require, etc.

But I was under the impression that node could generally import and handle strictly conformant CommonJS packages just fine in practice.

Of course, I won't argue that many npm packages not being conformant CommonJS packages makes things difficult for non-node server-side javascript environments, since they either need to add additional node compatibility, or might need their own package repository.

Re: Some notes on using esbuild

#132

Post by cube2222 »

3np wrote: post #50
betageek wrote: post #45

Earlier quoted context omitted.

I don't understand why people are holding JS to a higher standard than other languages, is it just because it used to be easier? Knowing nothing about Java, I wouldn't expect to open a Java file and know what every line means. There's a million reasons to find modern web dev complicated but not taking the time to google "js import" is not one of them. Also I wouldn't expect to "just know" how to take a Java program a…

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 name in the go.mod file, then you don't have to modify any imports.

Re: Some notes on using esbuild

#133

Post by ComputerGuru »

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…

I wrote a generic loader that’s compatible with old school scripts, amd, node, and es imports that does just that. It’s zero config and would be fully automated except given a local npm/yarn env, I just need some way of going from “fookpg” in “import foo from foopkg” to node_modules/foopkg/entrypoint.JS

How can you resolve a module name to its path without external dependencies?

Re: Some notes on using esbuild

#134

Post by toastercat »

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?

Yes. I've used them all. I think Julia's approach is the best: code like it's 2005 until you feel like you hit roadblocks, then pick the simplest and most focused tool for the job (which at this point, I think esbuild is the best pick for its scope and speed).

I'm dealing with a complex webpack/babel setup at work. It is rife with issues, and it amazes me that these are issues that we created ourselves. Endless dev time is wasted on debugging overly complex toolchains.

Re: Some notes on using esbuild

#135

Post by [deleted] »

smt88 wrote: post #117
cxr wrote: post #108

Earlier quoted context omitted.

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

[deleted]

Re: Some notes on using esbuild

#136

Post by rglover »

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…

esbuild is the gold standard. Its creator has done a phenomenal job (and it's still early in its lifecycle). It's the first time I used a JS build tool and didn't scream at the monitor when dealing with nonsensical APIs and error output.

Re-implemented a complex setup using it in an afternoon with very few hiccups: https://github.com/cheatcode/joystick/blob/master/cli/src/fu....

Re: Some notes on using esbuild

#137

Post by maxfurman »

rglover wrote: post #136
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…

esbuild is the gold standard. Its creator has done a phenomenal job (and it's still early in its lifecycle). It's the first time I used a JS build tool and didn't scream at the monitor when dealing with nonsensical APIs and error output. Re-implemented a complex setup using it in an afternoon with very few hiccups: https://github.com/cheatcode/joystick/blob/master/cli/src/fu... .

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.

Re: Some notes on using esbuild

#138

Post by elevader »

mkl wrote: post #37
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…

IE (all versions) seems to have 1-2% market share, so I'm not sure it's worth jumping through hoops for.

Sadly it's a lot more than old IE versions, there are a lot of mobile devices with surprisingly old/buggy browsers around. Of course this is highly dependent on the target audience but at my last job we did some runtime feature detection (basic stuff like arrow functions, let/const...) and shipped a modern build or a legacy build. And something like 10% of users got the legacy build, most of them on mobile browsers.

Re: Some notes on using esbuild

#139

Post by modeless »

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

Re: Some notes on using esbuild

#140

Post by rglover »

maxfurman wrote: post #137
rglover wrote: post #136

Earlier quoted context omitted.

esbuild is the gold standard. Its creator has done a phenomenal job (and it's still early in its lifecycle). It's the first time I used a JS build tool and didn't scream at the monitor when dealing with nonsensical APIs and error output. Re-implemented a complex setup using it in an afternoon with very few hiccups: https://github.com/cheatcode/joystick/blob/master/cli/src/fu... .

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 screaming "wEbPaCk iS dEaD!!!lol" it's clear the author is thoughtful (observable via the project itself, the docs, and how he interacts with people in Github comments).

Restored my faith quite a bit.

Post reply on HN