I think SPAs can be a decent choice for certain classes of applications, but this article seems really weird to me. > Templating languages are basically smart

I think SPAs can be a decent choice for certain classes of applications, but this article seems really weird to me. > Templating languages are basically smart string interpolators and have quirky syntax. Well, yes, templating languages take a string + data and return another string. That's definitely true. What that actually means isn't clear. Especially when the followup "have a quirky syntax" doesn't have a particularly precise meaning (and may not be universally true) and also, the problem remains the same whether you address it on the server or in the client. > We cannot use server side rendering any more — or can we? Let’s write endpoints that return HTML and not JSON. I can't tell if that last part is sarcasm, or attempt to examine a potential avenue, or a complaint that one would have to multiply endpoints in order to return JSON or HTML instead of having a back-end that pays attention to the HTTP Accept header and has capabilities of returning different representations of the same resource. > When to subscribe/unsubscribe from events. Otherwise we will run into memory leaks. This is also hard to decipher -- is he talking about event listeners on replaced portions of a document? > How to name things — when everything is dynamic, naming becomes hard. As the saying goes, naming is one of the two hard problems in software. The browser is itself a dynamic environment with a dynamic primary runtime. There are languages that'll help or hobble you in the browser or on the server but that's orthogonal to whether you're choosing an SPA. There might be a kernel of a worthwhile argument in here about component testing and isolation being more difficult if you're doing it on both the server and the client, but the rest of this seems thinly justified rather than reasonably explored.