Por que o JavaScript não é usado para o desenvolvimento clássico de aplicativos (software compilado)? [fechadas]


14

Durante meus anos de desenvolvimento web com JavaScript, chego à conclusão de que é uma linguagem poderosa e incrível, e você pode fazer coisas incríveis com ela.

Oferece um rico conjunto de recursos, como:

  • Digitação dinâmica
  • Funções de primeira classe
  • Funções aninhadas
  • Encerramentos
  • Funções como métodos
  • Funções como Construtores de Objetos
  • Baseado em protótipo
  • Baseado em objetos (quase tudo é um objeto)
  • Regex
  • Literais de matriz e objeto

Parece-me que quase tudo pode ser alcançado com esse tipo de linguagem; você também pode emular a programação OO, pois oferece grande liberdade e muitos estilos de codificação diferentes.

Com mais funcionalidades personalizadas orientadas a software (E / S, sistema de arquivos, dispositivos de entrada etc.), acho que será ótimo desenvolver aplicativos.

Embora, até onde eu saiba, seja usado apenas no desenvolvimento da Web ou em softwares existentes como apenas uma linguagem de script.

Apenas recentemente, talvez graças ao V8 Engine, tenha sido usado mais para outros tipos de tarefas (consulte node.js por exemplo).

Por que até agora só é relegado apenas ao desenvolvimento web? O que o mantém longe do desenvolvimento de software?


8
Se o desenvolvimento web não é (um caso especial de) desenvolvimento de software, o que exatamente é então ...?
Péter Török

@ Péter Török: Eu acho que você entendeu. O que quero dizer é que, até agora, ele era usado apenas como linguagem de script por softwares, para aprimorar os recursos. Nunca foi usado para realmente programar um aplicativo de software para um sistema operacional.
Jose Faeti

4
Vejo a digitação dinâmica como uma grande desvantagem e também gostaria de me livrar dos valores nulos.
Jonas

2
Você quer dizer "desenvolvimento clássico de aplicativos", não "desenvolvimento de software", certo? Melhor mudar seu rumo de acordo.
Doc Brown

2
@JoseFaeti para as janelas a ficha 8 permite-lhe fazer algum desenvolvimento em HTML5 e JS
Raynos

Respostas:


14

Recentemente, o node.js avançou o desenvolvimento do servidor. Portanto, agora é possível escrever JavaScript, para desenvolvimento.

Isso é verdade. Na história, ele não foi usado como uma linguagem de desenvolvimento. Mas, ei, até scripts no ambiente do cliente (User Agents) são um tipo de desenvolvimento. Não é?

A principal razão pela qual ouvi e li em muitos blogs é que as pessoas não sabiam sobre seu poder e singularidade até os últimos anos . O que fez isso acontecer foi que talvez outras línguas estivessem fazendo seu trabalho apenas o suficiente e ninguém nunca pensou em fazer algo paralelo.


Deve ser assim, e eu parece que algo está realmente se movendo agora :)
Jose FAETI

15

A partir daqui :

Observe que estou baseando todos os meus argumentos em casos de uso do mundo real. Contra-argumentos que não podem ser copiados com um exemplo de uso em aplicativos reais, completos, interessantes e úteis são inválidos. Eu já vi as pequenas "demonstrações de linguagem" que todo mundo já viu, as postagens do blog detalhando como os protótipos e a digitação dinâmica tornam um pequeno exemplo trivial algumas linhas mais curtas do que seria em C #, mas elas simplesmente não são relevantes para os problemas que você encontra ao escrever código real , em vez de micro-demonstrações e brinquedos. Então, aqui estão minhas queixas com JS:

a) Magia 'isso'. É isso, exceto quando é isso. O JavaScript o leva a usar funções anônimas em todo o lugar, exceto que elas sempre acabam perdendo o contexto apropriado para a variável 'this'; portanto, você acaba tendo um código idiota como "var _this = this" em todo o lugar e depois usando isso dentro de seus retornos de chamada ou outras funções. Alguns dias, juro que o número de funções que consigo escrever que não usam o nome 'this' são realmente menores que o número que o fazem.

