Banner anúncio do Revelo UP, com o logo do programa e o texto 'Financiamento de curso em tecnologia' à esquerda, a frase 'Investir no seu futuro começa agora' no meio e, à direita, a palavra 'UP' vazada, com uma mulher pensativa no 'U' e um homem fazendo anotações no 'P'.

Torne o Chrome rápido

Alguns leitores me indicaram o Mighty, um novo navegador que promete ser um “Chrome mais rápido” e que “usa 10 vezes menos memória” que o Chrome (ou 10%, certo?).

Como? Fazendo streaming da web. É um pouco difícil de entender porque a ideia parece errada, mas é isso mesmo: um navegador que se conecta a outro navegador em servidores potentes (na nuvem), que são bem mais rápidos que o seu computador, como se fosse uma Netflix, só que para acessar o Facebook ou seu extrato bancário. Se pareceu-lhe uma ideia estúpida, calma que piora: é pago. O preço ainda não está definido, mas o formulário para solicitar acesso ao serviço fala em até US$ 50 por mês.

Coisas como esse Mighty só viram realidade porque a web foi desfigurada e, hoje, acessar o Facebook ou qualquer site “moderno”, eufemismo para sites pesados, exige computadores super potentes. Eu poderia apostar uns trocados que existem maneiras melhores de atacar esse problema do que fazendo streaming de navegador.

Deixe uma resposta

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

