HTMX: Why You Don't Always Need a SPA Framework - Duncan Hunter - NDC Sydney 2024

This talk was recorded at NDC Sydney in Sydney, Australia. #ndcsydney #ndcconferences #developer #softwaredeveloper
Attend the next NDC conference near you:
ndcconferences...
ndcsydney.com/
Subscribe to our KZbin channel and learn every day:
/ ‪@NDC‬
Follow our Social Media!
/ ndcconferences
/ ndc_conferences
/ ndc_conferences
#html #vuejs #reactjs #angular #htmx #ux #web #app
The HTMX library allows you to access modern browser features directly from HTML rather than using JavaScript or a framework like React, Angular or Vue.
We'll discuss a Hypermedia Driven Application (HDA) architecture, a new/old approach to building web applications based on the server returning HTML vs JSON that can help you avoid the complexity and overhead of more complex frameworks.
By the end of this talk, you'll better understand when and why you might choose HTMX over a single page app for your next web app.

[@ParhamSalamati]

Although sound cut-offs were absolutely distracting, Thanks for sharing! :D

[@CristianKirk]

I think JS frameworks, as we know them today, are on the way out. And I don't think HTMX is a framework, I just see it as an amazing tool/library for doing and handling ajax requests, HTMX won't force any kind of structure on your project. I'm using HTMX in production combined with Symfony (PHP) for the backend.

[@FINALLYQQQQAVAILABLE]

Yes, htmx is not a framework. It is a tiny but quite powerful library that supports a declarative and hypermedia driven approach when building applications. People seem to have forgot that you can develop fully functional web applications without a frontend framework. Htmx just vastly extends the scope of what you can do should you choose that route.

[@zombiefacesupreme]

@@FINALLYQQQQAVAILABLE Would you normally construct your website as a series of HTML partials if you weren't using HTMX? Do you rely on HTMX to stitch together those partials on the front end? So, HTMX calls YOUR CODE that you put in to hx-attributes (classic Hollywood Principle or Inversion of Control), and you can't properly use HTMX unless you construct your entire application in a way that fits the FRAMEWORK.

[@evoker7lug]

I think HTMX doesn't have millions of NPM downloads because most developers use it via CDN

[@TechTalksWeekly]

This is an excellent talk and it has been featured in the last issue of Tech Talks Weekly newsletter 🎉Congrats!

[@ErickPaquin]

Really nice presentation. I will use this.

[@coffeeintocode]

Good talk. Timestamps would help though

[@Dmitry-Moiseenko]

Thank you for a great talk! 😊

[@TheDistantTrain]

Bought the Govee bulbs when you recommended them before. Looking into these now, thanks, Erin.

[@CernyMatej]

"I can actually call the server from an anchor tag with a href and actually do a get to my server" :D

[@drax432]

If we start sprinkling attributes like hx-delete, hx -swap all over the htmls, will it impact maintenance and readability of html ? I am more concern on big complex frontend.

[@drax432]

Similarly, if we add hx-trigger attributes in 100 different locations to trigger ajax call to fetch some data from server, then i decide to change my mind to replace the ajax call, with fetching data from local storage, e.g, will this require to apply the changes manually at 100 locations?

[@nuharaf]

@@drax432 yes

[@FINALLYQQQQAVAILABLE]

You don't have to sprinkle htmx attributes all over. Elements that make use of htmx features should typically be quite few. Buttons, links and other interactive elements. If you're going to replace 100 hx-trigger attributes in an application, then it's quite likely you're getting rid of htmx altogether. If you're doing that because you want to have more state on client side you're probably moving from a light frontend (which htmx is about) to a heavy frontend (which JavaScript frameworks are about). It's a change of architecture. You're probably rewriting great deal of your application. If you know you need a heavy frontend with a lot of state, then htmx is not the way to go unless you plan to use it for fast prototyping. Htmx might work well for prototyping as it allows a single full stack developer to go very fast with whatever backend language and frameworks (s)he's comfortable with.

[@fahim8690]

❤❤

[@abrahamtio]

so package data in html instead of a json. replace an spa's component-rendering with a server-side method that returns html. a backend dev has to learn html, or a front end dev has to learn something other than javascript. looks like a solution looking for a problem

[@555mek]

i dont know anything about this, i listen for the poetry, but the problem is the complexity of managing state on the client side. and as for learning, i dont know the words, but you simplify the build process or something. i wish i could think of a reason to try this cause even i know html and im not any kind of dev.

[@emmanikenna]

Also, This will force your to create a separate backend for api for other platform like mobile apps. I rather use jquery than htmx

[@tokeivo]

@@emmanikenna That's both true and false... HTMX (or HATEOS or whatever the right term is here) doesn't talk with the api. It talks with the app-state-engine. If you think you're transferring "the data", you're looking at it wrong. You're building the app on the fly. The backend is not sending you "the users", it's sending you "the user list window". If you need to build an api anyway, there's a chance HTMX is not for your project and you'll be better off using a framework that can consume your api.

[@nuharaf]

@@emmanikenna some company already have separate backend for mobile and web because its kind of hard to create general api that cater for both use. Even more when both mobile team and web app team want the api to server their specific purpose.

[@fluffysheap]

It means that much of what the front end dev does runs on the server, using a template engine instead of a JS framework. The things that define front end dev: presentation, html, css, browser compatibility, etc do not change. Only the place where the code runs changes. You will still have traditional Javascript for things that only JS can do. You just don't put your whole application state there. There is no reason why

[@pookiepats]

Stop calling it a framework lol wtf

[@pookiepats]

Now a methodology is a framework too ok dude

[@zombiefacesupreme]

It's classic inversion of control. HTMX calls the code you put into HTML attributes. HTMX is clearly a framework by the traditional definition.

[@pookiepats]

@@zombiefacesupreme wrong yet strongly stated - what a treat

[@zombiefacesupreme]

@@pookiepats I'm glad you like it! I can't link to it here, but feel free to read "Is htmx Just Another JavaScript Framework?" by Alexander Petros on the official HTMX site if you want to understand more. Have a good evening! 🙂

[@pookiepats]

@@zombiefacesupreme ok I'll be back!

[@howemeet]

bring back jquery and stop inventing new frameworks