Video

I agree with you. But I'm not sure it's a need to stop others from working rather than a constant need to prove they are smarter. There's a saying, "those who can't do, teach, and those who can't teach, teach sports". I believe academic types have this frustration, a sort of inferiority complex. They need to constantly use big words and complex imagery to convey meaning. Whereas any programmer worth his salt knows you should "keep it simple, stupid", and complexity is the enemy of engineering. Secondly, academic types also need to pay those bills. Beyond tenure there's not much you can do - so you sell your "authority". You write books, you attend conferences, and you create courses and programs that have your signature on them. You constantly remind people how well known you are and how much you contributed to Scrum or whatever and you keep on tapping into people's authority bias to make a quick buck until your name becomes synonymous with charlatan at which point you retire to a villa in southern Italy.

Absolutely

@@markjivko I need to ask you something. Which framework do you recommend for purely client side rendering, which solves all those issues that you mentioned in the video (and others as well)?

You don't need any framework. I've used "vanilla" JavaScript for many years without issues. But if your goal is to build a slightly more reactive application, I'd recommend starting with either React or Vue. They have slightly different approaches to data flows and I prefer react because it doesn't "pollute" HTML with made-up attributes, like Vue. If you need something with "batteries included", maybe go for Next.js - a React framework. Ignore their recent SSR madness and go for plain old SSG: nextjs.org/docs/pages/building-your-application/rendering/static-site-generation That's what I'm using on most of my recent projects. What I love about an SSG (statically generated site) is not "Separation of Concerns", but rather its side effect, which is portability. Once you export your entire UI in a humble folder - so it's all just CSS, JS and HTML files -, you can literally put that anywhere. CloudFlare Pages, GitHub Pages, GitLab Pages, Netlify etc. for free CDN or even an Electron.js app for a fully native desktop experience. If you want, you can even export it as an Android app and load the folder in a WebView component. Literally write once and deploy everywhere. Hydrate that static folder with really tiny API calls and you're golden. The recent trend to re-consider SSR is misguided in my opinion. It focuses on DevEx (developer experience), i.e. the need to stop learning how do do things right in order to do things fast. It just erases 20-something years of hard lessons and progress to blindly go back to "f-#$k it, I'll use WordPress". If you care about performance and costs at any meaningful scale, SSR is a really poor choice. If you care about code extensibility, as your team grows - SoC is more important than the made-up term of "Locality of Behavior". You articulated this very well - it's best to delegate as much as you can to end-user devices. You get those CPU clocks and memory for free.

@@markjivko Great. Thank you very much for this advice.

Some CTO on LinkedIn wrote that "there's no such thing as front-end and back-end. you're either a software engineer or you're not". Harsh, but true. It seems to me that some of those defending htmx are willfully ignorant. As another commenter pointed out "they just don't want to learn javascript". You can't really appreciate the beauty and complexity of Software Engineering without deeply studying all edge cases. Blindly following a cult like htmx/intercooler/livewire without "doing your own research" as the web3 guys like to say is misguided. Run the benchmarks, simulate 10,000 active users, simulate throttled internet connections and egress costs and you'll reach the same conclusion as this video. DevEx does not trump profitability and UX.

I don't like "else if".

Next.js and other JS libraries transitioning to SSR is arguably a meme at this point, I agree.

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.

Exactly! And there are some techniques to help the brain send dopamine to the right brain channels. One of them is listen to a continuous sound like "Brown Noise".

I could not love this comment more. I think I should probably look for an engagement ring or something.

It's weird that there aren't 10.000 different SaaS doing this, right?

Yes. The websocket connection is alive only as long as your browser process is uninterrupted. It's also a good idea to keep that tab on top so that your browser doesn't throttle the javascript engine.

Can you kindly point me to a large project built with 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.

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.

I don't drink alcohol and I'm trying to get rid of my Coca Cola habit too. I'm nearing 40 yo and I need to start taking better care of myself.

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".

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.

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.

"like having to learn more front-end madness" - this is a critical observation. I don't know why those defending HTMX keep coming back to the complexity of React. This is a myth. I personally hardly ever use anything more than useEffect() and useState() in my React projects - so I would say it's actually a very simple library. The complexity lies in how you structure your project as it grows and HTMX does not allow you to properly separate concerns. So long-term, htmx-like projects (meaning SSR in general) tend to become "code spaghetti". Here's an example of a game engine I wrote that uses SSR in very much the same approach as htmx, 4 years ago: github.com/markjivko/rpg I regretted the "html over ajax" approach quite soon. If I were to greenfield this project, I'd probably use react this time and save myself a lot of headaches.

