optimization: inline static markup

[ottomated]

Describe the problem

Say I have a component with a bunch of markup rendered from a static array:

<script>
  const episodes = [{name: 'foo', length: '10:00'}, /* ... 100 more episodes */];
</script>

<ul>
  {#each episodes as episode}
    <li>{episode.name} - {episode.length}</li>
  {/each}
</ul>

This generates JS that looks something like:

function Component($$anchor) {
  const episodes = [{ name: 'foo', length: '10:00' } /* ... 100 more episodes */];
  var ul = root();
  $.each(ul, 21, () => episodes, $.index, ($$anchor, episode) => {
    // etc...
  });
}

This has to do all the work of iterating through the array, and also create all the associated signals.

Describe the proposed solution

If a local variable is never mutated, svelte should detect that and generate something like the following:

$.from_html(`<ul><li>foo - 10:00</li></ul>`);
// large `episodes` array is not included in the generated code!

Importance

nice to have

[Ocean-OS]

Thank you for writing this but I don't think it will be acted upon. While static analysis is a powerful tool, it cannot feasibly perform certain optimizations, such as working with objects. Someone could, for example, do something like this:

let arr = [1, 2, 3];
let clone = (() => { 1; return arr; }());
clone.push(4);

and try to use arr in an #each block. If static analysis wasn't thorough here, it wouldn't be able to identify that arr is mutated, and incorrectly use [1, 2, 3] in the compiled output. If static analysis was powerful enough to do this correctly, we'd have a bunch more things to worry about, such as adhering to the TC39 spec. If you want to see something that is powerful enough to do things like this, take a look at Prepack. Although it is abandoned, it can do optimizations to the level that you're describing. Additionally, although it's nowhere near as complex as Prepack, you could check out this (rejected) PR I made a little while ago that tried to add some rather powerful partial evaluation to Svelte, #15802. It also includes a very good comment from Rich, explaining why it was closed and adds on to this comment well.

[ottomated]

Good points, I followed up in #16296 for a similar solution that should be more doable