I’m excited to share Nex, a web framework I’ve been building for the past few months. It’s designed for indie hackers, startups, and anyone who wants to ship web applications fast without enterprise complexity.
The philosophy:
Nex embraces simplicity and convention over configuration. It’s built for:
Internal tools & dashboards – Admin panels, data dashboards
Real-time applications – Live dashboards, chat, streaming with SSE
Server-side rendering done right – Modern web apps without JavaScript overhead
What makes it different:
File-based routing – No configuration. Drop a file in src/pages/, get a route.
HTMX-first – Build interactive UIs with server-side rendering. No JavaScript framework needed.
Hot reload – Instant feedback while developing via WebSocket.
Real-time ready – Built-in Server-Sent Events for streaming data.
Zero config – Works out of the box with sensible defaults.
Production-ready – Docker included, deploy to Railway/Fly.io/Render in minutes.
Quick example:
defmodule MyApp.Pages.Todos do
use Nex.Page
def mount(_params) do
%{todos: fetch_todos()}
end
def render(assigns) do
~H"""
<h1>My Todos</h1>
<form hx-post="/add_todo" hx-target="#todos" hx-swap="beforeend">
<input type="text" name="title" required />
<button>Add</button>
</form>
<ul id="todos">
<li :for={todo <- @todos}>{todo.title}</li>
</ul>
"""
end
def add_todo(%{"title" => title}) do
todo = create_todo(title)
~H"<li>{@todo.title}</li>"
end
end
Glad to see this, I think we need more web frameworks!
WRT the above, my understanding is that these “hypermedia frameworks” (htmx maintains a list) are generally designed to interop with pretty much any standard backend, so you shouldn’t really have to worry about picking a winner.
I’ve been waiting for something like this for a while. Great initiative! (I really wish Phoenix would have a less boilerplate code approach, and this is a great foundation)
IMO it’s all about the learning curve. I suppose someone coming over from Next.js would prefer Nex’s same file-based routing concept. As for HTMX, I vote LiveView
LiveView’s great (it keeps the roof over my head) but it’s not a one-size-fits-all (nor is any framework, though LiveView is a little more honest about that).
And I would say that file-based routing would be familiar to anyone who started back in the 90s writing spaghetti PHP/ASP/etc for who HTMX also feels familiar, no need to bring Next into the discussion
Kind of. They do similar things in different ways so you’d still need to rewrite things if you wanted to switch from one to the other.
Comparing solely htmx to datastar, htmx is less capable out of the box. Datastar = htmx + sse + alpine. All in a smaller footprint. I also think their default to fat morph is a nice DX win. Feels a lot more declarative.
Objectively I don’t see a good reason to chose htmx over Datastar but I can understand the subjective “I’m used to htmx”.
I also think they’re doing some interesting things with their web component lib, Rocket.
Oh yeah, I just meant this framework doesn’t need to choose a winner. Of course as a dev you still have to pick
As you know I have a strong preference for React-likes (a category in which I include LiveView even if it’s not quite there) so my opinion matters little here, but I’d probably choose HTMX solely on vibes. Datastar is open-core and the database world has taught me to be extremely skeptical of such things. Of course there are exceptions like Oban, but they are an exception because they have built community trust over a long period of time.
But yeah, you can always use React itself with Phoenix or I’m sure with Nex here as well. I am not particularly interested in React proper, though, only its model. LiveView’s model is similar except that it runs on the server and its design is not quite as careful.
I have grown quite wary of this layering of frameworks on top of frameworks without anyone actually understanding why things are the way they are underneath. That’s how you end up with accidental complexity, because those using and even designing the tools don’t remember what it was they were supposed to be doing.
There is something to be said for minimalism (and I hope the OP here is able to pull it off), but achieving a minimal design is a very careful and effortful process. React right after Fiber/Hooks is a good example of a design that was refined to near perfection over a long period of time. Since then idk what they’ve been up to and I don’t really care.
I briefly looked at the article. Is he trying to say that because modern “views” are highly interactive, we shall think there’s an MVC within MVC and get to a conclusion that the term itself makes no sense? It kinda does make sense to me, because I always think of MVC from a server-first apps perspective. A controller is a server action/endpoint to me. A model is the data that’s being transferred to views. A view is responsible for presenting that data to the end user and leaves them a choice to call other controllers.
The author’s writing style lends itself to deep insights that only reveal themselves after weeks to months of repeated readings (at least in my experience, and I have seen others suggest the same). I would not recommend skimming his work as you are unlikely to glean much of value that way.
In this case, though, I was just making a joke about how MVC generally does not mean much of anything at all, a point underscored somewhere in the article.
Rapid development – Ship features, not prototypes
Indie hackers & startups – Build profitable products
Internal tools & dashboards – Admin panels, data dashboards
Real-time applications – Live dashboards, chat, streaming with SSE
Server-side rendering done right – Modern web apps without JavaScript overhead
We’re all
