Aguarde...

19 de maio de 2022

A Web além dos navegadores

A Web além dos navegadores

Os padrões da Web não são exclusivamente para facilitar a consistência entre navegadores. A padronização das APIs da plataforma web além do navegador está chegando, e estou aqui para isso.

Aqui estão alguns links que têm solidificado essa ideia na minha cabeça ultimamente.

Primeiro: na semana passada, Ryan Dahl (criador do Node.js e agora Deno) postou um artigo intitulado “JavaScript Containers” .

A tecnologia é difícil de prever, mas certamente a World Wide Web estará aqui em 10 anos. A cada dia que passa, mais e mais infraestrutura humana se conecta por meio de aplicativos da web – a web está comendo o mundo. Se você acredita que a web estará aqui em 10 anos, então certamente os padrões que compõem a web – HTTP, HTML, CSS, JavaScript – estarão aqui.

É por isso que acho que minha previsão para a web permanecendo basicamente a mesma (mas aprimorada!) é sólida. Mais e mais coisas vão se acumular em cima das camadas padronizadas existentes de tecnologia que compõem a web. HTTP, HTML, CSS, JavaScript, eles vão existir por um longo tempo. Eles estão embutidos em tudo o que fazemos. E JavaScript é um espaço de desenvolvimento particularmente interessante nesta pilha.

A web é o meio fundamental de informação humana. O JavaScript é diferente de outras linguagens de programação, pois está profundamente vinculado a essa infraestrutura.

Então, quais desenvolvimentos estão acontecendo em JavaScript além de APIs novas e padronizadas nos navegadores?

Há um novo contêiner de nível superior emergindo para software de servidor: o próprio sandbox JavaScript.

Este contêiner não se destina a resolver a mesma amplitude de problemas que os contêineres do Linux visam. Seu surgimento é resultado de sua simplicidade. Ele minimiza o clichê da lógica de negócios do serviço da Web. Compartilha conceitos com o navegador e reduz os conceitos que o programador precisa saber…

Nesta camada de abstração de servidor emergente, o JavaScript toma o lugar do Shell. É um pouco mais adequado para scripts do que Bash ou Zsh. Em vez de invocar executáveis ​​do Linux, como o shell faz, o sandbox JavaScript pode invocar o Wasm

Além de tudo isso, há o benefício da universalidade:

Todo engenheiro web já conhece as APIs do navegador JavaScript. Como a abstração do contêiner JS é construída nas mesmas APIs do navegador, a quantidade total de experiência que o engenheiro precisa é reduzida. A universalidade do Javascript reduz a complexidade.

Sim! Como Ryan diz, “o futuro das linguagens de script é o JavaScript do navegador”. Padronizar esse futuro é agora uma tarefa muito importante à nossa frente.

O erro fundamental do Node.js foi divergir do navegador à medida que novas APIs foram padronizadas, inventando demais. Em 2010, não tínhamos módulos ES, mas uma vez padronizado, deveria ser trazido para o Node. O mesmo pode ser dito para promessas, async/await, fetch, streams e muito mais. Bits não padrão antiquados como CommonJS requerem, package.json, node_modules, NPM, o objeto de processo global será padronizado e adicionado ao navegador ou suplantado por substituições alinhadas à web.

Acho que da mesma forma que pessoas como Zeldman ajudaram a mostrar a necessidade e a importância de construir navegadores com padrões da web, estamos vendo a mesma coisa acontecer com tecnologias adjacentes a navegadores, como servidores. Aposte nos padrões!

O que me leva ao anúncio de hoje do “Web-interoperable Runtimes Community Group (WinterCG)”. Do blog Deno :

ao usar o Deno, você não está aprendendo novas APIs ou funcionalidades específicas da plataforma, mas está investindo em seu conhecimento da maior e mais importante plataforma do mundo: a web.

Mas nem tudo é sol e arco-íris. Muitas APIs da plataforma web foram projetadas apenas com o navegador em mente, e não com os tempos de execução do lado do servidor. Isso significa que, quando os tempos de execução do lado do servidor implementam essas APIs, às vezes eles precisam divergir sutilmente das implementações e especificações do navegador, para que a API se torne útil no servidor. Um ótimo exemplo disso é fetch: a própria superfície da API funciona bem nos servidores, mas somente quando o CORS é ignorado, os usuários podem manipular redirecionamentos manualmente e os fluxos HTTP full duplex são suportados.

De fato, existem divergências complicadas para APIs originalmente feitas para navegadores que agora estão sendo portadas para ambientes de servidor. Pessoalmente, aprendi sobre essas nuances profundamente enraizadas da fetchmaneira mais difícil: por tentativa e erro ao tentar criar um proxy CORS no servidor e executar códigos de status de redirecionamento .

Essas diferenças sutis no comportamento da API existem para todas as implementações de busca do lado do servidor, mas geralmente não são bem documentadas e não são consistentes em tempos de execução. Para corrigir isso, engenheiros da Deno, Cloudflare e algumas outras empresas se reuniram para discutir como poderíamos resolver esse problema. Queremos tornar os tempos de execução do lado do servidor consistentes e compatíveis entre si…

O objetivo deste novo grupo da comunidade W3C é promover tempos de execução que suportem uma superfície de API unificada abrangente na qual os desenvolvedores de JavaScript podem confiar, independentemente do tempo de execução que estão usando: sejam navegadores, servidores, aplicativos incorporados ou tempos de execução de borda.

Eu adoro a ênfase em trazer à tona esses solavancos nas APIs da plataforma web (dependendo do tempo de execução) e trabalhar para suavizá-los. Acredito que isso ajuda todos a crescer em seu conhecimento e experiência da web sobre abstrações de terceiros sob medida.

(Tomada sem vergonha: os adaptadores Remix preenchem essas divergências com o objetivo de um dia não serem mais necessários .)

A web está, de fato, comendo o mundo. E suas tecnologias estão rapidamente se tornando a base de tudo o que fazemos (até mesmo aplicativos nativos no macOS estão usando visualizações da Web ) — especialmente JavaScript. O objetivo, ao que parece, não é mais JavaScript isomórfico que roda no cliente e no servidor, mas sim (como ouvi em devMode.fm) JavaScript megamórfico: JS que roda no navegador, no servidor, de forma isolada, em um service worker ou em um contêiner. Resumindo: em todos os lugares!

Postado em Blog
Escreva um comentário