Phoenix creator here – excited to finally have shipped this! Happy to answer any elixir/phoenix/liveview questions.
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
Thank you Chris. Though it is clear that the similarity between Elixir and Ruby is only superficial, I cannot refrain from seeing your and José's work as a reflection and evolution of the work started with Ruby and Rails. Which includes the friendly community, the pragmatism to build solid software for people that need to ship, and the excellent stewardship of the Elixir and Phoenix projects.
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.
Application name must start with a letter and have only lowercase letters, numbers and underscore
So I changed to test_elixir_app, and got this output:
downloading https://github.com/elixir-lang/elixir/releases/download/v1.17.3/elixir-otp-27.zip
fedora is not supported
This was a spur of the moment thing, so maybe I'll try from an Ubuntu machine or something another time, but the friction was unfortunate. Grats on the launch though, the demo gif of using the project installer looked great.
Thank you for everything!! I've shipped quite a few successful apps to clients on Phoenix ever since the beginning, and am about to launch a startup on it. It's truly changed my career more than maybe any other library.
Congrats on 1.0 and really appreciate all the work involved. One thing that I'd love to see is more demos around optimistic UI's. It's a lot of work, but Ryan Florence from Remix did a whole playlist [1] around recreating Trello in Remix.
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).
I need to polish the code, but here's more advanced optimistic UI example added to an existing demo app (TodoTrek). It uses recent LiveView features that allows any client code to hook into the full optimistic UI/server sync primitives that are built into LV:
Congratulations Chris! I started using LiveView shortly after the beta was released. A few of my coworkers were really excited to try it out, so I was tasked with recreating our company's login page with LiveView. Needless to say, there were… ahem… growing pains—but it was super fun to encounter a problem and then just have it go away the following week because of some new update to LiveView.
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!
Thank you and the team for your hard work, and congratulations on the release!
Suggestions for Demos:
1.Charting Libraries Integration
There’s currently a lack of demos showcasing LiveView integrated with powerful charting libraries like Apache ECharts, Plot, Chart.js, etc. A demo of a LiveView-powered dashboard using one of these libraries, connected to a database like SQLite (for simplicity) or DuckDB (for speed and demonstrating integrations beyond Ecto-native DBs), would be fantastic.
Emphasizes interactivity: For example, demonstrate how a server-based LiveView can handle actions such as mouse hover on a chart to update tooltips/labels, click-and-zoom interactions, or connected charts with brush functionality.
2.UI Component Libraries
A demo showcasing robust integration with UI component libraries would also be valuable. Features like tables with pagination, sorting, filtering, and autocomplete/typeahead functionality within modals could be a strong focus.
I’d suggest leveraging lightweight libraries like Flowbite or Preline, as they integrate seamlessly with Phoenix and rely on almost pure HTML and Tailwind for styling.
For additional inspiration on speedy charting libraries, this resource might be useful:
Congrats! Been running a startup off only liveview for about a year as a solo dev and it's been wonderful. Appreciate the work you all do.
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.
Will keep this in mind! My ElixirConfEU keynote just used limit/offset pagination, but shows how easy it is to do bidirectional infinite pagination. Streams allows you to keep a virtualized infinite list in the DOM without keeping the giant collection around on either client or server, example:
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
Congrats to you and the rest of the team on the big milestone accomplishment. A very cool demo would be a retake on your “road to 2 million web socket connections” but now leveraging LiveView.
I wonder if it would be possible to make a Phoenix LiveView "Live" that runs in the browser for testing similar to Wordpress Playground: https://wordpress.org/playground/
We've built many production apps using LiveView. It has some limitations inherent to its design, namely the need to have a semi-reliable WebSocket connection to be able to effectively use the app, but with this tradeoff come a number of advantages:
- 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)
Because of the separation of concerns by convention (i.e. keeping business logic in Contexts), it's also a very viable pathway to build a webapp using LiveView first, and serve an API once you need other types of clients (native apps, API consumers) with minimal changes. Ecto is also great to use for validations, and having that available for "frontend" code is a pleasure. It's also great to be able to have backend and frontend tests in Elixir.
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!
Thanks! Love to hear it! Note that LiveView also fully works on the LongPoll transport (which is enabled by default), and we have automatic fallback to longpoll support if websocket fails for whatever reason. So even in the case of obscure websocket issues (like some "corporate proxies" doing weird things like allowing the 101 websocket upgrade then just dropping things into the ether), things should be good. In my experience 1-2% of traffic seems to have websocket issues today for the production apps I work on.
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.
Need is such a strong word. I use LV mainly over long polling at the moment, only drawback is the whining about the client being unable to establish a WebSocket connection in the JS console.
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.
Your course has been fantastic to work through, please keep up the great work (also saw you just launched a companion deep-dive on Phoenix forms, congrats!)
- not affiliated, just a humble enjoyer of Arrowsmith Labs materials
> I struggled to find good learning materials when I was starting out, so I’ve tried to rectify that problem.
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).
Most expensive part of the typical web app is the coordination cost between front and backend devs. Thus the rational to have 1 dev implement full stack. But the trade-off for coordination costs are heavy context switching and knowledge costs to know both ends. Neither option is very ideal and most companies have accepted the coordination costs.
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.
Forcing frontend and backend into the same codebase and coupling them together is excellent. I think it helps avoid creating silos of frontend vs backend devs. I'm being dead serious here, having actual impediments to splitting the stack vertically is good.
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.
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.
It varies. Literally everything from how modals work, notifications, etc. all had to be written. The things that I take for granted in my React app were fairly complex to figure out.
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.
Congratulations to the team and a tremendously big warm hug for creating something that makes my professional life easier and joyful.
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.
Readit News
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:
windows powershell: You can visit those url's directly to see what the scripts do. It extends the official elixir prebuilt installers: https://elixir-lang.org/install.sh and https://elixir-lang.org/install.batedit: 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'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!
For fedora, Elixir has instructions on their site:
https://elixir-lang.org/install.htmlI'd love to make it work for elixir install if we can though :)
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-...
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...
https://x.com/chris_mccord/status/1864160634394325038
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 :)
Suggestions for Demos:
1.Charting Libraries Integration
There’s currently a lack of demos showcasing LiveView integrated with powerful charting libraries like Apache ECharts, Plot, Chart.js, etc. A demo of a LiveView-powered dashboard using one of these libraries, connected to a database like SQLite (for simplicity) or DuckDB (for speed and demonstrating integrations beyond Ecto-native DBs), would be fantastic.
Emphasizes interactivity: For example, demonstrate how a server-based LiveView can handle actions such as mouse hover on a chart to update tooltips/labels, click-and-zoom interactions, or connected charts with brush functionality.
2.UI Component Libraries
A demo showcasing robust integration with UI component libraries would also be valuable. Features like tables with pagination, sorting, filtering, and autocomplete/typeahead functionality within modals could be a strong focus.
I’d suggest leveraging lightweight libraries like Flowbite or Preline, as they integrate seamlessly with Phoenix and rely on almost pure HTML and Tailwind for styling.
For additional inspiration on speedy charting libraries, this resource might be useful:
https://github.com/leeoniya/uPlot
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.
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
Its extremely easy to customize and build a reusable paginated table component
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.
URL: https://www.phoenixframework.org/blog/the-road-to-2-million-...
Congrats to you and everyone else who made it happen!
What JS solution/approach would you recommend to use with LiveView for pure client-side stuff?
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/...
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
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.
I think you meant rationale
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.
Deleted Comment
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.
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?