You don't need a build step • Hacker News Board

Re: You don't need a build step

#151

Post by tracker1 » Thu, Mar 02, 2023, 8:08 PM UTC

hobofan wrote: post #118

LunaSea wrote: post #101

Earlier quoted context omitted.

> What's so bad about package management? Hard coding URLs is significantly worse than having a package.json file: - you don't need to write the full URL to import a module - you have a quick overview of which modules are installed and for which reason (dev dependencies) - you can easily create an immutable list of dependencies > And what's useless about the security harness Because most apps will have to enable all…

- URL-based dependencies also have some additional security issues in the most common usage scenarios (see my recent flagged post: https://news.ycombinator.com/item?id=34937327 ). - You also lose all ecosystem upgradability, as everyone is using pinned versions instead of SemVer ranges

How many things have been broken by doing that in practice though?

I mean seriously... in node/npm, I've seen way too many times where a minor version broke things in practice... so we go to patch level by default, usually safer... In the end, we still wind up needing tools, like with github to alert to issues that require larger bumps.. Oh, your application hasn't been updated in a year, and you now have two major versions of LibraryX to run through... Next thing you know, you've spent literally three weeks to update your node/npm/react project... and even then, some packages were too painful to update, so you just deal with the warnings anyway.

And, now you've concentrated targets to the latest minor/patch versions in packages... where if everyone is pinned, the targets are mostly unknowned from outside without deeper inspection.

Just saying, I'm not sure auto semver with lockfiles is really a win over just locking to begin with.

Re: You don't need a build step

#152

Post by [deleted] » Thu, Mar 02, 2023, 8:11 PM UTC

evmar wrote: post #116

I worked on JS infra for Google. One thing we found in this space is that when your apps get very large in terms of number of source files, there is a developer-impacting load time cost to the unbundled approach. That is, your browser loads the entry point file, then parses it for imports and loads the files referenced from there, then parses those for imports and so on. This process is not free. In particular, even…

[deleted]

Re: You don't need a build step

#153

Post by tracker1 » Thu, Mar 02, 2023, 8:12 PM UTC

geysersam wrote: post #119

andrewmcwatters wrote: post #109

The dumbest thing about people building JavaScript to me is that you burn all of the energy and labor of building with almost none of the meaningful benefits. No one is building and ending up with bundles that are reducing the bloat of the web, you can’t tree-shake your way out of bad practices. Articles and real lived experiences show us that the web is still bloated. And why are we transpiling anything? If people w…

> Which is it? Do you want to be a scripting language or a programming language that compiles to something? It’s so gross to me. This is ridiculous. Just aesthetics. JS compiles to machine code when you run it "just in time". It's even relatively efficient considering it doesn't need static typing. The "build step" is just for reducing the size of the payload. It is possible a binary representation would make it even…

A bit older, but both worth a read, and most of this is still relevant today...

https://www.amazon.com/High-Performance-Web-Sites-Essential/...

https://www.amazon.com/Even-Faster-Web-Sites-Performance/dp/...

Re: You don't need a build step

#154

Post by hobofan » Thu, Mar 02, 2023, 8:20 PM UTC

tracker1 wrote: post #151

hobofan wrote: post #118

Earlier quoted context omitted.

- URL-based dependencies also have some additional security issues in the most common usage scenarios (see my recent flagged post: https://news.ycombinator.com/item?id=34937327 ). - You also lose all ecosystem upgradability, as everyone is using pinned versions instead of SemVer ranges

How many things have been broken by doing that in practice though? I mean seriously... in node/npm, I've seen way too many times where a minor version broke things in practice... so we go to patch level by default, usually safer... In the end, we still wind up needing tools, like with github to alert to issues that require larger bumps.. Oh, your application hasn't been updated in a year, and you now have two major v…

> Just saying, I'm not sure auto semver with lockfiles is really a win over just locking to begin with.

It's still a win even if you consider only patch version updates. Without that, for a CVE in a dependency, every dependent package will have to update, and will first have to wait for the lower level to update and publish a new version. So for a dependency ~4 layers deep, with coordination and publishing lag in between, this can quickly take more than a week (and this is assuming responsive maintainers).

Re: You don't need a build step

#155

Post by noahtallen » Thu, Mar 02, 2023, 8:22 PM UTC

rakoo wrote: post #69

sixstringtheory wrote: post #57

Earlier quoted context omitted.

> I hate hate hate that modern web development requires a build system Why? For any sufficiently complex software system, a build system serves as a reducer whose input is something that is more convenient for developers, ie huge codebase with tons of utilities and annotations, and whose output is something more optimized to run on the end users' devices. It's good to do such optimization because there will be, at le…

Because the need for a tool that bridges the impedance mismatch only hides the impedance mismatch even more, it allows developers to be even more remote from end users than before. It doesn't even start to question why we have an impedance mismatch in the first place. It keeps engineers in their position of those-who-know, and end-users in their position of those-who-need, preventing appropriation of technology. As s…

In what other similar user-facing system would that be the case? There is an impedance mismatch just in the fact that a UI is much different from code itself. There is a mismatch between what your parents can learn to use (UI) vs. what computers can understand (code). Most other UI projects are compiled (native apps), and they don’t even need to care about sending that final executable over the wire very quickly, or even other web optimizations a bundler might do like code splitting.

These systems become complex because the web is a much different deploy target than, say, iOS.

Re: You don't need a build step

#156

Post by sitkack » Thu, Mar 02, 2023, 8:26 PM UTC

evmar wrote: post #116

I worked on JS infra for Google. One thing we found in this space is that when your apps get very large in terms of number of source files, there is a developer-impacting load time cost to the unbundled approach. That is, your browser loads the entry point file, then parses it for imports and loads the files referenced from there, then parses those for imports and so on. This process is not free. In particular, even…

Is the article targeted at Google use cases? The vast majority of programmers probably write less than 50kloc of code in their entire life and work on projects with a handful of files.

Re: You don't need a build step

#157

Post by Vaguely2178 » Thu, Mar 02, 2023, 8:37 PM UTC

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 other languages. If I ship a python app I don't have to worry about reducing the length of variables names to shave off a few bytes, or bundling multiple files together to reduce the number of http requests. 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.

The closest comparison outside of the browser would be to the container ecosystem, which also runs code in an environment agnostic way, and there's plenty of complexity and volatility there (podman, buildah, docker, nerdctl, k8s, microk8s, k3s, k0s, nomad, docker swarm, docker compose, podman compose, et cetera).

Re: You don't need a build step

#158

Post by simplotek » Thu, Mar 02, 2023, 8:40 PM UTC

dathinab wrote: post #149

agency wrote: post #127

Earlier quoted context omitted.

A poor craftsman blames their tools.

A good craftsman knows not to use bad tools.

> A good craftsman knows not to use bad tools.

In your opinion, what's so wrong in prefering to just run your JS/TS code without having to maintain a build/bundling step?

To me, Deno's approach is undoubtedly a killer feature with regards to the status quo of the whole nodejs ecosystem. Don't you agree?

Re: You don't need a build step

#159

Post by brundolf » Thu, Mar 02, 2023, 8:45 PM UTC

explaininjs wrote: post #141

brundolf wrote: post #94

Earlier quoted context omitted.

I might be missing something, but I'm not seeing how import maps are related to tree-shaking (of individual declarations within a module) Importing ES modules directly instead of bundling will probably mean you ultimately load more code, yeah, which is one reason bundling hasn't gone away. Though you get other benefits in exchange- more granular caching, free and very granular "bundle splitting" (every module is "spl…

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

With that out of the way: yes, the lodash case would be pretty egregious if you imported the whole library in one. And most libraries imported this way will not be totally optimal: you'll probably load some code you don't need. But I think lodash is a pretty dramatic outlier; not only is it gigantic, it's exceptionally modular. Compare it to something like React, which is not small, but is nearly a monolith. The same I assume goes for Vue, etc, as well as other kinds of big libraries like GraphQL clients, third-party SDKs, etc. The percentage of code loaded that didn't need to be is, I would guess, usually much much smaller than it is if you're using a single function from lodash

I would add a couple more things:

- Minification is definitely a loss in the naive case, however, that should be easy for a CDN to implement (I think several already do it). I wouldn't be surprised if Deno/Fresh do this automagically too.

- 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. Of course like you said "depth" is still a limiting factor.

- For extreme cases, dynamic import() is an option in the native ES module system, and can be used to strategically defer module loading

So I don't think it's all that bad, even though like I said above there are tradeoffs. And I'll be curious to see where the industry goes.

PS: It would be good to have the option to bundle with Deno, though. One thing I would be excited to see, personally, is a Deno-ready bundler. One of the main limitations of using Deno right now, if you've got a front-end, is the lack of front-end tooling. You could install Node separately just for tools... but then that's a whole other system dependency, set of concerns, etc. I'd like to be able to do:

  deno run https://deno.land/x/bundler/cli.ts

And have that Just Work™. Maybe it uses WASM modules for speed.

...or maybe this could even be a first-class feature of the `deno` CLI

Re: You don't need a build step

#160

Post by abraxas » Thu, Mar 02, 2023, 8:46 PM UTC

spookthesunset wrote: post #91

kevingadd wrote: post #66

Earlier quoted context omitted.

Over the course of a month or two the time taken to compile a single .ts file in our codebase climbed from 'too small to measure' up to '7 seconds'. It eventually turned out that a single type definition in the file was causing all typechecks to become incredibly slow. Getting timing data out of build tools like rollup was brutal, and editors with tsc integration like vs code/sublime text would just lag and misbehave…

I have to say, for some reason one of the more satisfying things to do is dramatically speed up a lengthy build. It’s hard to beat taking a build that runs forever and making it take a few seconds. I don’t know why. Perhaps it’s because it’s something you and your peers use constantly so when it speeds up the quality of life for all in the shop improves. I mean, it’s not often you get to make an improvement to your p…

To me that's a definition of make work. A good development ecosystem should require no wizardry to make it perform well. And it adds absolutely zero value for the end user of your product. This is why myself and 99% of developers abhor Rube Goldberg build systems like those that permeate JS.