From React To HTMX

[@ArkhKGB]

20 years to go from HTML generated by the server with some JS for interactivity to GUI programing in pure JS back to HTML generated on the server with some JS. Time is really just a circle.

[@laughingvampire7555]

@@thelvadam5269 who did it? AFAIK no one did, it is just developers who get obsessed with trying the new shinny thing, because we are humans and humans get addicted to novelty pretty easy. Get ready because htmx will be awesome for awhile and then people will get overcomplicated once again.

[@Bluesourboy]

Good solutions never go out of fashion

[@docmars]

@@thelvadam5269 I totally disagree. Before NodeJS, having to work in two different languages just to get a server + client going with horrendous spaghetti code using jQuery or vanilla JS was a nightmare, before React, Vue, and eventually Svelte came along. The developer experience matters just as much as the resulting code/technologies chosen for a project. A good developer experience is a productive one. The more you can reduce cognitive load, the easier + faster it will be to create an application.

[@balen7555]

​@@docmars Have you thought that perhaps this is because of other factors? Like JS being worse then? This is also a false dilemma; your choices are not limited to spaghetti code using jQuery or full-blown SPAs. The DX for Phoenix LifeView and the likes of it is much better than React for most part. Also, developer productivity is how well you're accustomed to a stack.

[@docmars]

@@balen7555 I personally don't think JS is worse somehow. It was easier to learn than PHP or Ruby (+on Rails) even and has served me really well for my entire career. My whole point is: being able to work isomorphically reduces cognitive load because you aren't juggling several languages to solve a small scope of problems, which in this case, is the web itself. The native language for browsers is Javascript, so you may as well be writing JS, debugging JS, and working in JS to solve problems in the browser. Using anything else for scripting is an abstraction around that, and often with frustratingly limiting factors. I hold this opinion less strongly when it comes to servers, because APIs and server-side business logic is a whole different animal. In any case, all of this is a matter of preference, but back to the original argument -- I think it's naive to say that JS is a poor solution to web problems, when... _it is the web._

[@fiery_transition]

The more you understand the more impressed you get by simple stuff, because in reality, there's so much complexity underneath everything, it's awesome

[@jonty3551]

ooofffffcccoouuuurrrrsssseeee

[@fiery_transition]

@@jonty3551 SHARING THE THINGS WE APPRECIATEEEEEEEEEEEEEEEEEEEEEEEEE IS NOT DUUUUUUUUUUUMMMMMMMMM

[@vasiliigulevich9202]

Not really, if you start with Netscape without JS, the complexity of modern web is obviously moronic.

[@fiery_transition]

@@vasiliigulevich9202 Well, I meant it more like an appreciation of everything which is usually taken for granted, from the bottom of the computer architecture to the top. JS is what it is, 2 weeks worth of programming to ship a product back in the day. What can you do.. And what the web is today, well, that is a longer story, but we can agree that unneeded complexity is bad, but even if you peel everything away you don't like, the uncrufty things are still quite interesting none the less .

[@anggoran7398]

We use framework to get rid of complexity. React is not only about SPA that is simple to host, but also a framework that has templating engine on it, JSX. Think about what React simplifies: 1. Templating engine. 2. Hosting. 3. No need to write CSS (using component library). 4. If we need a server-side rendering with frontend-focused, we can use Next.js. 5. Many more.

[@laughingvampire7555]

Apple has had the Hypercard since the 1980s, Carson based HTMX on the Hypercard, and Apple had the opportunity to have had revolutionized browsers before Brendan Eich ruined them with JS. But they were to busy going bankrupt in the 1990s and trying to get Jobs back.

[@disruptive_innovator]

sad but true

[@rodrigobarraza]

Even though your statements about HyperCard and Apple getting financially fucked are true, there is no confirmation that HTMX drew inspiration from HyperCard, and a little bit of an overstatement to say that Brendan Eich "ruined" browsers with JavaScript. JavaScript has indeed become a fundamental technology that enables interactive web pages and is a critical component of web applications. While JavaScript's design and implementation have been subject to critiques, it has contributed significantly to the web's evolution one way or another. For all we know it could have been just as worse as it could have been better, but "what if's" are just that in the end.

[@MicahKillian]

Carson's hyperscript is the language based off of Hypercard.

[@ArkhKGB]

We should have gotten Hyperlisp kzbin.info/www/bejne/bnuydWR3hqyke8k

[@fennecbesixdouze1794]

@@MicahKillian *based off of HyperTalk and its descendants (AppleScript etc).

[@sadboisibit]

I love the take on browser developers vs server developers. Where I work we are split into "web developers" and "software engineers" (aka back-end). I'm the only full-stack developer in the department. It is so painful to see people in their respective camps hyper focused on their small slice of a project. They can't see how their actions/inactions effect the devs on the other side of the fence.

[@TheSulross]

Am so thankful that have not been cursed in life to be a web front-end developer. Those that are mired in that fate must have a lot of past life bad karma to pay down on.

[@LuxFerre4242]

255 dependencies to 9 is crazy. The maintainability from that alone makes this worthwhile.

[@mentotong9652]

I was able to dev a software that acts as if a SAP by just using HTMX with django... No Frontend framework... It works wonders

[@asadbhimjee5578]

@15:24 totally hit the nail on the head. I'm laughing with you but crying on the inside because it's a struggle to make dev-friends with a busy life working part-time in a warehouse while looking for a dev job after graduating boot camp while trying to support my family (wife + 3 year old + one incoming) while keeping the house from falling into chaos living with parents while trying keep my passion for coding from burning out. Life's hard but it doesn't have to suck!

