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

281–290 of 301 posts

Re: The three pillars of JavaScript bloat

#281

Post by rtpg »

serial_dev wrote: post #71
rtpg wrote: post #65

Earlier quoted context omitted.

I think the fact that everyone cites the same is-number package when saying this is indicative of something though. Like I legit think that we are all imagining this cultural problem that's widespread. My claim (and I tried to do some graph theory stuff on this in the past and gave up) is that in fact we are seeing something downstream of a few "bad actors" who are going way too deep on this. I also dislike things li…

Have you heard of the left pad incident? The problem is not imagined.

Even there the "problem" was left-pad being used by one or two projects used in "everything".

So the problem isn't that everyone is picking up small deps, but that _some_ people who write libs that are very popular are picking up small deps and causing this to happen.

This is different because it doesn't really say that all JS developers are looking to include left-pad. But I _do_ think that lots of library authors are too excited to make these kinds of dep trees

Re: The three pillars of JavaScript bloat

#283

Post by jazzypants »

userbinator wrote: post #279
jazzypants wrote: post #230

Earlier quoted context omitted.

Literally nothing has degraded. What in the world are you talking about? All of this stuff is optional.

Looking at the state of things, it sure doesn't seem that way. Literally nothing has degraded Trying to gaslight others into thinking everything is just fine is not working anymore.

What has degraded? Name one single thing specifically.

Every aspect of web development is easier and better than it was two, five, ten, or twenty years ago.

Entropy is a fact, but whining about it without solutions doesn't help anyone.

Re: The three pillars of JavaScript bloat

#284

Post by stephenr »

saghm wrote: post #276
stephenr wrote: post #106

Earlier quoted context omitted.

Fair point. Let's compromise and say that whoever is responsible for involving (javascript|electron fields) in the display of a website, should each understand their respective field. I don't expect a physicist or even an electrical engineer or cpu designer to necessarily understand JavaScript. I don't expect a JavaScript developer to understand electron fields. I do expect a developer who is writing JavaScript to un…

The issue with this framing is that understanding something isn't a binary; you don't need to be an expert in every feature of a programming language to be able to write useful programs in it. The comment above describing prototypical inheritance as esoteric was making the point that you conflated the modulus operator with it as if they're equally easy to understand. Your responses don't seem to indicate you agree wi…

Given that they literally changed the language to support the class keyword, I think we can safely assume it isn't just the beginners who never bothered to learn how prototypical inheritance works.

Re: The three pillars of JavaScript bloat

#285

Post by chihuahua »

stevage wrote: post #280
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…

It depends a lot what kind of thing you're building. If it's a simple marketing website, sure. But any application that does stuff is likely using dependencies that provide a lot of functionality. I make a lot of sites with maps. There's no real alternative to mapbox/maplibre/openlayers.

That should be self-evident and obvious, but apparently it still needs to be pointed out.

On one extreme, you have the current world where there are millions of 1-line or 1-function packages like leftPad and isArray.

On the other extreme, there are no packages and everyone builds everything from scratch, every single time.

It should not be controversial or groundbreaking to suggest that perhaps there is a reasonable middle ground in between! Someone builds a substantial piece of functionality, and it can be reused.

Re: The three pillars of JavaScript bloat

#287

Post by shimman »

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

Any resource/blogs you'd recommend on writing "modern" JS beyond the usual es5 reccomendations?

Re: The three pillars of JavaScript bloat

#288

Post by userbinator »

jazzypants wrote: post #283
userbinator wrote: post #279

Earlier quoted context omitted.

Looking at the state of things, it sure doesn't seem that way. Literally nothing has degraded Trying to gaslight others into thinking everything is just fine is not working anymore.

What has degraded? Name one single thing specifically. Every aspect of web development is easier and better than it was two, five, ten, or twenty years ago. Entropy is a fact, but whining about it without solutions doesn't help anyone.

As I write this comment, this happens to be at the top of the front page: https://news.ycombinator.com/item?id=47480507

Re: The three pillars of JavaScript bloat

#289

Post by b00ty4breakfast »

embedding-shape wrote: post #160
b00ty4breakfast wrote: post #73

Earlier quoted context omitted.

I'm not very familiar with rust but I'm pretty sure it has a runtime. Even C has a runtime. Unless you're talking about an "environment" eg Node or the like

Indeed Rust has a runtime, I'm not sure why the whole "Rust has no runtime" comes from, I keep seeing it repeated from time to time, but can't find the origin of this, I don't think it's ever been true?

The only thing I can think is that folks are getting confused by stuff like the JRE and Node being called "runtime environments".

Re: The three pillars of JavaScript bloat

#290

Post by spartanatreyu »

Frotag wrote: post #270
josephg wrote: post #174

Earlier quoted context omitted.

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.

Some utility stuff I copy paste between projects: - range, clamp, inIvl, enumerate, topK - groupBy (array to record), numeric / lexical array sorts - seeded rng - throttling - attachDragListener (like d3's mousedown -> mousemove -> mouseup) - Maps / Sets that accept non-primitive keys (ie custom hash) So basically functions that every *dash variant includes.

Also, all the functions that are already in the standard library but are made in a way that don't use more modern features:

- Functions that use map-like and set-like objects instead of maps and sets.

- Functions that should be async that aren't

- Async functions that should be cancellable, but aren't

- Functions that should use the disposable and async disposable stack (e.g. the `using` keyword)

- Functions that should return deeply immutable data structures but can't. (The R̶e̶c̶o̶r̶d̶s̶ ̶a̶n̶d̶ ̶T̶u̶p̶l̶e̶s̶ / Composites, and Structs proposals would help here)

- Concurrency coordination primitives (Imagine an array of 10 async functions that we wish to run. Going through them one at a time is too slow. `Promise.allSettled()` executes them all at the same time which might slow things down even more due to bottlenecking. We should have an easy way to say only execute a maximum of 3 at a time. As 1 function resolves, the next one is started, until all are resolved).

Post reply on HN