20 comentários

  1. Concordo que a ideia parece absurda pelo fato de “streamar” um site que qualquer computador deveria ser capaz de abrir. Mas Ghedin, você parece levantar a ideia de isso ser inseguro (o que pode ser apenas impressão minha), o que não seria diferente de, por exemplo, uma VPN ou até um aplicativo de mensagem que diz que não tem acesso aos seus dados. Estou errado?

    1. Uma VPN deve sempre ser encarada, a princípio, como insegura. O maior trabalho de uma empresa que oferece esse serviço é mitigar desconfianças, por isso elas precisam de uma política de privacidade robusta, auditorias externas e regulares e outros compromissos e atitudes.

      E há uma diferença fundamental para o Mighty: as aplicações web e sites estariam rodando lá, e não no meu computador, ou seja, o Mighty é uma das “pontas” da comunicação. Tudo que é novo causa certa desconfiança, acho natural isso, e ainda mais com uma proposta tão… ahn… “sui generis”. Eles que lutem para nos convencer do contrário.

  2. Cara, a grande maioria é o próprio dev que traz esse problema. Lançaram um framework/lib novo, la no Spotify, Google, Nubank… estão usando, partiu implementar aqui. É o que eu vejo hoje em dia.

    No final, hoje o mundo do desenvolvimento vive do “hype” de alguma ferramenta (seja de código ou de gestão)

    1. Na verdade não é o próprio dev e sim as empresas que exigem desenvolvimento de sites e aplicativos o mais rápido possível. Ex: Um desenvolvedor pode fazer um site e aplicativo para IOS e Android usando uma só linguagem (JavaScript) e até a mesma base de código, o que antes só era possível usando tres linguagens diferentes: JavaScript, Java para Android e Swift para IOS. Por outro lado, os apps são praticamentes “emulados” nas plataformas, fazendo com que apps simples ficam pesados e grandes por não usar a linguagem de programação nativa.

      1. Então o mais rápido possível é enfiar frameworks/libs? Ñ quero generalizar, mas culpar só as empresas é tentar defender que um desenvolvedor ñ tem a “liberdade” de entregar o resultado final que a empresa espera. Seja com framework, sem, etc…

        Se quando a populariedade de libs/frameworks começaram aflorar no mundo de desenvolvimento, tinhamos desenvolvedores sabendo o framework sem nem entender do que era feito, hoje percebo que essa “moda” de todo mundo ser programador tá trazendo profissionais que ñ sabem o básico.

        1. Fui programador por 11 anos e nunca tive liberdade pra usar nenhum framework ou linguagem em produção. Essas tecnologias sempre eram legadas ou escolhidas pela parte de arquitetura/projeto. Eu era só um peão (e programador é exatamente isso, um peão que constrói coisas) que executava.

          Eu só tive alguma liberdade quando eu iniciei um projeto de PLN. E eu tenho certeza que essa liberdade só ocorreu porque eu era o único que sabia fazer isso na equipe (e uma das 3 pessoas que sabia fazer isso na empresa inteira).

  3. O Opera para celular fazia isto até uns anos atráz. Chegou a levar para o desktop também, antes de migrar para o Chromium.

  4. É um absurdo completo o quanto de scripts de monitoramento/propaganda são executados em qualquer site, mas não me parece ser a proposta usar esse serviço para acessar redes sociais em casa

    A ideia deve ser mais para que usa webapps pesados no dia-a-dia, como VS Code ou Google Drive. Não é tanto meu caso, mas em startup, basicamente todas as ferramentas são uma aba no navegador (Slack, Notion, Drive, Jira, Asana, etc…)

    São aplicações complexas em si, mesmo que possam ser otimizadas, não tem como comparar com o Facebook.

    1. Sim, o foco parece ser mais em empresas, mas não deixa de ser meio absurdo — se não pela ideia em si, pelo fato de terem transformado a web em plataforma para aplicações profissionais pesadas que, feitas de outra forma, rodariam bem em computadores comuns. Essa ideia é tipo aquele meme do cara colocando um band-aid na rachadura de um galão enorme de água 😄

      1. É inegável que tudo seria melhor nativo, mas não é uma solução razoável para 99% das aplicações comum. Um Slack, não imagino menos que 10X mais de complexidade para manter solução nativa para mobile (iOS/Android), desktop (Windows/MacOS) e web. Se mal executado, que é bem provável, pode ficar até pior.

        Sei que a maioria vira os olhos: mas não importa os bilhões que as empresas têm, “débito técnico” não se resolve com dinheiro nenhum no mundo. Precisa orquestrar mais gente, mudanças demoram muito mais e não existe mão de obra qualificada (e disposta). Não é incompetência (somente) que empresas Fortune 500 usam COBOL e a Microsoft não consegue arrumar o painel de controle do Windows.

        Só a Apple consegue manter um ecossistema nativo forte, mas só funciona porque é uma boutique, devs são submetidos a regras tirânicas e deve dominar o “1% mais rico” dos usuários. Só ela pode quebrar APIs e compatibilidade, barrar aplicações, etc. Todo esse trabalho é financiado pelos usuários ricos que ela monopoliza, possibilitam um Tweetbot por exemplo, porque pagam pela melhor experiência.

        Algumas coisas se justificam, mas acho que a solução passa muito mais por melhorar o multi-plataforma que ser nativo. Nunca gostei de IDEs multi-plataforma, mas o VS Code é rápido o suficiente para mim, dado os enormes benefícios.

        1. Concordo com tudo. Só me pergunto, no final, se o desenvolvimento é algo binário, ou seja, bom e nativo ou zoado e web/multiplataforma. Hoje deveria ser possível construir aplicações web multiplataforma que não exijam (literalmente) servidores na nuvem para rodarem sem engasgar os computadores e notebooks extremamente rápidos que temos em casa e nas empresas, não?

          1. É tão sofrível a experiência assim, para o usuário padrão? Não acho que rodar no servidor seja necessário para 1% dos usuários.

            Eu entendo que tem casos desnecessários de apps Electron e outros que são simplesmente ruins, o Teams é horrível aqui, mesmo para mandar/receber mensagens de texto pura. O VS Code é ótimo, como eu disse, da mesma empresa e usando mesma tecnologia.

            Acho que a performance é um problema de uma de uma minoria vocal, misturado com uma expectativa “injusta”, de achar razoável ter mais de 10 abas abertas com webapps. Se fossem 10 programas abertos na barra de tarefas, não reclamaria porque não é “só um browser”.

            Fora que determinados usos são mais extremos: Excel pessoal é um coisa, mas na empresa faz vezes de sistema e dashboard corporativo. Na minha área, tem até problema de otimização feito em planilha, que é algo inerentemente pesado em processamento. Uma cloud para rodar seria uma baita ajuda.

            Em resumo, acho que poderia ser melhor, mas é aceitável e tem evoluído (WebAssembly, o V8 é bem rápido, etc…) esse uso como plataforma de software. O problema que vejo são sites de conteúdo pesados, por causa de trackers e frameworks, que talvez seja sintoma de um modelo de negócios quebrado.

          2. Eu não sou parâmetro para isso, mas acho os serviços do Google bem pesados. O Google Docs e o YouTube são muito lentos — até já comentei aqui num post. E nos últimos meses da minha finada conta do Facebook, ficava espantado em como as interfaces web, tanto a antiga quanto a (na época) nova, eram pesadas.

            Mas… né, é a vida. Esse tipo de “evolução” não depende muito de nós, no que quero dizer que se a maioria adotar, é pouco provável que daqui a alguns anos seja possível escapar do uso de algo assim.

          3. Até hoje acho bizarro como uma aba do Google Planilhas é mais pesada que uma planilha do MS Excel.

            As justificativas podem existir e serem válidas. Mas do ponto de vista do usuário, leigo na maioria dos casos, é irrelevante, sabe.

            Outro exemplo é uma aba do Gmail mais pesada que um app de e-mail.

        2. Eu já ouvi dizer que o grande problema da lentidão dos webapps é que a maioria usa AWS e a Amazon mantém rotas problemáticas que exigem um tempo de resposta muito alto e “pendura” a aba do browser por muito tempo (isso seria um problema de DevOps, provavelmente) esperando a resposta que bate-e-volta em diversos nós.

          Aliás, quando eu comecei em 2006 na Tlantic a gente tinha os servidores dos PDV’s todos locais (aqui no Brasil e em Portugal) tanto pra teste, homologação e produção e eles rodavam bem rápido em computadores muito piores do que os de hoje. Principalmente o que se chamava de “retaguarda” (escrito em PHP) desses pontos. Hoje em dia é tudo AWS ou Azure =/

      2. Uma detalhe que você está esquecendo é o custo do desenvolvimento de aplicaçãoes nativas. Na web você tem uma aplicação só, seja macos, linux, windows, android ou o que for. Se fizer nativo (que tende a ser mais rápido (se bem feito)) você vai ter que ter várias equipes que conhecem de n tecnologias diferentes dando suporte e mantendo em dia que a evuloção da plataforma. Não é viavel.
        E ainda bem que a web foi “desfigurada”, como você diz, senão estariamos até hoje no geocities com sites toscos.

        1. E ainda bem que a web foi “desfigurada”, como você diz, senão estariamos até hoje no geocities com sites toscos.

          Isso seria um sonho! 😍 (Ok, estou brincando, mas acho que a web acabou virando o mínimo denominador comum e, com isso, repositório de muito software mal feito e preguiçoso que poderia ser muito melhor, mesmo feito rodando em navegadores.)

  5. Um dos problemas da web moderna, e veja bem, posso estar falando m*rda, são os frameworks pesados, mal otimizados, e usados em sites feito às pressas. Não culpo os devs, porque na maioria das vezes é pressão de gerente de projetos. “Temos que usar o que há de mais novo no mercado, e o tempo de implementação é curto”.

    1. Concordo. Quando sai um framework novo, corre todo mundo pra usar, sem dar para amadurecimento tanto do framework quanto dos devs. Lembro muito bem quando surgiu o Angular.js e todo mundo ficou maravilhado e correu pra usar. Pouco tempo depois a própria equipe percebeu o monstro que tinha criado e optou por desenvolver o Angular 2 do zero.

O site recebe uma comissão quando você clica nos links abaixo antes de fazer suas compras. Você não paga nada a mais por isso.

Nossas indicações literárias »

Do NOT follow this link or you will be banned from the site!