Hacker News Reader

Author here.

> First of all, what is load time? Load time is when server is generating HTML for request. I should have been more precise.

> Most server side templating engines are compiled, rarely string concatenated and even if that was true, how is that different on the client side? If JavaScript code dynamically creates HTML markup then it also (at some level) stitches string together or does it not

Templating languages generate string that is returned through an endpoint. Just because it is string interpolation doesn't mean it cannot have loops.

Also, by using the phrase "string interpolation" I am actually pointing out the discrepancy between the generator and the generated.

> Huge news announcements! The client side code has to "PICK UP" the response which the server sends to the client! OMG!!! Thank god in a SPA the client code doesn't have to "pick up" server side generated objects, right? (NOT)

It is not response, you have to give unique id's or smart class names and then find those elements using document.getElementById and attach to it. Having a SPA helps reduce the number of named things.

> OMFG. client-server communication is not a paradigm for static documents. PDF is static documents.

It's not a paradigm, but client asking server for a response is more suited for documents when you are returning HTML.

> you have to give unique id's or smart class names and then find those elements using document.getElementById and attach to it. Having a SPA helps reduce the number of named things.

Agreed. It's my biggest gripe with traditional server-side rendered apps versus SPAs.

I don't really get the issue with that. For heavily interactive stuff, sure, you might want to use an SPA and all that this entails. But that's something almost everyone here seems to agree on.

But for almost everything less than that, and that probably covers the majority of use cases, you'll have a few dynamic elements on the page, and it's just a matter of ReactDOM.render() + document.getElementById() for the handful of those.

> If JavaScript code dynamically creates HTML markup then it also (at some level) stitches string together or does it not?

well most spa's building the dom directly, so actually it is really a little bit different.

but yeah, I would prefer c# razor pages over any spa and I actually coded a lot with angular. however I wouldn't say that I will never touch spa stuff, but I wouldn't go full spa anymore, more like add widgets with vuejs and reactjs where it matters.

No offense, but it sounds like you are not a native English speaker and had difficulty interpreting the article. It's not very clearly written, but it's not as incomprehensible as you make it out to be.

I'm a native English speaker and most of the criticisms above are valid.

That's true that I'm not a native English speaker but I still think that the whole article is extremely confusing. For example the author mentions multiple times AJAX in connection with the downsides of a MPA, but AJAX is a technology used for updating a page without a page refresh, so really more inline with a SPA rather than a MPA. Things like this make this article very confusing.

I am still not clear if the intention was to criticise:

1. The original article which was referred at the top

2. Criticise server side templating engines (but he didn't explain how a templating engine is different on the client)

3. MPA in general

4. AJAX (mentioned several times in connection with server side templating)

5. Anything which is not component based (since this is the final point in his conclusion)

6. A combination of those

Which one was it according to your understanding (genuine question)?