Our great sponsors
-
I have never used LiveView, but I'd love to see the web moving towards this kind of interfaces. HTML over the wire is powerful! The deep integration between all the parts (Phoenix, LiveView, the HEEx engine...) is nice, and compile-time template validation looks really cool.
One thing that concerns me about doing everything over WebSockets, is that it seems you now need to keep a connection with every connected client, even if they are not doing any "highly interactive" actions. I think (in most cases) it would be more efficient to do a bunch of AJAX requests to receive those HTML chunks. Now that we have CDNs, HTTP/{2,3}, etc. the benefits of using WebSockets for everything seem less obvious.
This is what HTMX[0] does by default, and then you can use WebSockets[1] if you need it. Another great thing about HTMX is that the backend can be whatever you like, as long as you can handle HTTP requests and return HTML.
In any case, I like both approaches and I would love to see the web development ecosystem moving back to sending HTML over the wire, regardless of the framework.
-
glimesh.tv
Glimesh is a next generation live streaming platform built by the community, for the community.
We use Phoenix and LiveView to power all of our non-video interactions on Glimesh.tv[0] and the immediate out of the box features and performance are unmatched. LiveView allowed us to get a completely real time updating channel where streamers can edit their metadata (game, title, viewer count, etc) and all of the viewers can see it in real time. Not to mention we implemented a distributed chat system that sends message updates in real time to both browser clients and API clients. Both of these features combined amount to less than 1000 lines of code and "just work" across multiple web nodes.
It can be daunting to jump into such a strange world as a LiveView environment may look (Elixir syntax, OTP terminology, etc) but honestly once you dig in deeper, everything just makes sense. LiveView (and HEEx) continue to be very simple to understand abstractions on top of the rock solid OTP platform. It's a joy to build real time applications using it, and I very much appreciate the "developer experience" focus both Chris & Jose have for us Elixir devs!
I'm excited for the launch of Phoenix 1.6 and HEEx is shaping up to be a complete replacement for your traditional SPA + Backend API, and using one consistent language for your full stack really has very freeing & powerful benefits, especially for small teams!
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
> Sync.rb works like this: the browser WebSockets to the server, and as Rails models change, templates get re-rendered on the server and pushed to the client. HTML rendered from the server would sign a tamper-proof subscription into the DOM for clients to listen to over WebSockets. The library provides JavaScript for the browser to run, but sync.rb programmers don't have to write any themselves. All the dynamic behavior is done server-side, in Ruby.
It sounds like Stimulus Reflex is essentially Sync v2 (today's libraries are able to accomplish Chris's original vision)
-
Are you guys looking into the Web Transport protocol for the future? Right now you have to tunnel the websocket connections over http2 and it will probably be the same for http3 afaik.
I know there is this work in progress (https://w3c.github.io/webtransport/) and websockets are probably fine for a long time but sooner or later (unless there is an update to websockets) it will probably be faster to just do normal http requests and listen on server sent events.
What are your thoughts for Liveview for the future? Will it forever stay on websockets or would you be open to change the underlying technology if / when new stuff becomes available?
-
Hi, really excited about the new release - Heex and Esbuild support is fantastic.
Do you think it is possible for newcomers to pick up Phoenix and at the same time learn how frameworks work? For example, FastAPI [0] is a widely extensive Python framework yet its documentation essentially is just a long tutorial which explains basic web-development concepts while teaching its core. OTOH, almost all Phoenix learning material I have come across so far are targeted to experienced devs (especially Rails).
I really love that Phoenix is opinionated but I feel like there should be some ways to learn about the rationale behind those choices, without having 10 years of development intuition.
-
I totally get the "Am I doing this the right way?" feeling, especially coming from Rails where everything was so opinionated and wanting to stay idiomatic.
Phoenix, while it does have opinions, is far less opinionated in the sense that it doesn't do it darndest to force you into certain conventions (for example, if your module name doesn't match your file name, Phoenix won't complain). Its generators do try and push you toward using good DDD practices (which is my opinion is a GREAT thing), but of course the generators are completely optional.
I don't have experience writing large LiveView apps but I would say that if you are familiar with any component-based frameworks (like React), I would take a look at SurfaceUI[1]. It simplifies a few "gotchas" in LiveView (though I would say they are very minor gotchas and worth learning about at some point) and gives you a component-rendering syntax more like React. Once you get going, you'll learn that LiveView doesn't have all the headaches that come with bigger React apps (like having to memoize functions or comparing props to avoid a re-render and whatnot). The recent release candidate for Phoenix 1.6 has made strides for a cleaner component syntax, but if you're having trouble with LiveView, Surface might bring some familiarity.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
> What’s the story in Phoenix and Elixir land for handling external shell processes from web requests
Great story here thru erlang ports. I'm a big fan of the Porcelain library which wraps ports with some nice features on top:
-
phoenix-liveview-counter-tutorial
🤯 beginners tutorial building a real time counter in Phoenix 1.7.7 + LiveView 0.19 ⚡️ Learn the fundamentals from first principals so you can make something amazing! 🚀
This is a pretty good liveview tutorial: https://github.com/dwyl/phoenix-liveview-counter-tutorial
We also have a hiring project that's designed to ease people in to Phoenix + LiveView. We extracted this from a real app and tried to make it as simple as possible to work on: https://github.com/fly-hiring/phoenix-full-stack-work-sample
-
This is a pretty good liveview tutorial: https://github.com/dwyl/phoenix-liveview-counter-tutorial
We also have a hiring project that's designed to ease people in to Phoenix + LiveView. We extracted this from a real app and tried to make it as simple as possible to work on: https://github.com/fly-hiring/phoenix-full-stack-work-sample
-
turbo
The speed of a single-page web application without having to write any JavaScript (by hotwired)
-
-
-
The Symfony community has been going for Server Sent Events rather than websockets, via https://mercure.rocks/. I don't understand the benefit when every other framework wanting interactivity is still going for websockets.
As you say SSE seem more suitable for notifications rather than bi-directional communication.
-
There are good libraries around authentication and authorization. There was at one point an analogue to ActiveAdmin, but it looks to be a dead project now. I generally discourage the use of those kinds of interfaces but if you must, this is more current: https://github.com/mojotech/torch
-
A better balance would be to build the webapp in hybrid mode, some logic can be run by client-side javascript. Only the event handlers that rely on data from the server needed to be sent to the server.
In this pixel paint demo, the state and reaction of "changing the pen color" can happens locally: https://github.com/beenotung/live-paint/blob/master/server/a...
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