[@huuhhhhhhh]

I can relate. Keep at it bro. Glad to have Prime trying to hype us out of life in React hell.

[@repotranstech]

I have microfinance system in Django and htmx.A life saver,dont have time to manage react complexity,when i have more important things on the backend,like ledgers , accounting and api integrations.😊😊

[@nchomey]

Is this something that is public? I'd be curious to take a look

[@k98killer]

Nice. I've been working on a new FOSS fintech stack for over a year at this point. Trying to integrate advanced cryptographic features and such informed by Bitcoin but in the context of a credit network.

[@repotranstech]

​@@nchomeybanking and regulations give me your email address.i share a link

[@ralexand56]

I don't understand what's so complicated about React. It's functions and JavaScript.

[@repotranstech]

​@@ralexand56json serialization steps and as a banking app the state should always be on the server.

[@MrDiverXHD]

@ThePrimeTime funnily enough i work at a company where it is actually necessary for the web app to work offline because else someone might die because information is not transferred after reconnect and then miscommunication will happen.

[@danielvaughn4551]

Something indeed has happened to our brain lol. I get excited by stuff like this, but then I check out what's going on in the game dev world and I see Lumen and Nanite, crunching trillions of polygons at 60FPS...and I feel sad.

[@perc-ai]

everything will be gpu based streamed

[@OryginTech]

You got excited to see global state management? I swear prime is a prime example of someone with a serious skill issue when it comes to react. Even a junior dev in my company can do global statement management in 5mins of work. It’s not some mind blowing incredible feat of engineering to write a few lines of code and use zustand etc etc.

[@jkf16m96]

​@@OryginTechoh boy. You're really writing this as it was that simple. Then tell me, why do you thing zustand was invented in the first place, and how the early react users handled react? Even before hooks. It's not such a big deal right now because react ecosystem improved, but how wild it was before react hooks and whatever, damn. Redux is a big deal, but nowadays you can use redux toolkit or zustand always, I prefer zustand always.

[@perc-ai]

@@OryginTech do it without zustand u dummy lol then come back here to write a comment you are a jr dev that cant write zustand or anything close to it dont put down Prime he is staff architect

[@OryginTech]

@@jkf16m96 oh boy. Tell me again why we are talking about react before hooks? I can remember a time where computers were the size of entire rooms 🫨 oh man computers really SUCK huh? The whole point of react is it’s mature ecosystem. Literally takes 2secs to npm install anything you need to build a product. I’ve literally seen an entire thread with hundreds of comments on why Svelte is better because it has great built in state management 🤦‍♂️ Are you that lazy that you can’t install zustand and copy the boilerplate in 😂😂

[@wertigon]

I remember working on a website in 2010. PHP driven, so real old school. We used jQuery to a) provide IE6 compatibility and b) do some easier CSS selector magic. I remember being VERY firm on using HTML classes to define functionality..Needed a table to be sorted? table class="sortable". We also used #section-id to update a specific section - and if you had JS turned off the page would actually reload and go to that place! All in all the content took up less than 30kb of client side code and another 300kb of images. It was glorious. PHP backend was a template nightmare though 😁

[@TheNewton]

A main difference now is instead of classes is using attributes for SOC from styles, and for making the responsibility & namespacing clearer.

[@fennecbesixdouze1794]

Nothing in this talk impressed me at all in terms of "wow, you can do THAT with just HTMX?" Of course you can, I worked for companies that did similar interactivity with just Flask partials and hand-written JS for the DOM updates and header eventing. The only thing that really stood out to me with this talk is a lesson that splitting up your team into "all us Django people working on all the respectable interesting hard 'backend' stuff" versus "that React guy we hired as cheaply as possible and don't respect, refuse to talk to or collaborate with, who we think of as just doing all that trivial frontend stuff that we don't want to think about", is not a recipe for a successful small team.

[@zettadam]

