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

171–180 of 301 posts

Re: The three pillars of JavaScript bloat

#171

Post by RadiozRadioz »

padjo wrote: post #148
RadiozRadioz wrote: post #144

Earlier quoted context omitted.

Both my claim and theirs are unsupported by evidence, therefore they are equally valid.

A third argument is that it was because of aliens from the planet Blotrox Prime. But I suppose without evidence we'll just have to accept that all three theories are equally probable.

Interesting how you decided to switch to hyperbole instead of providing evidence for your claim. Backing up your viewpoint would have easily shut me down, putting the ball in my court to do the same. Instead you gave a knee-jerk childish response.

Re: The three pillars of JavaScript bloat

#172

Post by skrebbel »

AltruisticGapHN wrote: post #170

"some people apparently exist who need to support ES3 - think IE6/7, or extremely early versions of Node.js" Seriously what kind of business today needs to support ES3 browsers? Even banking sites should refuse to run on such old devices out of security concerns.

This is 100% teams who set up their build tooling back in 2015 and haven't updated since. There's plenty widely used apps and libs that date this far back, and back then, IE8 compat was considered pretty important still, esp for products targeting enterprise/government customers.

Upgrading eg Webpack and Babel and polyfill stacks and all that across multiple major versions is a serious mess. Lots of breaking changes all around. Much better to just ship features. If it ain't broke, don't fix it!

Re: The three pillars of JavaScript bloat

#173

Post by wheattoast »

“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 maintain.

Re: The three pillars of JavaScript bloat

#174

Post by josephg »

stevoski wrote: post #107

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.)

What functionality is still missing from the JS standard library? The JS standard library seems massive these days.

Edit: Removed a reference to node and bun.

Re: The three pillars of JavaScript bloat

#175

Post by stephenr »

CoderLuii wrote: post #39
stephenr wrote: post #29

The primary cause of JS bloat is assuming you need JS or that customers want whatever you're using it to provide. For $client we've taken a very minimal approach to JavaScript, particularly on customer facing pages. An upcoming feature finally replaces the last jquery (+ plugin) dependent component on the sales page, with a custom implementation. That change shaved off ~100K (jquery plus a plugin removed) and for mos…

160K total is impressive. most landing pages i see are shipping 2-3MB of js before the first paint. the "write your own code" approach gets laughed at but when you actually do it the result is faster, easier to debug, and you dont wake up one morning to find out one of your 200 dependencies got compromised.

Wait till I tell those people we keep all our dependencies (js and backend) in our own git repo.

Updating dependencies is a task a person does, followed by committing the changes to the repo.

I am aware a lot of these ideas are heretical to a lot of software developers these days.

Re: The three pillars of JavaScript bloat

#176

Post by assimpleaspossi »

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…

CSS has a standard library? I stopped doing web dev just three years ago and am not aware of such a thing. Do you mean the CSS standard?

Re: The three pillars of JavaScript bloat

#177

Post by j45 »

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…

Nice resource!

Depending on the use case, minimizing dependancies can also decrease attack vectors on the page/app.

Re: The three pillars of JavaScript bloat

#178

Post by josephg »

bryanrasmussen wrote: post #86
cobbzilla wrote: post #61

Earlier quoted context omitted.

sure, setting and character are the same thing

the implication is that if mood is the character of the place then those sentences that set mood are advancing character.

Some authors rarely describe a place objectively. We see a space through the eyes of the characters - and in doing so, we learn about our characters as we learn about the space they inhabit.

Re: The three pillars of JavaScript bloat

#179

Post by j45 »

robocat wrote: post #168
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…

Rendering components is the easy part. Another goal of frameworks is to provide the model (reactive updates): https://mjswensen.com/blog/the-single-most-important-factor-... What do you use for model updates?

Looking into the history of reactive updates, we find that it started with simple javascript commands helped kickstart most of it.

https://en.wikipedia.org/wiki/Ajax_(programming)

The idea of reactivity started in the 1990's in production.

When Gmail was released this technology is what made a website behave like a desktop app (plus the huge amount of storage)

If we were to look into today's equivalent of doing this, it might be surprising what exists in the standard libraries.

Re: The three pillars of JavaScript bloat

#180

Post by j45 »

Maxion wrote: post #58
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…

Did this for a project in 2022. Haven't had any drama related to CVEs, hadn't had any issues related to migration from some version of something to another. The client has not had to pay a cent for any sort of migration work.

It's nice to sidestep the relative brittleness of web implementations simply because of versions.
Post reply on HN