search

w3ctag / polyfills

Finding on polyfills
https://w3ctag.github.io/polyfills
18 stars 6 forks source link

A Disappointing Document #8

Closed WebReflection closed 7 years ago

WebReflection commented 7 years ago

I've been asked to provide my feedback and here I am.

Some Background

In 2006 I've written my second version of the JavaScript Standard Library, where the first one was bringing standard ECMAScript down to IE4, the one without even try/catch statements.

I've been writing polyfills forever and I've felt like contributing to move the Web forward for the last 15 years.

When I've read this document I couldn't believe how offensive it could result for passionate developers that spent time to contribute to the Web platform.

Instead of blaming slow standardization process and admitting mistakes from same browsers vendors, this document puts all the blame to Web Developers, also advocating some non-sense or misinformed bad practice.

Hence my following reaction.

About Feature life cycle

From a practical standpoint, the development of web platform features goes through a number of distinct phases

In ECMAScript land, we eventually ended up in a list of stages, which makes it clear to anyone about the risk in adopting any of the proposed new features. It would be awesome if developers could have a central place, web page, repository, to understand the stage of a proposal for the web.

Risks of premature polyfilling

Any JavaScript library ... risks creating problems for the development of the Web

Most of the ECMAScript 5 has been agreed after one or more libraries that were polluting global objects prototypes have been adopted by the majority of the Web Developers.

This means that standard bodies eventually listened to developers and embraced their patterns, covering their most important users use cases, instead of blaming them.

This is quite the opposite scenario of what you wrote here:

If that library becomes widely available, and used, prior to the standardisation and implementation of the feature it seeks to create or emulate.

You took Mootools as example saying that since many developers loved and used its Array.prototype.contains pollution, standards had problems replacing it with something else.

Am I the only one seeing that the real issue is that standard bodies didn't check what user-land liked, and needed, before deciding it was OK to start shipping such method?

They've been obtrusive in the other way round and only Mootools ever took the blame for it.

I am not saying polluting globals is OK, but sometimes if something is convenient for everyone and widely adopted, it's not necessarily a bad thing or something to avoid at all costs.

During the evolution of Web Components, Google created a polyfill for createShadowRoot.

This document also states that browsers vendors and teams behind are "the best" to avoid security issues and stuff.

Polyfills are generally not written by browser vendors, and may not have the infrastructure or support network of a major project, leading to potential security concerns.

So, developers shouldn't create polyfills because browsers vendors team "are better", but browsers vendors can seppuku new standards like createShadowRoot ?

About requestAnimationFrame

Today, Microsoft Edge also recognises webkitRequestAnimationFrame despite not being a webkit browser, in order to maximise their compatibility with sites originally optimised for the iPhone.

What have Web Developers to do with the IE decision to emulate other browsers in order to not being seen as a browser that "doesn't work"?

You are telling the wrong story here, let me recap how the Web evolved in the last 10 years:

... and this document seems blames Web Developers about last point?

I don't remember Chrome or Firefox, putting an MSIE in their UA back those days, while IE still has Mozilla in its UA string, right?

About Nomenclature

Although 'polyfill' has come to be a well understood and recognised term, its etymology is obscure and culturally specific to the UK.

This same document is written in UK language, take recognised as example VS recognized, but the problem in this point is the confusion you have with terminology Web developers understand already.

You know, they learn daily new things by job specification so, an extra term isn't usually such a big deal (they are smarter than you think).

However, let me help you with other terms:

Telling developers they should use ponyfill only as a term, is helping pretty much nobody in understanding important differences between these libraries.

If I can dare, you are basically causing functional analphabetism on one of the most important aspect of the Web, and its movign forward, with this single point.

About Security Concerns

This point is the one that disappointed me the most.

I'll explain you why after reminding this part:

Consideration should be given to whether excessively large polyfill bundles place a punitive cost burden on users with the least ability to pay that cost: those with older devices which may be on metered connections paying for data in very small increments.

It's about 2+ years I am polyfilling and fighting in favor of Custom Elements is="" attribute feature in order to keep promoting graceful enhancement, and one browser vendor is pushing back without providing any valid alternative.

As a developer, I want to support every device on this planet and use graceful enhancement, but they want me to redirect, I guess behind some User Agent sniffing and on the server side, since your proposed robust feature detection goes nowhere in the real world out there.

I should provide another version so that the already slow device, with slow DNS resolution too, needs more effort for an ad-hoc site created for too old browsers, and my company has to pay extra time for its development.

This is because Custom Elements cannot, and should not, be polyfilled for too old devices but current specification requires mandatory polyfills and, on top of that, transpilers for classes that are holding back modern browsers instead.

As result, today we transpile for old browsers that will never be able to use modern Web features, requiring polyfills on top, and penalizing modern browsers that would benefit the most from not transpiled code and probably no polyfills as well.

So how about suggesting and promoting best practices such graceful enhancements instead, including the already old device friendly solution that custom elements the is="" proposal provides?

Moreover ...

Polyfills are generally not written by browser vendors,

Actually they are people writing most polyfills since they are even paid by their companies for doing that.

and may not have the infrastructure or support network of a major project, leading to potential security concerns.

Throwing security concern if you are "not a cool dev" is demoralizing anyone that simply needed a bloody standard feature and decided to waste time to Open Source, and publish, a library that fixes that gap and is useful for others too.

Open Source also works in a way that anyone can contribute to a library so the team number means pretty much nothing if developers collaborate.

