A discussão dos resultados do ano no frontend tornou-se subitamente o assunto da discussão . Acrescentarei minha opinião e ficarei feliz em ouvir a opinião de outras pessoas.
Parece-me que faz sentido falar sobre o que está acontecendo na web moderna, é percebido de fora e de dentro é completamente diferente. Sim, e "dentro" tem vários níveis. A visão "eles complicam o layout novamente" é absolutamente correta, por um lado, e errônea e depravada, por outro, mas a visão "não nos impede de construir abstrações" também é ineficaz.
Quando alguém reclama que a web moderna se tornou muito complicada, toda vez que eu quero lembrar a essa pessoa que ela confia seu dinheiro em bancos e formulários de compra on-line, correspondência pessoal em redes sociais e versões da web de mensagens instantâneas, e arquivos pessoais nas nuvens. E provavelmente ele realmente quer que o processo de desenvolvimento desses sistemas seja complexo, difícil, mas confiável e não falhe.
fonte de imagem
Sob o frontend moderno e seus amigos, agora eles entendem muito mais do que parece do lado de fora. Estes são sites clássicos e SPA, aplicativos no elétron e aplicativos móveis no cordova, NativeScript, React Native e até no Flutter. Essa é uma infraestrutura complexa com CDNs, serviços geo-descentralizados, chatbots em JS e até ferramentas de aprendizado de máquina para otimizar a montagem e até a geração de layout .
E, na própria Web, aparecem soluções monstruosamente complexas que anteriormente podiam funcionar exclusivamente no modo desktop. Eu mesmo tive alguns anos atrás para abordar o desenvolvimento de um navegador genoma completo no navegador - eu estava envolvido em fornecer desempenho e 60FPS, o que era um problema grande o suficiente, mas solucionável. Mesmo 5 anos atrás, ninguém poderia pensar que o navegador do genoma não poderia ser algo instalado em um computador poderoso, e essa solução permitiu que médicos e pesquisadores trabalhassem com o genoma mesmo em um tablet ou laptop leve.
Porque
No momento, o pacote HTML + CSS + JS é um dos mais poderosos em termos de criação de interfaces - não apenas devido às suas capacidades, mas também ao número de soluções criadas nele - estruturas CSS, bibliotecas de componentes visuais, interfaces para um grande número de serviços e SAAS . Em termos de eficiência nas horas de desenvolvimento para potencial público e acessibilidade, as tecnologias da Web estão à frente das soluções móveis e de desktop. E agora se dividiu em três áreas:
- Desenvolvimento de sites totalmente estáticos e quase estáticos com conteúdo parcialmente dinâmico (galerias, pop-ups, etc.)
- Desenvolvimento de aplicativos Web "clássicos" em estruturas de servidor (django, rails)
- Desenvolvimento de cliente da Web
E cada um deles tem uma especificidade completamente diferente.
O desenvolvimento de JS foi realmente doloroso, então começaram a aparecer soluções que resolviam essa dor.
Se você olhar para eles, poderá ver algo muito interessante: primeiro, soluções como jQuery e CoffeeScript começaram a aparecer, reduzindo a redundância e a verbosidade da linguagem. Mas eles desapareceram rapidamente e, em seu lugar, surgiram ferramentas que tornaram possível reutilizar o código da maneira mais eficiente possível, detectar estaticamente erros e criar abstrações eficazes, "ocultando" níveis individuais de complexidade por trás de interfaces simples e bem descritas.
Apareceu o GraphQL, que resolve problemas com a complexidade de descrever, documentar e manter o REST. Apareceram o TypeScript e o Flow, que solucionaram os problemas de falta de digitação. Surgiram novas entidades de idioma que permitem trabalhar efetivamente com operações assíncronas, classes e fluxos de dados. O WebAssembly apareceu, permitindo reutilizar o código de outros idiomas e fazê-lo rapidamente.
Todas essas soluções visam a mesma coisa: reutilizar o código e o potencial para criar equipes "simples". Eles resolvem o problema para pegar o código de outra pessoa e começar a usá-lo.
Esta é uma evidência clara de que a web está se desenvolvendo para trabalhar em grandes equipes; ela se tornou uma plataforma para soluções "adultas".
Uma série de eventos que se tornaram ainda mais evidentes: Reagir Native, NativeScript, Dart + Flutter e outras soluções para reutilizar código em plataformas nativas apareceram. Esse é um ponto muito importante: devido à falta de capacidade de usar outros idiomas na Web, as empresas começaram a ajustar seus processos em busca de uma "bala de prata" que lhes permitisse reduzir de maneira alguma os pequenos custos de desenvolvimento e o tempo para fornecer novas funcionalidades a todos os clientes. É importante que qualquer projeto seja rápido, e especialistas de alto nível começaram a se unir em busca da oportunidade de trabalhar efetivamente no JS.
A propósito, pela mesma razão, os mecanismos de modelo começaram a morrer parcialmente: o uso de mais uma semântica provou ser menos eficaz do que usar HTML familiar com pequenas extensões em JS (Angular, Vue) ou usar apenas uma linguagem para descrever o layout (React, Flutter). A incapacidade de expandir, a necessidade de apresentar aos desenvolvedores uma nova linguagem, o risco de a plataforma morrer, a descentralização levou ao fato de que eles começaram a preferir os modeladores de estrutura que tentavam estar o mais próximo possível das plataformas HTML / DOM.
No entanto, além de escrever código com eficiência, também há um "coeficiente" para sincronizar um comando. Se a linguagem permitir que você trabalhe de maneira super rápida, mas ao mesmo tempo sincronizar uma única funcionalidade entre dois desenvolvedores criar uma dor terrível, provavelmente continuará sendo um nicho. Portanto, muitos dos recursos e soluções de idiomas têm como objetivo específico reduzir problemas com a sincronização e a ausência de problemas. Eles reduzem esse "coeficiente", que indica quantos juniores podem controlar simultaneamente o meio e quantos médios podem ser controlados pelo desenvolvedor líder. Dos exemplos mais recentes desses recursos, o es6 imports resolve parcialmente o problema da dependência cíclica, enquanto o mais bonito permite que você obtenha a mesclagem esperada e adequada do código git, independentemente de como o desenvolvedor o escreve. Não deve ser bonito, deve estar bem sincronizado.
E, no final, em apenas alguns anos, a web como plataforma foi adquirida por grandes empresas e equipes sérias, razão pela qual a maioria delas apresentava "fadiga de javascript" . A propósito, a principal reivindicação ao quase monopólio do Google na web diante do Chromium é que eles colocam o que precisam nos recursos da plataforma web e do JS (embora isso geralmente coincida com o que a maioria das empresas precisa).
Como resultado, por um lado, temos uma plataforma absolutamente agradável para o código reutilizado em todos os lugares, sintaxe que permite trabalhar com grandes comandos simples. Mas ...
Tudo ficou complicado e todo mundo ficou confuso
E ninguém entendeu o que fazer. Qual é, de fato, o problema? Nessas três categorias diferentes.
- Desenvolvimento de sites totalmente estáticos e quase estáticos com conteúdo parcialmente dinâmico: esse tipo de aplicativo é caracterizado pelo HTML como ponto de entrada, velocidade máxima de download e JS opcional
- Desenvolvimento de aplicativos Web "clássicos" em estruturas de servidor (django, rails): atualmente, essas soluções são caracterizadas pelo carregamento com HTML como ponto de entrada, mas, em vez da velocidade máxima de download, eles se concentram na reutilização de código, DRY e integração de back-end. O código JS é parcialmente gerado pela estrutura (notificações, formulários, links turbo e assim por diante), parcialmente você precisa se escrever
- Desenvolvimento de aplicativos cliente da Web. Aqui acontece o inesperado: o HTML, em vez do ponto de entrada, torna-se o manifesto do aplicativo e a plataforma de renderização, e JS, o "ponto de entrada".
O que quero dizer com ponto de entrada: essa é uma determinada entidade, cujo carregamento é igual à entrega mínima para o usuário do produto. Se o usuário precisar mostrar as informações, precisamos de HTML + CSS; se executarmos o aplicativo, precisaremos de JS que é executado a partir do HTML.
E para confundir todo mundo completamente, apareceu uma quarta categoria:
Aplicações isomórficas
Em "isomórfico" no desenvolvimento web, geralmente significa algo que funciona tanto no servidor quanto no cliente. Nesse modo, aplicativos em react, angular, vue.js podem funcionar, existem estruturas prontas - Next e Nuxt , por exemplo.
Ambas as tarefas são relevantes para elas: o aplicativo Web deve entregar seu estado inicial ao usuário o mais rápido possível e atuar como um aplicativo. Em outras palavras, eles devem fornecer HTML e JS como dois pontos de entrada, um para o conteúdo e outro para o aplicativo. Isso cria dois parágrafos conflitantes: por um lado, a quantidade de dados entregues deve ser mínima; por outro lado, é necessária a reutilização do código. Para JS, isso é resolvido por blocos da web, divisão de código e carregamento dinâmico de código, os modelos deixados para JS, mas o CSS ainda permanece. E o mais importante - queremos não fornecer um único byte extra ao usuário. E então alguém teve a ideia: esses aplicativos realmente têm dois pontos de entrada. Eles podem ser processados como duas entidades autônomas.
A partir disso, nasceu o conceito CSS-in-JS, concentrando-se em dois processos separados: gerar um arquivo CSS para conteúdo estático e salvar estilos próximos aos componentes.
Tudo deixou para JS.
Agora em JS você pode encontrar estilos, layout e o código real.
Agora tudo está em js e isso é bom
Vale a pena fazer outra digressão - agora para o lado do supermercado.
É importante que qualquer produto no desenvolvimento ou desenvolvimento possa "mover-se" na outra direção. Atua em qualquer um dos níveis:
A capacidade de transformar um componente visual em um componente com lógica mínima adicionando uma linha de código é muito interessante. A necessidade de reescrevê-lo do zero não é legal.
Tornar barato se tornar um SPA ou aplicativo do servidor é muito legal, mas raramente é possível. É mais sábio, se não impõe custos, começar desde o início com essa plataforma.
Portanto, quase todo projeto da Web que corre o risco de precisar renderizar no servidor, o risco de refatorar componentes, passar de um mecanismo de modelo para outro, tenta evitar riscos.
Quando existe uma plataforma única na qual algumas entidades podem se transformar em outras com um preço bastante baixo, o desenvolvimento é muito rápido.
No caso de uma aplicação em angular / react / vue, é exatamente isso. Eles são difíceis de entender. Não é tão complicado quanto o Angular 1, é claro, mas de qualquer maneira - o caminho para compreendê-los é longo e os cursos on-line de seis meses não são suficientes para entendê-los. Mas eles oferecem a oportunidade de fazer em poucas horas o que foi feito várias semanas antes e em alguns dias - o que costumava levar vários meses.
No entanto, o oposto também é verdadeiro - muitos não precisam deles, mas são usados porque estão "na moda".
Quando o arquiteto de infraestrutura do grupo de aplicativos da Web e de dispositivos móveis e o designer de layout estiverem conversando, será muito difícil para eles. Agora, essas são direções tão diferentes que não terão interseções no conhecimento, exceto no JS.
Da próxima vez que você quiser dizer "a web ficou muito complexa e inchada" - pense em como é difícil projetar e tornar um cliente de email da caixa de entrada do Google (com entidades inteligentes incluídas dependendo da letra), um IDE da Web, como Cloud9 ou Internet banking .
Mas se um codificador chegar até você e começar a falar sobre o fato de que ele precisa reagir, porque ele precisa de digitação e decoradores rigorosos para o layout da página de destino, não ceda à persuasão.