This repository was archived by the owner on Apr 8, 2020. It is now read-only.
This repository was archived by the owner on Apr 8, 2020. It is now read-only.
Create a C# Based SPA #963
Closed
Description
The Problem:
- SPAs are great in theory however, SPAs are massively complex to setup and maintain with MANY moving parts and endless dependencies.
- To have SEO you need server side pre-render which requires nodejs be executed through .NET which is just a cludge and slow and just silly.
- Developers have to know javascript/typescript to be able to develop for web.
- Because developers have to know javascript they naturally use javascript for everything and as a result they move away from C# because it's easier to write everything in JavaScript (even if badly, friends don't let friends develop server side with node...) because you can have a single developer in a small organization do everything or even 2 javascript developers instead of having to have a C# guy, a Xamarin guy that knows C# and a web guy to build websites or worse.
- As a result of this lowest common demoninator .NET is at servere risk of losing relivency because if you're forced to use nodejs anyhow, why bother using .NET at all for your SPA (and hopefully just use it for server side but could likely mean an end to server side as well)
- As a result of this momentum that is underway right now Microsoft also loses server business and even Database business while weakening Azure revenue in the long run because the value proposition for C# developers with all of the integration becomes less and less and Azure becomes an also ran like everyone else and has to compete solely on price.
The proposed solution:
- At BUILD this year @shanselman demoed MVC Pages that simplifies the pipeline and puts the controller back where it should belong in the nested .cs file to the razor view. This was an excellent first step!
- All SPAs have 2 phases: 1. Load the HTML and load the base data for the display. 2. Allow the user interaction with that display.
- The load of base data is typically done in an init function and that kicks off the rest. This is similar to the controller's method. Then the interaction is done typically in events much like events were passed back to the server side in ASP.NET Original.
- By making MVC Pages also compile to JavaScript and providing a routing engine based on the MVC.net routes MVC Pages could be used to generate a SPA that did server side rendering for setup and display and then handed off to the compiled javascript for the rest. And when the first page is rendered this way, if the device has javascript (i.e. isn't a bot) then all subsequent pages could be loaded using javascript loads just like a normal SPA and even the setup init functions could be executed on the client side.
- Typically this means that HttpClient would need to compile to javascript xhr calls and we would need basic plumbing for routing, page changes and eventing.
- We would also need the ability to take typescript definitions and use them strongly typed in C# that would ultimately get compiled down to javascript.
- Controls like Kendo Angular would need to be interpreted from their javascript for the rendering system to generate the input controls for server side pre-render as necessary. This would be done server side on compile of the SPA and ultimately by convincing the control manufacturers to create native controls that worked very much like angular controls in markup in html but were compatible with the C# backend. I'd suggest working with Aurelia people since they work for Microsoft to get this going.
- Provide a version that executes a compiled .NET core library for native on Android and iOS later similar to how ionic and others do with phonegap and nodejs.
- Finally put a ton of Macs in the cloud for compiling and distributing Xamarin apps to the iOS store and give it away free to any MSDN subscriber. By doing so the developer won't need a Mac and can use only a PC. It is this singular reason that MS lost developers because if you have to buy a mac anyhow, why use windows when your windows stuff is in the browser and you can do that on the mac? By hiding the mac and selling it as a service you eliminate that argument and the problem which makes the above viable as a business case in development shops.
- Razor becomes the syntax of choice in the HTML and is consistent on server and client side which is a major plus.
Why?
- A C# developer can now always be a C# developer. With the combination of XAML Standard and .NET Standard 2 and upcoming improvements to Xamarin along these lines a developer can confidently know XAML, HTML/CSS and C# and that's in and get a superior development environment with far less setup and maintenance of the mess that most SPAs are today. This eliminates the cost gaps for business.
- Current C# developers can be more productive very quickly than their javascript peers because "it just works" like in the good old days of vb 6 versus every other development tool for enterprise. The result will be new projects will move to this to save money and MS will recapture the developer market.
- By compiling C# to javascript using a consistent methodology of MVC.net and giving all of the benefits of a SPA with all of the benefits of mvc.net you make mvc.net relevant again to serve web pages.
- You make all of those developers that haven't yet built a SPA based application able to do so with almost 0 new learning. The path is MUCH shorter.
- You can make those new MVC.spa applications easily compilable to mobile platforms and even the Windows Store and provide a true option for write once run anywhere that starts in the browser just like ionic etc. promise (even if they don't deliver)
- You get rid of the need for a mac which gets rid of the need to develop on a mac which means people can come back to Windows development.
- The overhead of building this should be pretty low given the expertise in the typescript group with javascript compilation.
- With server side detection of the browser in question exactly the right code can be provided to the client with exactly the right number of shims and compatibility stuff and absolutely nothing else so this will load MUCH faster than angular etc. that have to do it after the fact. I'd bet that a .NET SPA would be 1/3rd the size of Angular or similar and run faster too.
- You could add C# compiled script execution to Edge and make those apps run way faster than javascript as a result of full typing etc. while making the package even smaller giving companies a reason to use Edge instead of Chrome and creating an artificial advantage. If the WebApplication spec ever gets off the ground for executing native code then this is ideally positioned.
- This is a half-way step to bridge.net because it still uses html/css instead of trying to make XAML work in a browser compiled down which means that you won't be in such a walled garden and the compilation of this will be real html, css and javascript that could be taken and run on it's own if necessary.
- No more NODEJS! It's gone and as a result your site is vastly faster running server side functionality in .net core than running nodejs in .net core or directly without .net core.
This would put MS head to head with everyone and give developers that adopted it a major competitive advantage at the same time, and drive developers back to MS in a big way if done right. You don't need Native support day one but it needs to be on the road map and the rest creates a simple SPA that uses standard things like bootstrap and kendo and allows dev in C# and only C# with HTML as the markup. That's HUGE.
Metadata
Metadata
Assignees
Labels
No labels