Pow Maykão... sonho você pegando um projeto top desse da Rocket e adicionando o HTMX consumindo APIs de Terceiro mesmo, algo como o IMDB, Open Weather, Dados Públicos do Governo... qualquer coisa que mostre outros caminhos para nós Devs. Eu amo demais o NextJS mas, só cheguei nele porquê tive que fazer um projeto em Nuxt mas, só de pensar no node_modules, servidores nodejs em dólar ... não tem como não pensar em aplicações feitas em Codeigniter com HTMX onde você tem menos 'complexidade'. É uma ideia para quem quer pelo menos ter um software e pagar um valor menor de manutenção. Faz falta o conteúdo mais raiz.
Eu recomendo todos que querem saber um pouco sobre o Intercioler, que é o precurssor dele. É claro ler o livro que tem o formato PDF disponível no site do próprio htmx. Se você em algum momento tiver que falar para o seu cliente que não pode desenvolver algo em htmx é porque você não sabe programar, porque o htmx não fica no caminho da programação ele simplesmente emite requisições recebe resultado que foi programado e jiga na tela, e não necessariamente na tela toda.
Achei muito interessante, mas ficou várias dúvidas como: - Auth, como persistir token, como lidar com cookies ou session, e repassar o token em chamadas seguintes. - Tratativas de erro, se pensar que o erro vem do back está ok, mas se o front nem encontrar o back? - Implementação em mobile, tem algo pronto ou isso está funcional com PWA? - Animações, validações e coisas do tipo... - Tem tanta coisa que me passa pela cabeça que nem vale detalhar cada uma... Deixo esses pontos como sugestão para um novo vídeo.
Conteúdo top. htmx funciona muito bem com Django, Golang entre outros, mas fica aquela dúvida, se, por ventura, futuramente o cliente precisar algo mais complexo que o htmx não atenda, falaremos pro cliente que não será possível? haha.
@@ustav_o se o início do projeto for um projeto simples, e ao caminhar o usuário queira algo mais complexo. Super normal ter alteração de funcionalidades no decorrer de qualquer projeto
Pelo menos no Django, existem uma infinidade de pacotes (Repositório Pypi) que podem ser agregados, para solucionar situações específicas, sem falar que o próprio Framework é escrito na linguagem, assim como o seu ORM muito robusto, estável e é nativo.
É aquela história do MVP que o cliente pede e depois jamais vai querer abrir mão. Eu fiz um MVP e depois de 2 meses trabalhando e entregando novas features, o cliente disse que o MVP é projeto de 20 dias e que já havíamos passado dessa fase faz tempo. Por sorte, eu já havia começado com o arsenal completo. React, Redux Sagas, Design System e por aí vai.
Ja fiz algumas validações com o HTMX/SSR, eu gostaria muito de subsituir o vue, mas nao é tão simples assim, aqui estão as limitações - componentizacao é complexo - muito complicado usar o frontend pra criar uma app mobile usando o capacitor por exemplo - nivel de reatividade no client-side, o HTMX PRECISA ir no server, mas tem casos que vc precisa reatividade no front, isso faz com que vc precise usar um alpine da vida infelizmente ainda não da pra substituir pra aplicações complexas, vc acaba digitando muito codigo javascript de qualquer forma, mas realmente simplifica MUITO, rotas, sem precisar fazer build etc. o caminho é esse, mas precisa resolver as questões que falei acima
@@maykbrito eu uso Go + Vuejs, estou sempre de olho pra tentar ficar só no Go + HTMX + Templ, aparentemente o templ da pra criar componentes. O SSR realmente simplifica MUITO, mesmo o Vue sendo "smples", aplicação JS fica complexa demais, bugs e muitos erros pq js é uma bosta(desculpe se vc é fã de JS), sem tipagem forte e isso gera MUITO erros, me lambra os erros do Python em tempos atrás (migrei do Python pro Go) Eu realmente quero dedicar um tempo e fazer uma validacao, talvez desenvolver algumas telas SSR no sistema atual, eu gosto de testar na prática mesmo onde o cliente vai usar na vida real. como o GO é extremamente rápido, request pro server pra renderizar HTML(HTMX) é algo meio que nao faz nem cocegas no Go. Eu realmente estou animado em poder usar somente o server, sem processo de build, isso DA MUITA FLEXIBILIDADE, SEGURANÇA, muitas possibilidades, tenho a impressão que esse futuro é inevitável, vamos ver rsrsrs
muito bom gostei do video, mas dessa forma o backend desse app vai depender do htmx para sempre? Pois pelo o que eu entendi, vamos sempre ter que mandar tags html, e nao um json como normalmente fazemos
Htmx é o que HTML deveria ter se tornado, se a W3C não fosse tão covarde e se não tivesse tanta empresa nela atuando como stakeholder, tentando embutir suas soluções proprietárias e remover outras funcionalidades porque seus navegadores estavam mais interessados em ocupar o market share do que serem refeitos para poder rodar direito. No ponto de vista computacional o advento de linguagens como Vue, Angular e similares mostrou apenas que havia um vácuo que foi inflacionado assim como sempre existe um vácuo para você rechear com frameworks que dizem que vão resolver todos os problemas quando na verdade são todos parecidos apenas com uma forma diferente de desenvolver que nada mais é o "cacoete" de quem fez o framework. Quando angular foi lançado eu percebi que a programação tinha se transformado em uma grande torre de Babel e as empresas iam se dividir em diversas linguagens e tornar a vida do programador ainda mais confusa. Não dá para ser full stack sabendo um pouco de cada coisa e no final não sabendo nada de tudo...
Bom, se você tem um landing page, faz muito sentido. Ou de 3 a quatro páginas num site ou blog. A coisa começa a ficar feia quando se precisa reaproveitar o código em diferentes páginas, modais, slides e etc. Aí amigão, os frameworks de SPA brilham.
Mayk, o que você acha de assistir a uma vídeo aula de um projeto, tentar realizá-lo, e quando encontrar dificuldades, consultar a vídeo aula? Após concluir o projeto, assistir à vídeo aula novamente e tentar replicá-lo até conseguir realizar sem ajuda. Você acha essa abordagem válida?
o que mata o ecosistema desenvolvimentista do javascript é a diversidade, é uma miríade de ferramentas muitas para fazer a mesma coisa (css, scss, tailwind,etc...), a curva de aprendizado é gigante e depois a curva para vc obter experiência idem.
HTMX eu vi pela primeira vez, a partir de uma palestra em Python, com objetivo de fugir desse JS mais pesado (programação funcional, programação reativa, Typescript, etc.) e por isso mesmo foi citado o termo JS Fatigue, que cada vez mais agrega funcionalidades, o que de certa forma trás incômodo a muitos desenvolvedores Full Stack forçando-os a serem eternos aprendiz em ambiente que cada vez mais exija produtividade e que torna código escrito, cada vez mais verboso e que o desgaste maior gerado, é em função do DEV se afastar do negócio em si, criando uma demanda desnecessária a meu ver.
Nossaa..... que delicinhaaa esse HTMX... (com licença da palavra pelo Deschamps)
Pow Maykão... sonho você pegando um projeto top desse da Rocket e adicionando o HTMX consumindo APIs de Terceiro mesmo, algo como o IMDB, Open Weather, Dados Públicos do Governo... qualquer coisa que mostre outros caminhos para nós Devs.
Eu amo demais o NextJS mas, só cheguei nele porquê tive que fazer um projeto em Nuxt mas, só de pensar no node_modules, servidores nodejs em dólar ... não tem como não pensar em aplicações feitas em Codeigniter com HTMX onde você tem menos 'complexidade'. É uma ideia para quem quer pelo menos ter um software e pagar um valor menor de manutenção.
Faz falta o conteúdo mais raiz.
Eu recomendo todos que querem saber um pouco sobre o Intercioler, que é o precurssor dele. É claro ler o livro que tem o formato PDF disponível no site do próprio htmx.
Se você em algum momento tiver que falar para o seu cliente que não pode desenvolver algo em htmx é porque você não sabe programar, porque o htmx não fica no caminho da programação ele simplesmente emite requisições recebe resultado que foi programado e jiga na tela, e não necessariamente na tela toda.
Achei muito interessante, mas ficou várias dúvidas como:
- Auth, como persistir token, como lidar com cookies ou session, e repassar o token em chamadas seguintes.
- Tratativas de erro, se pensar que o erro vem do back está ok, mas se o front nem encontrar o back?
- Implementação em mobile, tem algo pronto ou isso está funcional com PWA?
- Animações, validações e coisas do tipo...
- Tem tanta coisa que me passa pela cabeça que nem vale detalhar cada uma...
Deixo esses pontos como sugestão para um novo vídeo.
Conteúdo top. htmx funciona muito bem com Django, Golang entre outros, mas fica aquela dúvida, se, por ventura, futuramente o cliente precisar algo mais complexo que o htmx não atenda, falaremos pro cliente que não será possível? haha.
se o cliente quer algo complexo nunca devera ser feito utilizando o htmx primeiramente
@@ustav_o se o início do projeto for um projeto simples, e ao caminhar o usuário queira algo mais complexo. Super normal ter alteração de funcionalidades no decorrer de qualquer projeto
Pelo menos no Django, existem uma infinidade de pacotes (Repositório Pypi) que podem ser agregados, para solucionar situações específicas, sem falar que o próprio Framework é escrito na linguagem, assim como o seu ORM muito robusto, estável e é nativo.
É aquela história do MVP que o cliente pede e depois jamais vai querer abrir mão.
Eu fiz um MVP e depois de 2 meses trabalhando e entregando novas features, o cliente disse que o MVP é projeto de 20 dias e que já havíamos passado dessa fase faz tempo.
Por sorte, eu já havia começado com o arsenal completo. React, Redux Sagas, Design System e por aí vai.
Não trabalho com react, na empresa usamos boa parte em vuejs no front. Em projetos simples, tenho adotado o Alpinejs, é muito massa utilizá-lo!
Gostei muito da matéria. Achei bacana o autor levantar essa bandeira do "diga não ao JS", não que eu concorde, mas faz a gente refletir sobre...
Sempre um conteúdo de excelência ❤
Ja fiz algumas validações com o HTMX/SSR, eu gostaria muito de subsituir o vue, mas nao é tão simples assim, aqui estão as limitações
- componentizacao é complexo
- muito complicado usar o frontend pra criar uma app mobile usando o capacitor por exemplo
- nivel de reatividade no client-side, o HTMX PRECISA ir no server, mas tem casos que vc precisa reatividade no front, isso faz com que vc precise usar um alpine da vida
infelizmente ainda não da pra substituir pra aplicações complexas, vc acaba digitando muito codigo javascript de qualquer forma, mas realmente simplifica MUITO, rotas, sem precisar fazer build etc.
o caminho é esse, mas precisa resolver as questões que falei acima
Boa!! Obrigado por somar sua experiência! Se algum dia escrever sobre isso, manda pra gente ler em live e gerar conteúdo pra comunidade ;)
@@maykbrito eu uso Go + Vuejs, estou sempre de olho pra tentar ficar só no Go + HTMX + Templ, aparentemente o templ da pra criar componentes.
O SSR realmente simplifica MUITO, mesmo o Vue sendo "smples", aplicação JS fica complexa demais, bugs e muitos erros pq js é uma bosta(desculpe se vc é fã de JS), sem tipagem forte e isso gera MUITO erros, me lambra os erros do Python em tempos atrás (migrei do Python pro Go)
Eu realmente quero dedicar um tempo e fazer uma validacao, talvez desenvolver algumas telas SSR no sistema atual, eu gosto de testar na prática mesmo onde o cliente vai usar na vida real.
como o GO é extremamente rápido, request pro server pra renderizar HTML(HTMX) é algo meio que nao faz nem cocegas no Go.
Eu realmente estou animado em poder usar somente o server, sem processo de build, isso DA MUITA FLEXIBILIDADE, SEGURANÇA, muitas possibilidades, tenho a impressão que esse futuro é inevitável, vamos ver rsrsrs
muito bom gostei do video, mas dessa forma o backend desse app vai depender do htmx para sempre? Pois pelo o que eu entendi, vamos sempre ter que mandar tags html, e nao um json como normalmente fazemos
Htmx é o que HTML deveria ter se tornado, se a W3C não fosse tão covarde e se não tivesse tanta empresa nela atuando como stakeholder, tentando embutir suas soluções proprietárias e remover outras funcionalidades porque seus navegadores estavam mais interessados em ocupar o market share do que serem refeitos para poder rodar direito.
No ponto de vista computacional o advento de linguagens como Vue, Angular e similares mostrou apenas que havia um vácuo que foi inflacionado assim como sempre existe um vácuo para você rechear com frameworks que dizem que vão resolver todos os problemas quando na verdade são todos parecidos apenas com uma forma diferente de desenvolver que nada mais é o "cacoete" de quem fez o framework.
Quando angular foi lançado eu percebi que a programação tinha se transformado em uma grande torre de Babel e as empresas iam se dividir em diversas linguagens e tornar a vida do programador ainda mais confusa. Não dá para ser full stack sabendo um pouco de cada coisa e no final não sabendo nada de tudo...
Bom, se você tem um landing page, faz muito sentido. Ou de 3 a quatro páginas num site ou blog.
A coisa começa a ficar feia quando se precisa reaproveitar o código em diferentes páginas, modais, slides e etc. Aí amigão, os frameworks de SPA brilham.
Mayk, o que você acha de assistir a uma vídeo aula de um projeto, tentar realizá-lo, e quando encontrar dificuldades, consultar a vídeo aula? Após concluir o projeto, assistir à vídeo aula novamente e tentar replicá-lo até conseguir realizar sem ajuda. Você acha essa abordagem válida?
o que mata o ecosistema desenvolvimentista do javascript é a diversidade, é uma miríade de ferramentas muitas para fazer a mesma coisa (css, scss, tailwind,etc...), a curva de aprendizado é gigante e depois a curva para vc obter experiência idem.
e quanto a tratativa de erro como ele faz ?
HTMX eu vi pela primeira vez, a partir de uma palestra em Python, com objetivo de fugir desse JS mais pesado (programação funcional, programação reativa, Typescript, etc.) e por isso mesmo foi citado o termo JS Fatigue, que cada vez mais agrega funcionalidades, o que de certa forma trás incômodo a muitos desenvolvedores Full Stack forçando-os a serem eternos aprendiz em ambiente que cada vez mais exija produtividade e que torna código escrito, cada vez mais verboso e que o desgaste maior gerado, é em função do DEV se afastar do negócio em si, criando uma demanda desnecessária a meu ver.
Esse aí utilizou o Javascript pra falar mal do Javascript kkk
@@andersonmendes6610 hahahaahaah metajavascript