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?
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.
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."
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.
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.
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!
Spoiler for the next article: here is a basic code snippet with a counter implementation.
// UI FragmenttypeCounterstruct{// Dynamic elementnodeNode// Local Statecountint}// Click-handler functionfunc(c*Counter)handler(ctxcontext.Context,_RequestEvent[PointerEvent])bool{c.count+=1// Updating the node with new contentc.node.Update(ctx,c.display())// Not done; keep hook activereturnfalse}// Display click counttempl(c*Counter)display(){Clicked{c.count}time(s)!}// Fragment-render functiontempl(c*Counter)Render(){// Render dynamic element@c.node{// Initial contentClick→}// Button with an attribute constructor and on-click action<button{A(ctx,Click{On:c.handler})...}>ClickMe!</button>}
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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?
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.
Hi Hunter
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)
Right, this is how bidirectional, low-latency communication is achieved via QUIC.
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.
At least I believe it is an architectural improvement. 1, 2, and 3 make it possible to perform as expected.
Thanks for your questions!
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
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!
Great job! I can see a lot of experience, common sense, and erudition. Good luck!
Just first thoughts to share:
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.
This is wild...in the best way..
Sounds great! All the best.
Thanks, that's very important for me to hear.
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!
Interesting. Thanks for sharing!
Man if it makes you happy it is worth it.
I hope it will make more people happy.
This looks awesome, but jeez, that's a massive leap of faith.
Thanks. Yeah, I feel the pressure.
Spoiler for the next article: here is a basic code snippet with a counter implementation.