Skip to content
This repository was archived by the owner on Apr 8, 2020. It is now read-only.

Create a C# Based SPA #963

Closed
JohnGalt1717 opened this issue May 20, 2017 · 21 comments
Closed

Create a C# Based SPA #963

JohnGalt1717 opened this issue May 20, 2017 · 21 comments

Comments

@JohnGalt1717
Copy link

The Problem:

  1. SPAs are great in theory however, SPAs are massively complex to setup and maintain with MANY moving parts and endless dependencies.
  2. 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.
  3. Developers have to know javascript/typescript to be able to develop for web.
  4. 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.
  5. 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)
  6. 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:

  1. 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!
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. Razor becomes the syntax of choice in the HTML and is consistent on server and client side which is a major plus.

Why?

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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)
  6. 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.
  7. The overhead of building this should be pretty low given the expertise in the typescript group with javascript compilation.
  8. 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.
  9. 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.
  10. 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.
  11. 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.

@JohnGalt1717
Copy link
Author

@SteveSandersonMS @MarkPieszak @shanselman Food for thought. My dev team and several other dev teams I've talked to recently are all fed up with the complexity of Angular and React and are experiencing major declines in team performance as a result of Angular 2 (even more so than Angular 1 was) even after major training efforts etc. because of all of the moving pieces that are constantly breaking or do magic without good documentation etc.

Extending mvc.net to build a full spa in C# is such an elegant solution that I think it would appeal to ALOT of people and the productivity and simplicity gains for a team would be undeniable. It would put MS right back in the game.

@ghost
Copy link

ghost commented May 21, 2017

110% agree @JohnGalt1717 , well said
The dream for me would be writing C#/XAML, essentially WPF in the browser
I really hope Microsoft are listening! There are lots of people asking for similar

We're a MS shop that writes in house line of business apps, but like most don't have an Amazon sized budget. What we lose in productivity, means less features/capabilities in our business apps. There is no unlimited budget to deliver x,y,z at any cost.
We are at the point where new apps have to be web based to support mobile/tablets and I think MS sees this as well with the lack of investment in WPF/Winforms the last few years. We've mostly enjoyed using ASP.NET core but can't say the same about the UI with Angular 2. It has been very slow going and has killed our productivity. The less features/capabilities we add the less data/resources/services we consume in Azure. The current day reality of a .NET web application is having two incompatible code bases that then need to talk to each other, which is painful and productivity sapping.

https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/10027638-create-a-ubiquitous-net-client-application-develo

http://forums.dotnetfoundation.org/t/does-compiling-net-code-including-ui-technology-to-webassembly-sound-reasonable/1414

https://github.com/dotnet/corefx/issues/5766

https://github.com/xamarin/WebSharp
But looks like only 1 person working on it 😞

microsoft/xaml-standard#57

Watch how fast this topic gets closed

@coolcsh @terrajobst @migueldeicaza @Mike-EEE

@JohnGalt1717
Copy link
Author

@FlightLevel I'm glad I'm not the only one that sees the Elegance of this!

Yes web assemblies are the holy Grail. Until we can drop ie 11 etc support unfortunately it needs to be compilable to HTML.

Bridget.net does what you're describing. You might want to take a look.

This is the half way step to that that leverages MVC.net to generate the HTML/JavaScript automatically to run purely client side while supporting server side rendering for first load and SSO.

It's a doable enhancement to MVC.net that would make .net developer vastly more productive than the competition and give ms a major market advantage which is exactly what they need right now to get developers back. Good will isn't enough.

I hope this doesn't get closed a d it is taken seriously because as it stands we and many other firms I'm involved with are considering cutting bait with Ms and just going full node because the overhead is way less. Javascriptservices does nothing but add unneeded complexity.

So just like windows itself, .net is facing an inexerable decline through this slow attrition unless something is done. It's like watching windows mobile all over again. Making MVC.net which as it is right now better and faster is a waste of time for serving web pages. (Great for api but again why bother knowing two languages when you can do it all in nodejs and just Chuck a ton of mini docker containers at the problems with node?)

