Comment by ComputerGuru | Hacker News Reader

Comment by ComputerGuru | Hacker News Reader

I maintain a few JavaScript libraries that I manually verify compatibility against IE6 (and have lints to catch violations). I manually polyfill a few necessities and quality-of-life improvements up top in the script. Out of curiosity, I removed my polyfills and tried swc and babel both, followed by an eslint pass, and the results were absolutely atrocious. Everything gets polyfilled, even stuff that has been supported in every IE version ever. The usage-based detection is completely borked, and is completely based off string searching property/function names. Using toString() anywhere pulls in the polyfills for Date to string, Regex to string, and Object to string. Using regex anywhere pulls in a bunch of regex polyfills. It was a nightmare and the size of my library increased by orders of magnitude!

(I tried opening an swc issue about optionally using typescript ast info (via a plugin, not in swc core) to have more correct usage-based polyfill detection, but that was closed as unlikely to be acted upon.)

Author here.

That mirrors my experience too on working in various projects. The automatic polyfilling story is such a good thing in theory, but reality isn't as rosy and much more polyfills than necessary are included.

Thanks for writing your article and sharing! One thing I do on my other libraries is also to polyfill a few heavier things asynchronously instead of making everyone pay the price upfront, so for example I detect if a JSON polyfill is required before asynchronously loading that polyfill. I think the expectation for most things is that the browser will support them by default, and it’s ok if all/any polyfills are loaded separately and asynchronously.

> I maintain a few JavaScript libraries that I manually verify compatibility against IE6

Genuinely curious why anyone would target IE6 in 2023. Is it a personal goal to have massive coverage for your library?

It was used in the checkout flow on our website and the marginal cost of supporting IE6 wasn’t worth a lost sale. That was many years ago, and since then I don’t think we have anyone on less than IE8 due to TLS version issues with CloudFront, but the code already supported IE6 and there aren’t many polyfills extra compared to IE10, so :shrug:

Why are you supporting IE6?

I replied to a sister comment to yours but it’s an old library that started off with IE6 support maybe 10 years ago and just kinda never lost it.

Thank you for supporting IE6. I also maintain some JS and ensure compatibility with older browsers. Someone out there still wants to use it, whether it's an old machine with nostalgic value, the only machine they happen to have available, or just retro-computing enthusiasts, and I take pride in accommodating them. Good on you.

Since IE6 depends on the schannel implementation of the OS, it should not support neither TLS1.2 nor TLS 1.3. This means that it simply can't access the modern web anymore. Maybe there are still webservers out there though that still support outdated SSL/TLS versions and were never patched shudder

For accessibility reasons, I make my sites available using HTTP.

It allows users to bypass using TLS in situations where it breaks being able to access the website, such as this one.

(There are many scenarios when TLS can break accessibility, and in many of them access to the information is more important than the integrity of the connection.)

I guess one could also set up a proxy server that terminates TLS and rewrites https links to http. That would considerably improve confidentiality (TLS is not about integrity. Integrity has to be added at the application layer!)

I agree, and that is a great idea.

It would not solve all the problems, since not every user can set this up for themselves, but it would help a lot in the retro-computing world.

Reply on news.ycombinator.com