1. 29
  1. 7

    I can get on board with some version of this, but the particular filter recommended is pretty aggressive imo. According to the linked stats, the filter of “>0.25% market share, not ie 11, and not opera mini” covers only 87% of web traffic. Having your site break on one out of 7 visitors is a pretty high failure rate!

    If you instead used the filter “>0.1%”, it would cover 95% of traffic, which is at least a bit more reasonable imo.

    1. 7

      If your site is so dependent on JavaScript that it doesn’t work at all in browsers that get shut out by "browsers": [ ">0.25%", "not ie 11", "not op_mini all" ], I would suggest that your problem isn’t with your implementation but with your design.

      1. 2

        Sure, you should make your site not be JS-dependent in the first place. But then you don’t need any of this polyfill stuff at all! If the JS is only for optional functionality, you can just write whatever recent dialect of JS you want directly. I’m assuming that people who use stuff like babel and polyfills are doing so because their site actually needs the JS to run, so they need to translate it to maintain compatibility with a range of browsers. And in that case, I think you might as well aim for a wide range of compatibility while you’re at it.

      2. 2

        One could automatically create optimized bundles for the different browsers, and send the appropriate one to the browser, according to the User-Agent HTTP header.

        But unfortunately, the ethics of accessible, diverse and welcoming web contents has long gone.
        Now the web is platform and a product, and people should just buy the stereotypical industrial offer.

        Please visitor, conform!

        1. 1

          according to the User-Agent HTTP header

          This is a bit of a problem, since browsers like to identify as other browsers (think “request desktop site” in mobile browsers, or browsers with a small market share), but they don’t execute JavaScript the same way that the browser they pretend to be does.

          1. 1

            Well, if you even want to support cheating users (:-D) just include a browser detection script first, and then include the proper bundle.

            I think the matter is pretty simple technically.

            The fact is that most companies don’t think user’s freedom has a value because they can’t profit from it.

            So why test for that weird 13% that insists to be different?

            IMHO, intranet enterprise applications are the only case in which such optimisation makes sense.

        2. 1

          This is where good defaults come in. I don’t think this is the sort of thing that a developer should be configuring at all, unless there’s a specific browser that they need to support.

        3. 6

          It’s rapidly approaching the point where every blog post/tweet/article about JS development makes me just go “huh, wat?”

          I used to work for an agency of sorts, and “custom” javascript (i.e. something more complex than can achieved by a few lines of bootstrap and some jquery plugins) was one of the things I became (one of or the, depending on timing) goto guy(s) for when projects needed help.

          This concept of “we can automatically support browsers of ridiculous age, but choose not to” is fucking mind boggling.

          Maybe the current frontend dev community is too many years removed from a true monopoly on browsers, (and hasn’t opened its eyes enough to realise the risks of the coming monopoly).

          1. 1

            This concept of “we can automatically support browsers of ridiculous age, but choose not to” is fucking mind boggling.

            But that’s not what is happening. Babel can provide automatic syntactic support for those older browsers. But it does not provide automatic runtime support. And it is extremely likely that one’s dependencies won’t support those older browsers. In most cases, the automatic syntactic support provides no actual benefit to the users of those older browsers, but does incur a cost to everyone else.

          2. 6

            I… what? Why would you disable support for browsers when that support is automated? The mind boggles.

            1. 5

              To reduce app size and download times. 4G LTE with unlimited data access isn’t ubiquitous.

              1. 4

                I guess so. Seems like the size reduction would be pretty small compared to making the app better

                1. 2

                  Depending on the browsers in question, it can actually make a pretty significant difference. And if, for example, you are making a web app for businesses which has very clear specs about what browsers you are willing to support, you should definitely ship the smallest JS bundle possible for the supported browsers.

            2. 4

              Their design on this is so good imho

              1. 6

                It’s pretty but it hurts my eyes to read

                1. 1

                  I have slight dyslexia. I am quite sure that headache from reading that site is not worth it.

                2. 2

                  I bet if you were in the group

                  "browsers": [ ">0.25%", "not ie 11", "not op_mini all" ]

                  it would really look awesome. Time to upgrade! ☺

                3. 1

                  What is the good practice for making builds reproducible when using babel-preset-env’s relative queries? When trying to debug an issue in an older (but still supported) version of a library, is there a way to build it using historic browserslist data? Perhaps some sort of a browserslist lock file?