Os Iluminados, os Cépticos e a Morte do Flash

Algures a meio de 2008 tive a seguinte troca de comentários:

PauloQuerido : @mvalente tenho feito tudo em js+css: http://tinyurl.com/6b7pbz

mvalente : @PauloQuerido Nao discuto :)… Em 5 anos o Flash vai estar no mm “nicho” em q estao as Java applets (ie. +- nulo)

mvalente : Ajax Animator is nice http://antimatter15.110mb.c… It does Flash but also Processing.js+canvas. 5 years? Make it 2…

Em suma: previa que o Flash estivesse morto daí a 5 anos (2013) e depois ajustei a previsão para 2 anos (2010)

Nos 2 anos entretanto passados, não tenho perdido a oportunidade de reforçar essa opinião cada vez que apareceram novos exemplos do uso de standars como o Javascript, HTML5, CSS, SVG, etc.

Também nos 2 anos entretanto passados, não faltaram “iluminados” e cépticos a discordar, com comentários tipo “o flash vai ter sempre o seu lugar”, “not the decline of Flash as jack of all trades”, “flash has its audience and its utility”, etc, etc.

E ainda nos mesmos 2 anos, também vi muitos cépticos e “iluminados” a virarem a casaca e passarem a ser arautos das boas novas. Os maiores fanáticos são sempre os recém convertidos…

Chegamos assim a 2010. O Flash está morto? Não. Mas pelos vistos vai bem encaminhado para estar em 2013:

GwtQuake: Taking the Web to the Next Level

A verificar-se a validade deste resultado (ainda não tive oportunidade de testar, mas tudo indica que sim, dadas as várias confirmações existentes) muita gente vai ficar caladinha a assobiar para o lado, a ver se passa despercebida. Só que eu sou um arrogante e não vou perder a oportunidade de dizer “I told you so”.

Esperei de ontem até hoje para escrever sobre o assunto mas, caso isto seja mesmo uma brincadeira de 1 de Abril, é inevitável que passe a realidade mais cedo ou mais tarde. Mantenho a previsão de que o Flash vai morrer: até 2013 ainda tenho tempo para ter razão.

EDIT: “Então e o o facto de o Google Chrome passar a incorporar o Flash?”. Amigos, isso é o que se chama um reverse takeover: o Chrome garante a compatibilidade com o Flash sem ser preciso fazer o download de plugins; e assim pode esperar que os sites passem a usar o HTML5 e  quejandos; e se calhar no entretanto substitui a VM do Flash pela  VM Javascript, com render do Flash directo para Canvas. Esse, aliás, é a provavel salvação do Flash: ser um conjunto de ferramentas que permite desenvolver aplicações tendo como target JS+Canvas+SVG; na realidade o Flash não é muito mais do que isso (o ActionScript não é mais do que uma versão de Javascript)

