>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 don't know if what I'm imagining is technically possible. But it would be cool to be able to have my email mirrored to two different services. One email address, email shows up in Mango Mail and my Google Apps email. Then I can evaluate Mango Mail's spam performance against Google's to see if it's good enough for my needs.
If I get up the courage to try again, yours will be my first choice :)
Just chiming in with my one data point of personal experience: I've primarily used Gmail for all of my email needs. I heard about Migadu several years back and decided to migrate over and give it a try. I was shocked at how completely inundated with spam my inbox was. They had a spam filter with a tunable threshold and no setting on that filter worked well for me. Even on the highest protection level some spam was still getting through, and tons of my actual mail was winding up in spam; which made wading through my spam folder multiple times a day a requirement. Compare that to when I was using Gmail, I didn't even really think about spam. My non-spam email almost never ends up in the spam folder, and I basically never get unwanted email in my inbox.
So after about 6 months of dealing with spam, I went back to Gmail. It's a minor ordeal to move email providers. I'd be scared to move providers without being able to see how well their spam filter works.
As an aside, that would be a nice capability (no idea if it's possible): a way to have your email mirrored to another service to test it out.
Your mail service looks cool though! If I hadn't already been burned I would be more inclined to give it try.
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.