Explore dropping support for Internet Explorer

[futagoza]

I'm thinking before releasing 0.12 I should drop support for Internet Explorer entirely (both from the library and from the online editor). There are a couple of reasons for this;

• More development software overtime seems to not work with it (in this cause, NPM modules)
• Google Analytics shows a huge drop in IE11 users in the last 2 years
• It's become a pain trying to keep from using ECMAScript built-ins not supported by IE11
• I find it a pain in general now 😅

In the upcoming month's I plan to add changes that support evergreen compatibility (using ES2015+ built-ins via polyfills); after this, I will decide if it's worth it or not to totally drop support for IE; In the meantime, feel free to discourage (or encourage) this change.

[StoneCypher]

No.

IE is the world's third most common browser, and there are no problems for Peg under IE. There are major problems for PEG that have nothing to do with IE that we've been waiting on you three years to solve.

There is no need or call for polyfills in PEG. Nothing in PEG wants or needs them. You're going to 10x the size of the parser for no reason, to solve problems that don't exist.

Please consider turning PEG over to someone with the experience to get releases started again. You have not released anything, and you've changed the shape of the library to that none of the old contributors are even able to fix small things anymore. You're working on a different parser in a different language with a different AST that none of us will be able to use.

If you want to write a new PEG engine, fine, go ahead.

Don't kill this one. Let us have our software back now

.

More development software overtime seems to not work with it (in this cause, NPM modules)

Respectfully, there is zero overhead from IE.

[StoneCypher]

It's become a pain trying to keep from using ECMAScript built-ins not supported by IE11

You shouldn't be doing this. You should be accepting the patches from 2016 and 2017 that let us use them directly.

A parser should not be trying to use shims.

A parser should not be trying to dictate what goes in based on the exterior machine.

A parser should not be interacting with NPM.

A parser should not require you to install package managers.

A character-level parser should not need support from a browser to do parsing.

You should not be using tools from outside of a parser to do parsing.

A zero-library parser should not be stuck on ditching active users over library support to do parsing.

There is a reason that none of the other parsers out there work this way.

Please let someone bring this back to being a healthy, normal, atypical parser now. I would be happy to help. I can give you es6 and typescript support in under 30 days without any major changes, in 0.10, the same way I said I could in 2018. We don't need major architectural changes, breaking AST replacements, to ditch browser support, a programming language switch, a new from-scratch parser, or any of this.

We need a maintainer who's willing to accept small patches, have small manageably sized releases, and who's willing to keep the library in a healthy state at all times.

Nobody has been able to contribute since 2017.

It's time for you to let someone else help.