O que a regra do menor poder significa para desenvolvedores modernos

Bryan Robinson Blocked Desbloquear Seguir Seguindo 21 de dezembro de 2018

O poder do desenvolvimento web de front-end está crescendo a um ritmo constante. Podemos fazer coisas com HTML, CSS e JavaScript com as quais poderíamos sonhar há cinco anos.

Com todos os novos recursos, é natural querer alcançar a ferramenta mais poderosa para qualquer tarefa. Essa é a melhor política?

Mais frequentemente do que não, é problemático. De fato, os criadores da web pensaram sobre essa eventualidade. Tim Berners-Lee e Noah Mendelsohn escreveram um documento chamado “ A regra do menor poder ” (RLP) em 2006.

Ao projetar sistemas de computador, frequentemente se depara com uma escolha entre usar uma linguagem mais ou menos poderosa para publicar informações, para expressar restrições ou para resolver algum problema. Este achado explora as compensações relacionando a escolha da linguagem com a reutilização da informação. A "Regra do Menor Poder" sugere escolher a linguagem menos poderosa adequada para um determinado propósito.

Por que a linguagem do menor poder?

Pode parecer que o W3C quer torturar desenvolvedores da web. Por que sugerir que um desenvolvedor não use a ferramenta mais forte para o trabalho?

Berners-Lee e Mendelsohn propuseram que o poder e a flexibilidade estão inversamente relacionados. À medida que a energia cresce, a capacidade de analisar a saída diminui.

Eles viam o futuro da web como algo construído a partir de peças reutilizáveis. Muitos dispositivos e aplicativos podem ler os dados, usá-los e combiná-los de várias maneiras.

As informações publicadas na Web podem ser flexivelmente combinadas com outras informações, lidas por uma ampla gama de ferramentas de software e navegadas por usuários humanos da Web.

Em outras palavras, a web é um mundo de remixes infinitos.

Isso é algo que deve apelar para nossas sensibilidades modernas. Modularidade sobre integração. Componentes sobre páginas.

O que isso significa para um desenvolvedor moderno?

O estado da regra do menor poder no desenvolvimento web moderno

Em alguns casos, a regra do menor poder está em jogo no desenvolvimento moderno da web. Conceitos como modularidade, componentes e pacotes são estruturas modernas. Eles também são conceitos-chave de uma web reutilizável, como Berners-Lee e Mendelsohn discutiram.

Com isso, você pode pensar que estamos alinhados com essa filosofia. Eu vejo uma quantidade surpreendente de “melhores práticas” modernas que parecem estar em desacordo com essa filosofia, no entanto.

Não acredita em mim?

Eu gostaria de apresentar três cenários. Cada cenário será cada vez mais controverso.

Cenário 1: Descrevendo dados para seu aplicativo

Esse cenário deve ser óbvio para a maioria dos desenvolvedores de JavaScript modernos.

Quando você deseja descrever dados para seu aplicativo, como e onde você deve criá-lo?

Aqui estão suas opções: crie variáveis dinamicamente em seu código funcional ou crie um objeto de dados.

Vejamos como criamos dados conforme você precisa em seu código funcional.

Neste exemplo, construímos nossos dados dentro de nossa função com declarações de variáveis e, em seguida, usamos imediatamente os dados:

Neste exemplo, temos código funcional. Isso faria o trabalho. Nossos dados seriam reutilizáveis? Não. Esses dados viveriam para sempre nessa função.

Em vez disso, criamos um objeto de dados. Isso pode ser o resultado de um endpoint RESTful, uma chamada GraphQL ou apenas um arquivo de dados simples.

Esse objeto de dados representa os mesmos dados, mas é infinitamente analisável e reutilizável:

Este é um exemplo de JavaScript Object Notation (JSON), com o qual a maioria dos desenvolvedores JS é familiar. As funções JSON são a espinha dorsal da maioria dos nossos aplicativos.

Este é um exemplo do que o RLP chama de "famílias de linguagem escalonáveis".

Especificamente, o JSON fornece o uso independente de um subconjunto declarativo da sintaxe de declaração literal da linguagem JavaScript. A padronização de subconjuntos de idiomas pode facilitar modelos simples para publicação na Web, ao mesmo tempo em que permite a integração com variantes de linguagem mais poderosas quando necessário.

Traz os benefícios de uma linguagem declarativa e combina com os benefícios de poder de JS.

A maioria dos desenvolvedores concordará com essa configuração. Dados em uma camada de dados em JSON; aplicação escrita em uma poderosa linguagem de programação.

O que torna isso o melhor resultado possível é a portabilidade dos dados. Os dados podem ser consumidos pelo aplicativo JavaScript que você planejou hoje. Ele também pode ser consumido por um aplicativo futuro que você ainda precisa escrever ou você pode abrir esses dados para outros usuários para escrever novos aplicativos.

Essa separação de interesses abre todas essas portas.

