[mhoad]

It's a really nice time to be a Ruby / Rails developer. Rails itself has made some really nice improvements with this release and there is also the "NEW MAGIC" should be following in the next couple of days which is currently being sold as what Rails was to the back end, this will be to the front end.

Ruby 3 is also just a few days away which brings optional type checking to helps add some additional structure to larger code bases.

Then in the wider community you have projects like Hanami 2.0 looking to launch next year which aims to bring all of the structure of "clean architecture" approaches and best practices with the simplicity and expressiveness of Ruby.

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

[rsanheim]

I’m so glad the pendulum seems to be swinging back to sensible server side based web dev that embraces the web and layers in dynamic front end behavior when needed. Most sites need a small amount of JS. Some benefit from quite a bit more, and for that there are things like Stimulus. And maybe you need a ton and it needs to work offline and manage a ton of local state - for that there are the usual SPA suspects. But those are and should be outliers.

The fact that “let’s use React with a JSON API Backend” is becoming much less the default is a very good thing. Web dev went into a dark time for awhile there and I’m hopeful we are coming out of it.

[cutler]

I don't see this trend out in the real world. Look on any major jobs site and you'll find React jobs everywhere.

[jaredcwhite]

We're also hard at work over at the Bridgetown project to make Ruby a first-class citizen on the Jamstack. A static Bridgetown site combined with a Rails API is a killer combo for some pretty interesting use cases. Anyway, you're absolutely right—what a time to be a Rubyist! =)

[dmix]

It's always a goods time to be a Rails developer employment-wise as well.

I recently saw a report on w3 showing Ruy is now more popular server-side than Java.

https://w3techs.com/technologies/overview/programming_langua...

[Dirlewanger]

>Ruby 3

Oh shit, I didn't realize that that's the scheduled Christmas release. Finally, all strings frozen by default!

[shaicoleman]

Ruby 3.0 will not have frozen strings by default:

https://bugs.ruby-lang.org/issues/11473#note-53

[3pt14159]

I still can't believe they changed their mind about this. It's the cause of so many bugs and security issues.

[digianarchist]

I was hoping to remove this line from almost every file in a few projects at work:

    # frozen_string_literal: true

[cactus2093]

> Ruby 3 is also just a few days away which brings optional type checking

Just curious, has anyone here been using type ruby type checking effectively? (since Sorbet is already available and working in ruby 2).

My experience across ruby, python, and js codebases is that Typescript for JS is leaps and bounds above anything in the other two languages, both in its capabilities and overall community adoption, and the lead is only growing. I could be wrong, maybe it will hit some critical point soon and take off, but I don't realistically see type checking catching on in ruby or python.

[dyeje]

Shopify and Stripe have been using it in production.

[arthurcolle]

I tried integrating Sorbet into my side project and it was pretty challenging. I gave up. It seems to be super sensitive to small things. Can't exactly remember what made me just rip it out altogether but yeah it was a huge pain. It seems really great though, I should give it another go when I roll out some more features.