Live data from Hacker News

Phoenix LiveView 1.0.0 is here

phoenixframework.org

31–40 of 142 posts

Re: Phoenix LiveView 1.0.0 is here

#31
post #26

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, thou…

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.

Re: Phoenix LiveView 1.0.0 is here

#32

Earlier quoted context omitted.

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'…

How much state is it safe to store in the URL these days?

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.

Re: Phoenix LiveView 1.0.0 is here

#33
post #26

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, thou…

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/

Re: Phoenix LiveView 1.0.0 is here

#34
post #32

Earlier quoted context omitted.

How much state is it safe to store in the URL these days?

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.

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?

Re: Phoenix LiveView 1.0.0 is here

#35

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 ht…

I build 3 client projects in 3 months with Phoenix and Live View (and Ash!). Thank you so much!

Re: Phoenix LiveView 1.0.0 is here

#36
post #31
post #26

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, thou…

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.

You can use a JS service worker and local storage.

This is how Firestore works, for example

Re: Phoenix LiveView 1.0.0 is here

#37
post #26

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, thou…

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.

Re: Phoenix LiveView 1.0.0 is here

#38
post #9

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 pa…

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.

Re: Phoenix LiveView 1.0.0 is here

#39
post #25

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 ht…

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 thr…

https://x.com/src_rip/status/1860081489486188812?t=S8QJBrmMO...

Re: Phoenix LiveView 1.0.0 is here

#40
post #26

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, thou…

>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

Post reply on HN