The Truth About HTMX | Prime Reacts

Recorded live on twitch, GET IN
/ theprimeagen
Reviewed video: • The Truth About HTMX
Channel: Theo - t3.gg | / @t3dotgg
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact
Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))
turso.tech/deeznuts

[@bobbycrosby9765]

I've been doing things the way HTMX does it for about 15 years now and have never touched react. Apparently tech is cyclical, and if you're a lazy boomer long enough you become the hipster.

[@CallousCoder]

That’s so true I’ve noticed that as well after 40 years programming and 30 years of professional IT.

[@cholst1]

React is hot garbage, praise yourself lucky. Only cultists enjoy it.

[@LoneIgadzra]

Ditto. I have nothing against front-end code, love writing it, and I think typescript + JSX is really quite a nice experience, it's just a complete waste of time for CRUD and a ton of internal SAAS apps. These tools never needed React, and never will. I am continually frustrated by the pointlessly over-complicated approaches developers take for this stuff, not understanding the advantages of the old way, and how little effort it requires to make it a lot more like a SPA, rather than going full SPA. One issue I have with Theo's video (and this moment in general) is I don't really see HTMX as a big improvement over LiveView or Hotwire. It's just one particular take, but simplifying XHR calls is a big win.

[@jordixboy]

bruh, Ive been saying this shit all the time and im 10 years in the industry. Isnt React on the server (SSR) the same thing what we havbe been doing with PHP 20 years back like WTF and now people preach it

[@spicynoodle7419]

I'm new and always hated when someone just gave me a CRUD object like a logged in user and an order object. The order has status of "In Delivery", so can I cancel the order at this point? Who knows, maybe ask the other team overseas what the business logic is and replicate it on the frontend. CRUD and inferring state has been the biggest pain I've experienced. Even when I was designing both ends of a site. I simply didn't know better. HyperMedia as a protocol and task-based UI (as opposed to CRUD) makes everything so much easier and shit doesn't break all the time when business logic changes.

[@xdman2956]

as a dev in poland i can confirm that i am in poland and i sleep half the time

[@tomaszsikora3221]

😂

[@GreyDeathVaccine]

Backend dev from Poland here 🙂. Did work with U.S company. Having meetings with client at 3 PM (my local time) and client just woke up was source of funny moments

[@TurboBorsuk]

I feel for the team in Poland, they didn’t realize they worked with a genius.

[@Satook]

This is the clarification we needed 😂

[@Drawdek]

Future dev from Poland. How do you sleep? This thing is too complicated for me to comprehend

[@stuglass]

As a frontend developer, waiting for the backend team to make api changes is how I find time to watch these videos. Why change that?

[@Daijyobanai]

Is it finished yet? There is no BE. Is it finished yet? Basically GOTO 20.

[@languagelearningexperience6814]

I feel attacked... 😂

[@suchislife801]

Does anyone else find it extremely annoying that whenever this specific guest joins he CONSTANTLY interrupts Prime by saying: "Yup. Right. Yup. Yup. Yup. Right. Yup. Yup. Yup annnnnd... Yup. Right. Right . Yup. Yup. Right. Yup. Yup. Yup. Right. Right. Yeah. Yup. Right. Yeah. Yeah annnnd... Yeah. Yup. Right. Yup. Yup. Right. That and he CONSTANTLY FUCKING BOUNCES in what I believe to be a God damn Yoga Ball never really being still throughout the ENTIRETY of every Prime Video he is in? God DAMN that's annoying.

[@xnoreq]

That's an invalid argument anyway. If there is no backend functionality e.g. to query the state of an order then how would you render that unavailable state in htmx? You can't. Backend functionality has to be there. And if you're telling me that you can extend the backend with functionality that renders the state in html then why can't you offer it through the backend API, which is even simpler?

[@docgonecoder]

Not me in this exact same situation lmaoo

[@Stabby666]

About the "nobody did single page apps before jquery" - Fun fact, I was writing arcade game clones, and single-page apps back with IE4 and NS4. I pulled data in using hidden s, and DHTML for animation. I wrote a bunch of games, Galaxians, Tempest (using VML), Frogger, Pacman, Pengo, Donkey Kong etc all using the original arcade graphics and running at full framerates :) I then got a cease and desist from Nintendo and had to take a bunch of my games down. This was over 20 years ago...

[@metaphoricallyalive8109]

Dayum bro, you were the Man

[@GeneraluStelaru]

Legend!

[@Stabby666]

@@GeneraluStelaru Oh forgot to add I also did some multiplayer games, like video pool so people could challenge eachother. The games engine I wrote (open source) had functions to add multiplayer easily using the my site at the time and we had a really active forum of games developers - I hosted their games on the site for free. The main reason I ended up shutting it down was because the hosting costs became ridiculous as other sites were linking directly to the games. I also had chat channels that became really busy, it all used JS and then Perl on the backend at the time. Good days :)

[@rtsa4633]

Damn that's epic :o

[@deniyii]

So many Legends lurking in primes community

[@JasonEmanuel]

"Let the man cook." Pauses every 15 seconds 😂

[@nyahhbinghi]

haha

[@00jknight]

How does Prime fit 40hr/week at netflix, streaming for a ton of time, being a dad and going to the gym into his schedule?

[@perc-ai]

He prioritizes health so he has a healthy body and mind to do all these things

[@bobbycrosby9765]

@@perc-ai lol. That doesn't really help. He's talked about his schedule before and the answer is some combination of: he doesn't need as much sleep as many of us, he works from home, and he has a significant other that can help with much of the house/childcare aspect of things while he's busy streaming/etc.

[@danielsharp2402]

It's quite likely he also doesn't work 40h exactly as almost no dev workplace requires that if the tasks are done.

[@perc-ai]

@@bobbycrosby9765 bro cut the bs you do realize health is key right? you think he gets 5 hours of sleep or something lol this dude has streamlined his life so well hes able to do all this stuff. Health sleep wife/kids remote job all of it comes into play to understand how hes so alert it also helps to have an iq of 140+

