4 ms·

I admit I didn't finish reading this blog article because the author completely lost me when saying weird things like: - Templating language is basically strin

I admit I didn't finish reading this blog article because the author completely lost me when saying weird things like: - Templating language is basically string interpolation which builds the presentational layer at load time. First of all, what is load time? There is compile time and runtime and then there is runtime on the server and runtime on the client. Load time is just fuzzy language and has no meaning IMHO. Also, what the blimming heck does he mean by string interpolation? 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? > Client side code is developed separately and has to “pick up” the target elements after it is loaded. 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) > Templating languages are basically smart string interpolators and have quirky syntax. Quirky syntax? First of all, pick an engine which isn't quirky if that's your problem, and secondly EVERY templating engine, regardless of server/client side has a "quirky syntax" if you wish. It's not like front end development is done without a framework or library which gives you more power than just rudimental HTML markup. > One language (server side) is generating markup for a different language which takes over on the client. One language generates output of another language is his problem? So I guess he doesn't use anything but pure JavaScript, because anything on top of pure JavaScript is another language generating JavaScript, right? Also the "server somehow takes over on the client"? What does that even mean, seriously? > If AJAX is used to dynamically alter the state of our app by means of adding, ... How did he transition from C# + Razor to AJAX. Did I miss something? Razor is not AJAX... > Taking paradigms that work well for static documents and using them for building software is simply inadequate. OMFG. client-server communication is not a paradigm for static documents. PDF is static documents. Honestly... I stop at this point.. I can't read anymore. It's painful.

tpetrina 8y ago
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.
- ngrilly 8y ago
  > 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.
  - mercer 8y ago
    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.
merb 8y ago
> 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.
aardshark 8y ago
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.
- andybak 8y ago
  I'm a native English speaker and most of the criticisms above are valid.
- dustinmoris 8y ago
  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)?

tpetrina 8y ago

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.

ngrilly 8y ago
> 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.
- mercer 8y ago
  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.

merb 8y ago

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

aardshark 8y ago

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.

andybak 8y ago
I'm a native English speaker and most of the criticisms above are valid.
dustinmoris 8y ago
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)?