Throughout his talk the presenter really shits on that front-end developer they let go (who's probably happy he left). This talk is not awesome at all.

[@x--.]

@@zettadam Dependencies and lines of code may not be the best metric but it certainly speaks to maintainability. So either they hired what they could afford or they cheaped out and found efficiencies that allowed them to spend less money to get the same thing? Maybe it's not revolutionary but certainly that's the nature of "improvement through competition" -- they got a better end product cheaper. Even in the "wow" isn't something intrinsic to HTMX but rather due to market forces such as the availability of highly-competent labor it's still a big deal.

[@TMRick1]

R is my main language and I honestly don't feel confident when dealing with JavaScript. On my job I developed some Plumber APIs (API implementation with R, very similar syntax with Express) that already delivers HTML buffers as a response to the requests. Being able to integrate this with HTMX is just a god's gift for me.

[@ccj2]

Between this and Rust, this is one of the most exciting times for me as an engineer. Anything that shortens the amount of time that I have to work with React as a massive win in my book. So glad Prime is shining light on these things for me, I can't wait to start my next project.

[@FromRootsToRadicals_INTP]

Should i check out rust? Im a senior full stack heavy js and mainly spa or mvc.

[@ccj2]

@@FromRootsToRadicals_INTP I recommend it, but if you’re not familiar with working with statically typed languages it may be a bit bigger if a learning curve. It’s worth looking into nonetheless, the documentation for it is fabulous.

[@ralexand56]

What's wrong with React?

[@ccj2]

@@ralexand56 specifically when using React for web: Verbosity. Incorporating state management (like Redux) is unnecessarily complicated. JSX. Very easy for developers to implement anti-patterns and poor design choices. I personally hate hooks but that’s probably more of a me thing than a React thing.

[@aodhai]

@@ralexand56are you watching the video or just reading the comments

[@y_arml]

it would be cool if htmx gets standardized and supported by browsers so that there would be no need even for that little js that sends and receives parts of the page cuz the browser takes care of it.

[@ihnatklimchuk1018]

It's called cache

[@y_arml]

@@ihnatklimchuk1018 uhmm no?

[@mma93067]

@@ihnatklimchuk1018we mean native partial support

[@arjix8738]

@@ihnatklimchuk1018 if htmx was natively supported, it would be more optimized, you wouldn't depend on the JIT optimization JS has

[@Hwyadylaw]

It wouldn't make a huge difference in practice. However, I agree that some functionality in the direction of htmx would be good (and honestly long overdue)

[@TheChillBison]

This was a great video reaction. I sense fresh air from the HTMX direction that is exciting. Having built sizable projects in Ember (long time ago) and then Angular (still maintaining that one), *not* having a front-end framework seems wonderful. Also, I love how surprising and abrupt the signoffs here are!

[@namenamington]

Prime: "I'm not going 1.5x speed simply because since he's not obviously a native English speaker I don't want it to become too hard to understand him." Me watching this on 2x speed: "Good choice."

[@nandoflorestan]

That's when you ought to realize you should lay off the cocaine.

[@constantinegeist1854]

>who is here shocked it's all server side driven functionality without JS Yeah, like what we had with PHP 20 years ago? Our legacy project from 2008 swaps portions of the page by fetching dynamically generated HTML from the server :)

[@quelchx]

I'm waiting for developers to come full circle again and say in 10 years React is the way to go rather than just HTML and sprinkle of JavaScript

[@ea_naseer]

I feel like if Haskell fully embraced all the functional concepts yes everybody will say it is the future in 10 years

[@inkryption3386]

​@@ea_naseerhaskell is kind of dead in the industry

[@fantasypvp]

@@ea_naseerimo rust is a better option as it has functional elements but is much more versatile and far closer to existing standards. everything you can do with js you can theoretically do with rust compiled to wasm (and many rust libraries for the frontend have similar syntax to things like react)

[@katrinabryce]

I hope that in 10 years time, Javascript is considered as obsolete as Cobol or Visual Basic, and we have an actually decent front-end language.

[@TheNewton]

In 10 years it will all be webasm containers for server side viewport rendering sent to clientside canvas ala angular shell payloads. There will be no DOM rendering"mutations clientside; basically glorified remote browsers. As long as the users internet connection is stable sites will load in MS instead of seconds and paint-update in even less.

[@Tony-dp1rl]

People commenting on XSS and HTMX don't seem to understand what XSS is, or how it is accomplished. The same potential issues apply to HTMX as to React, they are just solved in different places.

[@ThePrimeTimeagen]

Someone here gets it at least

[@JeyPeyy]

I can't imagine getting 1 month to do a proof of concept at my job. Management won't even give me a week to do proof of concepts.

[@perc-ai]

ur job sucks then

[@hannessteffenhagen61]

And now there’s my current company spending 6 months on a PoC with one team, then handing it to us to re-implement it in two months with a completely new design.

[@BlazingMagpie]

You guys get to make PoCs?

[@TheNewton]

if you don't have a prototyping phase your product is a prototype with all the problems of a prototype baked in.

[@ShafickCure]

@@BlazingMagpieHaha.

[@DanielLiljeberg]

If a rich "offline experience" is a main concern.... you probably shouldn't be writing a webapp to begin with.

[@fernandojmhs]

That is a really fair point

[@PaulSebastianM]

I mean it's cool if what you want or need is to move as much frontend user interaction code and data fetching code to the server, but to me it looks like a very declarative PHP, like a way to make SSR integrate better with user interaction, and in fact feels a lot like Microsoft's Razor pages.

[@datguy4104]

Just started using Razor pages, but after the initial SSR on it you still rely on JS to update pieces of the page unless you want a full page reload, right? Provided you aren't using Blazor components in the page anyway.

[@PaulSebastianM]

​@@datguy4104 Razor replaces only changes html so a diff.

[@iamlovishgarg]

Javascript going in every field, meanwhile getting kicked out from it's own house lol

[@mma93067]

Imagine if we had native partial support, to insert html response instead of a re-render

[@Malix_Labs]

Tbh I don't imagine that or a similar thingy NOT being the next big thing in web-dev

[@ea_naseer]

​@@Malix_Labspartial hydration? 😂

[@TheNewton]

2025 - webasm with DOM manipulation 2027 - template attribute for block level elements added to spec renders template on load: 2028 - Observer/pubsub primitives added to javascript 2030 - observe attribute added, use element behavior expanded Hello World or Hello World Hello World

[@losiu998]

@@ea_naseer qwik doesn't do smth like that?

[@Sandromatic]

That would certainly help. That does 1/3rd of htmx's main things already. The other two are thus: allow html by itself to issue any http request, not just GET/POST, and allow any element to be triggered and issue requests via any event that the dom already has. Like, frankly, these are things that only had to be implemented by htmx because html for some reason doesn't support it. If html did support these simple things, we wouldn't need htmx, but since it doesn't, htmx fills the gap.

[@lascivio]

yes the french place E at the end of things and then they go on to not pronounce them!

[@VonKuro]

Prime, my man, the French do not add e at the end of the words. It's the English speakers that are forgetting letters.

[@NathanHedglin]

😂😂😂

[@SigururGubrandsson]

Well, then why do they never say them out loud? 😂

[@electrictrojan6719]

Richard Beauchamp did nothing wrong

[@lashlarue7924]

No, you are forgetting année, journée, crée, soirée, tablée, donnée, mosquée, etc. You are definitely adding extra 'e's at the end of your words.

[@Jabberwockybird]

Les Français mettre un 'e' pour les mots feminine. grand /grande Petit / petite Cet / cette Etc / etce

[@TOAOGG]

I guess I am just dumb and don't get it, but when rendering a "huge" list of 1000 items leads to a "wow"...omg.

[@avwie132]

It’s amazing. We haven’t progressed at all in 20 years. We’re rendering HTML on the server again…. Dear lord

[@TBTapion]

I have to admit that, when I watched this on my own, my jaw dropped when the counter updated as he unfavorited one of the articles. Framework brain is strong

[@kollpotato]

I prefer JDSL over htmx

[@ich6885]

Tom is a genius

[@HolgerNestmann]

Tom is a genious

[@cursordgod2935]

Tom is a geanios

[@ActualJosiahPreston]

Tom is a jeanius

[@SoulaORyvall]

Have you seen Marko?

[@sacredgeometry]

31:33 You dont have to do that. People just write shitty code. Just like my early projects in python were equally egregious. It's nothing to do with the language and it absolutely is nothing to do with react. The main problem with JS/TS is the dependency hell that is a matter of course. It is a massive cultural problem and probably more to do with most of the people using it not being actual engineers/ developers but rather people that can lego prebuilt pieces together. It is enabled by there being so many options for them that if those pieces dont fit together they can probably find one that does even of its horribly written and could have been written by someone who knows how to code in minutes.

[@arjix8738]

one great example of this is oracle's apex, it is a lego website building tool the documentation is horrendous and you can only do backend stuff in PL/SQL, their shitty programming language

[@mrhivefive]

Phoenix Liveview would melt his mind.

[@elshadshirinov1633]

So instead of updating a central state and having views that show this same state (possibly in many different places of the UI), we do swaps on specific elements in our templates. Sounds so much better... not

[@CSharp1991]

When you say "kind of ok" is 25%, you are using Imperial system. He's from Europe we use metric system here. Kind of ok is 40%

[@TheSuperDoum]

love it! In ruby on rails, we now have turbo/hotwired which is basically the same thing! works great and love that! we can make a very reactive UI with very little effort, no need for a frontend team!

[@Deletedeletedelete]

Yes) looks like rails invented again :)

