Olá pessoa desenvolvedora. Depois de muito tempo resolvi tentar voltar a escrever artigos. A de hoje não tem nada de programação, é muito mais historinha. Espero que gostem. :)
Não sou historiadora e os fatos não estão descritos necessariamente numa ordem cronológica certa tão pouco científicos. Esse texto tem tanta credibilidade quanto uma página da Wikipédia no início do milênio, ou seja, nenhuma. Não a usem como base histórica.
Motivação
Quem no começo da carreira não se preocupava com quantos espaços identava seu código, se usava tab, se botava ou não chaves se o if tinha apenas uma linha...?
E claro que com isso empresas e pessoas desenvolvedoras começaram a se preocupar com a forma que iriam programar. Criaram diretrizes, chamadas de Guias de Estilo, ou em inglês Style Guides, para todos escreverem um programa de forma única parecendo como se fosse programado por apenas uma pessoa.
Por outro lado, pessoas desenvolvedoras também se preocupavam se seu programa funcionava de forma correta. Testavam manualmente e viam se o comportamento do teste condizia com o que foi planejado.
Não só isso. Com o passar do tempo vieram outras preocupações como qualidade de código, se existe muitos códigos duplicados, se o programa roda regularmente em qualquer ambiente que for suportado.
Imagine pessoas lidando com tudo isso, lendo e corrigindo códigos, apontando erros, verificando se a aplicação não quebraria, testando em diversos ambientes... Um tanto inviável, certo?
Criou-se então uma necessidade de se automatizar tarefas "triviais" (no sentido que possam ser reproduzidos) de forma não humana pois usando um programa para avaliar outro programa seria muito mais rápido que uma pessoa avaliando o código fonte ou funcionalidade de outro programa em específico.
Hoje em dia, quem processa contas complexas mais rápido? Uma pessoa mediana/padrão ou um computador já configurado para fazer contas?
Então por que não atribuir tarefas corriqueiras pra máquinas para as pessoas programadoras se preocuparem muito mais em criar programas que ficar pensando qual a melhor maneira para programar?
E o JavaScript?
Os navegadores sempre foram bons programas em acessar um servidor, pegar uma informação em texto e imprimir pro usuário.
Este protocolo de mensageria entre navegador e um servidor é a própria HTTP. Do inglês Hypertext Transfer Protocol, literalmente traduzido como Protocolo de Transferência de Hipertexto.
Mas somente imprimir um texto na tela é chato, não? Imagine não poder nem botar uma corzinha, uma imagenzinha... E com este pensamento os navegadores evoluíram e agregaram mais funcionalidades.
Em 1995 foi atribuida uma tarefa para um funcionário da Netscape chamado Brendan Eich: desenvolver uma linguagem que seria embutida nos navegadores da Netscape. Inicialmente chamada de LiveScript, mas pouco tempo depois renomeada para JavaScript para aproveitar a popularidade de outra linguagem de programação: o Java.
Apesar de ser uma das primeiras linguagens da Web a possibilitar adicionar interatividade às páginas estáticas, o JavaScript nem sempre foi fácil de programar. Linguagem que apesar do nome, não se parecia em nada com o Java.
Mesmo assim a web evoluía e novas formas de interatividade foram criadas.
Applets em Java... Animações em Flash...
E o JavaScript além de possuir limitações, cada navegador podia adicionar alguma funcionalidade no JavaScript da forma que bem entendesse e quando entendesse.
Mas da mesma forma que vieram e tiveram seu hype, também tiveram sua decadência. Applets Java utilizavam a JVM, Java Virtual Machine, ou em português: Máquina Virtual do Java, trazendo um problema de segurança. Sendo o mesmo interpretador que estava na máquina do usuário, uma pessoa desenvolvedora poderia maliciosamente criar um programa com outra finalidade e ter acesso ao computador do visitante.
Já sobre o outro, havia uma frase famosa que todos repetiam na época:
O Flash foi morto pelo Steve Jobs
Quando a Apple criou o iPhone, contendo um navegador dentro dele, foi-lhe arrancada qualquer método de rodar Flash. Animações e aplicações em Flash rodavam perfeitamente no computador, porém num computador de bolso poderia exigir mais da máquina e comprometer o tempo de bateria do dispositivo.
Também haviam outros fatores como a Apple ter que lidar com um produto de uma companhia externa que talvez exigisse algum retorno por ceder uso de uma tecnologia proprietária.
Ferramentas para códigos escritos em JavaScript
Uma das primeiras ferramentas criadas com o intuito de modificar um código JavaScript foi devido a preocupação de enviar um código muito grande pra quem navegasse a página que carregaria este script.
Ninguém escreve código todo em uma linha, certo? Digo, pessoas programadoras normais. Ficaria ilegível.
Mas e se uma ferramenta tirasse os espaços e quebras de linha e o meu arquivo JavaScript tivesse um tamanho menor?
Assim foi criado o minificador de código. E qual o ganho? O usuário do site iria ficar esperando menos tempo para baixar script embutido na página.
Esta mesma pessoa que criou o minificador também tinha umas opiniões fortes sobre como um desenvolvedor deveria escrever seu código.
Logo em seguida o mesmo criou uma ferramenta que apontava más práticas de escrita de código JavaScript e também procurava erros triviais como estrutura do código, se uma instrução foi escrita sem erro... Coisa que já existia em outras linguagens. Este analizador de código estático foi chamado de JSLint.
A pessoa que criou ambos se chama Douglas Crockford. Não sei se foi realmente as primeiras ferramentas criadas para códigos escritos JavaScript, porém foram uma das primeiras ferramentas mais populares.
Este também foi responsável por popularizar o formato de documentos JSON.
Porém mesmo sendo umas das primeiras ferramentas para modificar códigos JavaScript, a primeira rodava em linha de comando e foi escrito em C. A segunda só rodava no navegador.
Google quem?
Uma empresa que já estava bem consolidada no mercado de buscas se intromete e decide também ditar regras de como uma pessoa desenvolvedora de tecnologias web deveria escrever seus sites de forma performática, já que era assim que eles faziam.
Sim, essa empresa era..... o Yahoo!.
Uma das primeiras ferramentas online sobre performance (pelo menos que eu tenho ciência) foram feitas por eles. Leia mais no site do YSlow, em inglês..
Algo que era hype nessa época eram os Provedores de Serviços. Sites que agregavam de tudo. Nelas qualquer pessoa podia fazer sua página, ter sua conta de email, ver notícias, enviar mensagens, jogar joguinhos em Flash... TER SEU BLOG!!!
Outra coisa que era hype na época eram discadores personalizados barras pro Internet Explorer personalizados. Toda empresa provedora de serviços tinha um navegador onde o usuário só clicasse e a primeira página que abria era a da própria provedora.
E com isso o visitante nem precisaria digitar dáblio dáblio dáblio ponto......
E mesmo o Yahoo! sendo um dos portais mais famosos e acessados da Internet na época e sempre pensando em performance, uma empresa rival no setor de buscas começou a ter visibilidade e abocanhar seu market share quando ofereceu uma conta de email onde a capacidade da sua caixa de entrada seria de um giga. Nenhuma outra empresa oferecia tanto espaço para guardar emails. Algumas davam 1mb, 4mb de armazenamento e a pessoa tinha que apagar os emails pra ter espaço para receber mais e-mails.
Mas esta empresa não contente com o navegador da Microsoft, resolveram ao invés de só criar uma barra personalizada, lançaram um novo navegador: o Google Chrome.
Que quase levou o nome de GBrowser, analogamente ao GMail.
Ok, não foi bem assim...
Não foi só pra ter um navegador próprio que a Google criou o Chrome. Foram contratades pessoas desenvolvedoras que participaram do desenvolvimento do Internet Explorer e de ferramentas da Mozilla para a concepção deste produto.
O Firefox também já existia na época. Mesmo assim o Internet Explorer dominava o market share dentre os navegadores (claro que por ser um navegador que vinha junto do Windows por padrão).
Mas a motivação para a criação de um novo navegador pela Google foi a de ter uma experiência para seus usuários do Gmail, Blogger e YouTube muito mais parecida com um aplicativo Desktop que simples páginas web.
Caso queira saber mais sobre a criação do Google Chrome, veja este artigo, em inglês.
Tá, e pra que toda essa historinha longa?
Este novo navegador criado pelo Google, inicialmente utilizava Webkit, criado pela Apple e já sendo código aberto (open source) desde 2005.
Porém por problemas de compatibilidade, a Google decidiu criar seu próprio motor interpretador de JavaScript, o V8.
Toda essa volta pra falar que uma pessoa pegou esse motor do navegador e decidiu tirar ele de lá e rodar localmente na máquina.
Assim surgiu o Node.js. E nome deste programador é Ryan Dahl.
E assim começaram os pesadelos e os full stacks unicórnios
Isso possibilitou que as pessoas programadoras pudessem usar o mesmo JavaScript que existia no navegador para criar programas que rodavam não no navegador, mas sim na máquina.
E assim aqui eu costuro com o começo da história:
O Node tornou possível que pessoas desenvolvedoras na linguagem JavaScript pudessem usar o JavaScript para criar programas que automatizassem tarefas triviais como análise estática de código, validadores de sintaxe, executáveis de testes unitários com emuladores de API do navegador etc...
E então o npm fomentado pelo Open Source explodiu de aplicações que faziam de tudo, pois muito dev já programava em JavaScript para web.
Uma delas é o CoffeeScript, uma das primeiras linguagens a compilar para JavaScript. Também foi precursor para que voltassem as discussões do Ecma262 e a TC39, que são comitês de padrões ligados ao JavaScript voltadas às evoluções da linguagem. Inclusive, com o CoffeeScript já era possível utilizar arrow functions.
Hoje existem diversas outras linguagens que compilam para o JavaScript: TypeScript, ClojureScript, Elm, ReasonML, dentre outras.
Atualmente também existem ferramentas que mesmo rodando a partir do Node, parte foi programada em outra linguagem, muitas vezes low-code como C, C++ e ultimamente Rust e Go para serem mais performáticas.
Olá pessoas, sou a Nina Kitsu.
Decidi contar uma historinha, como diriam, "baseadas em fatos reais", de como foi a minha percepção de fatos sobre tempo enquanto profissional da área focando no surgimento de aplicações feitas com JavaScript fora do navegador, nas máquinas locais.
Hoje aplicações JavaScript são usadas diariamente no frontend, no backend e até no seu computador.
E com esta historinha abro uma série onde falo um pouco de ferramentas para ambientes JavaScript e configuração de repositórios.
Top comments (0)