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).
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.
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.
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.
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.
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.
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!
[+] [-] chrismccord|1 year ago|reply
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!
[+] [-] sph|1 year ago|reply
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!
[+] [-] hiisukun|1 year ago|reply
[+] [-] sbrother|1 year ago|reply
[+] [-] tiffanyh|1 year ago|reply
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-...
[+] [-] mike1o1|1 year ago|reply
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...
[+] [-] ashton314|1 year ago|reply
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!
[+] [-] st3fan|1 year ago|reply
[+] [-] kuatroka|1 year ago|reply
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
[+] [-] goosejuice|1 year ago|reply
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.
[+] [-] formo|1 year ago|reply
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.
[+] [-] BryanBryce|1 year ago|reply
[+] [-] d_sc|1 year ago|reply
URL: https://www.phoenixframework.org/blog/the-road-to-2-million-...
[+] [-] xnx|1 year ago|reply
[+] [-] AlchemistCamp|1 year ago|reply
Congrats to you and everyone else who made it happen!
[+] [-] pier25|1 year ago|reply
What JS solution/approach would you recommend to use with LiveView for pure client-side stuff?
[+] [-] estreeper|1 year ago|reply
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!
[+] [-] chrismccord|1 year ago|reply
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/...
[+] [-] cess11|1 year ago|reply
[+] [-] arrowsmith|1 year ago|reply
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.
[+] [-] evnp|1 year ago|reply
- not affiliated, just a humble enjoyer of Arrowsmith Labs materials
[+] [-] AnonC|1 year ago|reply
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).
[+] [-] thedangler|1 year ago|reply
Thanks
[+] [-] mrdoops|1 year ago|reply
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.
[+] [-] liampulles|1 year ago|reply
[+] [-] namaria|1 year ago|reply
I think you meant rationale
[+] [-] losvedir|1 year ago|reply
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.
[+] [-] bcardarella|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] arrowsmith|1 year ago|reply
[+] [-] sb8244|1 year ago|reply
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.
[+] [-] learning_elixir|1 year ago|reply
[+] [-] sergiotapia|1 year ago|reply
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.
[+] [-] liampulles|1 year ago|reply
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.
[+] [-] obeavs|1 year ago|reply
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.
[+] [-] mrcwinn|1 year ago|reply
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.
[+] [-] chrismccord|1 year ago|reply
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...
[+] [-] kuatroka|1 year ago|reply
Preline - https://preline.co/docs/frameworks-laravel.html You can use the Laravel guide and adapt it to Phoenix. Quite trivial install
These two UI component libraries are mostly HTML and Tailwind, so not too complex to use.
[+] [-] mike1o1|1 year ago|reply
[+] [-] sysashi|1 year ago|reply
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)
[+] [-] pentacent_hq|1 year ago|reply
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
[+] [-] pawelduda|1 year ago|reply
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.
[+] [-] BobbyMcWho|1 year ago|reply
[+] [-] mfsch|1 year ago|reply
[+] [-] cancan|1 year ago|reply
[+] [-] winrid|1 year ago|reply
[+] [-] pjullrich|1 year ago|reply