This is exactly what I'm doing with my personal "framework" I use for client contracts. It's just Web Components with a handy class based wrapper. I call it Template, since it's based off <template> tags.
It's a joy to work in, feels "frameworky" but it's just web standards with <100 lines of convenience JS wrapped around it. There is no magic beyond what the browser provides - I like it that way.
It's "open source" as a reference. Just using it for myself. There aren't many docs beyond notes to myself. But the actual framework is a 90LoC JavaScript file that is an easy read.
You're welcome to kick the tires. If you like it I'd entertain PRs and stuff but it's such a small library forking is probably entirely reasonable to make your own flavor too.
The general idea is you extend the Template base class and call "super" with the id of the <template> that will get bound to the ShadowDOM when the class is mounted. Then you call instance.mount and pass a dom node to mount it into the DOM. For child nodes, you use `this.fragment.querySelector` to select them from the <template> you mounted. It supports garbage collection by tracking children, so when you "unmount" it recursively unmounts all child instances as well. Finally it has an event emitter implementation, so changes/actions/events bubble up the DOM while state can push down through the DOM. Keeps things clean.
I recently added state methods since I was duplicating state management everywhere. Now the base template class has a `setState` that will emit a single `change` event for all changes in the current "tick" of the browser eval loop.
I like how for your brief documentation you start with a single index.html file. Too many web/framework docs start with a command that gives you a directory full of who knows what, which tends to negatively affect beginners more than anyone
I can pinpoint the exact time where I fully became disillusioned with front end work and it was the day where I realized that in order to be productive with these tools, you had to set it up with the CLI.
A lot of these frameworks don't actually need a CLI to scaffold them. React was (at least originally, I haven't checked in on it in a while) designed to be _incrementally_ adopted so you can retrofit an existing website with React components.
But I do agree with the CLI for bootstrapping being a problem for react. It's less of the CLI itself and more of the mountains it moves under the hood to setup the app. I run a single command and get an absolutely massive project. Yes the final dist file is only KBs in size, but the entire build process that gets scaffolded is still part of my project. That single command install seems "easy" but leaves me with a huge amount of existential dread - no matter how much the tooling "paves the path" it doesn't delegate responsibility. Ultimately I'm on the hook for this application and when things don't work it's on me to understand why and fix them. After a CRA install, I'm often left feeling like I'm looking off a cliff into an abyss that is going to take a huge investment to understand.
The last time I used React was inside a big company. I felt safe using it there because there was a team responsible for "owning" react inside the company. I followed their docs to start with CRA and pull in their component library. If anything inside my CRA app went sideways I _had_ delegated responsibility to another team for that, I had a support line that I could reach out to to get help and ultimately problems at that level were their responsibility. That isn't true in my personal projects - so I don't use it there.
FWIW I actually feel the same way about infrastructure components. I am Terraform certified, have been sysadmining Linux installs for over a decade, have built a serverless platform inside FAANG, played SRE, etc. But still K8S, Linux, etc. leave me with similar feelings. When I can delegate their responsibility I'll build on top of them or participate on teams that manage them, but for my own stuff there is too much to chew for me to adopt that for a personal or client project. Even with my background, for my projects I choose platforms where I can delegate that part of the stack to a vendor. These days I'm building on Cloudflare Workers, R2, and PlanetScale for my DB (until D1 is prod ready). When I adopt a service - I pay for it at a rate that gets me support contracts. That $$$ is funding an engineering team far greater than me to build, support, maintain, and understand that chunk of the system so I don't have to.
I just swapped my app to Vite from CRA and it's far better. CRA was pretty simple too especially if you weren't using typescript, I assume you were post "eject".
This is awesome! I was actually looking for this very kind of thing the past couple of days. I was searching HN and Github for "vanilla js" and various "framework" queries but not finding anything. Thanks!
Watch out for the Web Component gotchas, though: the shadow DOM encapsulates the CSS cascade meaning your styles will not apply to your components unless you explicitly apply them to each one. Also, events don’t automatically bubble up!
I just put together a content style website using nothing but web components and used a base class to put my global styles into and just inherited my various components from it.
Was also really easy to factor out shareable styles like various page layouts using a similar technique.
That just left me with doing small targeted tweaks where I would override things with custom properties along the way as needed plus any component specific styles.
Was probably the cleanest approach I’ve had in as long as I could remember. Plus it was delivering me a perfect 100 score in Lighthouse too for what it’s worth. Would recommend.
Glad you like it! Feel free to take it and make it your own.
If you make changes, I'd appreciate a follow up GitHub comment that lets me know where you made improvements, but no obligation. It's licensed under a BSD-style license so you're free to do with it whatever you like!
It's a joy to work in, feels "frameworky" but it's just web standards with <100 lines of convenience JS wrapped around it. There is no magic beyond what the browser provides - I like it that way.
https://github.com/retrohacker/template/
It's "open source" as a reference. Just using it for myself. There aren't many docs beyond notes to myself. But the actual framework is a 90LoC JavaScript file that is an easy read.
You're welcome to kick the tires. If you like it I'd entertain PRs and stuff but it's such a small library forking is probably entirely reasonable to make your own flavor too.
The general idea is you extend the Template base class and call "super" with the id of the <template> that will get bound to the ShadowDOM when the class is mounted. Then you call instance.mount and pass a dom node to mount it into the DOM. For child nodes, you use `this.fragment.querySelector` to select them from the <template> you mounted. It supports garbage collection by tracking children, so when you "unmount" it recursively unmounts all child instances as well. Finally it has an event emitter implementation, so changes/actions/events bubble up the DOM while state can push down through the DOM. Keeps things clean.
I recently added state methods since I was duplicating state management everywhere. Now the base template class has a `setState` that will emit a single `change` event for all changes in the current "tick" of the browser eval loop.
Cheers and happy hacking!