A quick talk about content churning and groupthink around my recent video on HTMX and the reaction it got from @ThePrimeagen HTMX apology: • HTMX apology HTMX apology reaction: • HTMX Apology
Applied some thinking on my own, as you recommended. I do acknowledge that crowd mentality is brutal, you stop being a human, and you become a target. That sucks. That said, it seems you tried to rationalize the situation too much and in the process, you insinuated that Primeagen (or however you spell this nickname) has a skill issue on his own. Find this ironic. Then there is a SSR part and you present the most "well ackchyually" stance possible. Nobody ever stated that the client is not rendering when you use SSR. The key difference is the availability of data needed for rendering, which means you don't have to fetch additional information to construct DOM and it's constructed based on HTML. Historically all web pages were static pages or generated on the server, then people started to mess around with fetching data from a browser level, it was a shift in how you approach frontend and that's why people feel like it's an important distinction. Of course JS community had to put their spin on the idea and here we are. It was never about showing pixels and literally nobody says that.
It's especially funny to see that a good part of his argument is "tech youtubers/influencers have skill issues because they stopped working, I have 15 years of experience" but it completely ignores that Primeagen also has those 15 years of experience, and at the time of that video he was working for Netflix. Making a case against RU-vidrs in a RU-vid video is pretty ironic too. From a surface level perspective, they are both RU-vidrs with similar levels of experience. Which makes this video... RU-vid drama. Oh well, he won, I engaged with it now.
I don't agree with all your takes but it is good to have an opposing voice with a different perspective than the status quo on the platform. Keep it up!
Thanks for putting the SSR misconception into words, wish this was documented better. Went through a bit of trouble grasping the concept because the terms' oxymoronic nature. It got to the point where the word 'render' lost all meaning for me and I had to look up what it actually meant in a web dev context.
SSR is a buzzword term - easy to remember, but incorrect. Rendering is always done client-side. What SSRs do is "HTML over RPC". Sending HTML chunks as API responses over endpoints that resemble more Remote Procedure Call than any other architecture (rest, soap etc.) So it should simply be called "HTML/RPC". It's still short (enough), and at least it actually means what it says it means.
Great video! Though I've worked with FAANG-sized React codebase and I don't agree that it does scale well. Quite the opposite. Unmanageable complexity (but might be skill issue, don't know). But I don't think that HTMX would scale to that size too, probably even worse. For small apps? HTMX is much better than React. For large apps? Neither.
Someone at work claimed "there's a revolution happening" when talking about HTMX :D Glad to hear you clear arguments and thanks for sharing your thoughts. Simplicity is misunderstood to be lazy (not being inclined to adopt the latest hype), but simplicity in fact requires deeper wisdom.
It's awesome when people get excited about stuff and it is certainly not my intention to rain on anyone's parade. There is a huge difference between a naive implementation and a simple implementation, though - and I wanted to clear that out as much as I could without becoming boring. HTMX is a tool. A nice tool, too. But it is certainly our duty as Engineers to analyze all edge cases and trade-offs when considering any tool, and the opinion of any influencer should not allowed to interfere with that process.
The main reason why I think React does not scale well is because components hold data, synchronization of the data and behaviour attached to the data inside of the components themselves. It makes it extremely difficult to maintain such architecture. It's more scalable to control components outside of components, which allows to have more control of multiple components in different parts of the application and don't rely on esoteric state management libs.
Nice video. I thought the point of htmx is that not everything needs to scale. React was built for scale, both in the number of users, and the number of developers. However, many things will never have many developers or users. The corporate world is full of internal webapps with very few developers, less than a 100k users, and very small api surfaces. For these cases, what is wrong with the naive approach?
"For these cases, what is wrong with the naive approach?" - there's nothing wrong with it. That's the entire point I'm trying to make, but I sometimes feel that some people prefer to only hear the first part of my argument. They stop at "please reconsider using htmx", and don't listen to the second part, which is "when you're building for scale - for the following reasons". Thank you for your very thoughtful comment!
Your last statement is important. It reminds me of when the MSM instructed people in the UK to clap for the nurses of the NHS during the corona-panic, and they obeyed happily.
It's part of human nature to yearn for that feeling of belonging, I guess. It's a flaw we all have to an extent that can be abused by "leaders" - whether they're politicians, bosses or #influencers.
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.
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.
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.
Everything you said is true except about SSR. While you are technically correct about rendering always being "client side" you miss the face that SSR renders 2-10x faster (until the user sees something) compared to a SPA. So SSR does in fact carry a huge benefit over a SPA.
I've answered this already but it's my pleasure to answer you too. Preparing an HTML block is actually extremely cheap. Ridiculously cheap. "Barely an inconvenience", a youtuber would say. It's only after you have prepared that HTML string (or virtual object) and you change the DOM (with .innerHTML or other mutators), that the browser takes over and begins rendering. So that CSS parsing, re-layout, re-flow, re-render process is the one that's extremely expensive for the browser. Here's a visualization: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-dndeRnzkJDU.html That's the reason React uses a virtual dom. Because string and object manipulation are extremely (insanely) fast. And you want to propagate changes to the actual DOM as rarely as possible, because that's when the CPU goes to 100%. Now, there's a common counter-argument here: "yes, but we're using 10 different API calls to generate the HTML in javascript; with htmx, we would only make 1 call". That is an architectural issue. If you're starting the project from scratch (as in, you're rebuilding the thing with htmx), why not refactor your API? If you can do it in 1 API call with htmx, there's nothing stopping you from returning JSON instead of HTML in your previously bloated application and simplify things. SSR is incomplete if you consider all data points - indeed, there are AJAX calls (in essence, talking to a DB), but you also have websockets, user gestures, PWA webworkers with pure access to the filesystem and more, devices such as camera, microphone and more etc. Modern web applications no longer rely solely on data from AJAX calls. There's no performance gain from using an SSR over local HTML block building because rendering is the expensive part. For most repetitive user gestures such as incrementing a counter really fast, I would argue that SSR is considerably slower due to networking bottlenecks. And for other inputs such as microphone and friends, SSR is simply not a option. Here's an example of that: markjivko.com/tutorials/B3wWIsNHPk4/ Finally - YES. First load. That first load is an issues with modern SSGs. It's true. But it's also true that there are many techniques for lazy loading and tree shaking and opportunistic caching to make that first load experience excellent for your end-users. But what happens after that first load is where a PWA-cached SSG shines over an SSR - you simply can't beat 0ms response times and offline support.
@@markjivko I don't disagree with you about anything in particular, but you're kind of missing my point still - returning the HTML in the initial response and then hydrating it (which should not result in any real DOM changes at all except event handlers) is MUCH faster than serving an empty shell (SPA approach) then load JS, parse JS, run js, write the changes to DOM and THEN user sees the page.
@@markjivko I think this statement is, at best, incomplete: "CSS parsing, re-layout, re-flow, re-render process is the one that's extremely expensive for the browser" CSS parsing, re-layout, re-flow and re-render can be slow if you are using a CSS-in-JS library which inserts style rules when the JS library you are using (most likely React) is rendering the components. There's even a discussion on Github started by Sebastian Markbage on this topic. Generally, JS is by far the most expensive resource, both in terms of data transfer and the CPU usage and it's not hard to understand why: browsers use native C++ code to render the HTML and CSS, but they need to parse the JS through a VM.
That might be true - I honestly don't know. I have been writing code since Internet Explorer was king and "SSR" was absolutely the only way to do things - poorly. And server costs were huge. I've been spoiled recently with PWA web caching of SSG hosted for free by Cloudflare (with DDoS protection and free SSL included - 'member when SSL alone used to cost $100/year?) - all hydrated with tiny calls to a RESTful API. Not to mention access to camera, microphone, full local storage and many, many more wonderful things like webgl and friends. I'm not sure why one would avoid discovering all that - "just cause ajax on click is good enough".
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.
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
