Livecoding EEx template improvements (twitch livestream)

Yeah, sending ,"... segment ..." is slightly less data than index:"... segment ...". That’s what I meant. And for a flat array I can have even more effucient encodings.

This is amazing. I can’t believe I’ve missed this optimization! This is probably bigger than my inline stuff. It requires a slightly smarter Javascript client, of course, but it’s a great idea.

And one I can implement in Vampyre, too.

Are you sure you eant to apply this optimization on regular rendering? This makes the initial render dependent on Javascript, which I’m not sure is a good idea.

I wanted to say the first rendering for the JS client. Good catch.

@josevalim, do you already have a strategy to optimize form_for/4 without turning it into a macro? I’m extremely curious about what you’ll come up with

We will go with the simplest approach for now which is to convert this:

<%= form_for @changeset, ..., fn -> %>
  <%= text_input f, :name %>
<% end %>

into this:

<%= f = form_for @changeset, ... %>
  <%= text_input f, :name %>
</form>

Effectively removing the nesting. Not the prettiest thing but definitely the simplest that works.

Hm… I don’t see how this can work. How is it possible that f is simultaneously a %Phoenix.HTML.Form{} struct and a binary containing the opening <form> tag, the CSRF token and the other hidden input tags that forms in Phoenix have?

You’d have to define something like:

<% f = Phoenix.HTML.FormData.to_form(@changeset) %>
<%= form_tag f %>
  <%= text_input f, :name %>
</form>

which I actually prefer instead of your version above.

On further thought, I wonder if optimizing forms is such a big deal. With the lack on inlining, it’s possible that you don’t gain much if you’re not inlining segments (which Vampyre can do but LiveEEx can’t - at least not yet). After all, forms in phoenix depend a lot on HTML generating functions. For example, let’s look at an example of a form generated by a Phoenix generator:

<%= form_for @changeset, @action, fn f -> %>
  <%= if @changeset.action do %>
    <div class="alert alert-danger">
      <p>Oops, something went wrong! Please check the errors below.</p>
    </div>
  <% end %>

  <%= label f, :field1 %>
  <%= text_input f, :field1 %>
  <%= error_tag f, :field1 %>

  <%= label f, :field2 %>
  <%= text_input f, :field2 %>
  <%= error_tag f, :field2 %>

  <%= label f, :field3 %>
  <%= text_input f, :field3 %>
  <%= error_tag f, :field3 %>

  <div>
    <%= submit "Save" %>
  </div>
<% end %>

The only static segments inside the form are sequences of whitespaces, <div> and </div> at the end. Also, almost all of the dynamic segments depend indirectly on the changeset. And on f, of course. LiveEEx doesn’t have a way of determining which fields to update when f (or @changeset) changes, so it will have to regenerate all widgets which depend on f, which are all of them.

You will also have to regenerate the CSRF token, unless you mark that as static somehow, as well as the other hidden input tags.

If you’re going to have to generate almost the whole form, maybe it’s not worth it to optimize that part.

On the other hand, in Vampyre I can optimize most almost all input fields to mostly static data with just 3 dynamic segments, with most of it being static.

<input name="<%= form.name %>[field1]" id="<%= form.name %>_field1" value="<%= form_value(form, field) %>">

And the form.name segments can be optimized into static segments if we assume that the form shape won’t change (which is pretty much true for almost all forms).

PS: I’ve just noticed on reviewing my code that my form_for macro doesn’t support setting the value attribute yet, but supporting it is a very minor change.

We just need to implement Phoenix.HTML.Safe for it.

It is most likely that actual user forms are more complex than this. It also serves as a good example on how to handle nesting and it opens up the possibility to explore other approaches later.

I think if there is a lesson in this whole discussion is that starting simple allows us to incrementally improve based on new ideas, feedback, etc. If I had started thinking about how to optimize comprehensions, we may have ended-up with a more complex solution and very different than the one today. I am happy to go with baby steps.

Well, it goes both ways xD If I had started thinking about how to optimize for comprehensions (instead of quitting), I’d have stumbled upon your solution about 1 month ago It’s a natural consequence of trying to do things at compile time, because we can take advantage of the fact that for is a special form that can’t be overriden, so it can be analyzed statically.

But I believe we may have started with different priorities.

You had @chrismccord’s example from the LiveView talk and and maybe optimizing such dynamic highly dynamic templates was a priority for you.

I started thinking about (mostly static) forms and how to optimize those, because those are the ones I saw myself using the most, especially the part of having real-time form validation without writing any JS. That brought me naturally close to the idea of inlining static parts and merging adjacent binaries together. Yes, live tables that could update in response to typing in a search field were cool, but I had already given up on those

I’m the first to praise the simplicity of your implementation but I think most of the complexity with my approach is unavoidable. It’s the result of implementing an optimizing compiler (although a very simple one) that tries to separate the static and dynamic parts in a very obsessive way.

The other main source of complexity with my approach is probably the attempt to maintain backward compatibility with Phoenix.HTML, which contains some things that are not very easy to optimize statically. The tag() function, in particular, is a bit weird, and I should probably break compatibility so that it can be abetter building block for the rest. If I can encapsulate most of the complexity inside the tag() macro (because I need it to be a macro), thins will probably be much simpler in the rest of the code base.

I don’t consider this “premature” optimization, because it’s essential for my main goal, which is to send the absolute minimum amount of data over the network for things like forms.