opentypejs / opentype.js

Read and write OpenType fonts using JavaScript.
https://opentype.js.org/
MIT License
4.36k stars 467 forks source link

The variable font code uses Proxy, a non-polyfillable ES6 type. #716

Open ILOVEPIE opened 1 month ago

ILOVEPIE commented 1 month ago

The variable font code uses Proxy, a non-polyfillable ES6 type, preventing opentype.js from being transpiled to anything lower than ES6.

Expected Behavior

In order to implement a legacy/compatibility build this code must be reworked slightly to remove the dependence on Proxy.

Current Behavior

While most JavaScript features can be polyfilled for older browsers, proxy is one of the few that cannot. Even SWC and Closure Compiler cannot polyfill this feature.

Possible Solution

Don't use Proxy, it doesn't add any significant amount of code to avoid it.

Context

This is blocking #693

Connum commented 1 month ago

There's es6-proxy-polyfill on npm and https://github.com/GoogleChrome/proxy-polyfill - why can't we use that? Using proxies has the advantage of triggering recalculations automatically for example.

ILOVEPIE commented 1 month ago

We can use it if we directly add support for the polyfill into our code, but it's not a true polyfill for it, it's more like a workaround. The only way to truly polyfill it is the non-standard and deprecated Object.observe().

Connum commented 1 month ago

Mhh, what is a "true" polyfill for you?

ILOVEPIE commented 1 month ago

A polyfill is a piece of code that replicates the functionality of a feature using other older features. In this case, the chrome polyfill doesn't work in all cases.

The polyfill supports just a limited number of proxy 'traps'. It also works by calling seal on the object passed to Proxy. This means that the properties you want to proxy must be known at creation time.

Currently, the following traps are supported- get set apply construct

ILOVEPIE commented 1 month ago

We could use it though, it's just we have to be careful about the traps used, and how we use it.

axkibe commented 1 month ago

Is this backward compatibility really necessary? Nowadays users need to have a relativly recent browser due to security dangers anyway. If polyfilling is possible without much effort I'm all to it, if it put additional constraints on development I'd give it a no to waste time and effort on it.

ILOVEPIE commented 1 month ago

Is this backward compatibility really necessary? Nowadays users need to have a relativly recent browser due to security dangers anyway. If polyfilling is possible without much effort I'm all to it, if it put additional constraints on development I'd give it a no to waste time and effort on it.

A lot of smart TVs and other embedded browsers use old versions of chromium and webkit. For compatability with such devices this is needed.