The blog post argues against interactive emails, specifically targeting AMP for Email. It contends that email's simplicity and plain text accessibility are its strengths, while interactivity introduces complexity, security risks, and accessibility issues. AMP, despite promising dynamic content, ultimately failed to gain traction because it bloated email size, created rendering inconsistencies across clients, demanded extra development effort, and ultimately provided little benefit over well-designed traditional HTML emails with clear calls to action leading to external web pages. Email's purpose, the author asserts, is to deliver concise information and entice clicks to richer online experiences, not to replicate those experiences within the inbox itself.
The blog post explores using Phlex, a Ruby HTML templating library, as a replacement for ERB in Rails Action Mailer. It highlights Phlex's component-based approach, allowing for reusable email templates and a more organized code structure compared to traditional ERB files. The author demonstrates how to set up Phlex within a Rails project, including configuration adjustments and creating view components specifically for emails. They showcase the benefits of using Phlex, like cleaner syntax, improved maintainability through component reusability, and a more intuitive way to manage email layouts and partials. Ultimately, the post positions Phlex as a modern alternative to ERB for building emails in Rails, offering a more streamlined and manageable development experience.
HN users generally expressed interest in Phlex as an alternative to ERB for Rails email templating, praising its cleaner syntax and potential performance benefits due to compiled templates. Some questioned the practicality of another templating language, citing the existing ecosystem around ERB and the learning curve involved. Others noted that while Phlex offered improvements, the article's benchmark showing only a 20% improvement wasn't compelling enough to justify switching. There was also discussion around the complexity of view components within emails and whether Phlex sufficiently addressed those challenges. Finally, some users compared Phlex to other templating options like Slim and wondered about the real-world performance difference, especially within the context of email rendering where other factors might dominate performance.
Summary of Comments ( 44 )
https://news.ycombinator.com/item?id=43725865
HN commenters generally agree that AMP for email was a bad idea. Several pointed out the privacy implications of allowing arbitrary JavaScript execution within emails, potentially exposing sensitive information to third parties. Others criticized the added complexity for both email developers and users, with little demonstrable benefit. Some suggested that AMP's failure stemmed from a misunderstanding of email's core function, which is primarily asynchronous communication, not interactive web pages. The lack of widespread adoption and the subsequent deprecation by Google were seen as validation of these criticisms. A few commenters expressed mild disappointment, suggesting some potential benefits like real-time updates, but ultimately acknowledged the security and usability concerns outweighed the advantages. Several comments also lamented the general trend of "over-engineering" email, moving away from its simple and robust text-based roots.
The Hacker News post titled "AMP and why emails are not (and should never be) interactive" has generated a significant discussion with numerous comments. Many of the comments express strong opposition to AMP for email, echoing the sentiment of the original blog post.
Several commenters focus on the privacy implications of AMP, arguing that it allows Google to track user interactions within emails, providing them with even more data. This is seen as a significant downside, especially considering the potential for abuse and the general lack of trust in Google's data handling practices. One commenter specifically mentions that allowing dynamic content in emails would make phishing attacks significantly easier to execute, making it harder for users to distinguish between legitimate and malicious emails.
Another recurring theme is the added complexity for both email developers and users. Developers would need to learn and implement AMP, increasing development costs and potentially leading to inconsistencies across email clients. For users, the interactive elements could be confusing or even annoying, particularly for those who prefer the simplicity of traditional email. One commenter notes the irony of Google pushing for more complexity in email while simultaneously promoting the minimalist "Inbox Zero" philosophy.
Some commenters also question the actual benefits of AMP for email, arguing that the proposed interactive features, such as completing surveys or browsing product catalogs directly within emails, are not particularly compelling and could be easily achieved through traditional links to external websites. The added complexity and privacy concerns are seen as outweighing any potential benefits.
There is also discussion about the control Google would gain over email communication with AMP. Commenters express concern that Google could potentially manipulate the functionality of AMP, favoring their own services or even censoring certain types of content within emails. This control is seen as a threat to the open nature of email communication.
Finally, several commenters express skepticism about Google's motivations for pushing AMP for email, suggesting that it's primarily driven by their desire to collect more data and further integrate their services into users' lives. They see AMP as another attempt by Google to exert more control over the internet, rather than a genuine effort to improve the email experience. The ultimate failure of AMP is highlighted by multiple commenters, bolstering the arguments against its implementation in email.