🎙️ Vime 2.0

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

1. Improved developer experience interacting with the library as a consumer and contributor.

2. Maintain great end-user experience by focusing on: aesthetics, accessibility, i18n and UI responsiveness.

3. Component/s API simplification and closer to native DOM implementation (Eg: Subscriptions -> Events).

4. Maintain customization and configuration but in a much simpler form.

5. 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 API will closely match the HTMLMediaElement API.

• The core design will prefer passing additional complex props via child components.

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

• #16
• #5
• #42
• #46
• #47
• #48
• #23
• #56

[mihar-22]

👋

For anyone that’s keeping any eye, apologies for the delayed release. I went off track but I’ve been improving framework integrations.

• Clean and simple support for custom components in React, Vue, Angular and Svelte.
• I added a Svelte output target to Stencil so it can generate fully typed and documented Svelte bindings. They’re essentially wrappers around existing web components but feel just like any other Svelte component.
• I’ve added a usePlayerStore function so you can hook up the player in Svelte to a store const { currentTime } = usePlayerStore(player). You get auto-subscriptions and all that good stuff.
• Improved all existing examples (https://github.com/vime-js/vime/tree/master/examples) and added a sample custom component (haven’t done the new Svelte yet).

Going forward I’m going to:

• Iron out the Svelte bindings and release them.
• Improve the Svelte example.
• Add Svelte to the components API examples.
• Wrap up the main section of documentation
• … and RELEASE before I come up with some other feature to add. I have a disease I swear.

Cheers 👍

[flergbarn]

Hey that’s awesome @secretcaptain. How’s Vime 1 been for you? What’d you struggle with when using Stencil, hit any limitations?

Overall it’s been great! I was looking for a lightweight wrapper around the Vimeo and YouTube players and vime fits the bill perfectly. My only two wishes are video aspect ratio detection (where possible, Vimeo is easy since it comes in the oEmbed JSON but YouTube I think is a bit trickier) and some more control over the lazy loading parameters, but not a big one.

My experience with Stencil (albeit a little while ago, maybe it’s improved) was good overall, but I ran into weird bugs with events not firing when they should and ultimately gave up on it. Lots of people obviously have great experiences with it, so take it with a grain of salt. I think think using webcomponents for this library is a solid idea overall. Will be watching 2.0 with interest!