b) 1 + "1" - 1 = 10. Além disso, "1" + 0 = "10". Sim, isso realmente causou bugs para nossos aplicativos, onde dados que deveriam ser um número foram carregados de um arquivo JSON como uma string devido a um bug em outro aplicativo e o resultado não foi bom. Todo o nosso código de carregamento teve que ser atualizado para adicionar uma tonelada de conversões de tipo em todo o lugar. Quando eu preciso que algo seja um número, eu realmente quero que seja um número, não uma string ou um objeto ou nulo ou qualquer outra coisa. Lua, que é muito semelhante ao JavaScript na maioria dos aspectos, corrigiu esse problema simplesmente não sendo retardado o suficiente para usar o mesmo operador para adição e concatenação de cadeias.

c) Global por variáveis ​​padrão. Portanto, mesmo se você usar o argumento de que a digitação dinâmica é apenas "mais fácil" porque você não precisa pensar em declarações de variáveis, o JavaScript lança esse argumento pela janela, colocando você 'var' na frente de novos identificadores em todo o lugar . E então ele estraga tudo silenciosamente, se você esquecer.

d) Protótipos em vez de classes. Existem muito poucos aplicativos JavaScript do mundo real em larga escala que não conectam seu próprio sistema de classes para solucionar a inutilidade inerente dos protótipos na arquitetura de aplicativos de grande porte. Esses mesmos aplicativos fazem o uso mínimo de protótipos para estender os tipos JavaScript básicos, e somente porque o JS foi tão mal projetado que até os dois tipos internos interessantes que ele contém estão com metade dos recursos que você espera que eles tenham.

e) Incapacidade de criar tipos de passagem por valor. Este é um problema frequente em praticamente todos os idiomas, exceto o C ++ / D, na verdade. Para aqueles que usam JavaScript para escrever aplicativos WebGL, dê uma olhada em todas as bibliotecas de álgebra linear para JavaScript. Em aplicativos 3D, você quase usa vetores com mais frequência do que escalares. Imagine se todos os números inteiros no seu aplicativo fossem passados ​​por referência, para que "a = 1; b = a; b ++" tornasse ambos aeb iguais a 2. Cada pequeno vetor de três componentes é um objeto completo. Eles são passados ​​por referência (a fonte de quase metade dos erros em nosso jogo WebGL até agora, na verdade). Eles existem em grande quantidade, são alocados no heap e são coletados no lixo, o que exerce uma pressão intensa sobre o GC, o que pode e resulta em pausas no GC, mesmo em jogos WebGL simples, a menos que o desenvolvedor salte por obstáculos ridiculamente complicados para evitar a criação de novos vetores em todos os lugares onde é lógico criar novos vetores. Você não pode sobrecarregar o operador; portanto, você tem expressões muito grandes e feias para executar operações básicas. O acesso a componentes individuais é lento. Os objetos não são compactados de forma nativa e, portanto, são incrivelmente lentos para serem inseridos em um buffer de vértice, a menos que você os implemente como instâncias de Float32Array, o que confunde a porcaria dos otimizadores do V8 e do SpiderMonkey atualmente. Eu mencionei que eles passaram por referência? O acesso a componentes individuais é lento. Os objetos não são compactados de forma nativa e, portanto, são incrivelmente lentos para serem inseridos em um buffer de vértice, a menos que você os implemente como instâncias de Float32Array, o que confunde a porcaria dos otimizadores do V8 e do SpiderMonkey atualmente. Eu mencionei que eles passaram por referência? O acesso a componentes individuais é lento. Os objetos não são compactados de forma nativa e, portanto, são incrivelmente lentos para serem inseridos em um buffer de vértice, a menos que você os implemente como instâncias de Float32Array, o que confunde a porcaria dos otimizadores do V8 e do SpiderMonkey atualmente. Eu mencionei que eles passaram por referência?

f) Nenhum recurso incorporado inclui ou requer funcionalidade. Sério, ainda. Existem bibliotecas de terceiros, mas quase todas elas têm algum tipo de bug ou outro, entre as quais um problema de cache confuso, pelo menos no Chrome, tornando o desenvolvimento real um incômodo.