[@nickbenavides21]

One source of truth vs two ... so true, state in more places just means more bugs

[@outwithrealitytoo]

I agree - Multiple state machines reflecting one anothers' state... that way lies madness. It is why "Do not creating extra processes, threads or service types unless you have to" is not just sound advice, it is an adage of quality software.

[@rudzon]

I've got PTSD attack looking at those '{%'

[@hck1bloodday]

if blazor server side rendering do what it promises, you can have a spa aplication feeling with server side rendering

[@pierrehebert9743]

About the separation of concerns thing -- every time I've used react, I've ended up with a separation between the UI and the business logic, which is horizontal slicing. HTMX, on the other hand, seems to promote vertical slicing: you can, somewhat, expect every call made to the server to be a single feature, with all the business logic and UI logic for that feature in one place, and little to no logic for other feature being mixed in. As far as I know, that is better separation of concerns, rather than none at all like the presenter implied.

[@cat-.-]

sometimes I value having an 'pure API' that returns json so you can have different kinds of clients all connecting to the same server. because mobile web is still shitty thanks to apple.

[@CoderThomasB]

@@cat-.- Presumably, you can still have a JSON API or waterier alongside an HTML API. While this might be too complicated, you could have the HTML API just fetch from the other API and reformat the data in HTML.

[@avwie132]

HTML API…. Are we for real right now? We’re going to use HTML as a means of transporting data?

[@MichaelButlerC]

I think I just might have to jump in to HTMX as an old backend/fullstack head that never really fully jumped into the React/VUE.js land. I love how you can actually use HTMX with the old skool style CDN

[@redbenus]

It’s all cool until you want a mobile app or need to sell a headless product in parallel

[@sergenalishiwa9097]

You just create new endpoint on your existing server.

[@jamesyin3220]

Remember the days we built full websites with Flash and ActionScript 2.0? You drag a button on to a screen and you write a script on the button about what to do, and you're done.

[@freyrh3582]

I just realized that I never have to increase the speed of TheHTMXisgoingtokillReactbecauseReactisanoverengineeredpieceofgarbage-agen's videos because he speaks at normal speeds and that is very nice.

[@danielsepulveda4123]

Couldn't the complicated functionality displayed in the demo also be accomplished quite simply with a data fetching tool (such as react query / swr) and just marking the query as outdated?

[@lisinsignage]

Typical of a french engineer (I know I'm one). Show an impressive stuff using visually non-impressive suff. The exact opposite of US marketers 😂

[@airkami]

Thanks for the croissant

[@jwickerszh]

I might actually give this HTMX thing a try on an old ERP Java project where using a JS framework is not an option at all.

[@ThePrimeTimeagen]

this sounds like a perfect use

[@JT-mr3db]

Loving the simplicity of htmx. It’s good to remember that there are a colossal amount of high value, profitable products built on technology we would consider today as the “wrong way to build”. What wins in the end is the right product.

[@afiiiiiii]

Complexity exists somewhere, here in HTMX the complexity arises inside the attributes. It sure is nice to have no js, but this is not a react replacement.

[@0ktothorp]

I'm professionally a react developer and I freaking love this. I need to build something now with htmx.

[@0ktothorp]

I have written backend services in the past. Also, have used Django, so no problem 🤓

[@loquek]

We all forgotten about web components now...

[@infantfrontender6131]

Because nobody doesn't want to create it from scratch. Libs like Stencil and Lit isn't popular

[@onyilimba]

Me using htmx and Django since 2019. :Look what they need to do to mimick a fraction of our power.

[@modernkennnern]

I can't wait for View Transitions API personally(the fact that v1 is single-page-only is crazy.. I can see a use-case for it, but it's fairly minor). View Transition API alone almost makes me want to swap over to Chrome..

[@huge_letters]

So what exactly is the problem with having a React app with server state through react-query? Same stuff but looks much easier to maintain sync between components(say you have a favorite count and 3 different places where you can mark stuff as favorite) - and react-query will actually make only 1 reqeust between those 3 places unlike HTMX. Templating language is a thing of preference but writing onclick in React is probably easier than sprinkling your bits of native javascript in your Django templates. And in the end a React version will put less strain on the server. I think this presentation should've actually compared back to back some piece of UI code which was hard to do with React and was much easier to do through Django+HTMX - I'm not debating that writing a template with Django is not a bad experience, yet this is only thing this talk has convinced me of. I agree that if you have templates in Django - integrating it with HTMX is probably easier than a React rewrite. The only real example of React being a bad choice was a mention of how poorly in handled a render of 1000 element-long list - w/o a code example tho.

[@arashitempesta]

react-query was a game changer, but remember the talk was in 2017, no hooks, and we were in the redux epoch, render props and the other myriad of patterns that people were figuring out to make SPAs with react, at that time, it was common to have duplicated server data inside the redux store through sagas and actions which was a pita as you are duping server data and logic in the clients, and now you need to deal with cache invalidation. Its the other reason why nextjs and other metaframeworks were born, letting the server handle everything it can standardizes a lot of stuff, mainly authentication and authorization which on a SPA you need to handle by yourself and sync state. Apollo client and react-query introduced the mental model that made it make much more sense. About server load, I somewhat agree, it depends on how you architecture the app, you can strain the server all the same with a SPA compared to rendering the html over there. Right now with SSR and other metaframeworks, like for example Remix, you ask for the same thing in several places and get the same result if it hasnt changed following that same model, with react-query, urql, apollo client you have a cache that you can pull from but, that doesnt mean you cant implement cache on the server with htmx too, difference is that you will need to follow http standards to handle said cache. React right now its mostly a safe bet due to inertia and adoption, huge ecosystem around it and a lot of devs you can pull from to work on the codebase, which is why most people start learning it or just choose it for everything. I feel that right now people are seeing other tools like svelte or solidjs and realizing that maybe the extra abstractions and mental models that react enforces arent the best path for every project, as it uses the vDOM so now you need to engineer solutions for accessibility and DOM interaction, which is similar to what happened to redux, which is a really good tool but people abused it for everything and anything and now its seen with disdain whenever someone talks about it, because they have the redux saga trainwreck trauma in the back of their minds.

[@wanking9040]

You're absolutely right. I was not impressed by this at all. The guy in the video is Python back-end developer. He hasn't had to develop a large, complex, maintainable front-end app. Using HTML templates is bad developer-experience and unmaintainable.

[@huge_letters]

@@wanking9040 I admit that what they had built with HTMX and Django looks nice - I just have trouble understanding what was so shitty about their React code except for that list example. Is that presentation a proof that you can built a cool production-ready app with HTMX? Sure. Is that proof that to build the same with React you would have to deal with 5 times the complexity? No, pretty sure it would be at least on par if not better.

[@ThisNoName]

@@wanking9040 It started as using declarative data attribute to trigger ajax and swap html, looks like it still is. Guess not everything is large and complex, or need to be complex ... but almost exclusively, we are judged and paid by lines of code produced, libraries aiming at reduce complexities have never been popular

[@huge_letters]

@@arashitempesta By caching I meant more scenarios where you have 3 buttons to toggle favorite - you need only 1 request to know what their state should be and react-query will handle that. I don't think you can do that with HTMX whatsoever - you can trigger events in other elements with a response but these events can only just send new requests. So yeah, you can press add to favorite, a server will send a response and a header in that response will tell the other 2 buttons to show updated state but both buttons will just send two new requests to fetch their state. it's not a deal breaker for sure but since we're making comparisons. Yeah, i agree that svelte is an amazing tool(haven't used solid yet) - I've just focused on the comparison the video is making. So as I've said my main takeaway is that HTMX is a really good solution if you use some backend language for templating - like go or python etc. I struggle to see how it should be an easier replacement to React except for performance reasons - in that case I think switching to Svelte/Vue/etc would be a more reasonable choice because of the flexibility these frameworks allow. Cause showing that "you can put hx-trigger=click and it replaces the element contents on click - ISNT THAT SUPER EASY??" - yeah, no shit, it's also really easy to do in React too. I don't really understand what people mean when they say React model is complex - you don't need to know how vDOM works and state model which just requires you to assign a new value is fairly straightforward. Yeah "arr=[...arg, element]" is really dumb BUT it's fairly simple to understand. Probably easier than "arr=arr" in Svelte or that "obj={...obj, a:5}" will lose reactivity in Vue - even thought I agree that Vue/Svelte reactivity/state models are superior to React. So in the end as I've said - remove all client state from you React app, replace it with server state through react-query and you've got the same thing basically but with an easy opt-in for stuff which you can only do with React(or with Svelte, Vue etc).

