Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

webpack2 doesn't support IE8 #3070

Closed
breeswish opened this issue Sep 27, 2016 · 38 comments
Closed

webpack2 doesn't support IE8 #3070

breeswish opened this issue Sep 27, 2016 · 38 comments

Comments

@breeswish
Copy link

@breeswish breeswish commented Sep 27, 2016

es5-shim cannot polyfill getters or setters of Object.defineProperty:

https://github.com/webpack/webpack/blob/master/buildin/module.js#L10

@jdalton

This comment has been minimized.

Copy link
Contributor

@jdalton jdalton commented Sep 27, 2016

jQuery, Lodash, Ember, Angular, Prototype, React, & h5bp have already dropped IE8 support and Microsoft really only supports IE 11 and Edge now.

I think dropping IE8 support is a fine thing for Webpack 2.
With that Webpack 2 can update its buffer dependency to v5 too!

@breeswish

This comment has been minimized.

Copy link
Author

@breeswish breeswish commented Sep 28, 2016

ok here is my idea. I think at least the most commonly used part (in this case, the module) should be compatible with ALL JavaScript
enabled, a-well-accepted-standard implemented browsers.

I don't care about buffer. Those things come from Nodejs, which is not expected to work in browser before webpack. Webpack make it work in browsers. Good. with a browser version requirement. Accepted.

Webpack is only a module bundler, acts as a build tool chain as well nowadays. It should not make working things doesn't work any longer in the same environment. I think this is as unreasonable as gulp or grunt doesn't support ES3.

In addition, browserify supports IE8 and its core functionality (I mean, without Nodejs polyfills) can even work in IE6.

@jdalton

This comment has been minimized.

Copy link
Contributor

@jdalton jdalton commented Sep 28, 2016

@breeswish I totally hear ya, but IE8 is a dead browser on a dead OS. You can check out the discussion/stats on the h5bp thread. At some point projects have to move on and a major bump is a good time for them to do that. For legacy support you can always use Webpack v1.

@breeswish

This comment has been minimized.

Copy link
Author

@breeswish breeswish commented Sep 28, 2016

Thanks I agree with that. It is dead. It should be replaced. However I would like to express my thoughts: what webpack should do is to bundle modules. what it shouldn't do is to make working things not working. Even babel won't break existing working code.

@jdalton

This comment has been minimized.

Copy link
Contributor

@jdalton jdalton commented Sep 28, 2016

@breeswish

Even babel won't break existing working code.

