Aloha Editor: a browser word processor built on RequireJS and contenteditable

What the editor is built on

Aloha Editor describes itself in the repository description as a JavaScript content editing library, and the README heading calls it the HTML5 WYSIWYG Editor. The package keywords in package.json spell out the mechanism more precisely: wysiwyg, editor, rte, html5 and contenteditable. The last of those is the important one. Aloha is not a textarea replacement or a toolbar bolted onto an iframe; it drives the browser's native contenteditable editing surface and adds behaviour on top of it.

That choice has consequences worth naming. Native editing gives you spell checking, accessibility and platform behaviour for free, and it means the editor inherits whatever the browser does, including behaviour that changes between versions. It also means the interesting work in the codebase is event handling, command dispatch and DOM normalisation rather than implementing a text engine.

The library is dated in one respect and current in another. The package declares `"node": ">=20"` under engines, and the development toolchain is modern: esbuild pinned at 0.19.3, eslint 8, PostCSS 8 and Cypress 12 for end to end tests. So a project whose README still talks about vendor directories of ExtJS and RequireJS is being built with a current Node toolchain and tested in a browser runner.

Plugins are the architecture, not an add-on list

The repository layout makes the design decision visible. Under src/lib/aloha sit the main editor core sources, while features live in two bundles: src/plugins/common for the common plugin bundle and src/plugins/extra for the extra one. That split is the practical answer to how a WYSIWYG editor stays manageable, since commands, toolbar items and UI behaviour are plugins rather than core code.

Each bundle has a matching build profile. The build script in package.json points RequireJS at a profile called build-profile-with-common-extra-plugins, which is the concatenated form of the two bundles:

"build": "node ./node_modules/requirejs/bin/r.js -o build/aloha/build-profile-with-common-extra-plugins.js"

So the distribution artifact is a single file produced by the RequireJS optimiser, not an npm package of ES modules. Running the build by hand is therefore the normal way to get a usable Aloha bundle, and that is a meaningful constraint if your application is bundled with webpack or esbuild from npm packages.

The build also keeps vendored dependencies inside the repository rather than resolving them at install time. The README describes /vendor as holding vendor source code such as ExtJS, require-js and jquery, with matching copies under src/lib/vendor and utilities like json2.js and class.js in src/lib/util. Carrying ExtJS in-tree is a choice from an era when ExtJS was a supported backend; it also means the security surface of your editor includes whatever version of those libraries is checked in.

Running the demo locally with the npm scripts

There is no install command in the README, so the concrete path is package.json. The four scripts are a Cypress launcher, a demo server and two identical build invocations:

"cypress:open": "cypress open",
"demo:start": "http-server target/build-profile-with-common-extra-plugins -p 8080",
"demo:build": "node ./node_modules/requirejs/bin/r.js -o build/aloha/build-profile-with-common-extra-plugins.js"

The shape is: build the combined profile, serve the directory the build writes into on port 8080, and open the result in a browser. http-server is a development dependency, not a production server, and the served content is the demo rather than anything you would expose. cypress-real-events is also a dependency, which is how the end to end suite sends events a synthetic dispatch cannot reproduce, something that matters when the code under test is editing real DOM ranges.

Only one runtime dependency is declared, fs-extra, which is used by the build tooling rather than shipped to the browser. Everything else is a development dependency, which is consistent with an application-shaped project that you copy files from rather than install as a library.

Tests: QUnit in the tree, Cypress in the configuration

Aloha carries two testing systems, which tells you about how long the project has been alive. src/test holds QUnit tests, the in-browser unit testing framework from the RequireJS era. At the top level there is a cypress.config.js and a cypress/ directory, with Cypress 12.17.1 and cypress-real-events pinned in devDependencies.

Running both is more work than running one, and it means unit tests live inside the source tree while end to end tests live outside it. Post-processing also runs through PostCSS with autoprefixer, cssnano, postcss-import, postcss-url, postcss-combine-duplicated-selectors and postcss-plugin-namespace. That last one is the detail to notice: namespace prefixing keeps editor styles from leaking into the host page, which is exactly the problem a contenteditable editor embedded in someone else's CMS has to solve.

There is also a Jenkinsfile, a report-assembly.xml and a .travis.yml in the tree, alongside a .github directory. Having both a Travis file and a Jenkins pipeline is a fossil record of two eras of continuous integration, and neither is described in the README.

Reading the repository's actual state

The default branch is dev, and the last push was on 2026-09-28, so work is happening on that branch right now. What is missing is any release history: the repository has no GitHub releases at all, and the version field in package.json reads 1.0.0. A version field that has never moved tells you nothing about whether an API changed, so anyone integrating Aloha has to read the changelog and the commit history rather than a tag list.

Licensing is likewise ambiguous. GitHub reports the licence as NOASSERTION while the tree contains a LICENSE.txt. Read that file before shipping it inside a product, particularly since the vendored ExtJS, jQuery and RequireJS copies carry their own terms and the repository does not summarise them anywhere.

The README is also candid about the documentation being in progress. It points at new guides under `<repos>/doc/guides/output` and on aloha-editor.org, a wiki for end users and implementors, and a separate support forum for end user questions. There are 145 open issues on a repository of this size, which is high but not disqualifying for a project where the core audience is a small number of implementors.

Where Aloha sits against the usual alternatives

The alternatives named in the search data for this project are Squire and Jot, and they are useful contrasts because they solve the same problem with different assumptions. Squire is a small contenteditable editor focused on formatting commands with a deliberately minimal API; Aloha is a larger system with a plugin architecture, a demo bundle and a toolbar model. Jot is lighter still and treats the editable region as the whole interface.

All three sit inside the contenteditable browser rather than beside it, so none of them removes the underlying risk: browsers disagree about selection handling, and every one of these editors has an issue history showing it. Aloha's differentiator is the plugin bundle structure and the fact that it has been developed long enough to have opinions about command dispatch.

Two decades of accumulated behaviour also means two decades of compatibility work you inherit. The cost of choosing Aloha is not the initial build, it is the ongoing one: a framework tied to RequireJS, vendor code in-tree, and no semantic version history to guide upgrades.

Editorial conclusion

Aloha Editor makes sense for a content management system that wants a full word processor rather than a plain textarea, and that can accept a RequireJS based build and a vendored copy of ExtJS and jQuery. It is a poor fit for a modern bundler project or for anyone who needs a release cadence, because the repository publishes no releases at all and its default branch is dev. Start by running the demo target the package scripts name, read the guides under doc/guides/output, and check the age of the API you plan to call before committing, since the version field has sat at 1.0.0 while the last push was on 2026-09-28.

Frequently asked questions

Official sources

1. alohaeditor/Aloha-Editor on GitHub
2. Issues
3. Project website
4. README