[@sylver76]

Thank you. I learned React just because all the job offers ask for it, but it always seemed like an incredible amount of work to do something that I could already do on the back end relatively easily and just doing partial reloads through JQuery. And I kept telling myself "surely there has to be something more to React that I am not seeing that makes it an absolute must for business teams even though it's apparently an overengineered piece of crap that could be replaced by far less code". I kept waiting for the "Ah ah" moment that would show me why things had to be done that way and that never happened. Every new thing I learned about React was made to address problems that React itself created? After this video, I think the argument's finally settled, at least for me. React isn't worth it as far as producing apps is concerned.

[@mjacksonjones]

I love HTMX. Been using it for the last 2 years now.

[@VChu22]

They could have used hyperscript for the JavaScript parts.

[@BrianWisti]

First, hyperscript would have still been pretty raw when they were working on that conversion. Heck it's still not 1.x. It's also a pretty big context shift for folks. I used a tiny sprinkling of htmx and hyperscript for a Django project in 2021, and the client devs were so disoriented by the hyperscript that I just swapped it out for plain htmx (which they handled fine) in slightly more complex django-component support code.

[@chris.dillon]

The viewpoint that has never gone away is second class citizen stuff like putting CSS in "static" as if to say "this isn't code". I guess that would be fine except the products look terrible because the backend viewpoint never wants to do the frontend at all. That's why they copied the CSS into static and don't want to keep working on it. They never want to do the frontend so they don't. So the page looks old. This has been happening since Java servlets in 2005 or whatever. If there are two directories "src" and "static" then the JS and CSS go in "static" because it's _not real source code_. They would put the HTML files in there too if they weren't django templates. It's the attitude of the frontend is in the backend repo, not the backend is in the frontend repo. Second class afterthought. This isn't a strawman against his main point. I'm just commenting on the one bit where he shows the project folder structure. I see this all the time.

