4 ms·

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

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.

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.