Ms has to do something drastically innovative. Creating an integrated server and browser based version of MVC.net is exactly what the doctor ordered.

@Mike-E-angelo
Copy link

Thank you for the ping, @FlightLevel!

To add a little more here, the core problem here is a business problem. One that was solved two-fold when MSFT acquired Xamarin last year. However, there still remains a costly divide between .NET and "web" that simply does not exist in a NodeJS/NativeScript/Plain 'ol JS solution. In the sake of keeping chatter (read: repeating myself over and over) low, I explain more here.

@ClaudioNunes
Copy link

ClaudioNunes commented May 22, 2017

@FlightLevel , MS already created and promoted a "WPF in the browser": "wpf/e" named "Silverlight" after (RIP). To do what you asking for, MS has to rollout its own client framework (client routing, http calls, validation, and etc.) and deal also with other things like module bundlers and loaders. As you I also would LOVE write web applications using only C# and XAML (I was able to do this with now"dying" Silverlight) but I really don't see MS going in this direction, albeit having two client framework mentors in it's trenchs ( @SteveSandersonMS and @EisenbergEffect)

@Mike-E-angelo
Copy link

@ClaudioNunes we're closer than you might think. We already have a Mono port to WebAssembly underway. Seeing on how WASM is 20x faster than JavaScript (!), it might be worth looking into it just in case it catches on... oh, and it's already deployed in Chrome and FireFox. 😄

@SteveSandersonMS
Copy link
Member

SteveSandersonMS commented May 22, 2017

Great to see interesting discussion on this subject!

I agree with most of the thoughts posted here, and overall, would personally love for us to build something along these lines. It's certainly something that various people have considered in the past, with a range of different approaches. I too have experimented with prototyping a C#-based SPA framework, have a lot of opinions on how it could work best, and generally agree it could be really effective. However, I can't personally make Microsoft actually build something like this, and am not aware of specific plans for it to happen.

[flightlevel] Watch how fast this topic gets closed
[JohnGalt171] I hope this doesn't get closed a d it is taken seriously

I'm sorry but I am going to mark it closed, because this is an issue tracker for the JavaScriptServices code, i.e., where we track what work is actually going to happen in this specific repo. Like mentioned above, I do hope this sort of thing could happen, but if it does, it wouldn't be developed here in this repo - it would be a separate product. That said, you're totally welcome to continue the discussion here! I hope that seems reasonable.

@JohnGalt1717
Copy link
Author

Thanks @SteveSandersonMS ! I appreciate you listening!

How could we get this infront of the right people? Integrating this directly into MVC.net seamlessly would be so elegant...

@SteveSandersonMS
Copy link
Member

@JohnGalt1717 Since this is the second-highest-requested item on https://visualstudio.uservoice.com/forums/121579-visual-studio-ide, I suspect that the relevant level of management is already well aware of the demand. Whether they have plans to do something with this or not, I don't know.

@Mike-E-angelo
Copy link

Excellently spoken (and closed), @SteveSandersonMS! 👍

And actually @JohnGalt1717, we can get you with a little more detail there:

https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/10027638-create-a-ubiquitous-net-client-application-develo

Nearly seven thousand votes... and counting. 😉

@Mike-E-angelo
Copy link

Mike-E-angelo commented May 22, 2017

Actually, when combining all known/identified issues that are asking for this, the vote total is over forty-five thousand and is on its way to approaching fifty thousand. Here is the last known vote report generated around this issue (the first one labelled "Ubiquitous / Cross-Platform Client .NET"):

http://blog.developers.win/2017/04/weekly-vote-report-for-friday-april-21-2017/

@JohnGalt1717
Copy link
Author

Wow. One would think that creating a seamless MVC.NET SPA would be #1 priority for @shanselman and crew with those kinds of numbers. IT could be so elegant and so compelling if done right that the market advantage would be enormous.

