5 ms·

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 che

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 dependency-heavy projects.

CoderLuii 6mo ago
been doing something similar. the projects ive been building recently use as few dependencies as possible and honestly the maintenance burden dropped significantly. when something breaks you actually know where to look instead of digging through 15 layers of node_modules. people said the same thing to me about it not scaling but the opposite turned out to be true.
- auxiliarymoose 6mo ago
  yeah, plus stack traces, debuggers, and profiling tools are easier to use when all of the non-essential complexity is stripped out. which in turn means it's possible to work productively on software that solves more complex problems. that's in contrast with the sort of stuff that invariably shows up when something falls over somewhere in a dependency: cannot access property "apply" of null at forEach() at setTimeout() at digest() at callback() at then() ... it's not fun to step through or profile that sort of code either...
anematode 6mo ago
This is absolutely the way to go
- k__ 6mo ago
  Doesn't this go against the credo of not building your own crypto?
  - embedding-shape 6mo ago
    Depends on what cryptography you're talking about, the Web Crypto API exists for quite some time, so I'd say that fits in (usually) with "The standard library in JS/CSS is great".
  - auxiliarymoose 6mo ago
    No, it means using the crypto module in the standard library instead of importing some third party dependency.
leptons 6mo ago
If I need a library for nodejs, the first thing I do is search for the dependency-free option. If I can make that work, great.
Maxion 6mo ago
Did this for a project in 2022. Haven't had any drama related to CVEs, hadn't had any issues related to migration from some version of something to another. The client has not had to pay a cent for any sort of migration work.
- auxiliarymoose 6mo ago
  There are certainly security benefits to keeping things in-house. Less exposure to supply-chain attacks (e.g. shai-hulud malware) and widespread security bugs (e.g. react server components server-side RCE). Plus it's much easier to do a complete audit and threat model of the application when you built and understand everything soup-to-nuts. Of course, it also means you have to be cautious about problems that dependencies promise to solve (e.g. XSS), but at the same time, bringing in a bunch of third-party code isn't a substitute for fully understanding your own system.
- bell-cot 6mo ago
  > The client has not had to pay a cent for ... From human society's PoV, you sound like a 10X engineer and wonderful person. But from the C-suite's PoV ...yeah. You might want to keep quite about this.
- jsmith99 6mo ago
  Is the lack of CVE because the implementations you wrote are better written and safer than those in the standard libraries or because no one has checked?
  - foldr 6mo ago
    Presumably the latter. However, mindlessly bumping package versions to fix bullshit security vulnerabilities is now industry standard practice. Once your client/company reaches a certain size, you will pretty much have to do it to satisfy the demands of some sort of security/compliance jarl.
    - consp 6mo ago
      And yet npm install [package with 1000 recursieve dependencies] is not considered a supply chain risk at all to those security/compliance jarls. Let alone having to check all licenses...
Joeri 6mo ago
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 knowledge ecosystem of youtubers and tutorial platforms is oriented around big frameworks and big tooling. People think it is much harder than it actually is to build without frameworks or build tools, or that the resulting web app will perform much worse than it actually will. A typical react codebase ported to a fully vanilla codebase ends up just as modular and around 1.5x the number of lines of code, and is tiny in total footprint due to the lack of dependencies so typically performs well. 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. What I’m saying is that most web developers are trapped in a mindset that these dependencies must be used when in reality they are optional and not always the best choice.
- auxiliarymoose 6mo ago
  Thanks for creating and sharing that resource! I'm reading through it now, and it looks fantastic. I'll share it the next time someone asks where to get started with web dev. Come to think of it, I should write up the techniques I use, too...e.g. I have simple wrappers around querySelector() and createElement() with a bit of TypeScript gymnastics in a JSDoc annotation to add intellisense + type checking for custom elements. Would you be open to a pull request with a page on static analysis/type checking for vanilla JS? (intro to JSDoc, useful patterns for custom elements, etc.) If not, that's totally OK, but I figure it could be interesting to readers of the site. And agreed on vanilla/dependency-free not being a silver bullet. There aren't really one-size-fits-all solutions in software, but I've found a vanilla approach (and then adding dependencies only if/when necessary) tends to help the software evolve in a natural way and stay simple where possible.
  - Joeri 6mo ago
