Here's a link to the full interview: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-2A3sFIHXTPQ.html And here's how I built the thing in 30 days: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-mncu6GQIbtI.html
"seperation of concerns" is the argument used against react back in the day "you can't have your html templates in your JS, that violates SEperATIOn of COnceRNS". There's not something that magically happens to make your code base better when you put all the files with the same file extension in the same folder. Seperation of concerns needs to be dropped as something that is used in discussion or good practices. Its meaningless. I will always mix my concerns. I put my concerns in a blender. my code is a concerns smoothie
The only reason JS frameworks took off was because everyone was self-hosting their apps and bandwidth cost money. The offer of only sending data over the wire as opposed to an entire HTML document was very attractive when your ISP is gouging you every month. However now we live in a cloud-based world where servers are fast and bandwidth plentiful. We can go back to using the server to host (and secure) our app and only use the browser for rendering the markup to the user. But HTMX also gives us the nice interactivity that most people now are probably firing up a whole Angular/React/Svelte/Whatever.js app to do. You may write off HTMX, but plenty of us devs who've been in tech since BBSes will understand and appreciate its elegance.
The first three minutes accurately and coherently explained why react and heavy javascript spas are the stupidest thing to come along. Like, you literally talk about breaking separation of concerns, badly tying user interaction to application logic, which exactly what htmx fixes. React broke so many kids a decade ago
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.
I got a slap on the face just at the point 1... The video is amazingly amazing. I follow you on LinkedIn, and it is great you are sharing your knowledge here on YT as well.
I really don't know much about this topic, but I have a feeling that I would use as much client side as possible, because that would use clients memory and everything. It is like using energy of someone else for free. I personally don't like the idea of server side rendering, although now it is popular. More energy used on client side means more money saved in our pockets, right?
@@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.
I love how every 2 years Web devs try to reinvent the wheel. No matter what technology/ language is used, good software practices should apply. Given the hate in the comments, I'd say let them enjoy the monster they created & learn by experience. "Be careful of unearned wisdom" they say :)
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.
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
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.
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 am trying out nextjs with tailwind, css modules and scss right now in a side project and my biggest problem with tailwind is its copy/pasta and the hard readability. CSS not only styles your HTML but also describes it through classnames and ids which tailwind doesnt. Its way harder to see what which element is without reading the styles. Also conditional styles and css variables dont seem to work well with tailwind without something like clsx in react it gets really painful. And thats another downside. When using tailwind to KIS you have to create all the components for your "atoms" anyways so it doesnt really make a difference if your using css or tailwind because they are very simple. For me where tailwind shines is when you have no clue what you want to do and just try out and experiment with your ui but I wouldnt want to be the guy that has to maintain it. SOC may be hard in the beginning but once you need it youre happy its there. Its like brushing teeth, you may not see the effects instantly but you should still do it anyways.
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.
From watching your video's about htmx i get the impression you have never build a large project with htmx. Meanwhile you have strong words about using htmx in large projects. I have never used htmx in a large project as i'm more at home with React, Vue, etc.. but that does not stop me from wondering if there is a better way of doing things and from reading blogposts about htmx most seem very happy about building or switching a large project in htmx so i'm a bit confused with your takes. Can you make a video where you criticise a blog post that is positive about switching a large project to htmx? I'm interested in your criticism.
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.
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.
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
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.
I didn't scour the comments in your other video, but a cursory look didn't show me any of the vitriol you were talking about other than skill issue. But I'm thinking its a valid comment.
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.
There is a tool for everything. I’m no expert only learning a bit of web development with Django. For me htmx helps to solve the very specific problem of reloading parts of the webpage without reloading the howl page without too much effort. It “requires” having additional functionality to handle request of that particular htmx post in the backend. I can totally see however that more complex themes will create a challenge to keep up with all those snippet sized requests handling in the backend. So I presume there are other challenges when moving to a more client based approach… like having to learn more front-end madness. But well it sounds logical to me that this might be necessary on large projects especially when serving different endpoints for viewing
"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
I remember one of the first videos Primeagen did reviewing htmx where he just said "HMMMM! InTeReStInG!!!!" every five seconds. Thought the dude was fishy ever since. This isn't engineering. It's just content.
it's a good point, SSR caching works very poorly, because you mix template (which is stateless and can be cached) with dynamic data. On the other hand, CSR rebuilds your html each time, so it's also not really cacheable. This is why I like to use native things like <template>. It allows me to cache static data and at the same time just release it with dynamic data when I need to.
"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 agree with your analysis of RU-vid tech content. I also agree that there is time and place for React, HTMX, and Angular. However, most apps that are written with React today, could be very easily be written with HTMX, and the both the developer and user experience would be better. In a way, HTMX breaks group thinking that your shitty app needs the complexity of React. This is the hubris of developers, they don't want to accept that they have been bamboozled by React and that there is a better way for 90% of their React apps.
I genuinely came to this video looking for a detailed critique of htmx, you know a fair critique which one would use if they were evaluating approaches to their next project but then it became a break down of how youtube videos work in general. Anyway getting to the end there are few statements about it being naive and that it doesn't scale but no level 2 or level 3 analysis or reasoning as to why it be just naive or why naive is bad ( or good ). So I am left to conclude that was not the primary purpose of the video, so I'll check out the other htmx videos because I assume good faith. So seee you guys in the comment sections :)
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 RU-vid - 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: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-KABh8CwpSM4.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.
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!
I hope nobody actually thinks server side rendering is rendering in the graphics sense. seems like a silly point to bring up but IDK, maybe some people actually misunderstand that
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
