5 ms·

Phlex for Rails Emails: Action Mailer Without ERB

71 points by camillovisini 2y ago

axelthegerman 2y ago
Nice write up, however personally I'd take ERB over Phlex a million times. Sure ERB is another DSL and some things are not perfect. But for the mark-up you write actual HTML instead of having to learn and get used to writing blocks for each element. I guess to each their own, you enjoy rails with Phlex and I will with ERB. I think the bigger challenges with emails is that action mailer itself is a little dated and feels cluttered. Most email clients being a nightmare with the actual rendering and not being able to use stylesheets etc makes it even harder... So I'd love to see a general iteration on action mailer to bring it up to the level of Rails 8
- berkes 2y ago
  > Nice write up, however personally I'd take ERB over Phlex a million times. Agreed. This has been tried so many times, and non of them really "stuck". HAML, slim, liquid and now phlex. All "DSLs" to some extent that solve the problem of "not having to write HTML". Is that a problem, really? 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've found the opposite to be true: another layer of abstraction that new hires need to understand. Another DSL to learn. Another syntax/LSP/docs to add to the IDE, or editor. Another leaky abstraction that has to be debugged, monitored, performance-tested. And a very strongly and tightly coupled dependency: it's almost undoable to just move from, say, HAML back to erb in a 10k+LoC rails app: you're effectively married to HAML, and truly in trouble when (not if) the gem gets abandoned. Now, like Cells[1], Phlex main "problem it solves" isn't "HTML is hard" but "Rails' templates are too simple/poorly designed". Rails templates push a lot of magic (global) state around, is bidirectional (you can update the database from within a template just fine. Both intentional and accidental), it's not isolated, and because of all this, very hard to test. All this becomes worse if you want to re-use components. But, like Cells, Phlex solves this problem by introducing some DSL to abstract the HTML. Which then makes up the largest part of the gem. Why? Really. OOP templates can be classes that have a "render" and that then use (scoped) "erb" files just fine. This pattern is both easy and available - no gems needed even. So, yes. My opinionated, advice, fed by decades of struggling with numerous rails projects, is to stay away from such gems: KISS. ¹ edit : https://trailblazer.to/2.1/docs/cells/ https://trailblazer.to/2.1/docs/cells/
  - pushcx 2y ago
    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.
    - joeldrapper 2y ago
      > I'm not sold on some of its design like the distinction between views and components There is no distinction in Phlex. The distinction is only made in generated code in Phlex-Rails where it felt like a sensible way to fit with the existing mental model. Views are technically just components, but they are expected to be HTML documents composed of components and rendered directly from controller actions. You wouldn’t want to render a view inside another component because you’d get another doctype and `<html>` tag. So they are sort of “entry points”. > There's a little metaprogramming in SGML::Elements I dislike Many crimes are committed in the name of performance. For example, we have a different code path for standard elements with attributes and content, standard elements with attributes but no content, standard elements with content but no attributes and standard elements with no attributes or content. Not to mention void elements. This allows us to reduce the number of string concatenation operations required during rendering and is why it renders ~1.5gbps of HTML per core. I’ve considered having an API-compatible minimal version of Phlex that would be much easier to take on and maintain yourself if it didn’t make all these performance optimisations.
dewey 2y ago
There's a general pattern of: - People inventing new technologies to not write SQL - People inventing ways to avoid writing HTML I feel like the solution to both of these is just to stick to SQL / HTML as for both of these there's a lot of resources, tooling and knowledge and they will not go away. They are transferable between languages, projects and whatever tooling companies are using.
- deleted 2y ago
  [deleted]
- 3by7 2y ago
  And - People inventing new technologies to not write JS - People inventing new technologies to avoid writing CSS
- MyOutfitIsVague 2y ago
  HTML, yes, but SQL has another major problem in that it's not composable. HTML can be broken into fragments, but it's very difficult to work with and write reusable SQL in a modular way. CTEs and views help a bit, but they are not a great answer to the fact that SQL statements almost always have to be treated as an indivisible chunk. I like SQL alright from a functionality perspective (the syntax leaves much to be desired), but I still use ORMs where appropriate just to be able to modularize and make reusable behavior where it makes sense.
- joeldrapper 2y ago
  How do you write an each loop or a conditional in HTML?
- dajonker 2y ago
  It's a necessary evil, isn't it? You're not programming your application in pure HTML or SQL, you write it in some general language that can do much more. But the browser and database don't speak that language natively. They want strings which they then turn into something useful. So you need to build these big strings and unless your application is completely static, you'll need string interpolation one way or another.
dasil003 2y ago
Two decades in I still love ruby and rails, but I’m a bit surprised that the subculture promoting aesthetic perfection of code via over-wrought DSLs is still this strong. Haven’t we learned anything about pragmatism since 2009?
xutopia 2y ago
I can't help but feel that Rails is having a comeback now. Lots of people building really cool projects like this one popping up. The stack is insanely good for doing everything I need to do and the Hotwire Native stuff is starting to get more and more solid every day.
- GGO 2y ago
  I still prefer Vue3 with Vite over hotwire and stimulus. It is much easier to be productive on frontend if you need anything beyond usual CRUD
  - Ocha 2y ago
    Second this - here is a guide for good setup for this https://mailsnag.com/blog/rails7-vuetify3/ https://mailsnag.com/blog/rails7-vuetify3/
  - joeldrapper 2y ago
    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.
- nop_slide 2y ago
  Adding an anecdote I'm one of those newcomers having rediscovered rails a few months ago after all the buzz around version 8. I just got done porting https://www.skatevideosite.com https://www.skatevideosite.com (and our custom admin panel) from sveltekit/fastapi to Rails and I'm stoked on the results so far. I need to write up my experience about the rewrite, having a blast so far.
  - sharps_xp 2y ago
    wow this is the first i've seen someone port from sveltkit to rails. can't wait to read that writeup
    - 2y ago

71 points by camillovisini 2y ago

Nice write up, however personally I'd take ERB over Phlex a million times. Sure ERB is another DSL and some things are not perfect. But for the mark-up you write actual HTML instead of having to learn and get used to writing blocks for each element. I guess to each their own, you enjoy rails with Phlex and I will with ERB. I think the bigger challenges with emails is that action mailer itself is a little dated and feels cluttered. Most email clients being a nightmare with the actual rendering and not being able to use stylesheets etc makes it even harder... So I'd love to see a general iteration on action mailer to bring it up to the level of Rails 8

berkes 2y ago
> Nice write up, however personally I'd take ERB over Phlex a million times. Agreed. This has been tried so many times, and non of them really "stuck". HAML, slim, liquid and now phlex. All "DSLs" to some extent that solve the problem of "not having to write HTML". Is that a problem, really? 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've found the opposite to be true: another layer of abstraction that new hires need to understand. Another DSL to learn. Another syntax/LSP/docs to add to the IDE, or editor. Another leaky abstraction that has to be debugged, monitored, performance-tested. And a very strongly and tightly coupled dependency: it's almost undoable to just move from, say, HAML back to erb in a 10k+LoC rails app: you're effectively married to HAML, and truly in trouble when (not if) the gem gets abandoned. Now, like Cells[1], Phlex main "problem it solves" isn't "HTML is hard" but "Rails' templates are too simple/poorly designed". Rails templates push a lot of magic (global) state around, is bidirectional (you can update the database from within a template just fine. Both intentional and accidental), it's not isolated, and because of all this, very hard to test. All this becomes worse if you want to re-use components. But, like Cells, Phlex solves this problem by introducing some DSL to abstract the HTML. Which then makes up the largest part of the gem. Why? Really. OOP templates can be classes that have a "render" and that then use (scoped) "erb" files just fine. This pattern is both easy and available - no gems needed even. So, yes. My opinionated, advice, fed by decades of struggling with numerous rails projects, is to stay away from such gems: KISS. ¹ edit : https://trailblazer.to/2.1/docs/cells/ https://trailblazer.to/2.1/docs/cells/
- pushcx 2y ago
  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.
  - joeldrapper 2y ago
    > I'm not sold on some of its design like the distinction between views and components There is no distinction in Phlex. The distinction is only made in generated code in Phlex-Rails where it felt like a sensible way to fit with the existing mental model. Views are technically just components, but they are expected to be HTML documents composed of components and rendered directly from controller actions. You wouldn’t want to render a view inside another component because you’d get another doctype and `<html>` tag. So they are sort of “entry points”. > There's a little metaprogramming in SGML::Elements I dislike Many crimes are committed in the name of performance. For example, we have a different code path for standard elements with attributes and content, standard elements with attributes but no content, standard elements with content but no attributes and standard elements with no attributes or content. Not to mention void elements. This allows us to reduce the number of string concatenation operations required during rendering and is why it renders ~1.5gbps of HTML per core. I’ve considered having an API-compatible minimal version of Phlex that would be much easier to take on and maintain yourself if it didn’t make all these performance optimisations.

