Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You don't need a build step

deno.com

Post reply on HN
Print view View original

161–170 of 224 posts

Re: You don't need a build step

#161

Post by winrid »

KyleJune wrote: post #96
franciscop wrote: post #6

So basically Deno has its own bundler that lets you not have a local build step and it gets bundled dynamically per-route as requested by users, right? This is very different from industry standards and possibly has many new concerns from devs, none of which are addressed in the article since it's treating the system as a perfect solution, which makes sense since it's a marketing page ("content marketing"). If it was…

They are not using their own bundler. They are using esbuild at runtime to generate bundles for individual islands when the process starts up. Then they store those files in memory in a Map. When the bundle files are requested, it just pulls the copy that was generated at runtime. Here is a link to the source where esbuild is used. https://github.com/denoland/fresh/blob/main/src/server/bundl... I personally think it…

It's like you combined the warmup phase of the JVM with the compilation phase, except you still have to wait for the JIT, too. I better not hear anyone complain about JVM warmup times again. :p

Re: You don't need a build step

#162

Post by ashishb »

Vaguely2178 wrote: post #157
ashishb wrote: post #138

In other languages, devs build better tools for solving existing problems faster or easier. In no other language, build tools are so broken that the best tool changes every few years. In the JavaScript world, a significant chunk of energy is directed inwards, solving problems created by using JavaScript!

Very few languages operate under the same constraints as js. When you ship js you can't guarantee the version of Ecmascript that the client will be running, or the standard library of DOM functions that will be available (which differ slightly from browser to browser), so you end up transpiling your code to the least common denominator. You also have completely different performance requirements compared to most othe…

> The closest comparison outside of the browser would be to the container ecosystem

And as someone who has worked on both, I can tell you that the container ecosystem is way better and way more deterministic. `Dockerfile` from 10 years back would work today as well. Any non-trivial package.json written even a few years ago would have half the packages deprecated in non-backward compatible way!

There is another similar ecosystem of mobile apps. That's also way superior in terms of the developer experience.

> Other languages don't need to dynamically load code via http requests, they generally run under the assumption that all of the code is available before execution.

And that's not what I am objecting to. My concern is that the core JS specification is so barebones that it fragments right from the start.

1. There isn't a standard project format 2. There isn't a single framework that's backward compatible for 5+ years. 3. There isn't even an agreeement on the right build tools (npm vs yarn vs pnpm...) 4. There isn't an agreement on how to do multi-threaded async work

You make different choices and soon every single JS project looks drastically different from every other project.

Compare this to Java (older than JS!) or Go (newer than JS but highly opinionated). People writing code in Java or Go, don't expect there builds to fail ~1-5% of the times. Nor are the frameworks changed in a backward-compatible way every few years.

Re: You don't need a build step

#163

Post by sitkack »

onion2k wrote: post #80
irrational wrote: post #48

I hate hate hate that modern web development requires a build system. No build system would probably get me to convert to Deno.

I hate hate hate that modern web development requires a build system. No build system would probably get me to convert to Deno. I feel the same about C and C++. And Java. And Fortran, Pascal, Lisp, Kotlin, Swift, Rust, Forth...

Not being snarky, but Lisp and Forth should have interactive experiences that the other languages do not have. The Pascal related languages are renowned for being designed to be compiled at high speed.

This is a wonderful book, "The School of Niklaus Wirth: The Art of Simplicity"

https://tkurtbond.github.io/posts/2022/07/04/the-school-of-n...

Esp this chapter on the Wirthian way of designing compilers https://www.researchgate.net/publication/221350529_Compiler_...

See also the widely read (on hn), https://prog21.dadgum.com/47.html

Re: You don't need a build step

#164

Post by jahewson »

ashishb wrote: post #138

In other languages, devs build better tools for solving existing problems faster or easier. In no other language, build tools are so broken that the best tool changes every few years. In the JavaScript world, a significant chunk of energy is directed inwards, solving problems created by using JavaScript!

I don’t know, C++ has Make, CMake, Buck, Pants, Ninja, GYP, Bazel.

Re: You don't need a build step

#165

Post by jeroenhd »

ashishb wrote: post #138

In other languages, devs build better tools for solving existing problems faster or easier. In no other language, build tools are so broken that the best tool changes every few years. In the JavaScript world, a significant chunk of energy is directed inwards, solving problems created by using JavaScript!

I don't know, I've seen plenty of build tool bulk in native code. Configure scripts, automake, make, cmake, meson, and plenty of others that are even more obscure. Most of them integrate with some kind of project specific shell script (that claims to be sh compatible as long as sh means bash) to make thing easier.

The languages where the build tools remain static are often also the languages where innovation lags behind or where no real alternative exists. C and C++ projects often use standards that go back literal decades for compatibility reasons, and rely on apt/dnf/pacman to install their dependencies. Java is stuck on nine year old tech in most production systems because what if upgrading to Java 9 will break AncientProprietaryHackedTogetherLibrary. Python seems to be moving away from the pip vs conda wars, though the ML space seems to be reintroducing conda into newer projects; to run popular software, I've had to install at least two conda packages and pip (and then disable the auto load in my bash shell because all of them made the shell prompt take literal seconds to come up).

Go/Rust/.NET and other more recent languages have a single package manager+compiler+build tool+publishing system combination that's changing so rapidly no alternative could be written. I guess you can manually script calls to the compiler, linker, and download scripts, but I doubt this will be maintainable. I wonder how long it'll take for GCC Rust and official Rust will run into trouble in this space.

