Yes the Isomorphic buzz has become more predominant. In addition, the collapse of server side MVC architecture was hastened by client side frameworks like React and Angular. Now we are seeing a resurgence in server side rendering which the .NET stack has been doing for over 20 years. This makes me think of the commercial featuring the song Round and Round. Good architecture never dies it just continually improves.
Typescript and .NET backend
In considering Isomorphic architecture, Typescript and C# are so similar that there is almost no difference other than learning the libraries. However, the WebAPI portion of .NET is lean and mean, easy to learn with a plenty of Good documentation and huge Stack Overflow community.
As for server side MVC, yes it is a stateless protocol but that doesn't mean state is not a part of the equation. A concept known as strong type binding allows any state to be easily 'synced' between server and client on each request cycle without any baggage other than the json data inbound submission. Client side state, still a major client side concern has enough horsepower these day to keep track of everything it needs.
An interesting thing happened when ASP.NET Core 3.2, they changed the default set up to favor WebAPI over MVC. MVC is still supported, but there never was that much difference (other than the controller) between the two. I believe this is a hint, that Cloud integration is more important these days and SOA is still king.
I've haven't had enough courage to take the JavaScript SSR plunge even though true Isomorphism is really great. Then again I have to laugh a bit because SSR was around in .NET for 20 years, and now the JavaScript community is discovering it's niceties.
ASP.NET was where I spent my first 6 years as a professional web developer (2005-2011). It felt natural at first because I was big into C# and the Microsoft stack in general since the late 90s. However, it left a very negative effect on how I view this stuff, so I'm glad to hear that things have improved. I spent years trying to keep that in the rearview so to speak. Part of why I worked hard to try to prove client-side alone could outperform SSR. I wrote arguably the fastest client JS framework and worked on figuring out best patterns here.
Part of the problem was the culture around it at the time. We were writing C# code to basically avoid writing JavaScript, not because it was the best thing to be doing. I spent the last 3 years of that job doing mostly JavaScript progressive enhancement on server-rendered pages. Partially because other devs didn't want to touch it like it was dirty. I used it as an opportunity to get up to date with JavaScript ecosystem which helped immensely in the following decade.
At least at the time the server state solutions involved a lot of data serialization going back and forth and brought this immense wait. I understand Hotwire isn't .NET UpdatePanels etc... but even the approaches to partial updates were very involved. I have to imagine things are much better now a dozen or so years later.
Although I do understand the dilemma. There is another path other than JS isomorphism which is WASM which could achieve similar things. And it is awesome that people are working on it. There just is monumental work to make that truly comparable. Both sides of the equation have tradeoffs and once you cross over you need to be concerned with a whole new number of considerations. This makes truly hybrid solutions difficult and where some of my initial skepticism around React Server Components come from. The obstacles on the JavaScript side seem mostly conceptual/architectural whereas the obstacles on the WASM side initially are implementation. Missing capability, concerns around size, performance of implementation. The former has the ability of the whole JavaScript community to look and work on solutions, where the latter puts a lot of onus on the browser vendors and each language vendor. It will get there, but if the experience with things like Web Components are any indicator it will probably take some time.
In terms of taking the plunge in JavaScript. I'd probably wait still. The prospect still terrifies me a bit the more I understand how the "current" solutions work. We are changing that rapidly right now, but with very few exceptions most JavaScript frameworks are only adequate here. I think if someone with deep .NET knowledge or Rails came into the JavaScript SSR (not class templated MVC express etc..) they'd be like what is going on? It's not like the problem isn't complex from either side of it, it's just we are moving out of the mechanical stage into presenting smooth solutions. Things aren't as well packaged up outside of MetaFrameworks which until recently have been 2nd class citizens. But in the next 12 months I expect this conversation to go completely differently.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Love your in-depth articles Ryan.
Yes the Isomorphic buzz has become more predominant. In addition, the collapse of server side MVC architecture was hastened by client side frameworks like React and Angular. Now we are seeing a resurgence in server side rendering which the .NET stack has been doing for over 20 years. This makes me think of the commercial featuring the song Round and Round. Good architecture never dies it just continually improves.
Typescript and .NET backend
In considering Isomorphic architecture, Typescript and C# are so similar that there is almost no difference other than learning the libraries. However, the WebAPI portion of .NET is lean and mean, easy to learn with a plenty of Good documentation and huge Stack Overflow community.
As for server side MVC, yes it is a stateless protocol but that doesn't mean state is not a part of the equation. A concept known as strong type binding allows any state to be easily 'synced' between server and client on each request cycle without any baggage other than the json data inbound submission. Client side state, still a major client side concern has enough horsepower these day to keep track of everything it needs.
An interesting thing happened when ASP.NET Core 3.2, they changed the default set up to favor WebAPI over MVC. MVC is still supported, but there never was that much difference (other than the controller) between the two. I believe this is a hint, that Cloud integration is more important these days and SOA is still king.
I've haven't had enough courage to take the JavaScript SSR plunge even though true Isomorphism is really great. Then again I have to laugh a bit because SSR was around in .NET for 20 years, and now the JavaScript community is discovering it's niceties.
What's next? WASM?
ASP.NET was where I spent my first 6 years as a professional web developer (2005-2011). It felt natural at first because I was big into C# and the Microsoft stack in general since the late 90s. However, it left a very negative effect on how I view this stuff, so I'm glad to hear that things have improved. I spent years trying to keep that in the rearview so to speak. Part of why I worked hard to try to prove client-side alone could outperform SSR. I wrote arguably the fastest client JS framework and worked on figuring out best patterns here.
Part of the problem was the culture around it at the time. We were writing C# code to basically avoid writing JavaScript, not because it was the best thing to be doing. I spent the last 3 years of that job doing mostly JavaScript progressive enhancement on server-rendered pages. Partially because other devs didn't want to touch it like it was dirty. I used it as an opportunity to get up to date with JavaScript ecosystem which helped immensely in the following decade.
At least at the time the server state solutions involved a lot of data serialization going back and forth and brought this immense wait. I understand Hotwire isn't .NET UpdatePanels etc... but even the approaches to partial updates were very involved. I have to imagine things are much better now a dozen or so years later.
Although I do understand the dilemma. There is another path other than JS isomorphism which is WASM which could achieve similar things. And it is awesome that people are working on it. There just is monumental work to make that truly comparable. Both sides of the equation have tradeoffs and once you cross over you need to be concerned with a whole new number of considerations. This makes truly hybrid solutions difficult and where some of my initial skepticism around React Server Components come from. The obstacles on the JavaScript side seem mostly conceptual/architectural whereas the obstacles on the WASM side initially are implementation. Missing capability, concerns around size, performance of implementation. The former has the ability of the whole JavaScript community to look and work on solutions, where the latter puts a lot of onus on the browser vendors and each language vendor. It will get there, but if the experience with things like Web Components are any indicator it will probably take some time.
In terms of taking the plunge in JavaScript. I'd probably wait still. The prospect still terrifies me a bit the more I understand how the "current" solutions work. We are changing that rapidly right now, but with very few exceptions most JavaScript frameworks are only adequate here. I think if someone with deep .NET knowledge or Rails came into the JavaScript SSR (not class templated MVC express etc..) they'd be like what is going on? It's not like the problem isn't complex from either side of it, it's just we are moving out of the mechanical stage into presenting smooth solutions. Things aren't as well packaged up outside of MetaFrameworks which until recently have been 2nd class citizens. But in the next 12 months I expect this conversation to go completely differently.