Eventualmente, o HTML5 / JS substituirá todos os idiomas do lado do cliente? [fechadas]

Eu só estou pensando sobre o futuro de tudo isso. IMHO, existem quatro forças que definem para onde a tecnologia vai: Microsoft, Apple, Google, Adobe.

Parece que os iADs do iPhone / iPad da Apple agora podem ser programados em HTML5. Então, isso significa que o HTML5 eventualmente substituirá o objetivo-c?

Além disso, a Microsoft mudou seu foco do WPF / Silverlight para HTML5 e presumo que o Visual Studio 2011 seja sobre suporte a ferramentas para HTML5. Porque é isso que a Microsoft faz. (Ferramentas). Em alguns meses, o IE9, o último navegador principal suportará HTML5.

Da mesma forma, a Adobe está entrando na onda do HTML5 e permite exportar conteúdo em flash para o HTML5 em suas ferramentas mais recentes.

E todos sabemos quanto custa o Google com o html5. Caramba, o seu mais recente sistema operacional (Chrome OS) nada mais é do que um grande navegador da web.

Os aplicativos para celular (iPhone, Android, WM7) são muito difíceis para uma empresa programar, especialmente para muitos dispositivos diferentes (cada um com seu próprio idioma), portanto, suponho que isso não dure muito tempo. Ou seja, HTML5 será a linguagem unificadora. O que é um pouco triste para os desenvolvedores de aplicativos, porque agora os usuários poderão reproduzir os aplicativos html5 "legais" gratuitamente na Web e será difícil cobrar por eles.

Então, as linguagens fortemente tipadas estão realmente condenadas e, no futuro, digamos 5 a 10 anos, a programação do lado do cliente será apenas em HTML5? Todos nós nos tornaremos programadores javascript? :) Porque os sinais com certeza apontam dessa maneira ...

Acho errado sugerir que o HTML5 / JS substitua TODAS as linguagens do lado do cliente. Muitos aplicativos serão assim nos próximos anos? Sim provavelmente. Será que todos eles? Não.

O outro ponto importante a ser observado é que a paisagem está mudando constantemente. O HTML5 é uma ótima tecnologia que promete resolver muitos dos problemas que os desenvolvedores estão enfrentando ao tentar escrever aplicativos que funcionam em várias plataformas. Certamente, o HTML5 / JS pode resolver muitos desses problemas, mas o cenário mudará e um novo conjunto de problemas surgirá. Eventualmente, o HTML5 parecerá datado.

Em 10 anos, pergunte-se se o HTML5 / JS foi a solução para todos os problemas e posso garantir que a resposta será não. Em 20 anos, a pergunta em si provavelmente parecerá ridícula.

Javascript é uma linguagem de programação muito ruim. A tradução de linguagens de programação com tipos estatísticos, como Java com GWT, está se tornando cada vez mais comum. Javascript pode se tornar o mesmo tipo de linguagem unificadora que o assembler - você pode escrevê-lo diretamente, mas raramente é uma boa ideia.

Sim.

Aqui está o porquê. Os aplicativos são compostos de código da interface do usuário e dados de back-end. O código da interface do usuário é executado em HTML5 / CSS3 / Javascript. O código de back-end pode ser proprietário e executado em qualquer idioma. Além disso, o jQTouch e bibliotecas semelhantes podem ser usados ​​para emular UIs semelhantes ao iPhone, mas de código aberto e escritos em Javascript / HTML5 / CSS. O jQTouch mostrou que, se o navegador conceder aos programadores JS acesso aos eventos de interface do usuário do dispositivo, os programadores JS emularão qualquer estilo de interface do usuário que esteja na moda para a mesma plataforma.

Os programadores Javascript estarão mais em demanda do que nunca. Em uma arquitetura de controlador de exibição de modelo, o modelo e o controlador estão no backend, mas o código de exibição é melhor gravado no navegador. ou seja, HTML5, Javascript, CSS. E você precisa escrever o código JS para acessar os dados de back-end, especialmente com o código AJAX pesado.

