Replies: 2 comments 2 replies
|
I would recommend using DataStar since LiveView is already associated with Phoenix and Websockets. So having an alternative using SSE instead of websockets is a nice option to have that could make this framework be something to consider when making new applications. SSE is a technology for realtime events available since 2006, but most solutions went with websockets. Also consider that using SSE is not bound to Datastar, is a simple protocol so any JS frontend can be used if they follow the protocol.
|
1 reply
|
Lines of Code in Lines of Code in Lines of Code in |
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
TL;DR: I am rethinking the core engine of Nex. Should I stick to the lightweight HTMX roots, or embrace the power of Phoenix LiveView?
Hey everyone! π
As I continue to build Nex (aiming to be the Next.js for Elixir), I've hit a major architectural crossroad. In the spirit of Building in Public, I want to share my internal debate with you and ask for your feedback.
π§© Where I Am Now
Currently, Nex is designed as a micro-framework powered by
Plug,Bandit, andHTMX.I built a custom state management system (
Nex.Store) using ETS to give you "stateful" components over stateless HTTP.It works like this:
It's simple, lightweight, and efficient. But...
π€ The Friction Point
While building apps with Nex, I noticed a mental gap.
Coming from React or Phoenix LiveView, I am used to a declarative model: "Change the state, and the UI updates automatically."
In the current Nex implementation, you have to explicitly tell the framework what HTML to send back every time.
<button>fragment.<ul>fragment.It feels a bit... manual. And syncing the client-side DOM with the server-side state can get tricky for complex UIs.
π‘ The Idea: "Nex as a LiveView Wrapper"
I am considering a pivot: Making Phoenix LiveView the default engine for Nex.
Imagine Nex becoming an opinionated, zero-config wrapper around LiveView.
src/pages/users/[id].ex).router.ex, noapp.js, noendpoint.ex).The Trade-off
phoenix), higher server memory usage (WebSockets).π£οΈ I Need Your Voice
I am building this for YOU. Which direction excites you more?
Please drop a comment below. Your feedback will directly shape the v0.3.0 release! π
All reactions