Problema de performance em páginas grandes.

Se você tem muitos dados, não pensou em fazer paginação? Se paginação não for suficiente, terá que usar outra estratégia.

A solução ensinada por mim no curso é funcional e simples, voltada para que o aluno aprenda OO, funcional, padrões de projetos sem pegar pesado no projeto. Não é uma solução que eu usaria em produção, pois eu seria o responsável em manter todo o código. Eu prefiro usar frameworks de terceiros.

No entanto, para você receber essa mensagem que você esta recebendo, deve ter alguma coisa diferente no seu código, algum gagá-lo que não seja o innerHTML. É algo a se investigar antes de descartar o uso da solução.

Se você esta fazendo um SPA com essa estratégia, ela não cobre zilhões de coisas como o deregister de listeners, mutações de DOM, etc, router, etc.

Aliás, não tem como um código de umas 200 linhas fazer o que Angular ou React com mais de 100.000 linhas fazem, né :)

A boa notícia é quando você for usar esses frameworks, ficará bem à vontade porque entenderá a motivação de muita coisa.

Fiz alguns testes por aqui e o que está demorando os 2.5 segundos é o template string, justamente porque ele refaz a página toda. E não o innerHTML mesmo.

Já percebi boa parte da motivação do Angular. Sobre deregister de listener (essa foi uma das modificações do seu padrão).

Tô achando que vou acabar usando o vue.js, fiz seu outro curso e gostei muito também.

Pois é, o Vue.js é o mais acessível de todos. Aliás, há dois cursos que criei para a plataforma Alura que dá uma base bem sólida.

Agora, se quiser investir em uma solução caseira, você precisa fazer igual ao que o React faz. Ele renderiza tudo, mas com o auxilio de um virtual DOM. Há uma biblioteca que você pode tentar incorporar no seu código e gerar apenas as mutações necessárias.

https://github.com/fiduswriter/diffDOM

Sucesso e bom estudo, meu aluno!

Se puder depois compartilhar no github o código. Só não prometo ver por agora, mas fiquei curioso para ver até onde você ampliou a solução.

Abração!

Olá Flávio/colegas, vai ser um pouco complicado eu compartilhar. Mas acho que não era nada relevante.

Só um adendo, estou migrando para Vue.js e ao enfrentar um problema com um plugin do jquery (inputmask) que eu usava para formatar valores monetários. Eu usei a API do ecmascript para isso. Eureka, descobri o motivo da lentidão, mesmo assim vou continuar a migração para o Vue.

Obrigado pelo feedback!

Então, para ficar claro aqui. o problema não era no innerHTML nem na template string, mas no código de validação, era isso?

O sistema ainda é um protótipo não funcional. Logo extrapolei os dados. Há uma lista com 150 objetos javascript que usando template string gero uma tabela responsiva, o problema é que 5 campos de cada linha são float e devem ser formatados para dinheiro (###.##0,00). O que ocorre é que aproveitei um plugin do Jquery que uso para formatação dinâmica dos inputs para fazer a formatação de float para string (esse plugin também faz isso). Mas descobri (por conta da migração para o vue.js), que esse plugin não faz isso com uma performance muito boa. Fiz a substituição abaixo:

const formatter = new Intl.NumberFormat('pt-BR', {
  style: 'currency',
  currency: 'BRL',
  minimumFractionDigits: 2,
});


export class Helper {

    constructor() {
        throw new Error('Esta classe não pode ser instanciada');
    }

    static formatReal(vl) {
//        return Inputmask.format(v, { alias: "realBrasileiro"})
        return formatter.format(vl);
    }
}

Depois disso tudo ficou muito rápido. Usei um formatador do ecmascript, agora tenho que me preocupar com compatibilidade, pois acho que o Babel.js não resolve esse cara.