3 ms·

What killed IE (I am not a IE hater) is the amount of extra work you had to invest to get a site to work. I've recently done some work that had to work with ver

What killed IE (I am not a IE hater) is the amount of extra work you had to invest to get a site to work. I've recently done some work that had to work with versions of IE9-11. I consider myself pretty good with writing front end code that will work with IE and there are many gotchas that I had forgotten about. The debugger is painful to use even on IE11.

osrec 7y ago
I think that's the broad, standards based support that they were missing!
computerex 7y ago
The debugger in IE11 is so painful to use. It's an absolute nightmare. It takes forever to launch, it freezes, freezes the whole browser, I don't understand how it's acceptable for it to be so sluggish when running on a top of the line development workstation. The app I work on has to support IE11 and it's easily the worst part of the job. Often times regressions are made because someone accidentally used some js keyword/feature that's not supported. The build takes forever because of IE, and so there is a flag IE_BUILD that's false most of the times until someone has to test in IE at which point they turn it on and wait for 10 mins for the thing to build. We had to implement theming, and for every other browser we used CSS variables but for IE we had to implement a hacky/complicated solution where we compiled customer specific CSS files. In short, IE sucks and I wish it'd die.
- uk_programmer 7y ago
  With regards to IE specific code. Generally the approach I would take would: 1) Code normally and check compatibility of functions with the minimum version of IE. I then either polyfill the browser (if I understand the polyfill, some polyfills are quite large). Where I don't understand what the polyfill is doing or it is quite large (more than 40 or 50 lines) I then implement a specific work around and try to put it that logic in a separate function e.g. for dataset on Elements I have a function that detects whether data set exists and then just uses setAttribute with some regex munging as 90% of the time I only need to read and write dataset values and I rarely care about dom mutations. 2) Regarding styling. My approach is to that I style everything up and then use specific overrides for things that browsers can't do. I also tend to avoid specific IE builds as you end up supporting almost two code bases. However I have years of intuition of what will and won't work in outdated browsers. However I appreciate that this isn't always possible or desirable depending on frameworks / libs used etc.
tootie 7y ago
That's not it at all. You're talking about the IE tax in a post-IE world. Look at US v Microsoft in 2001 and the early Browser Wars. IE had crushed Netscape (via shady business practices) and had market domination. For a long time, all projects were IE-first, then you would worry about niche upstarts like Firefox. It wasn't until the launch of Chrome and Safari and the resurgence of Apple and OSX that there was any plausible alternative. It was at that point that standards and compatibility really became paramount. IE wasn't "extra work", it was the primary objective.
- rstupek 7y ago
  Having been developing for the web back then IE also was at that time a simply better browser than Netscape. Once it started to stagnate that ended up not being the truth but many of the things we take for granted today (xmlhttprequest for example) were invented in IE 6.
- pavlov 7y ago
  "> IE had crushed Netscape (via shady business practices)" No, IE was actually a much better browser in 1999-2000. It crushed Netscape 4 even on web standards support. For example much of CSS was terribly broken in Netscape.
  - jart 7y ago
    Hear Hear. I look back at supporting Netscape 4 in late 90's as equally painful as supporting IE6 in late 2000's. It's difficult to imagine, but Internet Explorer was superbly superior during that time. For example, the Netscape4 window couldn't even be resized without needing to reload and redraw the page from scratch.
  - icedchai 7y ago
    Not to mention Netscape was incredibly unstable. I remember Netscape 4 crashing roughly every half hour. IE was rock solid in comparison.
  - Firehawke 7y ago
    This was actually one of the things I was going to reply with-- it also crashed significantly less on Windows than Netscape 4 and ran faster up until Active Desktop started to clog the whole thing up.

osrec 7y ago

I think that's the broad, standards based support that they were missing!

computerex 7y ago

The debugger in IE11 is so painful to use. It's an absolute nightmare. It takes forever to launch, it freezes, freezes the whole browser, I don't understand how it's acceptable for it to be so sluggish when running on a top of the line development workstation. The app I work on has to support IE11 and it's easily the worst part of the job. Often times regressions are made because someone accidentally used some js keyword/feature that's not supported. The build takes forever because of IE, and so there is a flag IE_BUILD that's false most of the times until someone has to test in IE at which point they turn it on and wait for 10 mins for the thing to build. We had to implement theming, and for every other browser we used CSS variables but for IE we had to implement a hacky/complicated solution where we compiled customer specific CSS files. In short, IE sucks and I wish it'd die.

uk_programmer 7y ago
With regards to IE specific code. Generally the approach I would take would: 1) Code normally and check compatibility of functions with the minimum version of IE. I then either polyfill the browser (if I understand the polyfill, some polyfills are quite large). Where I don't understand what the polyfill is doing or it is quite large (more than 40 or 50 lines) I then implement a specific work around and try to put it that logic in a separate function e.g. for dataset on Elements I have a function that detects whether data set exists and then just uses setAttribute with some regex munging as 90% of the time I only need to read and write dataset values and I rarely care about dom mutations. 2) Regarding styling. My approach is to that I style everything up and then use specific overrides for things that browsers can't do. I also tend to avoid specific IE builds as you end up supporting almost two code bases. However I have years of intuition of what will and won't work in outdated browsers. However I appreciate that this isn't always possible or desirable depending on frameworks / libs used etc.

tootie 7y ago

That's not it at all. You're talking about the IE tax in a post-IE world. Look at US v Microsoft in 2001 and the early Browser Wars. IE had crushed Netscape (via shady business practices) and had market domination. For a long time, all projects were IE-first, then you would worry about niche upstarts like Firefox. It wasn't until the launch of Chrome and Safari and the resurgence of Apple and OSX that there was any plausible alternative. It was at that point that standards and compatibility really became paramount. IE wasn't "extra work", it was the primary objective.

rstupek 7y ago
Having been developing for the web back then IE also was at that time a simply better browser than Netscape. Once it started to stagnate that ended up not being the truth but many of the things we take for granted today (xmlhttprequest for example) were invented in IE 6.
pavlov 7y ago
"> IE had crushed Netscape (via shady business practices)" No, IE was actually a much better browser in 1999-2000. It crushed Netscape 4 even on web standards support. For example much of CSS was terribly broken in Netscape.
- jart 7y ago
  Hear Hear. I look back at supporting Netscape 4 in late 90's as equally painful as supporting IE6 in late 2000's. It's difficult to imagine, but Internet Explorer was superbly superior during that time. For example, the Netscape4 window couldn't even be resized without needing to reload and redraw the page from scratch.
- icedchai 7y ago
  Not to mention Netscape was incredibly unstable. I remember Netscape 4 crashing roughly every half hour. IE was rock solid in comparison.
- Firehawke 7y ago
  This was actually one of the things I was going to reply with-- it also crashed significantly less on Windows than Netscape 4 and ran faster up until Active Desktop started to clog the whole thing up.