From React To HTMX
Вставка
- Опубліковано 26 вер 2024
- Recorded live on twitch, GET IN
/ theprimeagen
Original: • DjangoCon 2022 | From ...
Author: / @djangoconeurope
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/dee...
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
ooofffffcccoouuuurrrrsssseeee
@@jonty3551 SHARING THE THINGS WE APPRECIATEEEEEEEEEEEEEEEEEEEEEEEEE IS NOT DUUUUUUUUUUUMMMMMMMMM
Not really, if you start with Netscape without JS, the complexity of modern web is obviously moronic.
@@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 .
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.
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.
@@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.
Good solutions never go out of fashion
@@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.
@@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.
@@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._
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.
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.
@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!
I can relate. Keep at it bro.
Glad to have Prime trying to hype us out of life in React hell.
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
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.😊😊
Is this something that is public? I'd be curious to take a look
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.
@@nchomeybanking and regulations give me your email address.i share a link
I don't understand what's so complicated about React. It's functions and JavaScript.
@@ralexand56json serialization steps and as a banking app the state should always be on the server.
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.
sad but true
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.
Carson's hyperscript is the language based off of Hypercard.
We should have gotten Hyperlisp ua-cam.com/video/8JOD1AQGqEg/v-deo.html
@@MicahKillian *based off of HyperTalk and its descendants (AppleScript etc).
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!
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.
Should i check out rust? Im a senior full stack heavy js and mainly spa or mvc.
@@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.
What's wrong with React?
@@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.
@@ralexand56are you watching the video or just reading the comments
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.
It's called cache
@@ihnatklimchuk1018 uhmm no?
@@ihnatklimchuk1018we mean native partial support
@@ihnatklimchuk1018 if htmx was natively supported, it would be more optimized, you wouldn't depend on the JIT optimization JS has
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)
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.
everything will be gpu based streamed
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.
@@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.
@@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
@@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 😂😂
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.
ur job sucks then
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.
You guys get to make PoCs?
if you don't have a prototyping phase your product is a prototype with all the problems of a prototype baked in.
@@BlazingMagpieHaha.
I've got PTSD attack looking at those '{%'
Javascript going in every field, meanwhile getting kicked out from it's own house lol
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 😁
A main difference now is instead of classes is using attributes for SOC from styles, and for making the responsibility & namespacing clearer.
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
I feel like if Haskell fully embraced all the functional concepts yes everybody will say it is the future in 10 years
@@ea_naseerhaskell is kind of dead in the industry
@@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)
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.
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.
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.
>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 :)
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."
That's when you ought to realize you should lay off the cocaine.
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
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.
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.
@@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.
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.
Someone here gets it at least
@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.
Prime, my man, the French do not add e at the end of the words.
It's the English speakers that are forgetting letters.
😂😂😂
Well, then why do they never say them out loud? 😂
Richard Beauchamp did nothing wrong
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.
Les Français mettre un 'e' pour les mots feminine.
grand /grande
Petit / petite
Cet / cette
Etc / etce
Imagine if we had native partial support,
to insert html response instead of a re-render
Tbh I don't imagine that or a similar thingy NOT being the next big thing in web-dev
@@Malix_Labspartial hydration? 😂
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
@@ea_naseer qwik doesn't do smth like that?
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.
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.
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.
@@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.
HTML API…. Are we for real right now? We’re going to use HTML as a means of transporting data?
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.
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.
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.
@@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.
@@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
@@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).
Phoenix Liveview would melt his mind.
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
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.
Look at 16:15
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.
yeah HTMX would increase the server load
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.
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.
It’s amazing. We haven’t progressed at all in 20 years. We’re rendering HTML on the server again…. Dear lord
I prefer JDSL over htmx
Tom is a genius
Tom is a genious
Tom is a geanios
Tom is a jeanius
Have you seen Marko?
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
yes the french place E at the end of things and then they go on to not pronounce them!
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%
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?
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.
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.
@@datguy4104 Razor replaces only changes html so a diff.
It’s all cool until you want a mobile app or need to sell a headless product in parallel
You just create new endpoint on your existing server.
One source of truth vs two ... so true, state in more places just means more bugs
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.
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 😂
Thanks for the croissant
We all forgotten about web components now...
Because nobody doesn't want to create it from scratch. Libs like Stencil and Lit isn't popular
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.
YES, FINALLY, THANK YOU.
"FULL-STACK" frameworks are always like that meme with half-finished drawing of horse - one party beautiful and finished, one barely sketched.
Agreed.
if blazor server side rendering do what it promises, you can have a spa aplication feeling with server side rendering
Me using htmx and Django since 2019. :Look what they need to do to mimick a fraction of our power.
How this guy said ¨We don´t have spaguetis code¨, and all i see is spaguetis code ? 😐
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.
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.
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.
255 dependencies to 9 is crazy. The maintainability fro. that alone makes this worthwhile.
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
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.
I'm professionally a react developer and I freaking love this. I need to build something now with htmx.
I have written backend services in the past. Also, have used Django, so no problem 🤓
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.
I love HTMX. Been using it for the last 2 years now.
prime's chat absolutely malding over this talk gives me great pleasure
This proves that MDD is the best pattern of all time. Meme Driven Development
isn't everything popular a meme at the same time?
29:15 *YES* that's what most of us are, brilliantly explained 👏👏
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!
Yes) looks like rails invented again :)
it's just templating
fuck I reach the part of the video where he shows the favorites feature... if it's easy I'll give it a try
but what causes the re-render...?
aaaaaah noooo it's a state store
"i don't want to go 1.5 speed. .... " *me turning prime to 2x*
15:30 "What, its barely working" lol so ralatable
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).
After you've been down in the mines long enough, knowing the "when" of "until you have to" seems non-trivial.
@@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?
In English, rendezvous would require six words: The place where we will meet. Just saying...
@@canadiantechprep "meeting," "meet up," "hang" (slang), "tryst," "rally point." These terms imply location to varying degrees. False argument from laconism.
I just want to say that mention "No Javascript on this" is just not true. You maybe don't have to write javascript code to do stuff with htmx but the core heart of the all thing is JS.
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.
this sounds like a perfect use
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.
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
"Overwhelmed with complexity" is a generally good description of writing frontends with React.
Nah, I think it’s more of a skill issue tbh. Even devs with no experience at my company build great front ends using react with zero issues 😬😬
@@OryginTech wasn't the experience of myself or my colleagues who have been developers for decades and tried using React several times. But then again, we called the bluff of it being a write-once, run-anywhere-as-a-native-app thing. State management was a generally horrible experience. The amount of bullshit we had to do to share/propagate state changes was ridiculous, and then the shit never ran properly except in a browser anyway.
Maybe a couple more years of React dev defenestration were all it took to get to the point where it is currently understood how to use React to make decent frontends, but it was a bloody landscape a few years ago.
@@k98killer sorry to have to tell you this… if you were a dev for decades and struggle so much to get some state management in react working… you just suck at your job 🤷♂️😬😬 again, junior devs at my company build complex scalable apps with it, zero issues 😬
Again what it comes down to is a simple “skill issue”
@@OryginTech my primary job is backend, but I am not an incompetent frontend developer. Developing in React is just a shitty experience, and most devs I've met who have had the displeasure to use it say it sucks. "It's a library that you use with a metaframework" -- React itself doesn't even know what it is. Hooks released after we used React for the first time; state management was possible but obtuse as I recall. The introduction of Redux, which we used when it first came out, made shit even weirder. If you and everyone you know loves React, then you must not have been there during the bad old days of React, nor in the time before React when you could just build a website using html, css, and javascript. Several years make a difference in the viability of a not-framework, but the accumulated disdain I and the devs I know have for React is unlikely to be overcome by the allegation that some asshole somewhere is having a good time with it.
@@OryginTech more to my original point, have you ever opened the node_modules folder in a React project? JS dependency hell is notorious.
Tbh, every time he said, "buckets" all I heard was, "baguettes" 😂
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.
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.
@@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.
@@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.
@@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!
@@IvanRandomDudeYes, you can do it that way but I prefer to have the flexibility of separate controllers for the different routes.
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.
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".
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?
This dude sounds like Bill Burr talking about front end development and I fucking love it lmao.
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"
exactly
PHP Dev here. I have been keeping away from JS frameworks since they appeared because I have always been a dinosaur in terms of web development. In 2023 the web is so over-complicated and everyone thinks you should do EVERYHING in JS because EVERYTHING must be quick, smart, crisp etc.
Reality is the end user gives absolutely ZERO shit about it, and I talk from experience since I have been working with designers on design systems etc.
They just want their content in a good amount of time, stop. So everything has been put into place, it's only cause of trends.
We do not need all of this, this is why HTMX is making people rage. Everyone is stuck in this crappy mentality dictated by trends, when at the end, you can do awesome applications by just sticking with the old but gold:
- PHP
- JS
- HTML
- CSS
And a bit of enhancement from HTMX/jQuery.
It's the way you create it, not the tool that makes it great. And you do not need to learn front-end frameworks to be considered a good developer.
Working on a codebase like this looks awful to be honest. You could probably do the same server-side stuff using Next 13 or Remix and have a much leaner, maintainable codebase, with the same user experience
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.
This is exactly how I was taught web development in HS about 12 years ago
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.
Been saying this for years: SPAs where a mistake. Glad I can live to see the day ❤
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.
thats what french means
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.
The last time I was offline for more than a week was in the mid 90s. Offline mode? Hahah what's that?
Please, do NOT use 1.5x speed ever! Your foreign audience would really appreciate it!
I'm a big fan of pure HTML5 with some jquery components. But hell, I'm going HTMX baby!
15:15 "this is your brain. this is your brain on react"
We've been reinventing the wheel for years and now we see it's better to go back to the old good days.
The best technology for me is the technology that allows me to write less code, when he said you wanna see how this works and opened the code editor and I saw line 1000+ and all the templates down there waiting to be called and executed, don't forget the amount requests and responses you have on each server state change, it's either am stupid and I don't see the benefit of htmx, or like it's too much.
Based on the talk it seems like that's just their coding style.
They seem to be very comfortable working in Django in a very particular way, and have no patience or tolerance for working in any other way. It's very clear based on the speaker's attitude and coding style that the React experiment was doomed from the start, especially when you listen to him about how they went about it.
ua-cam.com/video/wIzwyyHolRs/v-deo.html here he showed how codebase were reduced, esepcially the javascript
@@fennecbesixdouze1794 I agree 100% on your take.
People forget we're all different and our brains works differently.
When I see a backend developer say React is bad, [insert a backend framework here] is good, all I see is someone who doesn't understand frontend beyond the very basics. They're used to see things a certain way and changing their mental model is extremely hard. They simply don't get the "React way", their brain is wired to complete the task in their backend ways (which are not wrong either, it's all trade-offs).
To be fair, frontend developers are suffering from the same problems. They look at the backend code and go bonkers over how complicated it looks like. They're used to see things a certain way and changing their mental model is extremely hard.
It's clear to me both the original video and this commentary video are biased as hell. You can do things very simply by using a client or a server approach. Both methods have trade-offs and they both trying to evolve to solve their cons.
As a side note, it's also why I don't believe anyone is truly a fullstack web developer. The skills required to wire up a good API and infrastructure architecture are very different from the skills required to wire a great UX with all the subtleties of frontend architecture, user perception and accessibility. There is simply too much knowledge for 1 brain to be an expert in both. I've met awesome developers on both sides, they can definitely hack something relatively good on the side they're less comfortable with, but if you compare experts vs experts, they're all lacking a huge amount of stuff they don't even know they don't know. If your team is all fullstack then you're simply lying to yourself. Either they're expert in frontend or backend OR they're jack of all trades and master of none. The people that can actually hack both sides on the expert level are so rare you have more chances to win the lottery.
So in resume it uses a HTTP header to define a event, then it triggers ui rendering filtering the events?
And my application now is merged backend with html for specific purpose of rendering? For a mobile I will still need a api! Thus 2 backends?
Whell, I get the feeling, it can be done too in any other framework. Like, in my web saas, we use extjs and reactjs, one legacy and one 'responsive'.
70% of our clients still use the extjs version, since its a 'desktop' like ui.
For some actions, we listen for http headers on both ui, then 'react' for those events and do some stuff.
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
I love it, it’s a dream come true
Been using HTMX for a while now. It is growing very fast and it’s just getting better
does this open up security concerns like htmx injection attacks (or whatever the xxs equivalent in htmx is called)?
Yes, xss is certainly a concern, as it always would be when templating anything user given. Use a sensible templating framework on the backend, and be aware of xss. (Also, obviously, don't use htmx to refer to a backend that you don't control, that can obviously lead to problems.)
The more I learn about HTMX the more I dislike it. One big reason is that the application state is on the server (usually in a db) and changes of that state are done by the server. However it is ultimately the decision of the client what to do with the response. HTMX decides where to place the new content. But if the sever mutated a piece of state that would require an update somewhere else in the ui, then HTML cannot help you. You have to either react to an event emitted by HTMX, and do it yourself, which is prone to de-synchronization issues the more you have these situation. Or HTMX needs to send multiple HTML chunks that need to be sorted into their right place and I'm pretty sure HTMX cannot do that. It would be an interesting feature since it would transform HTMX to closer to a server component.
Also I don't like the video, because I don't like the premise of saying that frameworks are bad, because react is a terrible implementation.
The French guy bases his opinion of React on a single developer's vision and implementation. Sounds plausible this is just a skill issue.
You can return multiple elements to htmx in a single response and instruct it to replace elements in different places in the DOM. It's called out of band swaps. Pretty easy to do
It will generate way more designers because instead of forcing the front end to also be a designer instead you can hire real designers.
That codebase is exactly what it looks like when you are paid by hour :D
Hi, can you elaborate pls?
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..
I also decided to never touch client side javascript ever again, unless I have to build a web ide.
Htmx has one problem: without javascript it does nothing. So any typo or vendor update could ruin it.
Same could be said about react
Prime reactions are the bests !
Back in my angelfire days, we used to handle this with
I prefer vue over htmx, but it is always nice having similar alternatives.
(Why did I call vue similar to htmx? well, you can use vue w/o a build step, although there are limits to that)
My rule of thumb: Every reactivity in Vue is a v-model or v-bind.
This works 75% of the time.
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.
And it only requires thousands lines of python code in order to manage state and output full html sites to the clients… great achievement