Todos os ganhos de produtividade serão direcionados para as linguagens interpretadas dinâmicas. À medida que os processadores ficam cada vez mais rápidos, a produtividade de codificação do programador, a produtividade do administrador de sistemas e a produtividade do administrador de aplicativos são influências mais fortes na produtividade geral. Você simplesmente não precisa se preocupar com a rapidez com que o VM ou o compilador da sua linguagem de programação executa mais. Agora, você precisa se preocupar mais com quanto custa provisionar e dar suporte ao seu aplicativo.

A maioria dos aplicativos independentes não é tão boa na minha opinião. Assim como existem alguns ótimos aplicativos de PC independentes, e os melhores estão sendo transformados em aplicativos da Web. Na verdade, é melhor doar o aplicativo cliente HTML / JS / CSS gratuitamente e cobrar uma taxa mensal pelo acesso aos dados de back-end e à lógica de negócios. Os programadores farão uma venda melhor de assinaturas do que os aplicativos únicos.

BTW, dê uma olhada neste vídeo sobre como escrever parte de um aplicativo Web independente em um navegador Webkit. É interessante...

Existe uma vontade de substituir linguagens de codificação de aplicativos como C ++, Java ... por HTML / Javascript. Há muitas razões por trás disso, algumas delas:

• Desenvolvimento mais rápido
• Força de trabalho mais barata
• A conectividade é incorporada
• Mais fácil de produzir algo que parece bom
• O texto é acessível para mecanismos de indexação

No entanto, talvez outros idiomas apareçam, para serem usados ​​como substitutos do JavaScript. Afinal, é difícil ter um idioma que possa fazer tudo certo, mantendo um idioma de alto nível! E o JavaScript existe há algum tempo e acumulou algumas deficiências.

O JavaScript pode muito bem acabar sendo a principal linguagem para o cliente, mas acho que não pode nem deve ser a única , porque, sendo JS uma linguagem orientada por padrões e projetada por um comitê, isso simplesmente matará a inovação nesse nível (linguagens de programação).

Também depende da habilidade da maioria dos desenvolvedores e das ferramentas que eles usam. Os gigantes da tecnologia mencionados podem impulsionar uma tecnologia com base nas ferramentas que eles fornecem. Por exemplo, as pessoas dizem que o HTML5 é um assassino em Flash, mas acho que é muito longe, existem muitos desenvolvedores de Flash e é uma tarefa assustadora mudar suas habilidades para JavaScript. O que eventualmente acontece, a habilidade permanece a mesma, mas a produção se torna diferente. Nesse caso, a Adobe lança a ferramenta de conversão HTML5.

Além disso, você precisa pensar no desempenho dos aplicativos clientes. Onde for necessário, será utilizada a ferramenta específica da plataforma. Leva jogos e aplicativos para iOS, por exemplo. Sei que o WebGL está saindo bem, mas sinto que as pessoas ainda usam C para criar jogos. Ou eles criarão uma linguagem de jogo que cria jogos de alto desempenho. Inicialmente, a Apple queria apenas aplicativos da web, mas quando os desenvolvedores viram as maravilhas do Cocoa, saltaram sobre ele para criar aplicativos elegantes.

Para resumir, sempre haverá novas ferramentas / linguagem / tecnologias que serão sempre mais legais que as atuais.

Nem todos, mas provavelmente a maioria. Talvez o javascript possa se tornar rápido o suficiente para substituir o HashCalc, mas não há alternativa da Web ao VLC (os navegadores não suportam todos esses codecs). Duvido que os navegadores da web me permitam acessar qualquer arquivo que eu queira ou armazene uma lista de arquivos recente (sem um 'está ok para acessar' toda vez que clico no arquivo recente) e não gosto da ideia de distribuir aplicativos que sejam 99% de navegadores da web (vários mb) com meus 100kb de código quando se trata de casos em que o código quebra, os navegadores bc não são compatíveis com o html ou preciso de uma variante / pequena modificação do webkit.

-edit- também gosto de linguagens estáticas e não dinâmicas, mas estou assumindo que posso usar uma boa linguagem com o LLVM, que deve ser suportada pelo navegador.

Acho que continuaremos nessa direção até que o navegador se torne o sistema operacional e tudo começará a se reciclar na mesma ordem, mas com lições aprendidas e melhorias.