Por que separar os profissionais web em Front e Back-End?
Tags: webdev, webcomponents, software, programming
Published: 2022-01-23 16:27:49

Web Browsers são softwares super interessantes.

São nossa principal porta de entrada para o mundo web, exibindo páginas e mais páginas de sites por aí, além de habilitar toda a parte de comunicação com a internet, fazendo do seu usuário não apenas um mero espectador, mas também uma entidade ativa nesse grande oceano. Por conta disso, browser são softwares complexos que tem que lidar com uma grande quantidade de informação e interpretação de código, além de oferecer funções nativas.

Por isso, considero que browsers são verdadeiros sistemas operacionais que nos habilitam comunicação fora dos nossos limites habituais, porém não podemos nos enganar: os mesmos são escritos para funcionarem em cima de outros sistemas operacionais. Ainda são dependentes de chamadas de sistemas e não possuem kernel próprio (apesar de ter alguns motores por trás). É possível fazer um kernel específico e um sistema inteiramente a base de web? Talvez sim, mas como o browser só lida com códigos e comunicação web, creio eu que não seria o ideal.

![Browsers](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2c330a1qnhfumd62v907.png)
 

Pois bem, o browser é um ecossistema complexo que tem uma capacidade poderosa e ímpar como um programa. Tudo começa com o fato de ele ser hábil em fazer requisições HTTP para solicitar a um servidor arquivos HTML, e junto desse arquivos, arquivos complementares. Como é o protocolo padrão de comunicação, o browser deve suportar os verbos relacionados a ele. A implementação do protocolo é chave para que o browser cumpra sua função.

Quando o arquivo chega a máquina, o próximo trabalho do browser nessa cadeia é interpretar o código HTML. Há um motor que trabalha nesses processos, passando pelo parsing, tokenização, etc. Dentro dessa interpretação, o motor web irá encontrar links para arquivos CSS e arquivos JS. Para os arquivos CSS será necessário um outro tipo de parsing para associar as indicações encontradas nesse arquivo e, ainda, renderizar o que foi declarado lá dentro.

Quanto aos arquivos Javascript, eles terão que ser interpretados por um motor em separado, devido à complexidade da linguagem. Temos diversos motores já feitos conforme padrão ECMAScript, e o processo é o mesmo: dar parse na linguagem, tokenizar, executar de acordo com as instruções. Mas fora isso, o motor tem que se preocupar também com pedaços de código que fazem uma ligação com outros elementos da página: as APIs. E olha que a página HTML vai soltar muitos APIs para o Js: interface de HTMLCollections, videoAPI, DOMAPI, Event API.

![Javascript Engine](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6t3zblm45hv1f6gf7wx0.png)

Só nesse processo foram milhares de linhas de código para poder implementar cada pedaço. Fora isso, devem ser programadas as funções nativas do navegador, como funções de Refresh, Home, biblioteca de favoritos, um tracer de histórico, devTools, além de, claro, implementar uma API para possibilitar a inclusão de plugins.

Então, perceber que o browser é um sistema complexo e que merece uma atenção especial e um conhecimento especial é, na minha opinião, o que melhor motiva a questão da separação entre o que é back-end (o que lida com um computador em um nível mais baixo para poder fornecer um servidor) e um front-end (o que lida com um computador em um nível mais alto, diretamente com um browser, para interpretar corretamente o que vem do servidor). Então, talvez, um front seja mais complexo do que o back e é muito ofuscado pela abstração, visto que as mesmas coisas que o back lida o front também lida, só que em um nível a mais. Talvez o front não se preocupe com um buffer de teclado, mas tem que entendê-lo de certa forma para ter um melhor entendimento sobre eventos de teclado. Talvez o front não se preocupe com gerenciamento de memória, mas tem que entender para que a página web não vire um grande elefante.

Termino com as palavras do **user2188685** no tópico do StackOverFlow que inspirou este post (acesse [aqui](https://stackoverflow.com/questions/598841/how-to-get-started-building-a-web-browser)): 
>"You need to look at building a web browser like building an operating system, because that's essentially what a browser is -- it's an operating system for running web apps. And like an operating system, a web browser is a very complex piece of software with many components."

Tradução minha: *Você precisa perceber que construir um web browser é como construir um sistema operacional, porque essencialmente é isso que um browser é - Um sistema operacional para rodar aplicações web. E como sistemas operacionais, um web browser é um software muito complexo com muito componentes.*