6 Web Development Myths about Microsoft Edge

As you all know that Microsoft Edge is the default browser for Windows 10 and has a completely different rendering engine which translates HTML5 Web Standards more like Chrome, Firefox and Safari browsers than the older versions of the Internet Explorer.

This will be good news for web developers when they combine the news that Microsoft has ended lifecycle support for IE8, IE9 and IE10 (where IE means Internet Explorer). Microsoft Edge is very different from the other versions of the Internet Explorer since there are no BHOs (Browser Helper Object) or ActiveX components other than the PDF or Flash.

Microsoft Edge browser has leading support for ES6 (ECMA Script 6). And 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.

I have observed that web developers on social media or forums showing off their code that may be web apps are not taking full advantage of Microsoft edge, although they think it works; their code is still treating Microsoft Edge more like the Internet Explorer than Chrome, Firefox or Safari. It is happening because may be some developers are assuming that the Microsoft Edge is IE11, so let me tell you guys, Microsoft Edge is NOT IE11. That’s why I would like to address the myths that web developers sometimes assumes or may be unaware about Microsoft Edge browser. Let take a look at some of the web development myths about Microsoft Edge.

Myth #1

Microsoft Edge is using Trident rendering engine.

Fact Check: False!

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

How to Check This?

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

Myth #2

HTML Document Declaration

Some developers think that Microsoft Edge does not or cannot use this line

<!DOCTYPE html>

Fact Check: False!

The truth is that the Microsoft Edge browser is better off using the HTML5 document type and telling the browser EdgeHTML to translate 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.

Myth #3

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

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

Fact Check: False!

There is a Big NO for this; you don’t need to add this line at all. Even if you targeted IE11 browser, there is 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 you have to do if you need the site to be compatible with the old browsers such as IE8, IE9 or IE10? See Myth #4 and #5 those are listed below.

Myth #4

To be good with Edge browser, I should recognize or sniff the browser User Agent string (UA String) before asking for substance from the web server, so when the server react, I can give back the right HTML form as needs be.

Fact check: False!

The truth is that you must have to avoid any kind of sniffing or detecting browsers User Agent string for conditioning request to the web server. You should just have to return the any request as HTML5 Web Standards contents. In some of the cases, you may need to sniff the browser UA string, but make sure it is only for the checking purpose and not for the conditioning of the web server responses. Why? It is because HTML layout or rendering engine is a fault tolerant declarative language. It will never block the 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 of all you must have to 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. And also make sure that 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. For this I recommend to use Modernizr.js.

Modernizr.js is an industrial standard JavaScript to check browsers compatibility. It tells you what HTML, CSS and JavaScript features the user’s browser has to offer. The other way is that you can just use the normal HTML which has smart fallback mechanism. For an instance, the code below will render normally in modern browsers and non-modern browsers, even though it is using HTML5 code.

Here is the output on Microsoft Edge

And here is on Microsoft IE6. Hold on! What does IE6 means here? This is only used for testing. It does not mean that you should use IE6 instead. It is just to proof that the HTML5 code works because browsers HTML layout or rendering engine are fault tolerant. It renders what it understands.

Myth #5

Microsoft Edge JavaScript is Slow!

Fact check: False!

You don’t have to always blame your browser; there are so many factors that can go into the performance that includes certain standards compliant code on a site. Here are the latest benchmarks across popular test; you can see the impact of Chakra’s improvements:

My conclusion to this benchmark is not for you to utilize it as a reason to make non-standards compliant code and anticipate that the browser will render it. When we say HTML5 is the best option that incorporates the CSS3 and JavaScript. By means, every single modern browser is incredible. Each has its own quality and shortcoming. Some of the time web designers likewise contrast the browser particular features with each other. I let you know, it won’t have the same standards. Here is a case: suppose iOS Safari, Apple will have their own particular CSS prefix for coordinating its device elements, for example, iPhone 6S, to suit their particular application. In any case, that is a bit much for different programs. Therefore, my proposal is to simply utilize the best possible HTML5 Web Standards that work on all the browsers. Simply code one HTML5, test in all browsers. In the event that you have to utilize certain elements, you can utilize Modernizr.

How to Optimize This?

You can do the benchmark to test your web app by opening it in Edge browser. You can simply optimize the web by using proper HTML5 Web Standards. Scan your site using the Site Scan Tools and can see which parts can be optimize other than the JavaScript codes. This may gain performance and you can also use the Vorlon.js, if you need to debug the HTML5 on multiple 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 or frameworks. Use wisely; Microsoft Edge currently supports JavaScript ES6 (Kangax ES6 Compatibility Table).

Myth #6

My web app is for Line of Business (LOB) 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 the 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 to make the path towards making the migration smoother, there are still so many performances, usability and just the maintenance of one standards compliant code base to consider. Suppose that 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 is high time to use HTML5.

How to Migrate?

Following are the some myths that I observe during the process and what you should do if you face them:

  • Most enterprises still use Windows 7 that we cannot migrate

Well you can install IE11 or the latest version of the Chrome or Firefox if you want to make it work in HTML5. You can start migrating slowly to target the IE11, but please use HTML5 as your plan for migration. So not only plan to browser migration but also do the HTML migration as well.

  • My intranet requires ActiveX for our LoB app

No problem in this, you can use IE11 or the latest version of the Chrome or Firefox while you are planning for the migration. Use it as a temporary migration process. Simply remove any BHO (Browser Helper Object), such as ActiveX Plugins and replace with the new web app development with the HTML5 Web Standards. It is more secure and provides better performance.

  • You don’t understand that we have hundreds of intranet web app

By and by I do get it. That is the reason you need a plan to migrate. Put it like this, the migration to HTML5 is your need and you have to do it beginning at this point.

  • I use 3rdparty product for the intranet web app

Contact the vendors and ask for the updated HTML5 one. If they don’t have it then doesn’t use it. Use the one that is up-to-date. According to my suggestion if the vendor is using ActiveX then replace it with the proper HTML5 Web Standards only.

Conclusion: Use HTML5 Web Standards

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

Proper HTML mean:

  • Ensure HTML5 Rendering Mode on the first line
  • Avoid Browser Sniffing and Detection
  • Avoid Vendor Specific CSS Prefixes
  • Update your JavaScript Libraries
  • Stop Using Plug-ins

That’s it, here I am done. Read them carefully and if you have any doubt you can leave that in the comment section or if you want to share something about your experience in this process you can also leave that in the comment section.


Originally published at www.balharainfotech.com on February 2, 2016.