Vime 2.0
Introduction
This "issue" is to layout my thoughts and plans for Vime 2 and for any community feedback. I'd love to hear from people who've actually tried Vime 1 and what they thought (especially what they hated), and what they'd love to see in a media player library.
In all honesty it was my first-time building out a "larger" front-end library. I did it at first because I needed the player for another project and I wasn't happy with existing solutions by modern standards. That motivation slowly transformed into me loving the JS ecosystem and exploring it. I think as most do, I made a lot of mistakes and over-complicated the library on my "first attempt" (not counting few rewrites). Looking back on it now I just keep shaking my head haha. I plan to remedy those mistakes in the next release.
Work will commence on the v2
branch.
Goals
-
Improved developer experience interacting with the library as a consumer and contributor.
-
Maintain great end-user experience by focusing on: aesthetics, accessibility, i18n and UI responsiveness.
-
Component/s API simplification and closer to native DOM implementation (Eg: Subscriptions -> Events).
-
Maintain customization and configuration but in a much simpler form.
-
Make the library easier to maintain.
Plan
Foundation
I think one move that would actually hit all my goals is migrating from Svelte to Stencil. This will provide us with:
-
Easier maintenance. Project compilation/bundling out of the box, auto-gen docs, built-in TS support, lazy-loading, polyfilling etc.
-
Reusability/integrations. Web Components are a native DOM solution to building reusable components. It's widely supported today by browsers and frameworks. In addition, Stencil specifically has solutions/guides for integrating with frameworks.
-
TypeScript + JSX. There is no need to dig into the benefits TS brings to a collaborative workspace and shipping a package/library because it's been written about a million times. My personal experience on a few projects confirms it. Also TS + JSX work seamlessly together in contrast to SFCs or native HTML.
-
Testing. Unit + E2E testing solution built-in.
-
Dev server with hot reloading. Comes with an integrated dev server in order to simplify development.
To elaborate a little more ... Svelte is built to be general purpose. It's not aimed specifically at building applications (Sapper aims to solve this part), nor libraries. It's easy to adopt/learn and just get shit done with. These are all reasons to absolutely love it but it also means it's not made for all use cases. It doesn't cover the tedious elements of maintaining a library of which some are mentioned above. TypeScript support is also poor and probably always will be because of the nature of the library + SFCs, similarly to how it feels hacky or unnatural in Vue.
I really really enjoyed Svelte but in a simple trade-off I have to let it go for now :( But ... it's not all bad news! Lucky for us Svelte has complete web component support!
Browsers
The following browsers will be supported:
- IE 11
- Safari
- Mobile Safari
- Firefox
- Chrome
- Opera
- Edge
Existing Packages
I think all the separate packages, names and features in Vime 1 are confusing. All existing packages will be merged into a single package called @vime/core
.
-
@vime-js/preview
will be axed. For the general consumer of this library, this component seems unnecessary and it can be easily achieved without our help.
-
@vime-js/lite
will become provider specific versions such as the vime-lite-youtube
component exported from the @vime/core
package. @vime-js/lite
will be axed to simplify the library and because the effort-reward ratio was too little. It was only going to shave off at most 5-10 kB off the full version and provide a super bare bones API that was probably going to suck.
-
@vime-js/standard
and @vime-js/complete
will be merged to become the vime-player
component exported from the @vime/core
package.
-
@vime-js/core
and @vime-js/utils
will now live inside the @vime/core
package.
Core API
The core API will be available on the root media player component vime-player
which is exported from @vime/core
and it will reside in packages/core
.
The following props will also be included:
isFullscreenActive
isPiPActive
canAutoplay
canMutedAutoplay
aspectRatio
canSetFullscreen
hasPlaybackStarted
hasPlaybackEnded
mediaType
isAudio
, isVideo
and isLive
The following methods will also be included:
canSetPiP
, requestPiP
and exitPiP
requestFullscreen
and exitFullscreen
Example
<vime-player>
<!-- ... --->
</vime-player>
Providers
All providers will follow the convention vime-provider-x
(vime-provider-youtube
) for the core provider and vime-lite-x
(vime-lite-youtube
) for an embed. They will be exported from @vime/core
and reside in packages/core
.
- Providers will be implement the
MediaProvider
interface.
- They are responsible for actually rendering the media and controlling playback.
- Unlike Vime 1, normalization will occur in each provider instead of attempting to normalize the differences globally. This caused a lot of headaches in Vime 1 and was very easy to break.
The lite
version of a provider is only available for embedded media and it should extend the Embed
component and implement the MediaLiteProvider
interface.
Embedded media should always attempt to extend the lite
version of the provider.
A more detailed specification should exist in the future for the provider interface.
Examples
<vime-player>
<vime-provider-youtube videoId="1y2xOj4QN6Q" />
</vime-player>
Plugins
All plugins will follow the convention vime-plugin-x
(vime-plugin-localstorage
). They will be exported from @vime/core
and reside in packages/core
.
- The registry will be simplified and have a well-defined lifecycle. Something simple like
mount
-> register
-> attach
-> detach
-> deregister
-> unmount
.
- Plugins will implement the
Plugin
interface.
- They will not include any visuals and simply extend the functionality of the player. For example a
vime-plugin-chromecast
plugin might add a cast
method to the root media player.
Example
<vime-player>
<vime-plugin-chromecast />
</vime-player>
UI Customization
All UI components will follow the convention vime-x
(vime-controls
). They will be exported from @vime/core
and reside in packages/core
.
Example
<vime-player>
<!-- ... -->
<vime-controls>
<vime-control icon="play.svg" />
</vime-controls>
</vime-player>
Integrations
Seperate packages for each integration will be exported from @vime/x
(@vime/react
) and reside in packages/x
(packages/react
).
Vime 2 will aim to support the following environments with the help of Stencil:
- JavaScript
- Svelte
- Preact
- React
- Vue
- Stencil
- Angular
- Ember
Testing
All components will be tested. E2E tests will be preferred over unit tests but we'll see. I'm interested in creating a test harness to ensure all providers follow a strict flow of events when playing media, seeking etc.
Site
- The playground will be removed in Vime 2.
- Introduction and Getting Started documentation pages will be removed.
- The documentation will move from GitBook to most likely Docusaurus.
- The home page of the site will contain code snippets with feature previews.
- Thanks to Stencil all the API documentation will be auto-generated for all components. We can focus on writing up any necessary guides such as a quickstart, creating your own controls, creating a provider, creating a plugin, integration guides and so on.
- Comparisons and reviews of Plyr and Video.js will be removed.
References