AmplitudeJS: an HTML5 audio player where you write the markup

The problem AmplitudeJS solves: the browser decides the player, not you

A plain <audio> element gives you a play button, a scrubber and a volume control drawn by the browser. Those controls look different in every browser and cannot be restyled beyond a few pseudo-elements. AmplitudeJS takes the opposite position: you write the HTML for the controls, give the elements the class names the library expects, and it binds behaviour to them. The README states the goal plainly: it is "a lightweight JavaScript library that allows you to control the design of your media controls in your webpage -- not the browser."

The audience is front-end developers who are already comfortable writing markup and CSS and who have a design that a native audio element cannot match. Playlists are part of the model, not an add-on: the feature list mentions support for multiple playlists, live streaming, waveform and visualization generation through the Web Audio API, and public functions for control. If your player is a single track behind a native control, this library is more machinery than the job needs.

How AmplitudeJS binds your markup to an audio element

The architecture visible in the repository is a single bundled library plus a configuration object. The package entry point is dist/amplitude.js, built by webpack from src/, with tests/ run under Jest. There is no runtime dependency list in package.json, only devDependencies for Babel, webpack, Jest and Prettier. That is what "0 dependencies" means here: nothing is pulled in at runtime, but the build toolchain is still there for anyone who builds from source.

The data flow is markup-first. You write the player controls in HTML, then call Amplitude.init() with a configuration describing songs, playlists and the elements to bind. Amplitude then drives the underlying audio element and updates the DOM nodes you supplied. Because the library does not generate the interface, styling is entirely yours: the README describes design as "100% customizable" and the examples repository is separate, at serversideup/amplitudejs-player-examples.

The trade-off is that the library cannot help you with markup it did not write. If a class name is wrong or an element is missing, the binding fails silently rather than rendering a fallback control. That is the cost of the design-first approach, and it is the same cost every headless player library carries.

Installing AmplitudeJS and wiring a first player

The README points to an installation page under the documentation site rather than listing steps inline. What the repository does confirm is the package name, the main file and the build layout: package.json names the package amplitudejs, sets main to dist/amplitude.js, and ships only the dist directory in its files field. The README's installation section says installation is "very flexible on how you want to use it" and links to the docs for the actual steps, so treat that page as the source of truth for the exact snippet for your setup.

The npm package name and entry point are the two facts you need before wiring anything:

{
  "name": "amplitudejs",
  "version": "5.3.2",
  "main": "dist/amplitude.js",
  "files": [
    "dist"
  ]
}

That tells you the published artifact is a single bundled file. If you install from npm, you get dist/amplitude.js and nothing else; if you want to build from source, the repository has src/, webpack.config.js and a build script, and the README's installation page is where the project explains the options it supports.

What you should expect after following the installation page: a player whose controls are the elements you wrote, driven by a configuration object passed to the library. The README does not reproduce the initialization call inline, so the exact key names belong to the documentation site, not to this article. Read the installation page before you write markup, because the class names it lists are what the binding depends on.

Where AmplitudeJS is the wrong tool

The release history is the first limitation. The most recent release listed is v5.3.2 on 2021-06-11, and the repository's last push was on 2026-07-02. A push date is not a release, and the README does not describe what changed after v5.3.2, so anyone adopting this should plan on reading the source rather than a changelog when something behaves unexpectedly.

Browser support is stated in a table that includes IE11 and Edge, Firefox 4.0+, Chrome 3.5+, Safari 4.0+ and Opera 10.5+. Those are old baselines. The build uses webpack 2 and babel-preset-es2015, both of which are far behind current tooling. If your project already runs a modern bundler, adding this package means accepting a dist file produced by an older pipeline.

AmplitudeJS is also the wrong choice when the player is not the point. If you need a widget you can drop in and forget, a component library that ships its own markup will get you there faster. And if your audio work is about real-time processing, scheduling or synthesis rather than playback controls, the Web Audio API usage here is limited to waveform and visualization generation, which the feature list mentions but the README does not explain.

AmplitudeJS compared with Howler.js and Green Audio Player

Howler.js appears in the related search terms and is the natural comparison. Howler is an audio playback engine: it abstracts codec support, sprites and spatial audio, and it does not care what your interface looks like because it has none. AmplitudeJS is the inverse. It assumes playback is handled and concentrates on binding a UI you wrote to an audio element. If you want a player and no interface opinions, Howler is the smaller commitment. If you want an interface and no playback abstraction, AmplitudeJS is the direction.

Green Audio Player is the other name that comes up. That style of project ships a styled player you embed and theme within limits. AmplitudeJS gives you no default appearance at all, which is more work up front and more control later. The honest summary: AmplitudeJS is a binding layer between your markup and the browser's audio element, and everything else in the feature list (playlists, waveforms, live streaming) is built on that binding.

Licence, maintenance and what an upgrade costs

AmplitudeJS is MIT licensed, and the README links the LICENSE file at the repository root. MIT is permissive: you can use it commercially, modify it and redistribute it, provided the copyright notice and licence text are kept. This is not legal advice; check the LICENSE file yourself before shipping, particularly if you vendor dist/amplitude.js into a bundle.

The README is explicit that the project is community-run and asks anyone earning revenue from it to contribute through Open Collective or GitHub Sponsors. That funding model matters for planning. There is no stated release cadence, and the gap between the v5.3.2 release in June 2021 and later repository activity is not explained in the README.

Upgrade cost is low in one sense and unclear in another. The runtime surface is a single file with no dependencies, so replacing it is a file swap. But the version script in package.json builds and commits dist/ on every version bump, which means the published artifact and the source are kept in step by the maintainers, not by you. If you need a fix, you either wait for a release or build from src/ with the project's webpack 2 setup.

Editorial conclusion

Adopt AmplitudeJS if you need a player UI that matches your own design system and you are comfortable reading the docs in the repository's /docs folder. Do not adopt it if you want a maintained component with recent releases, or if you need a drop-in widget with no markup work. Before committing, verify the installation page and the player examples still match the API you plan to call, and check dist/amplitude.js against the version you expect.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. serversideup/amplitudejs on GitHub