Indeed, react.js / next.js apps and friends may be large - on first load. After that initial load, you've got PWA WebWorkers caching 100% of the UI. It's effectively as if the app was natively installed on your device. Interactions between first load and the time the user leaves the app account for 99% of bandwidth. And if you can serve that from localStorage instead of an over-the-internet call, that just means much lower egress costs for you, and great UX for your clients. Once your app reaches a certain size and you need to focus on optimizing egress costs and reactivity, you'll get a very clear understanding of why pure HTML data transfers for every single call that just needs to re-render a portion of your UI is a bad idea.

Patrick told me it's scheduled in about 3 weeks. You can follow www.youtube.com/@acquiredotcom

Here's a link to the full interview: kzbin.info/www/bejne/aHKWpHl_fb2HhrM And here's how I built the thing in 30 days: kzbin.info/www/bejne/o5_Gpml9hq6Vqqs

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

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