So what is the point of telling developers if they want to polyfill something they shouldn't because they are not better than browsers vendors team?

These concerns are amplified if the polyfill acquires wide adoption, which may leave many unconnected sites vulnerable to the same security exploit.

Both Mozilla and Google use my polyfills here or there and I've never been a browser vendor developer.

About UMD

There is ES6 with its import and export and CommonJS. Everything else lost the battle every single time.

UMD causes that useless extra amount of file sizes mentioned somewhere else about polyfill sizes or old devices and payed data.

I'd drop AMD and UMD; it' sabout the time the Web agrees with its own proposal, import and/or import() and eventually suggests one extra standard which is de-facto standard everywhere else outside the W3C and the front end Web browser: require

About Don't create globals with common names for speculative polyfills

The hint here is hilarious. It reads like: don't create global variables that represent a fix for an API that's been proposed at W3C, feel free to pollute the global scope with any sort of fancy name you like. Who cares about conflicts and global scope pollution, right?

How about suggesting modules and nothing else? Anyway ...

If a feature has not passed the tipping point, do not squat on the common, expected or likely name (whether it's a property of the global object or of a global constructor/prototype). Consider prefixing or changing the common name, or appending 'polyfill'. For example, if an upcoming feature is likely to be called window.API, consider attaching your polyfill to window.AlmostAPI or window.APIPolyfill.

Web Developers know that global pollution is bad, period. The moment you decide to do that, is because you want to use that API that is cool but not widely implemented yet.

More on that:

If the feature is a method of an existing global prototype, do not create that method for features that have not passed the tipping point. Instead, consider creating a standalone function, e.g. doTheThingPolyfill(element) instead of Element.prototype.doTheThing.

There is this thing that is always painful for companies when it needs to be done: refactoring.

If companies understand something is going to be standard, they don't want to produce code that will need to change once the thing is standard.

Companies want to produce code that after N+ years will remove the single polyfill dependency needed for that bit and make everything natively fast: profit!

That is the whole purpose of a real polyfill: you have it there but you don't want to think about it until the day you just remove it (or you need an obvious update).

It's a top level ghost dependency that is transparent for everything else where code is expected to run as if it was native, without bothering more.

TL;DR: Polyfills are just like transpilers, one day you'll remove them, that's the deal!

About the short or generic names joke ...

Do not by default use incredibly short or generic names, such as $, root or web.

Open your browser, go about:blank, open the console and type $. If you are on Chrome, you'll see a polluted environment with stuff nobody asked for.

Are browser vendors also better than normal Web Developers at deciding utilities?

And that $ is not even jQuery ...

About Not Serving Polyfills Not Required

Pick realistically your poison:

Uh wait, that's actually what's being suggested:

Consider using techniques such as feature detection in the browser to dynamically determine which polyfills to use, or User-Agent based browser identification to do so on a server.

So we are now telling Web developers to use UA sniffing because ... that's robust?

And this has nothing to do with the issue Microsoft and IE had when its browser was badly sniffed out, right?

About Considering Alternatives

That's, as example, is called Custom Element native extend, it's being put on hold without providing alternatives by some vendor.

That's instead holding back modern browsers and the Web, 'cause developers just transpile without targeting. Today, as example, that means that most JavaScript class out there are plain broken.

Fair enough, but I believe this is a bad advice for PAs since it's easy at this point to say "hey, I'm following best practices so I don't need to support your cheap Android they still sell".

About Updating Polyfills

Keep the polyfills that you host up to date. If practical, push updates directly to your customers, otherwise encourage them to move to the latest version.

I have no idea why this point is in this document since you are suggesting npm, which is based on samever, so that we, authors, should just follow common best practices to prevent surprises like push/forcing an update to anyone else.

About Collecting data

collect information about which polyfills are most popular ... and send that information to the appropriate parties.

This has been proven to have mostly zero real-world effect on how standards get adopted, proposed, or implemented, unless you are part of standard bodies.

About Not bundling dependencies ...

If you offer a service that bundles multiple polyfills together, make sure people using the service are able to easily find out which polyfills are being included

WebComponents from Google has been delivered with highly obtrusive WeakMap broken polyfill for years now, they are those secure browsers vendors team mentioned before.

As Summary

It would be great if standard bodies would stop feeling superior and actually start confronting reality with Web Developers.

The same history of the Web is full of failures and contradictions and in this document it looks like somebody thinks it's all Web Dev fault but we all know it's not.

So, thank you for creating more reasonable, informed, humble, and improved specifications for your most valuable customers: Web Developers.

Best Regards, from a Web Standard supporter since about ever.

torgo commented 7 years ago

Andrea - first of all thank you for taking the time to write this feedback. It is always valuable to receive well thought-through and well written feedback like this, whether negative or positive. Without getting in the substance of what you've written: what I would like to be able to is to decompose your feedback inti individual issues that can be discussed separately. I believe this will help make the document in question as good as it can be (which is our major priority) and will help to separate issues we can address from more general ecosystem issues that may be out of our scope. It may seem like make-work but I think it will really help. Can I ask you to do this decomposition? Otherwise I can do it. In any case, we will be taking up these issues and addressing them. Thanks, again.

torgo commented 7 years ago

The substantive issues that we have found in this text have been moved to separate issues and linked to this one. It would be useful to us if in future feedback you raise each point as an independent issue, and please also see our code of conduct.