add a build which includes polyfills for IE

[XhmikosR]

Since this is basically a development tool, I need to test things on IE11.

The current builds target explicitly only 3 browsers. That's way too strict IMO. It's just ~30% of the global market, see https://browserl.ist/?q=last+2+Chrome+versions%2C+last+2+Firefox+versions%2C+last+1+Safari+version%2C+not+dead

Please consider using a more lax config, like for example

>= 0.5%
last 2 major versions
not dead

https://browserl.ist/?q=%3E%3D+0.5%25%2C+last+2+major+versions%2C+not+dead

[XhmikosR]

BTW this was introduced in 7d848a6#diff-b9cfc7f2cdf78a7f4b91a753d10865a2R40 and there's no mention in the releases.

[bep]

Note that Hugo currently uses #84 -- I haven't found the time to finish that PR (add tests).

[XhmikosR]

Yup, I figured so from the Hugo git log. :)

That's the commit that introduced this issue because it's based on 3.x which they introduced this breaking change.

[smhg]

I guess it's fine to extend that list. It will impact build size and performance though.
So probably best to avoid browsers that aren't used for development.

[XhmikosR]

Many people test things in multiple browsers and livereload is for development. I wouldn't care so much about performance compared to compatibility here, but it's your project and there's room for changes there.

IMO just adding IE11 will increase the size as much as it gets. The other browsers shouldn't really impact this a lot.

But anyway, let's agree that 30% is just too small :)

[smhg]

Not my project, just helping out :)

I'm definitely ok with IE 11 support. It only indeed more than doubles bundle size. You spend so much time in IE 11? You support other browsers too?

Don't focus on the 30%. That's quite meaningless as mobile support isn't very useful.

[XhmikosR]

I don't actually spend a lot of time on IE but I do test it from time to time to see what works, or when trying to fix something IE-specific. I had actually noticed this earlier but I hadn't dug into it sooner.

…

On Sat, Aug 31, 2019, 19:27 Sam Hauglustaine ***@***.***> wrote: Not my project, just helping out :) I'm definitely ok with IE 11 support. It only indeed more than doubles bundle size. You spend so much time in IE 11? You support other browsers too? Don't focus on the 30%. That's quite meaningless as mobile support isn't very useful. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#85?email_source=notifications&email_token=AACVLNLVQN4AKPYC4LEYVB3QHKLYPA5CNFSM4IST35UKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5TQDMQ#issuecomment-526844338>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACVLNN7TR2K7SR7S4FVL63QHKLYPANCNFSM4IST35UA> .

[smhg]

Am I correct to assume you develop/test first in an evergreen browser? And only test IE once everything works in them?
In that case, do you get much value from livereload in IE? Or are the errors it now (likely) throws the most problematic part?
I'm just trying to get a better picture of your/other's needs.

[XhmikosR]

It's not what I need, IMO. Livereload is a developer tool; it's not used in production. Performance isn't a big issue locally. I mean, most of us don't even minify CSS/JS in development.

As such, it should not have this kind of limitations, IMO. It's way too soon to target these browsers only.

Also, this wasn't mentioned anywhere in the releases nor in README.md. You did make it a major version bump, but still.

[smhg]

This is only about devs testing in IE (9-11). All other browsers are basically covered.
Regular use of IE is about 2%, but browserlist queries are meaningless in this context.

What I'm trying to do is figure out what the benefits are of supporting livereload on IE.
When they are meaningful, we definitely need to add support. If there are very few, it might not be worth it.

These are my current assumptions:

• Probably close to no one develops in IE first.
• Projects that have hard requirements on IE probably have automated tests.
• When IE support is a nice-to-have, IE tests probably take place when things run fine in other browsers. In those cases it is likely about polyfilling one or more things (?).
• Having livereload throw errors on IE is annoying. Do you get any?

Please help me out by filling in the gaps.

Edit: I've added a note about dropping IE support in the 3.0.0 release. Thanks!

[bep]

My 50 cents:

• This library's primary use case is for web development
• If you develop a library that needs to work in IE, you need to do a visual inspection (in addition to any automated tests)
• If you need to debug/fix IE specific issues, you really want LiveReload to help you out.
• I'm pretty sure that most devs understands the above and don't mind some extra bytes from localhost even if they don't care about IE.

[smhg]

If you need to debug/fix IE specific issues, you really want LiveReload to help you out.

I guess that's mostly true in the case of CSS? JS differences with evergreen browsers are about including the right polyfills, no?

I'm pretty sure that most devs understands the above and don't mind some extra bytes from localhost even if they don't care about IE.

Well, that's hard to estimate. In the same sense as whether IE support is a necessity. Let's imagine all the extra IE polyfills would add a 100ms startup delay (random number). This library is used a lot. Altogether that would not be free.

But I guess even only for CSS debugging it's worth it. Maybe a separate build can be a solution.
Let's first make a release with #84 and then add this to 4.0.0.

[XhmikosR]

Unless you have a benchmark, as it is now, we can assume there's no performance hit important enough to bother people who develop with this breakage.

If this wasn't a dev tool we wouldn't be discussing all this, of course.

@bep: we can also just maintain your fork since you already have a custom patch that's not merged.

[smhg]

Unless you have a benchmark, as it is now, we can assume there's no performance hit important enough to bother people who develop with this breakage.

Feel free to clarify why you assume adding +60KB of polyfills has no significant consequences.

If you mean compared to the burden of the IE 'breakage': in the last 5 months, since version 3.0.0, you are the first to report this. This tells me IE use might actually not be that common.

However, with a separate build, if feasible, we can tackle both. As always: PR's are much appreciated.

[AlexWayfer]

I've developing sites for IE11 too, and I test them in it sometimes, but I can live without livereload in this browser. But it can be helpful.

[XhmikosR]

Again, without a benchmark you have no proof, nor do I. Even if I agree that it might be slower, without numbers, this is moot.

You could have at least mentioned this in the release notes or in README.md. It's quite a big assumption to make.

This issue is not about IE. It's about relaxing the browserslist config. People don't always live on the edge. You are even excluding Firefox ESR.

[smhg]

Just to make sure:
The browserlist config only affects the build output (dist/livereload.js), right?
Because I'm not aware of any other consequences it has. If there are, they would of course be important.

To summarize:
If there would be a build with all possible polyfills (e.g. dist/livereload-max.js), would it offer a (proper) solution?

Off-topic:

...and there's no mention in the releases.

Also, this wasn't mentioned anywhere in the releases nor in README.md.

You could have at least mentioned this in the release notes or in README.md.

Please keep issue reports to the point. If you think something can be done better, please contribute. Feel free to contact the owner of the project to take things in a different direction.

Backstory: with the 3.0.0 release, I completed a second attempt to convert the codebase from coffeescript to modern JS. This required a new build process. I chose babel based on a browserlist config I thought would suffice. There was no plan to drop support for anything, I just didn't image livereloading in IE was a thing. I've now added the breaking change in the release notes.