Bockit 6mo ago
I've been doing JS for nearly a couple decades now (both front and back) and I landed on the same approach a few years ago. Pick your absolutely minimal set of dependencies, and then just make what you need for everything else. Maybe counter-intuitive to some, I feel like I'm more comfortable maintaining a larger codebase with less people. 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.
robocat 6mo ago
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-that-differentiates-front-end-frameworks/ https://mjswensen.com/blog/the-single-most-important-factor-... What do you use for model updates?
- j45 6mo ago
  Looking into the history of reactive updates, we find that it started with simple javascript commands helped kickstart most of it. https://en.wikipedia.org/wiki/Ajax_(programming) https://en.wikipedia.org/wiki/Ajax_(programming) The idea of reactivity started in the 1990's in production. When Gmail was released this technology is what made a website behave like a desktop app (plus the huge amount of storage) If we were to look into today's equivalent of doing this, it might be surprising what exists in the standard libraries.
- apsurd 6mo ago
  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.
assimpleaspossi 6mo ago
CSS has a standard library? I stopped doing web dev just three years ago and am not aware of such a thing. Do you mean the CSS standard?
- theandrewbailey 6mo ago
  It wouldn't surprise me if CSS has a standard library. It is Turing complete, after all.
- auxiliarymoose 6mo ago
  Sure it's not officially called the "standard library," more precisely it would be "the parts of the ECMAScript and CSS standards implemented by all popular evergreen browsers," but "standard library" expresses this in the way people usually talk about programming languages.
obsidianbases1 6mo ago
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
arcadianalpaca 6mo ago
Yeah I've been doing this more and more. The friction of keeping dependencies updated has gotten worse than the friction of just maintaining the (often times) 20 or so lines you need to write yourself. Not to mention the pain you'll eventually find yourself when a bug isn't patched fast enough, or when you need to make a small change, or when a transitive dependency you've never heard of gets compromised...
stevage 6mo ago
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.
- chihuahua 6mo ago
  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.
pennaMan 6mo ago
This is one of the best parts of agentic development. I almost never had to reach for any npm package besides the foundational staples like the tailwinds and react queries. My pacakge.json dependency array vs project size ratio is just incredible nowadays

CoderLuii 6mo ago

been doing something similar. the projects ive been building recently use as few dependencies as possible and honestly the maintenance burden dropped significantly. when something breaks you actually know where to look instead of digging through 15 layers of node_modules. people said the same thing to me about it not scaling but the opposite turned out to be true.

auxiliarymoose 6mo ago
yeah, plus stack traces, debuggers, and profiling tools are easier to use when all of the non-essential complexity is stripped out. which in turn means it's possible to work productively on software that solves more complex problems. that's in contrast with the sort of stuff that invariably shows up when something falls over somewhere in a dependency: cannot access property "apply" of null at forEach() at setTimeout() at digest() at callback() at then() ... it's not fun to step through or profile that sort of code either...

anematode 6mo ago

This is absolutely the way to go

k__ 6mo ago
Doesn't this go against the credo of not building your own crypto?
- embedding-shape 6mo ago
  Depends on what cryptography you're talking about, the Web Crypto API exists for quite some time, so I'd say that fits in (usually) with "The standard library in JS/CSS is great".
- auxiliarymoose 6mo ago
  No, it means using the crypto module in the standard library instead of importing some third party dependency.

leptons 6mo ago

If I need a library for nodejs, the first thing I do is search for the dependency-free option. If I can make that work, great.

Maxion 6mo ago

Did this for a project in 2022. Haven't had any drama related to CVEs, hadn't had any issues related to migration from some version of something to another. The client has not had to pay a cent for any sort of migration work.

