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

Change last n version scheme to include all browsers listed on caniuse #98

Closed
hexalys opened this issue Jan 1, 2017 · 16 comments
Closed

Change last n version scheme to include all browsers listed on caniuse #98

hexalys opened this issue Jan 1, 2017 · 16 comments

Comments

@hexalys
Copy link

@hexalys hexalys commented Jan 1, 2017

As previouly mentioned for autoprefixer usage. Consider including current browsers with large market share such as Opera, UCBrowser etc.. (now classified as minor browser) as supported, by the n version scheme.

e.g. 'last 2 versions' should include Opera Mini, UCBrowser and Firefox for Android, Samsung...

@ai
Copy link
Member

@ai ai commented Jan 1, 2017

I think we should do it.

But because it is major change, let’s wait for a while.

@ai
Copy link
Member

@ai ai commented Jan 1, 2017

@hzoo are you agree with this changes? It will affect to babel-present-env too.

@TCotton
Copy link

@TCotton TCotton commented Jan 3, 2017

That seems to be a big (breaking?) change. Opera Mini has a "pick'n'mix" approach to CSS features. Few of us write code with that browser in mind (whether we should or not is a separate discussion). I don't know how this would work in practice

@ai
Copy link
Member

@ai ai commented Jan 3, 2017

@TCotton sure, it will be a major release for Browserslist and for Autoprefixer.

@ai
Copy link
Member

@ai ai commented Apr 17, 2017

Done 0e145a6

@ai ai closed this Apr 17, 2017
@ebidel
Copy link

@ebidel ebidel commented Apr 17, 2017

Just to play devils advocate...

I wonder if 0e145a6 will have a greater negative impact than a positive one? IOW, tons of people use latest n versions and will continue to do so after a major release. With this change, they're going to be potentially pushing 3-4x more bytes per CSS feature and never realize it. Extrapolating that out to a large CSS file could mean significant delays to first paint and other page load metrics :(

The feature differences between the latest major browsers and all browsers can be large. Would it make more sense to support a (new) opt-in query?

@ai
Copy link
Member

@ai ai commented Apr 17, 2017

@ebidel prefixes are very easy task for gzip. I think bundle sizes become bigger only in 1-5%.

@ebidel
Copy link

@ebidel ebidel commented Apr 17, 2017

Very true about gzip. It would be interesting to real numbers from the wild. 26% of the web still doesn't compress responses.

More bytes are more bytes :)

  • larger responses cause more decompression work, increased memory, cpu time, etc.
  • larger responses increase issues with browser caching.

Mobile makes all of this worse. I've seen the HTTP cache take anywhere from 50-100ms to return a fresh asset on a Nexus 5 (no network cost). That's also without main thread contention. I'd imagine that number grows with resource size and main thread contention but haven't looked at that closely.

@ai
Copy link
Member

@ai ai commented Apr 17, 2017

@ebidel maybe real benchmark will be better. Could you take your companies CSS and compare size for current behaviour and new behaviour (you can emulate 2.0 behaviour by last 2 chrome version, …).

In my experience, inline images and gradients is the biggest part of CSS.

@ebidel
Copy link

@ebidel ebidel commented Apr 17, 2017

I don't really have a meaningful file to test with. Something like a news site might be interesting and representative. I'll try to through in some time, but things are pretty busy between now and prepping for Google I/O.

@ai
Copy link
Member

@ai ai commented Apr 18, 2017

@ebidel I compared (minified, no gzipped):

  • last 2 versions of any main browsers: 276,9 KB
  • last 2 versions of all browsers: 287,8 KB.

Just 4% of extra size. I think it is very good price for Internet which will be ready for any browsers (it is sad that most developers ignores browsers not popular in US, but have big market in other countries like Opera or Chinese browsers).

@ebidel
Copy link

@ebidel ebidel commented Apr 18, 2017

Nice! Thanks for looking into some numbers in a large stylesheet. I think you're probably right about the 4%. There are bigger performance bottlenecks on the web. ~10kB is pretty chill in the grand scheme of web bloat :)

@Jessidhia
Copy link

@Jessidhia Jessidhia commented May 9, 2017

Very late comment, but some notes:

  • babel-preset-env does use browserslist for calculating supported browsers, but it only uses data for a specific list of browsers (https://github.com/babel/babel-preset-env/blob/20ddb722/src/index.js#L49; if it's not in this object, it's ignored).

  • matching all browsers with last n versions can make some linters like doiuse very angry and possibly impossible to use without restricting the matched set.

@ai
Copy link
Member

@ai ai commented May 9, 2017

Yeap, it is too late 😅

@zslabs
Copy link

@zslabs zslabs commented Jun 1, 2017

👋 Coming over from postcss/autoprefixer#838, is there a setting we could use to get back the major browsers only that were supported previously? Thanks!

@ai
Copy link
Member

@ai ai commented Jun 1, 2017

Nope, because previous behavior is a bad practice in general.

In if you want it, write browsers by name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants