We Got to LiveView

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • Paraxial.io - Bot detection and prevention for Elixir/Phoenix applications
  • SonarQube - Static code analysis for 29 languages.
  • Scout APM - Less time debugging, more time building
  • htmx

    </> htmx - high power tools for HTML

    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.

    [0] https://htmx.org/

    [1] https://htmx.org/attributes/hx-ws/

  • 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!

    [0] https://github.com/Glimesh/glimesh.tv/

  • Paraxial.io

    Bot detection and prevention for Elixir/Phoenix applications. Paraxial.io is bot detection and prevention for Elixir/Phoenix applications. Dealing with scrapers, card cracking, or credential stuffing? We take care of that.

  • Absinthe Graphql

    The GraphQL toolkit for Elixir

  • stimulus_reflex

    Build reactive applications with the Rails tooling you already know and love.

    > 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)

    https://docs.stimulusreflex.com/

  • webtransport

    WebTransport is a web API for flexible data transport

    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?

  • fastapi

    FastAPI framework, high performance, easy to learn, fast to code, ready for production

    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.

    [0] https://fastapi.tiangolo.com/

  • surface

    A server-side rendering component library for Phoenix

    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.

    [1] https://github.com/surface-ui/surface

  • SonarQube

    Static code analysis for 29 languages.. Your projects are multi-language. So is SonarQube analysis. Find Bugs, Vulnerabilities, Security Hotspots, and Code Smells so you can release quality code every time. Get started analyzing your projects today for free.

  • porcelain

    Work with external processes like a boss

  • contex

    Charting and graphing library for Elixir

    https://contex-charts.org

    > 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.6.7 + LiveView 0.17.9 ⚡️

    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

  • Stimulus

    A modest JavaScript framework for the HTML you already have

  • Alpine.js

    A rugged, minimal framework for composing JavaScript behavior in your markup.

  • Mercure

    Server-sent live updates: protocol and reference implementation

    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.

  • torch

    A rapid admin generator for Elixir & Phoenix (by mojotech)

    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

  • live-paint

    Demo pixel painting webapp with realtime updates across all connected tabs and browsers

    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...

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts