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

231–240 of 301 posts

Re: The three pillars of JavaScript bloat

#231

Post by 12345hn6789 »

rtpg wrote: post #27

I think on the first point, we have to start calling out authors of packages which (IMO) have built out these deptrees to their own subpackages basically entirely for the purpose of getting high download counts on their github account Like seriously... at 50 million downloads maybe you should vendor some shit in. Packages like this which have _7 lines of code_ should not exist! The metadata of the lockfile is bigger…

Reminder this user is paid per download https://github.com/A11yance/axobject-query/pull/354#issuecom...

Re: The three pillars of JavaScript bloat

#232

Post by panstromek »

grishka wrote: post #192
panstromek wrote: post #84

Earlier quoted context omitted.

Yea, honestly you probably just don't understand. FE frameworks solve a specific problem and they don't make sense unless you understand that problem. That TSoding video is a prime example of that - it chooses a trivial instance of that problem and then acts like the whole problem space is trivial. To be fair, React is especially wasteful way to solve that problem. If you want to look at the state od the art, somethi…

One of my projects does have a complex UI and is built with zero runtime dependencies on the front end. It doesn't require JS at all for most of its functionality. I just render as much as possible on the server and return commands like "hide the element with that ID" or "insert this HTML after element with that ID" in response to some ajax requests. Outside of some very specific interactive components, I avoid clien…

That's good and arguably the right default for most websites.

Re: The three pillars of JavaScript bloat

#233

Post by fragmede »

xigoi wrote: post #141
skrtskrt wrote: post #30

the fact that you can just redefine Map in a script is mind boggling

Why? Being able to redefine anything is table stakes in dynamic languages.

You can't assign a value to false, for example, so "anything" isn't everything (Node v22.17.0).

    > false = 4
    false = 4
    ^^^^^
    
    Uncaught SyntaxError: Invalid left-hand side in assignment
Fascinatingly enough though, you can assign a value to NaN. It doesn't stick tho.

    > NaN
    NaN
    > NaN = 42
    42
    > NaN
    NaN
    >
(map behaves as described.)

Re: The three pillars of JavaScript bloat

#234

Post by bryanrasmussen »

josephg wrote: post #178
bryanrasmussen wrote: post #86

Earlier quoted context omitted.

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.

sure, if a character is in some narrative role; however I would argue that no author ever describes a place objectively, especially not a completely fictional place. The question really is if the unobjective description serves a coherent narrative purpose.

Re: The three pillars of JavaScript bloat

#235

Post by obsidianbases1 »

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…

This is the way. Even more so now that LLMs can reliably write simple utilities, the kind of things a dependency would previously frag in hundreds of other utilities (that go unused) all while depending on another dozen dependencies

Re: The three pillars of JavaScript bloat

#236

Post by assimpleaspossi »

Defenestresque wrote: post #191
cwnyth wrote: 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."

For the curious, the rest of the types: Use the time of a total stranger in such a way that he or she will not feel the time was wasted. Give the reader at least one character he or she can root for. Every character should want something, even if it is only a glass of water. Every sentence must do one of two things—reveal character or advance the action. Start as close to the end as possible. Be a sadist. No matter h…

>>Write to please just one person. If you open a window and make love to the world, so to speak, your story will get pneumonia.

This, too, is the problem with movies and TV shows today. They worry so much about offending anyone they lose the interest of everyone. When was the last time you laughed hard and out loud?

Re: The three pillars of JavaScript bloat

#238

Post by padjo »

grishka wrote: post #199
padjo wrote: post #112

Earlier quoted context omitted.

> you could just modify your real DOM straight from your networking code You can also use your underparts as a hat. It doesn't mean its a good idea.

You imply that you somehow get a visibly different end result if you touch DOM directly. Except to me, using React instead of a simple assignment to e.g. update the text on a button feels like taking several long flights that complete a lap around the world just to get from LA to SF, instead of the 1-hour direct flight.

It's a case of Chesterton's fence. Having built complex apps pre-react, I wouldn't be in a hurry to go back to that approach because I have first hand experience of running into the problems it solves.

Re: The three pillars of JavaScript bloat

#239

Post by throw-the-towel »

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?

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

Re: The three pillars of JavaScript bloat

#240

Post by chrismorgan »

skydhash wrote: post #3

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

Rust is not going down the same path, and it’s ludicrous to suggest it is. Almost none of the first and third pillars are even possible in Rust, and to the extent they are, they’re not a problem in practice. As for the second, “atomic architecture”, it’s not taken anywhere near the extreme it frequently is with npm. There are not many micro-packages that get used, and where they are, they mostly make more sense than they did in npm, and they don’t have anywhere near the cost they do in npm, and can have some concrete advantages.
Post reply on HN