4 ms·

It's not about SPA's. It's about modernizing your development workflow and making it more accessible to a variety of devs -- not just .NET (Read: C#) developers

It's not about SPA's. It's about modernizing your development workflow and making it more accessible to a variety of devs -- not just .NET (Read: C#) developers. If you're still using Razorscript then you're probably causing more work for yourself than you realize, both from a resourcing standpoint and a functional one.

muglug 8y ago
Counterpoint: you’re probably not causing more work. Maybe your app is that simple, and maybe moving a lot of it to JS/AJAX would make it more complicated and less accessible to the end user.
- kadendogthing 8y ago
  Where does AJAX come into play with anything I said?
GordonS 8y ago
I don't see how server-side rendering is causing more work? It's less work, since you don't have a dependency on a front-end framework. Server-side rendering is my default go-to - IMO, this works very well for the majority of needs. I only bust out a front-end framework if the app is sufficiently complex that it can justify the extra work.
- 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 ago
        So, 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
pjmlp 8y ago
If by modern you mean a node_modules folder with several thousand packages, then I rather stay with server side templates and vanilajs.
- kadendogthing 8y ago
  No one said anything about moving away from server side templates. I don't know why .NET developers get so confused over this subject. By modern I mean using a very popular language in a domain that specifically has that language as its primary and first most choice in that domain for every single aspect of that domain's development. From the pool of developers you can choose from, to where those tools and applications can be run, to how you construct your web applications. On a new project that doesn't have historical roots in using the Razor view engine, again, what is Razorscript bringing to the table that other server side templating languages/frameworks are not? Why would you willingly choose to use a view engine and templating language that costs you in functionality, reduces the flexibility of your views, reduces the amount of programmers that can work with it, and causes really really bad start up times/cache miss hits (lol @ precompiling your views, so you can restart your app pool for tiny little changes)? You don't need an SPA to move away from Razor. It's quite the opposite: you better have a damn good reason to continue to use the Razor view engine.

muglug 8y ago

Counterpoint: you’re probably not causing more work. Maybe your app is that simple, and maybe moving a lot of it to JS/AJAX would make it more complicated and less accessible to the end user.

kadendogthing 8y ago
Where does AJAX come into play with anything I said?

GordonS 8y ago

I don't see how server-side rendering is causing more work? It's less work, since you don't have a dependency on a front-end framework. Server-side rendering is my default go-to - IMO, this works very well for the majority of needs. I only bust out a front-end framework if the app is sufficiently complex that it can justify the extra work.

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 ago
      So, 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

pjmlp 8y ago

If by modern you mean a node_modules folder with several thousand packages, then I rather stay with server side templates and vanilajs.

kadendogthing 8y ago
No one said anything about moving away from server side templates. I don't know why .NET developers get so confused over this subject. By modern I mean using a very popular language in a domain that specifically has that language as its primary and first most choice in that domain for every single aspect of that domain's development. From the pool of developers you can choose from, to where those tools and applications can be run, to how you construct your web applications. On a new project that doesn't have historical roots in using the Razor view engine, again, what is Razorscript bringing to the table that other server side templating languages/frameworks are not? Why would you willingly choose to use a view engine and templating language that costs you in functionality, reduces the flexibility of your views, reduces the amount of programmers that can work with it, and causes really really bad start up times/cache miss hits (lol @ precompiling your views, so you can restart your app pool for tiny little changes)? You don't need an SPA to move away from Razor. It's quite the opposite: you better have a damn good reason to continue to use the Razor view engine.