[HN Gopher] Phlex for Rails Emails: Action Mailer Without ERB
___________________________________________________________________
Phlex for Rails Emails: Action Mailer Without ERB
Author : camillovisini
Score : 64 points
Date : 2025-03-03 08:20 UTC (14 hours ago)
(HTM) web link (camillovisini.com)
(TXT) w3m dump (camillovisini.com)
| axelthegerman wrote:
| 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 wrote:
| > 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.
|
| 1 edit : https://trailblazer.to/2.1/docs/cells/
| pushcx wrote:
| 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 wrote:
| > 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.
| pushcx wrote:
| You know, you've told me that about views and components
| before, and I keep forgetting. I am so used to getting
| burned by software that has two names for things because
| a couple months or years later, ah yes, now that you
| mention it there is this one tiiiiny distinction that
| happens to be why the app is on fire now.
|
| It would be great if you could expand your explanation of
| the metaprogramming into a comment in the code. When I
| read it, I didn't immediately recognize the technique and
| its tradeoffs, so it seemed like an odd decision rather
| than an informed one.
|
| Having two versions of phlex would be a strong negative
| to me. I don't like to see dev teams spread themselves
| out, it's one more choice I'd have to make when adopting,
| if switching between them I have new risks that they've
| slipped out of sync in some way, and it's altogether
| another odd decision that has to be explained.
|
| What I was trying to say about the code is that I share
| the previous commenter's experience of "welp I guess if
| we want that bug fixed we have to click 'fork' on
| github... while we write up our plan to migrate away".
| Having had that experience several times, Phlex looks
| like an acceptable risk.
| willcosgrove wrote:
| >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.
| joeldrapper wrote:
| > 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.
| ch4s3 wrote:
| > you only need to know Ruby and HTML semantics (elements,
| methods, attributes, text, comments, doctype).
|
| If you know those things then you basically know ERB. And
| to your point the Ruby LSP works with ERB.
| dameyawn wrote:
| 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.
| dewey wrote:
| 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.
| 3by7 wrote:
| And - People inventing new technologies to not
| write JS - People inventing new technologies to avoid
| writing CSS
| MyOutfitIsVague wrote:
| 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 wrote:
| How do you write an each loop or a conditional in HTML?
| dajonker wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Second this - here is a guide for good setup for this
| https://mailsnag.com/blog/rails7-vuetify3/
| joeldrapper wrote:
| 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 wrote:
| 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 (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 wrote:
| wow this is the first i've seen someone port from sveltkit to
| rails. can't wait to read that writeup
| nop_slide wrote:
| drop me an email, hn at skatevideosite.com, and I'll be
| sure to message you when it comes out :)
| pawelduda wrote:
| Wonder if there is some data that backs up this claim
___________________________________________________________________
(page generated 2025-03-03 23:01 UTC)