[@IgorGuerrero]

@@danielsharp2402I'd say 99% of jobs are not like that, you need to be green in the chat and available for any issues or chats...

[@CraigMcNicholas]

There are quite a few points about the "backend defining the actions" or "it's already done on the backend so why reconstruct on the frontend" but the crux of this is poor contracts between front and backend. Almost all of my experience has involved multiple clients talking to a source of truth e.g. multiple native apps, machine to machine integrations, web apps and microfrontends. When you have to serve multiple clients the contract is the most important thing, not whether you use a backend first or frontend first framework.

[@moneymaker7307]

Roy Fielding did a poor job explaining the concept of a restful service. He never managed to get people build restful api the way he imagined. HTMX is moving people towards the right direction, but the root cause of the issue is poorly define contract on the backend.

[@stefankyriacou7151]

One thing I like doing depending on what i'm building, is to build a backend in rust with axum and askama, then load htmx and twind from a cdn; that way you're basically guaranteed to never send more than around 20kb of js + css to the client, then all your ui is just declaratively embedded in your html template.

[@wrathfulbear-5630]

When I look at the world of front-end development, I sometimes get the impression that the hype pushes to always reinvent the wheel by creating ever more complex ways to do the same thing but differently...

[@mornwind318]

Not really more complex than just doing backend. What Theo is describing is basically doing TypeScript instead of PHP (which is a whole lot worse) and shipping that. Once your app is all either front or backend, there's no distinction anymore. It's both in two different languages.

[@doyouwantsli9680]

You're totally right. And throw away the benefit of the higher level systems use. For example, adding back compilation to these scripting languages

[@LoneIgadzra]

1000% agree with Prime's diagram around 31:00. That's exactly it, the point I have been wasting time making on Reddit for years. Having a full client-side state based on JSON is unnecessary duplication of state.

[@thewiirocks]

Exactly so. I do not understand why front-end developer do that. Of course, I also think SPAs are an utterly terrible idea in 80-90% of cases and that simple jQuery development with page transitions blows most SPAs out of the water.

[@ivanjermakov]

@@thewiirocks some leads prefer to have decoupled backend APIs, so that you can make a new frontend with ease, e.g. introduce a mobile client.

[@Gorillaphase]

@@ivanjermakovThat can be solved by having separate services for each client though. Mobile client calls mobile HTMX server that serves mobile formatted HTML. ideally though the load profile is similar so the same service could handle all the clients, just returning different HTML based on endpoint / API. Could still have a pure JSON backend service

[@danilomendes977]

​@@thewiirocksbut... Htmx is SPA.

[@danilomendes977]

When working with frontend frameworks, you don't need to have the application state in a set of JS object. You can, if you prefer, just apply a template from the responses of the server (which is better than html payloads). This is an architectural concern that htmx enforces but can be done with frontend frameworks.

[@ayyoubkasmi3871]

This is a really profound video for me who's just new to these stuff. Really awesome!

[@ferdynandkiepski5026]

How does he manage to make a reaction to a 12 minute video last 50 minutes. Truly a talent many KZbinrs would like to reach the 10min mark for multiple ads.

[@Zuckerkome]

at least he doesnt just sit there and watch the video with nothing to add like many reaction streamers/youtubers do

[@impossibur]

So he's basically Asmongold

[@dermuschelschluerfer]

Im so glad I discovered HTMX on your channel. I never liked the complexity of frontend frameworks. Or why Frontend even requires so much work since logic and state should always be on the backend. I just want to display the stuff that is already there.

[@alang.2054]

Ekhm... Php is there for 20 years...

[@ajbrady4357]

@@alang.2054 but php wasn’t as good as other languages in the early 2000s!! Completely unusable in modern day bc it hasn’t had a single update since then smh my head it’s exactly the same

[@simm0l]

@@ajbrady4357 wait what? Not the biggest fan of PHP (used it enough to know its not for me), but what you're saying is just plain wrong. 1st Good as what other languages? PHP was originally template language for WEB - giving possibility to make from static HTML a Dynamic HTML Server rendered pages (yea a the new FE things :D ) when mixed with JS (the vanilla flavor or later JQuery) together with ASP Pages from Microsoft was one of the pinnacles of the Web development. 2nd PHP is well they are at their 8.x version now - yea its not moving as fast as JS frameworks 20 versions per week (which is a good thing actually). So love it or hate it one thing, want to use it or not is another, but its not fair to say its dead or not suitable for modern use :)

[@ajbrady4357]

@@simm0l my apologies I was being extremely sarcastic

[@xnoreq]

Most of the arguments made in the video are invalid. The idea that "with htmx there is no state at the frontend" is simply false. Let's say you make an order and the backend sends you "Order in state: Processing" and an enabled "Cancel order" button. That is a state, and it will diverge from the backend state over time. Because the backend will process the order and change its state possibly to a state where cancellation is impossible. So the backend logic has to check for invalid actions resulting from invalid frontend states anyway. So state-wise you haven't changed or fixed anything. And the backend logic that renders the enabled "Cancel order" button will still be distinct from the logic that handles order state transitions. So you haven't unified logic either, you've just moved it to another place. And it's not better in that place anyway. The same info that you will use in that backend logic to determine what the next valid/possible states are could just as well have been sent to the frontend.

[@ChrisPatti]

This is my favorite reaction. Video of yours! You make your points eloquently, and with a modicum of screaming :-)

[@MichaelMammoliti]

I once got asked in an interview "class components or hooks" I was like: "class components are more straight forward, useEffect and useState are bloating the code and make it harder to read". I started coding in React in 2016 and.. I did not get the job, I was still loving componentDidMount etc but understood what the market was after and the direction that react was going towards. I ended up loving hooks, but now I am doing Svelte.

[@donnybystrom]

