HTMX, ovvero: il mondo web è sempre sei mesi avanti!
Mario Alexandro Santini
la mia impressione, sviluppando web app da parecchi anni, è quella di
essere sempre 6 mesi indietro al resto del mondo.
In questi giorni al lavoro, sto migrando le app dalla versione 2 di vue
alla versione 3 (ricordo a chi usa vue che a fine anno terminerà
l'aggiornamento della versione 2 e la versione 3 sarà l'unica supportata).
Ma in giro c'è una nuova moda!
Ho pensato di scriverne in lista perché magari qualcuno potrebbe essere
interessato.
Parlo di HTMX, una libreria che permette di scrivere web app usando meno
javascript possibile.
In pratica utilizza degli attributi aggiuntivi sui tag HTML, per operare
richieste al server, alle quali si aspetta una risposta in forma di HTML
e non di dati JSON/GRPC da renderizzare sul client.
Questo perché HTMX riporta il rendering HTML sul server.
Ad occuparsi di tutti i passaggi è una libreria che dovete caricare
nelle vostre pagine e che si occuperà di gestire la comunicazione con il
vostro server.
La libreria è completamente agnostica rispetto allo stack che utilizzate
sul vostro server, purché generi HTML.
La filosofia è basata su HATEOAS (https://restfulapi.net/hateoas/).
https://htmx.org/
Sono sicuro che in molti ne avrete già sentito parlare. :)
Ad ogni modo io non la consiglio, nel senso che non avendola provata di
persona per farci una vera app, non ho una esperienza diretta su come
funziona e su quali problemi ci si potrebbe trovare.
La "promessa" è quella di non scrivere JavaScript, e credo che se ci
credete e la provate per questo, avrete una grossa delusione.
Mario
Simone Bordet
On Fri, Sep 8, 2023 at 3:53 PM Mario Alexandro Santini
<alexm...@gmail.com> wrote:
>
> Ciao,
>
> la mia impressione, sviluppando web app da parecchi anni, è quella di
> essere sempre 6 mesi indietro al resto del mondo.
>
> In questi giorni al lavoro, sto migrando le app dalla versione 2 di vue
> alla versione 3 (ricordo a chi usa vue che a fine anno terminerà
> l'aggiornamento della versione 2 e la versione 3 sarà l'unica supportata).
>
> Ma in giro c'è una nuova moda!
>
> Ho pensato di scriverne in lista perché magari qualcuno potrebbe essere
> interessato.
>
> Parlo di HTMX, una libreria che permette di scrivere web app usando meno
> javascript possibile.
>
> In pratica utilizza degli attributi aggiuntivi sui tag HTML, per operare
> richieste al server, alle quali si aspetta una risposta in forma di HTML
> e non di dati JSON/GRPC da renderizzare sul client.
>
> Questo perché HTMX riporta il rendering HTML sul server.
UX: "Ho cambiato il CSS come da richiesta business, quindi adesso mi
devi cambiare l'HTML che generi e aggiungere <div class="newClass">
S: "Ma dove esattamente?"
UX: "Ma lì"
S: "Fatto, ti faccio la release"
A few moments later...
UX: "No, non funziona non hai messo il <div> dove ti avevo detto"
GOTO 2
:D
--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
Guido Brugnara
Ciao,
la mia impressione, sviluppando web app da parecchi anni, è quella di essere sempre 6 mesi indietro al resto del mondo.
In questi giorni al lavoro, sto migrando le app dalla versione 2 di vue alla versione 3 (ricordo a chi usa vue che a fine anno terminerà l'aggiornamento della versione 2 e la versione 3 sarà l'unica supportata).
Ma in giro c'è una nuova moda!
Ho pensato di scriverne in lista perché magari qualcuno potrebbe essere interessato.
Parlo di HTMX, una libreria che permette di scrivere web app usando meno javascript possibile.
In pratica utilizza degli attributi aggiuntivi sui tag HTML, per operare richieste al server, alle quali si aspetta una risposta in forma di HTML e non di dati JSON/GRPC da renderizzare sul client.
Questo perché HTMX riporta il rendering HTML sul server.
L'approccio non mi è nuovo, ma la disponibilità di una libreria
ben strutturata e testata da usare o come fonte di ispirazione è
benvenuta.
Trovo interessante che supporta Websocket, anche se ancora
"experimental".
Ad occuparsi di tutti i passaggi è una libreria che dovete caricare nelle vostre pagine e che si occuperà di gestire la comunicazione con il vostro server.
La libreria è completamente agnostica rispetto allo stack che utilizzate sul vostro server, purché generi HTML.
Il codice Javascript contenuto nei TAG
<script/> inviati dal server verranno eseguiti nel browser
al suo caricamento. ma lo si può disabilitare.
Per chi come me sviluppa applicazioni molto interattive e
condizionate dal profilo utente questo approccio è preferibile
allo sviluppo di App. monolitiche e precompilate.
gdo
Mario Alexandro Santini
On 9/8/23 17:08, Simone Bordet wrote:
> Ciao,
Ciao Simone,
> Già mi immagino i developer UX che dicono ai developer Server:
>
> :D
>
:)
Penso che il target della libreria siano gli sviluppatori backend che
ogni tanto devono occuparsi del front-end e faticano a prendere in mano
framework come React o Vue o anche solo a studiarsi
JavaScript/TypeScript + HTML + CSS e via dicendo.
Lo capisco, perché le web app sono intrinseccamente complicate.
Qualche mese fa ho fatto una web app per lavoro, che uso solo io, è una
semplice pagina che mi permette di lanciare un build di docker e seguire
le varie fasi della build, senza collegarmi alla macchina con una shell.
Per farla ho usato Rust + Axum (web framework in Rust), con i template
Askama, perché pensavo che la paginetta, con un pulsante ed 2 tabelle,
fosse semplice abbastanza da usare solo HTML generato via server.
Alla fine, ho dovuto scrivere JS per alcuni aspetti che erano piuttosto
fastidiosi, tipo disabilitare il pulsante quando lanci la build.
Anche se il nuovo refresh della pagina disabilita il pulsante, il delay,
per quanto piccolo, ti tiene un momento in sospeso.
Per non parlare del feedback sulla partenza o meno del task...
Se mi capita una opportunità lo proverò, tanto per capire come funziona.
Mario
Mario Alexandro Santini
Ciao Guido,
I
l codice Javascript contenuto nei TAG <script/> inviati dal server verranno eseguiti nel browser al suo caricamento. ma lo si può disabilitare.
Ecco come lo scenario può diventare improvvisamente complicato.
Caricare pezzi di codice al volo in questo modo frammentato, conduce a situazioni dove debuggare un problema diventa molto complicato, perché potrebbero esserci delle azioni che sembrano "innocue", che invece mettono l'app in uno stato che porta al baco.
Per chi come me sviluppa applicazioni molto interattive e condizionate dal profilo utente questo approccio è preferibile allo sviluppo di App. monolitiche e precompilate.
Attenzione, HTMX si basa sull'assunto che lo stato dell'utente (di tutti gli utenti che utilizzano l'app) sia preservato sul server, oltre alla generazione del codice HTML ad ogni richiesta.
Mentre le SPA, scaricano il server dal conservare lo stato, perché lo tengono sul client.
In quanto all'interattività, non saprei se sia la scelta giusta
in questo caso.
bye
gdo
Mario
Guido Brugnara
On 9/9/23 11:08, 'Guido Brugnara' via Socraten wrote:
Ciao Guido,
I
l codice Javascript contenuto nei TAG <script/> inviati dal server verranno eseguiti nel browser al suo caricamento. ma lo si può disabilitare.Ecco come lo scenario può diventare improvvisamente complicato.
Caricare pezzi di codice al volo in questo modo frammentato, conduce a situazioni dove debuggare un problema diventa molto complicato, perché potrebbero esserci delle azioni che sembrano "innocue", che invece mettono l'app in uno stato che porta al baco.
Quel che definisci "frammentato" c'è chi lo chiama Miglioramento
progressivo (*)
Se sai cosa il server invia al browser il debug è fattibile alla
stessa stregua di un'App. SPA ma puoi anche inviare al browser
soltanto ciò che serve per replicare il bug e risolverlo in un
contesto più leggero.
Per chi come me sviluppa applicazioni molto interattive e condizionate dal profilo utente questo approccio è preferibile allo sviluppo di App. monolitiche e precompilate.
Attenzione, HTMX si basa sull'assunto che lo stato dell'utente (di tutti gli utenti che utilizzano l'app) sia preservato sul server, oltre alla generazione del codice HTML ad ogni richiesta.
Mentre le SPA, scaricano il server dal conservare lo stato, perché lo tengono sul client.
In quanto all'interattività, non saprei se sia la scelta giusta in questo caso.
Generazione del codice HTML ad ogni richiesta sì, ma solo per inviare frammenti di codice che cambiano la GUI dove serve.
Uso questo approccio in applicazioni costituite da centinaia di form da caricare on-demand che anche nel contenuto dipendono dal profilo utente. Avessi usato un approccio simil React o Vue (peraltro inesistenti nel 2003, quando il progetto fu ideato) dovrei creare e mantenere migliaia di form distinte oppure creare delle form assai compresse che cambiano aspetto lato client.
Non difendo questo modus operandi ma nemmeno lo promuovo ad
oltranza. Semplicemnte lo applico perché è nel mio caso
conveniente ormai da 20 anni e probabilmente lo sarà anche nei
prossimi 10, almeno fino a che i browser saranno in grado di
eseguire il codice Javascript ed interpretare l'HTML/CSS attuale.
bye
gdo
(*)
https://developer.mozilla.org/en-US/docs/Glossary/Progressive_Enhancement
bye
gdo
Mario
--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "Socraten" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a socraten+u...@googlegroups.com.
Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/socraten/74f5d118-4b5b-bbab-dac9-ebea48fc820c%40gmail.com.
Mario Alexandro Santini
Quel che definisci "frammentato" c'è chi lo chiama Miglioramento progressivo (*)
No, intendo frammentato e non è un miglioramento progressivo.
Il fatto valutare codice javascript inviato dal server "alla carte", espone al rischio di avere conflitti nei nomi e andare a ridefinire variabili globali o funzioni accessibili a livello globale.
Il che porta alla complessità di debug, perché fai fatica a replicare un bug, per il semplice motivo che è causato dalla modifica di una funzione che avviene per via di una chiamata fatta per un altro motivo.
Conta l'ordine di come carichi il codice dal server, quindi la sequenza delle operazioni eseguite.
La vita ti si complica di molto con questo modello.
Poi nel tuo caso Guido, tu lavoro da solo e sei molto disciplinato, quindi questi rischi sono di molto contenuti.
In un ambiente con più persone i rischi ci sono.
Naturalmente, anche evitare di mandare codice al client sulla singola richiesta è un modo efficace per abbattere questo rischio.
Ho letto delle issue su HTMX dove si chiedeva di caricare librerie restituite da una risposta del server.
L'autore della libreria HTMX suggeriva di evitare questo pattern, e di caricare le librerie che si usano nell'head del documento HTML.
Ed io concordo con questa impostazione.
Poi era anche dispostissimo a supportare la funzionalità in futuro, e poi sono problemi di chi la utilizzerà.
Se sai cosa il server invia al browser il debug è fattibile alla stessa stregua di un'App. SPA ma puoi anche inviare al browser soltanto ciò che serve per replicare il bug e risolverlo in un contesto più leggero.
Appunto "se sai cosa il server invia al browser", ma in questo scenario con HTMX, per saperlo ti serve che l'utente ti posa dire esattamente cosa ha fatto e anche in questo caso potresti non riuscire a replicare il problema, perché magari è dovuto a qualcosa che l'utente ha fatto un ora prima che gli capitasse il bug.
Uso questo approccio in applicazioni costituite da centinaia di form da caricare on-demand che anche nel contenuto dipendono dal profilo utente. Avessi usato un approccio simil React o Vue (peraltro inesistenti nel 2003, quando il progetto fu ideato) dovrei creare e mantenere migliaia di form distinte oppure creare delle form assai compresse che cambiano aspetto lato client.
Capisco chi non vuole usare Vue o React, che in effetti per chi
genera HTML lato server possono essere strumenti piuttosto
ingombranti. Oggi si possono usare anche i Web Components (o
meglio custom elements da specifica), che possono aiutare per le
parti più complesse che richiedono per forza JavaScript.
E secondo me, se non devi fare una SPA, devi dimostrare che ti sono veramente utili prima di utilizzarli.
Ma senza divagare troppo, se ci sono persone interessate, si pottrebbe anche organizzare un piccolo incontro online (o anche dal vivo avendo una sede disposta ad ospitarci) in cui sperimentiamo con HTMX creando una piccola app e vediamo cosa succede.
Mi offro come sperimentato per scrivere l'app, pur non sapendo ancora nulla di HTMX, ma sarebbe un modo per imparare e anche per condividere esperienze in maniera diretta.
bye
gdo
Mario
Luca Guadagnini
--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "Socraten" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a socraten+u...@googlegroups.com.
Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/socraten/d24a9f2a-83e5-4ea0-b6e2-9f408c1705eb%40gmail.com.
Mario Alexandro Santini
On 9/9/23 17:59, Luca Guadagnini wrote:
> Da quello che ho potuto vedere, i potenziali ambiti di HTMX, come
> avete già discusso, sono HATEOAS (e questo mi incuriosisce assai,
> soprattutto se venisse applicata l'implementazione Hydra) e server
> side rendering di UI.
>
hai perfettamente ragione.
> Perché è vero che negli ultimi 15 anni siamo stati abituati a SPA con
> AngularJS (ah bei tempi, più o meno), React e Vue, ma ultimamente i
> frontendisti con cui collaboro mi spacciano per nuovo la frontiera del
> backend-for-frontend, in altre parole server side rendering che non si
> appoggia necessariamente al classico server app con db, ma anche su
> api fornite da un altro servizio (un altro backend ad esempio).
supportato da Vue e React. In pratica si tratta della possibilità di
generare una pagina lato server a partire da componenti della SPA.
A questo si aggiunge la tecnica dell'hidration, ovvero di aggiornare la
pagina una volta che è stata caricata sul client.
Proprio di recente React ha introdotto una innovazione con il server
component, ovvero componenti React che sono sempre renderizzati sul
server e altri che sono renderizzati sul client, l'implementazione di
riferimento è Nestjs.
>
> Ma prima ci farò anch'io qualche prova, perché in effetti rendere
> stilosa una pagina HATEOAS con tanto di interazione non sarebbe male.
>
Mario
g...@leader.it
gdo
ma...@marcomoser.it
Parole sante Guido, io confermo e perseguo la TUA stessa identica esperienza:
la sostenibilità dei progetti è fondamentale (per piccolissime e grandi realtà aziendali)
Da: gdo via Socraten <socr...@googlegroups.com>
Inviato: domenica 10 settembre 2023 08:41
A: socr...@googlegroups.com
Oggetto: Re: HTMX, ovvero: il mondo web è sempre sei mesi avanti!
--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "Socraten" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a socraten+u...@googlegroups.com.
Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/socraten/S0RBW8%2400213595AD24D4DCAEAA899F7F9F502B%40leader.it.