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

211–220 of 301 posts

Re: The three pillars of JavaScript bloat

#211

Post by nkrisc »

cobbzilla wrote: post #44
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."

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?

What is the purpose of the setting if not to reveal character or advance the plot?

I don’t need to know the color of the walls if it does neither.

Re: The three pillars of JavaScript bloat

#212

Post by g947o »

https://immich.app/cursed-knowledge

> There is a user in the JavaScript community who goes around adding "backwards compatibility" to projects. They do this by adding 50 extra package dependencies to your project, which are maintained by them.

> https://github.com/immich-app/immich/pull/10690

Re: The three pillars of JavaScript bloat

#213

Post by g947o »

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…

https://immich.app/cursed-knowledge

> There is a user in the JavaScript community who goes around adding "backwards compatibility" to projects. They do this by adding 50 extra package dependencies to your project, which are maintained by them.

> 6/28/2024

Re: The three pillars of JavaScript bloat

#214

Post by g947o »

matheusmoreira wrote: post #33
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…

> entirely for the purpose of getting high download counts on their github account Is this an ego thing or are people actually reaping benefits from this? Anthropic recently offered free Claude to open source maintainers of repositories with over X stars or over Y downloads on npm. I suppose it is entirely possible that these download statistics translate into financial gain...

Yes.

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

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

Re: The three pillars of JavaScript bloat

#215

Post by g947o »

h4ch1 wrote: post #32
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…

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

Re: The three pillars of JavaScript bloat

#217

Post by whstl »

algolint wrote: post #156

[flagged]

I like to criticize React as much as the next person, but this is an JS ecosystem problem around third-party libraries, not a React problem per se.

If you're using third-party NPM packages to do "Vanilla", you're will probably run into the same problem.

If you import React directly from a CDN, you won't.

Re: The three pillars of JavaScript bloat

#218

Post by skydhash »

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.

React is a paradigm change (from imperative to functional) that makes sense in a large UI project. React itself is fairly small in terms of deps.

The main issue is the tooling. JSX is nice enough (not required though) to want a transpiler that will also bundle you app. It’s from that point things get crazy. They want the transpiler to also be a bundler so that it manages their css as well. They also want it to do minification and dead code elimination. They want it to support npm dependencies,etc…

This is how you get weird ecosystems.

Re: The three pillars of JavaScript bloat

#219

Post by h4ch1 »

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

yes! this.
Post reply on HN