Blog

v0! - really this is the first botched together version, I'm curious about feedback. It's kind of a combination of all the best things I like about alpine, vue, solid etc.
Seeing what is possible with using minimal libs and as much of browser features as possible. Just trying things out, more concerned with how the framework looks than the performance for now. Plenty optimisation to be done of different directives.
Also trying to integrate forms into the framework but maybe that should be a separate module for when its not needed. Same thing with extra turbo lib for MPAs.
Still fiddling with how signals are used in markup, currently need to use signal.value in dynamic directives etc, but looking to see if that can be simplified.

I don't think you need to be a web performance puritan to see the benefits of less js & leaner apps.

And building this im really not sure why we NEEDED jsx in the first place. A new language, that needs to be compiled in an extra step, meaning our frameworks don't work vanilla in the browser, and then instead of sending a <div class="big"> to the server were now sending document.createElement('div').class='big' etc. Meaning we're sending loads of extra js, which should be just our code, to transfer what should be html.

And then came next.js, which would PRE-RENDER your jsx into static html, which can look pretty while all the js loads, but its just a big loading screen to be replaced by the render output, which means we are sending everything TWICE. the <div> AND the jsx document.createElement ... All the while leading to the most pointless error of all, the HYDRATION ERROR, forcing you to move logic into useEffect() yada yada...
The javascript on a web page (or app) should only be used to describe the logic, the shape should be in html...

But then look at vue, it looks more like html than jsx magic, <div v-if="show" :class="{'big': big}">, and using <template> elements. But jsx seems like pure overhead to me, why can't our framework tie in directly with actual html? Work with the dom, and the actual elements. And this also means we can use all other vanilla js libraries and web components.
'Way' is essentially just vue without the jsx But loose the jsx, and we can still have nice things! We have the ability for components in html with web-components, and sure they don't have reactivity, but we have signals now. It's all already there. I'm surprised how easy and quick this was, just had to put all these existing pieces together in the right way.
Still of course there is plenty to do still

WHYYY another framework you ask? Well I might argue if this even counts a js framework, but anyway, our js frameworks are so bloated, we need to get back closer to html, web standards and browser api - as such, I LOVE ALPINE.

Alpine.js

Way.js is obviously just alpine with components. that is 100% what this is.

I love the concept of alpine, server render normal html, and the framework interactivity is just sprinkled in with html attributes. i think thats beautifully simple, and obviously super fast and efficient.
But in reality, we just do a lot of things on the client now, sadly not every company will just switch to htmx overnight. So we have some logic to implement client side. But build any larger logic and doing EVERYTHING in html attributes x-data="{...}" will get cramped. So in reality you will always use `Alpine.data('counter',()=>({ x: 123}))`.

Which is great, this is a beautiful way to work to me. But let things get a big bigger, and there is no easy way for re-usable logic (someone will correct me on this). For all the flaws of React, its so nice building and thinking in components, let me put the logic and markup for one part in a re-usable piece.

Components

and YES, i know thats not what alpine is intended for, i read somewhere that components were intentionally not added as this was supposed to be done through server-side templating. But its 2025 and here we are. I came across some alpine extensions for components (probably this one), but that was really just templating, and without a good way to pass in props for reusable logic it just wasn't that useful. So i tried making this work by writing my own web-components and alpine-extension, but I just couldn't get it to work. (I'd love for someone to build this for alpine).

Rebuild

So here we are, i thought I'd rebuild alpine with signals and web-components, in perfect harmony. because fine-grained reactivity is perfect for these specific dom updates, and see where it goes. And I'm surprisignly happy with the result. I think all these pieces fit together really well and the result is small but surprisignly powerful.
I also like the idea of building the NEXT framework on top of all the powerful new APIs coming to browsers, with View Transitions, native signals etc.

SPAc or MPA

So between a full SSR + alpine and a react SPA I think there is space to fill in this spectrum (yes similar area to livewire i guess), for when we need something more complex and composable, yet don't want to have to reach for a full js framework. Everything is still just html, so server render everything and sprinkle in an SPA where you need one.