10 ms·

Phoenix LiveView 1.0.0 is here

779 points by bcardarella 2y ago

bcardarella 2y ago
I wrote my thoughts on the LiveView 1.0 release: https://dockyard.com/blog/2024/12/03/phoenix-liveview-goes-1-0 https://dockyard.com/blog/2024/12/03/phoenix-liveview-goes-1...
- arrowsmith 2y ago
  Great write up, thanks!
- deleted 2y ago
  [deleted]
BobbyMcWho 2y ago
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.
sysashi 2y ago
Hats off to phoenix team! I've been working with Elixir and Phoenix for quite a while, it just brings joy to work with and pretty fun as well :) 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)
- bcardarella 2y ago
  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.
cancan 2y ago
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!
arrowsmith 2y ago
Now there’s some good news! 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 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 2y ago
  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
  - arrowsmith 2y ago
    Thanks!
- AnonC 2y ago
  > 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).
- thedangler 2y ago
  Will you update the course for v1.0 of Liveview? Thanks
  - arrowsmith 2y ago
mfsch 2y ago
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.
- arrowsmith 2y ago
  There’s the changelog: https://github.com/phoenixframework/phoenix_live_view/blob/main/CHANGELOG.md https://github.com/phoenixframework/phoenix_live_view/blob/m...
obeavs 2y ago
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.
- thomasfortes 2y ago
  Integrating javascript with liveview and pushing and receiving events from client to server (and from server to client) is pretty simple using hooks: https://hexdocs.pm/phoenix_live_view/js-interop.html#client-hooks-via-phx-hook https://hexdocs.pm/phoenix_live_view/js-interop.html#client-... The AI story is mostly centered around the Nx project: https://github.com/elixir-nx/ https://github.com/elixir-nx/
- tpdly 2y ago
  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.
- 2y ago
estreeper 2y ago
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!
- chrismccord 2y ago
  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. 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/1 https://x.com/chris_mccord/status/1799100642654638543/video/...
chrismccord 2y ago
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 windows powershell: > curl.exe -fsSO https://new.phoenixframework.org/app.bat; .\app.bat 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 https://elixir-lang.org/install.sh and https://elixir-lang.org/install.bat https://elixir-lang.org/install.bat edit: You can see it in action here: https://x.com/chris_mccord/status/1864067247255306332 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 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!
- st3fan 2y ago
  (Is it possible to add RSS to the blog? The articles are great but there is no good way to stay up to date.)
  - chrismccord 2y ago
    Done! https://phoenixframework.org/feed https://phoenixframework.org/feed You can thank Steffen from the Phoenix team :)
    - asa400 2y ago
      "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.
- ashton314 2y ago
  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!
conradfr 2y ago
Congratulations to Chris McCord and anyone who worked on Live View, what a ride since the first public version in 2019. 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.
ferfumarma 2y ago
I love Phoenix
bgdkbtv 2y ago
Congrats! Love Phoenix and absolutely love LiveView
sergiotapia 2y ago
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.
- mixmastamyk 2y ago
  > best decision of my professional career… Does this mean you are getting lots of work with it?
  - sergiotapia 2y ago
    All of my work has been with Elixir so far thankfully. I've also had to hire people for Elixir work, good dudes!
nickgnd 2y ago
Congratulations! That's a great milestone
mrdoops 2y ago
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.
- liampulles 2y ago
  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.
- namaria 2y ago
  > Thus the rational I think you meant rationale
mike1o1 2y ago
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.
- Cyph0n 2y ago
  Genuine question: wouldn’t server-based frontend JS apps be susceptible to the same issue? 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.
  - CharlieDigital 2y ago
    You can use a JS service worker and local storage. This is how Firestore works, for example
    - arcanemachiner 2y ago
      Someone made a PoC app (todo list) that integrates LiveView with offline support and conflict resolution via CRDTs. https://liveview-svelte-pwa.fly.dev/ 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]). [1] https://github.com/woutdp/live_svelte https://github.com/woutdp/live_svelte
      - mike1o1 2y ago
        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.
dantodor 2y ago
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!
pawelduda 2y ago
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.
orliesaurus 2y ago
6 years, holy guacamole, good job Elixir community!
abrookewood 2y ago
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.
- kgeist 2y ago
  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
  - philsnow 2y ago
    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.
sb8244 2y ago
Congrats! This stable release is huge. 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 2y ago
  What were the problems and how did you solve them?
  - sb8244 2y ago
    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.
pentacent_hq 2y ago
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 https://www.youtube.com/watch?v=8xJzHq8ru0M
losvedir 2y ago
Congrats to everyone involved! 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.
mrcwinn 2y ago
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.
- chrismccord 2y ago
  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/ 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=readme-ov-file#component-systems https://github.com/phoenixframework/phoenix_live_view?tab=re...
  - mrcwinn 2y ago
    Thank you for posting this.