22 comments

  1. Engraçado engraçado é uma boa parte do código fonte começar por ser… er… Java!

    =;o)

    • Não fazia mto sentido reescrever o Quake em JS de raiz. Pegar no Q2 escrito em Java e “compilar” para Javascript usando o GWT não invalida o facto de que na altura da execução se trata de JS.

      — MV

      • Pois… um engenho de Javascript moderno, com bytecodes, JIT compiler e todas aquelas lindas optimizações…

        Enfim, quando leio sobre estas técnicas avançadas utilizadas pelos engenhos de Javascript modernos (V8, TraceMonkey, SquirrelFish, Carakan, Chakra) mais me lembro de artigos similares sobre as optimizações deitas à boa e velha JVM (Java Virtual Machine).

        Pois, parece que o Javascript está mesmo a aprender alguma coisa com o Java.

        E não faz senão bem, se considerarmos certas medições de performance:
        http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=all

        • >Pois… um engenho de Javascript moderno, com bytecodes, JIT >compiler e todas aquelas lindas optimizações…
          >

          Mas tinha de ser um engine antigo? É proibido? Essas técnicas são pertença de alguma linguagem em particular?

          >Enfim, quando leio sobre estas técnicas avançadas utilizadas pelos >engenhos de Javascript modernos (V8, TraceMonkey, >SquirrelFish, Carakan, Chakra) mais me lembro de artigos >similares sobre as optimizações deitas à boa e velha JVM (Java >Virtual Machine).
          >

          E? … O facto de terem sido usadas no caso da JVM impede que sejam usadas por qq outro interpretador/engine ?

          >Pois, parece que o Javascript está mesmo a aprender alguma coisa >com o Java.

          E?… Se aprender e ficar melhor do que o Java? Isso faz com o Java seja “bom”?

          >E não faz senão bem, se considerarmos certas medições de >performance:
          >

          Se calhar o Java tb podia aprender algumas coisas com o Javascript. Veja-se o benchmark onde o JVM/Rhino perde para
          o Node.js em toda a linha:

          http://four.livejournal.com/1019177.html#cutid1

          Ou outro em que o Javascript chega a ter performances perto das de C compilado:

          http://andreasgal.wordpress.com/2008/08/22/tracing-the-web/

          “Our JIT generates code that is roughly equivalent to the performance of unoptimized C code (gcc -O0)”

          — MV

          • > … É proibido? Essas técnicas são pertença de alguma linguagem em particular?

            Claro que nao!

            > E? … O facto de terem sido usadas no caso da JVM impede que sejam usadas por qq outro interpretador/engine ?

            Claro que não!

            Eu até disse:
            >>E não faz senão bem, se considerarmos certas medições de performance…

            > E?… Se aprender e ficar melhor do que o Java? Isso faz com o Java seja “bom”?

            Mas queres então dizer que o Javascript anda a imitar características más do Java?

            Pelo menos há que admitir que o Java tem características boas.

            Nota que eu gosto de Javascript – é das linguagens de scripting de desenho mais simples e elegante – e mais poderosas – que já encontrei.

            Não percebo é a tua embirração com o Java.

            E isto já vem de há algum temp, como quando um dia disseste na mesma apresentação que:

            – O Java tinha uma performance inaceitável;

            – Que um exemplo de VM Javascript era o Firefox.

            …e isto passou-se no Codebits 2008, antes do TraceMonkey, quando a performance do Firefox…

            Ainda estou a tentar perceber, daí as minhas comparações.

            > Se calhar o Java tb podia aprender algumas coisas com o Javascript.
            > Veja-se o benchmark onde o JVM/Rhino perde para o Node.js em toda a linha:

            Isso tem a ver com o que se faz com o Java e não com o Java ou a JVM em si. O Rhino é um interpretador velho e obsoleto. Seria mais justa comparar o Node.js com um engenho de script como o do Pnuts (mas este não é Javascript) que é um dos poucos interpretadores bem feitos em Java:
            https://pnuts.dev.java.net/

            Infelizmente o Pnuts não pegou e está abandonado, mas esse sim usava o tipo de técnicas que permitia a comparação co mos engenhos de Javascript modernos, ao compilar (mesmo em runtime) o código Pnuts para Java bytecode.

            O Pnuts, no início do século, estava muito à frente do seu tempo. Só agora outras linguagens para JVM começam a fazer o mesmo.

            Mas não se pode dizer que essas estejam muito mais atrasadas que os engenhos de Javascript que só agora despertaram para a possibilidade de se tornarem rápidos a sério.

            > — “Our JIT generates code that is roughly equivalent to the performance of unoptimized C code (gcc -O0)”

            Pois, esse artigo é sobre o TraceMonkey, mas olha onde aparece o TraceMonkey (ou o V8) nesta listinha quando comparado com o Java e o gcc:
            http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=all

          • >Mas queres então dizer que o Javascript anda a imitar características más do Java?
            >Pelo menos há que admitir que o Java tem características boas.

            Claro.

            >Não percebo é a tua embirração com o Java.

            Memory footprint; duzentos ficheiros de configuração; static typing; parametros
            de metodos em numero e posicao fixa; obrigatoriedade de setters e getters….etc

            >E isto já vem de há algum temp, como quando um dia disseste na mesma apresentação que:
            >
            >- O Java tinha uma performance inaceitável;
            >

            E tem.

            >- Que um exemplo de VM Javascript era o Firefox.
            >

            Certo.

            >…e isto passou-se no Codebits 2008, antes do TraceMonkey, quando a performance do Firefox…
            >

            No Codebits 2008 o Tracemonkey já estava na latest version developers.

            >> Se calhar o Java tb podia aprender algumas coisas com o Javascript.
            >> Veja-se o benchmark onde o JVM/Rhino perde para o Node.js em toda a linha:

            >Isso tem a ver com o que se faz com o Java e não com o Java ou a JVM em si. O Rhino é um interpretador velho e >obsoleto. Seria mais justa comparar o Node.js com um engenho de script como o do Pnuts (mas este não é Javascript) que >é um dos poucos interpretadores bem feitos em Java:
            >

            O benchmark não me dá jeito e portanto o Rhino é velho e
            a comparação é injusta. Essa já é velha.

            >Mas não se pode dizer que essas estejam muito mais atrasadas que os engenhos de Javascript que só agora despertaram >para a possibilidade de se tornarem rápidos a sério.

            Isso não faz do Java “uma coisa boa”

            >> — “Our JIT generates code that is roughly equivalent to the performance of unoptimized C code (gcc -O0)”
            >
            >Pois, esse artigo é sobre o TraceMonkey, mas olha onde aparece o TraceMonkey (ou o V8) nesta listinha quando >comparado com o Java e o gcc:
            >http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=all
            >

            Mais uma vez: esse benchmark dá-te jeito; o que eu referi dá-me jeito a mim.
            Ou seja: qualquer pode arranjar benchmarks para provar o que quer.

            O importante é isto: o Java é complicado de entender; o Javascript é mais
            fácil e tem uma base instalade MUITO maior do q o Java; o Javascript vai
            ganhar, eventualmente.

            — MV

          • Porque dizes que o JavaScript “tem uma base instalada MUITO maior do que o Java”?
            É verdade que o Java desceu um pouco, mas mesmo assim ainda continua muito à frente do JavaScript: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html.

          • >Porque dizes que o JavaScript “tem uma base instalada MUITO maior >do que o Java”?
            >É verdade que o Java desceu um pouco, mas mesmo assim ainda >continua muito à frente do JavaScript:
            >

            O C, C++, PHP, VB, C#, Python, Perl e Delfi tem VM no browser? Não.
            O Java tem, mas pouca gente o usa e cada vez menos é usado.

            O mesmo raciocinio: algum dos atrás (tirando Java) tem engine em cima de telemoveis? Nao.

            O Javascript tem uma base instalada muito maior q todas as outras linguagens: tem uma
            VM instalada em todos os browsers. QED.

            — MV

          • > Memory footprint; duzentos ficheiros de configuração; static typing; parametros de metodos em numero e posicao fixa; obrigatoriedade de setters e getters….etc

            Os duzentos ficheiros de configuração têm a ver com “o que é que alguns fazem com o Java”, o Firefox tb. tem um belo Memory Footprint, os stters e getters não são propriamente obrigatórios (depende…) mas tb. embirro com eles, e tb. gostava de ter outras possibilidades em termos de parâmetros.

            > No Codebits 2008 o Tracemonkey já estava na latest version developers.

            My bad. A verdade é que eu não sabia e não fui ver. =:o/

            > O benchmark não me dá jeito e portanto o Rhino é velho e a comparação é injusta. Essa já é velha.

            E esta: tu na verdade estavas a comparar laranjas com maçãs (e eu caí na coisa) pois na verdade estavas é a compara a performance do C++ (se essa é a linguagem de implementação do Node.js) com o Java (linguagem de implementação do Rhino) como implementação de uma VM de Javascript, e NÃO o Javascript com o Java.

            …e o Rhino continua a ser obsoleto e os engenho de Javascript de que estamos a falar não.

            >>http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=all
            >
            >Mais uma vez: esse benchmark dá-te jeito; o que eu referi dá-me jeito a mim.
            >Ou seja: qualquer pode arranjar benchmarks para provar o que quer.

            Este benchmark, pelo menos, compara laranjas com laranjas.

            > O importante é isto: o Java é complicado de entender; o Javascript é mais
            > fácil e tem uma base instalade MUITO maior do q o Java; o Javascript vai
            > ganhar, eventualmente.

            O Javascript tem um desenho simples e é poderoso… mas não estou certo que a partir de um certo nível de complexidade seja mais simples de entender ou melhor que o Java em muitos outros aspectos.

            Acho que cada um tem o seu lugar, em termos do tipo de problema.

            Não estou a falar em termos de cliente vs. servidor, já que em 2001/2002 já eu andava a tentar meter Javascript no servidor, pela mesma lógica de haver na companhia em que trabalhava malta que já sabia javascript…

            …e, pois, com o Rhino. E só desisti do Rhino e passei ao Pnuts por causa de o Rhino ser uma besta complicada e na altura não haver grandes alternativas.

            Have fun,
            PJG

          • >> O benchmark não me dá jeito e portanto o Rhino é velho e a comparação é injusta. Essa já é velha.

            >E esta: tu na verdade estavas a comparar laranjas com maçãs (e eu caí na coisa) pois na verdade estavas é >a compara a performance do C++ (se essa é a linguagem de implementação do Node.js) com o Java >(linguagem de implementação do Rhino) como implementação de uma VM de Javascript, e NÃO o >Javascript com o Java.
            >

            A linguagem de programação da JVM tb é C/C++. E o Rhino não é o Javascript escrito em
            Java, é um compilador de JS (escrito em Java) que tem como target a JVM.
            Portanto a comparação é perfeitamente razoavel: JS compilado para o target JVM (feito
            em C/C++) e JS compilado para o V8/NodeJS (feito em C/C++).

            >…e o Rhino continua a ser obsoleto e os engenho de Javascript de que estamos a falar não.
            >

            Oh oh oh: http://www.mozilla.org/rhino/download.html

            — MV

          • > A linguagem de programação da JVM tb é C/C++. E o Rhino não é o Javascript escrito em
            > Java, é um compilador de JS (escrito em Java) que tem como target a JVM.
            > Portanto a comparação é perfeitamente razoavel: JS compilado para o target JVM (feito
            > em C/C++) e JS compilado para o V8/NodeJS (feito em C/C++).

            Continua a ser uma camada a mais.

            O V8 compila directamente o Javascript para “machine code”:
            http://code.google.com/apis/v8/design.html#mach_code

            >>…e o Rhino continua a ser obsoleto e os engenho de Javascript de que estamos a falar não.
            >>
            >
            > Oh oh oh: http://www.mozilla.org/rhino/download.html

            Ve as release notes e verificarás que não existe aí nenhuma revolução em curso.

            PJG

  2. o que será da web “indústria” da Pornografia e afins.. sem o Flash?

    :)
    :P

    Cumprimentos,
    Ricardo Martins

  3. Não esquecer que o flash está onde está também por causa de atitudes com a Apple que apesar dos riscos nunca aceitou inserir flash no iPhone e agora no iPad. Parece q a MS vai plo mesmo caminho com o seu novo tlm mas concerteza se não houvesse já o iPhone sem flash MS não arriscaria.

    Mas claro que é uma questão complexa que vai pra lá da tecnologia e mexe muito com a questão dos monopólios

    Não, não sou um Apple fanboy :p e uso Linux no dia a dia quando posso.

  4. O ActionScript não é uma versão de JavaScript! Mas ambos são baseados no ECMAScript.
    Quanto ao render do Flash directo para Canvas, já vai ser possível com o CS5: http://www.9to5mac.com/Flash-html5-canvas-35409730.

    • >O ActionScript não é uma versão de JavaScript! Mas ambos são >baseados no ECMAScript.
      >

      E a diferença é?… O quê?
      São quase a mesma coisa, são versões da mesma coisa.

      >Quanto ao render do Flash directo para Canvas, já vai ser
      >possível com o CS5
      >

      Ahmm… Não sei se reparaste mas esse link era precisamente o que eu referia como vindo provar a minha conjectura.

      — MV

      • JavaSctipt e ECMAScript são coisas diferentes. O ECMAScript é a especificação/standard e o JavaScript é uma implementação, assim como o é o ActionScript.

        Em relação ao link, peço desculpa, mas não reparei nele. Há um link que está encurtado, será esse?

  5. Pormenores técnicos à parte.
    Também acho que o Flash irá perder para o HTML5, mas não desaparecer.

    E é aqui que tenho uma opinião diferente da tua.
    Acho que o Flash vai continuar a existir e a ter lugar enquanto não houver ferramentas de desenvolvimento igualmente boas para fazer animações em JavaScript como existem actualmente para o Flash. E este é, sem dúvida, o ponto mais importante para o Flash continuar a ter adeptos.

    • Pois… enquanto isso não acontecer (ferramentas de desenvolvimento) o Flash bem nos pode queimar CPU impunemente à vontade.

      • As ferramentas já existem: o CS5 vai compilar directo para HTML5+JS+Canvas.

        Foi a isso que comecei por me referir, não sei se leram…

        — MV

        • Sim, tenho visto muitas referências a essa técnica futura, mas enquanto não vir a implementação…

          Há que ter em conta que a Adobe tem lixado muito uma ideia bastante razoável (que o Flash na era pré-canvas foi) na altura da implementação.

          Claro que se a implementação for boa, talvez o Flash nem dure até 2013…
          =;o)

        • Sim, ambos sabemos que o CS5 vai compilar directo para Canvas.
          Mas temos que admitir que isso ainda não é solução.
          Não que seja má, mas sim pelo seu suporte. Ainda continua a existir aquele nosso amigo browser que continua a dar dor de cabeça…
          E pior ainda quando desenvolves para o mobile. Aí claramente o Canvas ainda não é uma opção…