[freehunter]

Man I'm hoping NEW MAGIC is like Phoenix LiveView. As a Rails dev I started looking into the Elixir/Phoenix world just for LiveView but I don't really want to switch languages... I just want that new magic that LiveView offers. I know there are gems for Rails but I'd prefer if it was baked-in and officially supported.

[AlchemistCamp]

> I started looking into the Elixir/Phoenix world just for LiveView but I don't really want to switch languages...

Yes, you want to add languages! Join us...

[freehunter]

Haha I would love to and it seems like a really great language/community/ecosystem. I'm just a part-time developer though, so my "coding time" is extremely limited and mainly just around scratching an itch as quickly as possible. I'm confident Elixir/Phoenix would give me that speed and comfort too, but I already know Rails and the time I would spend learning Elixir/Phoenix just to get access to LiveView would be better spent just learning Javascript and moving on.

I wish I had a use case where Elixir's concurrency model makes the initial lift worth it, but my work doesn't even require me to learn how to make Ruby scale past a $5 DigitalOcean droplet.

[AlchemistCamp]

Yeah, that makes sense. For smaller projects, I don't think anything matches Ruby in terms of pure solo-dev productivity. I still use it for scripting.

One thing I would advise, given your situation, is to avoid full-blown SPAs. You can use something like Stimulus Reflux and be way more productive than going down the whole React/Redux/library explosion rabbit hole. Ditto for spending a lot of time on Kubernetes, Docker, etc.

If you're not a full-time dev, just do things with the minimum abstraction needed.

[freehunter]

You're spot on. I tried React and Vue and it just adds so much complexity for a solo dev. Right now I'm just using tiny bits of JS here and there, but I'm really hungry for something like LiveView that would let me do interactive front-ends while not having to manage state and authentication on the front-end.

[mhoad]

Depending on your patience you can go and take a look at a real life implementation of it at https://app.hey.com since they enable source maps.

What the actual developer facing API is going to look like however is another question. I do kind of worry that given how much is has been talked up by DHH in particular that it is going to struggle to live up to the hype.

Either way, I am excited to see something new in the Rails front end space, that has felt like it was lacking a LOT of structure.

[inopinatus]

I was sold on hey.com's UI design already because it's using <details><summary> for dropdown menus.

The really fun part, though: the summary content isn't just a menu icon, it's a trigger for some (currently unpublished) Turbolinks variant. The menu content is loaded (and subsequently 304'd) dynamically as a server-rendered partial (sans layout).

Most tellingly, if you visit the menu content's XHR URL with regular browsing then hey.com renders that menu as the sole content in a page layout.

We can't see the server-side parts yet, but if that becomes an out-of-the-box end-to-end behaviour within Rails, then in conjunction with Stimulus 2 and Action Cable I'm stoked about the possibilities. Especially so since I have a mission to replace all my dropdown & modal boilerplate with <details><summary> and <dialog> elements, and I like to build services that still work if JS is disabled. But it's also good for mundane stuff like progressive form validation in line-of-business apps.

[mhoad]

Based on my casual browsing of the code I assume that it pushes small HTML fragments via WebSockets whenever the backend state changes on a given ActiveRecord model. It covers things like automatically updating the state of a model on a page, adding, removing, reordering elements etc all without any custom code so long as things are wired up correctly.

Basically, all the "re-activeness" of an SPA but without ever having to worry about the concept of client side state management at all.

Edit: I am a grumpy old man in web-dev years who hadn't ever really looked into Phoenix Live View before now but after watching a video on how it works, yes, my understanding is that it works basically the same way.

[Serow225]

That sounds pretty similar to Microsoft's Blazor (server side) model.

[jxf]

> Especially so since I have a mission to replace all my dropdown & modal boilerplate with <details><summary> and <dialog> elements, and I like to build services that still work if JS is disabled.

Can you elaborate on why `<details><summary>` is specifically exciting to you?

[inopinatus]

It works without Javascript, which means a few things.

Firstly, for customers; it works behind asset-blocking insane corporate firewalls, or for some poor schmuck in the sticks getting one bar of cell data and just enough to load our HTML, or simply to impress anyone running uBlock₀ in Advanced mode.

Secondly; because front-end Javascript bitrots faster than any code I've ever seen in four decades in tech. Reducing the quantity of JS in favour of letting the browser just do its job, is one of the best investments I can make against technical debt. JS can't be abandoned completely, but I measure every kilobyte jealously, and graceful degradation to baseline browser behaviour is my north star; simply using baseline browser behaviour is by definition my optimum limit for long-term productivity.

Thirdly; for folks depending on assistive browsing technologies. Yes, they do work in the face of dynamic web pages & SPAs, but many screen readers are still at their best when tabbing through plain HTML with a sprinkling of ARIA markup.

Finally, it's also a simple yet versatile mechanism. Good for anything from FAQ items to dropdown menus, even with default styles.

[Existenceblinks]

You can try inspecting dropdown or button that shows modal on Github.com, they are using it all over the places.

[aczerepinski]

LiveView is awesome - I'd be pleasantly surprised if Rails were able to pull off something that good with Ruby's more limited capacity for concurrency.

[ibraheemdev]

Ruby 3 is putting a lot of emphasis on concurrency with the new (experimental) Ractor Actor model [1] and the Fiber Scheduler [2]. Concurrency in Ruby is getting a lot better.

1: https://github.com/ruby/ruby/blob/master/doc/ractor.md

2: https://bugs.ruby-lang.org/issues/16786

[latortuga]

We actually built something inspired by LiveView, it's called motion!

https://github.com/unabridged/motion

[freehunter]

Motion has been on my to-do list for way too long, I should spend some time with it this weekend.

[latortuga]

DHH mentioned on twitter that it is html over websockets so I fully expect it to be similar to LiveView.