@Mike-E-angelo
Copy link

You would not be alone in your thinking, @JohnGalt1717. Clearly. 😉 😉 😉

This would reduce the cost of creating a .NET solution that requires a web client. Currently .NET developers are saddled with two, incompatible languages that double the cost in development and maintenance. This is compared to NodeJS applications where JS is used exclusively everywhere for server, client, and native scenarios (hint: one code base is cheaper than two).

@JohnGalt1717
Copy link
Author

100% And when you can write nodejs for your web and use javascript only and that directly goes to Ionic or other webbased mobile platforms for android, ios and even Windows now, why would you bother using C#?

It is VITAL that MVC.NET is extended with full SPA and then native support. And MS has to put macs in the cloud for us to compile and deploy to the store against.

Then you can easily know just C# with passing javascript knowledge and HTML. If you want you can add on XAML with Xamarin and you're done. And if they did this right it's seamless with C# to javascript compilation and the MVC.NET pages functionality that was just announced. One code behind file that rules them all. Server side pre-rendering as we get right now, and compiled to javascript for browsers once first page is loaded. Routing is already done so just have it compile to javascript.

Break each folder into a separate bundle for size and speed. Volia. So Elegant. Way better than any node + angular approach for sure!

@Mike-E-angelo
Copy link

Happy to have your support, @JohnGalt1717. 😄 Don't fret though... this is a business problem that will solve itself once organizations start using Node/JS exclusively for their solutions and ditch .NET altogether since it is cheaper to do so. I'm just the messenger yelling "ice berg straight ahead!" 😛

@JohnGalt1717
Copy link
Author

So am I!!! I can't believe that it's taken them this long to figure this out. They should have had betas out a year ago.

@ghost
Copy link

ghost commented Jun 28, 2017

Great to see this getting some attention https://youtu.be/eiG2nP2vTgY?t=43m13s
And awesome work from @SteveSandersonMS over here https://github.com/SteveSanderson/Blazor

@JohnGalt1717
Copy link
Author

@SteveSandersonMS THERE IS 100% interest in this! Please continue! I'm so ready to dump Angular et. al. and dev in pure C# with some HTML again.

@JohnGalt1717
Copy link
Author

@SteveSandersonMS I'd love to see code behind methods in the mvc pages implementation and routing based on the mvc routing otherwise this is awesome! Totally sold! Please tell the people at MS to make this into a real deal and get this out the door. You'll absolutely kill it with this.

Especially if you make this compile to native for mobile apps too as an alternative to ionic etc.

@Mike-E-angelo
Copy link

100% agree here with @JohnGalt1717. It would suck, but using an HTML5 view system might be the way to go if you can get this to render in a native scenario as well.

I've echoed John's sentiments here and give @SteveSandersonMS a big shout out for a MSFT super raise here.

Also Mr. Sanderson, please consider opening up issues in your GitHub repo. While you might not be open to new bug reports and the like, it does offer a way for interested users to start discussions with your project. It's amazing that with how tied MSFT is to GitHub, that there haven't been efforts to improve the tooling and limited conversational featureset that GitHub provides. Threaded conversations (or really, conversations in general! think: forum) would go a long way towards improving engagement and community traction with projects, IMO.

@danroth27
Copy link
Member

Hi folks,

This issue has been closed for a bit, but here's an update in case anyone stumbles across this issue looking for a full stack .NET web development solution. I'm happy to share that today we announced that Blazor is now an official "experimental" ASP.NET project. Blazor is an "experimental web UI framework based on C#, Razor, and HTML that runs in the browser via WebAssembly". There's nothing to download yet, but the code is available and being actively worked on by the ASP.NET team (hopefully we'll have something for you to play around with soon!). We invite you to check out the action on the Blazor repo. Feel free to file issues or join the discussion on Gitter.

Thanks!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants