[HN Gopher] Phoenix LiveView 1.0.0 is here
___________________________________________________________________
Phoenix LiveView 1.0.0 is here
Author : bcardarella
Score : 712 points
Date : 2024-12-03 22:28 UTC (1 days ago)
(HTM) web link (www.phoenixframework.org)
(TXT) w3m dump (www.phoenixframework.org)
| BobbyMcWho wrote:
| 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.
| bcardarella wrote:
| I wrote my thoughts on the LiveView 1.0 release:
| https://dockyard.com/blog/2024/12/03/phoenix-liveview-goes-1...
| arrowsmith wrote:
| Great write up, thanks!
| sysashi wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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. 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 wrote:
| 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 wrote:
| Thanks!
| AnonC wrote:
| > 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 wrote:
| Will you update the course for v1.0 of Liveview?
|
| Thanks
| arrowsmith wrote:
| Of course! I'm already working on it.
| mfsch wrote:
| 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 wrote:
| There's the changelog:
|
| https://github.com/phoenixframework/phoenix_live_view/blob/m...
| obeavs wrote:
| 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 wrote:
| 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-...
|
| The AI story is mostly centered around the Nx project:
| https://github.com/elixir-nx/
| tpdly wrote:
| 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.
| felix_starman wrote:
| 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
| thruflo wrote:
| We've actually also implemented Phoenix sync using Electric:
| https://hexdocs.pm/electric_phoenix/Electric.Phoenix.html
|
| So you can have local-first sync in a Phoenix app using
| Electric. And you can use Electric to sync data into a
| LiveView using Phoenix.Streams, which is a very natural fit.
|
| We have a couple of example apps showing things in action:
|
| - https://github.com/electric-
| sql/electric/tree/main/examples/... -
| https://github.com/electric-
| sql/electric/tree/main/examples/...
| sph wrote:
| 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.
| estreeper wrote:
| 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 wrote:
| 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/...
| cess11 wrote:
| 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.
| chrismccord wrote:
| 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 and https://elixir-lang.org/install.bat
|
| edit: You can see it in action here:
| https://x.com/chris_mccord/status/1864067247255306332
|
| Of course we also have non |sh installation guides if that's what
| you're after: https://hexdocs.pm/phoenix/installation.html
|
| Now that this is out, I'm looking forward to put together a few
| new demos. What would folks like to see? Happy hacking!
| ashton314 wrote:
| 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!
| st3fan wrote:
| (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 wrote:
| Done! https://phoenixframework.org/feed
|
| You can thank Steffen from the Phoenix team :)
| goosejuice wrote:
| 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.
| andrewmutz wrote:
| How much state is it safe to store in the URL these days?
| ljoshua wrote:
| Still not much, realistically 4096 bytes or less.
|
| Browsers aren't as much the issue as they've been in the
| past, but I've hit snags with proxies, old servers, etc.
| ethbr1 wrote:
| How does pagination in urls work nowadays? You'd need ~3
| bytes to index a reasonable number of pages naively, no?
|
| But curious what current art is re: performance
| optimizations between frontend and backend. Or is it
| simply page indices?
| out_of_protocol wrote:
| 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
| cess11 wrote:
| There are libraries for Ecto that help with this.
|
| https://github.com/duffelhq/paginator
| sph wrote:
| 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.
|
| Here's the fork I created at the time to work around some
| of these issues: https://github.com/1player/paginator
| chrismccord wrote:
| 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:
|
| https://www.youtube.com/watch?v=FADQAnq0RpA&t=2322s
|
| This demo doesn't update the URL to keep state (but
| push_patch would make that trivial). I'll think about more
| complex examples for cursor pagination, but the solution to
| massive collections (thousands of entries) is going to be
| stream + limit
| goosejuice wrote:
| 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.
| davydog187 wrote:
| I highly recommend checking out
| [Flop](https://hexdocs.pm/flop/readme.html) and its
| Phoenix.Component [Flop
| Phoenix](https://hexdocs.pm/flop_phoenix/readme.html).
|
| Its extremely easy to customize and build a reusable
| paginated table component
| mike1o1 wrote:
| 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).
|
| 1.
| https://www.youtube.com/playlist?list=PLXoynULbYuED9b2k5LS44...
| 7sidedmarble wrote:
| https://x.com/src_rip/status/1860081489486188812?t=S8QJBrmMO.
| ..
| chrismccord wrote:
| 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:
|
| https://x.com/chris_mccord/status/1864160634394325038
| AlchemistCamp wrote:
| I've been looking forward to this for a long time!
|
| Congrats to you and everyone else who made it happen!
| BryanBryce wrote:
| I build 3 client projects in 3 months with Phoenix and Live
| View (and Ash!). Thank you so much!
| sbrother wrote:
| 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.
| hiisukun wrote:
| Maybe this isn't the best place for feedback, but I was
| inspired to give this a go. Sadly it didn't work out. First
| error was: sh: line 1: Application: command not
| found
|
| By visiting https://new.phoenixframework.org/test-elixir-app, I
| could see the proper output: 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.
| chrismccord wrote:
| I will see if we can do something about fedora, but we now
| convert hyphens to underscores because I'm sure that will
| trip more folks up - thanks!
|
| For fedora, Elixir has instructions on their site:
| sudo dnf install elixir erlang
|
| https://elixir-lang.org/install.html
|
| I'd love to make it work for elixir install if we can though
| :)
| cess11 wrote:
| I generally recommend using ASDF to install Erlang/Elixir,
| it has support for Fedora.
|
| https://asdf-vm.com/guide/getting-started.html
| https://github.com/asdf-vm/asdf-erlang
| https://github.com/asdf-vm/asdf-elixir
|
| Slightly more ceremony than curl | sh, but a good tool to
| have.
| cassepipe wrote:
| What does "support for Fedora" means in this context ?
| xelamonster wrote:
| 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.
| ashconnor wrote:
| Mise also has support
|
| https://mise.jdx.dev/
| jdxcode wrote:
| mise should get precompiled erlang on macos today too
| formo wrote:
| Congratulations!! The much awaited is finally here.
|
| 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.
| sph wrote:
| Thank you Chris. Though it is clear that the similarity between
| Elixir and Ruby is only superficial, I cannot refrain from
| seeing your and Jose'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.
|
| Thank you!
| d_sc wrote:
| 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.
|
| URL: https://www.phoenixframework.org/blog/the-road-
| to-2-million-...
| tiffanyh wrote:
| Hi Chris
|
| 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-...
| outlog wrote:
| totally this! maybe a 10 anniversary thing next year..
| ricketycricket wrote:
| Bandit is now the default in Phoenix.
| pier25 wrote:
| Congrats on the release Chris!
|
| What JS solution/approach would you recommend to use with
| LiveView for pure client-side stuff?
| pdimitar wrote:
| I'm not Chris but people have reported success and very low
| friction when using HTMX.
| conradfr wrote:
| 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 wrote:
| I love Phoenix
| bgdkbtv wrote:
| Congrats! Love Phoenix and absolutely love LiveView
| sergiotapia wrote:
| 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 wrote:
| > best decision of my professional career...
|
| Does this mean you are getting lots of work with it?
| sergiotapia wrote:
| All of my work has been with Elixir so far thankfully. I've
| also had to hire people for Elixir work, good dudes!
| mrdoops wrote:
| 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 wrote:
| 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.
| mike1o1 wrote:
| 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 wrote:
| 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 wrote:
| You can use a JS service worker and local storage.
|
| This is how Firestore works, for example
| arcanemachiner wrote:
| Someone made a PoC app (todo list) that integrates LiveView
| with offline support and conflict resolution via CRDTs.
|
| 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
| mike1o1 wrote:
| 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.
| mike1o1 wrote:
| 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.
| evnp wrote:
| 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"
|
| https://liveview-svelte-pwa.fly.dev/
| elcritch wrote:
| 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.
| Muromec wrote:
| >While I get offline support will never happen
|
| 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
| samgaw wrote:
| 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.
|
| [1] https://replicache.dev [2]
| https://hexdocs.pm/phoenix_live_view/Phoenix.LiveComponent.h...
| dantodor wrote:
| 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 wrote:
| 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 wrote:
| 6 years, holy guacamole, good job Elixir community!
| abrookewood wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| What were the problems and how did you solve them?
| sb8244 wrote:
| 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 wrote:
| 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
| losvedir wrote:
| 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 wrote:
| 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 wrote:
| 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
|
| https://github.com/phoenixframework/phoenix_live_view?tab=re...
| mrcwinn wrote:
| Thank you for posting this.
| winrid wrote:
| 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 wrote:
| Java VM is not the BEAM. That alone would be a major deal
| breaker for me.
| ricketycricket wrote:
| Elixir/Phoenix is compiled.
| sails01 wrote:
| Congratulations!
|
| Any plan to support native iOS & Android? I will love to consider
| Liveview as an alternative to our Ionic+Capacitor setup
| lawik wrote:
| 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.
| cess11 wrote:
| There's an ongoing effort in the LiveView Native project:
| https://github.com/liveview-native/live_view_native
| wkrp wrote:
| 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 wrote:
| 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 wrote:
| 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,
| indigo0086 wrote:
| 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 wrote:
| I believe you can use Phoenix channels for this.
| cess11 wrote:
| 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 wrote:
| Any collaboration or plans for Gleam support?
| lawik wrote:
| 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 wrote:
| 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 wrote:
| No, it will fall back on long polling. Most users won't notice.
| liampulles wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Congrats! I've been waiting for the stable release since I saw
| the keynote https://www.youtube.com/watch?v=FADQAnq0RpA
| nickgnd wrote:
| Congratulations! That's a great milestone
| arbaaz wrote:
| Congratulations to all !!!
| codr7 wrote:
| 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 wrote:
| anyone with experience who can compare LV and Blazor?
| k__ wrote:
| Is this the GWT for Elixir?
| zelphirkalt wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2024-12-04 23:02 UTC)