Hoje, grandes estruturas divinas estão na moda, mas são eles são saudáveis? Assim como comer fast food por conveniência, usar uma estrutura de fast food gordurosa significa que nossos aplicativos estão obesos e fora de forma. Os desenvolvedores podem produzir aplicativos muito mais saudáveis, uma vez que percebem que podem cozinhar em casa, contra as APIs nativas do navegador. Isso significa custos mais baixos, taxas de satisfação do usuário mais altas e aplicativos mais saudáveis.
O Center for Disease Controls estima mais de um terço da população dos EUA é obeso , conservador pelas minhas observações (eu me incluo na estatística). O CDC prossegue apontando os efeitos para a saúde e os custos adicionais devido ao nosso excesso de bagagem.
-As condições relacionadas à obesidade incluem doenças cardíacas, derrame, diabetes tipo 2 e certos tipos de câncer, alguns dos principais causas de morte evitável.-O custo médico anual estimado da obesidade nos EUA foi de US $ 147 bilhões em dólares de 2008; os custos médicos para pessoas obesas foram $ 1.429 mais altos do que aqueles com peso normal.
O CDC continua apontando que a obesidade afeta mais grupos étnicos e etários específicos. Os grupos étnicos se correlacionam mais com renda mais baixa, demografia menos instruída e cidadãos mais experientes.
O desenvolvimento da web de hoje tem um perfil semelhante. Os sites são gordos e apresentam a doença de uma experiência ruim. Esse excesso de peso cria overheads indesejados e atrasos no desenvolvimento. Também podemos apontar alguns dados demográficos da plataforma como problemáticos: WordPress, aplicativos corporativos e aqueles que usam frameworks god.
Como chegamos a este ponto?
Comemos fast food porque sentimos apressado. A comida é muito saborosa porque esquecemos o sabor dos alimentos frescos. Comer fora não é tão saudável quanto comer em casa. Isso, combinado com um estilo de vida sedentário, resultou em uma população moderna muito obesa. Os sites estão sofrendo um destino semelhante.
Desenvolvedores e arquitetos escolhem estruturas de fast food por motivos semelhantes. A maioria dos desenvolvedores esquece como é conversar com APIs nativas e acha que é difícil escrever um aplicativo enxuto. Muitos não reservam tempo para aprender coisas novas e, por isso, ficam sobrecarregados quando se trata de criar experiências modernas para o usuário da web.
Reservei um tempo para encontrar links para gráficos de nutrição de muitos restaurantes populares de fast food nos Estados Unidos. Nada do que eu peço cairia nas minhas diretrizes saudáveis.
As refeições de valor vêm com batatas fritas e uma Coca-Cola. Calorias, gordura, açúcar e muito poucas coisas boas de que precisamos. Meu palpite é que o pedido de fast food pessoal típico contém entre 12-1600 calorias. Já ouvimos essa mensagem há várias décadas, mas ainda visitamos lugares de fast food quase todos os dias. Fazendo algumas pesquisas, o adulto típico precisa de 2.000 a 3.500 calorias por dia, dependendo da idade, peso e nível de atividade.
Então, por que estou falando sobre americanos gordos e dieta saudável em uma postagem do blog sobre estruturas JavaScript?
Existem muitas correlações com a web de hoje, ela é gorda e fora de forma. Isso torna o desenvolvimento de sites mais caro e difícil de manter. Minhas experiências e interações nos últimos anos me deixam confiante para dizer que a maioria dos que se autodenominam desenvolvedores web não tem conhecimento de desenvolvimento web. Em vez de aprender a plataforma (HTML5, JavaScript e CSS), eles procuram soluções de fast food ou frameworks divinos.
Os mais recentes as estatísticas mostram o tamanho médio da página da web em cerca de 2 MB. Muito baixo com base em minhas observações. Minhas estimativas estão próximas de 5B. A divisão de peso do HTTPAchive é semelhante a:
- 59kb HTML
- 304kb JavaScript
- 62kb CSS
- imagens de 1,3 MB
No ano passado Angular, Ember e O backbone parecia ter a atenção de todos no espaço do JavaScript . Bootstrap tinha CSS bloqueado . Este ano parece que o React está recebendo toda a atenção. Em anos anteriores, ouvimos nomes como jQuery, Prototype, MooTools, etc. Todos eles vieram e se foram e deixaram cicatrizes como seu legado. O que não mudou, mas apenas melhorou, foi o VanillaJS , as APIs nativas.
god Framework Weights
- jQuery 2.1.3-83kb
- jQuery 1.11.2-94kb
- Angular 1,314-123kb
- Ember 1,10-373kb
- Backbone-20kb + 17kb (sublinhado)
- React 1.1.2-130kb (núcleo, apenas a funcionalidade de modelos)
- React + Complementos-270kb
- Bootstrap-220kb
É claro que cada um dos frameworks oferece um ecossistema de extensões que a maioria dos aplicativos aproveita, adicionando ainda mais peso à base do aplicativo. Esta é a refeição de valor extra do desenvolvedor da web, superdimensionada.
As probabilidades são de que os aplicativos raramente usem 90% do que um framework oferece. Eles estão cheios de gordura de código e açúcar sintático. As páginas da web são pesadas e lentas e constantemente lemos que a web não pode competir com os aplicativos nativos. Essa percepção se deve aos aplicativos lentos e complicados que criamos. Quando eu construo um aplicativo da web, um dos meus objetivos é construir uma experiência superior a uma contraparte nativa. Acho que é bastante simples e intuitivo porque uso as APIs nativas, o que significa que não preciso depender de uma grande estrutura god.
HTTPArchive arquiva o site de uma página da web média pesquisando centenas de milhares a cada mês. Ele compila dados e cria uma análise do que compõe uma página da web típica hoje. Acabamos de ultrapassar a marca de 2 MB, uma realização embaraçosa. A página da web média que encontro usando ferramentas como WebPageTest ou apenas as ferramentas de rede do meu navegador pesa bem mais de 5 MB.
Este peso está quebrado em 2 categorias distintas, tamanho do arquivo e número de solicitações http. Há anos sabemos que arquivos menores carregam mais rápido. Também sabemos que sites mais rápidos usam menos solicitações http para carregar. Essa experiência inicial de carregamento é crucial porque as pessoas não gostam de esperar. Na verdade, se você não estiver totalmente carregado em 3 segundos, você perdeu mais da metade de seus clientes em potencial .
Eu faço um esforço extra para carregar meus aplicativos em 1 segundo em banda larga. Através de uma conexão de celular eu atiro por menos de 5 segundos. Isso significa uma pequena carga útil de HTML, um único arquivo CSS pequeno e um arquivo JavaScript igualmente pequeno. A partir daí, depende do número de imagens necessárias para conduzir a experiência do usuário. Mesmo aqueles que utilizo ferramentas de otimização para torná-los o menor possível. Os carregamentos subsequentes são instantâneos ou tão rápidos quanto o instantâneo pode ser se o usuário tiver que esperar o navegador para iniciar (inicialize se desejar).
Como os frameworks de deus são grandes e gordos, não posso cumprir esses objetivos. A maioria leva entre 700-1500 ms para carregar e algumas vezes eu os registro perto de 3 segundos. Além disso, todos devem ser avaliados pelo navegador , atrasando ainda mais o tempo de carregamento. Para a maioria dos sites populares, isso é agravado apenas por scripts de análise e publicidade de terceiros mal escritos. Raramente encontro esses scripts carregados e executados dentro de um orçamento de desempenho desejado.
Embora a intenção do açúcar sintático seja tornar o código mais fácil para os humanos entenderem quando um framework’inventa’uma sintaxe que um desenvolvedor e uma empresa devem aderir a essa estrutura com um compromisso de longo prazo. frameworks JavaScript têm um histórico documentado de idas e vindas . Se você voltasse e olhasse as estruturas populares de 2008, veria uma lista de nomes há muito esquecidos. Apenas jQuery sobrevive e está em declínio hoje. No ano passado, o Angular era o rei da colina, apenas se destacando ao anunciar o 2.0. As previsões deste ano estão animando o React.
Os desenvolvedores aprendem a trabalhar com essas estruturas em vez das APIs nativas. Depois de entrevistar e conversar com muitos desenvolvedores no ano passado, estou bastante certo de que a maioria dos desenvolvedores corporativos não pode selecionar um elemento sem jQuery. A maioria dos desenvolvedores corporativos nunca ouviu falar de localStorage ou percebeu que os navegadores suportam a geolocalização nativa por mais de 6 anos. Em vez disso, um desenvolvedor ou uma empresa se compromete com a estrutura du jour pensando que eles têm segurança no emprego ou que seus aplicativos serão mais baratos de construir e manter. Meu amigo Chander chama isso de RDD (Resume Driven Development).
Em vez disso, eles acabam com grandes bagunças que devem ser arrancadas um ou dois anos depois. Se você acha que estou mentindo, deveria ver quantas solicitações passaram pelo meu caminho para ajudar a extrair o Angular, e nem estou tentando oferecer esse serviço ainda.
A promessa de conveniência e uma quantidade conhecida em um suposto preço barato atrai muitos arquitetos seniores e gerentes de desenvolvimento a escolher uma dessas estruturas de fast food. Para ser justo, o tomador de decisão empresarial típico não tem ideia de como construir um cliente front-end. A atitude que tenho lutado desde que o primeiro aplicativo móvel, 5 anos atrás, é o front-end, é simples e deve ser colocado junto. Isso não é verdade.
As empresas vão até a janela do fast food e pedem uma refeição superdimensionada para o front-end, pensando que estão economizando tempo e dinheiro. Os desenvolvedores sentem que estão escolhendo uma sensação de segurança no emprego. Ambos estão sendo enganados porque nenhum deles está seguindo uma dieta saudável de desenvolvimento da web. A empresa obtém um aplicativo pesado e fora de forma que precisará passar por uma cirurgia laparoscópica um ou dois anos depois, se não sucumbir ao equivalente binário do diabetes.
O que as empresas podem fazer?
Eu escolho enterprise porque esta é a classe que parece mais afetada por esses frameworks de deus, mas isso se aplica a qualquer projeto de desenvolvimento web. Todos nós queremos códigos que possamos manter e desenvolver. Mas os usuários finais mandam, o que significa que precisamos de velocidade e desempenho. Em vez de aprender a estrutura de hoje, aprenda as APIs nativas e como criar um módulo e estruturar seu aplicativo. Os frameworks fornecem uma abordagem opinativa para uma arquitetura de aplicativo, uma tentativa de resolver os problemas de todos. Seus problemas não são de todos. Você precisa usar as APIs nativas em algum momento e eu incentivo as empresas e os desenvolvedores da web a começarem a cozinhar refeições caseiras em vez de comer código de fast food. Estas são algumas etapas simples para ajudá-lo a chegar lá.
Defina um orçamento de desempenho
Defina um orçamento de desempenho e torne-o parte de sua construção fluxo de trabalho para responsabilizá-lo. Tim Kadlec definiu um orçamento de desempenho como:
Um orçamento de desempenho é exatamente o que parece: você define um “orçamento” em sua página e não permite que a página o exceda. Este pode ser um tempo de carregamento específico, mas geralmente é uma conversa mais fácil quando você divide o orçamento no número de solicitações ou no tamanho da página.
Por exemplo, eu trabalho para atingir um tempo de carregamento de 1000 ms para todos os meus aplicativos. Isso ocorre porque a mente começa a se maravilhar em 1 segundo, ou o usuário começa a perder o foco e sua mente fica pensando em outra coisa ou desenvolve ansiedade. Se você acha que eles perdoam mais os dispositivos móveis, você está errado, muitos esperam que ele carregue mais rápido em seus telefones do que no desktop. Eu consigo isso gerenciando o tamanho dos meus ativos e o número de solicitações.
Definir um orçamento de desempenho é semelhante à minha meta pessoal de perder mais de 60 libras em 6 meses. O ponto de partida foi ver o quanto eu pesava, muito e mais do que acreditava. Quando eu mostro aos clientes as cachoeiras e os horários de seus sites, eles geralmente ficam em choque. A maioria dos proprietários de sites pensa que eles estão carregando rapidamente, mas a realidade é que eles estão carregando em 8, 10, 20 segundos ou mais. A maioria dos sites que perfilo tem centenas de solicitações HTTP e bem mais de 5 MB completos. Para comparar com meus aplicativos, um total de aplicativos típico é inferior a 200kb, mas pode variar de acordo com o número de imagens que estão sendo usadas.
Desde 7 de janeiro, tenho me pesado todas as manhãs em condições semelhantes. Acompanhei meu peso e comecei a relacioná-lo com atividades e refeições. Minha perda de peso se tornou mais pronunciada. Definir um orçamento é o primeiro passo, medir as mudanças é o próximo. Você não conseguirá cortar a gordura do seu site durante a noite, isso levará tempo.
A primeira etapa é agrupar e minimizar todo o JavaScript e CSS em 2 solicitações HTTP. A partir daí, comece a comer menos, eliminando scripts e CSS não utilizados. Acompanhe as mudanças e mantenha a tendência de queda até atingir seu objetivo. Tenho dias em que ganho peso, mas principalmente perco. Você deve ter uma experiência semelhante com seus esforços de desenvolvimento da Web.
Aprenda as APIs nativas
Remover frameworks e bibliotecas é assustador se você nunca cozinhou para si mesmo. Reserve um tempo e aprenda como usar APIs nativas. Aprenda como selecionar elementos sem jQuery e, em seguida, como manipular o DOM nativamente. Eu amo o site You Might Not Need jQuery porque ele demonstra como é simples executar funções jQuery comuns, incluindo AJAX, nativamente. Hoje você não precisa mais se preocupar com navegadores legados ou diferenças entre navegadores. No próximo ano, o problema do IE 8 deve ser esquecido , saindo apenas um cenário de navegador moderno.
Ao cozinhar para você mesmo, você possui o seu código e pode resolver os problemas melhor. Você economizará tempo e dinheiro no desenvolvimento inicial, bem como na manutenção de longo prazo. Menos código significa menos esforço e significa maiores taxas de satisfação do usuário. Com o tempo, você ainda terá menos código e desenvolvedores melhores.
Resumo
Fizemos a web à nossa imagem, obeso . Não sou a primeira pessoa a dizer isso, mas soa verdadeiro. A web tem obesidade mórbida e precisa fazer dieta. Os desenvolvedores não sabem cozinhar para si próprios. As estruturas de deus do Fast Food estão aproveitando os tomadores de decisões empresariais para fornecer plataformas de aplicativos com alto teor de gordura e calorias. Desenvolvedores e empresas estão perdendo um jantar saudável à noite com a família e como cozinhar para si mesmos. Reduzir o tamanho dos aplicativos os torna mais ágeis, rápidos e fáceis de manter. O custo para construir um aplicativo estilo Vanilla JS ou Micro JS é o mesmo e geralmente menor do que um construído usando uma estrutura popular. As APIs do navegador raramente mudam, elas apenas ficam melhores. As estruturas estão aqui hoje, acabam amanhã e deixam para trás um rastro de tecido de gordura cicatrizado e aplicações prejudiciais à saúde que morrem ou precisam de muito trabalho para se manterem vivas. Aprenda a cozinhar em casa e a evitar lanchonetes de fast food. Depois de aprender a usar as APIs nativas, você nunca mais vai querer usar um framework fat god novamente.
