The core idea behind htmx is pretty simple: instead of taking a json response from the server and converting that to html on the client, just respond with html fragments on the server and inject it directly. It's a technique I've used on some projects for about 16 years now, but it's nice to have a more widely supported, featureful library to do it.
Mmm... AJAX was always implemented with document fragments/markup responses generated on the backend. All of this frontend templating is what is strange, the backend always had templating since CGI and PHP. Decent backend projects were always structured into templates/fragments, library and api. Modern web development keeps trying to shoehorn backend features into the frontend and leave the backend to do nothing other than an api to the database.
This seems pretty cool when you are writing your server in some low level language. Instead of having to write the client interactivity with js, you could essentially write everything with simple templating and still have a highly interactive client application.
this is where my thoughts are think of a real time video game, except the interactions are clicks and those are sent up and the new scene is rendered and sent down
let's be honest nobody will build the next gutenberg block editor or figma or hootsuite dashboard with htmx. The project feels like someone was so mad at the new world we are in that he gave every element the power to make requests which is cool but meh..
Htmx has been a god send as a solo developer. I’ve been running around for two years absorbing all the JavaScript hype and htmx just cuts straight through the bs and gets you right to developing in your favorite language. Building an enterprise level application? Use a framework. Building a smaller scale CRUD app? Htmx just makes it so much cleaner and easier to deploy if you run off a binary generating language like rust or go.
Honestly this is one of the only sane web technologies I lately have seen - was thinking about implementing something similar myself lol :-) What would be good if browsers add support to this directly - instead of needing to download even the small Js file for it.... But the script should be there in case of browsers who do not support this already...
The author of HTMX says that he simply made HTML to what it was supposed to evolve to but for some reason did not. It could be that the next HTML version would include similar functionality but i would not hold my breath.
I still can't believe how hard it's for young/"modern" devs to understand this. So used to js frameworks and separation of backend/frontend with "json API"s that can't grast this simple library. It's just hypertext! you interact with the browser that interchange hypertext, using REST, that's it!. It's what HTML since v3 or before should have been.
I love how this is such a huge paradigm shift that devs are completely befuddled by it at first. Then you realize how simple it is if you don't over think it
@@ed_iz_ed Yes, exactly. People need to understand that the vast, vast majority of their application does not require extreme video-game level interactivity. Most of it is view stuff, take form-like input, and then persist and reload the viewport (or part of it) with new info. There's no reason to over-engineer your application for that 1% portion that requires constant updating.
34:27 it wouldn’t be spaghetti code. But it would mean each interaction of a webpage maps to a specific URL. Which is what should be happening already (unless you have a GraphQL or gRPC) powered website.
What are the limitations? For my experience I was trying to build an end-end encrypted app and realized very quickly that was not going to happen. Offline is for sure out of the question. But most apps are just changing HTML based on server JSON which means that you should just cut out the middleman. Most apps should use this or something similar.
@@mihailmojsoski4202 there's backend-oriented templating languages and pretty much every language. It's a little different to work with than React since there's not really any state but in that way it's also a lot simpler. You store most of the state in the database which is kind of where you want it anyway for many apps.
So this is mainly for building form-driven sites with some kind of SSR? But without having to write a bunch of JS? I could see how that could be nice for some uses. Seems like it's a frontend tech for backend engineers xD
One of the problems with "the web" environment is that we create solutions that are meant to solve problems with things that were supposed to be solutions for other problems. And sure, it might be cool and shiny but IMO it would be beneficial to start from scratch and see if we can do something different than just Ajax 5000 with bells and whistles and 30 transpilers on top.
You need a whole dedicated ci pipleine server just to do the prettier->maxify->babel->polyfill->tsc->webpack->minify-> Are these out of order? No one knows because it's been slowly layering over the years, and no one actually know how all this stuff fits together
35:34 is it good? And what’s happening on the backend? The same stuff that happens on any SSR site. The only difference is that what is returned is a specific component rather than an entire page. It’s neat.
After reading a lot of the HTMX book, I'm really coming around to this HATEOAS thing - Hypermedia (HTML) as the engine of application state. When I think about writing that simple view-edit email form (~32:00) in a typical framework, you have to manage all that "isEditing" state on the client to show either plain text or an input and the form and the submit button. To me, this is so much simpler. If I'm on /contact/1, I'm showing the info. If I'm on /contact/edit/1, it's a form. Having done Ember, Angular, React, Vue, I'm really tired of the concept that all reactivity has to be done on the client.
I don't mind the idea of HTMX, I used to pass around html through AJAX request some decades ago. And I still kind of like using Turbo when I prototype an app with Rails (same idea as htmx except it only works with links / buttons / forms). This may be why I don't really like the idea that you can do request with any element. It seems to me to be an enormous issue for accessibility since a "div" shouldn't be interacted with. I guess you can kind of tell through aria attributes that a div is interactable but it's not the optimal solution: you are still hoping that the client can understand it correctly. As long as it is used accordingly, it could be nice for small projects or when you need to prototype something quickly.
Yeah it should discourage forcing interactivity on passive layout/formatting elements like div's,p,etc in favor of more semantic tags that lack editability like address, or easier to wrangle remote interactivity between 's toggling open something elsewhere on the page. Really just kinda need a framework DSL where you code something like HTMX but it just generates the appropriate forms and semantic elements.
This looks like a much nore pleasant way of dealing with event handlers and observers. Im curious how much security is provided though, for example what would prevent a malicious user posting to contact/2?
yes. The whole idea is to remove your dependency on javascript libraries as much as possible and have the server return HTML instead of JSON. HATEOAS is the original definition describing how html should be sent from the server
The H in HATEOAS is Hypertext. The point is driving all transitions with links returned from the server, which encode posible actions. HTML lends itself well to this, because you don't have to unpack the links, just render the elements which already hold the links .
So, if it works without JS, what if I wanted to plot a graph using a 3rd part library like D3 or maybe I wanted to use a Tailwind component library like DaisyUI which needs JS?
You pretty much need some sort of framework like this to make it work. It's really great I've used it in Elixir/Phoenix before. One simple way to try it out is to make admin inpoints for your back end to manage data for customers. Just return some HTML forms and you can do validation and other stuff without having to do all the crazy react stuff with APIs. We have a really robust customer service tools now because of it.
@@LoneIgadzra yeah exactly. It's a really great thing to learn for that reason because you can lower the time it takes you to implement this kind of thing by a huge amount. And if you combine it with an islands type architecture you can actually make a pretty advanced app. It only gets a little too complicated when we have a lot of stuff that needs to sync state across multiple components and therefore you end up in a situation where there's a lot of local state. That said, most apps have too much local state that doesn't need to be there.
@@GagePeterson Except for example you can just straight up use HTMX with PHP, no framework needed. Of course it's encouraged, but not needed since PHP natively returns HTML.
@@abitofBaileys yeah you totally could although I found in practice it's really nice to have all the database stuff, user management, generators, etc. things that would come with Laravel or some other Rails like framework. But for sure keep it simple if you're just starting out learning MPAs.
The problem was with calling it ajax. Xml is harder to read than json. So why not just use json. But that's where we strayed. It should have been called AH. Asynchronous Html. (I know html is a "subset" of xml, but that's not the point.) Xml is what we think of when sending raw data. Which was ultimately where things went wrong and the clients got too thick
You don't like dhh/ruby/rails... Butt.... Hotwire& turbo already have been doing this for a long time. They even mention it in their about section, they just wanted less opinionated.
This is feels a less optimized and more generic (or more "pure") version of LiveView and I think thats amazing because now you are not forcing devs to move to elixir (although it's amazing) just to enjoy a liveview-like experience. Imagine htmx with a go or rust backend just flying (htmx + go will probably be the sweetspot between performance and DX). I'm still going to use elixir because writing backend with it it's pure joy but I might try htmx with plain old Phoenix templates. Plus imagine if a future version of html adopted this and browsers were to support it natively not even requiring the htmx script. That would be crazy and more than enough for a very high percentage of webpages.
Not the same. Angular 1 was a client-side rendered JS framework, competing with Ember, React, etc. HTMX enables traditional SSR serving HTML to be more interactive.
@@LoneIgadzra you didn't need to do all templating with angular for it to be useful. early angular apps used both ssr and angular directives. react was and still is a spectacularly bad idea.
8:57 I can remember start of 2020 when I was learning jQuery, and I have not heard about React and stuff. But I wanted to create the same experience that page should not load when user clicks a link. So I just did the same thing. I sent a get request to the page I wanted to get and later-on I simply did "innerHtml = dataInTheResponse", (tbh this is what htmx sounds like till now) and this didn't re-loaded the page and end-user got the feel of a SPA with a lazy-loading feature...
Yep. Fetching html fragments was not uncommon in 2007 era when ajax was getting hyped. But then SPA and componental philosophy was getting hyped in 2012 where you fetch from API instead and let the SPA framework/components take in the data to display it. This feels like a mix of early Ajax days mixed with SPA template directives.
286 is Failed Successfully energy, should just be a straight 400, 403, etc 286 could be logically valid but seems like an antipattern because you have to stop what your doing to think about it like a double negative condition that should be unrolled into separate statements. Both that and 20:2 seems like a 429 too many requests or 508 Loop Detected status more than a made up status code
Why? It's just the backend saying "hey buddy, stop polling because the state of this call is not changing anymore" but it's still retuning the "final" version of the html requested by the frontend, so it's a 200 that also tells the client to not poll anymore. It's the same as using the recursive version where the backend returns an html that will call the same endpoint after 2 secs but then some future call will return the html element w/o the "call your own endpoint after 2 sec" part to indicate that this state is final so it makes no sense to keep asking for updates.
Still, a bit disingenuous to harp the "no JavaScript" bent of htmx. It's totally JS, just neatly tucked up and under, stuffed into element attributes syntax. Feels better to admit it out loud, right? 😮😢😂😅😊
It's beyond me how HTMX even got a following. Seriously, why would anyone in their right mind want to revert to this convoluted mess of HTML-centric code? It feels like taking a huge step back from the progress we’ve made with modern JavaScript frameworks. HTMX claims to make web development easier, but in reality, it’s just a thinly veiled attempt to cram server-side logic into the front-end, making everything more complicated and harder to maintain. The whole concept is a recipe for spaghetti code. And don’t get me started on the so-called "simplicity" of HTMX. Sure, sprinkling some attributes on your HTML might seem straightforward at first, but once your application grows, you'll quickly find yourself buried in an unmanageable tangle of attributes and custom behaviors. This might have been fine in the 90s, but we've moved on for a reason! To anyone considering HTMX: save yourself the headache and stick with frameworks that actually embrace modern development practices. Your future self will thank you.
Stop goofing with this nonsense languages, Elm is like Rust for the Web, but even better. To me HTMX is doing something similar to Vue/React/Angular1 but in the personalized view of the creator, is like N-th java-like that is supposed to be better than java but still offers the same thing the JVM.
Bruh, that's how javascript frameworks do it. It's a different syntax, but... The UI is event based, so attaching event handlers to things is totally normal
bruh this sounds terrible idea. mixing a markup language with functionality is just ... really limiting, esoteric (as in you have to learn ton of stuff to do stuff you could already have done with the languages/ways you already know without any improvements only limits), kinda feels like learning brainfuck just because you can write less things and get more output for simple examples. Like what's the point? You're still gonna use JS anyways. At least replace JS with an actual programming language. Not put JS things as an esoteric thing in HTML and then naming it HTMX. Then it's hot a Hypertext Markup Language. It's .... an esoteric something language. But definitely not Markup. Edit: But the point is not the abbreviation of "HTML". Name it whatever you want. The point is that it's really limited at what it can and can't do. Why would somebody use it when they're gonna use JS for even the slightest more complicated thing your language doesn't support anyways?
A couple points 1. "What you already know" is not a valid argument because if it's a better way, then people should have learned this way from the start. 1.B. You should be learning new things as a software developer. 2. You don't wind up using JS anyway. Becuase point 3. You still write this out in some kind of server language to provide the html. They don't show examples of it because they aren't prescribing what that looks like, but ultimately, that's where the writing will be done is on the server, and that's a good thing. Less worries about an extra layer of client caching
@@Jabberwockybird 1. "What you already know is not an actual argument"? Why? If I already know how to solve a problem easily in Javascript, why try to solve it in a new language I don't know that doesn't seem to provide solutions for so many other problems anyways? Like HTMX doesnt provide reactivity, state control or anything. That's where JS comes anyways! Either you use HTMX or not. Like you're not escaping Javascript, you're just pretending that you escape it for a while until you don't. 2. You're gonna have to use a server either way, either you use HTMX or not. What's your point exactly?
@@bioburden doesnt scale well , doesnt provide clear execution sequence, no debuging when screwing up , doesn't provide separation of concern ie behaviour separated from view, Idk about security concerns that htmx comes with.
@@lMINERl And let me add endpoints returning partials of HOW data should be displayed instead of data itself is problematic if you want to use that API for inter-service comms or for building another UI; HTML attributes seem nice and clean until you have your templates fully polluted; you lose data/UI reactivity, if you change data you have to remember which partials to return AND swap in the appropriate places, if you have little elements scattered across the page (say 4 UI elements) you have to remember to return the partials of all 4 AND specify where to place them based on DOM IDs. Why would you prefer this over those elements being updated by a framework when the data changes? Its literally the pubsub pattern that saves us so much work.
damn, chat is trash when he's trying to actually learn something instead of doing reaction
The core idea behind htmx is pretty simple: instead of taking a json response from the server and converting that to html on the client, just respond with html fragments on the server and inject it directly. It's a technique I've used on some projects for about 16 years now, but it's nice to have a more widely supported, featureful library to do it.
So the server is the frontend implementation.
@@rickdgsadly true
Mmm... AJAX was always implemented with document fragments/markup responses generated on the backend. All of this frontend templating is what is strange, the backend always had templating since CGI and PHP.
Decent backend projects were always structured into templates/fragments, library and api. Modern web development keeps trying to shoehorn backend features into the frontend and leave the backend to do nothing other than an api to the database.
@@PaulSpades exactly
but that isn't a bad though, right? @@PaulSpades
Woow! Finally, htmx getting the attention it deserves
This seems pretty cool when you are writing your server in some low level language. Instead of having to write the client interactivity with js, you could essentially write everything with simple templating and still have a highly interactive client application.
Yeah it seems like a more -powerful- granular SSR
this is where my thoughts are
think of a real time video game, except the interactions are clicks and those are sent up and the new scene is rendered and sent down
@@TheVimeagenI know that's a joke, but it's almost literally what game streaming services are 🤫
@@SimonBuchanNz that's actually a cool observation! Phoenix live view is kind of like doing this except it sends DOM diffs instead of pictures.
let's be honest nobody will build the next gutenberg block editor or figma or hootsuite dashboard with htmx. The project feels like someone was so mad at the new world we are in that he gave every element the power to make requests which is cool but meh..
Htmx has been a god send as a solo developer. I’ve been running around for two years absorbing all the JavaScript hype and htmx just cuts straight through the bs and gets you right to developing in your favorite language.
Building an enterprise level application? Use a framework. Building a smaller scale CRUD app? Htmx just makes it so much cleaner and easier to deploy if you run off a binary generating language like rust or go.
Honestly this is one of the only sane web technologies I lately have seen - was thinking about implementing something similar myself lol :-)
What would be good if browsers add support to this directly - instead of needing to download even the small Js file for it.... But the script should be there in case of browsers who do not support this already...
The author of HTMX says that he simply made HTML to what it was supposed to evolve to but for some reason did not. It could be that the next HTML version would include similar functionality but i would not hold my breath.
I still can't believe how hard it's for young/"modern" devs to understand this. So used to js frameworks and separation of backend/frontend with "json API"s that can't grast this simple library. It's just hypertext! you interact with the browser that interchange hypertext, using REST, that's it!. It's what HTML since v3 or before should have been.
htmx... some ppl cant stand its simplicity, its beauty, its awesomeness 🙂
I love how this is such a huge paradigm shift that devs are completely befuddled by it at first. Then you realize how simple it is if you don't over think it
Been using htmx for 6 months and loving it, really excellent workflow.
Yo, I just picked up HTMX. How the heck am I supposed to make shareable urls??
astro and htmx might be a good combo for simple web pages, with a few forms for interactivity.
if you need more interactivity you can just add it where needed
@@ed_iz_ed Yes, exactly. People need to understand that the vast, vast majority of their application does not require extreme video-game level interactivity. Most of it is view stuff, take form-like input, and then persist and reload the viewport (or part of it) with new info. There's no reason to over-engineer your application for that 1% portion that requires constant updating.
its called the AHA stack
I think this is a very nice tool for CRUD applications, where vanilla js is a hassle, and using something like react is 100% overkill
Vanilla JS is not really a hassle.
Like Prime said, "readability isn't a thing, it's just how familiar you are with the thing"
🍦
But I do like the htmx idea. It's better than using JS for a crud app
34:27 it wouldn’t be spaghetti code. But it would mean each interaction of a webpage maps to a specific URL. Which is what should be happening already (unless you have a GraphQL or gRPC) powered website.
Alternatively, you can reduce the amount of embedded content and hide it as server side state
seems pretty interesting, not sure why you'd need it when there is JDSL. Tom is a genius.
Trust me bro, it's really powerful
Been using HTMX with Spring Boot on my personal project, really happy with the results.
Htmx feels like for person who does mostly backend and want that upgrade from jQuery
I feel seen...
What are the limitations? For my experience I was trying to build an end-end encrypted app and realized very quickly that was not going to happen. Offline is for sure out of the question. But most apps are just changing HTML based on server JSON which means that you should just cut out the middleman. Most apps should use this or something similar.
Making your own template engine in the backend I guess
@@mihailmojsoski4202 there's backend-oriented templating languages and pretty much every language. It's a little different to work with than React since there's not really any state but in that way it's also a lot simpler. You store most of the state in the database which is kind of where you want it anyway for many apps.
So this is mainly for building form-driven sites with some kind of SSR? But without having to write a bunch of JS? I could see how that could be nice for some uses. Seems like it's a frontend tech for backend engineers xD
Yeah. As a frontend engineer, I hate this.
One of the problems with "the web" environment is that we create solutions that are meant to solve problems with things that were supposed to be solutions for other problems. And sure, it might be cool and shiny but IMO it would be beneficial to start from scratch and see if we can do something different than just Ajax 5000 with bells and whistles and 30 transpilers on top.
You need a whole dedicated ci pipleine server just to do the prettier->maxify->babel->polyfill->tsc->webpack->minify->
Are these out of order? No one knows because it's been slowly layering over the years, and no one actually know how all this stuff fits together
Woah, next can they make my JSON make http requests and mutate itself while being parsed?
You didn't just get DMCA'd, you also got DMC'd :D
35:34 is it good? And what’s happening on the backend? The same stuff that happens on any SSR site. The only difference is that what is returned is a specific component rather than an entire page. It’s neat.
After reading a lot of the HTMX book, I'm really coming around to this HATEOAS thing - Hypermedia (HTML) as the engine of application state. When I think about writing that simple view-edit email form (~32:00) in a typical framework, you have to manage all that "isEditing" state on the client to show either plain text or an input and the form and the submit button. To me, this is so much simpler. If I'm on /contact/1, I'm showing the info. If I'm on /contact/edit/1, it's a form. Having done Ember, Angular, React, Vue, I'm really tired of the concept that all reactivity has to be done on the client.
man your chat so annoyng, I can't even watch the video
Imagine htmx with tailwind 😂
5:30 Prime needs to clip that and replace his Costco clip lol
"Hi Primeagen what is sex" I for one am waiting for the prime birds and bees video
sounds like its time to get old serverside and session knowledge from the archives.
svelte is just plainly amazing .
no
Yuuuuhuuu, Svelte. I also like speed and Solid, but I bet on Svelte overall
I don't mind the idea of HTMX, I used to pass around html through AJAX request some decades ago. And I still kind of like using Turbo when I prototype an app with Rails (same idea as htmx except it only works with links / buttons / forms).
This may be why I don't really like the idea that you can do request with any element. It seems to me to be an enormous issue for accessibility since a "div" shouldn't be interacted with. I guess you can kind of tell through aria attributes that a div is interactable but it's not the optimal solution: you are still hoping that the client can understand it correctly. As long as it is used accordingly, it could be nice for small projects or when you need to prototype something quickly.
Yeah it should discourage forcing interactivity on passive layout/formatting elements like div's,p,etc in favor of more semantic tags that lack editability like address, or easier to wrangle remote interactivity between 's toggling open something elsewhere on the page. Really just kinda need a framework DSL where you code something like HTMX but it just generates the appropriate forms and semantic elements.
The Primeagen present YAHWIWD: Yet Another Hype Wave In Web Development
This looks like a much nore pleasant way of dealing with event handlers and observers. Im curious how much security is provided though, for example what would prevent a malicious user posting to contact/2?
cookies, setting a header, yknow... the classics
38:54 "the server drives everything" Is this what they call HATEOAS?
yes. The whole idea is to remove your dependency on javascript libraries as much as possible and have the server return HTML instead of JSON. HATEOAS is the original definition describing how html should be sent from the server
The H in HATEOAS is Hypertext. The point is driving all transitions with links returned from the server, which encode posible actions. HTML lends itself well to this, because you don't have to unpack the links, just render the elements which already hold the links .
It took me so long to understand HATEOAS. For so long, I though of REST the opposite way with raw data being resources.
Being submissive and being passive in a relationship are completely orthogonal concepts.
29:58 Do those confirmations use promt or can we link to some html to open a dialog?
33:18 So any validation messages also need to be within the scope of the outerHtml? And the hat does the back button do after clicking Edit?
It seems like PG was missing HTMX’s utility in static websites
So, if it works without JS, what if I wanted to plot a graph using a 3rd part library like D3 or maybe I wanted to use a Tailwind component library like DaisyUI which needs JS?
Laravel would probably work nice with this, it's got good support for these granular ssr components
I think it could be interesting to use with Laravel
would htmx make it manageable to work with django and rails? As opposed to using react
You pretty much need some sort of framework like this to make it work. It's really great I've used it in Elixir/Phoenix before.
One simple way to try it out is to make admin inpoints for your back end to manage data for customers. Just return some HTML forms and you can do validation and other stuff without having to do all the crazy react stuff with APIs. We have a really robust customer service tools now because of it.
There is already a django-htmx extension
@@LoneIgadzra yeah exactly. It's a really great thing to learn for that reason because you can lower the time it takes you to implement this kind of thing by a huge amount. And if you combine it with an islands type architecture you can actually make a pretty advanced app. It only gets a little too complicated when we have a lot of stuff that needs to sync state across multiple components and therefore you end up in a situation where there's a lot of local state. That said, most apps have too much local state that doesn't need to be there.
@@GagePeterson Except for example you can just straight up use HTMX with PHP, no framework needed. Of course it's encouraged, but not needed since PHP natively returns HTML.
@@abitofBaileys yeah you totally could although I found in practice it's really nice to have all the database stuff, user management, generators, etc. things that would come with Laravel or some other Rails like framework.
But for sure keep it simple if you're just starting out learning MPAs.
The name .............. is the HTMXeagen
I finally got the DMC meme. damn am I slow
So thats what 420 wpm programms like huh
this library is for full-stack PHP developers or full-stack Django developers with the "templates" thing or whatever.
20:45 it actually makes sense 😅 because of "outerHTML"
so, does HTMX propose constructing app using microfrontends?
This looks really neat. I'm gonna have to play with this soon
I wish there was a more simplified web protocol that was based on privacy and energy usage considerations that weren't text only.
websockets, webtransport, blobs using fetch?
lol Ibai breaking the Internet XDDD
yes HTMX
So, the Web is a little less broken?
HTMX + JSX is a smart way.
13:50 prime being mushy
You know how all languages are trying to target quantic computer, you have Qthis, Qthat... How much I'd love Brainf*ckQ
Oh this is amazin. I always felt its wrong to use json for ajax
The problem was with calling it ajax. Xml is harder to read than json. So why not just use json. But that's where we strayed.
It should have been called AH. Asynchronous Html.
(I know html is a "subset" of xml, but that's not the point.) Xml is what we think of when sending raw data. Which was ultimately where things went wrong and the clients got too thick
8 to 6 (86) working from 8 O'Clock PM to 6 O'Clock AM??
So you are telling me I need separate entry points on my server for mobile and web now?
Only now I noticed that this is not the Primeagen or PrimeTime
You don't like dhh/ruby/rails... Butt.... Hotwire& turbo already have been doing this for a long time. They even mention it in their about section, they just wanted less opinionated.
not sure which one is older, htmx is like the v2 of another lib., Intercooler, from the same author, but yeah, HTML-over-the-wire is not new
This is just like Phoenix LiveView for Elixir which we use at work but weirder.
This is feels a less optimized and more generic (or more "pure") version of LiveView and I think thats amazing because now you are not forcing devs to move to elixir (although it's amazing) just to enjoy a liveview-like experience.
Imagine htmx with a go or rust backend just flying (htmx + go will probably be the sweetspot between performance and DX).
I'm still going to use elixir because writing backend with it it's pure joy but I might try htmx with plain old Phoenix templates.
Plus imagine if a future version of html adopted this and browsers were to support it natively not even requiring the htmx script. That would be crazy and more than enough for a very high percentage of webpages.
Perl has some questionable readability as well 😆
Graffkweel!
you forgot about APL and whitespace. But yes, C++ and brainfuck are unreadable
This lookes quite similar to alpine and petits-vue.
the idea behind is the same as angular v1 with less features
Not the same. Angular 1 was a client-side rendered JS framework, competing with Ember, React, etc. HTMX enables traditional SSR serving HTML to be more interactive.
@@LoneIgadzra you didn't need to do all templating with angular for it to be useful. early angular apps used both ssr and angular directives. react was and still is a spectacularly bad idea.
8:57 I can remember start of 2020 when I was learning jQuery, and I have not heard about React and stuff. But I wanted to create the same experience that page should not load when user clicks a link. So I just did the same thing. I sent a get request to the page I wanted to get and later-on I simply did "innerHtml = dataInTheResponse", (tbh this is what htmx sounds like till now) and this didn't re-loaded the page and end-user got the feel of a SPA with a lazy-loading feature...
Yep. Fetching html fragments was not uncommon in 2007 era when ajax was getting hyped. But then SPA and componental philosophy was getting hyped in 2012 where you fetch from API instead and let the SPA framework/components take in the data to display it. This feels like a mix of early Ajax days mixed with SPA template directives.
218 respones code opp
so the back has to return html ? so the backend has to know the css class ?
That's not necessarily a bad thing. As it is today, html (with the css classes) is served up from some kind of back end.
I think I wasted 40 minutes for what could've been 10
10 minutes were good though
please unsub
@@TheVimeagen No flirting in the chat. It's against TOS.
286 is Failed Successfully energy, should just be a straight 400, 403, etc
286 could be logically valid but seems like an antipattern because you have to stop what your doing to think about it like a double negative condition that should be unrolled into separate statements.
Both that and 20:2 seems like a 429 too many requests or 508 Loop Detected status more than a made up status code
Why? It's just the backend saying "hey buddy, stop polling because the state of this call is not changing anymore" but it's still retuning the "final" version of the html requested by the frontend, so it's a 200 that also tells the client to not poll anymore.
It's the same as using the recursive version where the backend returns an html that will call the same endpoint after 2 secs but then some future call will return the html element w/o the "call your own endpoint after 2 sec" part to indicate that this state is final so it makes no sense to keep asking for updates.
DMC-ed or DMCA ed lol
Still, a bit disingenuous to harp the "no JavaScript" bent of htmx. It's totally JS, just neatly tucked up and under, stuffed into element attributes syntax.
Feels better to admit it out loud, right?
😮😢😂😅😊
I think the idea is to encourage people to only write logic in the server and not try to mix this with Javascript and make yet another framework.
NO HTMX. 😂 Let’s make YAF yet another framework.
It's beyond me how HTMX even got a following. Seriously, why would anyone in their right mind want to revert to this convoluted mess of HTML-centric code? It feels like taking a huge step back from the progress we’ve made with modern JavaScript frameworks. HTMX claims to make web development easier, but in reality, it’s just a thinly veiled attempt to cram server-side logic into the front-end, making everything more complicated and harder to maintain. The whole concept is a recipe for spaghetti code.
And don’t get me started on the so-called "simplicity" of HTMX. Sure, sprinkling some attributes on your HTML might seem straightforward at first, but once your application grows, you'll quickly find yourself buried in an unmanageable tangle of attributes and custom behaviors. This might have been fine in the 90s, but we've moved on for a reason!
To anyone considering HTMX: save yourself the headache and stick with frameworks that actually embrace modern development practices. Your future self will thank you.
Javascript/Typescript sucks, wasm is slow, so ill stick with htmx + rust or go
No idea why you'd use this over AlpineJS.
No idea why you would use Alpine JS, never heard of it.
It's obvious to you in the middle of it, but there are thousands of JS frameworks out there.
owo
Stop goofing with this nonsense languages, Elm is like Rust for the Web, but even better. To me HTMX is doing something similar to Vue/React/Angular1 but in the personalized view of the creator, is like N-th java-like that is supposed to be better than java but still offers the same thing the JVM.
Didn't the benevolent dictator strangle Elm to death?
This seems like a more aids version of vue
Isn't this like... Fundamentally unaccessible? Attaching click events to random tags is not what's recommended for any sensible website
Bruh, that's how javascript frameworks do it.
It's a different syntax, but...
The UI is event based, so attaching event handlers to things is totally normal
Also, check the definition of "hypermedia" that's when I had a major ah-ha epiphany and started to understand this stuff
bruh this sounds terrible idea. mixing a markup language with functionality is just ... really limiting, esoteric (as in you have to learn ton of stuff to do stuff you could already have done with the languages/ways you already know without any improvements only limits), kinda feels like learning brainfuck just because you can write less things and get more output for simple examples. Like what's the point? You're still gonna use JS anyways.
At least replace JS with an actual programming language. Not put JS things as an esoteric thing in HTML and then naming it HTMX. Then it's hot a Hypertext Markup Language. It's .... an esoteric something language. But definitely not Markup. Edit: But the point is not the abbreviation of "HTML". Name it whatever you want. The point is that it's really limited at what it can and can't do. Why would somebody use it when they're gonna use JS for even the slightest more complicated thing your language doesn't support anyways?
A couple points
1. "What you already know" is not a valid argument because if it's a better way, then people should have learned this way from the start.
1.B. You should be learning new things as a software developer.
2. You don't wind up using JS anyway. Becuase point
3. You still write this out in some kind of server language to provide the html. They don't show examples of it because they aren't prescribing what that looks like, but ultimately, that's where the writing will be done is on the server, and that's a good thing. Less worries about an extra layer of client caching
@@Jabberwockybird
1. "What you already know is not an actual argument"? Why? If I already know how to solve a problem easily in Javascript, why try to solve it in a new language I don't know that doesn't seem to provide solutions for so many other problems anyways? Like HTMX doesnt provide reactivity, state control or anything. That's where JS comes anyways! Either you use HTMX or not. Like you're not escaping Javascript, you're just pretending that you escape it for a while until you don't.
2. You're gonna have to use a server either way, either you use HTMX or not. What's your point exactly?
@@exapsyOne problem is a personal problem. You should check yourself before you wreck yourself. Only then would I bother continuing with you
🤔
javascript was a mistake.
This is bad, i hope i dont see htmx in near future srsly i hate this.
AGREE
Why though?
@@bioburden doesnt scale well , doesnt provide clear execution sequence, no debuging when screwing up , doesn't provide separation of concern ie behaviour separated from view,
Idk about security concerns that htmx comes with.
@@bioburden cont. I think something like that is already present angularjs,
@@lMINERl And let me add endpoints returning partials of HOW data should be displayed instead of data itself is problematic if you want to use that API for inter-service comms or for building another UI; HTML attributes seem nice and clean until you have your templates fully polluted; you lose data/UI reactivity, if you change data you have to remember which partials to return AND swap in the appropriate places, if you have little elements scattered across the page (say 4 UI elements) you have to remember to return the partials of all 4 AND specify where to place them based on DOM IDs. Why would you prefer this over those elements being updated by a framework when the data changes? Its literally the pubsub pattern that saves us so much work.
So slow
my heart rate goes up whenever someone uses vim unironically
i love vim
Emacs
maidenless
Microsoft notepad
ok , waste of time....
waste of watching this video
You think ocaml is readable?
O camel my camel!