Tudo é ótimo, mas se você usar isso, não conseguirá controlar o WireGuard no sistema. Se quiser usá-lo separadamente do túnel, vai precisar dividir o uso em uma VM.
Mesmo que seja uma web parecida com um app, acho que devemos buscar algo próximo do que foi concluído no texto. Se usar muito JavaScript, do ponto de vista do cliente a coisa fica pesada.
Na prática, também não é como se não existissem frameworks capazes de implementar isso. O próprio Next.js já permite algo mais ou menos nessa linha se você minimizar o uso de componentes de cliente e só os usar quando necessário, e, no ecossistema Rails que outra pessoa mencionou, o Hotwire (https://hotwired.dev/) oferece um conjunto de frameworks que dá suporte a uma web com cara de app para chegar bem perto da conclusão mencionada pelo autor (Turbo, Stimulus etc.).
Por causa da tentativa de aquisição pela OpenAI, a Claude parou de oferecer licenças para a versão mais recente, então para usar os modelos Claude 4.x no Windsurf é preciso comprar a API diretamente, o que sai caro. Será que a Claude vai voltar?
Ao contrário da cultura de desenvolvimento na Coreia, em que o trabalho desce da gestão para o planejador e depois para o desenvolvedor, no Ocidente não existe esse mesmo conceito de planejador como na Coreia, e há casos em que os desenvolvedores participam ativamente do planejamento de produto e afins. PMs no Ocidente, por exemplo, não correspondem perfeitamente ao planejador coreano, assim como cover letters e cartas de apresentação não são conceitos totalmente idênticos. Claro, no caso dos jogos, que têm um caráter mais fortemente criativo e em que diversão e jogabilidade são importantes, o Ocidente também é mais horizontal do que a Ásia, mas ainda assim o trabalho desce do diretor para o desenvolvedor.
É assustador demais.
Que registros maliciosamente manipulados possam derrotar a memória e a experiência, tornar-se prova
e acabar sendo usados para nos ameaçar.
Os navegadores que as pessoas usam nem são tantos assim, então por que existem tantos frameworks? Não seria melhor as empresas que gerenciam os navegadores criarem um framework ideal e o manterem junto? Até quando vamos repetir esse ciclo vicioso?
Concordo com o diagnóstico do fenômeno, mas não com a conclusão.
A causa superficial do fenômeno, como o próprio texto menciona, é o aumento da demanda por uma “web parecida com app”,
e acho que, tanto agora quanto naquela época, a web nunca foi realmente adequada para criar “algo com cara de app”, embora, com muito improviso, desse para “fazer algo parecido”.
Na verdade, a própria origem da web está em ser uma plataforma criada para compartilhar uma espécie de “documento”, como artigos acadêmicos.
Basta olhar para os elementos básicos do HTML.
Depois surgiram tecnologias capazes de gerar conteúdo dinâmico, como CGI, e, com a incorporação de linguagens de script no lado do navegador, passou a ser possível dar dinamismo ao resultado, iniciando o afastamento da “web como documento”.
O problema é que, desde esse primeiro afastamento até hoje, a base da web continua sendo um sistema fundamentado em “documentos”.
Claro, surgiram muitas tecnologias novas que fogem dessa orientação de “documento”, como WebSocket, WebRTC e WASM, mas, até hoje, a maioria dos sites ainda é desenvolvida dependendo da plataforma tradicional baseada em “documentos”.
Ainda precisamos empilhar tags div para desenhar a tela.
Até aqui é a análise do fenômeno, e isso leva à pergunta: então qual seria a resposta?
Se eu imaginar as características ideais da próxima plataforma, sem pensar nem um pouco na viabilidade prática, seria algo assim.
(Não estou dizendo que todo site deveria ser assim, e sim apenas os sites com natureza mais próxima de aplicação.)
Antes de tudo, o navegador se tornaria uma espécie de launcher de apps.
Depois de baixado uma vez, ele deveria poder ser executado também offline.
E o app seria implementado em outras linguagens, saindo do modelo atual de HTML/CSS/JS.
Nesse processo, talvez o navegador pudesse fornecer uma espécie de framework, como no Android.
A forma de comunicação com o servidor também poderia sair do modelo tradicional de requisições web e adotar outro paradigma.
No caso de comunicação que exige tempo real, talvez fosse possível usar a comunicação TCP como ela é hoje,
e também daria para criar e usar uma comunicação RPC mais simples, que não utilizasse o protocolo HTTP.
Há um mês, usando o CURSOR para aprender o que era programação com IA, comecei a desenvolver um framework de desenvolvimento.
Por cerca de 3 semanas, repeti o ciclo de sucesso seguido pela quebra do código-fonte que havia sido validado por um AI Agent, e tentei de todas as formas controlar o AI Agent, mas falhei.
Então percebi que, antes de desenvolver o framework, a prioridade era desenvolver o código-fonte para controlar o AI Agent.
No fim, exatamente 1 mês depois de começar tentando entender o que era a IA, alcancei o resultado de concluir o desenvolvimento de um software 100% implementável e 100% operável por IA, com controle completo sobre o AI Agent (mais precisamente, sem necessidade de LLM externo nem de AI Agent).
Agora, há 14 dias, estou conduzindo o processo de criar e fazer cumprir regras operacionais enquanto dou treinamento adicional a essa META AI para um refinamento extra, e ao mesmo tempo estou migrando, melhorando e padronizando três sistemas MES que antes haviam sido feitos de forma incompleta por pessoas, já entrando na fase final.
E agora estou me preparando para mais uma evolução.
As opiniões sobre "tedioso" estão divertidas haha. Se fosse para trocar por outra palavra, qual seria melhor? Batido, comum?
Não é uma história completamente diferente daquilo que você está dizendo?
Não entendo muito bem o que você quis dizer na última parte, sobre ser uma plataforma ideal.
No fim das contas, estamos falando da época em que se baixava um programa nativo e se usava ActiveX nele.
Traduzir
boringcomo “tedioso” realmente não transmite bem o sentido original.Boringnessé uma das filosofias de design do Go.Vai cair nessa de novo~
Não parece tão fácil de usar com praticidade de um clique.
Grok 4 agora é o modelo de IA líder
Review do Grok 4 por Simon Willison
O Grok pesquisa o que Elon Musk diz no X sobre a questão Israel-Palestina
Tudo é ótimo, mas se você usar isso, não conseguirá controlar o WireGuard no sistema. Se quiser usá-lo separadamente do túnel, vai precisar dividir o uso em uma VM.
Mesmo que seja uma web parecida com um app, acho que devemos buscar algo próximo do que foi concluído no texto. Se usar muito JavaScript, do ponto de vista do cliente a coisa fica pesada.
Na prática, também não é como se não existissem frameworks capazes de implementar isso. O próprio Next.js já permite algo mais ou menos nessa linha se você minimizar o uso de componentes de cliente e só os usar quando necessário, e, no ecossistema Rails que outra pessoa mencionou, o Hotwire (https://hotwired.dev/) oferece um conjunto de frameworks que dá suporte a uma web com cara de app para chegar bem perto da conclusão mencionada pelo autor (Turbo, Stimulus etc.).
Por causa da tentativa de aquisição pela OpenAI, a Claude parou de oferecer licenças para a versão mais recente, então para usar os modelos Claude 4.x no Windsurf é preciso comprar a API diretamente, o que sai caro. Será que a Claude vai voltar?
Ao contrário da cultura de desenvolvimento na Coreia, em que o trabalho desce da gestão para o planejador e depois para o desenvolvedor, no Ocidente não existe esse mesmo conceito de planejador como na Coreia, e há casos em que os desenvolvedores participam ativamente do planejamento de produto e afins. PMs no Ocidente, por exemplo, não correspondem perfeitamente ao planejador coreano, assim como cover letters e cartas de apresentação não são conceitos totalmente idênticos. Claro, no caso dos jogos, que têm um caráter mais fortemente criativo e em que diversão e jogabilidade são importantes, o Ocidente também é mais horizontal do que a Ásia, mas ainda assim o trabalho desce do diretor para o desenvolvedor.
As filosofias de desenvolvimento buscadas variam demais.........
Como era de se esperar, até a IA não é imparcial.
É assustador demais.
Que registros maliciosamente manipulados possam derrotar a memória e a experiência, tornar-se prova
e acabar sendo usados para nos ameaçar.
Os navegadores que as pessoas usam nem são tantos assim, então por que existem tantos frameworks? Não seria melhor as empresas que gerenciam os navegadores criarem um framework ideal e o manterem junto? Até quando vamos repetir esse ciclo vicioso?
Fico curioso para saber por que deu errado.
A forma definitiva de IA que bajula o usuário era, no fim das contas, a IA que bajula o chefão...
Concordo com o diagnóstico do fenômeno, mas não com a conclusão.
A causa superficial do fenômeno, como o próprio texto menciona, é o aumento da demanda por uma “web parecida com app”,
e acho que, tanto agora quanto naquela época, a web nunca foi realmente adequada para criar “algo com cara de app”, embora, com muito improviso, desse para “fazer algo parecido”.
Na verdade, a própria origem da web está em ser uma plataforma criada para compartilhar uma espécie de “documento”, como artigos acadêmicos.
Basta olhar para os elementos básicos do HTML.
Depois surgiram tecnologias capazes de gerar conteúdo dinâmico, como CGI, e, com a incorporação de linguagens de script no lado do navegador, passou a ser possível dar dinamismo ao resultado, iniciando o afastamento da “web como documento”.
O problema é que, desde esse primeiro afastamento até hoje, a base da web continua sendo um sistema fundamentado em “documentos”.
Claro, surgiram muitas tecnologias novas que fogem dessa orientação de “documento”, como WebSocket, WebRTC e WASM, mas, até hoje, a maioria dos sites ainda é desenvolvida dependendo da plataforma tradicional baseada em “documentos”.
Ainda precisamos empilhar tags
divpara desenhar a tela.Até aqui é a análise do fenômeno, e isso leva à pergunta: então qual seria a resposta?
Se eu imaginar as características ideais da próxima plataforma, sem pensar nem um pouco na viabilidade prática, seria algo assim.
(Não estou dizendo que todo site deveria ser assim, e sim apenas os sites com natureza mais próxima de aplicação.)
Antes de tudo, o navegador se tornaria uma espécie de launcher de apps.
Depois de baixado uma vez, ele deveria poder ser executado também offline.
E o app seria implementado em outras linguagens, saindo do modelo atual de HTML/CSS/JS.
Nesse processo, talvez o navegador pudesse fornecer uma espécie de framework, como no Android.
A forma de comunicação com o servidor também poderia sair do modelo tradicional de requisições web e adotar outro paradigma.
No caso de comunicação que exige tempo real, talvez fosse possível usar a comunicação TCP como ela é hoje,
e também daria para criar e usar uma comunicação RPC mais simples, que não utilizasse o protocolo HTTP.
Nossa, parece que o futuro da Windsurf também não é tão promissor assim.
Há um mês, usando o CURSOR para aprender o que era programação com IA, comecei a desenvolver um framework de desenvolvimento.
Por cerca de 3 semanas, repeti o ciclo de sucesso seguido pela quebra do código-fonte que havia sido validado por um AI Agent, e tentei de todas as formas controlar o AI Agent, mas falhei.
Então percebi que, antes de desenvolver o framework, a prioridade era desenvolver o código-fonte para controlar o AI Agent.
No fim, exatamente 1 mês depois de começar tentando entender o que era a IA, alcancei o resultado de concluir o desenvolvimento de um software 100% implementável e 100% operável por IA, com controle completo sobre o AI Agent (mais precisamente, sem necessidade de LLM externo nem de AI Agent).
Agora, há 14 dias, estou conduzindo o processo de criar e fazer cumprir regras operacionais enquanto dou treinamento adicional a essa META AI para um refinamento extra, e ao mesmo tempo estou migrando, melhorando e padronizando três sistemas MES que antes haviam sido feitos de forma incompleta por pessoas, já entrando na fase final.
E agora estou me preparando para mais uma evolução.