5 razões pelas quais JavaScript pode ser a próxima grande linguagem

October 30th, 2007 § 19 comments

Há sempre uma grande quantidade de especulação sobre qual a próxima linguagem que ganhará as mentes e corações dos desenvolvedores. As apostas atuais muito provavelmente tendem na direção do Ruby.

Considerando o sucesso que o Ruby on Rails está experimentando atualmente, eu também me sinto tentado a dizer que Ruby é a próxima grande linguagem. Ruby tem a história perfeita: virtualmente desconhecida em sua primeira década de vida, surgiu com uma estrela no cenário atual de programação, graças a uma killer app cujo mindshare não para de crescer.

Ruby é, através de Rails, responsável pela aceitação de linguagens dinâmicas como ferramentas possíveis na atualidade. Alguém poderia argumentar que a atual revolução dinâmica aconteceria com ou sem a presença do Ruby. Eu tenho que discordar: o sucesso do Ruby fez com que o passo de pesquisa e experimento em linguagem alternativas aumentasse em uma ordem de magnitude nos últimos dois anos. Eu acompanho o cenário de desenvolvimento há mais de uma década e foi somente após a explosão provocada pelo Rails que o cenário mudou.

Ainda assim, eu acredito que Ruby não será a próxima grande linguagem. A despeito de desenvolvimento como JRuby e IronRuby, o lugar no topo não está garantido para essa bela linguagem.

Esse lugar, eu acredito, pertence ao JavaScript.

Se o JavaScript se tornar a próxima grande linguagem, um ciclo completo estará formado. Uma linguagem que nasceu para transformar a parte cliente da Web e sofreu uma queda ignóbil, sendo considerada por anos algo que somente merecia a atenção de candidatos a programadores, está ressurgindo agora com uma fênix, elevada ao panteão de linguagens sérias e merecedoras de atenção.

Aqui estão cinco razões pelas quais JavaScript pode se tornar a próxima grande linguagem tanto no lado cliente quanto do lado servidor das aplicações modernas:

Razão #1: A similaridade com C e Java, simplificada

A verdade é dura: C ainda desfruta de uma enorme popularidade e influência do uso e desenho de linguagens. E com a ascendência do Java, a sintaxe do C se tornou ainda mais dominante. Por si só, isso já é um motivo para garantir uma certa medida de popularidade ao JavaScript.

Mas o motivo real está no fato de que JavaScript simplifica a sintaxe do C e do Java a um nível palatável para o desenvolvedor médio. O uso de características dinâmicas fala mais alto do que qualquer coisa. Se há um ponto em que o Java falhou foi aí: se Java tivesse gerado algo como o Groovy no seus dois primeiros anos e tivesse convertido isso na linguagem padrão para applets, a história da Web teria sido completamente diferente.

Um garbage collector funcional ajuda bastante. Como o Ruby e Python provaram, não é preciso controle granulado sobre alocação de memória para criar programas complexos.

A única desvantagem real do JavaScript, no que tange à sintaxe, pode estar no fato da mesma ser baseada em protótipos e não em classes. Isso deve mudar com o JavaScript 2, mas a decisão final dos desenvolvedores quanto a isso ainda está no futuro. Até o momento, o uso de protótipos não está freando a linguagem, embora esteja limitando determinados usos.

Razão #2: A plataforma é a Web

Não há nada mais ubíquo do que código fonte HTML. JavaScript segue a mesma direção. A despeito de minimizadores de código e obfuscadores, a vasta maioria do código JavaScript em uso atualmente está disponível para adaptação e incorporação em aplicações. De editores de textos ricos a plataformas completas de construção de interfaces passando por bibliotecas utilitárias, há uma enorme quantidade de código documentado e acessível.

Esse código, além de tudo, roda em uma plataforma aberta e extremamente acessível, que é a própria Web. Isso dá ao JavaScript um grau de liberdade em termos de experimentação que não está disponível a basicamente nenhuma outra linguagem. Com o crescimento de ferramentas de apoio, o custo de desenvolvimento inicial está caindo até um ponto em que qualquer programador pode se dar ao luxo de desenvolver aplicações mais complexas sabendo que terá suporte amplo para isso.

