htmx no desenvolvimento web (menos tempo e mais eficiência!)
Vložit
- čas přidán 5. 07. 2024
- APRENDA PROGRAMAÇÃO NA PRÁTICA (inscrição e evento GRATUITO): rseat.in/67pEzjzVK
Curso gratuito de programação WEB
↪discover.maykbrito.dev
Mais conteúdo?
↪ maykbrito.dev
Descubra como o htmx está revolucionando a forma de desenvolver aplicações web de maneira simples e eficiente. Aprenda como integrar recursos de hipermídia aos seus projetos, sem a necessidade de grandes frameworks. Explore as vantagens de utilizar o htmx para criar aplicações dinâmicas com menos complexidade, permitindo que você se concentre na experiência do usuário sem perder tempo com detalhes desnecessários.
00:00 🎯 Introdução ao htmx e desmistificação da busca por uma solução única
A complexidade na construção de software não tem uma solução única para resolver todos os problemas.
A construção de software envolve complexidade essencial e acidental.
A busca por uma "bala de prata" tecnológica não é realista, cada solução tem seu lugar e momento adequado.
03:11 🔍 Reflexão sobre a diversidade de tecnologias no mercado de front-end
A escolha de uma tecnologia deve levar em consideração o mercado e as oportunidades.
Não há uma solução única e mágica que sirva para todas as situações.
É importante estar aberto para aprender e utilizar diferentes tecnologias de acordo com o contexto.
05:37 🎯 Simplificação através do htmx e comparação com abordagens tradicionais
O htmx permite adicionar funcionalidades utilizando apenas atributos HTML.
A abordagem do htmx evita acumular mais e mais JavaScript no código.
A simplificação e eficiência do htmx são destacadas em comparação com abordagens tradicionais.
16:57 🧩 HTML puro como resposta do servidor
O htmx responde às solicitações com HTML puro.
O HTML entregue já está pronto para ser exibido, não necessitando de processamento adicional no navegador.
A abordagem do htmx se diferencia de frameworks SPA como o React, focando em hipermedia para manter a interatividade do navegador.
19:00 📜 Conceitos de hipermídia e REST
A hipermídia é uma mídia que permite interações não lineares, como links em um texto.
O REST, como concebido por Roy Fielding, defende a interação de aplicativos por meio de informações fornecidas pelo servidor, sem conhecimento embutido no código do cliente.
A abordagem de hipermídia do HTML possibilita manter informações de interação codificadas no texto, facilitando a navegação.
21:30 💡 Diferenças entre RESTful e REST com htmx
O JSON, por si só, não suporta facilmente os controles de hipermídia, o que impacta na implementação de uma API RESTful.
As API JSON frequentemente não são RESTful, pois é necessário adicionar links aos documentos para torná-las mais aderentes a esse estilo arquitetônico.
Adicionar hipermídia por meio do htmx pode tornar a interação com a API mais próxima dos princípios RESTful.
23:47 🌀 HTML como verdadeira hipermedia
O HTML é considerado uma verdadeira hipermedia, pois contém todas as informações de interação necessárias, como links e resultados de pesquisa.
O uso do htmx facilita a criação de aplicativos RESTful usando apenas HTML, superando limitações e simplificando a interação com o conteúdo da página.
Ao receber respostas em HTML do servidor via htmx, a aplicação pode ser mais dinâmica e interativa sem a necessidade de interpretar JSON.
34:16 🧩 JavaScript no Frontend e Backend
Argumento sobre usar JavaScript no backend também
Diferenças entre desenvolvimento frontend e backend
Pressão para usar JavaScript no backend
36:40 🖥️ Uso de htmx com Diferentes Linguagens de Programação
Flexibilidade em usar qualquer linguagem no servidor com htmx
Exemplos de integração de htmx com diversas linguagens
Facilidade de adicionar htmx a diferentes backends
38:17 🌐 Htmx como Suporte para Desenvolvedores de Backend
Htmx permite que desenvolvedores de backend foquem em HTML
Não é necessário entender JavaScript ou estilos para utilizar htmx
Viabiliza a construção de aplicações por desenvolvedores full stack
39:12 🔧 Htmx como Solução Simples em Comparação a Frameworks Spa
Abordagem de orçamento de complexidade de Carlson Gross
Situações em que o htmx é mais adequado do que frameworks Spa
Exemplo de migração bem-sucedida de React para htmx em um projeto
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.
Sempre um conteúdo de excelência ❤
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...
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.
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!
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?
e quanto a tratativa de erro como ele faz ?
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.
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.
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.