Getting to 1.0 of LV is huge and it finally happened!
Next thing is LiveView Native getting support for android and I'm never leaving this ecosystem ever. (at least for web/mobile dev heh)
I’ve been using LiveView for years now and couldn’t be happier with it. It’s a joy to work with, and has reinvigorated my love of web development. I’m so blazingly productive in LV it’s unreal.
I try not to be too self-promoey on HN but this feels like as good as time as any: if this v1.0.0 release makes you want to finally learn LiveView, I humbly recommend my own course at http://learnphoenixliveview.com. Get 20% off with the code HACKERNEWS.
I struggled to find good learning materials when I was starting out, so I’ve tried to rectify that problem. I hope that I can get more people over the initial learning curve because as far as I’m concerned, the more people get familiar with this awesome framework, the more everybody wins.
- not affiliated, just a humble enjoyer of Arrowsmith Labs materials
Just curious to know — was Pragmatic Studio not available or not affordable for you at that time? I’ve seen them teaching these for many years now. Pragmatic Programmers (the book publisher) has also had many books on these over the years (probably not as early as when Pragmatic Studio had online courses).
Thanks
https://github.com/phoenixframework/phoenix_live_view/blob/m...
I'd love to get some commentary from any active users on tradeoffs re: adopting tech like LiveView vs the community size and scale of JS land.
For example, JS land benefits massively from libraries like ProseMirror or even any of the more advanced CRDT libraries like Loro or Automerge. How about the AI story?
Is there a clear path to adopting this JS-based tech? Is it not needed? Would love to get a better understanding of the tradeoffs from folks who live in both worlds.
The AI story is mostly centered around the Nx project: https://github.com/elixir-nx/
Nevermind front end though, the main course is Erlang/Elixir's concise, functional, concurrency paradigm that feels more discovered than invented. The default structures they provide for thinking about message-passing actors are so much easier than tangled webs of async functions. This means CRDTs, calling out to APIs, running jobs in other languages, realtime coms, all go very well in Elixir.
I think Actors are a paradigm shift somewhat akin to garbage collection. Increasingly complex programs demanded we abstract away memory management to stay sane, knowing we'd drop down to memory manage when needed. In this web-heavy world, we abstract into tiny statefull services (actors) to stay sane, knowing we'll drop down to sequential languages when needed.
There's a langchain implementation that's fairly mature and definitely in production use (I saw the authors handle above actually :D ). Langgraph-style libraries exist (there's one called Magus that I've used) but I think that's where there could be some more efforts. Although it's important to note that building something comparable to langgraph isn't too hard in Elixir with its process model, and most Elixir devs could probably do it, but unfortunately that's not obvious to your average person searching "langgraph implementation in Elixir". There's no langsmith integration but the telemetry implementation in Erlang and Elixir is really nice so once some patterns around running chains and graphs emerge publicly (there's a few companies that I'd bet have private repos implementing their own equivalents of langgraph) I imagine integrating to langsmith would go pretty quick
So you can have local-first sync in a Phoenix app using Electric. And you can use Electric to sync data into a LiveView using Phoenix.Streams, which is a very natural fit.
We have a couple of example apps showing things in action:
- https://github.com/electric-sql/electric/tree/main/examples/... - https://github.com/electric-sql/electric/tree/main/examples/...
Pros: you do not need access to the extensive scale of the JS ecosystem. And you will not need to write as much JS, if at all.
If you do not have Stockholm Syndrome for Javascript, just switch to Liveview. And Erlang/Elixir is just a comfy yet secure platform to build serious apps.
- code generation makes for an extremely productive experience that makes standing up an actually-useful application very fast
- Elixir is a great language, especially for the web, and using it to render the frontend feels like having the full power of the language plus the simplicity of HTML (with little/no writing JavaScript)
- it's extremely efficient since only tiny changes are sent over the WebSocket when data is updated on the server
- you're already using WebSockets, so adding any kind of real-time functionality is very easy (chat, notifications, game state)
We've hit some bugs and gotchas over the years leading up to this 1.0 release, but it has long felt like a stable, well-built library that keeps our codebases simple and maintainable, which lets you move fast.
Congratulations to Chris, Jose, and all the other wonderful contributors!
To your point though, LiveView indeed requires a semi reliable connection for reasonable UX, but there is a ton of nuance to this topic that is usually missed from the discussions. Apps should more or less degrade similarly to SPA's that are going to the server. For robust UX on unreliable connections you need offline/local-first SPAs, and in my experience the vast majority of SPAs do not handle this. Failing that, most SPA frameworks seem to place the optimistic UI/rollback concerns on the developer. In fact most degrade quite poorly on bad connections. It goes against folks intuition, but even with degraded connections LiveView does better than people imagine because we have the existing connection established and don't need to go through the overheard of reestablishing things, and our payloads are generally smaller.
Annecdata of me driving through the mountains with spotty cell tethering and browsing facebook vs a LiveView app: https://x.com/chris_mccord/status/1799100642654638543/video/...
In case folks missed it, buried in the blog post is a new installer that lets folks try out elixir/phoenix in seconds. It installs elixir and generates a new phoenix project from a single command:
osx/linux:
$ curl https://new.phoenixframework.org/yourappname | sh
> curl.exe -fsSO https://new.phoenixframework.org/app.bat; .\app.bat
edit: You can see it in action here: https://x.com/chris_mccord/status/1864067247255306332
Of course we also have non |sh installation guides if that's what you're after: https://hexdocs.pm/phoenix/installation.html
Now that this is out, I'm looking forward to put together a few new demos. What would folks like to see? Happy hacking!
I don't do much (any?) web development these days, but LiveView gave me—a backend dev—the confidence to spin up my own web apps with classy UIs. Thank you so much for all your work!
You can thank Steffen from the Phoenix team :)
Selfish demo idea: Bi-directional cursor based infinite pagination with largish datasets with state managed in the url and streaming updates that change the order of the results. Like some kind of soft realtime leaderboard.
With long render times (morphdom bench on large sets isn't great as far as I can tell) it's hard to escape the jank. Particularly on slow connections.
Browsers aren’t as much the issue as they’ve been in the past, but I’ve hit snags with proxies, old servers, etc.
But curious what current art is re: performance optimizations between frontend and backend. Or is it simply page indices?
Here's the fork I created at the time to work around some of these issues: https://github.com/1player/paginator
https://www.youtube.com/watch?v=FADQAnq0RpA&t=2322s
This demo doesn't update the URL to keep state (but push_patch would make that trivial). I'll think about more complex examples for cursor pagination, but the solution to massive collections (thousands of entries) is going to be stream + limit
So in that demo, I'm curious how smooth the scroll would be when adding latency via the debug tools in the browser console. Even with some padding and fiddling with limi ts I've had trouble getting it to be an enjoyable experience. Just bouncy if that makes sense. More frustrating on mobile than desktop. With localhost latency it's great.
I'm thinking it may just need a hook to preload rows or something of that nature to provide space for the render. Though my CSS could very well be wrong.
Its extremely easy to customize and build a reusable paginated table component
One video or demo in particular that had some functionality I'd love to see in LiveView (or demo on how to do it) is Optimistic UI and Optimistic Add and Drag and Drop (the last three videos in the playlist).
1. https://www.youtube.com/playlist?list=PLXoynULbYuED9b2k5LS44...
Congrats to you and everyone else who made it happen!
sh: line 1: Application: command not found
Application name must start with a letter and have only lowercase letters, numbers and underscore
downloading https://github.com/elixir-lang/elixir/releases/download/v1.17.3/elixir-otp-27.zip
fedora is not supported
For fedora, Elixir has instructions on their site:
sudo dnf install elixir erlang
I'd love to make it work for elixir install if we can though :)
https://asdf-vm.com/guide/getting-started.html https://github.com/asdf-vm/asdf-erlang https://github.com/asdf-vm/asdf-elixir
Slightly more ceremony than curl | sh, but a good tool to have.
With Liveview the network gap between the client and the server dissolves. It's just magical.
Thank you Cris, Jose and the whole team for making the lives of developers easier.
I'm a full time Elixir developer since 2016 and it's still my favourite programming environment. I've recently had a client notice how smooth the dashboard I threw together in an hour feels, and he doesn't know that I have not written a single line of Javascript to build it.
Thank you!
URL: https://www.phoenixframework.org/blog/the-road-to-2-million-...
Many thanks for all the years of dedication to Phoenix and value you've given to developers around the world.
OT: any thought about updating the 9-year old perf benchmark blog post? And is bandit now recommended over cowboy?
https://www.phoenixframework.org/blog/the-road-to-2-million-...
What JS solution/approach would you recommend to use with LiveView for pure client-side stuff?
Although I sadly stopped using Elixir/Phoenix/LV for new projects I still have some in production that I was waiting for the 1.0 release to update.
Elixir is terrific, never feel like the language is slowing me down whatsoever.
The tools you need are unsurprising and boringly in your face. Oban background jobs, auth, encryption, the works.
The tools for your day to day are polished and immediately useful. mix ecto.reset, seeds.exs, mix test, mix format, mix compile --force to see warnings. Just everything right there in your fingertips and works unsurprisingly.
Performance to the point where you won't ever really worry about it until you've made it big. Literally using 275MB right now and chilling. Sub 100ms response times.
All this to say, give Elixir and Phoenix a try. It's been the best decision of my professional career to try it out in 2016.
Does this mean you are getting lots of work with it?
But LiveView just ignores these problems and does full stack without the heavy costs. Elixir/Phoenix/LiveView is a tool-set for maximizing how far one dev can go.
You'd think this would be a selling point in many companies: to have less devs ship more features but those heavy SPA stacks let middle managers rationalize hiring bigger teams. LiveView is for shipping - not stalling.
Of course, if your JS app isn’t server-based and can run non-trivial logic on the client, then it’s going to work better than a LiveView app.
This is how Firestore works, for example
https://liveview-svelte-pwa.fly.dev/
It's a toy app obviously, but I was impressed with the potential of so many technologies being integrated with each other (It even has Svelte in the mix via LiveSvelte[1]).
I don’t really have that with a traditional SPA, since the view is “dead”. Of course, interactions might be slow, but I can at least still browse the data already on the screen.
You can in theory compile part of your elixir app to wasm, run it on the client, threat is a just another process and mutate the state of live view from there. It's a question of fitting all the pieces of tooling together
[1] https://replicache.dev [2] https://hexdocs.pm/phoenix_live_view/Phoenix.LiveComponent.h...
I think this is my favourite piece of tech. And a lot of success stories, but would also love to hear if anyone ran into huge problems and had to ditch it? There are some footguns but overall I loved writing apps with LiveView, feels like magic.
No replacing servers to push code changes, no telling people to logout & back in to see the changes. Crazy.
1) every server build has a unique version ID
2) the version ID is embedded in the page on the first page load
3) on every htmx request (it can be done with a bit of HTMX configuration) the embedded version ID is sent to the server as a special HTTP header
4) a middleware on the server always compares the version IDs, and if they don't match, sends back a special "reload" HTTP response header
5) on each response, htmx checks if the reload header is present, and if the user navigates to a logically different page (which is usually part of SPA), then a full page reload happens (I have a few heuristics to tell if it's a logically different page or just a component update on a page) - to avoid losing state when the user is editing something (i.e. not just navigating)
6) all assets are versioned on full page render, so the full page reload triggers CSS/JS update
And it works on all pages automatically with 100 lines of additional JS on top of htmx.
Differences from LiveView:
1) each HTMX request still has all the overhead of auth checks
2) UI updates are not immediate, but only when the user attempts to navigate in the SPA (can be problematic if partials from different server builds are mixed on the page before a full reload, and they're not compatible)
3) UI updates trigger full page reloads which are noticeable by the user but generally it's OK because releases don't happen very often and critical user input isn't lost
I built my (unfortunately) failed startup using LiveView for ~18 months. It was actually really good to work with and a great product experience.
I ended up integrating React into it as well for some particularly complex / mature libraries (react-grid-layout, WYSIWYG editor). Pretty seamless connection to backend LiveViews, and I tried to keep everything in LV as possible.
The biggest difficulty was hitting problems that I had solved 50 times in React, and had to solve from-scratch in LiveView. Once I figured out a problem, I could re-use it easily.
I know there are paradigms to handle that now, although the details get complex in practice. For example, the idea of a "portal" in react is actually really important for layering modals and popups properly, but it can be difficult in LiveView.
The biggest single challenge I remember hitting was dynamic recursive forms (for example a logic builder). It took a lot of effort to get right.
For anyone who doesn't remember, this is the keynote at ElixirConf EU in Prague where Chris introduced LiveView to the community: https://www.youtube.com/watch?v=8xJzHq8ru0M
LiveView is one of those things that almost seems like it was "discovered" rather than invented. Like, in the early days Phoenix was just a "better rails", but it had this neat little "channels" functionality that Rails couldn't really manage because of ruby limitations. But "channels" gradually got fleshed out and then lo and behold an early version of LiveView was built on it. But while LiveViews were amazing, they were kind of disjointed with the more standard static views (or "dead" views as the community often calls them, which I really dislike). And over time things were updated so you could share code between live and static views, finally culminating in Phoenix 1.7 which has a whole new layout and philosophy on building web apps.
Phoenix 1.7 feels radically different to me from everything before, and a clean break from its Rails tradition. But it all kind of got there incrementally in ways that make sense. It feels like as soon as Elixir was created, this new way of organizing and building web apps was there all along in the rock, it just took a decade of chipping away at it to reveal.
A remaining opportunity is a beautiful component library like a shadcn. You can dunk on the complexity of JavaScript, but every choice has tradeoffs and a huge advantage of that ecosystem is you have amazing front end engineers doing beautiful, accessible UI work.
Just look at the demos of LiveView on their own site. Pretty rough by comparison.
It’s not to take away from the effort. Truly enjoyable to develop in. Just to point out there is an even higher level to reach next.
We list half a dozen in the readme, with https://fluxonui.com/ being the most recent, and fully accessible. There is also one inspired by shadcn
https://github.com/phoenixframework/phoenix_live_view?tab=re...
Any plan to support native iOS & Android? I will love to consider Liveview as an alternative to our Ionic+Capacitor setup
DockYard has built out LiveView Native which does a wild React Native style based on the LiveView server-rendered model.
I can attest to its JS interoperability. I have a project that streams data realtime into a liveview page that uses a combination of ag-grid, maplibre-gl, vega+lite, and Google's model-viewer all at once. All it takes is a little bit of JS plumbing to handle create and updates.
Its all done using phx-hook https://hexdocs.pm/phoenix_live_view/js-interop.html#client-... . While the documentation makes it look a bit more fancy, it is just a JS object with mounted() function. I set up my columnDefs and gridOptions in that function, and add the handleEvent() callbacks that are where I get data from the elixir side using send_update/3. Ag-grids vanilla JS documentation has been very helpful for how to use it without the benefit of react/vue,
Using Elixir from Gleam can be troublesome due to Elixir macros. I find macros quite important to the Elixir ecosystem but since they don't work in Erlang (and Gleam) they have some drawbacks in terms of of interop.
Because it is so ludicrously easy to send an asynchronous event to a user's browser from the backend, it helps avoid the temptation to synchronously wait in the browser for the backend to finish a long process, which helps avoid creating big chains of synchronous calls on the backend which can cause so many issues.
I've implemented similar designs for several projects; but I've been piggybacking updates on regular http requests, clicking a button etc.
I just put the page state in a LIFO with a big enough max limit on the server, clearing out anything older.
You do have the limitation of being stuck with the sever that answered the original request, but erlang should be a good platform to fix that.
I'm currently a full stack web dev using functional typescript, but leaning into Elixir world.
I make 100k more or less in Europe as an independent contractor/freelancer, I'd be happy to jump on Elixir/LV but not at a pay cut.