4 ms·
>I don't see how server-side rendering is causing more work? That's not what was stated at all. Razorscript specifically only works in a certain environment. O
by kadendogthing 8y ago
>I don't see how server-side rendering is causing more work?
That's not what was stated at all. Razorscript specifically only works in a certain environment. Other templating langues have the ability to be rendered server side and client side, have a wider development audience, and work on a variety of environments.
>I only bust out a front-end framework if the app is sufficiently complex that it can justify the extra work.
That's nice that you have such constraints, but it doesn't negate the fact that when the time comes you now have to work with two different systems instead of just using one. This by itself means you'll have to write more code, and finagle your data to work with two different frameworks and paradigms, AND you'll inherently have a split team.
It's pointless to use Razorscript when you gain nothing from it and it actually ends up hurting your code and your project.
- GordonS 8y ago> That's not what was stated at all. Razorscript specifically only works in a certain environment Apologies, I mis-read the comment, maybe I transposed parts of it with another, I don't know, but I thought it was an attack on server-side rendering. > That's nice that you have such constraints, but it doesn't negate the fact that when the time comes you now have to work with two different systems instead of just using one. YAGNI - the time invariably never does come.
- kadendogthing 8y ago>YAGNI - the time invariably never does come. If you are not dealing with a sufficiently complex app to the point where you don't need to use JS in a web application, then why are you using ASP.NET in the first place? Kind of renders this whole discussion moot when the entire platform isn't a fit for the application.
- GordonS 8y agoSo, I didn't say I didn't need to use JS - what I'm saying is that I often don't need to expose all data as a client-consumable API and render data using JS. > why are you using ASP.NET in the first place Because I need to do normal shit with backend systems - databases, message queues, APIs, ERP systems and the like.
- kadendogthing 8y ago> what I'm saying is that I often don't need to expose all data as a client-consumable API and render data using JS You don't need to. But what if you could just go ahead and use a proven, extremely popular templating language/engine anyways, just in case. At no cost. >databases, message queues, APIs, ERP systems and the like. And the web application exposing this data is already not a borderline SPA? I'm surprised.
- GordonS 8y ago> But what if you could just go ahead and use a proven, extremely popular templating language/engine anyways, just in case. At no cost. I don't see added complexity as no cost, and I don't need to add a templating engine when Razor works very well. > And the web application exposing this data is already not a borderline SPA? I'm surprised. See, I look at this a completely different way - I wouldn't want clients able to communicate directly with all these components. In particular, I really wouldn't want web clients communicating directly with our (multiple) ERP systems (and neither would our licensing or security people) - it's a lot simpler (and cheaper) to centralise access at the server-side. I can tell we're not going to agree on this, and thats fine, I like that you're passionate about it, and bid you adieu :)
- kadendogthing 8y ago>I don't see added complexity as no cost, Where is the added complexity? >and I don't need to add a templating engine when Razor works very well. I mean, objectively it doesn't work very well. > In particular, I really wouldn't want web clients communicating directly with our (multiple) ERP systems I don't see where I stated they needed to directly communicate with the ERP systems directly. There's still complex state that's being communicated to the client. If you're handling the visual aspect of this purely on the server, that pretty needless and costly. Costly to render, costly to maintain.