- kuatroka 2y ago
  Flowbite - https://flowbite.com/docs/getting-started/phoenix/ https://flowbite.com/docs/getting-started/phoenix/ install guide for Phoenix Preline - https://preline.co/docs/frameworks-laravel.html 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.
winrid 2y ago
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...
- sph 2y ago
  Java VM is not the BEAM. That alone would be a major deal breaker for me.
- ricketycricket 2y ago
  Elixir/Phoenix is compiled.
  - winrid 2y ago
    Fair, but not statically typed
sails01 2y ago
Congratulations! Any plan to support native iOS & Android? I will love to consider Liveview as an alternative to our Ionic+Capacitor setup
- lawik 2y ago
  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 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.
- cess11 2y ago
  There's an ongoing effort in the LiveView Native project: https://github.com/liveview-native/live_view_native https://github.com/liveview-native/live_view_native
wkrp 2y ago
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.
- Onewildgamer 2y ago
  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.
  - wkrp 2y ago
    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-hooks-via-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,
indigo0086 2y ago
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
- necessary 2y ago
  I believe you can use Phoenix channels for this.
- cess11 2y ago
  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.
lordofgibbons 2y ago
Any collaboration or plans for Gleam support?
- lawik 2y ago
  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.
cambaceres 2y ago
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?
- cess11 2y ago
  No, it will fall back on long polling. Most users won't notice.
liampulles 2y ago
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.
- mcintyre1994 2y ago
  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.
pjullrich 2y ago
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!
ranuzz 2y ago
Congrats! I’ve been waiting for the stable release since I saw the keynote https://www.youtube.com/watch?v=FADQAnq0RpA https://www.youtube.com/watch?v=FADQAnq0RpA
arbaaz 2y ago
Congratulations to all !!!
codr7 2y ago
I guess the main reason for using web sockets is to allow async? 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.
foretop_yardarm 2y ago
anyone with experience who can compare LV and Blazor?
k__ 2y ago
Is this the GWT for Elixir?
zelphirkalt 2y ago
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.
epolanski 2y ago
How's the remote job market for elixir? 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.
slimebot80 2y ago
Any thoughts on hosting? I'm attracted to JS+Cloudflare because hosting seems predictable and reasonably priced. Do people have good recommendations / experiences with hosting?
miloandmilk 2y ago
Late to the party but congrats on the release and thanks for all the work everyone put into Liveview, its truly a marvel.
neycoda 2y ago
"HTTP can go away"... uh, then how does the web client and server communicate with each other?

779 points by bcardarella 2y ago

I wrote my thoughts on the LiveView 1.0 release: https://dockyard.com/blog/2024/12/03/phoenix-liveview-goes-1-0 https://dockyard.com/blog/2024/12/03/phoenix-liveview-goes-1...

arrowsmith 2y ago
Great write up, thanks!
deleted 2y ago
[deleted]

BobbyMcWho 2y ago

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.

sysashi 2y ago

Hats off to phoenix team! I've been working with Elixir and Phoenix for quite a while, it just brings joy to work with and pretty fun as well :) 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)

bcardarella 2y ago
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.

cancan 2y ago

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!

arrowsmith 2y ago

Now there’s some good news! 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 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 2y ago
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
- arrowsmith 2y ago
  Thanks!
AnonC 2y ago
> 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).
thedangler 2y ago
Will you update the course for v1.0 of Liveview? Thanks
- arrowsmith 2y ago

mfsch 2y ago

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.

arrowsmith 2y ago
There’s the changelog: https://github.com/phoenixframework/phoenix_live_view/blob/main/CHANGELOG.md https://github.com/phoenixframework/phoenix_live_view/blob/m...

obeavs 2y ago

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.

thomasfortes 2y ago
Integrating javascript with liveview and pushing and receiving events from client to server (and from server to client) is pretty simple using hooks: https://hexdocs.pm/phoenix_live_view/js-interop.html#client-hooks-via-phx-hook https://hexdocs.pm/phoenix_live_view/js-interop.html#client-... The AI story is mostly centered around the Nx project: https://github.com/elixir-nx/ https://github.com/elixir-nx/
tpdly 2y ago
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.
2y ago

estreeper 2y ago

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!

chrismccord 2y ago
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. 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/1 https://x.com/chris_mccord/status/1799100642654638543/video/...

chrismccord 2y ago

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 windows powershell: > curl.exe -fsSO https://new.phoenixframework.org/app.bat; .\app.bat 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 https://elixir-lang.org/install.sh and https://elixir-lang.org/install.bat https://elixir-lang.org/install.bat edit: You can see it in action here: https://x.com/chris_mccord/status/1864067247255306332 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 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!