[@lol-wr8zw]

YES, FINALLY, THANK YOU.

[@lol-wr8zw]

"FULL-STACK" frameworks are always like that meme with half-finished drawing of horse - one party beautiful and finished, one barely sketched.

[@canadiantechprep]

Agreed.

[@cheleon94]

so each component listening for an event might be triggering a network call to update a number that has already been sent in the first network call? why not reuse that data? like, if I am showing the number of favorite documents in 3 sections that's 3 requests to the backend each time I add or remove something from favorites i guess it can be cached but the server still has to tell you that your e-tag is up to date and you are doing all of that work to communicate with the backend when you already got that data in the first place sounds like something that could be solved by an event bus

[@k98killer]

If I understood this correctly, HTMX uses an event bus under the hood, so the network call is only made when the client-side event is created elsewhere on the page.

[@k98killer]

Look at 16:15

[@k98killer]

Wait, nvm. I see what you're saying now. You're right. I was just thinking about how maybe a system that uses a composite CRDT for state management might be helpful, then just have pub/sub for parts of the CRDT, and the CRDT-state library just synchronizes with the server in the background.

[@arjix8738]

yeah HTMX would increase the server load

[@JensRoland]

True, but you could extend a htmx like framework with a clientside event bus for purely clientside interactions like cross-component data passing. In fact, that’s exactly what we did in Tomahawk, a framework very similar to htmx that I created back in 2012 (sadly closed source as it was built for a company I worked for). This avoided unnecessary server roundtrips and made cross-component (decoupled) communication really simple to implement. Unfortunately I think this would clash with the htmx philosophy as it can’t easily be made to gracefully degrade to no-JS.

[@fwd79]

29:15 *YES* that's what most of us are, brilliantly explained 👏👏

[@rhatalos1997]

I'm still sceptical about the UX. From a simple loading spinner to a real-time form input validation - so many actions require JavaScript or at least I don't see how it could be done without. Certainly a progressive web app needs to run mainly in the browser.

[@TheNewton]

This is just an example where most thing are exclusively server side. So offline etc needs for javascript are not even a consideration for such a demo, just the alluring idea of server-side "purity".

[@ytdlgandalf]

Ill come back from backend and devops when frontend becomes fun again, long road to go

[@RanilWijeyratne]

Been saying this for years: SPAs where a mistake. Glad I can live to see the day ❤

[@GKhagah]

15:30 "What, its barely working" lol so ralatable

[@xregularxjohnx]

prime's chat absolutely malding over this talk gives me great pleasure

[@NocV]

This dude sounds like Bill Burr talking about front end development and I fucking love it lmao.

[@sentinelav]

This is exactly how I was taught web development in HS about 12 years ago

[@LoneIgadzra]

Those of us who never left classic full stack frameworks have always known you can do things like this with the lame old tools. Been patiently pointing it out, but until now I've just been some dumb old-timer. React of course was created for a reason, but this kind of app degrades much better, has much better first load experience, and much less complexity and repetition of effort. It's much more feasible for a single developer, and still has great UX. Honestly, very few of the fanciest client-side apps I have seen were really a better UX.

[@rhatalos1997]

You probably already know that Microsoft Teams, VS Code, Slack, Spotify, Discord and many other programs are web apps. Are you actually certain that these products could be made with a "lame old tool" without sacrificing UX?

[@mage3690]