An htmx backend seems cool! Really snappy and intuitive for its purpose. But eventually in your business growth it is time to build a mobile app. With a backend spitting out html instead of data, how do you handle that with an iOS/Android/Cross platform app? I might not get the whole picture here, but it feels like kind of a technical lock in to build a backend that focuses on producing html documents like back in the days.

[@abdelazizlaissaoui9079]

Great point!

[@_rcs]

That's a good question.

[@pranavraaghav5570]

Ideally, business logic should be de-coupled from the delivery layer (HTMX in this case). If the business then wants to build a mobile application, we build a separate delivery layer (say, REST) and re-use the existing business logic. It may be more work later, but it makes HTMX seem viable if the business is unlikely to go for a mobile app anytime in the near future.

[@roshandx1]

maybe use the BFF pattern for this, split the views for web and mobile

[@MrMeltdown]

@@LePetitMondedePurexoYT Agreed. I log in to ebay and facebook using the browser on my phone, just cause I don't want yet another app nagging me for permissions to read my e-mail contacts etc.... It is amazing how many of the big websites struggle with all of this regardless of the responsive layout stuff. There is almost always something that can't be done on the mobile web version that requires the app. When an app may not technically be necessary AT ALL......

[@dexterman6361]

Wait a minute this looks like what I did (used to do?) with C# and XAML for UI. I always wished it was like that for the web too. Never got the hang of react. State management seemed so complicated and stressful. Nice, HTMX. Gonna check that out. I was actually floored with the other demo that you did a video on. The article loading thingy

[@FabulousFadz]

Hey... another XAML user. I loved working with XAML and when I crossed over to start working with web stacks, I felt how broken a lot of these things were. I ended up using Blazor to use the same language in the front and back. Now that I'm using Go, I needed something else to do my web frontends when I need a front end (not going to bring in C# and Blazor right now) and HTMX is a godsend. I'm sure you'll enjoy it.

[@KonradGM]

this is my issue with React mainly too. I did a lot of es6, jquery etc, and dabbled in few frameworks a little bit. I've come to the field late, graduaded like not too long ago from uni. And looking at a lot of the web dev stuff, i feel there is a lot of dev glasses what i could say. I fully understand why React is used, since writing anything in plain JS/Jquery when it's complicated and animated interactable element can get painfull and hell to manage, but at the same time, i aggree fully with Prime, with that React abstracts soo much to the point where you start to think "React" instead of thinkg webdev. Another thing i feel is there is just this emotional burden that makes people feel certain tase on frameworks where despite very often them being good at the same things, they will tribal to gating something. I don't have strong attachements to it or Angular, but at the same time i don't understand the Angular hate since both generally feel "simmilair enough" to me(would probably feel the difference on something more complicated, not arguing there), and it's hard to not think, it;s the issue of if somethings a hammer, everything becomes a nail.

[@happyaccidents156]

This is why I started to learn Svelte. When I was introduced to React, it felt like I just had to throw out all the HTML, CSS, and javascript I had learned previously to learn the React way and then learn the React ecosystem, but the react was didn't feel applicable to anything but React.

[@anxpara]

At this point I've shoved most of Angular out of my memory cause i hated it so much, but i remember it feeling super clunky and cumbersome, with poor documentation. Every simple thing i wanted to accomplish would take 4x as long as it should have in Angular, it was constant wrangling. I switched to Svelte and i love it; Svelte is what i wanted Angular to be.

[@erickmoya1401]

Svelte solves all these issues. Feels like an easier version of vanilla web development, not different. I even use plain css everywhere instead of adding more.

[@somebody-anonymous]

Just my 2 cents, I think that while state management is a good concept, using a single word "state" to shoehorn every single value/variable/cache/element into a single concept and then trying to say general things about that (and only that) can also be counterproductive. In prime's example of the game of life, it might make sense to talk about the "client state" for things like what the currently alive cells are, while at the same time acknowledging that things like managing your "savegames" bring with them the challenges associated with managing such state for which ultimately the backend is the source of truth (assuming for the moment that thats where the "savegames" are stored). It would be counterproductive to either require all the state to be a reflection of what the backend knows, while at the same time it might overcomplicate design if what savegames the user sees in their "html" cannot simply be seen as a reflection of the data in the backend

[@LusidDreaming]

We all know the proper way to synchronize state is call GET /entire-application-state every time a user interaction happens and also in a 50ms polling loop in three different places. Make sure you're calling this server side and on the client and hydrate redux with deep copies of the response so that spontaneous renders are constantly happening.

[@BudgiePanic]

Online multiplayer video games be like ☝️

[@draakisback]

Personally I think the way that Phoenix liveview does things is the best way. It's a two-way binding between your elixir app and the so-called client which is effectively just a web socket. You actually don't even need any HTML in your project (outside of the root template). The state is maintained by the processes and elixir has some extremely powerful fault tolerant tools to keep things synchronized. As such you can just have a single process with the state and you can use the pub sub to proliferate the state out to the clients, It's inherently simple.

[@madlep]

Ryan Winchester fighting the good fight in the video.

[@simonricard4403]

Yeah, what makes Liveview different is that the state is all server side. This makes it a joy to work it from the backend (speaking as a full-stack dev)

[@NoidoDev]

Don't even need any HTML in your project? But what would I still have to write? Does it generate the html and css?

[@madlep]

​@@NoidoDev "don't need any HTML" isn't quite right. There's still HTML, but there's no front end JS code at all. It's all server rendered HTML, with server side logic. Templates are rendered fully hydrated on initial load, then dynamic content is updated by re-rendering the partial templates server side, and sending the minimal partial diff over a websocket. The workflow is that you're just working with plain old partial HTML templates in one place. Very high performance, good SEO by default, and don't have to have separate server and client side code, so is quicker and easier to write, and much more maintainable. There’s a client side JS library to load, but that just does the Websocket and DOM updating logic, and is tiny (like 80kb I think) It’s like of server rendered react components but… done right.

[@NoidoDev]

@@madlep Okay, sounds good.

[@achrefnasri8847]