O fim das grandes diferenças de compatibilidade entre os vários navegadores também está contribuindo para que a Web se estabeleça cada vez mais como uma plataforma sólida para aplicações suficientemente sofisticadas que se confundem com o desktop

E um último ponto: o JavaScript está intrinsecamente mesclado em duas arenas que paralelizam a Web.

A primeira dessas arenas é a de aplicações ricas na forma de tecnologias como Adobe Air e Siverlight. Essas plataformas não só estão adotando o JavaScript como ferramenta primária como estão também aumentando o seu passo de desenvolvimento, oferecendo melhores interpretadores e compiladores.

A segunda arena é a de aplicações offline. Com o aumento de aplicações com o serviço, o uso de uma linguagem comum é necessária para aplicações que queiram deixar o confinamento do navegador e se tornarem cidadãs de um desktop extendido. JavaScript já é a linguagem candidata perfeita para isso.

Razão #3: Ajax

Não só a Web é a plataforma, mas o uso de Ajax está trazendo toda uma nova comunidade de desenvolvedores para o JavaScript. O Ajax está fazendo hoje o papel que o view source fez na Web de dez anos atrás.

Enquanto antigamente o JavaScript era relegado a funções como criar rollovers, simular transições e efetuar procedimentos minimalísticos similares em aplicações Web, aplicações atuais rotineiramente carregar centenas ou milhares de kilobytes de JavaScript para transformar a experiência do usuário.

Hoje espera-se que um desenvolvedor saiba utilizar plenamente JavaScript em suas aplicações. Seja qual for a linguagem que ele use para desenvolver–Ruby, Python, C# ou Java–uma linguagem permanece constante: o JavaScript.

Como é improvável que outras linguagens ganhem utilização em um navegador, a tendência é que o JavaScript se torne cada vez mais adaptada a criar uma experiência completa de desenvolvimento e execução em um ambiente que não ficará nada a dever aos atuais O Ajax está fazendo hoje o papel que o run-times.

Razão #4: Protocolos e ferramentas

JSON é hoje basicamente um padrão de transmissão e transformação de dados na Web. Compacto e compactável, substituiu rapidamente o XML como protocolo de transporte e tem liderança indiscutível por estar baseado na única linguagem cliente disponivel.

Esse desenvolvimento, apoiado em outros como o CouchDb estão dando ao JavaScript uma legitimidade enorme em termos de aplicação real. Nem mesmo o mundo corporativo foi capaz de resistir à mudança desencadeada por esse pequeno protocolo e, atualmnte, transformações baseadas em JavaScript são comuns. Tecnologias como o CouchDb, com sua integração direta ao JavaScript e com um uso eficiente e lógico de uma arquitetura REST só trazem benefícios à linguage.

Além disso, ferramentas e ambientes de desenvolvimento mais sofisticados estão proliferando. Ambientes de desenvolvimento estão intrinsecamente ligados ao sucesso de uma linguagem–isso, inclusive, é algo que a comunidade Ruby está percebendo agora. Esses ambientes fornecem um trampolim para desenvolvedores inexperientes e uma base sólida para desenvolvedores já experimentados.

Esse tipo de legitimização pode ser mais um dos passos que vai conduzir o JavaScript ao ponto em que outras linguagens igualmente dinâmicas não podem chegar.

Razão #5: Distribuição ubíqua

O JavaScript não está mais só nos navegadores. Como mencionado anteriormente, tanto o Adobe Air quanto o Silverlight incorporam funcionalidades baseadas em JavaScript–e de maneira muito significativa.

Mas a evolução do JavaScript não para aí. Máquinas virtuais stand-alone já existem e podem ser usadas para basicamente qualquer tipo de desenvolvimento necessário com JavaScript. A mera integração com o Java permite o acesso a uma quantidade enorme de bibliotecas que transformam o desenvolvimento de novas aplicações um passo trivial.

O processo atual de desenvolvimento do JavaScript está formando um círculo virtuoso de desenvolvimento que está colocando a linguagem em uma posição de franca ascenção. Desdobramentos como a liberação do Tamarin são avanços que repercutiram em breve na comunidade de desenvolvimento.

