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

151–160 of 205 posts

Re: Some notes on using esbuild

#151

Post by smt88 »

cxr wrote: post #144
smt88 wrote: post #117

Earlier quoted context omitted.

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.

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 it, and many of them look similar and have confusing conflicts with compilers/packagers.

Re: Some notes on using esbuild

#152

Post by Joeri »

recursive wrote: post #128
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.

I mean that when hosted as a static site you can do es6 imports by importing from a url for a file.

Re: Some notes on using esbuild

#153

Post by slmjkdbtl »

My biggest feeling about learning JavaScript build tools and ecosystems is I learned nothing! I learned a bunch of ways to navigate through man-made unecessary complexities, and end up with no new knowledge in computing. The brightside is it increases my tolerence for bloatware, which is a valuable skill to have nowadays.

esbuild is one of the few good tools, it has a ton of features and it's still fast and lean.

Re: Some notes on using esbuild

#154

Post by difosfor »

Sounds like she should consider just importing her script.js as a module and then import the rest from there. Probably no need for a build step and bundling at all. Also she might want to just use custom elements instead of Vue as your browser also just supports those out of the box.

Re: Some notes on using esbuild

#155

Post by Steltek »

modeless wrote: post #139
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)

I must be crazy because I still prefer regular Make to CMake. It seems like CMake tried to fix autotools problems (which were not Make's problems) but then created new problems of it's own. Why is setting an install prefix so complicated when it's the ONE option that almost everyone wants? Why the case sensitive name ending in .txt?

And CMake still seems extremely C/C++ focused. I don't want a language-specific build tool anymore. Heck, I'm not even sure I necessarily need a build tool so much as a generic task runner with patterns and complex/dynamic dependencies.

Re: Some notes on using esbuild

#156

Post by Joeri »

pitaj wrote: post #125
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.

Well, the libraries included at runtime from cdn are still minified. It’s only the app code that is gzipped and not minified, and it is only the very largest projects where minification will make a meaningful difference for the app’s own (not library) code. There is usually no point to minifying the app’s own code.

As for tree shaking. When using lightweight libraries meant for the no build path this isn’t necessary because these aren’t pulling in lots of dependencies. Preact is tiny and is a good enough react for my needs.

I wouldn’t recommend this approach for large web apps, but most web apps are small enough that a no build tools approach seems viable to me.

Re: Some notes on using esbuild

#157

Post by klodolph »

modeless wrote: post #139
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)

Not the parent commenter. I spent time using autotools long ago and developed a grudging respect for what they did and how they worked. Their design made sense, even though the system itself was quite cursed. CMake also—I never choose it for my own projects, and I hate using it, but I respect the consistency and portability.

Building JavaScript is just a fucking disaster. I’ve used a fair number of different bundling tools—Browserify, Webpack, Rollup, Esbuild, and Closure (the compiler). I’ve also used old-school concatenation… anything from tags to something like “cat”. It’s just fucking awful. Stay on the straight, narrow path and you’ll survive. Deviate slightly and you’re doomed.

Making things worse, you might have two different environments you run your code in. Node.js and the browser. Surprisingly, the browser lurches ever fowards, and Node.js is the anchor keeping us in the past. Making things worse, you might try to use TypeScript. Making things worse, you might use JSX.

Nearly every JS project I work on needs a ton of babysitting w.r.t. the build system. At various places I’ve worked, there might be a team handling that for me, but if I’m working on a side project, it is very difficult to keep the complexity of the build system down to a reasonable level. Most guides on how to use frameworks will tell you to do something like “oh, just use create-react app” or similar, and you end up with a couple dozen new dependencies. Your build system will be a mix of templated code pasted in to your repo and third-party libraries. Integrating with anything else often requires various "adapter" dependencies, but it's a roll of the dice whether those libraries are built reasonably.

My basic desire is often a fairly simple list… I want front-end TypeScript code to be type-checked and bundled, I want a dev server that serves the bundle, I want to see build errors quickly and easily, I want to run tests without a browser environment. I know this is possible, but every time I’ve gotten it, it’s taken an unreasonable amount of effort.

Re: Some notes on using esbuild

#158

Post by andrei_says_ »

smt88 wrote: post #52
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…

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.

After struggling to comprehend JS import and modules as much as I did as a single dev, I concluded that it’s my fault - that there’s something wrong with me.

I had to read the MDN guides multiple times and still need to refer to them.

Setting the build system part for my new projects is still the most challenging task.

Why do I have to learn how to build a grand piano every time I want to play a simple melody?

require ‘thing’ in Ruby requires the thing and that’s it.

require in JS should be use i. Node but not in the browser if I remember? Or maybe not? I don’t know, I guess I’ll just try things y til it works.

Re: Some notes on using esbuild

#159

Post by ehutch79 »

modeless wrote: post #139
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)

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.

Re: Some notes on using esbuild

#160

Post by klodolph »

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…

Yes, imports in JS are very frustrating. A big part of it is that your imports might be interpreted in, say, four different environments, and you have to consider how those four different environments work, how they can be configured, and pick some way of importing your packages that works in all four.

The four environments I often end up with are: Browser, Node.js, Rollup.js, and TypeScript.

For example, for a long time now, it has been sensible to just use "import" statements in code you intend to run in the browser. For a debug build, you don’t have to bundle, since browsers support import, but the imports have to be relative and have the full pathname. Node.js has a configuration option that allows you to use "import", but it is finicky and it can be surprising how many things will break when you turn it on—the alternative is to use ".mjs" as an extension. TypeScript has specific requirements about file extensions as well, and does not modify them. Finally, Rollup.js is hopelessly configurable.

Consider a simple requirement, “This code runs in the browser, I want to write a test using Jest.” I know it can be done, but I’m spending a bunch of time digging through forum posts to make it work, and understand how to make Jest load the code that already runs in the Browser, because the Node.js environment is so different… and most of the time, I end up writing code just to get something to build.

So the more than 3 ways, off the top of my head:

- Import paths: non-relative? relative? relative with leading slash?

- Import paths: .js suffix? no .js suffix?

- Files: use .mjs / .js suffix? use .js / .cjs suffix?

Post reply on HN