for me no other js library was exciting to me like JQuery of old it will always be my sweetheart she never complains about your setup never argue with you about your build preporcessor or packages. i curse the days i switched to React because it was "cool" and "new girl in the bloc" but now HTMX is like my mistresse reignited my love for simple CDN libraries that have the same montra "CODE LESS..... DO MORE"

[@D4ngeresque]

We are so back.

[@cabanford]

I totally agree. Am willing to take a solid look at htmx and how it would fit into my little mindset

[@ahallock]

What's good about React isn't React itself; it's the ecosystem around it. It's become very difficult to create modern UI components with accessibility without using something like RadixUI. Tailwind is creating Catalyst to compete and it's React-based. For example: a dropdown that responds to keyboard events and changes its orientation in case it's getting hidden. Good luck doing that with HTMX without a lot of custom JS.

[@adriengrsmto8658]

Exactly. And that's why companies still choose React for any new projects. I worked with companies choosing Svelte and it's consistently because they don't care about things like accessibility.

[@hba6018]

WebComponents my friend, htmx is standard friendly. 🤷‍♂️

[@Jabberwockybird]

Ecosystem is a poor argument. Angular also has an ecosystem around it. A company can build up an Ecosystem to support anything they use. HTMX can have an ecosystem too. But people really should have a mindset of thinking what the existing html standards support before reaching for something external.

[@gabrielnuetzi]

Very nice take about how you see it as a state problem, even I with not much web dev knowledge can 100% agree HTMX seems to reduce state sync problems and how you described it with the delete button was nice!

[@laloqf]

You can do that with JS why don't wait for the response before applying the change

[@colemichae]

Love your version and a better explanation, business logic stays on the backend just use the front-end to display the actions in progress. Based on a high speed network it's great.

[@W1ldTangent]

For internal apps that really don't need a fancy UI with all the bells and whistles as long as it works, and one would hope adequate network speed, I can see it being a significant time and effort saver for the developer.

[@xnoreq]

It's also nonsense. Most of the arguments presented are invalid. In reality you haven't eliminated frontend state and you also have not unified business logic: Let's say you make an order and the backend sends you "Order in state: Processing" and an enabled "Cancel order" button. That is a state, and it will diverge from the backend state over time. Because the backend will process the order and change its state possibly to a state where cancellation is impossible. So the backend logic has to check for invalid actions resulting from invalid frontend states anyway. And the backend logic that renders the enabled "Cancel order" button will still be distinct from the logic that handles order state transitions. So you haven't unified logic either, you've just moved it to another place. The same info that you use in that backend logic to determine what the next valid/possible states are could just as well have been sent to the frontend.

[@colemichae]

@@xnoreq it not just logic in the process, but rules, logical I can sell to you in any country but others have the Asian Pacific rights so I cannot deliver there for this product. We see that daily with netflix this is not allowed in that country or region, do we allow a front end overrule the backend.

[@xnoreq]

@@colemichae That is business logic. Just because it includes the word "logic" does not mean it is limited to the classical/mathematical understanding of logic. Business logic may, in fact, contain illogical rules. To your example: First of all, when dealing with rights, this has to be done in the backend anyway, regardless of where you do rendering. You cannot trust the input of the client (which includes its state, rights etc.). The backend can simply deliver a list of valid/possible countries the company can e.g. ship a product to. The frontend can then render this list of countries however it likes. The backend also has to figure out where the user is coming from using an IP geolocation service. You cannot trust the user's web application or browser/operating system settings. If it turns out that the user is in a country where the company holds no rights to sell the product then the backend simply will not include that product in the data response (or include it with a NotAvailableInYourCountry flag if you like to render it in the frontend in a disabled state). The frontend should never ever be able to overrule the backend.

[@harshsharma1828]

When he gave the example of todo on client state (optimistic update) which is actually sort of better with the use of react query in react but htmx seems really good to avoid duplicacy in the first place.

[@clamhammer2463]

You remind me of Uncle Reco. "If Falcor ever took off I'd have been someone!" "I bet that I could throw this API over those mountains."

[@yurcchello]

so, htmx is just lightweight good old frames. amazing innovation

[@depafrom5277]

LOL, yes without the frames

[@alexpyattaev]

An interesting angle here is that the amount of traffic to serve a given number of clients can be substantially reduced if you send protobuf to a wasm frontend as compared to html/x for every click.

[@davidjdriver]

But does saving those few bits ever offset the 5mb of JavaScript that it takes to parse, hydrate, and bind that data to the html?

[@alexpyattaev]

@@davidjdriver that depends on the session duration. If your user spends 30-40 min on your page doing stuff, maybe 1-2 MB of burst bulk upload is cheaper than thousands of tiny requests 1-2 KB each.

You will love the paper "Out of the Tarpit". BTW, that paper inspired Clojure. Highlights state management as top priority issue in Software development.

[@brianchandler3346]

OMG, how did I miss HTMX? Trend of near always connected will continue. Solutions over the past several years always felt like temporary fixes to me until offline is a thing of the past. Will have to try this. One of my old mentors told me when PHP vs ASP was a debate that we moved from thin clients + server -> move it all to desktop with thin server -> back to thin client, but now it's the browser and not the full system that's the "thin client". I feel like after he pointed that out that it's still playing out, just at a slower pace than we had figured.

[@ThePandaGuitar]

I was doing htmx 10 years ago with my own attributes "my-post" "my-get" instead of "hx-post" "hx-get" and engineers were shouting bad practice 😃 Programming is just fashion.

[@n4bb12]

I didn't understand what you meant by caching. What would be an example on frontend state resulting in a caching problem that server state would solve?

[@bobbycrosby9765]

In most apps I've worked on, the front end state is just a cache of the back end state.

[@kabaduck]

Fantastic video guys, I totally get why you want to use HTMX now. I'm 100% sold and will use this technique from here on out, my biggest struggle was going to be learning how to get JavaScript libraries that were designed for the client to work on the back end and then send it to the client.

[@Xefer]

are these (this and the last vod) reuploads? or did I just watch the live and forget?