g) Digitação dinâmica. Sim, estou disposto a iniciar esse argumento. Você começa a perceber isso no momento em que para de escrever pequenos aplicativos ou páginas da Web e começa a escrever grandes aplicativos em que você realmente tem dados que persistem por mais de um único clique do mouse ou ciclo de solicitação / resposta: adicione o tipo errado de objeto a um matriz para processar mais tarde e obter uma falha mais tarde de um membro ou método ausente em um código completamente diferente do local onde estava o erro real. Tempos divertidos. Sim, Java faz a digitação estática parecer ruim. Não, Java / C # / C ++ não é a única maneira de fazer a digitação estática. Inferência de tipo, ligação implícita à interface, etc. oferecem a você todas as vantagens "fáceis de lidar e com poucas pressionamentos de tecla" da digitação dinâmica sem todos os bugs. A segunda linguagem da Web mais popular - o ActionScript 3 - é digitada estaticamente, de fato, apesar de ser idêntica ao JS / ECMAScript. Além disso, recebo mais falhas nos aplicativos Python na área de trabalho do Fedora do que nos aplicativos C / C ++ (na verdade, nenhum dos aplicativos C / C ++ na minha área de trabalho falha, agora que penso nisso). Exceções de membros ausentes == muito mais fáceis de desenvolver e manter aplicativos, certo?

h) velocidade. Sim, houve um esforço ridiculamente imenso por um grande número de desenvolvedores super-durões dedicados aos tempos de execução da linguagem para tornar o JS quase metade da velocidade de um compilador C de baixo nível que um único colegial Junior poderia escrever em poucos meses. E LuaJIT está no mesmo barco que JS em termos de limitações fundamentais de linguagem, mas consegue fazer melhor do que qualquer implementação de JavaScript de qualquer maneira. Pessoas que não entendem o que todas as otimizações JS na V8 ou como realmente fazergostaria de afirmar que o JS pode fazer coisas incríveis em termos de velocidade, mas a realidade é que todas essas otimizações são basicamente "muito difíceis de analisar o código para descobrir tipos de variáveis ​​e compilá-lo como um tipo estaticamente ligeiramente retardado" compilador da linguagem faria isso. " Ah, e há rastreamento, mas o rastreamento também funciona em linguagens de tipo estaticamente (e funciona melhor devido à falta de necessidade de proteção de tipo no código de máquina gerado). Na verdade, nenhuma dessas otimizações de whizbang foi inventada por ou para JS; a maioria foi extraída de JVMs de pesquisa (Java é mau!) ou linguagens clássicas de POO (protótipos são impressionantes!).

i) Não é possível o IntelliSense. Deseja ver quais métodos existem nessa variável que você encontrou na linha 187 do foo.js no seu editor de texto? Que pena. Siga o código até descobrir onde ele foi inicializado e, em seguida, siga o código para descobrir qual o protótipo dele. E espero que não haja código que altere dinamicamente o protótipo nas suas costas. Na verdade, basta executá-lo em um navegador e definir pontos de interrupção, porque descobrir algo útil sobre o valor de qualquer outra maneira é basicamente impossível para qualquer base de código maior que os sites toy_web_app.html que os apologistas do JavaScript usam para glorificar a facilidade e a simplicidade do JavaScript. Alguns editores de código se esforçam muito para fazer melhor, e quase meio que têm sucesso nos casos realmente simples, às vezes uma vez.

j) Nenhuma vantagem. O JavaScript nem é especial se comparado a outra linguagem de tipo dinâmico. Ele não é capaz de fazer nada de interessante, o que também não pode ser feito por Lua, Python, Ruby etc. Nenhuma das implementações de JS é mais rápida que LuaJIT ou PyPy ou várias outras implementações avançadas de JIT de outras dinâmicas. línguas. O JS não possui aspectos positivos em comparação com outros idiomas comumente disponíveis. Ah, exceto que ele roda nativamente em um navegador da Web sem um plug-in. Qual é a única razão no mundo por que é tão popular. De fato, é a única razão pela qual o evento existe. Se alguém há dez anos tivesse pensado ", diabos, vamos colocar uma linguagem bem projetada e estabelecida em nosso navegador e fazer com que os outros façam o mesmo, em vez de fazer com que todos usem esse pequeno truque idiota que o NetScape inventou , "a Web pareceria muito diferente (melhor) hoje. Imagine o futuro se o Chrome inserisse o Python no Chrome como idioma suportado. Ou, na verdade, imagine o seguinte: o Google lança C / C ++ no Chrome como idioma suportado (http://code.google.com/p/nativeclient/).


Este é um post realmente interessante. Eu ficaria curioso para ver seus casos de uso que formam a base de seus argumentos. Não discordo dos pontos dele, mas desenvolvo aplicativos JS de tamanho corporativo há quase 10 anos e não experimentei algumas das coisas que ele mencionou (em particular, seu primeiro ponto sobre "fazer mágica"). Continuando por minha própria experiência, argumentos contra javascript como os deste post tendem a ser feitos por pessoas com grandes experiências tradicionais oop ... nesse caso, eu entenderia sua confusão.
JavaScript)

