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.
It supports most OSes rather nicely, check the docs for a long list of config options. It creates a local package store and configures your user's path for it, each tool is managed with a custom plugin that IME works flawlessly and versions are handled better than anything else I've ever used. It's the only way I'll install Golang or NodeJS lately, and I had good luck with it for Java too.
Ah cool, maybe I'll check it out someday. JVM isn't a huge part of my daily work though so I'm pretty happy having it managed the same way as everything else for now. I like the intuitive simplicity of a .tool-versions file in a repo that supports a huge variety of tools.
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:
"Phoenix" is misspelled in the title of the Atom feed. Sorry for reporting this here, I looked for a repository to open a fix PR but couldn't find one, the previous Phoenix site repo is archived.
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
Thanks! That is the approach I took, though I believe reordering rows requires a reset.
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.
flop_phoenix is great. If it lacks anything maybe it'd be great to just enhance it instead of building anything new. The author also has cursor based functionality
If you do limit/offset on database side, page number is enough. Though this doesn't work well for bigger page numbers. There's other ways to do pagination, e.g. with "cursors", where cursor is simply id of last record on previous page. SQL query is very efficient, but jumping to page X is impossible. In this scenario storing cursors for past pages is needed
Careful that this library last I used it (2020 or so) used a particularly insecure encoding of the cursor that basically allows remote execution. Not sure if they ever addressed it.
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.
Something I love about LiveView that is not mentioned often I think is how easy it makes full stack asynchronous processes.
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 found this with React-Router/Remix too. I really like their Action/Fetcher model, it's a great way to simplify communication with the backend (or with client-side fetch requests). But as soon as you introduce a long-running task and you want some way to inform the user about progress or provide partial results, you're on your own.
Congratulations to the team!! I've been following for some time and love a good DX story.
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.
It's tough because LiveView is really just the dessert at the Elixir dining hall-- you can't live off of dessert. It's (at least) an order of magnitude smaller an ecosystem than React and the like, and while average library quality is very high, you won't find ready-made solutions to all your use cases like you do in those big front end ecosystems. JS and LiveView do interoperate surprisingly well, so ProseMirror isn't off the table, but I still think there are important benefits in the big front-end ecosystems.
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.
Cons: you do not have access to the extensive scale of the JS ecosystem.
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.
Automerge wise, there's a ton of effort behind ElectricSQL which is written in Elixir and can also be run as part of an Elixir app, so you can get a lot of the same benefits of local first clients, afaict.
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:
So much is right about LiveView. Thank you for all the work.
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.
Thanks! This kind of thing was lacking for some time, and with the HEEx engine + function components released a couple years ago, we laid the groundwork for extensible component libs, and the community has put out some great options.
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
LiveView is super exciting and extremely productive developer experience. One thing that I hope future versions can help address is what I call the "elevator" problem, in that if I'm using a LiveView app on an elevator (or in my case at Costco), it becomes unusable as the connection gets too flakey. While I get offline support will never happen, maybe better support for unreliable connections would be fantastic, though I get how that could be against the ethos of what LiveView is trying to do.
I haven't had bandwidth to explore the implementation deeply yet, but this seems almost too relevant:
"Working in Elevators: Offline-Enabled Realtime Apps with LiveView, Svelte, & Y.js"
Yes it would, it’s just not as noticeable in my experience. For example, I have a Todo app with my shopping list. Every time I unlock my phone to look at it, I need to wait for the socket to reconnect. Either I lost it due to poor reception, or my mobile browser killed the socket connection (but not the tab process).
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.
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]).
Agreed! I am hopeful that future versions might help address these challenges at the framework level. It’s the Achilles heel to LiveView. As soon as the connection gets unreliable or has some latency a lot of the magic goes away. Most of the time the productivity boost from working in LiveView more than makes up for it, though.
I'm grossly over simplifying but I've always thought a cut down version of Replicache[1] functionality would be an amazing logical progression for LiveView. With Phoenix.Component[2] introducing attributes it's perhaps closer to being feasible.
There’s more support for doing some various JS events locally without waiting for the server. It also improves the offline connection support as well AFAICT. The `JS.push` stuff was new to me and makes it easy to do simple functionality like switching tabs without needing to wait for the server, or for the server to keep that state at all.
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
Well, we've had a bit of a set back on the Jetpack client. Unfortunately the Jetpack developer just moved on to another position. The client is nearly ready but kind of a kick in the pants to have to find someone new right now.
Thank you Chris and the Phoenix team for all your amazing work! I’ve been using LiveView in production since only a few months after the first version was released in 2019 and it’s been fantastic from the very beginning and a joy to develop with :-)
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
6 years, what a journey. Still remember these first demos :)
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.
LiveView has been a pleasure to work with, I jumped on the train only recently with a personal project, and once you get the hang of it, it feels like absolute magic.
That’s exciting! Is there a summary of what’s new in 1.0 somewhere? Usually the version announcements contain an overview of the most important changes, but this one is more of a retrospective and general overview apparently.
We are very happy with Elixir and Phoenix at Felt and have multiple internal apps built via LiveView, which I'm confident would take weeks more to build with anything else. Congrats to the team!
Has anyone tried both LiveView and say Vaadin Flow to compare them? I'm using Vaadin now on a project and it's pretty great so far with Quarkus. The app is also only using like 200mb of memory with production traffic, and I have a compiled language to work with. That's the main thing I'm waiting for with Phoenix...
Congratulations to the Phoenix team! I've been using LiveView since before v0.1 times (pulled it directly from GitHub into my production app, March 2019-ish) and it hasn't disappointed me a single time. Sure, it was rough around the edges, but it worked and has been working well ever since pre-0.1. The v1.0 release is an amazing milestone for a project and an awesome team that has come a really long way. I can't thank them enough for allowing me to build reactive production apps, big and small, with only a handful of people or just by myself. Thank you thank you thank you and here's to you. Cheers!
LiveView is so nice for full stack development, it's a wonderful palette cleanser after a day of enterprise programming.
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.
If it is possible can you share an example/samples integrating the mentioned libraries. I’m starting to learn LiveView again, mostly want to use aggrid and other custom libraries. An article highlighting the possibility and pointers to samples would greatly help everyone in this space.
I don't have any examples from my code, so the best I can do is the relevant documentation.
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,
The combination of Elixir, Phoenix & LiveView really is incredible: "What about supporting production hot code upgrades where browsers can auto re-render anytime CSS stylesheets, images, or templates change – without losing state or dropping connections? Sure!".
No replacing servers to push code changes, no telling people to logout & back in to see the changes. Crazy.
In my htmx project, the best I could pull off was:
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
Are assets versioned by URL (/path/to/foo-1234abcd.js or /1234abcd/path/to/foo.js) or are they updated in-place (/path/to/foo.js, but now containing 'const version="1234abcd";')?
If the first one, if you don't do it already, your reload header could act like a "preload" header ("Htmx-Preload-Root: 1234abcd") and tell the client which assets to start pulling even before a logical navigation click, so that they're hot in the cache when they eventually do that navigation.
Nice idea! The assets are versioned by URL. Indeed, if it's just a component update (not navigation), we can't fully reload yet, but we already know at that point that we can start pulling the new assets.
I still remember my gateway to Elixir, Dave Thomas' book on pragprog. And then his course. And I still remember how intrigued I was by the sentiments expressed by Dave, bringing back the joy of writing code. Which I see echoed in many comments here, and to whom I fully subscribe.
Congratulations to Chris, Jose and team!
I build internal web applications for companies in the transport industry, and I have considered to try out Phoenix LiveView for my next project ( I have never used Phoenix or Elixir). Everyone praises the DX but I'm conserned about the requirement of constant internet connection. What happens if a user enters a tunnel where there are no connection? Will the app just crash or are there ways to handle this better somehow?
I recently worked on a project where I created an elixir endpoint that handles websocket connections and did all the coordination manually with OTP. I'd like something like Phoenix that would give me an easy way to handle websockets without necessarily needing the phoenic ui stack. Is the underlying websockef functionality available as a seperate module or minimal Phoenix powered server
Sure, you can generate a project without Ecto and so on and pretty much use only Plug and Channel. There are flags you can pass to phx.new that excludes functionality.
One day, I hope, I am going to get around to learning Phoenix, and that time from the Phoenix docs/website itself. Perhaps I can also find a job to learn on the job. That would be great.
That seems out of scope for LiveView itself. You could of course use LiveView from a WebView shell. There is a project for bundling Elixir in an app as well. Not sure it is active? But they don't usually rot too bad.
https://github.com/elixir-desktop/desktop
DockYard has built out LiveView Native which does a wild React Native style based on the LiveView server-rendered model.
The Gleam team has their own, different efforts with Sprocket (LiveView-inspired I think) and Lustre (different, but related). I would look at those primarily or use Gleam modules with your LiveViews which should work fine if you don't mind the double language thing.
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.
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!
reply