auxiliarymoose 6mo ago
There are certainly security benefits to keeping things in-house. Less exposure to supply-chain attacks (e.g. shai-hulud malware) and widespread security bugs (e.g. react server components server-side RCE). Plus it's much easier to do a complete audit and threat model of the application when you built and understand everything soup-to-nuts. Of course, it also means you have to be cautious about problems that dependencies promise to solve (e.g. XSS), but at the same time, bringing in a bunch of third-party code isn't a substitute for fully understanding your own system.
bell-cot 6mo ago
> The client has not had to pay a cent for ... From human society's PoV, you sound like a 10X engineer and wonderful person. But from the C-suite's PoV ...yeah. You might want to keep quite about this.
jsmith99 6mo ago
Is the lack of CVE because the implementations you wrote are better written and safer than those in the standard libraries or because no one has checked?
- foldr 6mo ago
  Presumably the latter. However, mindlessly bumping package versions to fix bullshit security vulnerabilities is now industry standard practice. Once your client/company reaches a certain size, you will pretty much have to do it to satisfy the demands of some sort of security/compliance jarl.
  - consp 6mo ago
    And yet npm install [package with 1000 recursieve dependencies] is not considered a supply chain risk at all to those security/compliance jarls. Let alone having to check all licenses...

Joeri 6mo ago

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 knowledge ecosystem of youtubers and tutorial platforms is oriented around big frameworks and big tooling. People think it is much harder than it actually is to build without frameworks or build tools, or that the resulting web app will perform much worse than it actually will. A typical react codebase ported to a fully vanilla codebase ends up just as modular and around 1.5x the number of lines of code, and is tiny in total footprint due to the lack of dependencies so typically performs well. 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. What I’m saying is that most web developers are trapped in a mindset that these dependencies must be used when in reality they are optional and not always the best choice.

auxiliarymoose 6mo ago
Thanks for creating and sharing that resource! I'm reading through it now, and it looks fantastic. I'll share it the next time someone asks where to get started with web dev. Come to think of it, I should write up the techniques I use, too...e.g. I have simple wrappers around querySelector() and createElement() with a bit of TypeScript gymnastics in a JSDoc annotation to add intellisense + type checking for custom elements. Would you be open to a pull request with a page on static analysis/type checking for vanilla JS? (intro to JSDoc, useful patterns for custom elements, etc.) If not, that's totally OK, but I figure it could be interesting to readers of the site. And agreed on vanilla/dependency-free not being a silver bullet. There aren't really one-size-fits-all solutions in software, but I've found a vanilla approach (and then adding dependencies only if/when necessary) tends to help the software evolve in a natural way and stay simple where possible.
- Joeri 6mo ago

Bockit 6mo ago

I've been doing JS for nearly a couple decades now (both front and back) and I landed on the same approach a few years ago. Pick your absolutely minimal set of dependencies, and then just make what you need for everything else. Maybe counter-intuitive to some, I feel like I'm more comfortable maintaining a larger codebase with less people. 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.

robocat 6mo ago

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-that-differentiates-front-end-frameworks/ https://mjswensen.com/blog/the-single-most-important-factor-... What do you use for model updates?

j45 6mo ago
Looking into the history of reactive updates, we find that it started with simple javascript commands helped kickstart most of it. https://en.wikipedia.org/wiki/Ajax_(programming) https://en.wikipedia.org/wiki/Ajax_(programming) The idea of reactivity started in the 1990's in production. When Gmail was released this technology is what made a website behave like a desktop app (plus the huge amount of storage) If we were to look into today's equivalent of doing this, it might be surprising what exists in the standard libraries.
apsurd 6mo ago
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.

assimpleaspossi 6mo ago

CSS has a standard library? I stopped doing web dev just three years ago and am not aware of such a thing. Do you mean the CSS standard?

theandrewbailey 6mo ago
It wouldn't surprise me if CSS has a standard library. It is Turing complete, after all.
auxiliarymoose 6mo ago
Sure it's not officially called the "standard library," more precisely it would be "the parts of the ECMAScript and CSS standards implemented by all popular evergreen browsers," but "standard library" expresses this in the way people usually talk about programming languages.

obsidianbases1 6mo ago

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

arcadianalpaca 6mo ago

Yeah I've been doing this more and more. The friction of keeping dependencies updated has gotten worse than the friction of just maintaining the (often times) 20 or so lines you need to write yourself. Not to mention the pain you'll eventually find yourself when a bug isn't patched fast enough, or when you need to make a small change, or when a transitive dependency you've never heard of gets compromised...

stevage 6mo ago

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.

chihuahua 6mo ago
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.

pennaMan 6mo ago

This is one of the best parts of agentic development. I almost never had to reach for any npm package besides the foundational staples like the tailwinds and react queries. My pacakge.json dependency array vs project size ratio is just incredible nowadays