joeldrapper

There is an experimental feature that allows you to use ERB templates like ViewComponent. https://github.com/phlex-ruby/phlex/pull/867

It’s because that’s how constants are named in Ruby. The method names match the constant names of the component classes.

This is nonsense. You can cache it like anything else. But you probably won’t need to because it’s so fast.

In my experience, it’s not an extreme scenario to render several thousand components in a single view.

I think you’re looking at this from the perspective of having maybe a partial for your header and another for your footer. The way you build views in Phlex is you would have a component not just for the header but also the nav, each item in the nav, and each icon in each item.

We can argue about whether that level of abstraction and reuse is worth it, but the fact is ActionView gets very slow when you build views like that composing thousands of partials — and for people who want to build views like that, it matters.

Still, I think these “12× faster” comparisons are silly. If ActionView was just as fast at rendering thousands of small components, I’d still pick Phlex for the developer experience. I enjoy writing Ruby, not toggling between Ruby and HTML.

I believe Clearscope is the largest app using Phlex views exclusively, with 454 components and counting. There’s a list of some other users here. https://www.phlex.fun/project/community.html#who-s-using-phl...

It probably is (or at least was) faster than ActionView if you use lots of small partials, but it is not faster than ERB since it is not compiled. It generates HTML at about 1.6gbps per core on my laptop so probably fast enough for most things.

They’re not in the root namespace. They are instance methods (on the instance of the component) that start with a capital letter. https://www.phlex.fun/components/kits.html

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

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.

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

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

Ruby has blocks, so in Phlex, you’d write it like this using methods and keyword arguments.

  div(class: "example") do
    h1(id: "heading") { "This is an example" }
    h2 { "creating React markup" }
    AnotherComponent(foo: "bar") do
      li { a(href: "http://whatever.com") { "One list item" } }
      li do
        text " Another list item"
        hr
      end
    end
  end

You can avoid transpiling if you write views in pure Ruby instead. Ruby syntax has everything you need to concisely represent all valid HTML — method calls are tags, keyword arguments are attributes and blocks are content.

I count at least 17,800 requests for this feature. https://www.google.com/search?q=%22WIP%22+inurl%3Apull+site%...