Phlex for Rails Emails: Action Mailer Without ERB (opens in new tab)

> another layer of abstraction that new hires need to understand. Another DSL to learn.

The thing about Phlex is it’s actually one less thing to learn. Instead of learning Ruby and ERB and how to use them both with HTML — and all the context switching that goes with using three languages in one file, you only need to know Ruby and HTML semantics (elements, methods, attributes, text, comments, doctype).

> Another syntax/LSP/docs to add to the IDE, or editor.

If you’re writing an app in Ruby, you’ll already have Ruby LSP set up in your editor. There is no other syntax. I would strongly advise against using Phlex if not already writing an application in Ruby, though I have heard of someone using Phlex to generate PHP.

> Another leaky abstraction that has to be debugged, monitored, performance-tested.

I don’t know what you mean by “leaky abstraction”. I consider Phlex to be an air-tight abstraction around the parts of HTML I’ve ever had to use in the last 15 years of programming. There are a couple of things you can’t do without using `raw` — mainly CDATA and other non-HTML5 doctypes.

If I saw a convincing argument for supporting those parts of HTML, I would.

The real leaky abstraction for HTML is string templating, where none of the HTML semantics are validated and XSS vulnerabilities abound.

The thing I really like about Phlex is that it's not a full DSL, it's not its own language. It's an expressive Ruby API and the resulting code has the regular Ruby toolbox available. Ruby devs often call this a "DSL" and I lean away from that use of the term because I think it adds confusion in situations like this. But Phlex feels like a breath of fresh air because it's composable, testable, "just ruby", and has a lot fewer opportunities to footgun myself.

I agree on your criticisms of Erb and ActionView. I'd add that Erb is just really noisy jumping in and out of Ruby with <%= %> constantly. I'm regularly running down basic errors in producing well-formed HTML.

I'm still only experimenting a little with Phlex. I'm not sold on some of its design like the distinction between views and components, but maybe that's a practice/docs issue. I'd also like to see a performance test that's not a microbenchmark and I may try to make one this month. Similar to your note about haml, I've told the project devs that I'd be really encouraged by a phlex -> erb tool to reduce the perceived risk of getting locked into the dep.

EDIT: Oh, and I read the phlex code because I have similar experience outliving a dep. The library is ~1,600 loc with same again in tests. There's a little metaprogramming in SGML::Elements I dislike but it's not a dealbreaker. The library is small and straightforward enough that I'd be surprised if it broke without going unmaintained 5+ years, and I'd be fine maintaining a private fork for a year or so while migrating off.

>People writing Rails apps are developing web-apps. Writing HTML is part of the skillset, and of all the things in a Rails app, really not the most difficult, boring or inefficient ones.

I don't think of Phlex as something that lets me get away from writing HTML. I see it as a tool that allows me to bring all my experience and skills of writing clean and well organized Ruby code to the view layer. Am I repeating this same bit of markup frequently? Let's extract that out into a method. Are these two pages basically the same, only differing in one section? Perhaps they should share a common base class.

When I first started using Phlex, this wasn't even on my radar. My thought was that it was just a HTML builder DSL in Ruby, so what? The "so what" didn't hit me until working with it for a while. All my views are now Ruby—not text files with bits of interpolated Ruby. And in the 15 years I've been writing Ruby, I've picked up some skills at keeping it maintainable and readable. Skills that I can now apply to the view layer in a way I never could before.

So all of that is to say: I think I understand the reservations you lay out, and I had some of them as well. But I think there is more under the surface if you ever have the opportunity to give it a chance.

And just real quick, regarding this:

> you're [...] truly in trouble when (not if) the gem gets abandoned.

Phlex is sometimes described, somewhat tongue-in-cheek, as a string concatenation toolkit. At its core, it just builds strings. It is unlikely to stop working unless Ruby has some major changes. It is possible that the phlex-rails integration could go stale after a few Rails releases, if it was not being maintained. As long as Rails can send a string response, Phlex will remain usable.

I really loved using slim and only recently abandoned it because the benefits for using Cursor to code were so good.

Slim made views way easier to look at, understand, and code. I personally gained a lot of efficiency working with it.

wow this is the first i've seen someone port from sveltkit to rails. can't wait to read that writeup

Second this - here is a guide for good setup for this https://mailsnag.com/blog/rails7-vuetify3/

Vue3 is great. Also Svelte5. But I’m not sure I would use either of those for an email. And sometimes you don’t need any interactivity in the frontend and server-side-rendered HTML can be a good option.