JavaScript vs Python em 2017

Na verdade, o ecossistema JavaScript oferece todo o tipo de ferramentas para acelerar esse processo usando daemons e cache, mas você ou alguém em sua equipe tem que investir um pouco de tempo pesquisando, montando e mantendo uma ferramenta de JavaScript para o seu projeto antes que qualquer pessoa possa escreva uma linha de "moderno" JavaScript. Embora você possa finalmente conseguir um bom fluxo de trabalho de edição / atualização, você certamente não terá um fora da caixa como faria em Python.

"O JavaScript não é mais um idioma de edição / atualização. "

Outra diferença refrescante entre JavaScript e Python é a natureza "pilhas incluídas" de Python. Se você olhar para a biblioteca padrão que vem com JavaScript, é bastante mínima. O ambiente do Nó faz um trabalho modesto de aumentar o que é fornecido pela biblioteca padrão, mas a maioria das funcionalidades que você precisa inevitavelmente deve ser obtida a partir de npm. Especificamente, considere a seguinte funcionalidade que está incluída na biblioteca padrão do Python, mas deve ser obtida a partir de npm para um projeto de Nó:

Como você pode ver, para muitos desses recursos, existem várias bibliotecas de terceiros que fornecem funcionalidades sobrepostas. (Por exemplo, se você estivesse procurando um analisador JSON, você escolheria parse-json , safe-json-parse , fast-json-parse , jsonparse ou json-parser ?) Para piorar as coisas, os nomes dos módulos npm são usados em primeiro lugar, primeiro a ser servido. Muito parecido com nomes de domínio, isso significa que grandes nomes costumam ir a projetos implacáveis. (Por exemplo, a partir de sua contagem de downloads, o módulo npm chamado logging torna um dos pacotes de logs menos populares para JavaScript.) Isso faz com que a comparação de módulos de terceiros seja mais demorada, pois a qualidade do nome é não é um sinal útil para a qualidade da biblioteca.

Pode ser possível que o ecossistema de terceiros do Python seja tão ruim quanto o de Npm. O que é impressionante é que eu não tenho idéia se é esse o caso, porque é tão raro que eu tenho que procurar um pacote Python de terceiros para obter a funcionalidade que eu preciso . Estou ciente de que os cientistas de dados dependem fortemente de pacotes de terceiros, como o NumPy, mas, ao contrário do ecossistema Node, existe um pacote numPy que todos usam em vez de uma ladainha de concorrentes chamada numpy-fast , numpy-plus , simple-numpy , etc. .

"Devemos parar de manter a npm como um testemunho da diversidade do ecossistema JavaScript, mas sim citá-lo como uma falha na biblioteca padrão do JavaScript".

Para mim, uma das grandes ironias em tudo isso é que, sem dúvida, a presença de uma biblioteca padrão forte em JavaScript seria o mais altamente alavancado quando comparado a outras linguagens de programação. Por quê? Porque hoje, todo o site não trivial requer que você baixe underscore.js ou o que seus autores escolheram usar para compensar o núcleo fraco do JavaScript. Quando você considera o impacto adverso agregado que isso ocorre no tráfego de rede e nos tempos de carregamento da página, os números são assustadores.

Então … Você está dizendo que o JavaScript está morto?

Não, não, eu não sou. Se você está construindo UI usando tecnologias da web (o que é um monte de desenvolvedores), então eu ainda acho que o JavaScript é sua melhor aposta. Modulo o surgimento da Web Assembly (que vale a pena prestar atenção), o JavaScript ainda é o único idioma que é executado nativamente no navegador. Houve muitas tentativas de ter uma linguagem de programação existente e compilá-la para JavaScript para evitar "ter que" escrever JavaScript. Há casos em que os resultados foram bons, mas nunca pareciam ser excelentes. Talvez alguma ferramenta de transpilação acabe por ter sucesso em desencadear JavaScript como idioma para escrever na web, mas eu suspeito que ainda teremos a maioria dos desenvolvedores web que escrevem JavaScript por algum tempo.

