This video is about why you should not use htmx for LARGE projects: 1. Portability If your API uses HTML as a transport layer, that makes it difficult to (re-)use in front-ends that are not HTML-based: mobile apps, desktop apps, IoT apps, Unity/Unreal apps etc. "Why not both?" - because HTML is not just pure data, it also has a layout and rendering component. If it were just pure data, then you could argue for implementing a simple header like "accept: text/html, application/xml, application/json, application/bjson". 2. API egress costs The difference between JSON (or bJSON) and HTML at scale may be the difference between Gigabytes and Terabytes in egress, or the difference between $50 and $50,000 in monthly server costs. At large scale, the less redundancy in your output, the better. 3. Separation of Concerns When your app is small - both in codebase size and number of active users -, you may not care about the purity of your functions or SoC or DRY or any other design principle. Ignoring these principles for long enough, though, is always bad news. 4. What is the pain point? Back in the days of jQuery, DOM traversal was an actual, real headache. Creating that CSS-like selector engine was, indeed, a breakthrough. Today we have document.querySelectorAll() natively in all browsers, so the main feature of jQuery is no longer required from a 3rd party library. So what does htmx solve? It binds some event listeners that issue fetch() then inject the results with innerHTML. I wouldn't call this a huge time-saver. This is a talk about considering HTMX as a serious library for a professional (for profit), large-scale project.
(2) "you need to factor in the transport cost of sending all of the JS that will interpret and render the JSON" You load your front-end once (let's say as a Statically Generated SPA, hosted on Cloudflare), then store it (all of it) entirely in local storage with a PWA worker. Now you have 0 bandwidth requirements for your entire front-end (with offline-mode support) - until you update the app and force a re-download. The only remaining cost is your API, which still needs to respond with fresh data on every user call. (3) "hypermedia as the engine of application state" APIs are meant to be stateless (3) "doesn’t require a complex state management system" How do you know what your end-user will require? (3) "it minimizes the amount of processing that needs to be done client side" That's a minus; you want "an infinite pool of CPUs" to do most of the work, not the server YOU pay for (3) "it minimizes the amount of JavaScript the developer needs to know" This is never an argument FOR a software developer. You kind of need to know what you're doing, right?
"New/updated JS will be needed all the time." - indeed. You set up your PWA to invalidate the cache only for files that need to be updated, making each (weekly) update as small as possible bandwidth-wise for your customers; but remember that you're storing your SSG on CloudFlare, so you don't really incur any costs for this. Long term, though, your UX is much better with PWA caching and tiny API responses than going back to the early 2000s and expecting huge chunks of render-blocking HTML with each user interaction (click, double-click, swipe, hover etc.)
@@markjivko quote: "(3) "hypermedia as the engine of application state"APIs are meant to be stateless" -> HATEOAS is not a contradiction with "APIs are meant to be stateless". I have no clue what you are trying to say here.
Of course that's my intention 😂... not. I may sometimes come off as arrogant and I'm sorry about that. It's kind of hard to warn people about a fire without sounding just a little bit anxious / alarmist / negative.
was thinking the same thing, his argument is more about doing less on the backend and more on the frontend, but tbh I feel like he doesnt really understand how to use htmx in general
You are right. I do believe server-side rendering is short-sighted in most scenarios (obviously, not all). But that's not my ONLY argument against htmx - read the pinned comment.
You clarify in the pinned comment that you are talking about large projects, but here you also say "most scenarios". Do you think most projects are large projects? Or do you mean "In most scenarios involving large projects?"
Yes, I mean in most scenarios that involve projects that are meant to become large - or profitable - at some point in the future. I would argue that it is not premature optimization to consider scaling from day 1, regardless of project. That being said, there are, indeed, countless projects that would benefit from htmx: internal tools, proof of concepts, "known-scale" projects, portfolio projects etc. Thank you for your kind contribution.
So many wrong things here, just taking one: sending the whole HTML. That’s not what HTMX does, it sends small chunks of HTML. Which you can cache, compress, etc.
"That’s not what HTMX does, it sends small chunks of HTML." Let me explain this the best way I can, in terms of space complexity for the bandwidth requirements of your User Interface. 1. O(n) = 1 for an SSG cached with PWA web workers. Constant space. In other words, the entire UI "shell" gets downloaded once, then cached until the next update. That may be quite large (3MB+), but it only happens once per user. 2. O(n) = n for SSR. Linear space. Your UI "shell" gets re-downloaded in chunks with each user interaction or other triggered event. The more the user stays on your app, the more HTML chunks are downloaded, displayed, then discarded. There are many scenarios where you don't care about your bandwidth, latency, or internet connection reliability and offline support. Those may be great candidates for htmx and other SSR approaches. But if you do care about egress (the cost of bandwidth), as you plan to scale your app to at least 1000 active users, then you really need to consider that the difference between Gigabytes egress and Terabytes egress in terms of cost is jaw-dropping.
@@markjivko but #2 doesn’t happen with HTMX either. The difference is between calling an API that returns JSON vs HTML, that’s the only difference for this bandwidth cost discussion. If #2 is happening with HTMX is because you are not using HTMX correctly. You are essentially using vanilla HTML, negating the point of using HTMX in the first place. So, the idea is that for every event/user interaction you call an API. This API could return HTML (with HTMX on it) or JSON, still up to the FE if you want to cache the API call. Either way, HTMX is not the right tool for every web application and the same for React. I believe that HTMX fits more applications than you think.
@@markjivko Your video is interesting because there is not much people talking about the difference cost between running some code in a server and using the client resources. In .NET there is Blazor Server and Blazor WASM. Blazor Server is using signal R and when you click a button there is a road trip to the server. I have never ever considered this option.... Reducing our cost, being greener and offline support are great stuff!
Short story time. I run multiple tiny SaaS just for fun. One of them recently passed 100GB in monthly egress for its API. The service is quite small, less than 1000 active users. If I used HTML chunks instead of pure JSON, that egress number would be closer to 100TB, which would totally bankrupt the entire project. I know that what I'm saying is not sexy. But trust me, egress costs are a nightmare! HTMX might be this cool "new" toy, but buyer beware! You might NOT afford it at any meaningful scale.
@@markjivko It seems your arguments are more against Server-Side Rendering than HTMX specifically, as in you argue that web apps should be SPA-like in order to save data transfer fees. I can't really say for sure if that's always going to be worth doing, but in some cases it might be worth the savings. There are other technical considerations though like speed of first page load.
I believe that you believe what you are saying. As someone who uses HTMX, it does not feel like an honest review of HTMX. Have you built anything with HTMX?
Here's a code example: github.com/markjivko/rpg It's an entire Browser Game Engine I wrote in PHP as a WordPress plugin. It uses HTML as transport for API calls - much like htmx. That's WordPress land, so what can you do? If I had to rewrite that entire thing from scratch, ditching HTML as transport would be the first thing on my list. Separation of Concerns really is something you don't notice until your project reaches a certain scale.
@@markjivko Using HTMX or similar approaches for a real-time browser GAME??? That's like using Beer to make Milk & Cereal breakfast. IT's just the wrong ingredient combination for your ultimate goal.
I didn't say I used HTMX for the game, just Server-Side Rendering for some of its components (like dialogs). Here's a demo: ua-cam.com/video/KABh8CwpSM4/v-deo.html Here's the source code: github.com/markjivko/rpg If I were to build it again, I would probably go the WebGL/Canvas route instead of the pure HTML/CSS approach, with a heavy SSG UI and pure hydration component for the backend. I chose the SSR route "because WordPress".
you are too much into JS and you think you are losing your job , that is what I hear, projects need clear solutions , not megabytes of JS per page to render every tiny little element.
The video is fully packed with fear-inspiring statements not backed by facts or backed by imaginary facts. For example the "separation of concerns" between backend and front-end: if the two were really separated, the front-end would have its own server, and the data would not need be validated again on the server.
"the front-end would have its own server" Front-end does not necessarily mean a web-facing browser. It can be a WebView inside of an iOS or Android application, it can be a rendering thread inside an Electron.js application or some sort of micro-browser application inside your Fridge display or a standalone Native app written in C#/Unity or whatever. The "front-end" is a shell, and it can be quite successfully separated from the backend. It's called static hydration - and it's quite trivial with something like node.js or next.js My argument is that your API should be portable. It should be able to talk to your Browser app, to your Electron app, to your Android app AND to your native implementation of a UI in a linux-based environment or a Unity/Unreal app etc. HTML should not be the transportation layer because it mixes concerns: data and presentation/layout/rendering. That's it. But to each his own 👍
@@markjivkoyour point about APIs being portable. I wish things were that easy, after so many bad burns, I have learned that code duplication is not the demon that I learned when I was just learning programming. Code duplication is the right tool more often than you would think, over abstraction is way more damaging to a system. So, having different APIs for web vs mobile is way better than sharing them. Web needs speed, you need the ability to change the APIs way more often than mobile. We all think that we can deal with versioning and other techniques but let me tell you, it is very, very hard to do.
Solving a LeetCode problem with optimal O(n) is hard, but that doesn't mean it's something you should avoid IRL. I agree there are many scenarios where "the fast approach" is preferable as most SaaS ultimately fail - but that's not a compelling argument for me to ditch DRY, SoC and all other principles that make SWE more than a silly game.
@@markjivko no need to ditch SoC/DRY, but what about this: perhaps there's a viewpoint from which these principles are not at the top, and perhaps from the same viewpoint HTMX is great. By mentioning SoC/DRY often and soon it suggests you are seeing SWE from another viewpoint than people who see value in HTMX. That does not at all mean you are wrong, it just does not give the impression that your opinion is ready.
The simplicity of having state in 1 place, the server, and the ability to use your programming language of choice, without the need for specific frameworks i think are the most important pros. The complexity of having 2 apps one in browser and one is server, is what htmx try to solve i think. Maybe for some apps this is not possible so htmx alone cant do it, but still its usefull.
You don't technically have 2 apps. One is a shell (the UI), and one is the Hydration component (your API). This Separation of Concerns allows you to export the shell further: - to mobile as a WebView component - to desktop as an Electron.js app It also allows you to rewrite the shell independently from the API, opening the possibility for truly native apps - think Unity or Unreal "shells" that communicate with the same API; Internet of Things apps, VR/AR, you name it! "A shell is a shell, and the API is just an API." I would call this approach simpler than having everything smushed together on the backend.
If all the state we need can be saved on the backend, why to break the app in 2? Server can know, and send the HTML ready. State 1)app state = server state client just display what server sends 2)app state > server state (HTMX and some javascript) client has internal state that can't be saved in the server, but its not so big in size 3)app state >> server state (react?) client has internal state that can't be saved on the server, and its very big, hard to handle with javascript only If this makes sense, i guess htmx will be mainstream, because the majority i think are in 1) or 2) category, but maybe those that i say don't make sense, if someone knows can help with the limits of HTMX, based on state needs/perfomance etc
@@wdeath User experience + consumer agnostic APIs. You can't ship HTML to a native mobile app or smart tv. If you lose part of your response with a fully server approach, your application is dead for the client.
The whole point of HTMX is to move as much app state away from the client onto the server... With HTMX, separation of concerns is MORE strictly enforced than react because you have no client side state. The server is responsible for app state. The client gets HTML. Your example at 1:10 makes it seem like you haven't actually used HTMX. If you are waiting too long for HTML responses, its actually a skill issue, or an edge case, in which case you can just use something like React as part of the component that needs requires more complex client state.
I'm not sure how handling everything on the server is better for separation of concerns. Moving client side logic to the server imo just seems like something backend devs would want to do because of their superiority complex. I do like the idea and think it can work for a hobby project, but I can't imagine it scaling well for something like facebook.
@@JanVerny Implementing SoC in the backend is already required. By handling all the state in the BE that allows you to use HTML and web requests in a stateless way - as it was designed to be from the very beginning. There can be a million reasons why you might want to have state in the FE, and for something like Facebook it might be required, but 99% of real world projects out there are not Facebook and you can accomplish the same features without having state in the client. It just adds complexity because you already have to deal with state in the BE - so why do it twice?
@@lobaxxDon't think I can agree. By definition, you are taking a concern that was previously entirely within the frontend domain, and you are merging it into your backend. Increasing overall complexity. It also seems like you guys don't understand the point of RESTful APIs, as the server is the thing that is supposed to be stateless. The last sentence sounds completely insane to me, if your server is already dealing with state, you're doing backend wrong.
@@JanVernyState is defined two ways. Global state (things held across sessions and users) is held by the server in the database. Then there is session state like what page your on. In both react and htmx session state is held by the browser. In react as variables in htmx generally by url or by putting different elements on the page. The big split though is in global state. React copies some portion of the global state to the browser and then tries to keep it in sync with the server. This is very bad separation of concerns. In htmx your browser knows nothing of the global state and just displays what comes from the server which stops the back and forth of sending global state both directions and trying to deal with error management around state changes.
@@JanVerny No, the concern was not “previously entirely on the front end”. The Single Page Application-era were as much state as possible has been handled by the FE is fairly new. However, for 99% of all applications all we are doing is duplicating the state management, which means unnecessarily complicated applications. Previously, stateless frontends were all the rage. Remember when everyone built RESTful apis? Or when you had templating using PHP, Rails etc? HTMX is a twist on that tried and true approach, while trying to fix some of the flaws that made developers seek out SPA’s and FE-complexity.
1:31 - "You need to parse the server response". That's where you went wrong (and downhill from there). The point of HTMX (or Hotwire) is - you do all parsing and preparation on the server side inside your server-side framework. The response needs to be ready for consumption right away. HTMX is not an answer for everything, but it's a good alternative for a lot of CRUD monolith applications. Use appropriate tools for the situation. HTMX does debounce-ing, event bubbling etc.
"if you need to do anything non-trivial with your server response" - don't gloss over this one. HTMX cannot handle event bubbling well - consider there are other events except onClick - because the UI flow/state is interrupted by API calls inside a library you have no control over.
@@markjivko ""if you need to do anything non-trivial with your server response" - don't gloss over this one." I think everyone is going to interpret "non-trivial" differently. I am no frontend devel; I've done few simple things with vue recently. So maybe I'm biased, but the examples you immediately go to in the video (parsing stuff for canvas, etc.) sound like black magic to me.
I mean, I get it, if you're trying to compete with Netflix then sure, you need to know your stuff but sans my own skill issues, is really anything less than that "trivial"?
Why would you be trying to extract data from the HTML? If you're using HTMX, you are receiving fully-formed HTML that is getting swapped into the page. The server has already considered how the data should be presented and the client shouldn't have to care about the data used - it simply needs to display it. You wouldn't use HTMX to return data for consumption in a customer-facing API. It isn't a substitute for JSON, it's an entirely different approach.
--- "if you want to do something non-trivial with that response" Meaning, if you want to parse the response into a Canvas element, or write something to LocalStorage etc. You would need to extract that data from the server response (which is HTML) somehow: either with regex/tokenization from string, OR post-insertion into the DOM with node traversal.
Even if there wasn't a better way to handle it with HTMX, you can add endpoints that return JSON data for these edge cases and handle them with scripting. I don't think there would ever be a situation one could get themselves into that would require parsing HTML.
Excellent point! Really - "you can add endpoints that return JSON data". That is what I would call a fractured API. It sometimes returns data, other times it returns HTML. It's no longer a consistent API, and all because you did not follow proper SoC from the beginning. This is only the first negative side-effect of this approach. As your project scales you'll encounter more edge cases, and more issues.
Don't take as arrogance, but this video shows how little you know about the technology and software engineering. #1 separation of concerns: htmx has nothing to do with internationalization neither with separation of concerns. This is a design/architectural decision. #2 ux: it's literally the opposite of what he said, you load chunks of html instead of full pages - that's why htmx was invented. Giving the simplicity of templates back + Single Page Application (SPA) #3 devx: the opposite again, with htmx any person that knows html and basics of JS are good to go. React you probably need a course. Plus overtime JS frameworks tend to die or get bloated trying to keep up with new new features of frameworks that releases every day.
1. In this case SoC refers to the separation of concerns between the UI layer and business logic (backend / API); UI does not have to mean HTML - and maybe this point causes confusion. Think Mobile Applications (native code), desktop apps, IoT apps etc. One learns to appreciate SoC once the codebase passes a certain threshold in size/complexity and usage. 2. UX refers to the User's Experience in using the application, not one's experience as a developer working on the app; lack of offline detection, lack of graceful degradation in internet connection issues (latency, race conditions etc.) and others negatively impact UX 3. You're not a developer if you don't learn your tools. Yes, that means "needing a course". I would argue one needs a whole lot more than just a course for DevEx to begin applying to them. "Don't take as arrogance, but this video shows how little you know about the technology and software engineering." - that is not arrogance, that's an insult. I presented some arguments against a library - not against you as a person. So the fair thing to do is to present counter-arguments in favor of that approach, not to throw insults.
You start with "Don't take as arrogance" then immediately follows with an insult **sigh** In view of UX, DX and cost/carbon footprint. a. You will find it very hard to build modern UX frontends with HTMX, even simple things like dynamic modals, bind/rebind to javascript components is a pain. b. You will create an unmaintainable mess on your backend, with all the html fragments and endpoints and HX events scattered between all these. c. You will be the dev who increases your client's or employer's hosting/compute bill, because your HTMX is hammering the server for every state change, when you could have just relied on the browser.
@@depafrom5277 Saying the truth is not an insult. He's trying to teach a subject he barely knows how it works. Feels like I'm watching a bird trying to teach a fish how to swim. But honestly, I saw other videos on his channel and he's just messing around for the meme so idc. a. If you're dealing with binding/components/too much javascript with HTMX you're using it wrong. You are probably trying to apply what you have learned in frameworks like React to a completely different technology. "If the only tool you have is a hammer, you tend to see every problem as a nail". And no, having a "modern ux" has barely anything to do with the tech you chose. b. Mess code = bad design and poor coding skills. If you're messy then it will be worse with any javascript framework, since you still need to write the HTML + framework logic + API. c. Yes, HTMX is server-side rendered. You have to consider this when choosing the technology. You can get around this by generating static HTML and just serving it, it will be less expensive and more performant, but this approach doesn't fit every use case. Rendering on client also have drawbacks like the experience will be worse for shit devices.
Yes. I've been writing software professionally for 15 years. Most of it in Java, PHP & Typescript. Payload sizes for HTML > JSON > bJSON. Not my opinion, just the technical specification.
I don't make stupid arguments. Only arguments that may not resonate with you at the moment. My argument is that - AT SCALE -, HTML is much larger than JSON because HTML also carries layout and styling information. www.ietf.org/rfc/rfc1866.txt Whereas JSON (and binary JSON), can only carry data. When your app reaches SCALE, you do start worrying about egress. A lot. Because it's really expensive, still. And that's when you begin looking for solutions to compress and reduce those API calls. Yes, brotli/gzip, whatever can help. But not by a lot. Your best bet is to simply strip anything and everything that isn't pure data from API responses, merge multiple API calls into 1, and cache API calls as soon as possible. And since PWA WebWorkers are a thing, abuse them to cache your application skeleton (the UI), entirely in LocalStorage so you get 0ms response time on app loads and offline mode support after that pesky first-load event. I get it. HTMX is easier. It is an awesome tool for localhost apps and tiny PoC. But when you do get to have uncomfortable discussions around that egress bill, you begin to look for alternatives.
@@markjivko Again, it depends. Working with JSON costs something as well. There is no silver bullet. Do you think that AVG consumer of this video have to care about this? Make it simple, if you really have this kind of problem, there are solutions. But using this argument against good tech that can help people to ship fast is wrong.
"But using this argument against good tech that can help people to ship fast is wrong." As you mentioned yourself, there is no silver bullet. Even the absolute best tech has its drawbacks, and we should apply critical thinking. If the argument is valid, it needs to be pointed out, whether the tech is good or not. I'm not preventing anyone from shipping products fast(er), only warning about tradeoffs and edge cases at scale. Your position is "I like this tool, so don't judge it". If we were talking about a Bosch cordless drill, maybe you would care less about my arguments around max torque. But since htmx is more of a "movement" than a tool, I guess it attracts inflamed emotions. We should all try to do better. Be more rational. Apply first-principles reasoning more.
Localization should be done on the server side, as everything else. So based on accept-laguange + url path you will return the correct localization. There is no issue, related to HTMX...
- Internationalization (i18n) can be done server-side, but it's a presentation concern. As such, following Separation of Concerns, it should be part of the client application, not server-side. Unless, of course, you're internationalizing your API errors. - Localization (l10n) refers to numeric and date/time format, currency, keyboard shortcuts, rtl/ltr orientation etc. These are exclusively client concerns. These should never be server-side concerns. You can obviously do everything server-side. That's how we did things 20 years ago. But modern browsers have evolved to allow us full separation of concerns between the client and the API and I think we should take advantage of that. Mixing concerns leads to headaches. How do I know this? Well, among other things, I've built a game engine from scratch that uses Server-Side Rendering of "html chunks" delivered through AJAX calls 5 years ago. Bad choice. github.com/markjivko/rpg If I were to build it again, I'd go for react.
@@markjivko false. For example sending emails or notifications requires to have Localization on the server. What I am saying here is that you are using arguments that are not generally valid. It always depends on the specific implementation.
for context: I was working on projects that have several languages and money/date formats. And yeah I have to iterate to get my working scalable tech-stack: "Most of the things on the backend, stupid & replaceable client-side part".
We were talking about Web Applications. Let's not compare apples to oranges. (web) notification and e-mails are not web applications. Localization of a (modern) web application can and should be done user-side. The same way you localize your native iOS or Android app, for example. "Rich media" applications like dynamic ads, banners in IoT devices etc. can and should be internationalized server-side. But those do not web applications make.
I liked that he casually shit on jquery as well, despite jquery4 coming out recently, and jquery being far more appropriate for 90% of companies use cases than any of these overwrought and needlessly complex javascript frameworks he's likely a fan of.
I'm not a fanboy of any tool. I don't "shit on" or "highly applaud" anything at all. Ever. In fact, here's a game engine I wrote 4 years ago that uses SSR under the hood (very similar approach to htmx) and - drum roll - jQuery: github.com/markjivko/rpg I'm not advocating for or against anything in particular. My argument is that Separation of Concerns matters more than that made-up "Locality of Behavior" - if you're interested in scaling your projects to more than a handful of developers, more than 10k active users, and more than 100k LLoC. Just for fun, all tools are awesome!
jQuery4 or not its still jQuery, and its solves a very different problem than React, Svelte etc. "90% of companies use cases" when did you run the world-wide survey to get that exact percentage?
@@depafrom5277 I never said they solved the same problems. I thought somebody was going to try to make hay with that, so congrats, a winnar iz you. Still doesn't change that he was dumping on jquery which he denied, and that while they serve different roles jquery is still more likely to be a more appropriate inclusion for most companies. And 90% is generous. According to Forbes 99.9% of all businesses in the U.S. are classified as small businesses.
This breaks separation of concerns far less than putting logic in the frontend, especially if you replace HTMX with something like alpine-ajax where you literally just write an MPA and progressively enhance it, or if you use htmx with a forge plugin that adds things on top as part of server-side abstractions
110% correct ! Your entire argument against HTMX is that it makes it difficult, if not impossible.. to build systems using shockingly bad anti patterns. Like client side state management in JavaScript for starters. I totally agree
React ain't that bad. It's just that people are sick and tired of the front-end framework/library treadmill. A new week, a new shiny toy. At least with SSR, nobody can tell you how to write your HTML, damn it!
From my experience it depends on what you are building. Are you building an app where computing is mostly on the client (dashboard apps, facebook, youtube etc)? then nextjs should be amazing for you Are you build a load sensitive app where most of the computing can be done server side (ecommerce, blog, landing page)? Then htmx should be your new best friend
I agree. There are plenty of scenarios where a tiny shiv like htmx is "good enough". That being said, if you're going to do any sort of front-end engineering, you'd better know your tools. Because built-in, vanilla fetch() and .innerHTML replace the need for htmx in a second.
You’re saying all this like you have to force your JSON API to send HTML?? Why not just leave your data api alone to do it’s thing. Imagine not having to rebuild your data endpoints with every front end change because you use get peeks at safe server rendered data with HTMX on the front end. No it’s not for every project but saying it’s useless or costly at scale is just plain silly with nothing to back it up. I’m sure Netflix is just letting Prime code HTMX all over the place because they are getting on the hype train. Surely they don’t see use cases for it in gigantic projects. They are probably getting paid off by the one man company in Montana. Aren’t you just doggin HTMX to use the hype train for for your own server rendered answer anyway? Well played Sir.
It is costly at scale: ua-cam.com/video/HlVsfyHT-Lk/v-deo.html Don't invoke the "Authority bias" argument here - who cares Netflix and/or PrimeX did/does something? That should not be a substitute for your own reasoning and critical thinking. I'm not talking about HTMX to get on some hype train - I do it because at least 1 person needs to state the case against it. If you search for "htmx" on YoutTube, it's just 100% pure love and support - which makes no sense to me. You don't see that with any other library - jQuery, Bootstrap, Livewire, Tailwind, you name it. Someone has to state the drawbacks. What do I know? Well, I've written a PHP framework from scratch 13 years ago, then a CMS, then I built and sold a web Game Engine that relied heavily on SSR. With all due respect, I am not trying to troll anyone. HTMX really does have massive downsides and the SoC issue prevents it from scaling beyond tiny projects.
Server side rendering has its advantages, for instance if a user does not have permission do view a certain page / area / element he never receives that element. Even if the backend API is secured, just being able to see those interfaces might leak information. But I'd never move back to such a framework/library ever again, ASP was enough for me. Simple things are simple, complex things are near impossible or hacky and dirty.
I agree with you about the "UI data leak" of next.js and friends. However, there is no such thing as "security by obscurity". For best results, simply hiding your sensitive API endpoints won't do. You still need to thoroughly secure those calls on your backend. So I don't really see this as a huge concern. Especially when more serious issues like prototype pollution take the spotlight.
SSR is short-sighted. It's only adequate for small-scale or localhost stuff. I ran an Android dev studio for a while. Hundreds of apps used by 100+ million people in our "glory days". Using an SSR approach at that scale would have been suicide. I am so excited about Progressive Web Applications and the modern web for this reason - we can finally have "web apps". True applications. Completely decoupled from the backend, completely hosted on the end-user's device. PWAs enable massive distribution at low cost by shifting the rendering responsibility to the rendering device itself. I really don't see why we would want to go back 20 years OR how anyone can make financial sense of this htmx/ssr stuff - at scale.
@@markjivko1. why would you need PWA if you want your app to perform in realtime? Who wants a limited static mobile view version of a website unless its a Kind of Offline Portfolio Showcasing ...like a website of a service provider. Cuz user can simply make a bookmark on screen of any webpage and also user loves to interact with native apps that gives them rich user experience. Nobody wants to watch youtube in a PWA, ppl love the rich ux of YT native app.
Progressive Web Applications are not a particular style of web app, rather a recent extension of browser capabilities under one umbrella: web.dev/explore/progressive-web-apps You can enhance any web experience with various PWA functionalities like local storage, caching, access to various sensors etc. - whether those apps are "rendered" server-side, or they are fully static. Also, statically generated apps can behave quite dynamically with API hydration. You just need to carefully manage that state with, let's say, next.js or similar. Nothing's stopping you from implementing your own solution in vanilla JS, so I'm not arguing in favor of any specific js library. Finally, UX is a very complex topic, not well covered in a comment section like this one. If there's just one point I'd like to make is that bandwidth and latency issues do negatively impact UX. So beyond the initial loading time for a locally-cached PWA, you really can't beat 0ms response time for assets. At a certain scale, you do want your API responses to be as concise as possible for better UX and lower server costs. That is my argument. HTMX might be great for small-scale apps - in terms of lines of code and active users. But there's a certain threshold, though, where SSR (which is the approach behind HTMX) begins to fall behind in terms of costs, performance and UX.
"Locality of Behavior" is not a desideratum in SWE. Separation of Concerns is. Let me explain. Locality of behavior only works, so to speak, for extremely small codebases. - Once you reach any non-trivial size (say 10k+ logical lines of code), you're going to have to apply some design patterns. All of a sudden, your behavior is split into multiple files, in various folders. - Once you reach any non-trivial feature set or scale, you're going to want to break that monolithic architecture into microservices; DDD and other principles come to mind; your behavior is even more scattered. These design decisions are not only necessary, they are correct. You should apply divide-et-impera as you scale. Contradicting "Locality of Behavior" is actually a good thing. You want separation between application domains at certain scales. Unlike LoB (which is made-up by that htmx guy, by the way - not a real term), SoC (Separation of Concerns) actually matters a lot - at all stages of your application. Your front-end is not HTML-bound. It can be a native app (android / iOS, desktop), it can be a hand-held device etc. Sending HTML over Remote Procedure Calls works just fine enough if there's a browser listening at the other end, but what if you want to digest the same API from different clients? HTMX is great for small stuff. It's naive. It's fine. It works. But at any non-trivial scale it falls apart.
It is only frontender's talk, who dont know (seems) about partial html markup responses from backend, dont know about brolti compression, and about http response headers whitch will be parsed by default. In real cases HTML markup (xml in fact) response form HTMX will be lighter and faster then json+frontend_templates+tons-of-js-for-rendering. If this approach does not fit in the head of fans of overly complex frontends, then this is because the head is occupied with kilogams of superfluous JavaScript 🤷♀ Just try HTMX in action!
Funny how this video starts with an entirely wrong statement. You can in fact send json or god forbid xml with htmx and it works fine if you are into it. The author of the video didn't even read beyond the first page of the htmx docs
if server-side rendering is soo bad as ure making it sound, then y is ur react and next js moving everything to the server now 🤣🤣🤣 just face it, react and next js is nothing more than decorated php with vanilla js
2:22 Well, this brings up, you haven't even tried it, but complaining. Because HTMX is about PARTIAL rendering of HTML snippets on your API and replacing components, not about entire page reloading.
I have tried it and it's "good enough" for small-scale projects. But that's it. Here is my personal opinion. If I were to start a greenfield project tomorrow I wouldn't use htmx. That's because I can perform .innerHTML and other DOM mutations on certain events with vanilla JS in just a few lines of code. To me, the problem htmx solves is absolutely trivial. For me, using htmx over vanilla JS is like importing that "is-even" library from npm. www.npmjs.com/package/is-even The arguments I'm making in this video pertain to large-scale projects - in terms of features, team size and active users.
@@markjivko I like HTMX idea in a sense, you can create frontend using Pure HTML and less JavaScript. And especially, because you can ditch nodejs. I've seen Full-Stack Python FastAPI examples and I eager to try that. No NPM was used there. Only Jinja2 templates and one tag pointing to unpkg. I get what generating HTML on server side idea can be somewhat extreme or edgy. But no one stops you from using JS on browser, just use less of it. You can also use mustache or Alpine.js to generate forms on client-side, for example. My eye twitches every time I think about learning Vue or React is a MUST to create a web site and I have to install nodejs for it... Yeah, I'm not the frontend developer, but sysadmin. And I mostly write in Python. I have to admit.
I appreciate your perspective and coming from a purely "back-end development world" I can understand your frustration with the insane front-end world. We do have too many frameworks today. That is a fact. But ultimately your users don't really care what you used to build their solution. There's a time and a place for htmx, that's for sure. But if you do want to take control over that annoying browser, you need to master javascript. Forget "The Frameworks" or "flavor of the day stacks". Just pure, vanilla javascript. Once you see what a modern browser can do - I'm referring to Progressive Web Applications, WebGL and more -, you'll likely never think about htmx ever again.
@@markjivko I love PWA, especially a Photopea one as a good example. But it doesn't really matter how much javascript or frameworks I will learn, I am very confident, I will never write one. Even If I will, I will try a WASM (Flet aka Flutter, for example) approach first.
People state opinions as facts without proof. I don't do that. Here's a recent experiment I ran: 1. Send WebSocket frames of 64k bytes each with a Ping signal for each individual frame - download speed: ~750kB/s 2. Send WebSocket frames of 64k bytes each with a Ping signal every 16 frames - download speed: ~7MB/s The largest bottleneck was, intuitively, that Ping/Pong signal, right? Well, turns out, in the case of a duplex connection like a WebSocket your "overhead" is almost zero. And the network latency is the same in both scenarios, so that's not a factor. The issue was how that Ping signal was treated by the client application. It added tens of ms to each frame, without actually sending any data over the network. In the case of HTML over JSON as an API response, there are fewer variables. No complex handshakes, no duplex to worry about. The only difference is payload size. And HTML is more verbose by its nature - so it will return slower. And if your app is very "energetic", that means many http requests and waiting for large payload responses, which degrades UX. Contrary to what I would suspect is not actually popular belief, "the state" does not just mean database. Your app will also have a "visual state" - which can and should be handled entirely by your front-end. Having to clumsily send HTTP requests every time someone clicks on an "increment" button is naive - and we can do better in 2024. useEffect() and useState() are really all you need to master react. PWA webworker caching of an SSG hydrated with API calls results in much better UX than an SSR. What do I know about SSRs? Here's a game engine I wrote 4-5 years ago, that renders HTML received over API calls (with jQuery, as a WordPress plugin): github.com/markjivko/rpg
In this case, the host did more than just listen to that ping frame, it had to move a pointer in an open file handler and initiate a new message as a Blob object. That didn't necessarily "keep the CPU busy", meaning the CPU wasn't actually at 100%, but the extra steps taken by the client script added to a few tens of milliseconds per batch, which translated down the wire into massive bandwidth losses. Getting back to the htmx discussion: more http requests and larger payloads don't make for a smoother experience. You have the option in 2024 to fully cache the entire UI component of your HTML application with a webworker. All of it. That's 0ms load time every single time after that initial load event. So you completely eliminate the bandwidth discussion for your UI. All that remains is data. Pure, clean, tiny data.
@@markjivko I fail to understand how this seemingly a performance bug in handling websockets is related to html vs json workload. If anything this proves that you shouldn't overload the client (which can be pretty thin) with rendering. +20ms is a very noticeable change in client experience and no, additional workload cannot change this, but the client context switching can. I personally think there is a place and time for SPA and there is one for SSR. Noone should claim one is absolutely superior to the other.
HTMX does not make sense for backend developers either. I'm saying this after 15 years of software engineering, and having used Server-Side Rendering for most of that time. Mixing layout/rendering concerns with pure business logic always results in code spaghetti. By definition, rendering is something that always happens on end-user devices. So I don't see why one would introduce a networking bottleneck (with latency and bandwidth issues), to pre-"render" some HTML tags server-side (with added compute, memory and security issues), when the end-user's device is still ultimately responsible for converting those XML tags into - you know -, actual pixels, UI and buttons, animations and such. Actual, pure rendering always happens on client devices - whether it's HTML, native Android code, native iOS code, native Windows code or anything else. Actual, pixel-level rendering still requires client-side compute and memory. I believe Theprimeagen and others recommend HTMX simply because of its small learning curve, confusing simplicity (which is a desideratum in SWE) with naivety.
@@markjivko "Mixing layout/rendering concerns with pure business logic always results in code spaghetti." But this is what React does, does it not? The problem with React is that it holds data and behaviour attached to the data inside of the components, not outside. It's okay to have logic of rendering components inside of components, but I think it's not okay to have logic that controls state of the component inside. And it's not easy to control many separate components in React just because the whole synchronization logic is in the components via very esoteric abstractions like hooks.
Dude you forget HTMLX is javascript based. it implements such as GET and POST as tags on frontend (it's literally on the *first page* of the HTMLX website). you don't need them to be integrated on your backend and throw HTMLX crap. your backend just be backend throwing JSON/WSS and HTMLX just be frontend and display it.
HMTLX is seems like old tech.. first AJAX pages actually wasnt with JSON data whey contained html parts.. after was converted to XML and after this JSON. So whats new here actually? Also as backend dev you have to know how you data will be used you cant just generate random you need 'context'
You are correct that it is an old tech but fixing some bad roads we took back then. I highly recommend you to read about HATEOAS vs RESTful, HTMX is pretty much based on the original HATEOAS ideas. Honestly, most of what HTMX does should be supported by the browsers by default.
i agree these points , that is why i am now switching to alpine ajax same as htmx but different , it does not need whole html to be sent to http request, talk about this alpine-ajax
amazing, thank you so much bro, i wish i could send you 100 right now for the time you saved me lol, get a patreon or something imo (although i feel you are very wealthy so prob don't need small donations)
You very kind words are more than enough payment! I'm glad I could be of service. If there's one thing I forgot to mention in the video is this - always form your own opinions based on first-principles reasoning, and never blindly trust any "Authority" , be that person an influencer, ex-Google, CTO at OpenAI, or a University Professor with Tenure and 6 Nobel Prizes in {insert tech stack here}. Always questions everything and uncover the truth for yourself. My next video will cover group think and echo chambers around HTMX and other tools. You can subscribe if you wish. Thank you!
Wont you end up with some json API anyway? I mean you may need a smartphone app at some point ? HTMX is created from some back end devs that can't admit that UI development became complex for a reason.
That’s not it, I do both FE and BE and I recognize that UI dev is way harder than before. The point is that not all UI dev is that complicated, some it is, no question. For those, React and others frameworks are totally the right tool. But, there are a lot of applications that can benefit from something simpler. The point is that we don’t need to use React for everything.
You would have to make sure everything you receive is not escaping from the current scope. I trust most developers would do this but then again there’s bug bounty platforms for a reason.
i agree with everything in the video but htmx is not a xss nightmare, htmx doesn't provide any backend library to you. so it's based on templating library or language you use on your backend.
This video is about why you should not use htmx for LARGE projects:
1. Portability
If your API uses HTML as a transport layer, that makes it difficult to (re-)use in front-ends that are not HTML-based: mobile apps, desktop apps, IoT apps, Unity/Unreal apps etc.
"Why not both?" - because HTML is not just pure data, it also has a layout and rendering component.
If it were just pure data, then you could argue for implementing a simple header like "accept: text/html, application/xml, application/json, application/bjson".
2. API egress costs
The difference between JSON (or bJSON) and HTML at scale may be the difference between Gigabytes and Terabytes in egress, or the difference between $50 and $50,000 in monthly server costs.
At large scale, the less redundancy in your output, the better.
3. Separation of Concerns
When your app is small - both in codebase size and number of active users -, you may not care about the purity of your functions or SoC or DRY or any other design principle.
Ignoring these principles for long enough, though, is always bad news.
4. What is the pain point?
Back in the days of jQuery, DOM traversal was an actual, real headache. Creating that CSS-like selector engine was, indeed, a breakthrough.
Today we have document.querySelectorAll() natively in all browsers, so the main feature of jQuery is no longer required from a 3rd party library.
So what does htmx solve? It binds some event listeners that issue fetch() then inject the results with innerHTML. I wouldn't call this a huge time-saver.
This is a talk about considering HTMX as a serious library for a professional (for profit), large-scale project.
(2) "you need to factor in the transport cost of sending all of the JS that will interpret and render the JSON"
You load your front-end once (let's say as a Statically Generated SPA, hosted on Cloudflare), then store it (all of it) entirely in local storage with a PWA worker.
Now you have 0 bandwidth requirements for your entire front-end (with offline-mode support) - until you update the app and force a re-download.
The only remaining cost is your API, which still needs to respond with fresh data on every user call.
(3) "hypermedia as the engine of application state"
APIs are meant to be stateless
(3) "doesn’t require a complex state management system"
How do you know what your end-user will require?
(3) "it minimizes the amount of processing that needs to be done client side"
That's a minus; you want "an infinite pool of CPUs" to do most of the work, not the server YOU pay for
(3) "it minimizes the amount of JavaScript the developer needs to know"
This is never an argument FOR a software developer. You kind of need to know what you're doing, right?
"New/updated JS will be needed all the time." - indeed.
You set up your PWA to invalidate the cache only for files that need to be updated, making each (weekly) update as small as possible bandwidth-wise for your customers; but remember that you're storing your SSG on CloudFlare, so you don't really incur any costs for this.
Long term, though, your UX is much better with PWA caching and tiny API responses than going back to the early 2000s and expecting huge chunks of render-blocking HTML with each user interaction (click, double-click, swipe, hover etc.)
@markjivko "You may love it, you may hate that I'm right" This comes across very arrogant, not sure if that is your intention.
@@markjivko quote: "(3) "hypermedia as the engine of application state"APIs are meant to be stateless" -> HATEOAS is not a contradiction with "APIs are meant to be stateless". I have no clue what you are trying to say here.
Of course that's my intention 😂... not. I may sometimes come off as arrogant and I'm sorry about that.
It's kind of hard to warn people about a fire without sounding just a little bit anxious / alarmist / negative.
Most arguments you bring up seem to be against server-side rendering, not HTMX.
was thinking the same thing, his argument is more about doing less on the backend and more on the frontend, but tbh I feel like he doesnt really understand how to use htmx in general
Exactly.
You are right. I do believe server-side rendering is short-sighted in most scenarios (obviously, not all).
But that's not my ONLY argument against htmx - read the pinned comment.
You clarify in the pinned comment that you are talking about large projects, but here you also say "most scenarios". Do you think most projects are large projects? Or do you mean "In most scenarios involving large projects?"
Yes, I mean in most scenarios that involve projects that are meant to become large - or profitable - at some point in the future.
I would argue that it is not premature optimization to consider scaling from day 1, regardless of project.
That being said, there are, indeed, countless projects that would benefit from htmx: internal tools, proof of concepts, "known-scale" projects, portfolio projects etc.
Thank you for your kind contribution.
So many wrong things here, just taking one: sending the whole HTML. That’s not what HTMX does, it sends small chunks of HTML. Which you can cache, compress, etc.
"That’s not what HTMX does, it sends small chunks of HTML."
Let me explain this the best way I can, in terms of space complexity for the bandwidth requirements of your User Interface.
1. O(n) = 1 for an SSG cached with PWA web workers. Constant space.
In other words, the entire UI "shell" gets downloaded once, then cached until the next update.
That may be quite large (3MB+), but it only happens once per user.
2. O(n) = n for SSR. Linear space.
Your UI "shell" gets re-downloaded in chunks with each user interaction or other triggered event.
The more the user stays on your app, the more HTML chunks are downloaded, displayed, then discarded.
There are many scenarios where you don't care about your bandwidth, latency, or internet connection reliability and offline support. Those may be great candidates for htmx and other SSR approaches.
But if you do care about egress (the cost of bandwidth), as you plan to scale your app to at least 1000 active users, then you really need to consider that the difference between Gigabytes egress and Terabytes egress in terms of cost is jaw-dropping.
@@markjivko but #2 doesn’t happen with HTMX either. The difference is between calling an API that returns JSON vs HTML, that’s the only difference for this bandwidth cost discussion.
If #2 is happening with HTMX is because you are not using HTMX correctly. You are essentially using vanilla HTML, negating the point of using HTMX in the first place.
So, the idea is that for every event/user interaction you call an API. This API could return HTML (with HTMX on it) or JSON, still up to the FE if you want to cache the API call. Either way, HTMX is not the right tool for every web application and the same for React. I believe that HTMX fits more applications than you think.
@@markjivko Your video is interesting because there is not much people talking about the difference cost between running some code in a server and using the client resources. In .NET there is Blazor Server and Blazor WASM. Blazor Server is using signal R and when you click a button there is a road trip to the server. I have never ever considered this option.... Reducing our cost, being greener and offline support are great stuff!
Short story time. I run multiple tiny SaaS just for fun.
One of them recently passed 100GB in monthly egress for its API. The service is quite small, less than 1000 active users.
If I used HTML chunks instead of pure JSON, that egress number would be closer to 100TB, which would totally bankrupt the entire project.
I know that what I'm saying is not sexy. But trust me, egress costs are a nightmare!
HTMX might be this cool "new" toy, but buyer beware! You might NOT afford it at any meaningful scale.
@@markjivko It seems your arguments are more against Server-Side Rendering than HTMX specifically, as in you argue that web apps should be SPA-like in order to save data transfer fees. I can't really say for sure if that's always going to be worth doing, but in some cases it might be worth the savings. There are other technical considerations though like speed of first page load.
I believe that you believe what you are saying.
As someone who uses HTMX, it does not feel like an honest review of HTMX.
Have you built anything with HTMX?
Here's a code example: github.com/markjivko/rpg
It's an entire Browser Game Engine I wrote in PHP as a WordPress plugin.
It uses HTML as transport for API calls - much like htmx.
That's WordPress land, so what can you do?
If I had to rewrite that entire thing from scratch, ditching HTML as transport would be the first thing on my list.
Separation of Concerns really is something you don't notice until your project reaches a certain scale.
@@markjivko So the answer is no you did not.
I will look at the project this weekend.
It's been a week.
So? Did it absolutely change your life?
@@markjivko Using HTMX or similar approaches for a real-time browser GAME??? That's like using Beer to make Milk & Cereal breakfast. IT's just the wrong ingredient combination for your ultimate goal.
I didn't say I used HTMX for the game, just Server-Side Rendering for some of its components (like dialogs).
Here's a demo: ua-cam.com/video/KABh8CwpSM4/v-deo.html
Here's the source code: github.com/markjivko/rpg
If I were to build it again, I would probably go the WebGL/Canvas route instead of the pure HTML/CSS approach, with a heavy SSG UI and pure hydration component for the backend.
I chose the SSR route "because WordPress".
you are too much into JS and you think you are losing your job , that is what I hear, projects need clear solutions , not megabytes of JS per page to render every tiny little element.
The video is fully packed with fear-inspiring statements not backed by facts or backed by imaginary facts.
For example the "separation of concerns" between backend and front-end: if the two were really separated, the front-end would have its own server, and the data would not need be validated again on the server.
"the front-end would have its own server"
Front-end does not necessarily mean a web-facing browser. It can be a WebView inside of an iOS or Android application, it can be a rendering thread inside an Electron.js application or some sort of micro-browser application inside your Fridge display or a standalone Native app written in C#/Unity or whatever.
The "front-end" is a shell, and it can be quite successfully separated from the backend. It's called static hydration - and it's quite trivial with something like node.js or next.js
My argument is that your API should be portable. It should be able to talk to your Browser app, to your Electron app, to your Android app AND to your native implementation of a UI in a linux-based environment or a Unity/Unreal app etc.
HTML should not be the transportation layer because it mixes concerns: data and presentation/layout/rendering.
That's it.
But to each his own 👍
@@lasoloz6972It looks like he still hasn't heard of react server components, next.js etc.
@@markjivkoyour point about APIs being portable. I wish things were that easy, after so many bad burns, I have learned that code duplication is not the demon that I learned when I was just learning programming. Code duplication is the right tool more often than you would think, over abstraction is way more damaging to a system.
So, having different APIs for web vs mobile is way better than sharing them. Web needs speed, you need the ability to change the APIs way more often than mobile. We all think that we can deal with versioning and other techniques but let me tell you, it is very, very hard to do.
Solving a LeetCode problem with optimal O(n) is hard, but that doesn't mean it's something you should avoid IRL.
I agree there are many scenarios where "the fast approach" is preferable as most SaaS ultimately fail - but that's not a compelling argument for me to ditch DRY, SoC and all other principles that make SWE more than a silly game.
@@markjivko no need to ditch SoC/DRY, but what about this: perhaps there's a viewpoint from which these principles are not at the top, and perhaps from the same viewpoint HTMX is great.
By mentioning SoC/DRY often and soon it suggests you are seeing SWE from another viewpoint than people who see value in HTMX.
That does not at all mean you are wrong, it just does not give the impression that your opinion is ready.
The simplicity of having state in 1 place, the server, and the ability to use your programming language of choice, without the need for specific frameworks i think are the most important pros.
The complexity of having 2 apps one in browser and one is server, is what htmx try to solve i think. Maybe for some apps this is not possible so htmx alone cant do it, but still its usefull.
You don't technically have 2 apps. One is a shell (the UI), and one is the Hydration component (your API).
This Separation of Concerns allows you to export the shell further:
- to mobile as a WebView component
- to desktop as an Electron.js app
It also allows you to rewrite the shell independently from the API, opening the possibility for truly native apps - think Unity or Unreal "shells" that communicate with the same API; Internet of Things apps, VR/AR, you name it!
"A shell is a shell, and the API is just an API."
I would call this approach simpler than having everything smushed together on the backend.
If all the state we need can be saved on the backend, why to break the app in 2? Server can know, and send the HTML ready.
State
1)app state = server state
client just display what server sends
2)app state > server state (HTMX and some javascript)
client has internal state that can't be
saved in the server, but its not so big in size
3)app state >> server state (react?)
client has internal state that can't be saved on the
server, and its very big, hard to handle with javascript only
If this makes sense, i guess htmx will be mainstream, because the majority
i think are in 1) or 2) category, but maybe those that i say don't make
sense, if someone knows can help with the limits of HTMX, based on state needs/perfomance etc
@@wdeath User experience + consumer agnostic APIs. You can't ship HTML to a native mobile app or smart tv. If you lose part of your response with a fully server approach, your application is dead for the client.
The whole point of HTMX is to move as much app state away from the client onto the server... With HTMX, separation of concerns is MORE strictly enforced than react because you have no client side state. The server is responsible for app state. The client gets HTML. Your example at 1:10 makes it seem like you haven't actually used HTMX. If you are waiting too long for HTML responses, its actually a skill issue, or an edge case, in which case you can just use something like React as part of the component that needs requires more complex client state.
I'm not sure how handling everything on the server is better for separation of concerns. Moving client side logic to the server imo just seems like something backend devs would want to do because of their superiority complex.
I do like the idea and think it can work for a hobby project, but I can't imagine it scaling well for something like facebook.
@@JanVerny Implementing SoC in the backend is already required. By handling all the state in the BE that allows you to use HTML and web requests in a stateless way - as it was designed to be from the very beginning.
There can be a million reasons why you might want to have state in the FE, and for something like Facebook it might be required, but 99% of real world projects out there are not Facebook and you can accomplish the same features without having state in the client. It just adds complexity because you already have to deal with state in the BE - so why do it twice?
@@lobaxxDon't think I can agree. By definition, you are taking a concern that was previously entirely within the frontend domain, and you are merging it into your backend. Increasing overall complexity. It also seems like you guys don't understand the point of RESTful APIs, as the server is the thing that is supposed to be stateless. The last sentence sounds completely insane to me, if your server is already dealing with state, you're doing backend wrong.
@@JanVernyState is defined two ways. Global state (things held across sessions and users) is held by the server in the database. Then there is session state like what page your on. In both react and htmx session state is held by the browser. In react as variables in htmx generally by url or by putting different elements on the page. The big split though is in global state. React copies some portion of the global state to the browser and then tries to keep it in sync with the server. This is very bad separation of concerns. In htmx your browser knows nothing of the global state and just displays what comes from the server which stops the back and forth of sending global state both directions and trying to deal with error management around state changes.
@@JanVerny No, the concern was not “previously entirely on the front end”. The Single Page Application-era were as much state as possible has been handled by the FE is fairly new. However, for 99% of all applications all we are doing is duplicating the state management, which means unnecessarily complicated applications.
Previously, stateless frontends were all the rage. Remember when everyone built RESTful apis? Or when you had templating using PHP, Rails etc?
HTMX is a twist on that tried and true approach, while trying to fix some of the flaws that made developers seek out SPA’s and FE-complexity.
1:31 - "You need to parse the server response". That's where you went wrong (and downhill from there). The point of HTMX (or Hotwire) is - you do all parsing and preparation on the server side inside your server-side framework. The response needs to be ready for consumption right away.
HTMX is not an answer for everything, but it's a good alternative for a lot of CRUD monolith applications. Use appropriate tools for the situation.
HTMX does debounce-ing, event bubbling etc.
"if you need to do anything non-trivial with your server response" - don't gloss over this one.
HTMX cannot handle event bubbling well - consider there are other events except onClick - because the UI flow/state is interrupted by API calls inside a library you have no control over.
@@markjivko ""if you need to do anything non-trivial with your server response" - don't gloss over this one."
I think everyone is going to interpret "non-trivial" differently. I am no frontend devel; I've done few simple things with vue recently. So maybe I'm biased, but the examples you immediately go to in the video (parsing stuff for canvas, etc.) sound like black magic to me.
I mean, I get it, if you're trying to compete with Netflix then sure, you need to know your stuff but sans my own skill issues, is really anything less than that "trivial"?
Carson said it was a library not a framework
Localization is the problem with HTMX --- not really
It is if you're trying to extract data from the HTML response and do something with it - in JS.
Why would you be trying to extract data from the HTML? If you're using HTMX, you are receiving fully-formed HTML that is getting swapped into the page. The server has already considered how the data should be presented and the client shouldn't have to care about the data used - it simply needs to display it. You wouldn't use HTMX to return data for consumption in a customer-facing API. It isn't a substitute for JSON, it's an entirely different approach.
--- "if you want to do something non-trivial with that response"
Meaning, if you want to parse the response into a Canvas element, or write something to LocalStorage etc.
You would need to extract that data from the server response (which is HTML) somehow: either with regex/tokenization from string, OR post-insertion into the DOM with node traversal.
Even if there wasn't a better way to handle it with HTMX, you can add endpoints that return JSON data for these edge cases and handle them with scripting. I don't think there would ever be a situation one could get themselves into that would require parsing HTML.
Excellent point! Really - "you can add endpoints that return JSON data".
That is what I would call a fractured API. It sometimes returns data, other times it returns HTML. It's no longer a consistent API, and all because you did not follow proper SoC from the beginning.
This is only the first negative side-effect of this approach. As your project scales you'll encounter more edge cases, and more issues.
Don't take as arrogance, but this video shows how little you know about the technology and software engineering.
#1 separation of concerns: htmx has nothing to do with internationalization neither with separation of concerns. This is a design/architectural decision.
#2 ux: it's literally the opposite of what he said, you load chunks of html instead of full pages - that's why htmx was invented. Giving the simplicity of templates back + Single Page Application (SPA)
#3 devx: the opposite again, with htmx any person that knows html and basics of JS are good to go. React you probably need a course. Plus overtime JS frameworks tend to die or get bloated trying to keep up with new new features of frameworks that releases every day.
1. In this case SoC refers to the separation of concerns between the UI layer and business logic (backend / API);
UI does not have to mean HTML - and maybe this point causes confusion. Think Mobile Applications (native code), desktop apps, IoT apps etc.
One learns to appreciate SoC once the codebase passes a certain threshold in size/complexity and usage.
2. UX refers to the User's Experience in using the application, not one's experience as a developer working on the app; lack of offline detection, lack of graceful degradation in internet connection issues (latency, race conditions etc.) and others negatively impact UX
3. You're not a developer if you don't learn your tools. Yes, that means "needing a course". I would argue one needs a whole lot more than just a course for DevEx to begin applying to them.
"Don't take as arrogance, but this video shows how little you know about the technology and software engineering." - that is not arrogance, that's an insult.
I presented some arguments against a library - not against you as a person. So the fair thing to do is to present counter-arguments in favor of that approach, not to throw insults.
You start with "Don't take as arrogance" then immediately follows with an insult **sigh**
In view of UX, DX and cost/carbon footprint.
a. You will find it very hard to build modern UX frontends with HTMX, even simple things like dynamic modals, bind/rebind to javascript components is a pain.
b. You will create an unmaintainable mess on your backend, with all the html fragments and endpoints and HX events scattered between all these.
c. You will be the dev who increases your client's or employer's hosting/compute bill, because your HTMX is hammering the server for every state change, when you could have just relied on the browser.
@@depafrom5277 Saying the truth is not an insult. He's trying to teach a subject he barely knows how it works. Feels like I'm watching a bird trying to teach a fish how to swim. But honestly, I saw other videos on his channel and he's just messing around for the meme so idc.
a. If you're dealing with binding/components/too much javascript with HTMX you're using it wrong. You are probably trying to apply what you have learned in frameworks like React to a completely different technology. "If the only tool you have is a hammer, you tend to see every problem as a nail".
And no, having a "modern ux" has barely anything to do with the tech you chose.
b. Mess code = bad design and poor coding skills. If you're messy then it will be worse with any javascript framework, since you still need to write the HTML + framework logic + API.
c. Yes, HTMX is server-side rendered. You have to consider this when choosing the technology. You can get around this by generating static HTML and just serving it, it will be less expensive and more performant, but this approach doesn't fit every use case. Rendering on client also have drawbacks like the experience will be worse for shit devices.
"Huge HTML?" Not true, you can get just a partial response. Did you use any other programming languages?
Yes. I've been writing software professionally for 15 years. Most of it in Java, PHP & Typescript.
Payload sizes for HTML > JSON > bJSON.
Not my opinion, just the technical specification.
@@markjivko You literally said in the video 2:15, that you have to wait for "an entire HTML response, huge HTML." That's just a stupid argument.
I don't make stupid arguments. Only arguments that may not resonate with you at the moment.
My argument is that - AT SCALE -, HTML is much larger than JSON because HTML also carries layout and styling information. www.ietf.org/rfc/rfc1866.txt
Whereas JSON (and binary JSON), can only carry data.
When your app reaches SCALE, you do start worrying about egress. A lot. Because it's really expensive, still.
And that's when you begin looking for solutions to compress and reduce those API calls. Yes, brotli/gzip, whatever can help. But not by a lot. Your best bet is to simply strip anything and everything that isn't pure data from API responses, merge multiple API calls into 1, and cache API calls as soon as possible. And since PWA WebWorkers are a thing, abuse them to cache your application skeleton (the UI), entirely in LocalStorage so you get 0ms response time on app loads and offline mode support after that pesky first-load event.
I get it. HTMX is easier. It is an awesome tool for localhost apps and tiny PoC.
But when you do get to have uncomfortable discussions around that egress bill, you begin to look for alternatives.
@@markjivko Again, it depends. Working with JSON costs something as well. There is no silver bullet.
Do you think that AVG consumer of this video have to care about this? Make it simple, if you really have this kind of problem, there are solutions. But using this argument against good tech that can help people to ship fast is wrong.
"But using this argument against good tech that can help people to ship fast is wrong."
As you mentioned yourself, there is no silver bullet. Even the absolute best tech has its drawbacks, and we should apply critical thinking.
If the argument is valid, it needs to be pointed out, whether the tech is good or not.
I'm not preventing anyone from shipping products fast(er), only warning about tradeoffs and edge cases at scale.
Your position is "I like this tool, so don't judge it".
If we were talking about a Bosch cordless drill, maybe you would care less about my arguments around max torque. But since htmx is more of a "movement" than a tool, I guess it attracts inflamed emotions.
We should all try to do better. Be more rational. Apply first-principles reasoning more.
Thanks for raising some warnings. I am not ready to ascertain the merits yet but glad to listen to them !!!
Localization should be done on the server side, as everything else. So based on accept-laguange + url path you will return the correct localization. There is no issue, related to HTMX...
- Internationalization (i18n) can be done server-side, but it's a presentation concern. As such, following Separation of Concerns, it should be part of the client application, not server-side. Unless, of course, you're internationalizing your API errors.
- Localization (l10n) refers to numeric and date/time format, currency, keyboard shortcuts, rtl/ltr orientation etc. These are exclusively client concerns. These should never be server-side concerns.
You can obviously do everything server-side. That's how we did things 20 years ago. But modern browsers have evolved to allow us full separation of concerns between the client and the API and I think we should take advantage of that.
Mixing concerns leads to headaches. How do I know this? Well, among other things, I've built a game engine from scratch that uses Server-Side Rendering of "html chunks" delivered through AJAX calls 5 years ago. Bad choice. github.com/markjivko/rpg
If I were to build it again, I'd go for react.
@@markjivko false. For example sending emails or notifications requires to have Localization on the server. What I am saying here is that you are using arguments that are not generally valid. It always depends on the specific implementation.
for context: I was working on projects that have several languages and money/date formats. And yeah I have to iterate to get my working scalable tech-stack: "Most of the things on the backend, stupid & replaceable client-side part".
We were talking about Web Applications. Let's not compare apples to oranges.
(web) notification and e-mails are not web applications.
Localization of a (modern) web application can and should be done user-side. The same way you localize your native iOS or Android app, for example.
"Rich media" applications like dynamic ads, banners in IoT devices etc. can and should be internationalized server-side. But those do not web applications make.
@@markjivko web application can not send emails or notifications? There are full-stack apps.
Minimum Ethernet frame length is 64 bytes. STATUS:OK or some more HTML is literally not important because it fits inside the frame either way.
One area where DX is more important than UX is for internal dashboards or an admin UI
I liked that he casually shit on jquery as well, despite jquery4 coming out recently, and jquery being far more appropriate for 90% of companies use cases than any of these overwrought and needlessly complex javascript frameworks he's likely a fan of.
I'm not a fanboy of any tool. I don't "shit on" or "highly applaud" anything at all. Ever.
In fact, here's a game engine I wrote 4 years ago that uses SSR under the hood (very similar approach to htmx) and - drum roll - jQuery:
github.com/markjivko/rpg
I'm not advocating for or against anything in particular.
My argument is that Separation of Concerns matters more than that made-up "Locality of Behavior" - if you're interested in scaling your projects to more than a handful of developers, more than 10k active users, and more than 100k LLoC.
Just for fun, all tools are awesome!
@@markjivko right, memberberries is completely judgement free and neutral and doesn't carry any negative connotations.
jQuery4 or not its still jQuery, and its solves a very different problem than React, Svelte etc. "90% of companies use cases" when did you run the world-wide survey to get that exact percentage?
@@depafrom5277 I never said they solved the same problems. I thought somebody was going to try to make hay with that, so congrats, a winnar iz you. Still doesn't change that he was dumping on jquery which he denied, and that while they serve different roles jquery is still more likely to be a more appropriate inclusion for most companies.
And 90% is generous. According to Forbes 99.9% of all businesses in the U.S. are classified as small businesses.
This breaks separation of concerns far less than putting logic in the frontend, especially if you replace HTMX with something like alpine-ajax where you literally just write an MPA and progressively enhance it, or if you use htmx with a forge plugin that adds things on top as part of server-side abstractions
HTMx is non binary HTML?
110% correct !
Your entire argument against HTMX is that it makes it difficult, if not impossible.. to build systems using shockingly bad anti patterns.
Like client side state management in JavaScript for starters.
I totally agree
#sarcasm
😂 so why exactly was htmx created? Has React-development become so bad that someone thought moving back into time is the only way?
React ain't that bad. It's just that people are sick and tired of the front-end framework/library treadmill.
A new week, a new shiny toy.
At least with SSR, nobody can tell you how to write your HTML, damn it!
From my experience it depends on what you are building.
Are you building an app where computing is mostly on the client (dashboard apps, facebook, youtube etc)? then nextjs should be amazing for you
Are you build a load sensitive app where most of the computing can be done server side (ecommerce, blog, landing page)? Then htmx should be your new best friend
I agree. There are plenty of scenarios where a tiny shiv like htmx is "good enough".
That being said, if you're going to do any sort of front-end engineering, you'd better know your tools. Because built-in, vanilla fetch() and .innerHTML replace the need for htmx in a second.
You’re saying all this like you have to force your JSON API to send HTML?? Why not just leave your data api alone to do it’s thing. Imagine not having to rebuild your data endpoints with every front end change because you use get peeks at safe server rendered data with HTMX on the front end.
No it’s not for every project but saying it’s useless or costly at scale is just plain silly with nothing to back it up. I’m sure Netflix is just letting Prime code HTMX all over the place because they are getting on the hype train. Surely they don’t see use cases for it in gigantic projects. They are probably getting paid off by the one man company in Montana.
Aren’t you just doggin HTMX to use the hype train for for your own server rendered answer anyway? Well played Sir.
It is costly at scale: ua-cam.com/video/HlVsfyHT-Lk/v-deo.html
Don't invoke the "Authority bias" argument here - who cares Netflix and/or PrimeX did/does something? That should not be a substitute for your own reasoning and critical thinking.
I'm not talking about HTMX to get on some hype train - I do it because at least 1 person needs to state the case against it. If you search for "htmx" on YoutTube, it's just 100% pure love and support - which makes no sense to me. You don't see that with any other library - jQuery, Bootstrap, Livewire, Tailwind, you name it.
Someone has to state the drawbacks. What do I know? Well, I've written a PHP framework from scratch 13 years ago, then a CMS, then I built and sold a web Game Engine that relied heavily on SSR.
With all due respect, I am not trying to troll anyone. HTMX really does have massive downsides and the SoC issue prevents it from scaling beyond tiny projects.
Netflix is not using HTMX lol
Server side rendering has its advantages, for instance if a user does not have permission do view a certain page / area / element he never receives that element. Even if the backend API is secured, just being able to see those interfaces might leak information.
But I'd never move back to such a framework/library ever again, ASP was enough for me. Simple things are simple, complex things are near impossible or hacky and dirty.
I agree with you about the "UI data leak" of next.js and friends. However, there is no such thing as "security by obscurity".
For best results, simply hiding your sensitive API endpoints won't do. You still need to thoroughly secure those calls on your backend.
So I don't really see this as a huge concern. Especially when more serious issues like prototype pollution take the spotlight.
Bottom line: "I do believe server-side rendering is short-sighted in most scenarios."
SSR is short-sighted. It's only adequate for small-scale or localhost stuff.
I ran an Android dev studio for a while. Hundreds of apps used by 100+ million people in our "glory days". Using an SSR approach at that scale would have been suicide.
I am so excited about Progressive Web Applications and the modern web for this reason - we can finally have "web apps". True applications. Completely decoupled from the backend, completely hosted on the end-user's device.
PWAs enable massive distribution at low cost by shifting the rendering responsibility to the rendering device itself.
I really don't see why we would want to go back 20 years OR how anyone can make financial sense of this htmx/ssr stuff - at scale.
@@markjivko1. why would you need PWA if you want your app to perform in realtime? Who wants a limited static mobile view version of a website unless its a Kind of Offline Portfolio Showcasing ...like a website of a service provider. Cuz user can simply make a bookmark on screen of any webpage and also user loves to interact with native apps that gives them rich user experience. Nobody wants to watch youtube in a PWA, ppl love the rich ux of YT native app.
Progressive Web Applications are not a particular style of web app, rather a recent extension of browser capabilities under one umbrella: web.dev/explore/progressive-web-apps
You can enhance any web experience with various PWA functionalities like local storage, caching, access to various sensors etc. - whether those apps are "rendered" server-side, or they are fully static.
Also, statically generated apps can behave quite dynamically with API hydration. You just need to carefully manage that state with, let's say, next.js or similar. Nothing's stopping you from implementing your own solution in vanilla JS, so I'm not arguing in favor of any specific js library.
Finally, UX is a very complex topic, not well covered in a comment section like this one. If there's just one point I'd like to make is that bandwidth and latency issues do negatively impact UX. So beyond the initial loading time for a locally-cached PWA, you really can't beat 0ms response time for assets. At a certain scale, you do want your API responses to be as concise as possible for better UX and lower server costs.
That is my argument. HTMX might be great for small-scale apps - in terms of lines of code and active users. But there's a certain threshold, though, where SSR (which is the approach behind HTMX) begins to fall behind in terms of costs, performance and UX.
Hey @markjivko, those concerns you've got look awful separated, maybe put them back together again for better locality of behavior, eh?
"Locality of Behavior" is not a desideratum in SWE. Separation of Concerns is.
Let me explain.
Locality of behavior only works, so to speak, for extremely small codebases.
- Once you reach any non-trivial size (say 10k+ logical lines of code), you're going to have to apply some design patterns. All of a sudden, your behavior is split into multiple files, in various folders.
- Once you reach any non-trivial feature set or scale, you're going to want to break that monolithic architecture into microservices; DDD and other principles come to mind; your behavior is even more scattered.
These design decisions are not only necessary, they are correct. You should apply divide-et-impera as you scale.
Contradicting "Locality of Behavior" is actually a good thing. You want separation between application domains at certain scales.
Unlike LoB (which is made-up by that htmx guy, by the way - not a real term), SoC (Separation of Concerns) actually matters a lot - at all stages of your application.
Your front-end is not HTML-bound. It can be a native app (android / iOS, desktop), it can be a hand-held device etc. Sending HTML over Remote Procedure Calls works just fine enough if there's a browser listening at the other end, but what if you want to digest the same API from different clients?
HTMX is great for small stuff. It's naive. It's fine. It works. But at any non-trivial scale it falls apart.
EHTML allows to work with JSON
e-html.org/html/documentation.html
It is only frontender's talk, who dont know (seems) about partial html markup responses from backend, dont know about brolti compression, and about http response headers whitch will be parsed by default. In real cases HTML markup (xml in fact) response form HTMX will be lighter and faster then json+frontend_templates+tons-of-js-for-rendering.
If this approach does not fit in the head of fans of overly complex frontends, then this is because the head is occupied with kilogams of superfluous JavaScript 🤷♀ Just try HTMX in action!
Funny how this video starts with an entirely wrong statement. You can in fact send json or god forbid xml with htmx and it works fine if you are into it. The author of the video didn't even read beyond the first page of the htmx docs
I know this exists: htmx.org/extensions/client-side-templates/
But as 99% of HTMX fans will argue "that's not the point of htmx".
if server-side rendering is soo bad as ure making it sound, then y is ur react and next js moving everything to the server now 🤣🤣🤣
just face it, react and next js is nothing more than decorated php with vanilla js
2:22
Well, this brings up, you haven't even tried it, but complaining.
Because HTMX is about PARTIAL rendering of HTML snippets on your API and replacing components, not about entire page reloading.
I have tried it and it's "good enough" for small-scale projects. But that's it.
Here is my personal opinion. If I were to start a greenfield project tomorrow I wouldn't use htmx. That's because I can perform .innerHTML and other DOM mutations on certain events with vanilla JS in just a few lines of code. To me, the problem htmx solves is absolutely trivial. For me, using htmx over vanilla JS is like importing that "is-even" library from npm. www.npmjs.com/package/is-even
The arguments I'm making in this video pertain to large-scale projects - in terms of features, team size and active users.
@@markjivko I like HTMX idea in a sense, you can create frontend using Pure HTML and less JavaScript. And especially, because you can ditch nodejs.
I've seen Full-Stack Python FastAPI examples and I eager to try that. No NPM was used there. Only Jinja2 templates and one tag pointing to unpkg.
I get what generating HTML on server side idea can be somewhat extreme or edgy. But no one stops you from using JS on browser, just use less of it. You can also use mustache or Alpine.js to generate forms on client-side, for example.
My eye twitches every time I think about learning Vue or React is a MUST to create a web site and I have to install nodejs for it...
Yeah, I'm not the frontend developer, but sysadmin. And I mostly write in Python. I have to admit.
I appreciate your perspective and coming from a purely "back-end development world" I can understand your frustration with the insane front-end world.
We do have too many frameworks today. That is a fact.
But ultimately your users don't really care what you used to build their solution. There's a time and a place for htmx, that's for sure.
But if you do want to take control over that annoying browser, you need to master javascript. Forget "The Frameworks" or "flavor of the day stacks". Just pure, vanilla javascript.
Once you see what a modern browser can do - I'm referring to Progressive Web Applications, WebGL and more -, you'll likely never think about htmx ever again.
@@markjivko I love PWA, especially a Photopea one as a good example. But it doesn't really matter how much javascript or frameworks I will learn, I am very confident, I will never write one. Even If I will, I will try a WASM (Flet aka Flutter, for example) approach first.
Skill issue 🗿
Damn right!
I tried it and it sucks. It is like untyped string concatenation but between server and client and a lot of state in the middle
This guy gets it!
ENTIRE html response )) http overhead and network latency eat your status response anyway.
People state opinions as facts without proof. I don't do that.
Here's a recent experiment I ran:
1. Send WebSocket frames of 64k bytes each with a Ping signal for each individual frame - download speed: ~750kB/s
2. Send WebSocket frames of 64k bytes each with a Ping signal every 16 frames - download speed: ~7MB/s
The largest bottleneck was, intuitively, that Ping/Pong signal, right?
Well, turns out, in the case of a duplex connection like a WebSocket your "overhead" is almost zero. And the network latency is the same in both scenarios, so that's not a factor.
The issue was how that Ping signal was treated by the client application. It added tens of ms to each frame, without actually sending any data over the network.
In the case of HTML over JSON as an API response, there are fewer variables. No complex handshakes, no duplex to worry about. The only difference is payload size. And HTML is more verbose by its nature - so it will return slower.
And if your app is very "energetic", that means many http requests and waiting for large payload responses, which degrades UX.
Contrary to what I would suspect is not actually popular belief, "the state" does not just mean database. Your app will also have a "visual state" - which can and should be handled entirely by your front-end.
Having to clumsily send HTTP requests every time someone clicks on an "increment" button is naive - and we can do better in 2024.
useEffect() and useState() are really all you need to master react. PWA webworker caching of an SSG hydrated with API calls results in much better UX than an SSR.
What do I know about SSRs? Here's a game engine I wrote 4-5 years ago, that renders HTML received over API calls (with jQuery, as a WordPress plugin): github.com/markjivko/rpg
@@markjivko so wait a sec, you claim ping/pong in websockets keeps CPU busy for 10s of ms? Did I understand it right?
In this case, the host did more than just listen to that ping frame, it had to move a pointer in an open file handler and initiate a new message as a Blob object.
That didn't necessarily "keep the CPU busy", meaning the CPU wasn't actually at 100%, but the extra steps taken by the client script added to a few tens of milliseconds per batch, which translated down the wire into massive bandwidth losses.
Getting back to the htmx discussion: more http requests and larger payloads don't make for a smoother experience.
You have the option in 2024 to fully cache the entire UI component of your HTML application with a webworker. All of it. That's 0ms load time every single time after that initial load event. So you completely eliminate the bandwidth discussion for your UI.
All that remains is data. Pure, clean, tiny data.
@@markjivko I fail to understand how this seemingly a performance bug in handling websockets is related to html vs json workload. If anything this proves that you shouldn't overload the client (which can be pretty thin) with rendering. +20ms is a very noticeable change in client experience and no, additional workload cannot change this, but the client context switching can.
I personally think there is a place and time for SPA and there is one for SSR. Noone should claim one is absolutely superior to the other.
HTMX will not make sense to forntend devs
HTMX does not make sense for backend developers either.
I'm saying this after 15 years of software engineering, and having used Server-Side Rendering for most of that time.
Mixing layout/rendering concerns with pure business logic always results in code spaghetti.
By definition, rendering is something that always happens on end-user devices. So I don't see why one would introduce a networking bottleneck (with latency and bandwidth issues), to pre-"render" some HTML tags server-side (with added compute, memory and security issues), when the end-user's device is still ultimately responsible for converting those XML tags into - you know -, actual pixels, UI and buttons, animations and such.
Actual, pure rendering always happens on client devices - whether it's HTML, native Android code, native iOS code, native Windows code or anything else. Actual, pixel-level rendering still requires client-side compute and memory.
I believe Theprimeagen and others recommend HTMX simply because of its small learning curve, confusing simplicity (which is a desideratum in SWE) with naivety.
@@markjivko "Mixing layout/rendering concerns with pure business logic always results in code spaghetti." But this is what React does, does it not? The problem with React is that it holds data and behaviour attached to the data inside of the components, not outside. It's okay to have logic of rendering components inside of components, but I think it's not okay to have logic that controls state of the component inside.
And it's not easy to control many separate components in React just because the whole synchronization logic is in the components via very esoteric abstractions like hooks.
Dude you forget HTMLX is javascript based. it implements such as GET and POST as tags on frontend (it's literally on the *first page* of the HTMLX website). you don't need them to be integrated on your backend and throw HTMLX crap. your backend just be backend throwing JSON/WSS and HTMLX just be frontend and display it.
HMTLX is seems like old tech.. first AJAX pages actually wasnt with JSON data whey contained html parts.. after was converted to XML and after this JSON. So whats new here actually? Also as backend dev you have to know how you data will be used you cant just generate random you need 'context'
You are correct that it is an old tech but fixing some bad roads we took back then. I highly recommend you to read about HATEOAS vs RESTful, HTMX is pretty much based on the original HATEOAS ideas. Honestly, most of what HTMX does should be supported by the browsers by default.
i agree these points , that is why i am now switching to alpine ajax same as htmx but different , it does not need whole html to be sent to http request, talk about this alpine-ajax
amazing, thank you so much bro, i wish i could send you 100 right now for the time you saved me lol, get a patreon or something imo (although i feel you are very wealthy so prob don't need small donations)
You very kind words are more than enough payment!
I'm glad I could be of service.
If there's one thing I forgot to mention in the video is this - always form your own opinions based on first-principles reasoning, and never blindly trust any "Authority" , be that person an influencer, ex-Google, CTO at OpenAI, or a University Professor with Tenure and 6 Nobel Prizes in {insert tech stack here}. Always questions everything and uncover the truth for yourself.
My next video will cover group think and echo chambers around HTMX and other tools. You can subscribe if you wish.
Thank you!
A lot of good takes in this comment field. In the video as well! Good discussion guys!
Wont you end up with some json API anyway? I mean you may need a smartphone app at some point ?
HTMX is created from some back end devs that can't admit that UI development became complex for a reason.
If your HTML is responsive, your app can be a single WebView.
Like Spotify.
That’s not it, I do both FE and BE and I recognize that UI dev is way harder than before. The point is that not all UI dev is that complicated, some it is, no question. For those, React and others frameworks are totally the right tool. But, there are a lot of applications that can benefit from something simpler. The point is that we don’t need to use React for everything.
I have no idea about developing for frontend, but this video is easy to understand.
I love your energy! Keep making the videos!
Thank you so much!!
I agree 100%
You can improve on your video title!
Maybe "Why you should never use HTMX"
@@anstropleuton Nothing like a less intellectual title for more viewer engagement
love the salty comments from the htmx cultists. good video Mark
HTMX seems like a XSS nightmare
Why is that?
You would have to make sure everything you receive is not escaping from the current scope. I trust most developers would do this but then again there’s bug bounty platforms for a reason.
@@kickeddroid isn't it simply a matter of sanitizing user input on the backend? XSS = prevented
i agree with everything in the video but htmx is not a xss nightmare, htmx doesn't provide any backend library to you.
so it's based on templating library or language you use on your backend.
@@birthdayzrock1426 he has no idea what he is talking about.