@@markjivko well for someone just approaching a very restricted part of web development with not much knowledge of js to boot I can simply say that it fills the gap I need right now. Being aware that I should not get to fancy with it to not create spaghetti code though is good enough for me. I’m sure react is not that difficult once you have a reason and time to work with it. In my case I presume it to be just overkill :), maybe late rthat will change. Thanks for the input

Yes

@@markjivko Reminded me of good old times :)

"CSR rebuilds your html each time, so it's also not really cacheable" You could export your application as a static SPA, hydrated with API calls. It's true that the first load event will be quite large - in the order of megabytes usually -, but there's a lot you can do to improve the UX on first load like deferred load, and just-in-time caching. Also, since the "shell", the static UI, doesn't change between app versions, you can fully cache that locally with progressive web application web workers. That means that all app loads after the first one are actually instantaneous - close to 0ms for the whole thing -, and available offline. All that changes is data. And you can compress, optimize and minify API response as much as you like, way beyond the capabilities of HTMX. I'm talking g-zipped binary json & friends. The point I'm trying to make is that we now have the luxury of treating a Web application like any other native app (Android/iOS etc.) - with full separation of concerns between its UI and data.

I disagree that React is complex. You can get away with only ever using useEffect() and useState(). I know I do.

I'm sorry this video wasn't a more thorough "level 3+" analysis of htmx - maybe I'll create that in the near future. Indeed, there's a time and a place for any tool, and HTMX does have its merits. I wouldn't call React complex, though. Really - it's a simple library. You can search for Marc Lou here on CZcams - there's a video where he says he never uses more than useEffect and useState in React, and that's enough for all of his projects. I share that perspective. React is actually quite a simple tool. I've written software for 15+ years and guided teams for 10+ years. I've worked with almost everything from telecommunications (i.e. SIP protocol and friends), to Web3 and AR/VR. Maybe I'm super-biased, but to me HTMX looks more like www.npmjs.com/package/is-even Just because many people download and use the thing doesn't make it a great library. Instead of "npm install --save is-even", which then also installs "is-odd" and "is-number", you could simply check modulo 2. As in, "const isOdd = (x %2)". Just because some (maybe many) people recommend htmx, doesn't mean it actually solves a problem. Remember that jQuery did actually introduce CSS selectors to the world of JavaScript. Before $(".className") you had to write a complicated tree traversal algorithm every time you looked for a class in the DOM tree. HTMX really doesn't solve much. It uses native vanilla JS functionality to send AJAX calls (with fetch(), instead of the horror show we had back in the 2000s), and then performs DOM mutations with .innerHTML and other methods. You could use htmx to avoid writing some tiny javascript logic for greenfield, small-scale project. That's great! But once you scale a bit, you'll notice your RPC calls tend to get out of hand. If you need a deeper example of how an HTMX project might actually look like, here's a game engine I wrote a while ago in PHP: - Source: github.com/markjivko/rpg - Video: czcams.com/video/KABh8CwpSM4/video.html The engine uses plain HTML as responses to ajax calls - much like htmx. I regretted this approach as the game grew larger because the UI became too fragmented. I hope this helps.

We all know someone like this guy, unfortunately. He can't hide his bias or arrogance. Comes off very self sucking

I would feel offended otherwise, good sir!

I'm making that point because people keep arguing SSR is faster "because building the DOM is JS is slow". I'm just trying to clarify that the DOM manipulations themselves are not costly - it's the re-rendering, re-layout steps that take the CPU to 100%. Indeed, that first load is rather large for Single Page Applications - typically. So it's slower in terms of bandwidth. But there are many techniques to speed-up that first load like deferred loading, caching etc. A SPA that is fully cached locally with PWA webworkers responds in 0ms to all requests except that first load. So my point was that SSRs are not, in fact, faster - because they're not truly delegating the rendering task to a remote server. Also - "rendering is rendering is rendering". I don't like it when people abuse language like that, especially with technical terms. "SSR" is actually just "html chunks over remote procedure calls". I would name it "html/rpc" and call it a day. Concatenating some strings server-side is not rendering.

@@markjivko Yeah if they think server side rendering is faster that's pretty dumb. Taking a template/component and resolving it to html (in this case) is rendering, always has been. That's just what it's called it's not an abuse of language

It's not rendering, it's "we don't want to bother using a better word". I understand using the word "rendering" server-side when building a byte stream of sorts - whether that's pure binary data like a video stream or UTF-8 characters. It makes sense in that domain as your "output device" is your network adapter/socket etc. But SSRs are "multi-domain" objects. They are created on/streamed from a server but actually rendered from HTML to UI elements in a browser. Same word, two meanings - a lot of confusion.

@@markjivko Language gets confusing sometimes yeah, it's not exactly ideal. But it's always been called rendering bro, that's what the word means. It's not some hacked, clumsy use of the word either, it applies just as much to an image or a compressed video stream as it does to markup

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 <script> 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.