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

Comments

Projects
None yet
6 participants
@hexalys
Copy link

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

This comment has been minimized.

Copy link
Member

ai commented Jan 1, 2017

I think we should do it.

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

@ai

This comment has been minimized.

Copy link
Member

ai commented Jan 1, 2017

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

@TCotton

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

ai commented Jan 3, 2017

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

@ai

This comment has been minimized.

Copy link
Member

ai commented Apr 17, 2017

Done 0e145a6

@ai ai closed this Apr 17, 2017

@ebidel

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

ai commented Apr 17, 2017

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

@ebidel

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

ai commented May 9, 2017

Yeap, it is too late 😅

@zslabs

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

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