Major bumps avoid breaking working code as long as your dep ranges are following semver. Babel has introduced several breaking changes on their major version bumps (that's the primary reason for them).

@breeswish

This comment has been minimized.

Copy link
Author

@breeswish breeswish commented Sep 28, 2016

Sorry I'm not expressing clearly. I mean, by design, a toolchain which act as a transformer should not break working things. Even babel (any version) won't make my ES3 code not working any longer. It does clearly what it should: make ES5+ code compatible with ES5. It doesn't introduce side effects. In addition, it can be compatible with ES3 even when the code is using some modern ES5+ features.

@jdalton

This comment has been minimized.

Copy link
Contributor

@jdalton jdalton commented Sep 28, 2016

@breeswish

Babel is kinda a poor example. Babel v6 preset-es2015 lacks IE8 support out-of-the-box and
will generate code that doesn't run in it.

Why not stick with Webpack v1 for unsupported browsers?

@breeswish

This comment has been minimized.

Copy link
Author

@breeswish breeswish commented Sep 28, 2016

Yes that's why I am using the term "some". ES modules won't work in ES3, out-of-the-box, when using es2015 preset. However by using other plugins it can be achieved. Babel itself doesn't introduce side effects. Can webpack 2 supports ES3 by using other plugins? No, because webpack 2 itself introduce unavoidable side effects.

It solves my issue by using webpack 1. But eliminate webpack 2 side effect is another thing. I would like to treat this issue as a design or implementation mistake in webpack 2.

@jdalton

This comment has been minimized.

Copy link
Contributor

@jdalton jdalton commented Sep 28, 2016

@breeswish

That's a design issue.

I donno, I see putting the burden on Webpack v2 to support dead environments as an issue.
Heck, you could always run a post-process on your code to replace the bits IE8 has problems with. Trying to push a niche concern like this on Webpack doesn't seem so great.

@breeswish

This comment has been minimized.

Copy link
Author

@breeswish breeswish commented Sep 28, 2016

@jdalton Sorry but in fact it is really hard to run a post-processor. As said before, only some of the ES6/ES5 feature can be transformed to be compatible in ES3, which means for the rest of the features it is difficult. Unfortunately, getters and setters are one of those hard to be post-processed: https://github.com/webpack/webpack/blob/master/buildin/module.js#L10 It might me more approachable to fork a ES3 compatible version of webpack2 (or fix it in the master branch) than writing a post-processor.

@breeswish

This comment has been minimized.

Copy link
Author

@breeswish breeswish commented Sep 28, 2016

In fact according to NetApplications or StatCounter (the two most authoritative stat), IE8 is the second most popular browser in IE family and has a market share larger than 2%. 2% is not small. It is even larger than Windows Phone market share. Besides, according to NetApplications IE 8 is even the 3rd popular browser in global and has a market share 6.25% in the last year. In my own opinion the data of NetApplications should be more accurate because StatCounter doesn't take Internet blocking (for example China) into account and the samples of China is significant (700 million, 22% of the global). In addition, according to China's largest search engine Baidu (notice that Google is not accessible in China), in China IE8 has a market share more than 16%, which is the second most popular browser.

In short, IE 8 is not a dead environment, especially in some countries, for example, China, which has the MOST netizens in the world.


I see putting the burden on Webpack v2 to support dead environments as an issue

Let me explain my core idea: webpack is not a library. It is a toolchain. A toolchain should introduce minimum side effects to projects using it. That's it. It should not make working code not working, especially due to some completely avoidable issues.

The idea of only supporting environments you willing to, is applicable for a toy project. It is not applicable for an engineering project.

@jdalton

This comment has been minimized.

Copy link
Contributor

@jdalton jdalton commented Sep 28, 2016

@breeswish

Sorry but in fact it is really hard to run a post-processor.

Naw, it's not. Write a simple Node script to load your bundle and regex parse out the bits.
Get as hacky and as creative as you'd like.

In fact according to NetApplications or StatCounter

Seems a bit like cherry-picking.
The h5bp thread linked from earlier shows a majority of stats report super low usage.

In short, IE 8 is not a dead environment, especially in some countries, for example, China, which has the MOST netizens in the world.

I believe no matter where you are there's access to other browsers. I recommend directing users to alternatives. Folks still on IE8 are getting an increasingly degraded experience. There's no place in today's toolchains for a ~8yr old unsupported browser of a ~16yr old unsupported OS.

The idea of only supporting environments you willing to, is applicable for a toy project. It is not applicable for an engineering project.

You're free to use whatever tool you want, including Webpack v1. As mentioned, projects like jQuery, Lodash, Ember, Angular, Prototype, React, & h5bp have already dropped IE8 support. Even Uglify defaults to "screw-ie8" enabled and I'm sure if they were version bumping they'd be up for dropping it entirely. I know dead environments are a total bummer, but the burden of supporting them is on you and not modern toolchains.

@sokra

This comment has been minimized.

Copy link
Member

@sokra sokra commented Sep 29, 2016

If this code fragment is the only issue for ie8, feel free to find the commit changing loaded to l and id to i an revert it in a PR.

But keep in mind that the whole es modules stuff is based on getter an won't run on ie8. CommonJs may work.

@jdalton

This comment has been minimized.

Copy link
Contributor

@jdalton jdalton commented Sep 29, 2016

@sokra

So you're up for larger bundles, for everyone, for partial IE8 support (maybe cjs; no es-module)?
Did the partial revert from April nix most of the size wins?

@breeswish

This comment has been minimized.

Copy link
Author

@breeswish breeswish commented Sep 29, 2016

@jdalton I prefer to provide an opt-out for a fallback, like loose mode in babel or other modules. Besides, the size advantage by replacing longer words into shorter ones is minimum when gzip is applied.

@jhnns

This comment has been minimized.

Copy link
Member

@jhnns jhnns commented Oct 3, 2016

Sorry, @sokra but I don't think we should do that.

It may be just this little code line for now, but will future changes also be tested on IE8? If we do support IE8, we must ensure that all future changes also do support IE8. That's where I agree with @jdalton: A major version bump is the time to move on.

Shipping code for IE8 is irresponsibly because there are no security fixes for this browser + OS anymore. The web should look broken for them.

@tpizza

This comment has been minimized.

Copy link

@tpizza tpizza commented Nov 9, 2016

While I agree for the most part in regards to not supporting IE8 there is still a considerable subset of web applications which still have to support IE8. It sucks, I know first-hand, heh.

I mean, sure I can hang back on v1.13, but ideally it would be nice if output at least remained functional...or at least offered some sort of configurable settings for enabling ES3 compliant output. If this does not happen, I totally get it since IE8 support is such a costly endeavor, but it would be nice to be able to continue to drive Webpack adoption across some of my other teams who do not have a choice but to continue supporting that ugly abandoned browser. I've been pushing to try and sunset IE8 completely and at least bump to 9+, but in the B2B world...that burn can be too slow!

@jdalton

This comment has been minimized.

Copy link
Contributor

@jdalton jdalton commented Nov 9, 2016

@tpizza

I mean, sure I can hang back on v1.13,

I'm glad you see that as an option & are understanding. Doors everywhere are closing on IE8.
It had a good run, but there's really no going back at this point.

@sokra

This comment has been minimized.

Copy link
Member

@sokra sokra commented Nov 14, 2016

After some discussion we decided for the following statement regarding IE8:

We don't support IE8 in webpack 2. IE8 is not supported by Microsoft and doesn't get security fixes. We think it's no responsible to allow web developers to build webapps which support IE8. They must break!

@sokra sokra closed this Nov 14, 2016
@drewfreyling

This comment has been minimized.

Copy link

@drewfreyling drewfreyling commented Feb 26, 2017

"With that Webpack 2 can update its buffer dependency to v5 too!"
@jdalton - to be clear that would remove IE9 and IE10 support too (Which browserify has done as of v14).

@csvan

This comment has been minimized.

Copy link

@csvan csvan commented Mar 10, 2017

Rejecting this was a great move. Any effort to enable IE8 to keep existing is utterly irresponsible and ultimately detrimental to developers and users alike.

@ericyang89

This comment has been minimized.

Copy link

@ericyang89 ericyang89 commented Mar 30, 2017

i meet the same issue as breeswish ...
save life, drop IE8!

@jeromelecomte-okta

This comment has been minimized.

Copy link

@jeromelecomte-okta jeromelecomte-okta commented Nov 1, 2017

IE8 as a standalone browser is dead, no disagreement here. But the issue is embedded browsers such as the one used by Microsoft Office 365 which behaves like IE6. When you ship JS code that has to run in that environment (e.g. authenticating your user against an identify cloud), Webpack is no longer a viable option, which is unfortunate.

@jdalton

This comment has been minimized.

Copy link
Contributor

@jdalton jdalton commented Nov 1, 2017

I believe the HTML engine in Office is equiv to at least IE9+.

@jeromelecomte-okta

This comment has been minimized.

Copy link

@jeromelecomte-okta jeromelecomte-okta commented Nov 1, 2017

Interesting, what's your source please?

@jdalton

This comment has been minimized.

Copy link
Contributor

@jdalton jdalton commented Nov 1, 2017

@jeromelecomte-okta I made an Office agave/add-in probably ~2yrs ago and I seem to remember it being IE9+. I also did a quick search and turned up this. It's also the min bar noted here.

@inferpse

This comment has been minimized.

Copy link

@inferpse inferpse commented Nov 1, 2017

@jeromelecomte-okta webpack is very flexible and it’s possible to create a plugin which will “downgrade” webpack2+ generated source to support ES3 environment.

Of course it is a dirty and unreliable way which could break in any next release
but it’s possible and here’s the PoC plugin which resolves that:
https://github.com/inferpse/es3-harmony-webpack-plugin

@jeromelecomte-okta

This comment has been minimized.

Copy link

@jeromelecomte-okta jeromelecomte-okta commented Nov 13, 2017

Thanks for the info

@jeromelecomte-okta

This comment has been minimized.

Copy link

@jeromelecomte-okta jeromelecomte-okta commented Nov 28, 2017

@jdalton for reference, this is the source I had found hinting Office 365 embedded browser was closer to IE7 than IE9: https://weblog.west-wind.com/posts/2011/May/21/Web-Browser-Control-Specifying-the-IE-Version

@jdalton

This comment has been minimized.

Copy link
Contributor

@jdalton jdalton commented Nov 28, 2017

No worries, it's not IE7.

Update:

Spoke with an Office dev, I work at Microsoft, and while the official support target is IE11+, the actual engine is a modified IE9+ at the moment.

@pauldwaite

This comment has been minimized.

Copy link

@pauldwaite pauldwaite commented Nov 29, 2017

@jdalton

I believe no matter where you are there's access to other browsers.

Lots of users don’t get to choose what browser they run. I’m currently working on a project for internal UK government users, all of whom get a locked down computer to work on, running IE 8.

In addition, many of them don’t know what a browser is, let alone how to upgrade one.

@csvan

This comment has been minimized.

Copy link

@csvan csvan commented Nov 29, 2017

That is true, but perpetually supporting dead browsers and environments is detrimental to the overall progress of both technology and society. Institutions need to understand that maintaining their IT infrastructure matters.

@pauldwaite

This comment has been minimized.

Copy link

@pauldwaite pauldwaite commented Nov 29, 2017

@csvan sure. I don’t think anyone’s saying dead browsers should be perpetually supported. I think we’re saying IE 8 is not dead yet.

@csvan

This comment has been minimized.

Copy link

@csvan csvan commented Nov 29, 2017

IE8 is dead because it is officially (way) past its EOL, no longer maintained by anyone, and no longer a viable option for new development - not because there are pockets of the market who still use it.

@pauldwaite

This comment has been minimized.

Copy link

@pauldwaite pauldwaite commented Nov 29, 2017

@csvan it’s past EOL and no longer maintained, sure. When I say it’s not dead, I mean it’s still in use enough to warrant consideration by projects that build for the web.

And the outcome of that consideration can totally be “We don’t support it.” I personally find that disappointing from a tool that transpiles web code to work on older browsers, but it’s a valid position.

@jdalton

This comment has been minimized.

Copy link
Contributor

@jdalton jdalton commented Nov 29, 2017

@pauldwaite

When I say it’s not dead, I mean it’s still in use enough to warrant consideration by projects that build for the web.

There isn't enough use to warrant consideration for webby projects anymore. This is why the JavaScript ecosystem, as a whole, has moved on. If you're disappointed you can always use older versions of all the tools and libraries in the ecosystem, but it's unreasonable to demand support for it at this point.

@Justineo

This comment has been minimized.

Copy link

@Justineo Justineo commented Jan 6, 2018

A little off the topic: I want to point out that users are not always able to choose the browsers they use. Like here in China, many students/teachers/doctors/…, they use computers provided by their schools/hospitals/governments/…, which might receive a system image recovery everyday to prevent malware/virus/…, especially for poverty areas, where many schools are built with donation so they have rather limited resouces to replace computers/OS. Many of these people have to use outdated browsers like IE8, even down to IE6. So I wouldn't put supporting legacy browsers as “irresponsible”. China's largest search engine still supports IE8, just to take care of those people, letting them have a chance to connect to the outside world. The good news is the market share of these legacy browsers are continiously going down, which helps Chinese developers to move on. I'm not saying webpack should continue to support legacy browsers forever, but please understand there might be a reason behind every developer who has to do so at the moment.

@haishengwu-okta

This comment has been minimized.

Copy link

@haishengwu-okta haishengwu-okta commented Oct 19, 2018

just in case people search google and find this thread, this is how I solved at webpack 3 by updating the babel config.

presets: [
    ['es2015', {'loose': true} ]
],
plugins: [
    'transform-es3-member-expression-literals',
    'transform-es3-property-literals'
]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.