Earlier quoted context omitted.
This is absolutely the way to go
Doesn't this go against the credo of not building your own crypto?
The three pillars of JavaScript bloat
151–160 of 301 posts
Re: The three pillars of JavaScript bloat
#152Anyone want to tell him programming languages don’t matter anymore?
Re: The three pillars of JavaScript bloat
#153Re: The three pillars of JavaScript bloat
#154Earlier 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.
A while ago I started a game project in Rust using one of the popular engines. 10GB of build artifacts for the debug target.
With that said, there are plenty of small game engines out there, but couple Rust's somewhat slow compile times with the ecosystems preferences for "many crates" over "one big crate", and yeah, even medium-scale game engines like Bevy take a bunch of time and space to compile. But it is a whole game engine after all, maybe not representative of general development in the community.
Re: The three pillars of JavaScript bloat
#155Nobody argues what we currently have is great and that we shouldn't look to improve it. Reducing it to "JS developers bad" is an embarrassing statement and just shows ignorance, not only of the topic at hand, but of an engineering mindset in general.
Re: The three pillars of JavaScript bloat
#156Re: The three pillars of JavaScript bloat
#157I 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…
What's more, given the tools we have today, it fits really well with agentic engineering. It's even easier to create and understand a homegrown version of a dependency you may have used before.
Re: The three pillars of JavaScript bloat
#158I 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...
The incentives are pretty clear: more packages, more money.
Re: The three pillars of JavaScript bloat
#159Anyone want to tell him programming languages don’t matter anymore?
Re: The three pillars of JavaScript bloat
#160Earlier quoted context omitted.
Rust is different as there is no runtime.
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