[@nomadshiba]

i have made this point before 44:00 htmx is really good if you have lots of permissions and logic and not everything as public. i totally understand this, i have worked on projects where people just keep asking for dumb permissions on who can see what with lots of backend logic. validations and syncing can be a pain, but if I just had htmx back then, everything would have been 1000x simpler. i mean i would literally need 0 js. literally. i wanna use it. but if you have everything as public why spend time querying the db, generating the html then sending the html. while client can just query the db and generate the html itself. run the logic itself, invalidate bad data itself, and never ask for a permission. why not just have a dumb server. so i agree

[@macctosh]

This my approach to webdev... in the long run I want to do as much logic as possible on the front-end than on the back-end. Why? more resources on the front-end. it's just that simple user's PC/Tablets and Phones as insanely powerful, for an indie developer like me server resources are severely limited

[@Beysl]

If the html us public, you can probably cache it. If you can‘t cache it, well, you have to generate the data either way. Rendering html vs rendering json should not be a huge difference either. Same for the size difference if sending html vs json.

[@ba8e]

@@macctosh This is a great point!

[@elzabethtatcher9570]

In his story about music service, it sounds more like his company had especially bad team of backend devs, or their backend stack was bad for their use case. In no way a technology change can singlehandedly make one Theo backend dev replace 8 backend devs.

[@peerlesstuber9693]

"HTML/Template and Go" at 49:12, where should I be looking for templates (any site recommendations)? Also is go referencing the language or just getting started with HTML/Template?

[@automatic241]

I basically wrote a super simple version of that when I made a pretty bad web server framework in Rust. I really love htmx so far.

[@ddomingo]

Absolutely, using React since 2013 is way different than using it since 2018. The shit the rest of us have had to go through. Dark times for the frontend world that made me miss jQuery every day. I avoid React as much as I can because of that 2013-2014 era.

[@majpay]

Doing web dev since ~2005. Had some adventures with (P)react, vue and other technologies. Always went back to mostly hypermedia because it burns less time/money. Currently my apps consist of native custom elements, hypermedia and some sprinkles of js modules here and there. BTW i mostly code PHP - take that fancy framework kiddos 🎉

[@benbowers3613]

What if I use php AND a framework? 😈 (Laravel + AlpineJS 💪)

[@majpay]

@@benbowers3613 i add petite-vue if i need that kind of client side reactivity 👍

[@parihar-shashwat]

me Laravel with inertia. Its so piece of mind with unnecessary state management in frontend

[@Definesleepalt]

Gigachad PHP dev

[@annaanna3260]

​@@DefinesleepaltI use arch btw

[@_ncko]

How does this play out in applications with web-based _and_ mobile frontends?

[@FranciscoJAceves]

Disclaimer, I'm currently mostly a frontend React dev but I also had a lot of experience on Java/Kotlin backend. I haven't used HTMX but it sounds a lot to how we structure the code at my place of work in the sense that the BE isn't just an endpoint to get data but it actually tells us what we have to render and then we just render it, the biggest problem that I've encounter with that approach is that it creates a very tight dependency on both ends, we in the frontend cannot change anything before it going through te backend so we usually have to wait for them to finish their implementation or have to agree beforehand on one and then start coding; and the backend cannot change anything that affects the frontend (returns, endpoint interfaces, types) without getting our approval first, or else it could break the frontend.

[@NexusGamingRadical]

I prefer the Astro approach where everything is HTML (to the client) untill you want an escape hatch. Everyone wins in this approach.

[@depafrom5277]

100%

[@sokacsavok]

Great to see HTMX finally reinventing Ruby on Rails! It just took 19 years. We are back to square one.

[@W1ldTangent]

Except you don't need to write Ruby. So I'd call it an improvement.

[@sokacsavok]

@@W1ldTangent Yeah, if you don't like programming / software engineering just knowing HTML can work out up to a point.

[@erickmoya1401]

​@@W1ldTangentjajaja you get the point.

[@W1ldTangent]

@@sokacsavok I use other languages, have tried Ruby/RoR as well and just never saw what others saw in it. There were many better languages and frameworks then, and even more now.

[@sokacsavok]

@@W1ldTangent You mean like Javascript? A language where '2' + 2 = 22? I never got why others didn't see the benefits in RoR, still nothing has come close to it. Ruby is stable, flexible, consistent and great language. Rails is mature, well thought out, easy to use, just needs some learning.

[@orzumirzayev6630]

What about when we want to keep some state when network goes down, but we want to keep the app seem like working as there is network connection. And sync up the state in two place to sync when network becomes available?

[@dzmitryluhauskoi6363]

What about the cost though? With a nowadays stack we make the client do lots of calculations instead of our server (rendering) and minimize the cost by providing a minimal API. Am I missing something?

[@AScribblingTurtle]

37:10 : What technique to employ heavily depends on your use case. Having a throbbing (probably long 😏) loading bar is not always the best solution. Although it is the clearest and most understandable in terms of what is happening, it comes at the cost of responsiveness. If you have an app that needs to work in a low/none reception area having to wait for a Server response can be quite agonizing. Think of a package delivery service that needs to take in signatures in a Village at the ass of the world.

[@asdfghyter]

as long as you make sure that the rest of the app is still responsive during the throbbing, it should be fine. the main context i can think of where it's a problem is if you create a new item and need to wait for a response from the server before you can start filling it in. in that case you need to greedily make the item. though, i guess it can also be an issue when you want to edit a thing again after having changed it, but before the server has responded to the first change, which is kind of a tricky situation to sync properly, but can also be very annoying for the user. a typical example of this is a "like" button, which you might accidentally tap and then want to undo, but can't do it until the server has responded to the first tap. so i guess in the end, the only part of CRUD where it's not annoying to experience a long throbber is the D

[@n4bb12]