st3fan 2y ago
(Is it possible to add RSS to the blog? The articles are great but there is no good way to stay up to date.)
- chrismccord 2y ago
  Done! https://phoenixframework.org/feed https://phoenixframework.org/feed You can thank Steffen from the Phoenix team :)
  - asa400 2y ago
    "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.
ashton314 2y ago
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!

conradfr 2y ago

Congratulations to Chris McCord and anyone who worked on Live View, what a ride since the first public version in 2019. 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.

ferfumarma 2y ago

I love Phoenix

bgdkbtv 2y ago

Congrats! Love Phoenix and absolutely love LiveView

sergiotapia 2y ago

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.

mixmastamyk 2y ago
> best decision of my professional career… Does this mean you are getting lots of work with it?
- sergiotapia 2y ago
  All of my work has been with Elixir so far thankfully. I've also had to hire people for Elixir work, good dudes!

nickgnd 2y ago

Congratulations! That's a great milestone

mrdoops 2y ago

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.

liampulles 2y ago
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.
namaria 2y ago
> Thus the rational I think you meant rationale

mike1o1 2y ago

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.

Cyph0n 2y ago
Genuine question: wouldn’t server-based frontend JS apps be susceptible to the same issue? 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.
- CharlieDigital 2y ago
  You can use a JS service worker and local storage. This is how Firestore works, for example
  - arcanemachiner 2y ago
    Someone made a PoC app (todo list) that integrates LiveView with offline support and conflict resolution via CRDTs. https://liveview-svelte-pwa.fly.dev/ 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]). [1] https://github.com/woutdp/live_svelte https://github.com/woutdp/live_svelte
    - mike1o1 2y ago
      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.

dantodor 2y ago

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!

pawelduda 2y ago

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.

orliesaurus 2y ago

6 years, holy guacamole, good job Elixir community!

abrookewood 2y ago

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.

kgeist 2y ago
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
- philsnow 2y ago
  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.

sb8244 2y ago

Congrats! This stable release is huge. 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 2y ago
What were the problems and how did you solve them?
- sb8244 2y ago
  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.

pentacent_hq 2y ago

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 https://www.youtube.com/watch?v=8xJzHq8ru0M

losvedir 2y ago

Congrats to everyone involved! 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.

mrcwinn 2y ago

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.

chrismccord 2y ago
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/ 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=readme-ov-file#component-systems https://github.com/phoenixframework/phoenix_live_view?tab=re...
- mrcwinn 2y ago
  Thank you for posting this.
kuatroka 2y ago
Flowbite - https://flowbite.com/docs/getting-started/phoenix/ https://flowbite.com/docs/getting-started/phoenix/ install guide for Phoenix Preline - https://preline.co/docs/frameworks-laravel.html 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.

winrid 2y ago

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

sph 2y ago
Java VM is not the BEAM. That alone would be a major deal breaker for me.
ricketycricket 2y ago
Elixir/Phoenix is compiled.
- winrid 2y ago
  Fair, but not statically typed

sails01 2y ago

Congratulations! Any plan to support native iOS & Android? I will love to consider Liveview as an alternative to our Ionic+Capacitor setup

lawik 2y ago
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 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.
cess11 2y ago
There's an ongoing effort in the LiveView Native project: https://github.com/liveview-native/live_view_native https://github.com/liveview-native/live_view_native

wkrp 2y ago

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.

Onewildgamer 2y ago
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.
- wkrp 2y ago
  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-hooks-via-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,

indigo0086 2y ago

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

necessary 2y ago
I believe you can use Phoenix channels for this.
cess11 2y ago
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.

lordofgibbons 2y ago

Any collaboration or plans for Gleam support?

lawik 2y ago
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.

cambaceres 2y ago

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?

cess11 2y ago
No, it will fall back on long polling. Most users won't notice.

liampulles 2y ago

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.

mcintyre1994 2y ago
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.

pjullrich 2y ago

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!

ranuzz 2y ago

Congrats! I’ve been waiting for the stable release since I saw the keynote https://www.youtube.com/watch?v=FADQAnq0RpA https://www.youtube.com/watch?v=FADQAnq0RpA

arbaaz 2y ago

Congratulations to all !!!

codr7 2y ago

I guess the main reason for using web sockets is to allow async? 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.

foretop_yardarm 2y ago

anyone with experience who can compare LV and Blazor?

k__ 2y ago

Is this the GWT for Elixir?

zelphirkalt 2y ago

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.

epolanski 2y ago

How's the remote job market for elixir? 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.

slimebot80 2y ago

Any thoughts on hosting? I'm attracted to JS+Cloudflare because hosting seems predictable and reasonably priced. Do people have good recommendations / experiences with hosting?

miloandmilk 2y ago

Late to the party but congrats on the release and thanks for all the work everyone put into Liveview, its truly a marvel.

neycoda 2y ago

"HTTP can go away"... uh, then how does the web client and server communicate with each other?