Live data from Hacker News

The three pillars of JavaScript bloat

43081j.com

121–130 of 301 posts

Re: The three pillars of JavaScript bloat

#121
post #3

Fantastic write up! And we're seeing rust happily going down the same path, especially with the micro packages.

Rust is different as there is no runtime.

Yes, instead we pay with requiring supercomputers and 10 hour compile times to process billion of those “atomic architecture”.

Re: The three pillars of JavaScript bloat

#122

Well-written article, manages not to sound rant-y while describing the problem well. I feel like part of the blame for the situation is that JavaScript has always lacked a standard library which contains the "atomic architecture" style packages. (A standard library wouldn't solve everything, of course.)

I like rants though. They help me understand, not only how people feel about stuff, but also why.

Re: The three pillars of JavaScript bloat

#123
post #80

Earlier quoted context omitted.

All software has bloat, but npm packages and web apps are notorious for it. Do you think it could be inherent to the language? JavaScript seems to be unique in that you want your code to work in browsers of the past and future—so a lot of bloat could come from compatibility, as mentioned in the article— and it's a language for UIs, so a lot of bloat in apps and frameworks could come from support for accessibility, in…

> All software has bloat, but npm packages and web apps are notorious for it. Do you think it could be inherent to the language? It sure seems like it is because JS devs, by and large, suck at programming. C has a pretty sparse standard library, but you don't see C programmers creating shared libraries to determine if a number is odd, or to add whitespace to a string.

> you don't see C programmers creating shared libraries to determine if a number is odd, or to add whitespace to a string.

Believe me, if C had a way to seamlessly share libraries across architectures, OSes, and compiler versions, something similar would have happened.

Instead you get a situation where every reasonably big modern C project starts by implementing their own version of string libraries, dynamic arrays, maps (aka dictionaries), etc. Not much different really.

Re: The three pillars of JavaScript bloat

#124
post #104

I really think writing dependency-free JavaScript is the way to go nowadays. The standard library in JS/CSS is great. So are static analysis (TypeScript can check JSDoc), imports (ES modules), UI (web components), etc. People keep telling me the approach I am taking won't scale or will be hard to maintain, yet my experience has been that things stay simple and easy to change in a way I haven't experienced in dependen…

I’ve been exploring this for years, even made a tutorial website about building sites and apps without dependencies (plainvanillaweb.com). What I’ve learned is that many of the things the frameworks, libraries and build tools do can be replaced by browser built-ins and vanilla patterns, but also that making things that way is at present an obscure domain of knowledge. I think this is because the whole web dev knowled…

Thanks for creating and sharing that resource! I'm reading through it now, and it looks fantastic. I'll share it the next time someone asks where to get started with web dev.

Come to think of it, I should write up the techniques I use, too...e.g. I have simple wrappers around querySelector() and createElement() with a bit of TypeScript gymnastics in a JSDoc annotation to add intellisense + type checking for custom elements.

Would you be open to a pull request with a page on static analysis/type checking for vanilla JS? (intro to JSDoc, useful patterns for custom elements, etc.) If not, that's totally OK, but I figure it could be interesting to readers of the site.

And agreed on vanilla/dependency-free not being a silver bullet. There aren't really one-size-fits-all solutions in software, but I've found a vanilla approach (and then adding dependencies only if/when necessary) tends to help the software evolve in a natural way and stay simple where possible.

Re: The three pillars of JavaScript bloat

#125

So the guy who called JS, a weird language was not wrong huh?

Look at Python - similar story. Once a reasonably usable global package registry exists, this is exactly what happens. Languages and standard libraries evolve, shipped code more often than not doesn't.

Re: The three pillars of JavaScript bloat

#126

The most frustrating thing with the "Atomic architecture" bit with tiny packages is how obviously stupid it is. Any borderline sane person should look at isOdd/isEven and see that it's an awful idea Instead they've elevated it to a cultural pillar and think they've come up with a great innovation. It's like talking to antivaxers

It's because it has a smart-sounding name. Some people are shallow and performative; some nice-looking blog post says they can have "atomic architecture", then the trend starts and everybody wants to show how enlightened they are.

That’s not how we started down this path. See snark-free sibling comment from padjo.

Re: The three pillars of JavaScript bloat

#127
post #125

So the guy who called JS, a weird language was not wrong huh?

Look at Python - similar story. Once a reasonably usable global package registry exists, this is exactly what happens. Languages and standard libraries evolve, shipped code more often than not doesn't.

[dead]

Re: The three pillars of JavaScript bloat

#128
post #26

Earlier quoted context omitted.

Cf. Vonnegut's rule #4 of good writing: > Every sentence must do one of two things—reveal character or advance the action. Or Quintilian's praise of Demosthenes and Cicero: "To Demosthenes nothing can be added, but from Cicero nothing can be taken away."

Is there no room for describing the setting? Must every utterance that sets the atmosphere also advance the plot or reveal character? Is there no room for mood?

Setting would provide the context for action or characterisation to occur in a meaningful way, or provoke it, so it is necessary part of both (if done for either of those purposes). Given that, the charitable interpretation would be to only provide enough description of the setting for that.

Re: The three pillars of JavaScript bloat

#129
post #60

Yes, of course the tiny packages cause some of the bloat. As mainly a Java developer being pretty paranoid about my dependency tree (I'm responsible for every byte of code I ship to my users, whether I wrote it or not), I'm always blown away by JS dependency trees. Why would you reach for a library for this three-line function? Just write it yourself, ffs. But the real cause of JS bloat is the so-called "front-end fr…

Regarding tiny packages, I don't think they affect the size of shipped bundle at all. They only bloat your local dev environment.

Re: The three pillars of JavaScript bloat

#130
post #6

A lot of this basically reads to me like hidden tech debt: people aren't updating their compilation targets to ESx, people aren't updating their packages, package authors aren't updating their implementations, etc. Ancient browser support is a thing, but ES5 has been supported everywhere for like 13 years now (as per https://caniuse.com/es5 ).

> Ancient browser support is a thing

And weird browser support.

People use the oddest devices to do "on demand" jobs (receiving a tiny amount of money for a small amount of work). Although there aren't that many, I've seen user agents from game consoles, TVs, old Androids, iPod touch, and from Facebook and other "browser makers", with names such as Agency, Herring, Unique, ABB, HIbrowser, Vinebre, Config, etc. Some of the latter look to be Chrome or Safari skins, but there's no way to tell; I don't know what they are. And I must assume that quite a few devices cannot be upgraded. So I support old and weird browsers. The code contains one externally written module (stored in the repository), so it's only a matter of the correct transpiler settings.

Post reply on HN