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.

Nice resource!

Depending on the use case, minimizing dependancies can also decrease attack vectors on the page/app.

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)

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.

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?

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.

Very laudable, though this is probably also part of the issue: If the client doesn't need any migration work, the dev doesn't get more money, which in turn might be phrased: "It is difficult to get a man to understand something, when his salary depends upon his not understanding it!" -- by someone other than me.

I have worked at employer, where one could have done the frontend easily in a traditional server side templating language since most of the pages where static information anyway and very little interactive. But instead of doing that and have 1 person do that, making an easily accessible and standard-conforming frontend, they decided to go with nextjs and required 3 people fulltime to maintain this, including all the usual churn and burn of updating dependencies and changing the "router" and stuff. Porting a menu from one instance of the frontend to another frontend took 3 weeks. Fixing a menu display bug after I reported it took 2 or 3 months.

It's nice to sidestep the relative brittleness of web implementations simply because of versions.

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

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 wouldn't surprise me if CSS has a standard library. It is Turing complete, after all.

Doesn't this go against the credo of not building your own crypto?