Might you be speaking too broadly? For my part, I lament that we are still locked into JS.

If I'm speaking broadly it's because it's broadly the truth. Sure there are exceptions. And we all know there are drawbacks with JS, I'll be the first to admit it. But the solution to that isn't going back to the same old design patterns we had 10-15 years ago and solved with JS component models. It would be like if we said "there are problems with cars" and the solution was to bring back horses. The reason it looks like such a convenient solution is because it's just regression.

I think current solutions like Sveltekit are basically perfect.

This video response wasn't to say we need a single solution, you're absolutely correct we *should* use the right tool fort he job, and what I'm arguing is that SSR for web applications is *not* the right tool (for all the points covered). If however you don't have a web application and your site is static, then I wouldn't even SSR or SPA is the right tool in that case SSG would be the right tool.

Thank you for you kind words, I really appreciate it and it motivates me to create more stuff!

Very good point here regarding SEO, that is indeed on key legitimate criticism of SPA, there has been some solutions in this area, as you may already be aware there are solutions such as Nuxt and Next which can do isomorphic builds, but that's another rabbit hole!

Thank you I'm glad you liked it! 👍

even with more efficient languages it still doesn't solve the problem (it may buy you a little more headroom but that's it). Inverting the entire things does, because now you're essentially doing distributed computing by offsetting the computation over to *each* client, that means it doesn't matter how many extra clients requests you have your computation becomes (Computation * Zero) which is always zero!

@@watthedoodle I am not a designer or webdev by trait, I run that stuff. On a huge scale. And i do so since 20 years. I had customers, that moved to SPAs, and client side rendering. And guess what: The load difference on the servers where not measurable. But why is this so? Because rendering a HTML Template or crafting JSON from the same data does not have a large computational difference.

@@tbethenerd they're are *not* the same, one is transformation of data representation that is only minor structural changes (see XML -> JSON etc), while rendering full templates, include full on conditional elements based upon expressions all of which is infinitely nested along with loops etc, these are not the same. For simple templates and at small scale the difference will not matter, but the principle can not be avoided, whatever that computational load is *will* be multiplied with every client you add, and by scale I mean the total concurrent RPS.

​@@watthedoodlethis is where you start to go horribly wrong in your thinking Running data through a template to generate HTML is orders of magnitude less work than converting data to json The HTML template expansion can be done using no additional memory allocations. Transforming any data to json requires allocating strings for every element, converting numbers into strings, deallocation after use, etc You could roll out 100 HTML templates in the same number of clock cycles as doing 1 json payload

Thank you! Absolutely agree the JS fatigue is real and I have found Vite to be a breath of real fresh air, and that's the positive direction the ecosystem needs to move towards, I think I may do the next video into vite!

I literally provided the reasons as to why he is wrong, please re-watch carefully. I re-iterated the points throughout the video as well. Almost everyone else has understood the points I raised against Andrew.

Thank you sir for the kind words, I'm happy you liked it!

Freudian slip? Is it "Fanatic" or "Fantastic"? Lol

you don't need to "synchronise" state, http is idempotent. You simply "fetch" the client specific state that you need as and when you need it. All state is localised client side and is specific to each client instance. For you second point, yes while you *could* potentially have that strict segregation and use internal data "APIs", you still haven't the computation tax issue.