What I'm hearing is "never abstract unless and until you have to", writ large. Ultimately, you want to give the end user an HTML file that looks pretty when they click on it. Everything else is an abstraction off that ideal. Also yes, the French really do just add letters to the end of words. And to the middle of words. And sometimes to the beginning of words. Generally, the last 1-4 letters of any French word are silent. Rendezvous is a fantastic example: there are 11 letters in there, only 7 of them are relevant to the pronunciation (from an English perspective).

[@x--.]

After you've been down in the mines long enough, knowing the "when" of "until you have to" seems non-trivial.

[@mage3690]

@@x--. Fr tho. I could printf this, or I could do the same thing with 6 lines of Assembly. Printf seems like a reasonable abstraction and the logical extreme, but is it? At the other end we have React. It seems obvious to say that React is too much abstraction, but at what point does a collection of grains of sand become a heap? Assembly? C? The JVM? JavaScript? React? Where?

[@canadiantechprep]

In English, rendezvous would require six words: The place where we will meet. Just saying...

[@mage3690]

@@canadiantechprep "meeting," "meet up," "hang" (slang), "tryst," "rally point." These terms imply location to varying degrees. False argument from laconism.

[@clemensruis]

So it's basically like JSF with a component framework like PrimeFaces which has been around for ages. You need to write zero JS to have like a button which updates (partial ajax update) something within the page.

[@primosoma]

As far as I know, one of the advantage of a SPA is that you have only one API for all applications (Browser, Android, iOS). But, probably, nowadays we can use a PWA.

[@jessejayphotography]

Even better, you can have 1 API for HTML(X) website and 1 API for JSON for Android or iOS and they can both focus on what they do best and without polluting each others responsibilities or being compromised by specific design or data requirements.

[@IvanRandomDude]

@@jessejayphotography Probably don't even need to have different APIs for that. I've seen a project where we had endpoints that generated either partial HTML or JSON based on whether request is AJAX or not. For AJAX requests we were generating JSON and for standard request we were rendering HTML based on templates. It was .NET 4.5 project and used Razor templates. AJAX calls were served with JSON while non-AJAX calls were served partial views. But I guess it is cleaner to separate APIs.

[@primosoma]

@@jessejayphotography I mean, this is why we want one API, because we don’t want to do the same work twice. We send the same data, the difference is that in one case these data are presented with an html table, in the other case we use some mobile table component. If we have two APIs we have to maintain two APIs and we have to be sure that they behave in the same way, because I want to see the same data in both the browser and the mobile app. But I’m not an expert on this, I might be wrong.

[@jessejayphotography]

@@primosomaIts not hard at all. /user/{id}/settings -> HTMLX /api/v1/user/{id}/settings -> JSON They both can use the same business logic and database calls underneath to talk to the database and get the data and the controllers for each of these different routes can do whatever they want to transform the data to the API's needs. Like the HTMLX might need to inject CSRF tokens in the form and the JSON routes don't!

[@jessejayphotography]

@@IvanRandomDudeYes, you can do it that way but I prefer to have the flexibility of separate controllers for the different routes.

[@iWhacko]

I'm a big fan of pure HTML5 with some jquery components. But hell, I'm going HTMX baby!

[@elchiapp]

That awkward moment when you realize that React query is just a shared event bus that relies on cached http requests 😂 and now everyone's like "nooooo stop doing state management, just rely on react query"

[@ehm-wg8pd]

exactly

[@ulvidamirli2758]

We've been reinventing the wheel for years and now we see it's better to go back to the old good days.

[@kodeypatterson8973]

Been using HTMX for a while now. It is growing very fast and it’s just getting better

[@igortalic2021]

For me, the best part here is no npm modules, and updating all deps of react/next project and hoping everything will continue to work

[@laughingvampire7555]

to me as user a rich UI is a simple ui, no distractions, to the point of what I want, anything else is bloat. users don't care about refresh or anything else, users care about content.

[@fennecbesixdouze1794]

Users very much do care about refresh.

[@Chamieiniibet]

Did a client-side handling of up to 16 000 000 of nested records. In React+Redux. Working completely off-line between clicking Edit and clicking Save. With aggregate modifications and display of the entire selected set totals (resulting ACL permissions, that was a user management screen in the worst case). Everything worked smooth with not delays longer than 5 seconds (apart from the IE. Yes, we had to support Internet Explorer too). Where is your God now? Now tell me how you gonna manage the state of such a page (with unsaved modifications that should be cancellable and notessing with other instances of the same page open by the same user) with HTMX? Gonna keep temporary data sessions on the server? And for how long? Gonna have a garbage collector that purges them after a timeout? What if someone started working on the modification before a vacation to finish after? Gonna implement a heartbeat service or whatever?

[@datSilencer]

Oh man, I’m gonna have Nightmares about Tapestry, JSF, Velocity, JSP, Thymeleaf and aaaaaaalllll the server side templating engines I had to deal with… almost TWENTY YEARS ago. Time is indeed a flat circle… 😂😂😂 … but WTH… let’s give this another chance. Yes yes, I may be eating my socks again but who knows… maybe this time it won’t be so awful 😂😂😎

[@jasonterry9343]

I have not been this excited to code something in 4 years.

[@nexovec]

You have two options 1) RESTful HTML ajaxes 2) Javascript server that responds with javascript compiled from some other script that's emulating RESTfullness from the perspective of the developer and then handles the ajaxes.

[@karakaaa3371]

What is nice about JS SPAs is that you have very nice separation between the backend apis frontend code, which is nice when you can support mobile with that api. I imagine HTMX also has higher egress usage which is nontrivial at scale.

[@oceanfrog]

God almighty, after hearing you talk about the insanity that is React, I'm so glad I didn't get pulled past its event horizon.

