DEV Community

So I Quit $200k Job To Write A Framework

Alex on July 24, 2025

This may sound like the worst idea ever. But I think there is no better time than now. Trying To Fix The Web Dev: Part 3, The Formula. ...

Read full post

Hunter Sheridan • Jul 26

Hi Alex

Thank you for your creativity and entrepreneurial sacrifice (leaving the day job :-) ) in trying to innovate in this space and solve current architectural problems with web apps.

Sorry for the bother. Have i understood the strategic aspects of your framework correctly below?

Eliminate the need for APIs via html partial page requests
Solve Websocket/SSE fragility via rolling http connections and align with "SPA" UX
Coordinate traditional request/responses across rolling http connections with a protocol of status metadata (about the request/response) in the header of each rolling connection

Node, Beam, Fragment is an architectural improvement in it's own right, but breaking out "beam" and "node" from the traditional component approach better aligns with 1, 2 and 3 above?

Thanks in advance for your time.

Alex • Jul 26 • Edited

Hi Hunter

Eliminate the need for APIs via html partial page requests

It is more precise to say that API is eliminated by delegating UI event handling to the back-end (then server streams partial HTML updates)

Solve Websocket/SSE fragility via rolling http connections and align with "SPA" UX

Right, this is how bidirectional, low-latency communication is achieved via QUIC.

Coordinate traditional request/responses across rolling http connections with a protocol of status metadata (about the request/response) in the header of each rolling connection

The rolling request is used to synchronize the DOM state with the server, while UI events are sent with their dedicated requests (and have separate coordination mechanics, which I will cover later). With HTTP/2+, the overhead of additional and parallel requests is minimal. This approach allows me to achieve better parallelism, support multipart form data as a native payload, and maintain a communication organization that is not too different from the standard.

Node, Beam, Fragment is an architectural improvement in it's own right

At least I believe it is an architectural improvement. 1, 2, and 3 make it possible to perform as expected.

Thanks for your questions!

Hunter Sheridan • Jul 26 • Edited

Thank you for the answers Alex! I understand!

I can imagine quite a lot of time/effort goes into this .. key to the dance:
"That approach requires a more advanced synchronization error correction protocol (because it involves two independent data streams compared to WS). Probably deserves a separate article."

This is important. Everyone is invested in their backend ecosystems.
"If you are curious, "back-end role" in such an approach is not gone, now it is a separate module/lib in your project or private (internal) API you call in a secure server environment."

This is quite a scope of work :-).

Thanks
Hunter

TurboTurtle • Jul 24

really feels like a game-changer. Huge respect for the crazy leap and chasing what you believe in. The industry needs that kind of energy. Good luck!

cmaxm • Jul 25

Great job! I can see a lot of experience, common sense, and erudition. Good luck!
Just first thoughts to share:

Not sure that I understand everything correctly, especially in Node/Beam/Fragment chapter I am a bit lost - a diagram could make it more obvious.
Go is a great choice. Could be a real game changer.
Reminds me Vaadin framework a bit (greetings to Finland). Server state, synchronisation, JS components, etc. From my experience with Vaadin sync surprisingly was not a problem (back then in 2010 it was based on GWT), load balancing with sticky session was all right, but initial bootstrap time and server RAM consumption were problematic. And, yes, release was tricky for active sessions.

Alex • Jul 25

Much appreciated!
I added a detailed flow to clarify the Node/Beam/Fragment section.

Checked out Vaadin; it's an impressive platform, so I'll explore it further for inspiration. I found it amusing that, compared to my thing, it feels like Java compared to Go on multiple levels.

Parag Nandy Roy • Jul 26

This is wild...in the best way..

shinjith • Jul 25

Sounds great! All the best.

Alex • Jul 25

Thanks, that's very important for me to hear.

shinjith • Jul 25

Sure! just signed up for the early access.

I'm willing to contribute to the project in some way, but don't have enough experience in Go, may be I can do something with tooling part or so. Anyways nice start, keep going!

Andriy Ovcharov • Jul 25

Interesting. Thanks for sharing!

Emeka Elo-Chukwuma • Jul 25

Man if it makes you happy it is worth it.

Alex • Jul 25

I hope it will make more people happy.

Oscar • Jul 25

This looks awesome, but jeez, that's a massive leap of faith.

Alex • Jul 25

Thanks. Yeah, I feel the pressure.

Spoiler for the next article: here is a basic code snippet with a counter implementation.

// UI Fragment
type Counter struct {
    // Dynamic element
    node  Node
    // Local State
    count int
}

// Click-handler function
func (c *Counter) handler(ctx context.Context, _ RequestEvent[PointerEvent]) bool {
    c.count += 1
    // Updating the node with new content
    c.node.Update(ctx, c.display())
    // Not done; keep hook active
    return false
}

// Display click count
templ (c *Counter) display() {
    Clicked { c.count } time(s)!
}

// Fragment-render function
templ (c *Counter) Render() {
    // Render dynamic element
    @c.node {
        // Initial content
        Click →
    }
    // Button with an attribute constructor and on-click action
    <button { A(ctx, Click { On: c.handler })... } >
        Click Me!
    </button>
}