@@watthedoodle I will agree to disagree. Firstly, http is not necessarily idempotent, but even in the case that it is, state is not localised on the client side since you still have a database on the server side... when you update the server side database with an idempotent http method (let's say you DELETE a product listing), that change will in many cases, also need to be reflected on the client side, hence the need for synchronisation

@@byrongibby that DELETE request can either succeed or fail. If it fails then no need to update the current client state, if it succeeds then you can safely remove that data point from the client side. In either case navigating between "pages" will automatically load the latest database state anyway. Unless you want 100% seamless realtime state view across all clients in which case you would need to either use WebSockets and push out an the latest data point upon edit/delete/new OR use something like long polling OR server push etc. But this reload will be EXACTLY the same for SSR, the difference being with SSR you would have to refresh the entire page, whereas with SPA you would only re-fetch the changed data set. So actually it still wins out in terms of overhead.

@@watthedoodle I buy the argument that front end frameworks distribute the compute making it a more easily scaled solution, but to the point you just made - if you're using something like HTMX you aren't doing full page reloads. On the question of state, it has been my experience that you have your server side database, but you also have an in-memory database on the client. The DOM/view is updated as the client database changes - that seems to be a solved problem, the issue as I see it is comes from making sure the client side database and the server side database are kept consistent with each other. If you're saying that this is easy for you to do correctly that's fine, but I think a lot of people find it quite challenging.

@@byrongibby why would it be challenging? as long as the database is the SSOT (Single Source Of Truth), then the Client is simply the presentation of that state. The client also makes request's *to* the database in order to request mutations. The data flow is well established here, there is nothing to "synchronise", at least that's how I approach the design and data flow.

Sure I hear what you're saying, however I don't fully accept the "added complexity" part as that was one of the points raised by Andrew and what I'm suggesting is that in actual fact one doesn't even technically need a front end framework and yet still be able to fully do a SPA with ajax that doesn't rely on mashing the data and UI code on the server side. In fact you can watch my earlier video where I pretty much do that using Hono + Deno that has ZERO JavaScript build tooling, dependencies (client side) and zero frameworks, just raw JavaScript etc. Having built many modern production sites, I don't agree with this assessment that it's complex to maintain, are *some* frameworks overly complex? Yes that part I will absolutely agree with (I'm looking at you React!). But we shouldn't tar all frameworks with the same brush as that is unfair and incorrect. I would suggest that using Vite + Vue will be dramatically more productive than doing SSR, I know because I've done *both* commercially multiple times, and I know which one I pick every time and it's *NOT* SSR.

90% of sites you use on daily basis are built with heavy frontends. What ppl was creating decades ago is not relevant anymore

Single page applications are peak web dev.

JQuery or more specifically shitty jQuery has cost the business I work for about $2,000,000 in developer pay fixing bugs over 10 years and it's only 12 unique pages with the home page, product listing, search and product page being the most complex. Some members on my team were tasked with "updating" the existing product page built in 6000 lines of jQuery spaghetti. They had 3 months. It took 9 months until the defect list grew larger than the actual tasks, then 16 months until the project was scrapped and they were both fired. They handballed it to me, I rebuilt the page in 4 months using Angular. It's been live for 9 months without any critical issues after release. Sure you could make a nice enough webpage/site with HTML and jQuery, but I've never actually seen it in the wild. There are no standards for it's use so different developers do whatever they feel like at the time, some use the revealing module pattern if you're lucky, some global objects, most just free functions in a massive file, generally just hacking exponentially to make things work. SetTimeout's everywhere to deal with race conditions, functionality that overwrites other functionality. Events that are never unbound except occasionally you will see `$el.off().on() It's hard to debug so average developers just hack on whatever they need to get a story complete. Modular componentised code that follows single responsibility as much as possible is always going to be the best solution, but more importantly having standardised practices for average developers to follow and documentation they can read is the biggest benefit to modern js frameworks.

@@ivan.jeremic which is why everyone is so unhappy with them and the quality of most apps is terrible / rapidly declining? SPAs are "Peak" in the same way that server-side MVC frameworks were "Peak" 3-Tier. Both are bad ideas that caught on before the industry could actually evaluate the efficacy. By the time anyone realized they were bad ideas, everyone was doing them.

With HTMX, you can relatively easily embed a SPA for a single sub-route. (In my case, elmish). It's actually quite nice for a hybrid website.

At scale and at high RPS it does not scale sorry that's a simple fact. Given that SSR can mean having to re-render the entire page, this includes all the conditional logic and looping structures etc. Perhaps on the smaller scale it's negligible, but it really really isn't when you work at scale. And it turns out if you invert and delegate the computation to the client side that template computation goes to ZERO for the server side, and it's hard to beat zero.

​@@watthedoodleHow many are we talking about here? I need some valid numbers argument. Depending on the interaction it does not need to be fully server-side, it could just be when doing action that is only changing data (yes small js libs can be use for interactivity) and at that point i would argue the lifting is done more on the database side, which is another topic on itself. On the other side, most large application relies on microservices to run their API, this is scalable. But most SSR application mentioned do their scaling the same way using pods, replicas, load-balancing, etc. Why can't we make the same argument? Either way people seem to forgot the DevOps side of things, there no ZERO computation, you are always doing it somewhere, does not REDUCE the amount of computation in any way. The example shown is of course on a small scale where they are in one place, which should not be done on a large scale application (still, how large are we talking). Either way both are complicated, and i agree it should not be simplified.

@@zulfiqrysaadputra Because using client side rendering you wouldn't even **need** to scale the server side, that's entirely the point of CPU delegation.

Right, I choose htmx 😂

Yes I have used Jinja2 as well as many other template engines, front end frameworks also use templates in the form of composable render functions. So with respect your premise here simply doesn't hold.