Failing optimistic updates are an edge case, not the majority case. Which one should we optimize for? If an optimistic update fails, you can recover from it by keeping the previous state until the server responded. Or by refetching the state. Libraries like TanStack query have both strategies built-in. Or you just wait for the server depending on the case. Then there's all the client-only state that the server doesn't even know about. Like the tree expansion state of a tree view that every client has its own instance of. Why do that through the server?

[@JamieAlban]

it seems reasonable to me that there is client state that the server doesn't need to know about. I guess when the client is directly reflecting state from the server though, server side rendering could make more sense because you avoid duplicating the data structures? (I'm new to all this but just trying to wrap my head around these discussions)

[@macctosh]

For me I feel like people who are in the HTMX camp don't want or don't care about UI/UX in the long run! I am really curious how easy is it to change or add features in HTMX two years into development

[@catalintudorciurte309]

​@@macctoshNot every app is in perpetual development

[@macctosh]

@@catalintudorciurte309 if paying users are using your app then it's in perpetual development (ci/cd) or your paying users will go somewhere else.

[@bebel4298]

2:09 In Laravel, you can do the exact same thing wih Livewire. It's the same process: Laravel generates an AJAX request that fetches the output of a PHP script on the server when there is a need to update the frontend. And it does not refresh the whole page. It's been there for a while now...

[@depafrom5277]

Yes, Livewire just does it better

[@GreyDeathVaccine]

@@depafrom5277 But Livewire is vendor lock. You can combine HTMX with any backend, not just in PHP.

[@ishaanmalhotra3008]

Would you say HTMX is a quicker, easier option to Svelte in combination with a backend language like Go?

[@Michael-kq3qm]

For years, I've contemplated diving into the world of React, Vue, and similar front-end libraries/frameworks. However, it often appeared that these tools required a substantial amount of setup and configuration compared to what I could accomplish with Django sessions in conjunction with Ajax or HTMX. Strangely enough, I've consistently found that my web applications and sites remain just as snappy and interactive as those built with React. It's possible that I might be overlooking some key aspects, but I can't help but wonder if the perceived complexity of these front-end libraries is sometimes unnecessary for achieving impressive performance and interactivity on the web.

[@vripiatbuzoi9188]

I had the same concern as you and why I picked Vue over React. Vue requires no setup, not tooling, nothing (unless you want that). Can be integrated into any existing architecture no matter how legacy without a problem since it's so stand alone. Got Vue working in no time with an old but very large site built in WebForms which would be completely incompatible with anything else.

[@nanonkay5669]

Man I so agree with this. It's so nice to not have the JSON layer ie from frontend to JSON to backend to JSON to frontend. In between things can go wrong. And just to sync state and data, you need things like redux, RTK query, sagas, react query, for navigation it's react router or whatever solution etc. React has been relying on so many 3rd party libraries that try to solve bridging the gap between Fe and be. And these are just not simple libraries, they're whole concepts to learn to even use right. But a stack like HTMX, Alpine.js, Tailwind and maybe Go for the BE can potentially get you so far

[@the-white-fang]

But most of the times you are creating products, which means you are creating API's and now the frontend becomes just a part of the product and you might have a for example Android/iOS app. Now you need those state tranfers to those applications as well. And we are back to using JSON. It's hard to do right, everyone struggles with it. But, it is a devil we all have to deal with.

[@nanonkay5669]

@@the-white-fang yeah you're right, for mobile apps or apis to sell, you kinda don't have a choice but to use JSON back and forth and do all the gymnastics for caching, routing, etc. But if it's a full stack app in which the BE and FE are tailor made for each other, I don't see a reason to not fully couple the BE with the FE like with HTMX. The rest is unnecessary overhead and complexity

[@the-white-fang]

@@nanonkay5669 I completely agree with that. Use whatever best suits your needs. HTMX seems really fun and I hopefully will get to try it out someday.

[@ryandsouza2962]

How would the API look like if I have to support web and mobile apps? Would it be supporting HTML and JSON responses both via the same endpoint?

[@maninalift]

The htmx approach of swapping html seems similar to couple of frameworks from the functional world that have been around for quite a while ocsigen from ocaml Something from haskell that had a name with "monad" in it. Something catchy like "mmonad"

[@gritcrit4385]

I think that the components+reactive direction is good. React is just a part of an evolution towards that direction.

[@catalintudorciurte309]

Yea, looks like Angular was right all along

[@ba8e]

What about 3rd parties using the same API as your client app? With HTMX your API doesn't exist?

[@benjaminbras7475]

It does it just actual REST, but yes if you need a RPC "data" api then it doesn't

[@yuryzhuravlev2312]

With SvelteKit you can also avoid future state and you can use the same server state reflection by load function. But HTMX have other issues - concatinate server response, in the worse case we a re back to server templates.

[@MatejMachac]

I went from PHP frameworks with vanilla JS to jQuery, to React, to Vue (I choose to not count Angular 1 and 2 as memorable), only to now be happy to get back to vanilla JS inside of a project based on Shopify Liquid.

[@j-wenning]

Django Unchanged

[@dissident1337]

The problem with the practice of front-end frameworks like React is you're offloading more of the work that can be better handled by specially-built server software onto clients that are a lot worse in processing power and have to do a lot more HTTP transactions to make up for not repeating yourself a bunch of times in backend services. Progressive enhancement should have been the goal, but there's a lot more thought necessary to implement it properly, and companies loathe paying any kind of debt, especially tech debt.

[@PelFox]

What if you have state across mutiple components in the view? Can you use HTMX for that as well? Example, you are on a page deleting your todos but you also have a total count of todos in your navbar. Now that count would be off unless you re-render the whole page?

[@mattfletcher]

This is 5 months too late, but no. You can send an OOB response with the main response. I think the attribute is hx-swap-oob and any elements you include in your response with that attribute will replace elements with a matching id anywhere in the page, outside of your main response. It's designed for exactly this sort of thing.

[@edwardtam1456]

