Decrease the bundle size and the build time
How to use GitHub
- Please use the 👍 reaction to show that you are interested into the same feature.
- Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
- Subscribe to receive notifications on status change and new comments.
Is your feature request related to a problem? Please describe.
The current production build is:
- 47 MB of JavaScript which is VERY huge and much impact page load and UX
- About 200 MB built assets incl. source maps
- ~90-100 seconds of build time which impact CI time and DX
Describe the solution you'd like
✅ Do not make unnecessary browser compatibility
- Currently, we transpile ESNext -> ES5 (before ES2015)
-
- To archive that we use Babel. It is very flexible and supports ES5. But it is slow.
- ES6 and ES5 have a HUGE difference: shorthands, arrow functions, classes, promises, spread/rest operators
- We don't support browsers requiring old ES
Options:
- ✅ ESBuild - superfast and works great for modern ES
- https://github.com/nextcloud/spreed/pull/10055
- 🚧 Vite - uses ESBuild and better in tree-shaking
- Drawbacks: poor performance and poor multi-entrypoint handling
- Draft: https://github.com/nextcloud/spreed/pull/10065
- 🥷 RSPack - a great new but unpopular option :(
- 🐣 Rolldown - still in an early version
🚧 Extract CSS
- https://github.com/nextcloud/spreed/issues/14997
🚧 Remove/replace large dependencies
- https://github.com/nextcloud/spreed/issues/14434
- Lodash
✅ Lazy Load integrations
- https://github.com/nextcloud/spreed/pull/10323
🚧 Lazy load heavy components/libraries
- Audio Encoder
- libphonenumber
🤔 Consider dropping SASS
Many things CSS preprocessors were used for are not relevant now. Modern CSS has modules, custom properties (aka CSS Variables), functions, calc, and even CSS Nesting. To support older browsers we can use PostCSS-Preset-Env. I believe, nowadays the main purpose of using SASS is making a very flexible reusable CSS, like CSS frameworks with grids and utils generations, plugins and etc.
Why use PostCSS processing instead of css preprocessor?
- CSS is a web standard, we can follow standards
- Some features are supported already by most browsers natively
- Other features will be supported in future
- It may follow nextcloud/browserslist-config
Missing feature
The only missing feature is nesting with adding suffixes like
.message {
&__part {
...
}
}
But on the other hand, this adding suffices it's harder to find a style rule by class because there is no message__part in the source.
Build time is better now by moving to ESBuild for transpilling and minifying.
But bundle size is still a problem.