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 API to be tree-shaking friendly #53

Open
yanchith opened this issue Jan 21, 2019 · 1 comment
Open

Change API to be tree-shaking friendly #53

yanchith opened this issue Jan 21, 2019 · 1 comment

Comments

@yanchith
Copy link
Owner

yanchith commented Jan 21, 2019

Currently rollup does not attempt to prune class methods due to the dynamic nature of the language, and it seems that even if it did, it would have to be really conservative about it (rollup/rollup#349). This means that our current API does not tree-shake well: Device is a class with a lot of methods that utilize imports from the rest of the library.

This is what the API could look like with plain functions:

import * as gf from "webglutenfree"

const dev = gf.createDevice(); // or gf.createDevice(canvas) or gf.createDevice(gl)
const cmd = gf.createCommand(dev, vertexShader, fragmentShader, options);
const attrs = gf.createAttributes(dev, primitive, attributeData);
gf.target(dev, (rt) => {
    gf.draw(rt, cmd, attrs);
});

We could potentially keep methods that don't make use of imports, or move everything into functions for more consistency.

@yanchith
Copy link
Owner Author

I did some experiments with a really trivial hello world app (basically the triangle example), here are the build size results:

Without tree-shaking optimized API (current master)

125k webglutenfree-app.prod.js
40k  webglutenfree-app.prod.min.js

With tree-shaking optimized API (https://github.com/yanchith/webglutenfree/tree/tree-shakable-api)

84k  webglutenfree-app-treeshake-opt.prod.js
28k  webglutenfree-app-treeshake-opt.prod.min.js

The tree-shaking optimized version is roughly 67% to 70% of the current size, making this desirable to have.

Since the change would be a major API change and the new API would have to be either less straightforward (some operations would be functions, some methods), or less simple (making every operation a function would make it harder to tell which functions are associated with what data types), I won't pursue this for 0.1.0, but may possibly revisit later.

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

No branches or pull requests

1 participant