> Using the e18e CLI to detect replaceable dependencies https://github.com/e18e/cli That’s awesome. Could be hooked as a pre-commit for agents to do the grunt work of migration.
e18e CLI is great
The three pillars of JavaScript bloat
261–270 of 301 posts
Re: The three pillars of JavaScript bloat
#262I 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…
To the downvote— you know JavaScript is the blitting engine for , right?
Re: The three pillars of JavaScript bloat
#263I 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…
> To be clear though: I’m not arguing the dependencies are bad or don’t have any benefits at all or that vanilla coding is a superior way. Coding this way takes longer and the resulting codebase has more lines of code, and web components are “uglier” than framework components.
If you do it long enough, presumably you start to develop your own miniature "framework" (most likely really just some libraries, i.e. not inverting control and handing it over to your previous work). After all, it's still programming; JS isn't exceptional even if it has lots of quirks.
Anyway, love the website concept, just a quick petition: would it be possible to apply some progressive enhancement/graceful degradation love to such that there's at least the basic preformatted text of the code displayed without JS?
Re: The three pillars of JavaScript bloat
#264Earlier 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.
I wouldn't say every Rust app does, but I do think it has become more normal for Rust apps to have 200-600 dependencies. However when I look at the list, they usually all make sense, unlike with NPM. There are rarely any one-line crates. Actually I haven't seen any yet (except joke ones of course). There's no way the average C++ app uses 250 packages though. It's usually more like 5. C++ packaging is a huge pain so p…
Ardour (an open-source x-platform digital audio workstation, written in C++) has on the order of 80 dependencies.
Re: The three pillars of JavaScript bloat
#265[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.
[flagged]
Re: The three pillars of JavaScript bloat
#266[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.
[flagged]
Re: The three pillars of JavaScript bloat
#267Earlier 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?
There’s been a lot of progress (Temporal, URL, TextDecoder, Base64 encoding, etc.) but there are still gaps.
Math.clamp is a big one (it’s a TC39 proposal). I’d also love to have the stats functions that Python has (geometric mean, median, etc.).
On the more ambitious end: CSV reading/writing and IPv4/IPv6 manipulation.
Re: The three pillars of JavaScript bloat
#268There was a time I'd use dependencies for trivial things like copying a file during building or running things in parallel. Now I just script those in js and call that js from my build. Even testing is now included in node so I stopped using a testing framework.
Re: The three pillars of JavaScript bloat
#269I 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?
web components are reactive. They have a render pattern similar to React's render function. Granted, web-components are much more wonky than React, but the functionality is there.
It seems best practice to use the component's attributes directly. So the component is subscribed to its attributes change lifecycle and renders updates.
Re: The three pillars of JavaScript bloat
#270Well-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.
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)