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

The three pillars of JavaScript bloat

43081j.com

Post reply on HN
Print view View original

251–260 of 301 posts

Re: The three pillars of JavaScript bloat

#251

Post by wheattoast »

jefftk wrote: post #186
wheattoast wrote: post #173

“Alternatively, what’d be really nice is if they upgraded“ Easy enough for y’all with techie salaries, but as one of the millions of poor folks whose paychecks barely (or don’t even) pay the bills, it’d be really nice if we didn't have to junkheap our backbreakingly expensive hardware every few years just cuz y’all are anorexically obsessed with lean code, and find complex dependancies too confusing/bothersome to mai…

They're talking about people still running ES3 browser engines, like IE8, which was released 15+ years ago and went EOL 10+ years ago. The author could have done a better job clarifying this, but they're not pushing for a world with 2y device lifetimes.

Thanks for the clarification. I did not understand.

My knee-jerky reaction to the author’s blithe exhortation to upgrade stems from pain of watching as my prized workhorse (a 2015 MacBook) dies in my arms despite its magnificently healthy and powerful body.

Re: The three pillars of JavaScript bloat

#252

Post by ivanjermakov »

hrmtst93837 wrote: post #77
zdc1 wrote: 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 ).

[flagged]

Not just web, gamedev is suffering this too, since ~2020.

Re: The three pillars of JavaScript bloat

#253

Post by fireflash38 »

throw-the-towel wrote: post #239
josephg wrote: post #190

Earlier quoted context omitted.

Thanks but that doesn't answer my question. Forget node and bun then. What is missing from the standard library?

String.splitRight, for one. (As an example: "www.a.north.website.com".splitRight(".", 3) == ["www.a.north", "website", "com"].)

When would you want that when it wouldn't be covered by more domain-specific use cases?

Re: The three pillars of JavaScript bloat

#254

Post by wheattoast »

abanana wrote: post #245
jefftk wrote: post #186

Earlier quoted context omitted.

They're talking about people still running ES3 browser engines, like IE8, which was released 15+ years ago and went EOL 10+ years ago. The author could have done a better job clarifying this, but they're not pushing for a world with 2y device lifetimes.

Indeed, they're talking about the opposite extreme from the usual problem we all bemoan in here, which is JS devs being determined to use the newest shiniest thing as soon as it's been announced, instead of being willing to continue to use what they've always used and to wait until the new stuff works across all browsers. This article really surprised me, in how far some are apparently going in the opposite direction…

Fair, but personally I’d absolutely prefer slower bloated code with twice the lifespan to faster code that forces me to buy new hardware I can’t afford. But I’m a nearly extinct type of consumer who happily clings to pre-subscription-era software (e.g., Photoshop 7, Sketchup 2017). I understand and begrudgingly accept that businesses couldn’t survive by tending to the desires of folks like me.

Re: The three pillars of JavaScript bloat

#255

Post by tylerchilds »

I agree, but would also posit a parallel The Three Pillars of JavaScript Ecosystem Bloat

for example, javascript runs in a browser or on microcontrollers. you can write code that work for both natively [1].

TypeScript-- a mechanism that needs to compile first into javascript

React-- a mechanism that needs to compile first into javascript

Configuration-de-jour-- Depending on how you need to string your TypeScript and React together, there's a thing you need to manage your javascript managers. Vite is the best option in this field, since it recognizes exposing tools to fine tune how to optimize your resulting javascript from your typescript and react is a terrible idea that leads to mass fragmentation on a global scale for what it even means to "spin up a js project"

In conclusion, is javascript a compile target like assembly or a language that people can handcode to eek performance out of like assembly?

[1]: https://github.com/bellard/mquickjs

Re: The three pillars of JavaScript bloat

#256

Post by andai »

sheept wrote: post #80
andai wrote: post #17

Great article, but I think these are all marginal. The main cause of bloat is not polyfills or atomic packages. The cause of bloat is bloat! I love this quote by Antoine de Saint-Exupéry (author of the Little Prince): "Perfection is achieved, not when there is nothing left to add, but nothing to take away." Most software is not written like that. It's not asking "how can we make this more elegant?" It's asking "what'…

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…

I think it has to do with temperament and incentives.

For example we often see posts on HN about, "see, it's possible to write very fast software in language foo!" And most of the time yes, especially on modern hardware, most languages do allow you to write surprisingly fast software!

It's just that the people who actually want their software to run fast -- and who want it enough to prioritize it against other, competing values -- those people will generally reach for other languages.

With JavaScript, the primary "value" is convenience. The web as a platform is chosen because it is convenient, both for the developer and the user. So it stands to reason that the developer will also make other choices in the name of convenience.

Of course, there's weirdos like me who take pride in shipping games JS that are eight kilobytes :) But there are not very many people like that.

Re: The three pillars of JavaScript bloat

#257

Post by andai »

Tade0 wrote: post #140
socalgal2 wrote: post #91

Earlier quoted context omitted.

Every cargo install (rust) I've down downloads 300 to 700 packages Every C++ app I install in linux requires 250 packages Every python app I install and then pip install requirements uses 150 packages.

A while ago I started a game project in Rust using one of the popular engines. 10GB of build artifacts for the debug target.

In Rust land, I enjoyed Macroquad, for simple 2D stuff. It's very much in the vein of XNA/MonoGame.

Re: The three pillars of JavaScript bloat

#258

Post by eudamoniac »

josephg wrote: post #190
simonw wrote: post #182

Earlier quoted context omitted.

Those aren't a standard library for the language itself - they're not showing up in browsers, for example.

Thanks but that doesn't answer my question. Forget node and bun then. What is missing from the standard library?

Most things in Remeda, ramda, rxjs, the methods in the Ruby stdlib, etc. would all be great to have. I use at least Remeda in every project when I can.

Re: The three pillars of JavaScript bloat

#259

Post by JodieBenitez »

Joeri wrote: post #104
auxiliarymoose wrote: post #20

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…

Such a great website ! Congrats.

Re: The three pillars of JavaScript bloat

#260

Post by eudamoniac »

g947o wrote: post #215
h4ch1 wrote: post #32

Earlier quoted context omitted.

I remember seeing this one guy who infiltrated some gh org, and then started adding his own packages to their dependencies or something to pad up his resume/star count. Really escapes me who it was.

https://github.com/A11yance/axobject-query/pull/354 https://github.com/A11yance/aria-query/pull/497

Christ. What a psycho.
Post reply on HN