How can we improve the Microsoft Edge developer experience?

Better .NET-based extensions

Extensibility through .NET is very limited and cumbersome at the moment.

123 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Виктор МиловановВиктор Милованов shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    At BUILD 2015, we announced the development of a HTML/JavaScript-based extension model for Microsoft Edge. We do not plan to use .NET for these extensions since HTML/JS is a common language across browsers for extension models.

    If you would like to reuse your votes for that, please go to: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/6508820-javascript-browser-extensions

    13 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Mike-EEEMike-EEE commented  ·   ·  Flag as inappropriate

        Hi Magnus, thank you for your feedback. To be sure, the ask/vision here is not "native" .NET assemblies in which you are describing (which I 100% agree is NOT the way to go), but toolsets/chain in which these assemblies/artifacts are transpiled into JavaScript/HTML5-compliant resources which can then be loaded/viewed in any HTML5 browser -- Edge or otherwise. That way, MSFT developers and organizations who have invested heavily in .NET can continue to leverage those investments and not have to deal with the expensive alternative of dealing with two incompatible languages/code bases (C#/.NET and JS), which is (unfortunately) the current reality of today.

      • Magnus OlsenMagnus Olsen commented  ·   ·  Flag as inappropriate

        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.

      • Mike-EEEMike-EEE commented  ·   ·  Flag as inappropriate

        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:
        http://blog.developers.win/2015/10/the-broken-burned-bridge/

      • Mike-EEEMike-EEE commented  ·   ·  Flag as inappropriate

        Thank you for your reply, David. I understand it would be costly an an undertaking to develop two different infrastructures. However, that is not the ask here. There should be one infrastructure that is exposed via two different APIs: one for JavaScript, and the other for .NET/UWP.

        UWP does exactly this with their infrastructure. You can access/reference the same components through JavaScript and .NET. I think it's pure ridiculousness that they provide a JavaScript API (a bizzaro-world of JavaScript, if you will -- and 100% opposite of what we're talking about here), but hey. It works, and it's a good working example of what we're driving at here. Also consider the scenario where MSFT developers aren't exactly wanting to support other browsers, and are more about supporting MSFT (remember those days?). But also, as you alluded to, (and I discuss next), consider an alternative, innovative solution that enables .NET/UWP conversion to JavaScript and standards-compliant artifacts.

        As for your suggestion for cross-compiling into JavaScript: funny you should mention that, as if you have read any of my "Related vote"s in the other thread, you would have seen my vote that is already out there for this very idea: https://wpdev.uservoice.com/forums/110705-dev-platform/suggestions/7897380-expand-enable-universal-windows-platform-to-transp

        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]David Storey [MSFT] commented  ·   ·  Flag as inappropriate

        Hi Michael,

        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.

      • Mike-EEEMike-EEE commented  ·   ·  Flag as inappropriate

        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:
        https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/9467958-edge-extensions-net-compatibility

        Thank you again for your participation and consideration!

      • David Storey [MSFT]David Storey [MSFT] commented  ·   ·  Flag as inappropriate

        @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.

      • Mike-EEEMike-EEE commented  ·   ·  Flag as inappropriate

        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

      • Mike-EEEMike-EEE commented  ·   ·  Flag as inappropriate

        I see that this vote was taken down (which is completely against the spirit of a *community* telling YOU what THEY want):
        https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/6545194-better-net-based-extensions

        .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.

        By forcing developers to use JavaScript, and not utilize .NET languages, the Edge team is essentially forcing their users to break the fundamental principle of DRY:
        https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

        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.

      • MitchCMitchC commented  ·   ·  Flag as inappropriate

        its amazing how much neglect microsoft has given browser extensions

      Feedback and Knowledge Base