Esse é o cenário menos controverso. Vamos dar um passo para um novo exemplo, um pouco mais controverso.

Cenário 2: Servidores

Assim como devemos buscar o mecanismo menos poderoso para conter nossos dados, devemos procurar o servidor menos poderoso para entregar nosso aplicativo ou site aos nossos usuários.

Neste caso, não estou me referindo a RAM e processador. Quero dizer, devemos usar o servidor com a menor complexidade de software.

Nos dias da web emergente, os servidores eram qualquer computador conectado à Internet que servia páginas HTML. Simples.

Como a necessidade de mais conteúdo dinâmico se tornou maior, o mesmo aconteceu com as necessidades do nosso servidor. Agora precisávamos de um banco de dados. Precisávamos de linguagens de programação para acessar, manipular e armazenar os dados. No final, tudo isso acabou servindo documentos HTML para o navegador (se ignorarmos os tempos sombrios dos applets Flash e Java).

Há um grande experimento acontecendo agora. Há um movimento moderno de site estático. Eu sou um forte defensor desse movimento.

Sites estáticos costumavam significar colocar um monte de arquivos index.html em um servidor. Essa nunca foi a metodologia mais amigável para desenvolvedores. Agora temos todas as nossas conveniências modernas e uma ótima saída estática. Nós movemos a complexidade do servidor para o ambiente de desenvolvimento.

Tenha em mente que você ainda pode usar sua linguagem de programação preferida. Você só usa localmente, constrói os arquivos e publica em um servidor sem linguagens de script.

Por que isso?

  1. Como é apenas HTML sendo veiculado, isso nos dá downloads impressionantes
  2. Isso nos dá menos falhas de segurança, já que não há banco de dados nem linguagem de script
  3. Isso torna nossa aplicação altamente portátil e reutilizável – encontrar hospedagem incrivelmente barata para arquivos estáticos é muito simples

Quando sites estáticos não são suficientes

Essa abordagem se torna mais problemática quando você precisa de um servidor para processar alguma coisa. Se este é um local para armazenar com segurança chaves de API, processar um formulário ou aceitar pagamentos.

É aí que entram as funções “sem servidor”. É um pouco errôneo, mas essas funções são alugadas no servidor de outra pessoa. Ele tende a ser um recurso de baixo custo e baixa manutenção para fornecer esse tipo de funcionalidade.

O futuro da sua aplicação

Se você estiver gerenciando seu próprio servidor para o seu aplicativo, por todos os meios, mantenha esse servidor. Raramente há um ponto em um grande refatorador quando as coisas estão funcionando atualmente. Você pode começar já a aproveitar esse futuro em potencial.

Se você tratar seu servidor como uma série de endpoints em vez de uma máquina destinada a servir todo o aplicativo, poderá aproveitar o poder de sites estáticos com sua configuração atual. Se você conseguir dissociar sua lógica de back-end da sua camada de apresentação de front-end, poderá obter as vantagens que mencionei acima sem começar completamente.

Se você está começando do zero, definitivamente vale a pena olhar para uma arquitetura “sem servidor”. Utilizando princípios da regra de menor potência, ganhamos portabilidade e flexibilidade – sem mencionar custos mais baixos, velocidades mais altas e desenvolvedores front-end mais felizes.

Esse cenário se tornará menos controverso nos próximos anos, à medida que as ferramentas se tornarem cada vez mais fortes.

Meu próximo cenário tornou-se um tema bastante quente nos últimos dois anos.

Cenário 3: A Santíssima Trindade do desenvolvimento web

Desenvolvimento web tradicional vai um pouco algo como isto:

  1. O servidor recebe uma solicitação
  2. O idioma do servidor manipula o pedido e agrupa o HTML que envia ao navegador
  3. O navegador adora isso
  4. Ele cria o DOM e, em seguida, permite que o CSS e o JS sejam executados com esses elementos DOM
  5. CSS estiliza-os
  6. JS torna-os interativos
  7. Páginas lindas e interativas acontecem!

Essa metodologia foi perfeitamente razoável para o seu tempo. Depois veio o iPhone e a apresentação de aplicativos. Todo proprietário ou cliente de projeto queria que seu aplicativo fosse tão bom quanto um aplicativo iOS. A resposta para isso parecia simples: JavaScript.

Mais recente, mais "moderno" assume o desenvolvimento da web, muitas vezes parece algo mais parecido com isto:

  1. O servidor recebe uma solicitação
  2. Envia o mínimo absoluto de marcação possível (a <head> e possivelmente <div> no <body>)
  3. JS assume, cria o DOM, estiliza o DOM, torna o DOM interativo
  4. Páginas lindas e interativas acontecem!

Permitir que o JavaScript lide com essa sobrecarga cria páginas que se parecem cada vez mais com aplicativos. Eles são altamente interativos. Cada “carregamento de página” subsequente é geralmente instantâneo, em vez de fazer uma nova solicitação do servidor. Podemos carregar segmentos de conteúdo com animações incríveis.