Having frontend as a pure reflection of the backend state is good, but there are certainly usecases for frontend states approach as well, e.g.: - applications that don't have backend state (e.g. excalidraw) - applications that have a lot of interactions that making a call to the backend on each interaction is impossible, in which FE acts as an aggregator to batch the state changes before sending it back to the backend I do agree that majority of usecases don't actually require a frontend state.

[@donkeyy8331]

he did show that even in those cases HTMX is usable and easy, Game of Life is kinda the ultimate client side state machine.

[@mattrs1]

But at the same time the beauty is that with htmx you can freely use sever-rendered html, json and client state (react). So not only allows you to things on a simpler way, but allows you to easily mix methodologies and frameworks as suited.

[@branislav3800]

One thing I don't like about this channel is when it's comparing apples to oranges. I understand comparing technologies that do the exact same things. However, in this case React and HTMX can serve different purposes, and both offer capabilities depending on the use cases. Just choose the tools that are specific to what you working on. It's good that we have all these different options.

[@georgeokello8620]

The most generic answer ever without understanding the problem. The comparison issue of apples out orange is warranted when you have a problem domain and the solutions and trade offs are either going to benefit the Apple or the orange. You are randomly throwing randomized quotable in a careless manner. An Apple can be compared with an orange of my damn use case or problem is clients want Apple pie and not damn orange juice. Same thing is when you work in a new company with millions of dollars on the line to solve an engineering problem with its constraints and you have to make really great comparisons on what helps progress the product.

[@grinsk3ks]

htmx seems cool for many use cases. What I like about frameworks like nuxt is that you write your components once, you get an amazing template engine, code splitting is done for you. I can totally see it working with nuxt server components.

[@natetronn]

The question crossed my mind, "is Nuxt really the middle ground between htmx and react? The best of both worlds, so to speak?"

[@MariusEidem]

I made a webpage with EJB and JSP tags once. For some reason I have long since suppressed I ended up having to serialize objects and send send them to the back end as cookies

[@burdenedbyhope]

I used a framework called Vaadin a lot 10 years ago, it took gwt to the next level by having all the states to the server. Gotta check it again to see what they become after 10 years.

[@gerdokurt]