[@armsofundertow98]

I dont understand why data heavy web apps dont use angular over react and why he needed so many dependencies. That said, very cool and I can see the reason why people are excited about this

[@mikehodges841]

Couldn't agree more. I've been in startups my entire career and have evaluated using React as a framework for our apps every single time and not once has it bubbled to the top of the list as "Yes this is the correct choice". The fact that Angular has always been a full-fledged framework means that everything is packaged with it. When angular upgrades so does everything else. Your router, state management, request library, etc. will always play nicely together. In react this is far from guaranteed and usually makes staying up to date MUCH more difficult. And the fact that Angular defaults to TS was just a good move. No extra work to get all the bells and whistles.

[@UrzaRage778]

Tbh, every time he said, "buckets" all I heard was, "baguettes" 😂

[@frankbardon]

I’m going to fire up a deep poc with htmx… I’m intrigued. However, I don’t hate react like it seems a lot of people do, and I’ve made pretty great stuff with it over the years.

[@MarcoZanon]

This proves that MDD is the best pattern of all time. Meme Driven Development

[@ThePrimeTimeagen]

isn't everything popular a meme at the same time?

[@drsensor]

no.1 thing to avoid on htmx: never render your query into html table on the server, the bill is brutal 😂 (especially if the data source is in column based)

[@losiu998]

add limit 50 to query?

[@repotranstech]

Cache the data.most mvc frameworks do that easily.

[@CodingBill]

Baguette ! 19:45 Fuiit xD Well server componentsand hooks and context are solving those issues of spagheti code and 2 sides of truth. I mean that the 22k JS lines could have been refactored nowaday to something much much lighter. 2017 is old version of React and this conf is not talking at all about other new frameworks like Svelte or Qwik.

[@oscarljimenez5717]

How this guy said ¨We don´t have spaguetis code¨, and all i see is spaguetis code ? 😐

[@xesf]

That template was horrendous!! Not that JSX is better but managing templates like that won't be easy for sure long run. It looks like again people are following into the trap of Frameworks once again and htmx is the same. Going back to plain ES Modules with Web Components when required seems way better with zero dependencies and magic behind the scenes. Like Prime said, having an EventBus helps a lot.

[@yawaramin4771]

Re: French people with really good English accents. Fun fact, David Charvet, who played Matt Brody in _Baywatch,_ is French. Like literally 1st-generation French.

[@Tom-jy3in]

thats what french means

[@AnupamAgrawal-q9u]

I watch almost all videos at 1.25 but only your videos are the one which I have to watch on 1 , just because I don't miss anything important ! 👏

[@MrSofazocker]

Debates on API contracts.... so true.. What endpoints? What schema is the response? Where does it consume it? Oh the FE is missing some data? With HTMX the backend send html, debates over.

[@sacredgeometry]

The last time I was offline for more than a week was in the mid 90s. Offline mode? Hahah what's that?

[@donnybystrom]

An htmx backend is cool and all, but eventually in your business growth it is time to build a mobile app. With a backend spitting out html instead of data endpoints, how do you handle that?

[@romanval69]

I don't think there's a huge difference. Supporting a web browser client & a native mobile app is already two different UX designs / code bases.

[@peterszarvas94]

You build a separate endpoints for json, keep existing html endpoints. Or use something like hyperview for htmx-style mobile apps.

[@donnybystrom]

@@peterszarvas94 You are limited by not thinking full htmx mindset. What we should be doing is spitting out full pre-rendered views for the Android app, and separately full pre-rendered views for the iOS-app. if there are iOS watch and Android watches, create separate APIs for these too and spit out specific watch views. backenders should maintain it all, because backenders are fully qualified to understand and adapt to client environments thus the work should be theirs to solve. Idk, the whole concept seems like recreating problems we solved 10 years ago.

[@donnybystrom]

@@romanval69 the web clients and the mobile clients has different code bases, but they consume the same data. What's the difference in data in Linkedin App and Likedin Website rendering a post? Now instead of having two clients consuming the same data and handling their own rendering logic, you have one API spitting out htmx like its 2002, and another spitting out JSON to be used in an app. Like why. To save 100ms rendering time on web? It just doesn't make sense to go back to the dark ages of PHP where backend spit out client code when most certainly the client code should live in the client.

[@MaiconCarraro]

@@donnybystrom I also don't get it, there are so many layers on top of this, nowadays you can build insane experiences especially mobile, if you take "Vaul" from emilkowalski, thats a huge experience and it requires specific js code for ChromiumSafari... what I like the most in JS ecosystem are the custom UI to be consistent across different browsers/platform... and most of the time they have better a11y (radix) than the regular browser behavior. I started coding in a Java web project with Richfaces, it gives me a similar feeling when watching htmx (not a good feeling)... I'm really in love w/ Project Fugu that is improving web capabilities and allowing for even better experiences like Document PiP

[@bastian9945]

"i don't want to go 1.5 speed. .... " *me turning prime to 2x*

[@carnelyve866]

I also decided to never touch client side javascript ever again, unless I have to build a web ide.

[@Entropy67]

I'm a heavy svelte user but I'm really liking the idea of htmx, sometimes you just want to expose users to a database quick and easy.

[@TBTapion]

At 4:40 as a non-native English speaker, I appreciate the thought for us non-native English speakers. 👌

[@ibrahimblahblahyapyap]

Wouldn't have known about HTMX if I hadn't see this vid

[@joshbedo8291]

Interesting wasn't expecting the html to look like erb files from ruby