dewey 2y ago

There's a general pattern of: - People inventing new technologies to not write SQL - People inventing ways to avoid writing HTML I feel like the solution to both of these is just to stick to SQL / HTML as for both of these there's a lot of resources, tooling and knowledge and they will not go away. They are transferable between languages, projects and whatever tooling companies are using.

deleted 2y ago
[deleted]
3by7 2y ago
And - People inventing new technologies to not write JS - People inventing new technologies to avoid writing CSS
MyOutfitIsVague 2y ago
HTML, yes, but SQL has another major problem in that it's not composable. HTML can be broken into fragments, but it's very difficult to work with and write reusable SQL in a modular way. CTEs and views help a bit, but they are not a great answer to the fact that SQL statements almost always have to be treated as an indivisible chunk. I like SQL alright from a functionality perspective (the syntax leaves much to be desired), but I still use ORMs where appropriate just to be able to modularize and make reusable behavior where it makes sense.
joeldrapper 2y ago
How do you write an each loop or a conditional in HTML?
dajonker 2y ago
It's a necessary evil, isn't it? You're not programming your application in pure HTML or SQL, you write it in some general language that can do much more. But the browser and database don't speak that language natively. They want strings which they then turn into something useful. So you need to build these big strings and unless your application is completely static, you'll need string interpolation one way or another.

dasil003 2y ago

Two decades in I still love ruby and rails, but I’m a bit surprised that the subculture promoting aesthetic perfection of code via over-wrought DSLs is still this strong. Haven’t we learned anything about pragmatism since 2009?

xutopia 2y ago

I can't help but feel that Rails is having a comeback now. Lots of people building really cool projects like this one popping up. The stack is insanely good for doing everything I need to do and the Hotwire Native stuff is starting to get more and more solid every day.

GGO 2y ago
I still prefer Vue3 with Vite over hotwire and stimulus. It is much easier to be productive on frontend if you need anything beyond usual CRUD
- Ocha 2y ago
  Second this - here is a guide for good setup for this https://mailsnag.com/blog/rails7-vuetify3/ https://mailsnag.com/blog/rails7-vuetify3/
- joeldrapper 2y ago
  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.
nop_slide 2y ago
Adding an anecdote I'm one of those newcomers having rediscovered rails a few months ago after all the buzz around version 8. I just got done porting https://www.skatevideosite.com https://www.skatevideosite.com (and our custom admin panel) from sveltekit/fastapi to Rails and I'm stoked on the results so far. I need to write up my experience about the rewrite, having a blast so far.
- sharps_xp 2y ago
  wow this is the first i've seen someone port from sveltkit to rails. can't wait to read that writeup
  - 2y ago