|
|
|
|
|
|
by pushcx
476 days 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. |
|
|
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.