I've been doing things the way HTMX does it for about 15 years now and have never touched react. Apparently tech is cyclical, and if you're a lazy boomer long enough you become the hipster.
Ditto. I have nothing against front-end code, love writing it, and I think typescript + JSX is really quite a nice experience, it's just a complete waste of time for CRUD and a ton of internal SAAS apps. These tools never needed React, and never will. I am continually frustrated by the pointlessly over-complicated approaches developers take for this stuff, not understanding the advantages of the old way, and how little effort it requires to make it a lot more like a SPA, rather than going full SPA. One issue I have with Theo's video (and this moment in general) is I don't really see HTMX as a big improvement over LiveView or Hotwire. It's just one particular take, but simplifying XHR calls is a big win.
bruh, Ive been saying this shit all the time and im 10 years in the industry. Isnt React on the server (SSR) the same thing what we havbe been doing with PHP 20 years back like WTF and now people preach it
I'm new and always hated when someone just gave me a CRUD object like a logged in user and an order object. The order has status of "In Delivery", so can I cancel the order at this point? Who knows, maybe ask the other team overseas what the business logic is and replicate it on the frontend. CRUD and inferring state has been the biggest pain I've experienced. Even when I was designing both ends of a site. I simply didn't know better. HyperMedia as a protocol and task-based UI (as opposed to CRUD) makes everything so much easier and shit doesn't break all the time when business logic changes.
Backend dev from Poland here 🙂. Did work with U.S company. Having meetings with client at 3 PM (my local time) and client just woke up was source of funny moments
That's an invalid argument anyway. If there is no backend functionality e.g. to query the state of an order then how would you render that unavailable state in htmx? You can't. Backend functionality has to be there. And if you're telling me that you can extend the backend with functionality that renders the state in html then why can't you offer it through the backend API, which is even simpler?
About the "nobody did single page apps before jquery" - Fun fact, I was writing arcade game clones, and single-page apps back with IE4 and NS4. I pulled data in using hidden s, and DHTML for animation. I wrote a bunch of games, Galaxians, Tempest (using VML), Frogger, Pacman, Pengo, Donkey Kong etc all using the original arcade graphics and running at full framerates :) I then got a cease and desist from Nintendo and had to take a bunch of my games down. This was over 20 years ago...
@@GeneraluStelaru Oh forgot to add I also did some multiplayer games, like video pool so people could challenge eachother. The games engine I wrote (open source) had functions to add multiplayer easily using the my site at the time and we had a really active forum of games developers - I hosted their games on the site for free. The main reason I ended up shutting it down was because the hosting costs became ridiculous as other sites were linking directly to the games. I also had chat channels that became really busy, it all used JS and then Perl on the backend at the time. Good days :)
Im so glad I discovered HTMX on your channel. I never liked the complexity of frontend frameworks. Or why Frontend even requires so much work since logic and state should always be on the backend. I just want to display the stuff that is already there.
@@alang.2054 but php wasn’t as good as other languages in the early 2000s!! Completely unusable in modern day bc it hasn’t had a single update since then smh my head it’s exactly the same
@@ajbrady4357 wait what? Not the biggest fan of PHP (used it enough to know its not for me), but what you're saying is just plain wrong. 1st Good as what other languages? PHP was originally template language for WEB - giving possibility to make from static HTML a Dynamic HTML Server rendered pages (yea a the new FE things :D ) when mixed with JS (the vanilla flavor or later JQuery) together with ASP Pages from Microsoft was one of the pinnacles of the Web development. 2nd PHP is well they are at their 8.x version now - yea its not moving as fast as JS frameworks 20 versions per week (which is a good thing actually). So love it or hate it one thing, want to use it or not is another, but its not fair to say its dead or not suitable for modern use :)
Most of the arguments made in the video are invalid. The idea that "with htmx there is no state at the frontend" is simply false. Let's say you make an order and the backend sends you "Order in state: Processing" and an enabled "Cancel order" button. That is a state, and it will diverge from the backend state over time. Because the backend will process the order and change its state possibly to a state where cancellation is impossible. So the backend logic has to check for invalid actions resulting from invalid frontend states anyway. So state-wise you haven't changed or fixed anything. And the backend logic that renders the enabled "Cancel order" button will still be distinct from the logic that handles order state transitions. So you haven't unified logic either, you've just moved it to another place. And it's not better in that place anyway. The same info that you will use in that backend logic to determine what the next valid/possible states are could just as well have been sent to the frontend.
There are quite a few points about the "backend defining the actions" or "it's already done on the backend so why reconstruct on the frontend" but the crux of this is poor contracts between front and backend. Almost all of my experience has involved multiple clients talking to a source of truth e.g. multiple native apps, machine to machine integrations, web apps and microfrontends. When you have to serve multiple clients the contract is the most important thing, not whether you use a backend first or frontend first framework.
Roy Fielding did a poor job explaining the concept of a restful service. He never managed to get people build restful api the way he imagined. HTMX is moving people towards the right direction, but the root cause of the issue is poorly define contract on the backend.
I was doing htmx 10 years ago with my own attributes "my-post" "my-get" instead of "hx-post" "hx-get" and engineers were shouting bad practice 😃 Programming is just fashion.
this is my issue with React mainly too. I did a lot of es6, jquery etc, and dabbled in few frameworks a little bit. I've come to the field late, graduaded like not too long ago from uni. And looking at a lot of the web dev stuff, i feel there is a lot of dev glasses what i could say. I fully understand why React is used, since writing anything in plain JS/Jquery when it's complicated and animated interactable element can get painfull and hell to manage, but at the same time, i aggree fully with Prime, with that React abstracts soo much to the point where you start to think "React" instead of thinkg webdev. Another thing i feel is there is just this emotional burden that makes people feel certain tase on frameworks where despite very often them being good at the same things, they will tribal to gating something. I don't have strong attachements to it or Angular, but at the same time i don't understand the Angular hate since both generally feel "simmilair enough" to me(would probably feel the difference on something more complicated, not arguing there), and it's hard to not think, it;s the issue of if somethings a hammer, everything becomes a nail.
This is why I started to learn Svelte. When I was introduced to React, it felt like I just had to throw out all the HTML, CSS, and javascript I had learned previously to learn the React way and then learn the React ecosystem, but the react was didn't feel applicable to anything but React.
At this point I've shoved most of Angular out of my memory cause i hated it so much, but i remember it feeling super clunky and cumbersome, with poor documentation. Every simple thing i wanted to accomplish would take 4x as long as it should have in Angular, it was constant wrangling. I switched to Svelte and i love it; Svelte is what i wanted Angular to be.
Svelte solves all these issues. Feels like an easier version of vanilla web development, not different. I even use plain css everywhere instead of adding more.
1000% agree with Prime's diagram around 31:00. That's exactly it, the point I have been wasting time making on Reddit for years. Having a full client-side state based on JSON is unnecessary duplication of state.
Exactly so. I do not understand why front-end developer do that. Of course, I also think SPAs are an utterly terrible idea in 80-90% of cases and that simple jQuery development with page transitions blows most SPAs out of the water.
@@ivanjermakovThat can be solved by having separate services for each client though. Mobile client calls mobile HTMX server that serves mobile formatted HTML. ideally though the load profile is similar so the same service could handle all the clients, just returning different HTML based on endpoint / API. Could still have a pure JSON backend service
When working with frontend frameworks, you don't need to have the application state in a set of JS object. You can, if you prefer, just apply a template from the responses of the server (which is better than html payloads). This is an architectural concern that htmx enforces but can be done with frontend frameworks.
for me no other js library was exciting to me like JQuery of old it will always be my sweetheart she never complains about your setup never argue with you about your build preporcessor or packages. i curse the days i switched to React because it was "cool" and "new girl in the bloc" but now HTMX is like my mistresse reignited my love for simple CDN libraries that have the same montra "CODE LESS..... DO MORE"
Absolutely, using React since 2013 is way different than using it since 2018. The shit the rest of us have had to go through. Dark times for the frontend world that made me miss jQuery every day. I avoid React as much as I can because of that 2013-2014 era.
I once got asked in an interview "class components or hooks" I was like: "class components are more straight forward, useEffect and useState are bloating the code and make it harder to read". I started coding in React in 2016 and.. I did not get the job, I was still loving componentDidMount etc but understood what the market was after and the direction that react was going towards. I ended up loving hooks, but now I am doing Svelte.
@@perc-ai lol. That doesn't really help. He's talked about his schedule before and the answer is some combination of: he doesn't need as much sleep as many of us, he works from home, and he has a significant other that can help with much of the house/childcare aspect of things while he's busy streaming/etc.
@@bobbycrosby9765 bro cut the bs you do realize health is key right? you think he gets 5 hours of sleep or something lol this dude has streamlined his life so well hes able to do all this stuff. Health sleep wife/kids remote job all of it comes into play to understand how hes so alert it also helps to have an iq of 140+
How does he manage to make a reaction to a 12 minute video last 50 minutes. Truly a talent many RUclipsrs would like to reach the 10min mark for multiple ads.
Just my 2 cents, I think that while state management is a good concept, using a single word "state" to shoehorn every single value/variable/cache/element into a single concept and then trying to say general things about that (and only that) can also be counterproductive. In prime's example of the game of life, it might make sense to talk about the "client state" for things like what the currently alive cells are, while at the same time acknowledging that things like managing your "savegames" bring with them the challenges associated with managing such state for which ultimately the backend is the source of truth (assuming for the moment that thats where the "savegames" are stored). It would be counterproductive to either require all the state to be a reflection of what the backend knows, while at the same time it might overcomplicate design if what savegames the user sees in their "html" cannot simply be seen as a reflection of the data in the backend
Also for me it is simply an argument of whether to do things sync or async that simple. As it all boils down to that. And all design patterns and mistakes there off start from there till the perfect meeting point on the middle where no one reaches. Htmx has a latency issue, react has a concurrency issue. 2 different problems 1 same scenario. In an ideal world sync is right, bt its not, so I still prefer to react for now. Tanstack has tools for th state mgt problem so i think we are good enough for now. Only problem is carrying all the inneficiencies of react basically technical debt
One thing I like doing depending on what i'm building, is to build a backend in rust with axum and askama, then load htmx and twind from a cdn; that way you're basically guaranteed to never send more than around 20kb of js + css to the client, then all your ui is just declaratively embedded in your html template.
In his story about music service, it sounds more like his company had especially bad team of backend devs, or their backend stack was bad for their use case. In no way a technology change can singlehandedly make one Theo backend dev replace 8 backend devs.
Wait a minute this looks like what I did (used to do?) with C# and XAML for UI. I always wished it was like that for the web too. Never got the hang of react. State management seemed so complicated and stressful. Nice, HTMX. Gonna check that out. I was actually floored with the other demo that you did a video on. The article loading thingy
Hey... another XAML user. I loved working with XAML and when I crossed over to start working with web stacks, I felt how broken a lot of these things were. I ended up using Blazor to use the same language in the front and back. Now that I'm using Go, I needed something else to do my web frontends when I need a front end (not going to bring in C# and Blazor right now) and HTMX is a godsend. I'm sure you'll enjoy it.
An htmx backend seems cool! Really snappy and intuitive for its purpose. But eventually in your business growth it is time to build a mobile app. With a backend spitting out html instead of data, how do you handle that with an iOS/Android/Cross platform app? I might not get the whole picture here, but it feels like kind of a technical lock in to build a backend that focuses on producing html documents like back in the days.
Ideally, business logic should be de-coupled from the delivery layer (HTMX in this case). If the business then wants to build a mobile application, we build a separate delivery layer (say, REST) and re-use the existing business logic. It may be more work later, but it makes HTMX seem viable if the business is unlikely to go for a mobile app anytime in the near future.
@@LePetitMondedePurexoYT Agreed. I log in to ebay and facebook using the browser on my phone, just cause I don't want yet another app nagging me for permissions to read my e-mail contacts etc.... It is amazing how many of the big websites struggle with all of this regardless of the responsive layout stuff. There is almost always something that can't be done on the mobile web version that requires the app. When an app may not technically be necessary AT ALL......
Personally I think the way that Phoenix liveview does things is the best way. It's a two-way binding between your elixir app and the so-called client which is effectively just a web socket. You actually don't even need any HTML in your project (outside of the root template). The state is maintained by the processes and elixir has some extremely powerful fault tolerant tools to keep things synchronized. As such you can just have a single process with the state and you can use the pub sub to proliferate the state out to the clients, It's inherently simple.
Yeah, what makes Liveview different is that the state is all server side. This makes it a joy to work it from the backend (speaking as a full-stack dev)
@@NoidoDev "don't need any HTML" isn't quite right. There's still HTML, but there's no front end JS code at all. It's all server rendered HTML, with server side logic. Templates are rendered fully hydrated on initial load, then dynamic content is updated by re-rendering the partial templates server side, and sending the minimal partial diff over a websocket. The workflow is that you're just working with plain old partial HTML templates in one place. Very high performance, good SEO by default, and don't have to have separate server and client side code, so is quicker and easier to write, and much more maintainable. There’s a client side JS library to load, but that just does the Websocket and DOM updating logic, and is tiny (like 80kb I think) It’s like of server rendered react components but… done right.
We all know the proper way to synchronize state is call GET /entire-application-state every time a user interaction happens and also in a 50ms polling loop in three different places. Make sure you're calling this server side and on the client and hydrate redux with deep copies of the response so that spontaneous renders are constantly happening.
i have made this point before 44:00 htmx is really good if you have lots of permissions and logic and not everything as public. i totally understand this, i have worked on projects where people just keep asking for dumb permissions on who can see what with lots of backend logic. validations and syncing can be a pain, but if I just had htmx back then, everything would have been 1000x simpler. i mean i would literally need 0 js. literally. i wanna use it. but if you have everything as public why spend time querying the db, generating the html then sending the html. while client can just query the db and generate the html itself. run the logic itself, invalidate bad data itself, and never ask for a permission. why not just have a dumb server. so i agree
This my approach to webdev... in the long run I want to do as much logic as possible on the front-end than on the back-end. Why? more resources on the front-end. it's just that simple user's PC/Tablets and Phones as insanely powerful, for an indie developer like me server resources are severely limited
If the html us public, you can probably cache it. If you can‘t cache it, well, you have to generate the data either way. Rendering html vs rendering json should not be a huge difference either. Same for the size difference if sending html vs json.
Very nice take about how you see it as a state problem, even I with not much web dev knowledge can 100% agree HTMX seems to reduce state sync problems and how you described it with the delete button was nice!
For my personal use cases I basically need Static Single Page Applications that update once in a blue moon. And for work use cases we see iOS, Android and Web as three platforms; literally no server side rendering (not even for SEO). HTMX sounds nice and I'll probably never use it :D
OMG, how did I miss HTMX? Trend of near always connected will continue. Solutions over the past several years always felt like temporary fixes to me until offline is a thing of the past. Will have to try this. One of my old mentors told me when PHP vs ASP was a debate that we moved from thin clients + server -> move it all to desktop with thin server -> back to thin client, but now it's the browser and not the full system that's the "thin client". I feel like after he pointed that out that it's still playing out, just at a slower pace than we had figured.
Disclaimer, I'm currently mostly a frontend React dev but I also had a lot of experience on Java/Kotlin backend. I haven't used HTMX but it sounds a lot to how we structure the code at my place of work in the sense that the BE isn't just an endpoint to get data but it actually tells us what we have to render and then we just render it, the biggest problem that I've encounter with that approach is that it creates a very tight dependency on both ends, we in the frontend cannot change anything before it going through te backend so we usually have to wait for them to finish their implementation or have to agree beforehand on one and then start coding; and the backend cannot change anything that affects the frontend (returns, endpoint interfaces, types) without getting our approval first, or else it could break the frontend.
@@sokacsavok I use other languages, have tried Ruby/RoR as well and just never saw what others saw in it. There were many better languages and frameworks then, and even more now.
@@W1ldTangent You mean like Javascript? A language where '2' + 2 = 22? I never got why others didn't see the benefits in RoR, still nothing has come close to it. Ruby is stable, flexible, consistent and great language. Rails is mature, well thought out, easy to use, just needs some learning.
What's good about React isn't React itself; it's the ecosystem around it. It's become very difficult to create modern UI components with accessibility without using something like RadixUI. Tailwind is creating Catalyst to compete and it's React-based. For example: a dropdown that responds to keyboard events and changes its orientation in case it's getting hidden. Good luck doing that with HTMX without a lot of custom JS.
Exactly. And that's why companies still choose React for any new projects. I worked with companies choosing Svelte and it's consistently because they don't care about things like accessibility.
Ecosystem is a poor argument. Angular also has an ecosystem around it. A company can build up an Ecosystem to support anything they use. HTMX can have an ecosystem too. But people really should have a mindset of thinking what the existing html standards support before reaching for something external.
The problem with the practice of front-end frameworks like React is you're offloading more of the work that can be better handled by specially-built server software onto clients that are a lot worse in processing power and have to do a lot more HTTP transactions to make up for not repeating yourself a bunch of times in backend services. Progressive enhancement should have been the goal, but there's a lot more thought necessary to implement it properly, and companies loathe paying any kind of debt, especially tech debt.
The Django roast was my favorite. It's always been Django, it will forever be Django. I watched Theo's video first before this one and I thought "why does this guy think that there's any change over time in the web framework in Python land??"
For years, I've contemplated diving into the world of React, Vue, and similar front-end libraries/frameworks. However, it often appeared that these tools required a substantial amount of setup and configuration compared to what I could accomplish with Django sessions in conjunction with Ajax or HTMX. Strangely enough, I've consistently found that my web applications and sites remain just as snappy and interactive as those built with React. It's possible that I might be overlooking some key aspects, but I can't help but wonder if the perceived complexity of these front-end libraries is sometimes unnecessary for achieving impressive performance and interactivity on the web.
I had the same concern as you and why I picked Vue over React. Vue requires no setup, not tooling, nothing (unless you want that). Can be integrated into any existing architecture no matter how legacy without a problem since it's so stand alone. Got Vue working in no time with an old but very large site built in WebForms which would be completely incompatible with anything else.
After a long time of watching the htmx hype I finally feel I understand why, What you said prime makes sense. But my intuition still blocks me from getting convinced that HTMX is something actually useful. Here are my reasons: 1st I feel nice when my server is responsible for data transferring and not HTML templating. I understand that that was web 1.0 as you said but since the web complexity has risen undoubtedly, I've ended up really liking my server not being responsible for any templating. 2nd is that even if I accept that generating HTML on the server is the way to go and it makes sense to have my policies on my backend along with the templating stuff, I'm honestly scared about the AMOUNT OF CODE it would be required to create a modern UI UX experience the one that an average user expects. I imagine for example creating a data template to bind for a simple interactive page with html/template in go and MAN this sounds. I would prefer to send the data over the wire and have a UI tool that really helps with updating these kinds of things. I don't feel that HTMX complexity increased template complexity significantly. Again, I fear more about the transformations in your backend language in order to render the x piece of data and it's 5 derivative states in a Go code base for example. I feel the "maturity" of the js ecosystem is shines at EXACTLY this spot, my favorite recent way as with anyone being signals of course. This is why I think I like the split backend-frontend. I hate the modern framework complexity and I've been heavily working with it since 2015. But I don't feel that returning the templating the the server solves this. I'm already having nightmares maintaining all the interactions within both a template and a server that generate that template and it's bound data. I think I prefer to simple get a bunch of data from the server and manage my interactivity and state in the browser. And even though I get where you're coming from, it's hard for me to even imagine how this is easier. Would really like to discuss about this. @ThePrimeTime
It might have to do with the type of applications you write.. if you are writing a back end heavy app with a skinny front end & you don't pay for the extra network round trips to the server - HTMX is a great solution. I find it being a easier sell to predominantly back end teams that need UI - think Intranet/Corporate apps (wonder who still uses those terms :) ) .. If your server side code is sitting on Cloud functions like Lambda where you want to carefully audit network i/o, then HTMX might not make a lot of sense (depending on how chatty your app is )
An interesting angle here is that the amount of traffic to serve a given number of clients can be substantially reduced if you send protobuf to a wasm frontend as compared to html/x for every click.
@davidjdriver that depends on the session duration. If your user spends 30-40 min on your page doing stuff, maybe 1-2 MB of burst bulk upload is cheaper than thousands of tiny requests 1-2 KB each.
Love your version and a better explanation, business logic stays on the backend just use the front-end to display the actions in progress. Based on a high speed network it's great.
For internal apps that really don't need a fancy UI with all the bells and whistles as long as it works, and one would hope adequate network speed, I can see it being a significant time and effort saver for the developer.
It's also nonsense. Most of the arguments presented are invalid. In reality you haven't eliminated frontend state and you also have not unified business logic: Let's say you make an order and the backend sends you "Order in state: Processing" and an enabled "Cancel order" button. That is a state, and it will diverge from the backend state over time. Because the backend will process the order and change its state possibly to a state where cancellation is impossible. So the backend logic has to check for invalid actions resulting from invalid frontend states anyway. And the backend logic that renders the enabled "Cancel order" button will still be distinct from the logic that handles order state transitions. So you haven't unified logic either, you've just moved it to another place. The same info that you use in that backend logic to determine what the next valid/possible states are could just as well have been sent to the frontend.
@@xnoreq it not just logic in the process, but rules, logical I can sell to you in any country but others have the Asian Pacific rights so I cannot deliver there for this product. We see that daily with netflix this is not allowed in that country or region, do we allow a front end overrule the backend.
@@colemichae That is business logic. Just because it includes the word "logic" does not mean it is limited to the classical/mathematical understanding of logic. Business logic may, in fact, contain illogical rules. To your example: First of all, when dealing with rights, this has to be done in the backend anyway, regardless of where you do rendering. You cannot trust the input of the client (which includes its state, rights etc.). The backend can simply deliver a list of valid/possible countries the company can e.g. ship a product to. The frontend can then render this list of countries however it likes. The backend also has to figure out where the user is coming from using an IP geolocation service. You cannot trust the user's web application or browser/operating system settings. If it turns out that the user is in a country where the company holds no rights to sell the product then the backend simply will not include that product in the data response (or include it with a NotAvailableInYourCountry flag if you like to render it in the frontend in a disabled state). The frontend should never ever be able to overrule the backend.
37:10 : What technique to employ heavily depends on your use case. Having a throbbing (probably long 😏) loading bar is not always the best solution. Although it is the clearest and most understandable in terms of what is happening, it comes at the cost of responsiveness. If you have an app that needs to work in a low/none reception area having to wait for a Server response can be quite agonizing. Think of a package delivery service that needs to take in signatures in a Village at the ass of the world.
as long as you make sure that the rest of the app is still responsive during the throbbing, it should be fine. the main context i can think of where it's a problem is if you create a new item and need to wait for a response from the server before you can start filling it in. in that case you need to greedily make the item. though, i guess it can also be an issue when you want to edit a thing again after having changed it, but before the server has responded to the first change, which is kind of a tricky situation to sync properly, but can also be very annoying for the user. a typical example of this is a "like" button, which you might accidentally tap and then want to undo, but can't do it until the server has responded to the first tap. so i guess in the end, the only part of CRUD where it's not annoying to experience a long throbber is the D
One thing I don't like about this channel is when it's comparing apples to oranges. I understand comparing technologies that do the exact same things. However, in this case React and HTMX can serve different purposes, and both offer capabilities depending on the use cases. Just choose the tools that are specific to what you working on. It's good that we have all these different options.
The most generic answer ever without understanding the problem. The comparison issue of apples out orange is warranted when you have a problem domain and the solutions and trade offs are either going to benefit the Apple or the orange. You are randomly throwing randomized quotable in a careless manner. An Apple can be compared with an orange of my damn use case or problem is clients want Apple pie and not damn orange juice. Same thing is when you work in a new company with millions of dollars on the line to solve an engineering problem with its constraints and you have to make really great comparisons on what helps progress the product.
Watching this, my last 6 years of web development feel like i've wasted a lot of businesses money, time and opportunities by simply sticking to JS frameworks for the sake of just having it. I hate what i've created. I learned a lot, but I hate it.
Doing web dev since ~2005. Had some adventures with (P)react, vue and other technologies. Always went back to mostly hypermedia because it burns less time/money. Currently my apps consist of native custom elements, hypermedia and some sprinkles of js modules here and there. BTW i mostly code PHP - take that fancy framework kiddos 🎉
If your architecture includes GraphQL, your Backend is the SQLDB. Everything else is frontend. All these hoops just to render an SQL table to HTML. Hot take which is true for 99% of Apps (especially in the enterprise) HTMX + any template language makes more sense here.
2:09 In Laravel, you can do the exact same thing wih Livewire. It's the same process: Laravel generates an AJAX request that fetches the output of a PHP script on the server when there is a need to update the frontend. And it does not refresh the whole page. It's been there for a while now...
Video games are not an example of server state. The game analogue would be sending the whole game down to the client (HTML analogue). Once you exit the game, there would be nothing left on your PC. Instead, games are pre-installed with gigabytes of data. Clients only exchange minimal data with the server. Some information is exchanged between clients directly instead of the server. Games will typically also have a lot of state and processing that happens on the client (games can be GPU and CPU intensive). The client only talks to the server to persist or load data, just like SPAs. Some singleplayer games are completely offline. The problem with server state is that raw state is not the whole app and visualizing it is something that fits better into the client and needs to be done close to the user.
Год назад
You will love the paper "Out of the Tarpit". BTW, that paper inspired Clojure. Highlights state management as top priority issue in Software development.
Failing optimistic updates are an edge case, not the majority case. Which one should we optimize for? If an optimistic update fails, you can recover from it by keeping the previous state until the server responded. Or by refetching the state. Libraries like TanStack query have both strategies built-in. Or you just wait for the server depending on the case. Then there's all the client-only state that the server doesn't even know about. Like the tree expansion state of a tree view that every client has its own instance of. Why do that through the server?
it seems reasonable to me that there is client state that the server doesn't need to know about. I guess when the client is directly reflecting state from the server though, server side rendering could make more sense because you avoid duplicating the data structures? (I'm new to all this but just trying to wrap my head around these discussions)
For me I feel like people who are in the HTMX camp don't want or don't care about UI/UX in the long run! I am really curious how easy is it to change or add features in HTMX two years into development
I'm surprised or confused by Theo's perspective at 18:55. Most Frontend-teams I've seen handle clientside AND serservside (what Prime calls the Middle End) and the Backend-team served an API. We have been handling dynamic client updates (like in Search forms) by clientside fetching partial views rendered on our server. The one Theo thing in this video that I do conceed is that my frontend team does have to wait for the backend team to add stuff to the API-data
Man I so agree with this. It's so nice to not have the JSON layer ie from frontend to JSON to backend to JSON to frontend. In between things can go wrong. And just to sync state and data, you need things like redux, RTK query, sagas, react query, for navigation it's react router or whatever solution etc. React has been relying on so many 3rd party libraries that try to solve bridging the gap between Fe and be. And these are just not simple libraries, they're whole concepts to learn to even use right. But a stack like HTMX, Alpine.js, Tailwind and maybe Go for the BE can potentially get you so far
But most of the times you are creating products, which means you are creating API's and now the frontend becomes just a part of the product and you might have a for example Android/iOS app. Now you need those state tranfers to those applications as well. And we are back to using JSON. It's hard to do right, everyone struggles with it. But, it is a devil we all have to deal with.
@@the-white-fang yeah you're right, for mobile apps or apis to sell, you kinda don't have a choice but to use JSON back and forth and do all the gymnastics for caching, routing, etc. But if it's a full stack app in which the BE and FE are tailor made for each other, I don't see a reason to not fully couple the BE with the FE like with HTMX. The rest is unnecessary overhead and complexity
Fantastic video guys, I totally get why you want to use HTMX now. I'm 100% sold and will use this technique from here on out, my biggest struggle was going to be learning how to get JavaScript libraries that were designed for the client to work on the back end and then send it to the client.
As a dev working backend, Prime is so right about the insanity of maintaining states on client and server. Also something like HTMX will win purely because for every front end app there are like 10-20 backend services. Ultimately any backend server that needs some small UI to interact with it will adopt something like HTMX
With SvelteKit you can also avoid future state and you can use the same server state reflection by load function. But HTMX have other issues - concatinate server response, in the worse case we a re back to server templates.
I agree with your core analysis and the problem which Htmx solves, and on paper it makes 90% sense - Until you try to build large apps with 100s of views and modern UX. Your current low-res experiments with Htmx is fine, now try integrate different clientside view components, transitions etc. into your Htmx on the client and see the mess you create. Its also very weird to hammer the server for every bit of html hydration - with SPAs or even Island architecture you can do a lot in the client and only at the end send the Json data back to the server. Your "greyed out delete" scenario is also moot, because it works even better in a clientside app, where your store/model is reactive on the DOM, so when your server responds after delete the store/model is updated. Htmx is fine for small apps with minimal UX expectations.
I went from PHP frameworks with vanilla JS to jQuery, to React, to Vue (I choose to not count Angular 1 and 2 as memorable), only to now be happy to get back to vanilla JS inside of a project based on Shopify Liquid.
As someone whose done development for over 15 years.. I see the potential for each way of accomplishing these projects but the one missing piece this while argument is this. When the internet started or allowed individuals to build websites or applications it was slowwwwww. So these frameworks were developed to mitigate the unnecessary backand forth communication between the front and the back.. yet today we have much faster hosting resources that scale and flex to basically eliminate the the time getting the data back to the user.. so in many ways these bloated frameworks like react are going to become unnecessary over time. This argument that you can just stay in the same language sounds more like you’re not very flexible or willing to learn. Also a lot of these languages share so much overlap these days.. going from one to another has some differences but you can easily overcome them in a few months or less. The whole point for having a backend code and frontend is so it can be far more modular and easier to adjust.. having everything in one place requires a lot of really clean, readable and understood functionality.. I do both frontend and backend at my job. Plus i need to know sql and tons of other code. Any of you guys just doing one or the other need to get out of your box.
The difference between these two viewpoints is what you optimize for: The smallest possible interaction delay versus keeping state purely on the server. The first benefits the user. The second is an ideological take. You can't have all state on the server AND minimal latency. What is more, the code I've seen from HTMX proponents and examples like the connect 4 app or the game of life demo looks like a couple steps back to me.
i understand why the detached front end and backend is a pain ... BUT in the real word you have mobile, a client facing API and web all sharing the same service. Its much more convenient to have the one API. You do not want your whole service down because web pushed a mistake.
It’s kind of funny to me that developers have essentially spent 15+ years trying to figure out how to recreate the web structure from 1999 without Flash. Flash made a lot of this stuff comparatively trivial, except it was a security nightmare and was horrifically computationally inefficient. Then, Google and Apple decided to kill Flash entirely and claim that HTML5 was the future. Next thing anyone knew, the web was full of bloated JavaScript frameworks all trying to do the same things Flash did, but it’s okay because V8 makes JavaScript fast. The security nightmare never really went away, because everything runs WebKit, and WebKit is full of holes.
I didn't understand what you meant by caching. What would be an example on frontend state resulting in a caching problem that server state would solve?
Having frontend as a pure reflection of the backend state is good, but there are certainly usecases for frontend states approach as well, e.g.: - applications that don't have backend state (e.g. excalidraw) - applications that have a lot of interactions that making a call to the backend on each interaction is impossible, in which FE acts as an aggregator to batch the state changes before sending it back to the backend I do agree that majority of usecases don't actually require a frontend state.
But at the same time the beauty is that with htmx you can freely use sever-rendered html, json and client state (react). So not only allows you to things on a simpler way, but allows you to easily mix methodologies and frameworks as suited.
htmx seems cool for many use cases. What I like about frameworks like nuxt is that you write your components once, you get an amazing template engine, code splitting is done for you. I can totally see it working with nuxt server components.
48:55 This is just exactly what we used to do in traditional web development (if that's what it's called) before React and it's related tech showed up.
The issue with React is that managing states is complicated... and nobody wants to maintain the same logic twice in both the backend and frontend, but they feel forced to because our backend is used to responding just with just some basic data, so you have to derive state changes yourself when building the UI in there. Anyway, writing components(or declarative templates) is way nicer in most cases, so you'll end up writing them in the backend as well. Also, writing simple transitional states, like graying out something while the request is incomplete, seems to be the same effort for both HTMX and React, so I see no validity in your point around that. The real issue is that people write too much logic in client code, and have too much trouble managing states. Making Frontend a whole mess in the long term. HTMX is nice for simpler UIs and I give you that. But if people just focused on writing better backend code that can return decent state changes for the frontend, then having a Frontend framework wouldn't give us so much pain. However, if we do want to provide state changes from the backend, why not just provide HTML?
I love how often the word "React" is mentioned in this (supposedly HTMX-related) video. I've been writing web-based apps for over 20 years now and I never had a chance to actually use React (and I don't plan on using it since Svelte and HTMX are already here). There are other solutions out there. I was able to skip React entierly going the "Frames/IFrames -> JS/Ajax -> jQuery -> AngularJS -> Angular -> Svelte -> HTMX" route (over 20 years covered in a single sentence). ;) Also: GWT and Vaadin are a thing if you really want to mix front- and back-end (I don't like them though).
When he gave the example of todo on client state (optimistic update) which is actually sort of better with the use of react query in react but htmx seems really good to avoid duplicacy in the first place.
I belonged to the Web 1.0 era (when JSP/Servlet/PHP/ASP Classic were considered as skills). I really like HTMX. If HTMX becomes standard, I wonder what the Front-end guys (react/vue/angular devs) will do now?
The ultimate solution to state synchronization will be the use of CRDTs. And as soon as I'm done implementing them all in Python, I'm going to port the library to Go and then Dart. It will be beautiful. Edit: with CRDTs, any number of online and offline state updates are guaranteed to eventually converge to the same state once all updates are applied, regardless of the order of those updates or the number of times they are applied. CRDT updates are commutative and idempotent.
HTML as state and AJAX(HTMX) as API is all good, but it only works on web, on mobile, desktop app or games you will need some other API(REST, GraphQL, ...)
HTMX should become basis for HTML6 spec, with but built in signing/checksum for requests from browser to prevent XSS attacks. HTML6+XSS protection based on HTMX will make webdev accessible for the noobiest noobs and truly allow everyone to "learn to code"!
@@alexandersuvorov2002 HTML is so simple a small child and perhaps even an illiterate person could write it. JavaScript is a big jump for those folks. Imagine if every highschool graduate was able to make a **bare bones simple** SPA, as naturally as they could do reading and writing? What would that world look like, if grandma and grandpa were able to host their own websites by just uploading a .html file to a Cloud provider like they would a pdf or zip file? Think big man!
@@jibreelkeddo7030 We’ve been through this already with Wix, Wordpress and Java. This idea of incompetent folks being able to produce anything beyond preconfigured framework demo’s didn’t work. We end up with crap code that propogates through the entire solution and ruins all the work by those who actually put hours into tech and quality pro-grade code. The whole existence of TypeScript is because there are folks out there who just copy paste code snippets from the web into the codebase without even trying to understand what’s in there. And lastly, no grandpa and grandma will be able to produce advanced frontend UI by just doing HTMX frontpage demo. They need to understand DOM and HTTP and JavaScript anyway, so why to force them study HTMX on top of that? Or do you expect there are businesses out there who would settle with basic HTMX code?
I like your perspective, and it is true, but state on client can be reflected or generated after backend confirms an action as done (success or failure), but writing it proper is difficult, delete example is easy to do with frontend frameworks, I never touched htmx but I imagine it makes it more clear, simpler and easier. I hate react by the way :).
Feels like, putting React on a Django backend is like taking your time organizing your home meticulously, and then spray it with confetti. I keep learning it because of Native, because I like Flutter even less.
I unsubbed from theo recently. Too opinionated, self-centered, holier-than-thou. I like some of the things he does but I just couldn't take the childish drama. Just me?
I like Theo because its funny. He is the classical JS dev who has strong opinions that are often pretty dumb. But that's what makes it so funny as long as you don't take it seriously. Similar to why I like prime, I don't actually respect most of prime's opinions, because he talks out of his ass almost all the time, but I don't take him seriously so it's just funny entertainment. You can't look at these influencer/entertainment dev's seriously, their content is just pure entertainment not really educational or anything.
@@derschutz4737 Fair point, about prime too. Influencer is the right description. I just think the attention-grabbiness got too much in the way of me wanting to learn some new tools, but I'm probably looking in the wrong space for genuine educational content. I think the only exception here is Prime's frontend masters course(s) (not including the random web3 one lmao), cause he curbs his intensity there lol
I think it makes sense, and seems to align on how originally the web stack was designed to work.... Javascript provides the dynamism, html the data structure, CSS the decoration.
It feels a bit backwards to move in the direction of htmx. I always thought offline-first (using CRDTs) was the next thing. But it does make a very old approach of writing webapps much easier.
Most modern applications fit more into the pattern: - Have a backend with some clean (well defined) API - Having (multiple) applications using these API (Mobile, Web, Other services...)
I've been doing things the way HTMX does it for about 15 years now and have never touched react. Apparently tech is cyclical, and if you're a lazy boomer long enough you become the hipster.
That’s so true I’ve noticed that as well after 40 years programming and 30 years of professional IT.
React is hot garbage, praise yourself lucky. Only cultists enjoy it.
Ditto. I have nothing against front-end code, love writing it, and I think typescript + JSX is really quite a nice experience, it's just a complete waste of time for CRUD and a ton of internal SAAS apps. These tools never needed React, and never will. I am continually frustrated by the pointlessly over-complicated approaches developers take for this stuff, not understanding the advantages of the old way, and how little effort it requires to make it a lot more like a SPA, rather than going full SPA.
One issue I have with Theo's video (and this moment in general) is I don't really see HTMX as a big improvement over LiveView or Hotwire. It's just one particular take, but simplifying XHR calls is a big win.
bruh, Ive been saying this shit all the time and im 10 years in the industry. Isnt React on the server (SSR) the same thing what we havbe been doing with PHP 20 years back like WTF and now people preach it
I'm new and always hated when someone just gave me a CRUD object like a logged in user and an order object. The order has status of "In Delivery", so can I cancel the order at this point? Who knows, maybe ask the other team overseas what the business logic is and replicate it on the frontend.
CRUD and inferring state has been the biggest pain I've experienced. Even when I was designing both ends of a site. I simply didn't know better. HyperMedia as a protocol and task-based UI (as opposed to CRUD) makes everything so much easier and shit doesn't break all the time when business logic changes.
as a dev in poland i can confirm that i am in poland and i sleep half the time
😂
Backend dev from Poland here 🙂. Did work with U.S company. Having meetings with client at 3 PM (my local time) and client just woke up was source of funny moments
I feel for the team in Poland, they didn’t realize they worked with a genius.
This is the clarification we needed 😂
Future dev from Poland.
How do you sleep? This thing is too complicated for me to comprehend
As a frontend developer, waiting for the backend team to make api changes is how I find time to watch these videos. Why change that?
Is it finished yet?
There is no BE.
Is it finished yet?
Basically GOTO 20.
I feel attacked... 😂
That's an invalid argument anyway. If there is no backend functionality e.g. to query the state of an order then how would you render that unavailable state in htmx?
You can't. Backend functionality has to be there.
And if you're telling me that you can extend the backend with functionality that renders the state in html then why can't you offer it through the backend API, which is even simpler?
Not me in this exact same situation lmaoo
This is why react and storybook are a thing.
So we don't have to wait for the backend
About the "nobody did single page apps before jquery" - Fun fact, I was writing arcade game clones, and single-page apps back with IE4 and NS4. I pulled data in using hidden s, and DHTML for animation. I wrote a bunch of games, Galaxians, Tempest (using VML), Frogger, Pacman, Pengo, Donkey Kong etc all using the original arcade graphics and running at full framerates :) I then got a cease and desist from Nintendo and had to take a bunch of my games down. This was over 20 years ago...
Dayum bro, you were the Man
Legend!
@@GeneraluStelaru Oh forgot to add I also did some multiplayer games, like video pool so people could challenge eachother. The games engine I wrote (open source) had functions to add multiplayer easily using the my site at the time and we had a really active forum of games developers - I hosted their games on the site for free. The main reason I ended up shutting it down was because the hosting costs became ridiculous as other sites were linking directly to the games. I also had chat channels that became really busy, it all used JS and then Perl on the backend at the time. Good days :)
Damn that's epic :o
So many Legends lurking in primes community
Im so glad I discovered HTMX on your channel. I never liked the complexity of frontend frameworks. Or why Frontend even requires so much work since logic and state should always be on the backend. I just want to display the stuff that is already there.
Ekhm... Php is there for 20 years...
@@alang.2054 but php wasn’t as good as other languages in the early 2000s!! Completely unusable in modern day bc it hasn’t had a single update since then smh my head it’s exactly the same
@@ajbrady4357 wait what?
Not the biggest fan of PHP (used it enough to know its not for me), but what you're saying is just plain wrong.
1st Good as what other languages? PHP was originally template language for WEB - giving possibility to make from static HTML a Dynamic HTML Server rendered pages (yea a the new FE things :D ) when mixed with JS (the vanilla flavor or later JQuery) together with ASP Pages from Microsoft was one of the pinnacles of the Web development.
2nd PHP is well they are at their 8.x version now - yea its not moving as fast as JS frameworks 20 versions per week (which is a good thing actually).
So love it or hate it one thing, want to use it or not is another, but its not fair to say its dead or not suitable for modern use :)
@@simm0l my apologies I was being extremely sarcastic
Most of the arguments made in the video are invalid. The idea that "with htmx there is no state at the frontend" is simply false.
Let's say you make an order and the backend sends you "Order in state: Processing" and an enabled "Cancel order" button. That is a state, and it will diverge from the backend state over time. Because the backend will process the order and change its state possibly to a state where cancellation is impossible.
So the backend logic has to check for invalid actions resulting from invalid frontend states anyway. So state-wise you haven't changed or fixed anything.
And the backend logic that renders the enabled "Cancel order" button will still be distinct from the logic that handles order state transitions. So you haven't unified logic either, you've just moved it to another place. And it's not better in that place anyway.
The same info that you will use in that backend logic to determine what the next valid/possible states are could just as well have been sent to the frontend.
There are quite a few points about the "backend defining the actions" or "it's already done on the backend so why reconstruct on the frontend" but the crux of this is poor contracts between front and backend. Almost all of my experience has involved multiple clients talking to a source of truth e.g. multiple native apps, machine to machine integrations, web apps and microfrontends. When you have to serve multiple clients the contract is the most important thing, not whether you use a backend first or frontend first framework.
Roy Fielding did a poor job explaining the concept of a restful service. He never managed to get people build restful api the way he imagined.
HTMX is moving people towards the right direction, but the root cause of the issue is poorly define contract on the backend.
I was doing htmx 10 years ago with my own attributes "my-post" "my-get" instead of "hx-post" "hx-get" and engineers were shouting bad practice 😃 Programming is just fashion.
this is my issue with React mainly too.
I did a lot of es6, jquery etc, and dabbled in few frameworks a little bit. I've come to the field late, graduaded like not too long ago from uni. And looking at a lot of the web dev stuff, i feel there is a lot of dev glasses what i could say. I fully understand why React is used, since writing anything in plain JS/Jquery when it's complicated and animated interactable element can get painfull and hell to manage, but at the same time, i aggree fully with Prime, with that React abstracts soo much to the point where you start to think "React" instead of thinkg webdev. Another thing i feel is there is just this emotional burden that makes people feel certain tase on frameworks where despite very often them being good at the same things, they will tribal to gating something. I don't have strong attachements to it or Angular, but at the same time i don't understand the Angular hate since both generally feel "simmilair enough" to me(would probably feel the difference on something more complicated, not arguing there), and it's hard to not think, it;s the issue of if somethings a hammer, everything becomes a nail.
This is why I started to learn Svelte. When I was introduced to React, it felt like I just had to throw out all the HTML, CSS, and javascript I had learned previously to learn the React way and then learn the React ecosystem, but the react was didn't feel applicable to anything but React.
At this point I've shoved most of Angular out of my memory cause i hated it so much, but i remember it feeling super clunky and cumbersome, with poor documentation. Every simple thing i wanted to accomplish would take 4x as long as it should have in Angular, it was constant wrangling. I switched to Svelte and i love it; Svelte is what i wanted Angular to be.
Svelte solves all these issues. Feels like an easier version of vanilla web development, not different. I even use plain css everywhere instead of adding more.
1000% agree with Prime's diagram around 31:00. That's exactly it, the point I have been wasting time making on Reddit for years. Having a full client-side state based on JSON is unnecessary duplication of state.
Exactly so. I do not understand why front-end developer do that. Of course, I also think SPAs are an utterly terrible idea in 80-90% of cases and that simple jQuery development with page transitions blows most SPAs out of the water.
@@thewiirocks some leads prefer to have decoupled backend APIs, so that you can make a new frontend with ease, e.g. introduce a mobile client.
@@ivanjermakovThat can be solved by having separate services for each client though. Mobile client calls mobile HTMX server that serves mobile formatted HTML. ideally though the load profile is similar so the same service could handle all the clients, just returning different HTML based on endpoint / API. Could still have a pure JSON backend service
@@thewiirocksbut... Htmx is SPA.
When working with frontend frameworks, you don't need to have the application state in a set of JS object. You can, if you prefer, just apply a template from the responses of the server (which is better than html payloads). This is an architectural concern that htmx enforces but can be done with frontend frameworks.
for me no other js library was exciting to me like JQuery of old it will always be my sweetheart she never complains about your setup never argue with you about your build preporcessor or packages. i curse the days i switched to React because it was "cool" and "new girl in the bloc" but now HTMX is like my mistresse reignited my love for simple CDN libraries that have the same montra "CODE LESS..... DO MORE"
We are so back.
@@D4ngeresqueonly that cdns dont mean the same as they used to, chrome now due to privacy holds every script for every site
"Let the man cook." Pauses every 15 seconds 😂
haha
so true
So agile
Absolutely, using React since 2013 is way different than using it since 2018. The shit the rest of us have had to go through. Dark times for the frontend world that made me miss jQuery every day. I avoid React as much as I can because of that 2013-2014 era.
I once got asked in an interview "class components or hooks" I was like: "class components are more straight forward, useEffect and useState are bloating the code and make it harder to read".
I started coding in React in 2016 and.. I did not get the job, I was still loving componentDidMount etc but understood what the market was after and the direction that react was going towards.
I ended up loving hooks, but now I am doing Svelte.
How does Prime fit 40hr/week at netflix, streaming for a ton of time, being a dad and going to the gym into his schedule?
He prioritizes health so he has a healthy body and mind to do all these things
@@perc-ai lol. That doesn't really help.
He's talked about his schedule before and the answer is some combination of: he doesn't need as much sleep as many of us, he works from home, and he has a significant other that can help with much of the house/childcare aspect of things while he's busy streaming/etc.
It's quite likely he also doesn't work 40h exactly as almost no dev workplace requires that if the tasks are done.
@@bobbycrosby9765 bro cut the bs you do realize health is key right? you think he gets 5 hours of sleep or something lol this dude has streamlined his life so well hes able to do all this stuff. Health sleep wife/kids remote job all of it comes into play to understand how hes so alert it also helps to have an iq of 140+
@@danielsharp2402I'd say 99% of jobs are not like that, you need to be green in the chat and available for any issues or chats...
How does he manage to make a reaction to a 12 minute video last 50 minutes. Truly a talent many RUclipsrs would like to reach the 10min mark for multiple ads.
at least he doesnt just sit there and watch the video with nothing to add like many reaction streamers/youtubers do
So he's basically Asmongold
This is a really profound video for me who's just new to these stuff. Really awesome!
Just my 2 cents, I think that while state management is a good concept, using a single word "state" to shoehorn every single value/variable/cache/element into a single concept and then trying to say general things about that (and only that) can also be counterproductive. In prime's example of the game of life, it might make sense to talk about the "client state" for things like what the currently alive cells are, while at the same time acknowledging that things like managing your "savegames" bring with them the challenges associated with managing such state for which ultimately the backend is the source of truth (assuming for the moment that thats where the "savegames" are stored). It would be counterproductive to either require all the state to be a reflection of what the backend knows, while at the same time it might overcomplicate design if what savegames the user sees in their "html" cannot simply be seen as a reflection of the data in the backend
Also for me it is simply an argument of whether to do things sync or async that simple. As it all boils down to that. And all design patterns and mistakes there off start from there till the perfect meeting point on the middle where no one reaches. Htmx has a latency issue, react has a concurrency issue. 2 different problems 1 same scenario. In an ideal world sync is right, bt its not, so I still prefer to react for now. Tanstack has tools for th state mgt problem so i think we are good enough for now. Only problem is carrying all the inneficiencies of react basically technical debt
One thing I like doing depending on what i'm building, is to build a backend in rust with axum and askama, then load htmx and twind from a cdn; that way you're basically guaranteed to never send more than around 20kb of js + css to the client, then all your ui is just declaratively embedded in your html template.
In his story about music service, it sounds more like his company had especially bad team of backend devs, or their backend stack was bad for their use case. In no way a technology change can singlehandedly make one Theo backend dev replace 8 backend devs.
I totally agree. Am willing to take a solid look at htmx and how it would fit into my little mindset
Wait a minute this looks like what I did (used to do?) with C# and XAML for UI. I always wished it was like that for the web too. Never got the hang of react. State management seemed so complicated and stressful.
Nice, HTMX. Gonna check that out. I was actually floored with the other demo that you did a video on. The article loading thingy
Hey... another XAML user. I loved working with XAML and when I crossed over to start working with web stacks, I felt how broken a lot of these things were. I ended up using Blazor to use the same language in the front and back. Now that I'm using Go, I needed something else to do my web frontends when I need a front end (not going to bring in C# and Blazor right now) and HTMX is a godsend. I'm sure you'll enjoy it.
An htmx backend seems cool! Really snappy and intuitive for its purpose. But eventually in your business growth it is time to build a mobile app. With a backend spitting out html instead of data, how do you handle that with an iOS/Android/Cross platform app? I might not get the whole picture here, but it feels like kind of a technical lock in to build a backend that focuses on producing html documents like back in the days.
Great point!
That's a good question.
Ideally, business logic should be de-coupled from the delivery layer (HTMX in this case). If the business then wants to build a mobile application, we build a separate delivery layer (say, REST) and re-use the existing business logic.
It may be more work later, but it makes HTMX seem viable if the business is unlikely to go for a mobile app anytime in the near future.
maybe use the BFF pattern for this, split the views for web and mobile
@@LePetitMondedePurexoYT Agreed. I log in to ebay and facebook using the browser on my phone, just cause I don't want yet another app nagging me for permissions to read my e-mail contacts etc.... It is amazing how many of the big websites struggle with all of this regardless of the responsive layout stuff. There is almost always something that can't be done on the mobile web version that requires the app. When an app may not technically be necessary AT ALL......
This is my favorite reaction. Video of yours! You make your points eloquently, and with a modicum of screaming :-)
Personally I think the way that Phoenix liveview does things is the best way. It's a two-way binding between your elixir app and the so-called client which is effectively just a web socket. You actually don't even need any HTML in your project (outside of the root template). The state is maintained by the processes and elixir has some extremely powerful fault tolerant tools to keep things synchronized. As such you can just have a single process with the state and you can use the pub sub to proliferate the state out to the clients, It's inherently simple.
Ryan Winchester fighting the good fight in the video.
Yeah, what makes Liveview different is that the state is all server side. This makes it a joy to work it from the backend (speaking as a full-stack dev)
Don't even need any HTML in your project? But what would I still have to write? Does it generate the html and css?
@@NoidoDev "don't need any HTML" isn't quite right. There's still HTML, but there's no front end JS code at all. It's all server rendered HTML, with server side logic. Templates are rendered fully hydrated on initial load, then dynamic content is updated by re-rendering the partial templates server side, and sending the minimal partial diff over a websocket.
The workflow is that you're just working with plain old partial HTML templates in one place. Very high performance, good SEO by default, and don't have to have separate server and client side code, so is quicker and easier to write, and much more maintainable.
There’s a client side JS library to load, but that just does the Websocket and DOM updating logic, and is tiny (like 80kb I think)
It’s like of server rendered react components but… done right.
@@madlep
Okay, sounds good.
We all know the proper way to synchronize state is call GET /entire-application-state every time a user interaction happens and also in a 50ms polling loop in three different places. Make sure you're calling this server side and on the client and hydrate redux with deep copies of the response so that spontaneous renders are constantly happening.
Online multiplayer video games be like ☝️
i have made this point before 44:00 htmx is really good if you have lots of permissions and logic and not everything as public. i totally understand this, i have worked on projects where people just keep asking for dumb permissions on who can see what with lots of backend logic. validations and syncing can be a pain, but if I just had htmx back then, everything would have been 1000x simpler. i mean i would literally need 0 js. literally.
i wanna use it.
but if you have everything as public why spend time querying the db, generating the html then sending the html. while client can just query the db and generate the html itself. run the logic itself, invalidate bad data itself, and never ask for a permission. why not just have a dumb server.
so i agree
This my approach to webdev... in the long run I want to do as much logic as possible on the front-end than on the back-end. Why? more resources on the front-end. it's just that simple user's PC/Tablets and Phones as insanely powerful, for an indie developer like me server resources are severely limited
If the html us public, you can probably cache it. If you can‘t cache it, well, you have to generate the data either way.
Rendering html vs rendering json should not be a huge difference either. Same for the size difference if sending html vs json.
@@hardcorecode This is a great point!
You remind me of Uncle Reco. "If Falcor ever took off I'd have been someone!" "I bet that I could throw this API over those mountains."
Very nice take about how you see it as a state problem, even I with not much web dev knowledge can 100% agree HTMX seems to reduce state sync problems and how you described it with the delete button was nice!
You can do that with JS why don't wait for the response before applying the change
For my personal use cases I basically need Static Single Page Applications that update once in a blue moon. And for work use cases we see iOS, Android and Web as three platforms; literally no server side rendering (not even for SEO). HTMX sounds nice and I'll probably never use it :D
OMG, how did I miss HTMX? Trend of near always connected will continue. Solutions over the past several years always felt like temporary fixes to me until offline is a thing of the past. Will have to try this.
One of my old mentors told me when PHP vs ASP was a debate that we moved from thin clients + server -> move it all to desktop with thin server -> back to thin client, but now it's the browser and not the full system that's the "thin client". I feel like after he pointed that out that it's still playing out, just at a slower pace than we had figured.
Lots of projects don't even need htmx. Screen rerender can be blazingly fast for admin panels like Djangos cms. Hyper interactivity is over-rated.
Disclaimer, I'm currently mostly a frontend React dev but I also had a lot of experience on Java/Kotlin backend. I haven't used HTMX but it sounds a lot to how we structure the code at my place of work in the sense that the BE isn't just an endpoint to get data but it actually tells us what we have to render and then we just render it, the biggest problem that I've encounter with that approach is that it creates a very tight dependency on both ends, we in the frontend cannot change anything before it going through te backend so we usually have to wait for them to finish their implementation or have to agree beforehand on one and then start coding; and the backend cannot change anything that affects the frontend (returns, endpoint interfaces, types) without getting our approval first, or else it could break the frontend.
so, htmx is just lightweight good old frames. amazing innovation
LOL, yes without the frames
Damn that dudes handsome, should have just let him do the vid
I prefer the Astro approach where everything is HTML (to the client) untill you want an escape hatch. Everyone wins in this approach.
100%
Great to see HTMX finally reinventing Ruby on Rails! It just took 19 years. We are back to square one.
Except you don't need to write Ruby. So I'd call it an improvement.
@@W1ldTangent Yeah, if you don't like programming / software engineering just knowing HTML can work out up to a point.
@@W1ldTangentjajaja you get the point.
@@sokacsavok I use other languages, have tried Ruby/RoR as well and just never saw what others saw in it. There were many better languages and frameworks then, and even more now.
@@W1ldTangent You mean like Javascript? A language where '2' + 2 = 22? I never got why others didn't see the benefits in RoR, still nothing has come close to it. Ruby is stable, flexible, consistent and great language. Rails is mature, well thought out, easy to use, just needs some learning.
What's good about React isn't React itself; it's the ecosystem around it. It's become very difficult to create modern UI components with accessibility without using something like RadixUI. Tailwind is creating Catalyst to compete and it's React-based. For example: a dropdown that responds to keyboard events and changes its orientation in case it's getting hidden. Good luck doing that with HTMX without a lot of custom JS.
Exactly. And that's why companies still choose React for any new projects. I worked with companies choosing Svelte and it's consistently because they don't care about things like accessibility.
WebComponents my friend, htmx is standard friendly. 🤷♂️
Ecosystem is a poor argument. Angular also has an ecosystem around it. A company can build up an Ecosystem to support anything they use. HTMX can have an ecosystem too. But people really should have a mindset of thinking what the existing html standards support before reaching for something external.
I basically wrote a super simple version of that when I made a pretty bad web server framework in Rust.
I really love htmx so far.
The problem with the practice of front-end frameworks like React is you're offloading more of the work that can be better handled by specially-built server software onto clients that are a lot worse in processing power and have to do a lot more HTTP transactions to make up for not repeating yourself a bunch of times in backend services. Progressive enhancement should have been the goal, but there's a lot more thought necessary to implement it properly, and companies loathe paying any kind of debt, especially tech debt.
The Django roast was my favorite. It's always been Django, it will forever be Django. I watched Theo's video first before this one and I thought "why does this guy think that there's any change over time in the web framework in Python land??"
For years, I've contemplated diving into the world of React, Vue, and similar front-end libraries/frameworks. However, it often appeared that these tools required a substantial amount of setup and configuration compared to what I could accomplish with Django sessions in conjunction with Ajax or HTMX. Strangely enough, I've consistently found that my web applications and sites remain just as snappy and interactive as those built with React. It's possible that I might be overlooking some key aspects, but I can't help but wonder if the perceived complexity of these front-end libraries is sometimes unnecessary for achieving impressive performance and interactivity on the web.
I had the same concern as you and why I picked Vue over React. Vue requires no setup, not tooling, nothing (unless you want that). Can be integrated into any existing architecture no matter how legacy without a problem since it's so stand alone. Got Vue working in no time with an old but very large site built in WebForms which would be completely incompatible with anything else.
@@vripiatbuzoi9188vue is amazing shout at Vue
Totally! The frontend's only job should be "display shit". I don't get why our angular frontend has to rival the backend in size and complexity.
After a long time of watching the htmx hype I finally feel I understand why, What you said prime makes sense. But my intuition still blocks me from getting convinced that HTMX is something actually useful. Here are my reasons:
1st I feel nice when my server is responsible for data transferring and not HTML templating. I understand that that was web 1.0 as you said but since the web complexity has risen undoubtedly, I've ended up really liking my server not being responsible for any templating.
2nd is that even if I accept that generating HTML on the server is the way to go and it makes sense to have my policies on my backend along with the templating stuff, I'm honestly scared about the AMOUNT OF CODE it would be required to create a modern UI UX experience the one that an average user expects. I imagine for example creating a data template to bind for a simple interactive page with html/template in go and MAN this sounds. I would prefer to send the data over the wire and have a UI tool that really helps with updating these kinds of things. I don't feel that HTMX complexity increased template complexity significantly. Again, I fear more about the transformations in your backend language in order to render the x piece of data and it's 5 derivative states in a Go code base for example. I feel the "maturity" of the js ecosystem is shines at EXACTLY this spot, my favorite recent way as with anyone being signals of course.
This is why I think I like the split backend-frontend. I hate the modern framework complexity and I've been heavily working with it since 2015. But I don't feel that returning the templating the the server solves this. I'm already having nightmares maintaining all the interactions within both a template and a server that generate that template and it's bound data. I think I prefer to simple get a bunch of data from the server and manage my interactivity and state in the browser. And even though I get where you're coming from, it's hard for me to even imagine how this is easier.
Would really like to discuss about this. @ThePrimeTime
It might have to do with the type of applications you write.. if you are writing a back end heavy app with a skinny front end & you don't pay for the extra network round trips to the server - HTMX is a great solution. I find it being a easier sell to predominantly back end teams that need UI - think Intranet/Corporate apps (wonder who still uses those terms :) ) .. If your server side code is sitting on Cloud functions like Lambda where you want to carefully audit network i/o, then HTMX might not make a lot of sense (depending on how chatty your app is )
An interesting angle here is that the amount of traffic to serve a given number of clients can be substantially reduced if you send protobuf to a wasm frontend as compared to html/x for every click.
@davidjdriver that depends on the session duration. If your user spends 30-40 min on your page doing stuff, maybe 1-2 MB of burst bulk upload is cheaper than thousands of tiny requests 1-2 KB each.
Love your version and a better explanation, business logic stays on the backend just use the front-end to display the actions in progress. Based on a high speed network it's great.
For internal apps that really don't need a fancy UI with all the bells and whistles as long as it works, and one would hope adequate network speed, I can see it being a significant time and effort saver for the developer.
It's also nonsense. Most of the arguments presented are invalid.
In reality you haven't eliminated frontend state and you also have not unified business logic:
Let's say you make an order and the backend sends you "Order in state: Processing" and an enabled "Cancel order" button. That is a state, and it will diverge from the backend state over time. Because the backend will process the order and change its state possibly to a state where cancellation is impossible.
So the backend logic has to check for invalid actions resulting from invalid frontend states anyway.
And the backend logic that renders the enabled "Cancel order" button will still be distinct from the logic that handles order state transitions. So you haven't unified logic either, you've just moved it to another place. The same info that you use in that backend logic to determine what the next valid/possible states are could just as well have been sent to the frontend.
@@xnoreq it not just logic in the process, but rules, logical I can sell to you in any country but others have the Asian Pacific rights so I cannot deliver there for this product. We see that daily with netflix this is not allowed in that country or region, do we allow a front end overrule the backend.
@@colemichae That is business logic. Just because it includes the word "logic" does not mean it is limited to the classical/mathematical understanding of logic.
Business logic may, in fact, contain illogical rules.
To your example:
First of all, when dealing with rights, this has to be done in the backend anyway, regardless of where you do rendering.
You cannot trust the input of the client (which includes its state, rights etc.).
The backend can simply deliver a list of valid/possible countries the company can e.g. ship a product to. The frontend can then render this list of countries however it likes.
The backend also has to figure out where the user is coming from using an IP geolocation service. You cannot trust the user's web application or browser/operating system settings.
If it turns out that the user is in a country where the company holds no rights to sell the product then the backend simply will not include that product in the data response (or include it with a NotAvailableInYourCountry flag if you like to render it in the frontend in a disabled state).
The frontend should never ever be able to overrule the backend.
37:10 :
What technique to employ heavily depends on your use case. Having a throbbing (probably long 😏) loading bar is not always the best solution. Although it is the clearest and most understandable in terms of what is happening, it comes at the cost of responsiveness.
If you have an app that needs to work in a low/none reception area having to wait for a Server response can be quite agonizing. Think of a package delivery service that needs to take in signatures in a Village at the ass of the world.
as long as you make sure that the rest of the app is still responsive during the throbbing, it should be fine. the main context i can think of where it's a problem is if you create a new item and need to wait for a response from the server before you can start filling it in. in that case you need to greedily make the item.
though, i guess it can also be an issue when you want to edit a thing again after having changed it, but before the server has responded to the first change, which is kind of a tricky situation to sync properly, but can also be very annoying for the user. a typical example of this is a "like" button, which you might accidentally tap and then want to undo, but can't do it until the server has responded to the first tap.
so i guess in the end, the only part of CRUD where it's not annoying to experience a long throbber is the D
One thing I don't like about this channel is when it's comparing apples to oranges. I understand comparing technologies that do the exact same things. However, in this case React and HTMX can serve different purposes, and both offer capabilities depending on the use cases. Just choose the tools that are specific to what you working on. It's good that we have all these different options.
The most generic answer ever without understanding the problem.
The comparison issue of apples out orange is warranted when you have a problem domain and the solutions and trade offs are either going to benefit the Apple or the orange.
You are randomly throwing randomized quotable in a careless manner. An Apple can be compared with an orange of my damn use case or problem is clients want Apple pie and not damn orange juice. Same thing is when you work in a new company with millions of dollars on the line to solve an engineering problem with its constraints and you have to make really great comparisons on what helps progress the product.
I think that the components+reactive direction is good. React is just a part of an evolution towards that direction.
Yea, looks like Angular was right all along
Watching this, my last 6 years of web development feel like i've wasted a lot of businesses money, time and opportunities by simply sticking to JS frameworks for the sake of just having it.
I hate what i've created. I learned a lot, but I hate it.
Doing web dev since ~2005. Had some adventures with (P)react, vue and other technologies. Always went back to mostly hypermedia because it burns less time/money. Currently my apps consist of native custom elements, hypermedia and some sprinkles of js modules here and there. BTW i mostly code PHP - take that fancy framework kiddos 🎉
What if I use php AND a framework? 😈 (Laravel + AlpineJS 💪)
@@benbowers3613 i add petite-vue if i need that kind of client side reactivity 👍
me Laravel with inertia. Its so piece of mind with unnecessary state management in frontend
Gigachad PHP dev
@@DefinesleepaltI use arch btw
If your architecture includes GraphQL, your Backend is the SQLDB. Everything else is frontend. All these hoops just to render an SQL table to HTML. Hot take which is true for 99% of Apps (especially in the enterprise) HTMX + any template language makes more sense here.
2:09 In Laravel, you can do the exact same thing wih Livewire. It's the same process: Laravel generates an AJAX request that fetches the output of a PHP script on the server when there is a need to update the frontend. And it does not refresh the whole page. It's been there for a while now...
Yes, Livewire just does it better
@@depafrom5277 But Livewire is vendor lock. You can combine HTMX with any backend, not just in PHP.
Definitely agree with the emotional toll of working with React before 2018.
I still have nightmares from their "revolutionary" Flux architecture. (un)Holy mother of over-engineering Batman!
Video games are not an example of server state. The game analogue would be sending the whole game down to the client (HTML analogue). Once you exit the game, there would be nothing left on your PC.
Instead, games are pre-installed with gigabytes of data. Clients only exchange minimal data with the server. Some information is exchanged between clients directly instead of the server. Games will typically also have a lot of state and processing that happens on the client (games can be GPU and CPU intensive). The client only talks to the server to persist or load data, just like SPAs. Some singleplayer games are completely offline.
The problem with server state is that raw state is not the whole app and visualizing it is something that fits better into the client and needs to be done close to the user.
You will love the paper "Out of the Tarpit". BTW, that paper inspired Clojure. Highlights state management as top priority issue in Software development.
Failing optimistic updates are an edge case, not the majority case. Which one should we optimize for?
If an optimistic update fails, you can recover from it by keeping the previous state until the server responded. Or by refetching the state. Libraries like TanStack query have both strategies built-in. Or you just wait for the server depending on the case.
Then there's all the client-only state that the server doesn't even know about. Like the tree expansion state of a tree view that every client has its own instance of. Why do that through the server?
it seems reasonable to me that there is client state that the server doesn't need to know about. I guess when the client is directly reflecting state from the server though, server side rendering could make more sense because you avoid duplicating the data structures?
(I'm new to all this but just trying to wrap my head around these discussions)
For me I feel like people who are in the HTMX camp don't want or don't care about UI/UX in the long run! I am really curious how easy is it to change or add features in HTMX two years into development
@@hardcorecodeNot every app is in perpetual development
@@catalintudorciurte309 if paying users are using your app then it's in perpetual development (ci/cd) or your paying users will go somewhere else.
I'm surprised or confused by Theo's perspective at 18:55. Most Frontend-teams I've seen handle clientside AND serservside (what Prime calls the Middle End) and the Backend-team served an API. We have been handling dynamic client updates (like in Search forms) by clientside fetching partial views rendered on our server.
The one Theo thing in this video that I do conceed is that my frontend team does have to wait for the backend team to add stuff to the API-data
Man I so agree with this. It's so nice to not have the JSON layer ie from frontend to JSON to backend to JSON to frontend. In between things can go wrong.
And just to sync state and data, you need things like redux, RTK query, sagas, react query, for navigation it's react router or whatever solution etc. React has been relying on so many 3rd party libraries that try to solve bridging the gap between Fe and be. And these are just not simple libraries, they're whole concepts to learn to even use right.
But a stack like HTMX, Alpine.js, Tailwind and maybe Go for the BE can potentially get you so far
But most of the times you are creating products, which means you are creating API's and now the frontend becomes just a part of the product and you might have a for example Android/iOS app. Now you need those state tranfers to those applications as well. And we are back to using JSON.
It's hard to do right, everyone struggles with it. But, it is a devil we all have to deal with.
@@the-white-fang yeah you're right, for mobile apps or apis to sell, you kinda don't have a choice but to use JSON back and forth and do all the gymnastics for caching, routing, etc. But if it's a full stack app in which the BE and FE are tailor made for each other, I don't see a reason to not fully couple the BE with the FE like with HTMX. The rest is unnecessary overhead and complexity
@@nanonkay5669 I completely agree with that. Use whatever best suits your needs. HTMX seems really fun and I hopefully will get to try it out someday.
Fantastic video guys, I totally get why you want to use HTMX now. I'm 100% sold and will use this technique from here on out, my biggest struggle was going to be learning how to get JavaScript libraries that were designed for the client to work on the back end and then send it to the client.
As a dev working backend, Prime is so right about the insanity of maintaining states on client and server. Also something like HTMX will win purely because for every front end app there are like 10-20 backend services. Ultimately any backend server that needs some small UI to interact with it will adopt something like HTMX
With SvelteKit you can also avoid future state and you can use the same server state reflection by load function. But HTMX have other issues - concatinate server response, in the worse case we a re back to server templates.
I agree with your core analysis and the problem which Htmx solves, and on paper it makes 90% sense - Until you try to build large apps with 100s of views and modern UX.
Your current low-res experiments with Htmx is fine, now try integrate different clientside view components, transitions etc. into your Htmx on the client and see the mess you create.
Its also very weird to hammer the server for every bit of html hydration - with SPAs or even Island architecture you can do a lot in the client and only at the end send the Json data back to the server.
Your "greyed out delete" scenario is also moot, because it works even better in a clientside app, where your store/model is reactive on the DOM, so when your server responds after delete the store/model is updated.
Htmx is fine for small apps with minimal UX expectations.
Hope he takes note :|
I went from PHP frameworks with vanilla JS to jQuery, to React, to Vue (I choose to not count Angular 1 and 2 as memorable), only to now be happy to get back to vanilla JS inside of a project based on Shopify Liquid.
00:25 have you guys kissed ?
Lmao, as an old school laravel dev who just wrote a robust and expressive templating engine for Nim, and also just discovered HTMX… I’m so stoked haha
So what you are saying is that we need to write our server code in HTML!
As someone whose done development for over 15 years..
I see the potential for each way of accomplishing these projects but the one missing piece this while argument is this.
When the internet started or allowed individuals to build websites or applications it was slowwwwww. So these frameworks were developed to mitigate the unnecessary backand forth communication between the front and the back.. yet today we have much faster hosting resources that scale and flex to basically eliminate the the time getting the data back to the user.. so in many ways these bloated frameworks like react are going to become unnecessary over time. This argument that you can just stay in the same language sounds more like you’re not very flexible or willing to learn. Also a lot of these languages share so much overlap these days.. going from one to another has some differences but you can easily overcome them in a few months or less.
The whole point for having a backend code and frontend is so it can be far more modular and easier to adjust.. having everything in one place requires a lot of really clean, readable and understood functionality..
I do both frontend and backend at my job. Plus i need to know sql and tons of other code. Any of you guys just doing one or the other need to get out of your box.
The difference between these two viewpoints is what you optimize for: The smallest possible interaction delay versus keeping state purely on the server.
The first benefits the user. The second is an ideological take. You can't have all state on the server AND minimal latency.
What is more, the code I've seen from HTMX proponents and examples like the connect 4 app or the game of life demo looks like a couple steps back to me.
i understand why the detached front end and backend is a pain ... BUT in the real word you have mobile, a client facing API and web all sharing the same service.
Its much more convenient to have the one API. You do not want your whole service down because web pushed a mistake.
I dont tend to agree with theo but I thought he presented a well thought out take.
yeah! i think there is a lot there
It’s kind of funny to me that developers have essentially spent 15+ years trying to figure out how to recreate the web structure from 1999 without Flash.
Flash made a lot of this stuff comparatively trivial, except it was a security nightmare and was horrifically computationally inefficient. Then, Google and Apple decided to kill Flash entirely and claim that HTML5 was the future.
Next thing anyone knew, the web was full of bloated JavaScript frameworks all trying to do the same things Flash did, but it’s okay because V8 makes JavaScript fast. The security nightmare never really went away, because everything runs WebKit, and WebKit is full of holes.
I didn't understand what you meant by caching. What would be an example on frontend state resulting in a caching problem that server state would solve?
In most apps I've worked on, the front end state is just a cache of the back end state.
Having frontend as a pure reflection of the backend state is good, but there are certainly usecases for frontend states approach as well, e.g.:
- applications that don't have backend state (e.g. excalidraw)
- applications that have a lot of interactions that making a call to the backend on each interaction is impossible, in which FE acts as an aggregator to batch the state changes before sending it back to the backend
I do agree that majority of usecases don't actually require a frontend state.
he did show that even in those cases HTMX is usable and easy, Game of Life is kinda the ultimate client side state machine.
But at the same time the beauty is that with htmx you can freely use sever-rendered html, json and client state (react).
So not only allows you to things on a simpler way, but allows you to easily mix methodologies and frameworks as suited.
What about 3rd parties using the same API as your client app? With HTMX your API doesn't exist?
It does it just actual REST, but yes if you need a RPC "data" api then it doesn't
This is one of the best video of the last time ...
htmx seems cool for many use cases. What I like about frameworks like nuxt is that you write your components once, you get an amazing template engine, code splitting is done for you. I can totally see it working with nuxt server components.
The question crossed my mind, "is Nuxt really the middle ground between htmx and react? The best of both worlds, so to speak?"
48:55 This is just exactly what we used to do in traditional web development (if that's what it's called) before React and it's related tech showed up.
Django Unchanged
As a person learning to program, I didn't realize things didn't work like htmx and it just makes the most sense to me for things to work that way.
The issue with React is that managing states is complicated... and nobody wants to maintain the same logic twice in both the backend and frontend, but they feel forced to because our backend is used to responding just with just some basic data, so you have to derive state changes yourself when building the UI in there.
Anyway, writing components(or declarative templates) is way nicer in most cases, so you'll end up writing them in the backend as well.
Also, writing simple transitional states, like graying out something while the request is incomplete, seems to be the same effort for both HTMX and React, so I see no validity in your point around that.
The real issue is that people write too much logic in client code, and have too much trouble managing states. Making Frontend a whole mess in the long term.
HTMX is nice for simpler UIs and I give you that. But if people just focused on writing better backend code that can return decent state changes for the frontend, then having a Frontend framework wouldn't give us so much pain.
However, if we do want to provide state changes from the backend, why not just provide HTML?
If you are maintaining the same logic twice something is wrong with your design
I love how often the word "React" is mentioned in this (supposedly HTMX-related) video. I've been writing web-based apps for over 20 years now and I never had a chance to actually use React (and I don't plan on using it since Svelte and HTMX are already here). There are other solutions out there. I was able to skip React entierly going the "Frames/IFrames -> JS/Ajax -> jQuery -> AngularJS -> Angular -> Svelte -> HTMX" route (over 20 years covered in a single sentence). ;)
Also: GWT and Vaadin are a thing if you really want to mix front- and back-end (I don't like them though).
I think that`s way too many 80s porn mustaches in one 50 min video that isnt a 80s porn!
90% of React developers only use 10% of React.
Spaghetti code, but _inside_ HTML? That's a recipe for success
When he gave the example of todo on client state (optimistic update) which is actually sort of better with the use of react query in react but htmx seems really good to avoid duplicacy in the first place.
Those guys look like the brunette twin and the blonde twin 😂
More like a competent engineer and a close-minded web dev
I belonged to the Web 1.0 era (when JSP/Servlet/PHP/ASP Classic were considered as skills). I really like HTMX. If HTMX becomes standard, I wonder what the Front-end guys (react/vue/angular devs) will do now?
The ultimate solution to state synchronization will be the use of CRDTs. And as soon as I'm done implementing them all in Python, I'm going to port the library to Go and then Dart. It will be beautiful.
Edit: with CRDTs, any number of online and offline state updates are guaranteed to eventually converge to the same state once all updates are applied, regardless of the order of those updates or the number of times they are applied. CRDT updates are commutative and idempotent.
HTML as state and AJAX(HTMX) as API is all good, but it only works on web, on mobile, desktop app or games you will need some other API(REST, GraphQL, ...)
HTMX should become basis for HTML6 spec, with but built in signing/checksum for requests from browser to prevent XSS attacks. HTML6+XSS protection based on HTMX will make webdev accessible for the noobiest noobs and truly allow everyone to "learn to code"!
There’s “onclick” attribute already… That’s reinvention of the wheel.
@@alexandersuvorov2002 HTML is so simple a small child and perhaps even an illiterate person could write it. JavaScript is a big jump for those folks. Imagine if every highschool graduate was able to make a **bare bones simple** SPA, as naturally as they could do reading and writing? What would that world look like, if grandma and grandpa were able to host their own websites by just uploading a .html file to a Cloud provider like they would a pdf or zip file? Think big man!
@@jibreelkeddo7030 We’ve been through this already with Wix, Wordpress and Java. This idea of incompetent folks being able to produce anything beyond preconfigured framework demo’s didn’t work. We end up with crap code that propogates through the entire solution and ruins all the work by those who actually put hours into tech and quality pro-grade code. The whole existence of TypeScript is because there are folks out there who just copy paste code snippets from the web into the codebase without even trying to understand what’s in there.
And lastly, no grandpa and grandma will be able to produce advanced frontend UI by just doing HTMX frontpage demo. They need to understand DOM and HTTP and JavaScript anyway, so why to force them study HTMX on top of that? Or do you expect there are businesses out there who would settle with basic HTMX code?
I like your perspective, and it is true, but state on client can be reflected or generated after backend confirms an action as done (success or failure), but writing it proper is difficult, delete example is easy to do with frontend frameworks, I never touched htmx but I imagine it makes it more clear, simpler and easier. I hate react by the way :).
ReactJS devs thinks everything is a nail.
Feels like, putting React on a Django backend is like taking your time organizing your home meticulously, and then spray it with confetti. I keep learning it because of Native, because I like Flutter even less.
I unsubbed from theo recently. Too opinionated, self-centered, holier-than-thou. I like some of the things he does but I just couldn't take the childish drama. Just me?
Also, look at his FAQ page on his site. I mean... seriously? So humble.
I like Theo because its funny. He is the classical JS dev who has strong opinions that are often pretty dumb. But that's what makes it so funny as long as you don't take it seriously. Similar to why I like prime, I don't actually respect most of prime's opinions, because he talks out of his ass almost all the time, but I don't take him seriously so it's just funny entertainment. You can't look at these influencer/entertainment dev's seriously, their content is just pure entertainment not really educational or anything.
@@derschutz4737 Fair point, about prime too. Influencer is the right description. I just think the attention-grabbiness got too much in the way of me wanting to learn some new tools, but I'm probably looking in the wrong space for genuine educational content. I think the only exception here is Prime's frontend masters course(s) (not including the random web3 one lmao), cause he curbs his intensity there lol
Yh I got out of the js bubble and started coding real world apps
I don't trust Theo at all after his video transmission of "Svelte sucks". Most of his opinions are garbage.
I think it makes sense, and seems to align on how originally the web stack was designed to work.... Javascript provides the dynamism, html the data structure, CSS the decoration.
Both these guys looking like washed up cops
Is it the mustaches?
36:18 in and feeling pretty dang good about rejecting "Optimistic UI" from the Meteor days.
Long live server state!
HTMX is good, but i like UNPOLY
if you have very small task, just use vanilla js. I don't understand the argument. You should only use a technology when it is needed.
It feels a bit backwards to move in the direction of htmx. I always thought offline-first (using CRDTs) was the next thing. But it does make a very old approach of writing webapps much easier.
How often are you actually wanting to use a website while offline?
What is CRDT?
there is no need for such thing in 99.99% of all websites or web applications
@@alexandersuvorov2002 www.google.com/search?q=what+is+crdt? 🤷♂
I thought CRDTs was for collaboration software? Most stuff involves speaking to 3rd party services which involves online communication
Most modern applications fit more into the pattern:
- Have a backend with some clean (well defined) API
- Having (multiple) applications using these API (Mobile, Web, Other services...)