The Javascript ecosystem certainly seems to be the wildest when it comes to reinventing the wheel (and inventing new steps) to make new build systems, but every language either has too much of that or too little.

Re: You don't need a build step

#166

Post by hobofan »

ashishb wrote: post #162
Vaguely2178 wrote: post #157

Earlier quoted context omitted.

Very few languages operate under the same constraints as js. When you ship js you can't guarantee the version of Ecmascript that the client will be running, or the standard library of DOM functions that will be available (which differ slightly from browser to browser), so you end up transpiling your code to the least common denominator. You also have completely different performance requirements compared to most othe…

> The closest comparison outside of the browser would be to the container ecosystem And as someone who has worked on both, I can tell you that the container ecosystem is way better and way more deterministic. `Dockerfile` from 10 years back would work today as well. Any non-trivial package.json written even a few years ago would have half the packages deprecated in non-backward compatible way! There is another simila…

> `Dockerfile` from 10 years back would work today as well.

I highly doubt that any Dockerfile from back then would work if it runs `apt-get` (as many do), as the mirrors for the old distribution versions aren't online anymore.

Dockerfiles can be made to be quite deterministic, but many use `FROM` with unpinned tags and install from URLs that can and do go away.

Re: You don't need a build step

#167

Post by marginalia_nu »

ashishb wrote: post #138

In other languages, devs build better tools for solving existing problems faster or easier. In no other language, build tools are so broken that the best tool changes every few years. In the JavaScript world, a significant chunk of energy is directed inwards, solving problems created by using JavaScript!

Every language I've worked with that has had build tools (like beyond 'make'), those build tools have been janky as all hell, and it's taken me at least a day of googling to get them to do the most basic thing. In some cases the build tool itself keeps changing how it works so you need to waste another day figuring out how to do basic things. It's to the point where I'm not entirely certain it's even possible to do well.

Re: You don't need a build step

#168

Post by explaininjs »

brundolf wrote: post #159
explaininjs wrote: post #141

Earlier quoted context omitted.

In the example on that blog post, you want lodash's "startCase" function. In typical bundling with tree shaking, the developer would download all of lodash and the bundler would identify that only the "startCase" function (and it's deps) are referenced, it would smoosh them all together into one file along with the rest of your code, you put that file on a CDN, and you're done. The client can access everything they n…

Right okay, so, let's get our terminology straight real quick: an "import map" is just a piece of configuration that says, "when someone imports from module name X, load it from Y". This would for example let you `import { ... } from 'lodash'` and have it load from ` https://unpkg.com/lodash-es@4.17.21 `, or whatever else. That's all it does. Everything you're describing above is just about regular "ES module" behavi…

True, I was conflating the idea of having a map of where to find files with the idea of not putting all source in a single file. Though I do still posit that you don't need one if you have the other.

It's a bit like the ancient static vs dynamic linking debate, except in the web case you can't reuse modules that were downloaded by a separate origin, which kinda throws out a lot of the case for dynamic linking. The idea of caching the library files separate from the app files is still potentially valid on a per-origin basis, I suppose.

> HTTP/2 is optimized to make lots of parallel requests over a single TCP connection, which could conceivably mean a slightly larger total amount of code might load faster as separate modules than a single large bundle would

I'd be curious to see this put to the test. It'd require the OS to be able to stream multiple files from memory to the network adapter in parallel at higher bitrate than it could do just one, which is something I'm not sure is possible. Could be, I just don't know. That said, one area it could shine is in letting the browser parse the JS of one request while still downloading the others from the network.

I agree I'd like to see front end bundling treated as more of a first class citizen in the JS backend runtimes. I'm in the Bun camp lately and it is also lacking in that regard. Though as I mentioned, esbuild is great (and Bun interfaces with it faster than Node can!)

Re: You don't need a build step

#169

Post by frankfrank13 »

jstummbillig wrote: post #110

I am perplexed by the focus on this. Clearly there are excellent devs working on Deno — but what setups are you running that the actual build is holding your productivity back? Developing in node/ts or rails I don't think it would move the needle in the slightest for me. It's simply not an issue outside of my brain finding beauty in any kind of optimization. Is that all this is?

Idk, its another way of doing something that for some people could be very important. I've had Next apps take 5 minutes to start, with 1 minute single-page build times in local dev. So yeah, pretty easy to calc the payoff of speeding that up.

Re: You don't need a build step

#170

Post by pianoben »

falseassertions wrote: post #107
KyleJune wrote: post #96

Earlier quoted context omitted.

They are not using their own bundler. They are using esbuild at runtime to generate bundles for individual islands when the process starts up. Then they store those files in memory in a Map. When the bundle files are requested, it just pulls the copy that was generated at runtime. Here is a link to the source where esbuild is used. https://github.com/denoland/fresh/blob/main/src/server/bundl... I personally think it…

Man the things that pass for innovation in the node-adjacent space continues to blow my mind. It feels like hte horrors of /r/programmerhumor meets generic internet hype-beast cycles.

Conceptually, I don't see how this is much different from JIT compilers in the JVM, CLR, and similar runtimes. You don't hear so much from Java devs about how they can't* see the machine code their customers are running. They talk about cold-start performance, but accept that the first few requests will be slower in exchange for the productivity and eventually-high-performance.

Now that I think about it, this is how V8 works too, for JS code itself!

Why wouldn't this principle apply to bundling?

Post reply on HN