É muito interessante ver que em 2016, a resposta agora é totalmente obsoleta pela evolução da linguagem.
Stephan Bijzitter

@Senhor. JavaScript Olá. Você conhece uma série de tutoriais que se concentram em resolver exemplos de problemas do mundo real, em vez de apenas explorar o JavaScript e seus recursos e mecanismos? Não estou tendo sorte com pesquisas de palavras-chave. Por exemplo, em vez de passar por um link de tutorial tão detalhado e seus milhões de exemplos e recursos, onde encontro um repositório de pequenos tutoriais sobre como criar um aplicativo GUI para gerenciar algum sistema de seguro, médicos, escola ou parte operacional do um supermercado? Obrigado
Joshua

12

Por quê?

JavaScript a linguagem mais incompreendida

Estávamos na idade das trevas e ainda devemos aceitar que a comunidade de desenvolvimento geral JavaScript seja uma linguagem poderosa e versátil. Simplesmente não é mainstream.

O único avanço recente é que o node.js ficou cheio de palavras e as pessoas estão começando a aceitar que o javascript tem outros usos.

Eu tenho observado o desenvolvimento de JS e HTML5 para o Windows 8 e a reação da comunidade .NET foi "meu Deus, por quê?".

É simplesmente o fato de que a maioria dos desenvolvedores que não são da Web ainda vê o JavaScript como a linguagem de brinquedo usada para fazer a rolagem dos menus nos navegadores.

É certo que o JavaScript não se alinha às "práticas modernas de desenvolvimento". Para mim, o JavaScript ainda é uma linguagem de hackers que eu uso com o vim e a internet é a minha documentação. Não há IDE, não há ferramentas de desenvolvimento, não há preenchimento automático ou "intellisense", não há GUIs de clique e arraste.

No mundo dos desenvolvedores Java e .NET, eles estão ligados a suas GUIs e IDEs e não poderiam programar no vim.


1
Concordo com você, exceto "Não há IDE, não há ferramentas de desenvolvimento, não há auto-complete ou" intellisense ", não há clique e arraste as GUIs." Na verdade, você pode obter tudo isso usando muitos IDE diversos por aí, eu uso o Visual Studio, por exemplo, e é simplesmente ótimo.
Jose Faeti

1
@JoseFaeti desculpe, o Visual Studio não é um IDE javascript. Sou mais rápido no vim do que no VS2010. Isso significa que o VS2010 é um JS JS com vazamento.
Raynos 30/08/11

2
@ Raynos, "Sou mais rápido no vim do que no VS2010. Isso significa que o VS2010 é um JS JS com vazamento". - ou talvez isso simplesmente signifique que você não conhece o VS e o vim.
Péter Török

2
Absolutamente não, mas não vou criar um front-end RIA no Silverlight porque adoro o Resharper e o LINQ, ou o aplicativo ASP.Net MVC com uma fina camada jQuery, porque novamente é amigável ao .Net, quando existem linguagens Javascript do lado do cliente em mãos que são mais adequados para o trabalho.
sa93

1
Apenas adicionando minha voz ao coro de pessoas afirmando que existem IDEs JavaScript. É francamente bobo afirmar o contrário. Você pode não gostar dos IDEs e eles podem não ser perfeitos, mas ainda são IDEs. Ou eu estava imaginando o intellisense e a conclusão de código do VS ao trabalhar com JS?
precisa

10

Sua lista não contém nada sobre a gravação de arquivos no sistema, que é uma parte enorme do desenvolvimento de software.

As pessoas não pensariam em usar o JS para criar um aplicativo, pois é a linguagem de script de fato da Web, e você sempre usaria a ferramenta certa para o trabalho.

Por que escrever acres de JS para gravar um arquivo quando é uma operação trivial em Java / .NET / C / C ++?

