EDGE EXTENSIONS .NET COMPATIBILITY
I see that this vote was taken down (which is completely against the spirit of a *community* telling YOU what THEY want).
.NET has been around for over a decade. Organizations and developers alike have invested hundreds of thousands of hours learning .NET and its languages. Code bases and libraries have been built around these languages that eliminate friction and encapsulate solutions to problems encountered over the lifetime of a product and/or framework.
In addition to forgoing hundreds of thousands of hours (and dollars) of investment, organizations and developers must now solve re-occurring problems (already encountered and accounted for in their favorite and familiar language of choice) in a completely new language, and forcing them to abandon mature and tested code. In doing so, they encounter new frictions and frustrations related to a different, incompatible paradigm that is being (unnecessarily) forced upon them. This is a wasteful and inefficient (not to mention expensive) approach.
The net result of this approach is that the same problems are now solved in two different languages, fundamentally breaking the principle of DRY.
The Edge team should account for .NET developers and allow them to leverage their extensive and exhaustive investments to make Edge a better (and fun, thereby more popular) product.
Zaryab Haider commented
Well Unfortunately I have an web application basically developed in ASP classic and is rich with ActiveX controls to access hardware.. So basically the problem is Edge brings the end of ActiveX support and also other browsers are ending up support for NPAPI plugins as well.
We are going for cross browsers so I need a suggestion is there any way to replace those ActiveX controls with some other tech to make it work with compatibility of cross browsing platform?
Help would be much appreciated.
Thanks in advance.
Jason R commented
If you're going to emulate flash, you should also emulate .net/silverlight as well.
Some Idiot commented
Thanks for your feedback, Kai. To be sure, this ask is for tooling around the Extensions API exactly like you suggest in regards to an asm.js/WebAssembly.
This would indeed involve a serious toolchain and development process on .NET's side as you suggest (see: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/10027638-create-a-ubiquitous-net-client-application-develo ), but at some point it would indeed involve integration with the Edge team to properly connect the pieces and have their API play nicely with the new system.
There are two sides to MSFT: web and native (.NET), and they do not have to be incompatible. However, to build a bridge you need two stable foundations on each side from which to anchor the bridge. :)
More than anything, this is asking the Edge team to account for their side of the work (and to build awareness/demand, etc).
The important thing here is that we are NOT asking for another ActiveX/plugin design. Those days are over and done -- thankfully!
I don't think this is a good idea. It'll be another ActiveX style situation.
A .NET -> asm.js/WebAssembly compiler so you can run your .NET code in the browser would be better, and that would be more of a request to the .NET teams.
OK I have spent the past few months putting a site together to better articulate my position around this concept and the general ask here. The core of the issue is that promoting HTML5/JS is an incompatible strategy with other Microsoft properties. Namely, the Windows Store and ... well, pretty much every technology under its IP portfolio, LOL. However, that doesn't mean it's incompatible or that there isn't a solution.
You can view the series here: http://blog.developers.win/series/bridge-to-dotnet-ubiquity/
Furthermore, the particular post that examines the expensive and divisive nature of promoting HTML5 alongside current .NET client application models and corresponding technologies can be found here:
Additionally, you can vote for the idea that will fix all of this: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/10027638-create-a-ubiquitous-net-client-application-develo
Finally, this particular vote is a featured vote on Developers Win! http://developers.win/edge
Wow, that was a LOT longer post than I thought it was, LOL!
There has been some great discussions here and I (again) want to thank the Edge team and in particular David Storey for providing input and perspective. It's helped shaped my own thoughts around this and also made me realize that what I am after is bigger than the Edge group in particular (although they should most definitely be involved in some capacity).
You make some good points below, Cyprien. This vote doesn't really capture the goal here, but it does attend to some of the primary issues. Everything you say makes sense through the lens of a web developer. And, if Microsoft was a web development company, then case closed, we're all happy and end of discussion.
I would get to shut my face and you all would get to live in peace. :)
However, it's not, and therein lies the problem. We have 15 years of .NET development to account for that currently does not enjoy the web ubiquity that you do. That is 15 years and thousands of organizations and 100,000s of developers who LOVE and PREFER their client application models JUST AS MUCH as you and other web developers do with yours. How are we (and Microsoft) to account for this?
The primary issue here is that Microsoft does not have a bridge between the varying .NET client application models (WinForms/WPF/UWP) and the standards-compliant ubiquitous web. It is an enormously tremendous (expensive) hurdle and one that should be addressed altogether before every MSFT developer decides to bail altogether.
And they will.
Consider this: MSFT charges developers $19/year (and companies $99/year) to register for the Windows Store. Meanwhile, they are simultaneously promoting web-standards and HTML5 development through Angular and here with Edge.
If a developer can develop a HTML5 application FOR FREE and is available more ubiquitously than a hosted store, then what incentive do they have to pay the $19 to register for access for a non-ubiquitous market?
As awesome a job that the Edge team is doing, MSFT doesn't make money from its efforts or the standards it is promoting. In fact, MSFT doesn't make money from HTML5 at all, except if 1) Web Developers purchase Visual Studio (unlikely) or 2) Web Developers purchase and host on Azure (more likely).
(Feel free to correct me here if I am wrong.)
In fact, for every web developer out there, Microsoft is actually LOSING money because each one of those web developers are a potential $19 a year through the eyes of the Windows Store.
Talk about self-sabotage. If I were a MSFT shareholder, I would be disturbed by this revelation.
Again, this is a much bigger problem that is outside of the scope of this vote, but it is ultimately related. How do we bridge the divide between .NET client application models (which MSFT is now charging for registration as a featured business model) and the ubiquitous web (which is free and does not directly feed MSFT's bottom line)?
I appreciate the conversation and do know I am wanting to make sure that MSFT is successful with its endeavors. I say that as someone who has invested nearly fifteen years of their life into its technologies.
Cyprien Autexier commented
I think the original suggestion has been taken down because discussion was becoming non constructive.
I am not opposed to this suggestion but I don't think this is a priority at all and I would prefer to see the Edge team move fast rather than spending time on this one.
Here are the reasons I see :
- The is a huge community community
- The IntelliSense c# developer love will be there if you choose to use Typescript
- async await c# developers are addicted to are already in preview
- Typescript is very easy to learn for a C# developer
In addition I'm curious to hear about those companies who chose to invest massive money to build .net browser extension. I think C++ was more common.