4 ms·

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

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

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.