Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Phlex for Rails Emails: Action Mailer Without ERB

camillovisini.com

Post reply on HN
Print view View original

21–26 of 26 posts

Re: Phlex for Rails Emails: Action Mailer Without ERB

#21

Post by nop_slide »

sharps_xp wrote: post #18
nop_slide wrote: post #14

Earlier quoted context omitted.

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.

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

drop me an email, hn at skatevideosite.com, and I'll be sure to message you when it comes out :)

Re: Phlex for Rails Emails: Action Mailer Without ERB

#22

Post by ch4s3 »

joeldrapper wrote: post #17
berkes wrote: post #3

Earlier quoted context omitted.

> 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,…

> 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 synt…

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

Re: Phlex for Rails Emails: Action Mailer Without ERB

#23

Post by joeldrapper »

dewey wrote: post #4

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.

How do you write an each loop or a conditional in HTML?

Re: Phlex for Rails Emails: Action Mailer Without ERB

#24

Post by dameyawn »

berkes wrote: post #3
axelthegerman wrote: post #2

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 fe…

> 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,…

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.

Re: Phlex for Rails Emails: Action Mailer Without ERB

#25

Post by dajonker »

dewey wrote: post #4

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.

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.

Re: Phlex for Rails Emails: Action Mailer Without ERB

#26

Post by berkes »

joeldrapper wrote: post #17
berkes wrote: post #3

Earlier quoted context omitted.

> 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,…

> 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 synt…

> The real leaky abstraction for HTML is string templating

With actual XML and JSON (or csv etc) I would agree: for that you need a serializer, not a string templating env.

But for HTML, especially when used to build GUIs, string templating makes sense - to me -.

What I meant with "leaky abstraction" is that when I write a web-app, my goal is to write certain HTML, the actual strings, to a browser. I'll have my developers console open, inspect DOM/source and then modify the code of the app until the DOM/source matches what I want or need it to be. The closer my "code of the app" is to this actual DOM/source, the less I need to think through layers.

I prefer to just "move this UL out of the DIV and next to the H2¹" rather than manipulating the structure in a tree of objects. To each their own, I guess, but I rather prefer to stay "as close to the metal" as possible, especially if that metal isn't complex or difficult.

¹ I realized I wrote my HTML elements in capitals. I am that old; and I don't anymore, but old habits creap in, I guess :)

Post reply on HN