Com isso dito, como outros usuários mencionaram, o node.js e suas bibliotecas tornaram as operações no servidor triviais e com o node.js se tornando popular, aprendendo que isso se tornará uma habilidade para um CV, pois você poderá manter / estender / criar aplicações com ele.


1
O +1 esqueceu completamente como uma biblioteca stdio é meio importante.
Raynos

1
Para o sistema de arquivos, como você o coloca, agora temos APIs de armazenamento local, embora você não conte com elas para uma durabilidade séria. No entanto, a gravação em um sistema de arquivos não precisa ser direta, seu javascript pode estar fazendo chamadas repousantes para um servidor que (gravado no próprio LOLCode ou C ou JS) que grava em alguma forma de armazenamento.
sa93 30/08

1
No lado do servidor. A API do arquivo NodeJS é apenas trivial como C, etc ... <- se você estiver fazendo IO corretamente em C (sem bloqueio). Além disso, uma chamada Ajax com qualquer invólucro sadio pode ser de 2 a 3 linhas. MyLib.Ajax.post ('/ persistence / Something', {data: blahObj})
sa93

@ sa93, por favor, não confunda os ambientes host do navegador com JavaScript. localStorage é uma API de host nos navegadores. Não está definido na especificação ES5.
Raynos 30/08/11

1
@reinierpost Writing files to the file system has been replaced with HTTP POST.Não, se você estiver escrevendo as APIs que lidam com as postagens.
StuperUser

5

A maioria dos idiomas de uso comum é mais poderosa e melhor projetada que o JavaScript. Todos os recursos mencionados são suportados por outras linguagens dinâmicas, como Python ou Ruby, que são em geral melhor projetadas. E alguns dos recursos mencionados não são necessariamente desejáveis ​​- muitos considerariam a digitação estática com inferência de tipo preferível à digitação dinâmica, se você tiver a opção.

Eu não estou dizendo isso para diss JavaScript. Gosto muito de trabalhar com JS no desenvolvimento de web. Mas olhando objetivamente, o JS tem várias desvantagens em comparação com outros idiomas:

  • Inúmeras falhas não corrigíveis. Muitos erros foram cometidos no desenvolvimento inicial de JS. Não há necessidade de enumerá-los aqui, eles estão bem documentados. Todos os idiomas apresentam erros no design inicial que são corrigidos posteriormente. A diferença com o JS é que o idioma foi desenvolvido e lançado muito rapidamente e esses erros nunca podem ser corrigidos devido ao requisito de compatibilidade com versões anteriores nos navegadores.
  • Processo extremamente lento para introduzir melhorias e novos recursos. Como todos os fornecedores de navegadores precisam concordar e, por várias razões políticas, podem querer desacelerar o desenvolvimento do idioma. Veja o C #, que é realmente uma linguagem mais nova que o JS. Quando o C # foi introduzido, não havia, por exemplo. fechamentos ou funções de ordem superior como JS, mas depois de várias iterações, agora ele tem tudo isso e, além disso, apresenta como Linq e sintaxe assíncrona que os desenvolvedores de JavaScript só podem invejar.
  • Biblioteca padrão empobrecida. Linguagens modernas como Python, Ruby ou qualquer coisa baseada em Java ou .net têm extensas bibliotecas padrão para quase tudo que você precisa. Em JS, você nem consegue ler um arquivo sem bibliotecas de terceiros. Você menciona o Regex, mas todas as línguas modernas têm isso e milhares de coisas mais.
  • Outros idiomas alcançaram as poucas vantagens do JavaScript. Recursos como encerramentos e funções de primeira classe foram poderosos quando comparados a linguagens estáticas desajeitadas como Java há dez anos, mas linguagens dinâmicas e funcionais há muito tempo têm esses recursos, e até o Java, uma linguagem bastante conservadora, adicionou isso no Java 8.

O único recurso que realmente diferencia o JavaScript de outras linguagens modernas é a herança baseada em protótipo (em oposição à baseada em classe), e a vantagem desse modelo é duvidosa, pois todo mundo simplesmente o usa para simular a herança baseada em classe.

Simplesmente não há razão para escolher o JavaScript se você tiver a opção de escolher outro idioma moderno. A única razão seria se esse fosse o único idioma que você conhece.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.