I think that`s way too many 80s porn mustaches in one 50 min video that isnt a 80s porn!

[@Gorillaphase]

As a dev working backend, Prime is so right about the insanity of maintaining states on client and server. Also something like HTMX will win purely because for every front end app there are like 10-20 backend services. Ultimately any backend server that needs some small UI to interact with it will adopt something like HTMX

[@straightup7up]

What graphics editor is that guy using in the video?

[@TheDahc1]

As a person learning to program, I didn't realize things didn't work like htmx and it just makes the most sense to me for things to work that way.

[@dandogamer]

I dont tend to agree with theo but I thought he presented a well thought out take.

[@ThePrimeTimeagen]

yeah! i think there is a lot there

[@based_gigachad6094]

Those guys look like the brunette twin and the blonde twin 😂

[@bobDotJS]

More like a competent engineer and a close-minded web dev

[@florentd.5817]

Small question. why htmx don't use correct html syntax ? With " data- "attribute convention.

[@Jabberwockybird]

Becuase a convention is just a convention, it's not syntax

[@dienand_]

I feel like client side state management is really only supposed to be an issue on mobile where connectivity might be intermittent. In a desktop environment it’s just adding extra unnecessary complications.

[@depafrom5277]

I agree with your core analysis and the problem which Htmx solves, and on paper it makes 90% sense - Until you try to build large apps with 100s of views and modern UX. Your current low-res experiments with Htmx is fine, now try integrate different clientside view components, transitions etc. into your Htmx on the client and see the mess you create. Its also very weird to hammer the server for every bit of html hydration - with SPAs or even Island architecture you can do a lot in the client and only at the end send the Json data back to the server. Your "greyed out delete" scenario is also moot, because it works even better in a clientside app, where your store/model is reactive on the DOM, so when your server responds after delete the store/model is updated. Htmx is fine for small apps with minimal UX expectations.

[@depafrom5277]

Hope he takes note :|

[@mac.ignacio]

ReactJS devs thinks everything is a nail.

[@user-ud8hw4gp6t]

12:46 graphsql can be used with a service mesh (or webproxy) running in a pod that can be reached via load balancer. so he saying graphsql is in the middle because both front and backend share an "api" (your protobuffs) that replace json and servers like flask

[@tankberry9820]

What drawing tool do Theo and Primeagen use in this video??

[@bielgaucho_real]

The issue with React is that managing states is complicated... and nobody wants to maintain the same logic twice in both the backend and frontend, but they feel forced to because our backend is used to responding just with just some basic data, so you have to derive state changes yourself when building the UI in there. Anyway, writing components(or declarative templates) is way nicer in most cases, so you'll end up writing them in the backend as well. Also, writing simple transitional states, like graying out something while the request is incomplete, seems to be the same effort for both HTMX and React, so I see no validity in your point around that. The real issue is that people write too much logic in client code, and have too much trouble managing states. Making Frontend a whole mess in the long term. HTMX is nice for simpler UIs and I give you that. But if people just focused on writing better backend code that can return decent state changes for the frontend, then having a Frontend framework wouldn't give us so much pain. However, if we do want to provide state changes from the backend, why not just provide HTML?

[@macctosh]

If you are maintaining the same logic twice something is wrong with your design

[@mfpears]

Spaghetti code, but _inside_ HTML? That's a recipe for success

[@spottedmahn]

Wow, where’s dark theme on ur game?! (Just kidding, seen you mention this on other peoples apps) Great take as always 👍

[@neptronix]

Great explanation, thanks for this

[@n4bb12]

Video games are not an example of server state. The game analogue would be sending the whole game down to the client (HTML analogue). Once you exit the game, there would be nothing left on your PC. Instead, games are pre-installed with gigabytes of data. Clients only exchange minimal data with the server. Some information is exchanged between clients directly instead of the server. Games will typically also have a lot of state and processing that happens on the client (games can be GPU and CPU intensive). The client only talks to the server to persist or load data, just like SPAs. Some singleplayer games are completely offline. The problem with server state is that raw state is not the whole app and visualizing it is something that fits better into the client and needs to be done close to the user.

[@jibreelkeddo7030]

HTMX should become basis for HTML6 spec, with but built in signing/checksum for requests from browser to prevent XSS attacks. HTML6+XSS protection based on HTMX will make webdev accessible for the noobiest noobs and truly allow everyone to "learn to code"!

[@alexandersuvorov2002]

There’s “onclick” attribute already… That’s reinvention of the wheel.

[@jibreelkeddo7030]

​@@alexandersuvorov2002 HTML is so simple a small child and perhaps even an illiterate person could write it. JavaScript is a big jump for those folks. Imagine if every highschool graduate was able to make a **bare bones simple** SPA, as naturally as they could do reading and writing? What would that world look like, if grandma and grandpa were able to host their own websites by just uploading a .html file to a Cloud provider like they would a pdf or zip file? Think big man!

[@alexandersuvorov2002]

@@jibreelkeddo7030 We’ve been through this already with Wix, Wordpress and Java. This idea of incompetent folks being able to produce anything beyond preconfigured framework demo’s didn’t work. We end up with crap code that propogates through the entire solution and ruins all the work by those who actually put hours into tech and quality pro-grade code. The whole existence of TypeScript is because there are folks out there who just copy paste code snippets from the web into the codebase without even trying to understand what’s in there. And lastly, no grandpa and grandma will be able to produce advanced frontend UI by just doing HTMX frontpage demo. They need to understand DOM and HTTP and JavaScript anyway, so why to force them study HTMX on top of that? Or do you expect there are businesses out there who would settle with basic HTMX code?

[@Wyklepheph]

Lmao, as an old school laravel dev who just wrote a robust and expressive templating engine for Nim, and also just discovered HTMX… I’m so stoked haha

[@RaveYoda]

Hahahaha, that burn on Web 3.0! Nice job!

[@k98killer]

The ultimate solution to state synchronization will be the use of CRDTs. And as soon as I'm done implementing them all in Python, I'm going to port the library to Go and then Dart. It will be beautiful. Edit: with CRDTs, any number of online and offline state updates are guaranteed to eventually converge to the same state once all updates are applied, regardless of the order of those updates or the number of times they are applied. CRDT updates are commutative and idempotent.

[@n4bb12]

The difference between these two viewpoints is what you optimize for: The smallest possible interaction delay versus keeping state purely on the server. The first benefits the user. The second is an ideological take. You can't have all state on the server AND minimal latency. What is more, the code I've seen from HTMX proponents and examples like the connect 4 app or the game of life demo looks like a couple steps back to me.

[@TheSoulCrisis]

HTMX is interesting and looks to be pretty powerful itself.....gotta build a toy project in it sometime, great video!

[@Lorofol]

I wonder how much of this is applicable to a react-native/mobile dev like me. Seems like this is really important when we're only trying to limit how much we send to a user through a webpage, but if we're already shipping the entire client then it's not applicable?

[@tcurdt]

It feels a bit backwards to move in the direction of htmx. I always thought offline-first (using CRDTs) was the next thing. But it does make a very old approach of writing webapps much easier.

[@TurtleKwitty]

How often are you actually wanting to use a website while offline?

[@alexandersuvorov2002]

What is CRDT?

[@gangsterism]

there is no need for such thing in 99.99% of all websites or web applications

[@tcurdt]

@@alexandersuvorov2002 www.google.com/search?q=what+is+crdt? 🤷‍♂

[@dandogamer]

I thought CRDTs was for collaboration software? Most stuff involves speaking to 3rd party services which involves online communication

[@gonootropics2.065]

Both these guys looking like washed up cops

[@JohnFallot]

Is it the mustaches?

[@Nerzhus]

What is that app that they used for the schemes?

[@qm3ster]

Thinking the server is the true source of state is the problem. A clientside application is not just a cache or "optimism", it *is* the state. Servers are just for pulling down the app code and synchronizing the data between the app and other users/services. I really struggle to think of a good application for htmx. Not even Wikipedia/documentation, since those are highly structured uniform data and thus benefit from sending down/caching just the content and not the rendered html.

[@cowslaw]

I unsubbed from theo recently. Too opinionated, self-centered, holier-than-thou. I like some of the things he does but I just couldn't take the childish drama. Just me?

[@cowslaw]

Also, look at his FAQ page on his site. I mean... seriously? So humble.

[@derschutz4737]

I like Theo because its funny. He is the classical JS dev who has strong opinions that are often pretty dumb. But that's what makes it so funny as long as you don't take it seriously. Similar to why I like prime, I don't actually respect most of prime's opinions, because he talks out of his ass almost all the time, but I don't take him seriously so it's just funny entertainment. You can't look at these influencer/entertainment dev's seriously, their content is just pure entertainment not really educational or anything.

[@cowslaw]

​@@derschutz4737 Fair point, about prime too. Influencer is the right description. I just think the attention-grabbiness got too much in the way of me wanting to learn some new tools, but I'm probably looking in the wrong space for genuine educational content. I think the only exception here is Prime's frontend masters course(s) (not including the random web3 one lmao), cause he curbs his intensity there lol

[@yousafwazir3167]

Yh I got out of the js bubble and started coding real world apps

[@nanashi7726]

I don't trust Theo at all after his video transmission of "Svelte sucks". Most of his opinions are garbage.

[@macctosh]

redux makes state transitions a breeze in react!

[@PwrXenon]

Redux and the fact you need all those libraries is why react is a dumpster fire

[@ba8e]

LOL FUCK Redux XD... Pure over-engineered GARBAGE. Try working with Svelte stores and come to the light!

[@n1njaF4c3palm]

36:18 in and feeling pretty dang good about rejecting "Optimistic UI" from the Meteor days. Long live server state!

[@framegrace1]

I think it makes sense, and seems to align on how originally the web stack was designed to work.... Javascript provides the dynamism, html the data structure, CSS the decoration.