Recentemente Douglas Cockford, criador do JSON fez um pronunciamento bem interessante.
A melhor coisa que podemos fazer hoje ao JavaScript é aposentá-lo
Ele segue por uma linha que se encaminha para o lado da evolução da linguagem e como isso ficou complicado devido a como a linguagem está inflando cada vez mais e consequentemente se tornando mais difícil de corrigir em sua base.
É um ponto interessante e com toda certeza muito importante a ser abordado e levado a frente, no entanto, o que me chamou atenção foi outra coisa, uma que estava nos comentários: segurança.
Um contexto geral.
O JavaScript tem um grande objeto global que você provavelmente já usou bastante, o Window. Basicamente, podemos dizer que todo código está rodando no mesmo lugar o tempo inteiro, o que torna esse código vulnerável a qualquer tipo de extensão maliciosa, já que a mesma pode acessar dados sensíveis e alterar comportamentos sem dificuldade, por estar rodando no mesmo lugar.
Esse "recurso" é interessante por permitir coisas que muitas vezes são utilizadas por biblitocas, sendo o exemplo mais famoso o JQuery que insere algumas coisas diretamente no objeto global. Por outro lado, permite que você altere o comportamento padrão de algumas funções nativas do JavaScript e isso pode ser um problema de segurança.
Podemos até mesmo estender esse assunto para a gigante maleabilidade do JS, que também leva a falta de segurança. Isso, todavia, já tem uma solução que é amplamente conhecida e até mesmo utilizada, o TypeScript.
Uma nova linguagem
Segundo o Crockford, temos falhas no JavaScript que não podem ser corrigidas e o inchaço nas funcionalidades saiu de controle já que a linguagem está em constante evolução ao invés de constante melhoria em sua base, o que torna uma melhoria ainda mais complicada.
O pai da extensão do JS, sugere uma nova linguagem chamada E, uma criação conjunta entre o próprio CrockFord e alguns outros integrantes. Este seria uma linguagem orientada a objetos e planejada para tornar a computação mais segura.
Entretanto, sejamos realistas aqui. Essa mudança parece um pouco grande demais para vir assim do nada, principalmente se pensarmos que literalmente todos os navegadores usam o JS para a manipulação da DOM. Mudar isso seria um grande problema e seria uma mudança de longo prazo.
Como o próprio Crockford admitiu, ele nem sequer tem a linguagem pronta ainda e sua concepção é bem complexa e provavelmente vai demorar para termos algo concreto para podermos testar. Além disso, as empresas e desenvolvedores precisariam tomar a iniciativa de começar a aprender a linguagem e implementar ela em suas aplicações, o que me parece uma manobra arriscada visto que a princípio, seria uma linguagem com poucos recursos, bibliotecas e uma comunidade muito pequena.
E então?
Olha, eu concordo que tem muitas coisas contra o JavaScript, porém, ele tem um ponto muito forte e que provavelmente é o que eu mais gosto na linguagem, sua comunidade incrível e extremamente prestativa.
Eu acompanho bastante os grupos da ECMA e um que estou de olho é o TC39, isso por conta de um de seus membros chamado Leo Balter, o qual acompanho desde antes de decidir qual área de programação eu iria seguir.
Entre as propostas do TC39 nós temos Decorators, algumas melhorias para o Locale, melhoras para os arrays e por ai vai. Entre todas essas ideias uma fez meus olhos brilharem ao bater o olho, o ShadowRealm.
ShadowRealm
O que este chuchuzinho aqui faz é basicamente criar um contexto que tem seu próprio objeto global que não a Window, e com isso, funciona sem compartilha recursos de forma global com outras partes da aplicação. É como se separássemos o código do restante.
Usando o exemplo que é proposto dentro da própria publicação do Balter:
const sr = new ShadowRealm();
// Sets a new global within the ShadowRealm only
sr.evaluate('globalThis.x = "my shadowRealm"');
globalThis.x = "root"; //
const srx = sr.evaluate('globalThis.x');
srx; // "my shadowRealm"
x; // "root"
Nesse código, nós criamos a propriedade x tanto dentro quanto fora do ShadowRealm (sr), ambos com valores diferentes, e podemos ver que ambos estão completamente isolados um do outro.
Uma limitação interessante e que é importante ser pontuada é que o SR consegue apenas transportar dados primitivos (String, Number, BigInt, Symbol, Boolean, undefined e null). Outros tipos como objetos ou arrays não são permitidos. Isso é importante quando pensamos em manter a separação total dos ambientes já que objetos e arrays carregam referências do local aonde são criados.
Ainda assim, podemos contornar esse problema com outro recurso muito interessante do ShadowRealm. Ele consegue compartilhar funções e valores retornados por essas funções, como no exemplo abaixo:
const sr = new ShadowRealm();
const wrappedFn = sr.evaluate('(x) =; globalThis.foo = x');
wrappedFn(42);
globalThis.foo; // undefined
sr.evaluate('globalThis.foo'); // 42
Não quero me extender demais nisso então vou deixar aqui o link para o post original dos autores do ShadowRealm. Vale a pena dar uma boa olhada nele e no Github da proposta
No final das contas...
O JavaScript tem seus problemas, isso é fato. É uma linguagem dinâmica até demais muitas vezes e acaba ficando confusa de tantas funções que possui, sendo algumas bem desnecessárias. Não é um exemplo de segurança também.
No entanto, acho improvável que essa linguagem seja simplesmente abandonada agora. É a linguagem mais popular segundo a pesquisa realizada pelo StackOverflow e é extremamente utilizada na Web já que é o padrão para manipular a DOM.
Com isso em mente, é importante olhar para o que temos e tentar trabalhar em cima disso. O ShadowRealm é um exemplo excelente de como a linguagem pode sim melhorar e se tornar muito mais agradável no quesito de segurança.
Além disso, muito do que se trata de segurança parte de nós como os desenvolvedores. Querendo ou não é nossa responsabilidade estudar tanto quanto possível a parte de segurança da informação para saber como lidar com os dados dos nossos usuários.
O código que mandamos para o usuário é código perdido, já está na maquina dele e ele pode fazer o que quiser com isso e ter outra linguagem não muda esse fato. Cabe a você como programador, saber contornar esse problema e controlar o máximo possível o que o usuário vai ter acesso.
Top comments (0)