Microsoft Tech

6 Web Development Myths about Microsoft Edge

    Riza Marhaban
    Share

    This article is part of a web development series from Microsoft. Thank you for supporting the partners who make SitePoint possible.

    You may (or may not) have heard, Microsoft Edge is the default browser for Windows 10 and has a completely different rendering engine (EdgeHTML) which renders HTML5 Web Standards more like Chrome, Firefox, and Safari browsers than older versions of Internet Explorer.

    That should be good news for web devs especially when you combine the news that Microsoft has ended lifecycle support for IE8, IE9, and IE10 too. Microsoft Edge is also very different from other versions of IE since there are no BHOs (Browser Helper Object) or ActiveX components other than PDF or Flash.

    Microsoft Edge browser also has leading support for ES6 (ECMA Script 6); in fact it’s already supported up to 90% at the time I was writing this. We also know that the Edge JavaScript engine, ‘Chakra’, has now become open-sourced. This means developers can use this engine outside of browser environment.

    But with all this progress, I’ve also observed web developers on social media or forums showing off code that may web apps are not taking full advantage of Microsoft Edge, although they think it works, their code is still treating Microsoft Edge more like Internet Explorer than Chrome, Firefox, or Safari. Maybe some developers are assuming that Microsoft Edge is IE11–let me tell you this, Microsoft Edge IS NOT IE11. So I’d like to address the myths that web developers sometimes assume or may be unaware of about Microsoft Edge browser. Maybe, maybe not; anyway, I just want to help by sharing this. So, let’s look at six top web development myths about Microsoft Edge.

    Myth #1

    Microsoft Edge is using Trident rendering engine.

    FACT CHECK: FALSE!

    The truth is Microsoft Edge has a new rendering engine that continues to evolve called ‘EdgeHTML‘ and the JavaScript engine called ‘Chakra‘. It’s also even more standards-compliant as measured by HTML5Test:

    HTML5Test

    How to Check This

    To identify the Microsoft Edge and EdgeHTML version, just go to Settings (the dot-dot-dot icon on the top right) and scroll down to the bottom.

    EdgeHTML settings

    Myth #2

    HTML Document Declaration. Some developers think that Microsoft Edge does not/cannot use this line:

    <!DOCTYPE html>

    FACT CHECK: FALSE!

    The truth is the Microsoft Edge browser is better off using the HTML5 document type and telling the browser EdgeHTML to render as an HTML5 document. In fact, Internet Explorer 9+ has supported <!DOCTYPE html> in similar manner.

    How to Use It?

    Use at the top or the first line in the HTML document before <head /> element. Example:

    HTML Document declaration

    Myth #3

    In a Microsoft Edge HTML document, we need to add meta information, which is the User Agent (UA) compatibility as ‘Edge‘. That is:

    <meta http-equiv="X-UA-Compatible" content="IE=edge">

    FACT CHECK: FALSE!

    The truth is ‘NO‘, you do not need to add this line. Even if you targeted IE11 browser, there’s no need to add this meta information. It does not require or even has any function in the Microsoft Edge browser.

    How To Resolve This

    Remove any http-equiv=”X-UA-Compatible” meta tag on the HTML document. What if you need the site to be compatible with old browsers such as IE8, IE9 or IE10? See Myth #4 and #5 below.

    Myth #4

    To be compatible with Edge browser, I must detect or sniff the browser User Agent string (UA String) before requesting content from the web server, so when the server respond, I can return the correct HTML version accordingly.

    FACT CHECK: FALSE!

    The truth is, you must avoid any sniffing or detecting browsers User Agent string for conditioning request to the web server. You should just return any request as HTML5 Web Standards contents. In some cases, you may need to sniff the browser UA string, but make sure it’s only for checking purpose and not for conditioning of web server responses. Why? Because HTML layout/rendering engine is a fault tolerant declarative language. It wouldn’t block HTML document even if you throw any non HTML syntax. However, don’t abuse the HTML document with junk or some trash text.

    How to Resolve This

    There are several ways to resolve this. First, you must remove any client or web server side code that has UA sniffing for conditioning web server responses based on that UA string. Try to avoid this–this is not recommended in HTML5 Web Standards. Make sure you have a clean HTML document. Remove any non HTML web standards syntax.

    Some say, “What if I need to know whether the browsers support certain features?”

    Yes, no issue for that. My suggestion (recommended) is to use Modernizr.js. Modernizer.js is an industrial standard JavaScript to check browsers compatibility. Modernizr tells you what HTML, CSS and JavaScript features the user’s browser has to offer. The other way is you can just use a normal HTML which has smart fallback mechanism. For example, the code below will render normally in modern browsers and non-modern browsers, even though it is using HTML5 code.

    Modernizr.js

    Here is the output on Microsoft Edge:

    Microsoft Edge view

    And here is on Microsoft IE6. Wait! What… IE6? Yes, I also tried it on IE6 for testing. It does not mean you should use IE6 instead. Is just to proof that the HTML5 code works because browsers’ HTML layout/rendering engine are fault tolerant. It renders what it understand.

    Microsoft IE6 view

    Myth #5

    Microsoft Edge JavaScript is Slow! Like its predecessor, IE.

    FACT CHECK: FALSE!

    Don’t always blame the browser; there are many factors that go into performance including certainly standards-compliant code on a site. Here are the latest benchmark across popular tests; you can see the impact of Chakra’s improvements:

    Browsers performance benchmark

    My opinion to this benchmark is not for you to use it as an excuse to create non-standards compliant code and expect the browser to render it. When we say HTML5,that includes the CSS3 and JavaScript. By means, all modern browsers are great. Each has its own strength and weakness. Sometimes web developers also compare the browser specific features with one another. I tell you, it won’t have the same standards. Here is an example: let’s say iOS Safari, Apple will have their own specific CSS prefix for matching its device features, such as iPhone 6S, to suit their specific app. But that is not necessary for other browsers. Therefore, my suggestion is just use the proper HTML5 Web Standards that work on all browsers. Just code one HTML5, test in all browsers. If you need to use certain features, you can use Modernizr.

    How to Optimize This

    You can do a benchmark to test your web app by opening it in Edge browser. Optimize the web by using proper HTML5 Web Standards. Scan your site using the Site Scan Tools and see which parts can be optimized other than JavaScript codes. This may gain performance. You can also use Vorlon.JS if you need to debug the HTML5 on multiple browsers (including mobile browsers) to match designs, layout and compatibility.

    If you need to optimize the JavaScript, you can always use vanilla JavaScript. Don’t use too much of JavaScript libraries/frameworks. Use wisely. Microsoft Edge currently supports JavaScript ES6 (Kangax ES6 Compatibility Table).

    ES6 compatibility table

    Myth #6

    My web app is for LOB (line of business) and is for internal use only (Intranet). We don’t need to migrate to support Microsoft Edge now, since HTML5 will not be ready before year 2022.

    FACT CHECK: SUPER FALSE!

    HTML5 is here. Your intranet app should be migrated to HTML5 now or otherwise you should consider your migration plan to HTML5 at least on the year 2013 as modern browser continue to be deployed across organizations. While IE11 now has legacy emulation to help make the path towards migration more smooth, there are still performance, usability, and just the maintenance of one standards-compliant code base to consider. Just imagine if your colleague wants to use the latest mobile phones for accessing the intranet from outside of the office building. They cannot do that since mobile browsers did not support legacy web. There is no ActiveX, no Silverlight and no custom plugins that can be used. It’s time to use HTML5 now.

    How to Migrate

    Here are some small myths that I observe and what you should do.

    • Most enterprises still use Windows 7–we cannot migrate: Well, you can install IE11 or the latest version of Chrome or Firefox if you want to make it work in HTML5. You can start migrating slowly to target IE11, BUT, please use HTML5 as your plan for migration. So, not just browser migration plan. Do HTML migration plan as well.
    • My intranet requires ActiveX for our LoB app: No problem, you can use IE11 or the latest version of Chrome or Firefox while you are planning for migration. Use it as a temporary migration process. Slowly remove any BHO (browser helper object), such as ActiveX Plugins, and replace with new web app development with HTML5 Web Standards. It’s more secure and provides better performance.
    • You don’t understand, we have hundreds of intranet web app: Personally I do understand. That is why you need a plan to migrate. Put it like this, the migration to HTML5 is your priority and you need to do it starting now.
    • I use 3rd party products for the intranet web app: Contact the vendors and ask for the updated HTML5 one. If they don’t have it, don’t use it. Use the one that has up-to-date one. My suggestion, if the vendor is using ActiveX, than replace it with proper HTML5 Web Standards only.

    Conclusion: Use HTML5 Web Standards

    Use HTML5 Web Standards if you want to target all modern web browsers. Microsoft Edge and IE11 are modern web browsers. You don’t need to worry about compatibility as long as you use proper HTML5. Proper HTML5 means this:

    1. Ensure HTML5 Rendering Mode on first line. Yes this one line .
    2. Avoid Browser Sniffing and Detection for conditioning request based on browsers’ User Agent string.
    3. Avoid vendor specific CSS Prefixes. You cannot have the same browser features in all browsers. Therefore use the standards HTML5 one that has been rectified and supported in all modern browsers.
    4. Update your JavaScript Libraries, Please! E.g. don’t use outdated jQuery or any other JavaScript libraries. Don’t use libraries that have not been updated by the creator. Always update to the latest version since the creator will also follow the web standards specification; in this case HTML5.
    5. Stop using Plug-ins! No more Silverlight, avoid Flash, no more custom ActiveX. These are not HTML5 Web Standards, that is browser legacy options and not HTML. E.g. You can now create animation using CSS3 and JavaScript, even for 3D and vector graphics (SVG).

    More Hands-on with Web Development

    This article is part of the web development series from Microsoft evangelists and engineers on practical JavaScript learning, open source projects, and interoperability best practices including Microsoft Edge browser and the new EdgeHTML rendering engine.

    We encourage you to test across browsers and devices including Microsoft Edge – the default browser for Windows 10 – with free tools on dev.microsoftedge.com:

    More in-depth learning from our engineers and evangelists:

    Our community open source projects:

    More free tools and back-end web dev stuff:

    CSS Master, 3rd Edition