5 ms·

Neat, but I’m curious to know how many people are using server side templating with dotnet core? I avoid it like the plague these days, using vue/webpack and an

Neat, but I’m curious to know how many people are using server side templating with dotnet core? I avoid it like the plague these days, using vue/webpack and an http api. If there’s actually a lot of razor still out there, I should probably keep up with the latest version of it.

thrower123 8y ago
A lot of times, that's all you need. For quick and dirty internal tools, its a godsend. I'd be happy to use it more, and cut out the whole Gordian Knot of overburdened front-end development.
- caseymarquis 8y ago
  I’m hoping that wasm leads to a unified dotnet stack with fantastic tooling and shared classes for front-end development. Best of both worlds at that point. That said, I resisted getting into the JavaScript front-end ecosystem, but I really like it at this point.
- skinnyarms 8y ago
  I've been doing some experimenting with Gatsby to generate static sites for me, and it's made me realize how much I've missed server-side rendering.
nicoburns 8y ago
I'm a full stack developer, so I'm pretty comfortable with the front end frameworks, but there's definitely still a place for traditional server-rendered apps. They're super fast (HN is a good example!), and dev work is much quicker for basic stuff that doesn't involve too much complex interaction.
iamnothere 8y ago
Blazor 1.0 is coming (eventually) which will make client-side Razor templating feasible. It runs C# code in the browser using WebAssembly, with fallback to asm.js for older browsers. Vue is probably the best general-purpose SPA frontend option for .NET right now, in my opinion, but I'm really hoping that Blazor unseats it. Being able to reuse library code in the frontend would be fantastic! I've got a few use cases for this already that would avoid round trips to the server or duplicating/maintaining logic in different languages.
- caseymarquis 8y ago
  That sounds very exciting! I'll be keeping an eye on that for sure!
rocky1138 8y ago
They have the benefit of working with older browsers, people who don't use JavaScript, and wget/curl. They are also faster to render on the client.
pjmlp 8y ago
Lots of us. Very few websites are actually worthwhile doing as SPA, and guess what they are actually fast to deliver static content instead of JS frameworks.
- kadendogthing 8y ago
  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.
kadendogthing 8y ago
I don't know why you're being downvoted. Razorscript is functionally useless in web development. It's only applicable to web pages that are completely rendered server side, on an ASP.NET server (basically every other templating language works both on the server and the client), and has a barrier that prevents well rounded, experienced web developers from contributing to a project -- not everyone knows or will even care to learn C#, nor will they have an environment that allow them to run visual studio, or any kind of IIS server. If you're using Razorscript still you are doing yourself and your company a large disservice. There isn't anything Razorscript brings to the table that makes it a worthwhile option. And even worse, if you are using Razorscript, you will have to write more code to specifically be in harmony with any other kind of front end framework. And please I beg of anyone replying to these messages to not get confused and assume that pages not written in Razorscript are somehow specifically trying to be an SPA. They are not. The clear difference between something like Razorscript and say using server rendered react, is that the former will only ever be rendered on the server, and the latter can be rendered on both the server and the client.

thrower123 8y ago

A lot of times, that's all you need. For quick and dirty internal tools, its a godsend. I'd be happy to use it more, and cut out the whole Gordian Knot of overburdened front-end development.

caseymarquis 8y ago
I’m hoping that wasm leads to a unified dotnet stack with fantastic tooling and shared classes for front-end development. Best of both worlds at that point. That said, I resisted getting into the JavaScript front-end ecosystem, but I really like it at this point.
skinnyarms 8y ago
I've been doing some experimenting with Gatsby to generate static sites for me, and it's made me realize how much I've missed server-side rendering.

nicoburns 8y ago

I'm a full stack developer, so I'm pretty comfortable with the front end frameworks, but there's definitely still a place for traditional server-rendered apps. They're super fast (HN is a good example!), and dev work is much quicker for basic stuff that doesn't involve too much complex interaction.

iamnothere 8y ago

Blazor 1.0 is coming (eventually) which will make client-side Razor templating feasible. It runs C# code in the browser using WebAssembly, with fallback to asm.js for older browsers. Vue is probably the best general-purpose SPA frontend option for .NET right now, in my opinion, but I'm really hoping that Blazor unseats it. Being able to reuse library code in the frontend would be fantastic! I've got a few use cases for this already that would avoid round trips to the server or duplicating/maintaining logic in different languages.

caseymarquis 8y ago
That sounds very exciting! I'll be keeping an eye on that for sure!

rocky1138 8y ago

They have the benefit of working with older browsers, people who don't use JavaScript, and wget/curl. They are also faster to render on the client.

pjmlp 8y ago

Lots of us. Very few websites are actually worthwhile doing as SPA, and guess what they are actually fast to deliver static content instead of JS frameworks.

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

kadendogthing 8y ago

I don't know why you're being downvoted. Razorscript is functionally useless in web development. It's only applicable to web pages that are completely rendered server side, on an ASP.NET server (basically every other templating language works both on the server and the client), and has a barrier that prevents well rounded, experienced web developers from contributing to a project -- not everyone knows or will even care to learn C#, nor will they have an environment that allow them to run visual studio, or any kind of IIS server. If you're using Razorscript still you are doing yourself and your company a large disservice. There isn't anything Razorscript brings to the table that makes it a worthwhile option. And even worse, if you are using Razorscript, you will have to write more code to specifically be in harmony with any other kind of front end framework. And please I beg of anyone replying to these messages to not get confused and assume that pages not written in Razorscript are somehow specifically trying to be an SPA. They are not. The clear difference between something like Razorscript and say using server rendered react, is that the former will only ever be rendered on the server, and the latter can be rendered on both the server and the client.