Olhando para a combinação acima, eu não duvido que em breve surja um framework Web baseado em JavaScript, funcionamente equivalente ao Rails ou Seaside, capaz de ser rodado em basicamente qualquer plataforma possível, dada a profileração do JavaScript, e com a capacidade de integrar-se intimamente com outras ferramentas baseadas em JavaScript. É só uma questão de tempo.

Conclusão

Prever o futuro é uma atividade essencialmente frágil. Mas especular sempre é interessante quando o passo de modificações em uma determinada área parece chegar em um certo nível onde tudo parece posssível. Esse é o caso do JavaScript agora, em minha opinião, e as cinco razões acima são uma reflexão desse pensamento.

Eu volto então à minha aposta: e se eu tivesse que apostar agora, eu apostaria no JavaScript.

§ 19 Responses to 5 razões pelas quais JavaScript pode ser a próxima grande linguagem"

  • AkitaOnRails says:

    Hm, bons pontos, é um ponto de vista :-) Na realidade, Javascript *já* é a uma grande linguagem. Segundo o índice TIOBE ela é a 9o mais usada, à frente de Ruby.

    Eu particularmente gosto dos conceitos e programo JS desde a primeira versão em 1995, também gostaria que ela fosse usada mais. Porém, não vou tentar imaginar um “vencedor”, talvez pelo fato que isso não existe. Perl, Python, Javascript, estão mais ou menos com o mesmo market share há muito tempo, sem quedas ou subidas dramáticas. Não acredito que nenhuma se sobressaia.

    Não precisa haver “um” vencedor. É o meu ponto de vista anti-Highlander: “não precisa haver apenas um”. Não precisa ser o One Ring: “one language to rule them all, and in the darkness bind them”.

    Javascript é mais ubíquita do que parece. Graças à “venda casada” com os browsers, a própria Web, todo mundo tem necessariamente pelo menos um interpretador Javascript rodando. Mesmo assim é a linguagem mais incompreendida. Depois de 13 anos ela ainda não floresceu como poderia. Alguns dos motivos estão aqui:

    http://javascript.crockford.com/javascript.html

    Porém, eu vejo Javascript num nicho diferente, onde linguagens como o LUA atuam: como engines de script para outros sistemas/aplicativos, para “Embedded systems”.

    Os novos ‘brinquedinhos’ web, os Widgets, Gadgets ou seja lá qual for o nome para os mini-apps de plataformas como Dashboard (Mac) ou Konfabulator (Yahoo), é todo em Javascript.

    A suíte inteira da Adobe, de PDF a Photoshop suporta scripting com Javascript. Além disso já se tentou usar Javascript no server-side. Talvez o mais famoso foi o suporte a JScript no ASP 2.0 no antigo IIS (argh, eu sei). Temos mod_js para Apache.

    A maior vantagem do Javascript é ser pequeno, muito pequeno. Isso permite embutir essa engine em qualquer lugar que se precise ‘colar’ componentes, e javascript é uma excelente linguagem-cola. Um bom exemplo disso é o Rhino: javascript engine escrito em Java, que pode ser embutido em qualquer coisa que seja feita em Java, como servlets ou applets.

    Para quem não conhece o conceito: embedded languages são boas para coisas como aplicativos (como scripts de Word) ou jogos. Quem já jogou Doom ou derivados vai lembrar que havia um console onde se podia criar pequenos scripts (para cheating …). Os criadores de jogos não tem interesses em criar uma nova linguagem só para colocar num console. Solução: embutir uma linguagem que já existe, que seja pequena, compacta e fácil de integrar. Lua e Javascript servem esse tipo de mercado com facilidade.

    “Mas” nem tudo está perdido! :-) Alguns pesquisadores vem considerando essa possibilidade do Javascript se tornar uma linguagem de uso geral. A Sun, recentemente, tem atacado todos os tipos de fronts, e JS é uma delas, como mostra este paper de outubro de 2007:

    http://research.sun.com/techrep/2007/smli_tr-2007-168.pdf

    Por causa do Rails, todo mundo resolveu se mexer ao mesmo tempo. O próprio Ruby foi uma linguagem dormente e de nicho antes disso. O Javascript primeiro precisa de um patrono, hoje ninguém serve o papel de ditador-benevolente para liderar sua evolução; segundo precisa retirar sua má-reputação (talhada a anos de interpretadores bugados, uma especificação ECMA extremamente ruim, etc), terceiro precisa de um killer-app, afinal ser ubíquito não quer dizer ‘ser bom’, porque se fosse por isso o IE6 e o Windows teoricamente seriam ‘bons’. Além disso JS por sí só não tem um Core Library extensivo o suficiente: ela depende do DOM no browser, depende de componentes ActiveX, extensions, pois por si só ela não faz muita coisa. Mesmo no server-side, quando eu usava com ASP, para acessar o filesystem eu precisa do componente COM FileSystemObject. Para acessar a internet, ela precisa do XmlHttpRequest, e assim por diante. Por si só ela não tem recursos uniformes.

    Mas o ponto de vista é válido para que as pessoas não fiquem cegas ‘apenas Python …’, ‘apenas Perl …’, ‘apenas Java …’. Conclusão: não haverá uma linguagem vencedora. Esse papel continuará sendo do C por anos a fio, abaixo dela continuará existindo um ecossistema onde cada linguagem ocupará uma fatia ‘suficiente’, mas nenhuma necessariamente sendo ‘a maior’ e substituindo as demais.

    Existe até um caso engraçado :-) O bom e velho John Lam, re-escreveu um framework-clone ao Rails todo em Javascript!!

    http://www.iunknown.com/2007/06/steve-yegge-por.html

    Ele roda sobre o Rhino, e na verdade John Lam foi a pessoa mais importante a declara que JS poderia ser a “próxima grande linguagem”:

    http://steve-yegge.blogspot.com/2007/02/next-big-language.html

    Seria interessante. De qualquer forma, o link acima tem 148 comentários!! Uma guerra acirrada :-) Continuo achando que não haverá “a” próxima grande linguagem. Well, but what do I know? :-)

  • AkitaOnRails says:

    Oops, falei errado, o último link não é do John Lam, mas do Steve Yegge :-)

  • AkitaOnRails says:

    Ah é, e não podemos esquecer do JavaScript on Junction, um projeto acho que com 2 anos já e que é um clone de Rails em Javascript:

    http://code.google.com/p/trimpath/wiki/RubyRailsVsJavaScriptJunction

  • Concordo que um dos problemas para a adoção vai ser o pessoal entender como funciona a OO baseada em protótipos e não em classes…

    Além de outras coisinhas que seria legal eles arrumarem, como a impossibilidade de usar o “this” para referencia a própria classe numa função anônima (tem que criar outra variavel pra fazer essa representação)… eu acho chato isso 😛

  • […] Superfície Reflexiva » 5 razões pelas quais JavaScript pode ser a próxima grande linguagem Uma linguagem que nasceu para transformar a parte cliente da Web e sofreu uma queda ignóbil, sendo considerada por anos algo que somente merecia a atenção de candidatos a programadores, está ressurgindo agora com uma fênix, elevada ao panteão de lin (tags: logbr.reflectivesurface.com 2007 mes9 dia30 at_tecp javascript blog_post) […]

  • Thiago Silva says:

    Até tú, Brutus? 😉

    “A única desvantagem real do JavaScript, no que tange à sintaxe, pode estar no fato da mesma ser baseada em protótipos e não em classes”

    Por que acha que isso é uma desvantagem real?

    “o uso de protótipos não está freando a linguagem, embora esteja limitando determinados usos”

    Que tipo de uso está sendo limitado?

    “O fim das grandes diferenças de compatibilidade entre os vários navegadores “

    Eu não vou prender meu folego para ver o fim das diferenças…

    Bom, que JavaScript vai pegar em breve, eu não duvido. Só me pergunto “por quanto tempo?”. Pois eu não acho que durará muito.

    Meus dois centavos? Não acho que a possível adoção “mais agressiva” do JS vá oferecer soluções significantes na web. Acho que, pelo contrário, irá evidenciar problemas antigos e mais fundamentais.

    Agora, com meus centavos no balcão, pergunto: vc já deu uma olhada na nova especificação da linguagem? Grandes surpresas por ali….

    []’s
    Thiago

  • Ronaldo says:

    Opa, Akita–

    Realmente você gosta de respostas detalhadas. :-)

    Sobre ser um grande linguagem, eu estava pensando mais no sentido de ser uma linguagem com um uso não restrito. Por mais que JavaScript seja usado como linguagem auxiliar, ele ainda não é uma linguagem de uso geral–nem mesmo como scripting.

    Eu acredito que existam vencedores, sim. Não acho isso ruim e acho, inclusive, que a indústria poderia se beneficiar de um novo vencedor. A supremacia do C como linguagem de baixo nível não deve deixar de existir, mas não é aí que eu acredito que o JavaScript poderia entrar. Eu acharia interessante se ele tomasse o lugar do Java, por exemplo, como algo em que um projeto pudesse ser feito do princípio ao fim. A mudança de paradigma representada por isso traria um ânimo novo a uma indústria que está sem grandes revoluções desde os anos 70. O JavaScript poderia abrir uma porta para isso.

    O que eu estou considerando aqui não é uma filosofia de que só pode haver uma linguagem. Como qualquer programador um pouco mais experiente, eu uso uma quantidade enorme de ferramentas e linguagens e acho isso fundamental para o crescimento individual como programador e da indústria em si. A idéia nunca foi converter todos os programadores em usuários de uma linguagem só e acho que as dezenas de textos no meu blog falando sobre diversidade deixam isso mais do que claro.

    Eu também não acredito que JavaScript ficará restrito a esse nicho que você cita. Primeiro porque já saiu dele há um bom tempo. O ActionScript não é nada mais do que uma versão ligeiramente modificada no JavaScript (ou ECMAScript como queira) e não fica, de forma alguma restrita a isso. Widgets vieram até depois e seu uso de JavaScript é meio uma coincidência do meio em que nasceram. Há, sim, como você aponta, muito uso como scripting mas já se evoluiu muito além disso.

    Quanto ao lado server-side, é justamente aí que eu acho que teríamos muito a ganhar com o JavaScript. Não as versões limitadas de um JScript para ASP ou de um Sybase JavaScript. Tampouco com um mod_js que é basicamente uma versão JS do CGI mais básico possível. O interessante é justamente capitalizar em tudo aquilo que eu citei, de um REST JSON-based a um CouchDB passando por um Prism.

    Eu citei o Rhino justamente como um bom exemplo do que está sendo feito, mas não em termos de recursos embutidos. Acho que há um pouco de limitação até no que os próprios desenvolvedores pensam. O que o Yegge fez–eu lembro que na época causou um furor e é uma pena que não tenha sido publicado–mostra bem isso.

    No final, você quase cita o que eu escrevi: por causa do Rails, o cenário está mudando e isso é bom. Eu mantenho o “pode” no título justamente porque está mudando tanto que, na época em que o JavaScript se estabelecer como linguagem geral, o cenário pode ter mudado tanto que alguma outra linguagem estará fazendo as rondas. Mas o Ruby mesmo é um prova de que as coisas estão caminhando além do C. Índice TIOBE à parte, sendo o mesmo bem questionável, o uso de Ruby provavelmente é muito maior que o indicado. Isso vem da divisão corporativo/uso independente. E aí é que está o grande pulo do gato.

    Rafael, acho que é justamente por isso que eles estão adicionando classes à próxima versão do JavaScript. Aí a coisa fica mais opcional e mais “comum” em um certo sentido.

    Essas limitações, eu acredito, estão sendo resolvidas bem rápida. E acho que, atualmente, até o IE vai acompanhar isso.

    Thiago, poxa, não posso falar em JavaScript não? :-)

    Sobre a desvantagem, não é como linguagem. Eu não dou a mínima. Para mim, quanto mais paradigmas melhor. Mas a maioria dos programadores não pensa assim.

    Isso, de certa forma, limita certos usos implícitos de cadeias de objetos. A falta de distinção entre funções e objetos é um complicador adicional nisso. Não é que não dê para fazer o necessário, mas protótipos, pelo menos em minha opinião, são um pouco menos eficientes para representar o tipo de estrutura que um Rails ou Seaside precisa.

    Quanto ao fim das diferenças, acho que basicamente já aconteceu, não?

    Finalmente, se evidenciar os problemas, tanto melhor. Já está mais do que na hora de pensar em um tecnologia de programação que realmente seja adequada à Web.

  • AkitaOnRails says:

    Bom, novamente, não dá para ‘saber’ o que vai acontecer. O que fazemos é olhar para o passado e ver qual tem sido o trend nesse sentido e até agora nada realmente relevante aponta para uma grande revolução do lado Javascript. Tornar-se ubíquito não é um fator de relevância. É como uma caneta Bic, é ubíquita ao ponto de ser invisível. Isso a torna um excelente produto, sem dúvida, mas nada que vai torná-la a melhor caneta do mundo. Javascript é a Bic dos scripts. Exatamente como eu disse sobre embedded systems, ActionScript é justamente o Javascript usado para grudar pedaços que nunca foram nativas a ela: objetos vetoriais, linhas de tempo, elementos gráficos. Poderia ser qualquer linguagem (como foi, aliás, antes do Flash 3 se não me engano). É muito mais simples – e inteligente – plugar uma engine Javascript.

    Outro ponto é que o Javascript não pode ser feito em Javascript (talvez eu esteja errado, mas pelo menos é o que me lembro agora). Ele depende de outras linguagens para complementá-la. É o mesmo problema do Ruby agora, que ambos JRuby, Rubinius, XRuby estão tentando contornar. Para pensar em ser o “vencedor” pelo menos ele tem que não depender de outra linguagem. Porém como o Javascript não é auto-sustentável e nem tem Core Libraries suficientes para ser genérica (não tem I/O, não tem threads, etc) é muito difícil despontar com algo mais relevante do que ele já é. E na minha opinião onde ele está hoje já é bastante bom. Ele já está em diversas plataformas e impediu que outras sub-linguagens surgissem para o mesmo fim que ele consegue resolver.

    O “inimigo” de todos os tempos é o C :-) Por alguma razão muita gente odeia ele e gostaria que ele sumisse e outra coisa mais moderna tomasse seu lugar. Porém, C no fundo no fundo não é mais do que – vamos dizer grosseiramente – macros sofisticadas para Assembler. E até os processadores mudarem de paradigma completamente, abandonarem o esquema registradores, stack, instruções, o C continuará sendo o líder pois é o mais próximo do metal que se chega sem ter que literalmente caçar bit. Fortran é quase tão próximo do metal quanto mas mais abstrato e para algumas categorias de programação ele ainda não foi extinto. Tanto que quando a Intel lança novos processadores os primeiros dois compiladores de alta-performance que eles sempre lançam é a de C e de Fortran.

    Goste ou odeie (e eu espero não ter que recorrer a ele por muito tempo), o C continuará conosco.

    Alguns níveis acima disso, temos as linguagens de alto nível. E aí o mercado rola solto. Existem literalmente dezenas de linguagens, cada uma um pouco melhor do que a outra em algum aspecto mas nenhuma sendo dramaticamente melhor do que a outra.

    Isso me lembra aquelas imagens que o pessoal grudava a boca da Angelina Jolie, os olhos da Nicole Kidman, o corpo da Jessica Alba, os cabelos da Lindsay Lohan, etc etc naquela tentativa: vamos montar a mulher mais linda do mundo. Parece fácil: basta pegar o melhor pedaço de cada. Por incrível que parível, o resultado sempre é horripilante. Eu penso a mesma coisa de linguagens: porque existem tantas dezenas de linguagens? Porque cada uma é boa em um ou mais aspectos e não em todos.

    Javascript é uma excelente linguagem, a seleção natural passou por ela e ela sobreviveu em seu nicho. É um nicho em que outras linguagens como o próprio Java não se deram bem e foram selecionadas para não sobreviver nela. Ruby está exatamente neste momento sendo provado e vendo se sobrevive dentro dos ambientes em que se propôs, o tempo dirá como ela vai evoluir.

    Portanto, é o que disse, assim como no meio ambiente, não existe uma única espécie vencedora. Homo sapiens são ubíquitos mas nem por isso ela acabou com todas as outras milhares de espécies. Nós precisamos da diversidade, é a única forma de evoluir.

  • Ronaldo says:

    Acho que vamos ter que concordar em discordar, até porque estamos falando de coisas diferentes. Quando eu digo próximo grande linguagem, eu estou falando em algo como a ascendência do Java a partir de 1995. Já você está falando em uma linguagem que domine à exclusão das demais. Isso nunca aconteceu e nem vai acontecer.

    Quanto às limitações atuais do JavaScript, isso é uma mera função do modo como ele é usado hoje. Acrescentar suporte a threads, IO, etc, seria algo relativamente trivial–basta adicionar algum mecanismo de chamada ao OS (como o Squeak, por exemplo, faz usando FFI) e você teria basicamente tudo que é necessário. Tanto no caso do Rhino como Spidermoney e Tamarin bastaria um pouco de esforço para fazer isso acontecer. O mesmo vale para bootstraping que essencialmente depende da capacidade de executar análise sintática/semântica e emitir código. Isso seria relativamente trivial dentro do contexto anterior.

    Eu não compararia essa situação ao Ruby pelas diferenças óbvias: Ruby pode perfeitamente fazer seu próprio bootstrap hoje. É só que ninguém fez isso–provavelmente pela maior familiaridade com ambientes pré-existentes. Eu também não diria que o ActionScript é uma cola para algo não nativo: ao contrário, é uma mostra excelente de que um pequeno esforço pode levar o JavaScript a qualquer direção.

    Em resumo, o que eu estava dizendo é que JavaScript pode ser uma linguagem de uso geral–e provavelmente será, considerando os desenvolvimentos recentes. E pode também se tornar uma linguagem forte, ascendente. Isso não significa, repito mais uma vez, que ela se tornará a única. Como eu disse anteriormente, isso não só não é possível como eu não mencionei isso sequer uma vez em meu texto ou comentários. Eu acho que você está lendo os mesmos com um pouco de pressa demais.

  • AkitaOnRails says:

    Então concordamos, porque eu tinha entendido diferente :-) E não entenda “cola” com algo pejorativo. Bindings GTK+ num Mono por exemplo, não significa que isso seja ruim. Na verdade isso é “integração” e linguagens que oferecem isso de maneira mais simples sempre são boas. Javascript tem um histórico disso, o que é definitivamente bom.

    Meu ponto é que Javascript existe há anos. Apesar do seu paradigma diferenciado de Protótipo em vez de Classes ele ainda não é – for falta de palavra melhor – ‘compelling’ o suficiente. Tanto que de fato ninguém a defende nem a critica muito. Não vejo conferências sobre Javascript, manifestos sobre Javascript (além deste, claro :-)) enfim, não precisa, ela já é muito bem adotada. Se você quiser fazer web development precisa saber javascript, se quiser fazer Flash precisa saber Javascript.

    A hora que surgir um “killer app” como foi o Rails no caso do Ruby, que a coloque na frente dos holofotes aí sim, poderemos falar em tomar a dianteira.

    Ninguém poderia imaginar que Rails surgiria do nada. Muito menos que faria o sucesso que fez. Ninguém pode imaginar algo assim porque não é uma tendência, foi um evento Big Bang. Outros frameworks vieram antes dele. Um conjunto muito vasto de fatores, incluindo sorte, fizeram isso funcionar. Por anos as pessoas vão analisar: “o que fez Rails funcionar?” e mesmo juntando as mesmas condições não será necessariamente possível recriar o mesmo evento.

    Portanto por enquanto é uma adivinhação. Pode ser Javascript. Pode ser Dylan. Poder ser D. Pode ser OCaml. Pode ser Haskell. Pode ser Erlang. Mas por enquanto não há um número suficiente de Think Tanks advocando isso. Pelo contrário, pelo menos por enquanto os Pragmatic Programmers estão advocando Erlang – e muitos já a estão descartando. Não há nenhum fator que torne nenhuma delas um candidato preferencial frente aos outros, e temos MUITOS candidatos :-)

    No final, como diriam os evangelistas open source: “é bom ter escolhas”.

  • Thiago Silva says:

    “Thiago, poxa, não posso falar em JavaScript não? :-)

    Claro que pode! Só me chamou a atenção vc, além de outros ao longo deste ano, pensarem que JS será a próxima “surpresa” 😉

    “Não é que não dê para fazer o necessário, mas protótipos, pelo menos em minha opinião, são um pouco menos eficientes para representar o tipo de estrutura que um Rails ou Seaside precisa.”

    Eu acho difícil pensar em protótipos como algo que deixa a desejar em comparação com classes, pois vejo o primeiro como fundamento para o segundo. Por isso, particularmente, eu prefiro estipular o conceito de classes utilizando o que a linguagem JS oferece ao invés de definir, a nível de linguagem, uma notação de classes, como está sendo feito na nova especificação. Eu entendo porque estão fazendo isso, e concordo, dado o panorama geral. Mas não acredito que a adição de classes incrementa o mérito técnico desta linguagem…apenas a torna palatável para o grande público.

    “Quanto ao fim das diferenças, acho que basicamente já aconteceu, não?”

    Não temos a incompatibilidade que tinhamos há 10 anos atrás. Mas também, não acredito que tenhamos equivalência.

    “Finalmente, se evidenciar os problemas, tanto melhor. Já está mais do que na hora de pensar em um tecnologia de programação que realmente seja adequada à Web.”

    É com isso que estou contando :)

    []’s
    Thiago

  • […] 1st, 2007 by Rafael Mueller Não deixem de ler esse post e os comentários feitos no blog do […]

  • Thiago Silva says:

    A propósito…

    “Tanto no caso do Rhino como Spidermoney e Tamarin bastaria um pouco de esforço para fazer isso acontecer.”

    No caso do Rhino, não há esforço algum. Todas as classes Java do classpath podem ficar expostas (incluindo threads, IO, etc) para serem manipuladas escrevendo código JS. Mas, infelizmente, a performance do Rhino não é boa.

    []’s
    Thiago

  • Ronaldo says:

    Opa, Thiago–

    “Claro que pode! Só me chamou a atenção vc, além de outros ao longo deste ano, pensarem que JS será a próxima “surpresa” ;)”

    Pois é. Acho que o negócio começou a se acumular e o pessoal está prestando mais atenção.

    “Eu acho difícil pensar em protótipos como algo que deixa a desejar em comparação com classes, pois vejo o primeiro como fundamento para o segundo. Por isso, particularmente, eu prefiro estipular o conceito de classes utilizando o que a linguagem JS oferece ao invés de definir, a nível de linguagem, uma notação de classes, como está sendo feito na nova especificação. Eu entendo porque estão fazendo isso, e concordo, dado o panorama geral. Mas não acredito que a adição de classes incrementa o mérito técnico desta linguagem…apenas a torna palatável para o grande público.”

    Do ponto de vista de interessado em linguagens, eu também acho que não fica a desejar. É uma forma excelente de oferecer uma maneira alternativa de implementação e isso força uma discussão. Mas há um certo pragmatismo necessário para que a linguagem se torne dominante e eu acho que os protótipos acabam meio que caindo nisso sendo próximos demais para forçar uma variação grande na aceitação.

    “Não temos a incompatibilidade que tinhamos há 10 anos atrás. Mas também, não acredito que tenhamos equivalência.”

    Claro, equivalência não. Mas, em termos gerais, acho que a preocupação é bem menor. Isso se a briga não continuar. :-)

    “É com isso que estou contando :)”

    Idem. :-)

    “No caso do Rhino, não há esforço algum. Todas as classes Java do classpath podem ficar expostas (incluindo threads, IO, etc) para serem manipuladas escrevendo código JS. Mas, infelizmente, a performance do Rhino não é boa.”

    Sim. Mea culpa pelo delize. :-)

  • […] vai ser a próxima grande linguagem. Apesar de ainda estarmos longe de resultados surpreendentes, caminhamos rápido nesse sentido. […]

  • Carlos says:

    O que me dizem do Jaxer, do pessoal do Aptana.

    Não seria o ponto que faltava pro Javascript?

  • Djalma says:

    Bicho, que post!! Tá de muitíssíssímo parabens! Concordo ae quase 100%, os quase que nao cocordo é por que voce falou de coisas que eu nao entendo ainda, hehehe!

    Abraços.

  • […] 5 razões pelas quais javascript pode ser a próxima grande linguagem […]

  • […] vai ser a próxima grande linguagem. Apesar de ainda estarmos longe de resultados surpreendentes, caminhamos rápido nesse sentido. […]

Leave a Reply

Your email address will not be published. Required fields are marked *

What's this?

You are currently reading 5 razões pelas quais JavaScript pode ser a próxima grande linguagem at Superfície Reflexiva.

meta