Além disso, o navegador não é o único lugar onde os desenvolvedores estão criando UI usando tecnologias da web. Outros dois exemplos proeminentes são o Electron and React Native . O elétron é atraente porque permite que você escreva uma vez para Windows, Mac e Linux, enquanto o React Native é atraente porque permite que você escreva uma vez para Android e iOS. Ambos também estão habilitando porque os ciclos de edição / atualização usando essas ferramentas são muito mais rápidos do que os equivalentes nativos. Do ponto de vista da contratação, parece que os desenvolvedores que conhecem as tecnologias da web (1) estão disponíveis em maior número do que os desenvolvedores nativos e (2) podem suportar mais plataformas com equipes menores em comparação com desenvolvedores nativos.

Na verdade, eu poderia imaginar maneiras pelas quais essas plataformas poderiam ser modificadas para suportar Python como linguagem de script em vez de JavaScript, o que poderia mudar o cálculo. No entanto, uma coisa que todas as ferramentas loucas que existem na comunidade de JavaScript deu lugar a cadeias de ferramentas do transpiler como o Babel, o que torna mais fácil para os desenvolvedores comuns (que não precisam ser compiladores de hackers) para experimentar a nova sintaxe do JavaScript. Em particular, esta ferramenta abriu o caminho para coisas como o JSX , que eu afirmo é uma das principais características que fazem do React uma tecnologia tão agradável para construir UI. (Note que você pode usar React sem JSX, mas é tedioso.)

No meu melhor conhecimento, a comunidade Python não possui um mecanismo equivalente e popular para experimentar com DSLs dentro do Python. Porém, embora possa ser direto adicionar ligações Python nesses ambientes existentes, não acho que isso seja suficiente para que os desenvolvedores de produtos mudem para o Python, a menos que as alterações também tenham sido feitas para o idioma que tornou fácil expressar o código UI em Python como está em JavaScript + JSX hoje.

Key Takeaways

O Python 3.6 possui suporte incorporado para digitação gradual e assíncrono / aguardar. Ao contrário do JavaScript, isso significa que você pode escrever o código Python que usa esses recursos de linguagem e executar esse arquivo diretamente sem qualquer ferramenta adicional. Além disso, sua biblioteca padrão rica significa que você precisa gastar pouco tempo pescando e avaliando bibliotecas de terceiros para preencher lacunas em falta. É muito uma linguagem de script do lado do servidor "get stuff done", exigindo muito menos andaimes do que o JavaScript para obter um projeto fora do solo. Embora o Mypy possa não ser tão grafico ou performant como Flow ou TypeScript é hoje, a velocidade desse projeto certamente é algo que eu vou começar a prestar atenção.

Em comparação, espero que o JavaScript permaneça forte entre os desenvolvedores de produtos, mas aqueles que usam Node hoje para o código do servidor ou ferramentas de linha de comando provavelmente seriam melhores usando o Python. Se a comunidade do nó quiser resistir a essa alteração, acho que elas se beneficiarão (1) expandindo a API do Nó para torná-la mais abrangente e (2) reduzindo o tempo de inicialização para o Nó. Seria ainda melhor se eles pudessem modificar seu tempo de execução para reconhecer coisas como anotações de tipo e JSX nativamente, embora isso exigisse mudanças no V8 (ou Chakra, no Windows), o que espero seja difícil de manter e / ou a montante. Obter o TC39 para padronizar qualquer um desses recursos de linguagem (o que forçaria a mão do Google / Microsoft a adicionar suporte nativo em seus tempos de execução JS) também parece uma venda difícil.

No geral, estou ansioso para ver como as coisas se desenrolam em ambas as comunidades. Você nunca sabe quando alguém vai lançar uma nova tecnologia que obsoleta toda a sua ferramenta durante a noite. Por tudo o que sei, podemos acordar amanhã e todos decidem que deveríamos estar escrevendo o OCaml . Melhor ajuste o seu despertador.

Esta publicação apareceu originalmente no bolinfest.com .

Hacker Noon é como os hackers começam suas tardes. Somos uma parte da família @AMI . Agora estamos aceitando envios e estamos felizes em discutir oportunidades de propaganda e patrocínio .

Para saber mais, leia nossa sobre a página , como / nos envie no Facebook , ou simplesmente, tweet / DM @HackerNoon.

Se você gostou desta história, recomendamos ler nossas últimas histórias de tecnologia e histórias de tecnologia de tendências . Até a próxima, não concorde com as realidades do mundo!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *