Better .NET-based extensions
Extensibility through .NET is very limited and cumbersome at the moment.
Magnus Olsen commented
I think it is bad idea to implement .net support direcly in browers it will be come new ie 6.0 ****.
And still it is some company that can not upgrade to windows 7/8/10 they are stuck with ie 6.0 and it cost to mush to devloping a new system.
I hope MS keep to specficatyion and do not do any browers specify so we get new ie 6.0 era
In sweden a company call hogia have done their webplatorm complety in silverlight and they do not known what todo now, Edge, chrome, opera have droped napi support and firefox will drop it this year. so the advice big company and small do not upgrade to windows 10 if they want keep runing their products and another company system req html5 support and advice their costumer to upgrade. And I working with company that have both system solv for now is run firefox for hogia and upgrade to windows 10. if net will be implement we getting new **** on the market.
Better coordination between Microsoft's groups must occur to mitigate the damaging and harmful strategy between web and native client application models. Extensions should be defined in .NET components to preserve code reuse and prevent unnecessary and wasteful overhead. Defining a ubiquitous .NET client application development model offering would allow for this. Vote for this here: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/10027638-create-a-ubiquitous-net-client-application-develo
Furthermore, a blog post that examines the expensive and divisive nature of promoting HTML5 alongside current .NET client application models and subsequent technologies can be found here:
Bret Little commented
+1 on keeping edge focused on open web standards (JS and HTML)
Incidentally, I do want to add that I have a vote on UWP for exposing your browser DOM as a UWP API:
So, maybe some cross-work can be accomplished here.
I appreciate you telling me that is where I should place my energies. The question is: since you and your team are aware of this possibility, why are YOU not doing the same in your team/product/group/division/culture? You do work for Microsoft, right? Don't you care about the countless hours (and dollars) of investment placed into existing technologies that Microsoft (along with its loyal customers) has already built and put into your company?
Don't get me wrong, you should 100% fully follow and focus on web standards. That is a wise thing to do, considering the history of MSFT doing exactly not that. But, you should also consider and embrace the other significant part of Microsoft with years (and YEARS -- if not a decade-plus) of experience and investments that can also benefit from your efforts and focus.
Again, we get back to the reoccurring theme here of the rift that exists in the Microsoft developer ecosystem. At the moment, Edge is "yet another browser" with the MSFT name slapped on it. It doesn't do anything particularly innovative, and in fact it hurts the overall narrative and strategy with MSFT developers and corporations who depend on MSFT technologies to run their business. It adds and perpetuates costly confusion and bifurcates development resources (and budgets assigned to doing so) -- as now resources must learn HTML/JS/CSS in addition to .NET/C#/UWP. By focusing *exclusively* on web standards, you are hurting more than helping your own company and the developers/organizations that depend on it.
So, please do continue to focus on web standards, but please, please, PLEASE(!) also consider the other developers in the MSFT ecosystem and encourage/support/promote innovative solutions that help bring everyone together under under the MSFT flag so we can all attain dominance in the marketplace once again.
Thank you for any further thought and consideration around this (and thank you again for the dialogue).
David Storey [MSFT] commented
I assure you that no suggestions are thoughtlessly dismissed. Everything is considered in the team. It would certainly be a costly undertaking to create our extension infrastructure twice; once for HTML/CSS/JS that all other browsers support, and again for .NET extensions that no other browser supports. This would break the principles of DRY as we'd need to implement every API twice, and developers would need to create one extension for us if they built a .NET extension and recreate it again in HTML/CSS/Js for other browsers. With our current approach, developers can build one core extension and port it to Chrome, Opera, Firefox and Edge with ease. It would also likely slow down our development pace by implementing everything twice.
It is also where the industry is going. As well as Chrome and Opera having extensions built on web technology, Firefox is dropping their vendor specific XUL extension model in favour of a similar approach to where we are heading.
As you can also see, this forum has many suggestions that we have to consider and potentially implement. In the time it was open it received relatively few votes compared to other features. By comparison, the feature suggestion by the Dart community out voted both this and the suggestion to include XAML directly in the browser. We also decided to not do that one, as it would also require us to reimplement a lot of things for a second time using a different development language, and it was unlikely to get the cross browser support that developers could rely on it in a cross-browser/cross-platform manor. Instead we went full steam ahead on ES6 features, and are now the leading implementation there.
Further mode, as the web platform team, our skills here are on open web technologies such as HTML/CSS/JS. It would likely be better for the vote to be elsewhere.
Instead of this and the other XAML suggestion, I would recommend to put your energy behind solutions that cross compile into JS. For example, Web Assembly is a new technology on the horizon. There are also solutions supported in the browser today that allow you to write in C++, compile with Emscripten and run at closer to native speeds with ASM.js (behind a flag in Edge currently). Something similar to this for cross compiling .NET would be a better bet. As Silverlight has never worked cross device (plug-ins including Flash are not supported on Mobile/Tablet OS) and as browsers have removed plug-in support (prior to our announcement of not supporting ActiveX/plug-ins), this would give you a more future proof path going forward if you don't want to write in HTML/CSS/Js.
Thanks for listening.
Thank you for your reply, David. It would be nice to get answers to the other questions. This forum is meant to provide your customers/developers a place with ideas they would like to see in your product My other "duplicate" vote clearly demonstrated the need (and value) to enable .NET Extensibility in the Edge Browser (so it wasn't an "exact" duplicate of this issue). I find it highly ironic that Edge is built as a UWP application, but you are not allowing developers to leverage the same technology to extend it. By only promoting HTML/JS as a first-class application language in MSFT ecosystem, you are causing confusion and conflict with other application paradigms, such as the very mature/established .NET space. This is a very costly and shortsighted strategy and does not reflect well on your team at all. You should be open to other MSFT technologies and embrace them as potential pathways to improve your product. You DO want your product to thrive, don't you?
I have re-created that issue. Rather than thoughtlessly dismissing it and merging it back into this issue, please take time to read this issue and provide a more thorough dialogue there about why it is not feasible/possible for your group to achieve (or even consider) it. Again, this place is meant to be a meeting ground for thoughts and ideas to *improve* your product by your developers, which you should embrace and encourage, not vice versa:
Thank you again for your participation and consideration!
David Storey [MSFT] commented
@MichaelD! your vote wasn’t deleted. It was merged as an exact duplicate of this issue. Any lost votes are due to the same people voting for both issues.
Wow. You deleted my vote. Edge team: why are you perpetuating the MSFT developer divide between native .NET technologies and web technologies? Why are you not listening to your developers and dismissing their feedback? #unnovation #lazy #collectingapaycheck
I've re-opened this vote. Please do not shut down the voice of your community! You might not have plans for this now, but users should have the opportunity to voice their opinion on the matter to possibly change your direction sometime in the future:
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.
its amazing how much neglect microsoft has given browser extensions