Esses sites e aplicativos são sempre incríveis. Eles se sentem ótimos para usar.

Certamente, com sua proeminência e interações lisas e grande usabilidade, eles têm que ser o caminho a percorrer!

Se nos referirmos à Regra do Menos Poder, porém, percebemos muito rapidamente que este método viola-lo.

O problema

Se olharmos para a Santíssima Trindade do desenvolvimento web – HTML, CSS e JS – é fácil ver a hierarquia de poder. HTML é uma linguagem semântica declarativa. Isso significa que não há poder programático e cada um deles descreve um tipo de dado. CSS também é declarativo. Tem mais poder do que HTML, mas apenas o suficiente para fazer o seu trabalho.

JS é uma linguagem de programação. Pode ser usado para fazer pequenas coisas ou coisas incrivelmente grandes e complexas. É facilmente o mais poderoso dos três idiomas.

No segundo fluxo de trabalho, usamos a linguagem mais poderosa disponível para fazer todo o trabalho.

Por que isso é um problema?

Como o DOM é criado pelo JS, por padrão, os dados são menos analisáveis. HTML cria uma árvore de dados analisável. Esses dados podem ser consumidos por qualquer número de aplicativos.

  • O navegador pode convertê-lo para o DOM
  • Os bots do Google podem rastreá-lo sem esforço
  • Os leitores de tela podem lê-lo
  • No futuro, os assistentes de voz poderão lê-lo

É verdade que os bots e os leitores de tela do Google são melhores em renderizar JavaScript do que costumavam ser. Você tem que se perguntar, eles são bons o suficiente?

Se você se pergunta isso, já está à frente de muitos desenvolvedores.

Se você está preocupado com essas coisas, você deve procurar em testes. Se você pensou que os testes contra as duas últimas versões dos navegadores foram difíceis, isso não deve soar empolgante para você.

A solução

Pense em " Markup-First Development ".

Em primeiro lugar, renderize HTML significativo para o navegador. Isso cobrirá você para leitores de tela, bots e navegadores antigos que lutam com o JavaScript moderno.

Eu posso ser um velho fogy, mas eu amo escrever HTML. Eu entendo se não é sua atividade favorita. Eu entendo se você escreve JavaScript porque gosta de escrever JavaScript.

Nesse caso, você ainda pode pensar no Markup First. Certifique-se de que seus aplicativos são pré-criados. Existem serviços , frameworks e hosts que podem fazer isso para você com o mínimo de esforço. Escreva em sua estrutura favorita – seja Vue, Angular, React, etc. – e, em seguida, exiba conteúdo renderizado pelo servidor e renderizado pelo navegador .

Isso resolve um aspecto importante do problema. Agora você tem HTML na página. O navegador e outros aplicativos têm algo que podem ser facilmente consumidos. Não é suficiente apenas renderizar HTML para o navegador, no entanto. Sua marcação deve ser bem pensada e semanticamente correta.

Esteja ciente de suas tags. Nem tudo é um <div> ou um <span>.

Esteja ciente de seu aninhamento. Nem tudo precisa de elementos infinitamente aninhados. É exatamente por isso que o React lançou “Fragments” na v16.2.0 .

No final, não assuma que uma tag HTML é igual a outra. Se você arquitetar sua marcação com o mesmo pensamento que você coloca na lógica da sua aplicação, você criará algo altamente reutilizável. Quanto mais fácil para outros aplicativos consumirem seus dados, melhor para TODOS os usuários finais.

Pensamentos finais

No final do dia, a regra do menor poder é sobre a criação de código limpo.

Ao usar a linguagem menos poderosa para realizar o trabalho, obtemos o código menos complexo e mais portátil, à prova de futuro, que pudermos.

Quando você construir o seu próximo site, mantenha o RLP no fundo de sua mente. Seu eu futuro pode agradecer por isso.

Plug: LogRocket , um DVR para aplicativos da web

https://logrocket.com/signup/

LogRocket é uma ferramenta de registro de front-end que permite que você repita problemas como se eles tivessem ocorrido em seu próprio navegador. Em vez de adivinhar por que os erros ocorrem ou solicitar aos usuários capturas de tela e log dumps, o LogRocket permite que você repita a sessão para entender rapidamente o que deu errado. Ele funciona perfeitamente com qualquer aplicativo, independentemente do framework, e possui plugins para registrar o contexto adicional do Redux, Vuex e @ ngrx / store.

Além de registrar as ações e o estado do Redux, o LogRocket registra logs do console, erros de JavaScript, rastreamentos de pilha, solicitações / respostas de rede com cabeçalhos + corpos, metadados do navegador e logs personalizados. Ele também instrumenta o DOM para gravar o HTML e CSS na página, recriando vídeos com pixels perfeitos até mesmo dos aplicativos de página única mais complexos.

Experimente Grátis.