Ace Editor: Embedding a Code Editor in a Web Page

What Ace Editor solves, and who it is actually for

Ace is a standalone code editor written in JavaScript, and the README states the goal directly: a browser based editor that matches and extends the features, usability and performance of native editors such as TextMate, Vim or Eclipse. That framing matters, because it tells you who the project is for. If you are building a web product where users edit code, configuration, SQL, templates or any structured text, Ace gives you the editing surface without asking you to write one. It was developed as the primary editor for Cloud9 IDE and is the successor of the Mozilla Skywriter (Bespin) project.

The feature list is broad: syntax highlighting for over 120 languages, more than 20 themes, automatic indent and outdent, an optional command line, vim and Emacs keybinding modes, search and replace with regular expressions, code folding, multiple cursors and selections, and a live syntax checker for JavaScript, CoffeeScript, CSS and XQuery. TextMate and Sublime .tmlanguage and .tmtheme files can be imported, which is the detail that usually decides the question for teams with an existing colour scheme.

What Ace is not is a desktop application you install and open. There is no binary, no window, no file browser. The repository ships a kitchen-sink demo, but that is a demonstration page, not the product. If you want an editor your users launch from a dock, Ace is the wrong layer.

How Ace is structured: modes, themes and the container contract

The mechanism is straightforward and worth understanding before you write any integration code. Ace loads as a script, finds a DOM element by id, and replaces its contents with an editable surface. The README is explicit that the element must be explicitly sized and positioned absolute or relative for Ace to work. That is not a suggestion. An unsized div gives you an editor with zero height, and this is the single most common first-run failure.

By default the editor only supports plain text mode. Language support arrives as separate modules: you include the mode's JavaScript file, then construct the mode and attach it to the session. The same pattern applies to themes, which are individual JavaScript files that you include and then name in a setTheme call. This design keeps the base payload small but pushes composition onto you. There is no bundler magic that guesses which of the 120-plus languages you meant.

Extending the editor is possible in more than one direction. The README points to documentation on extending syntax highlighters, and separately notes that full language client support for many languages is available via ace-linters, a project maintained outside this repository. That separation is deliberate, but it means completion, diagnostics and hover behaviour are not part of Ace proper.

Installing Ace Editor and getting a first editor on screen

There are two supported routes, and the README recommends the first. You can use one of the pre-packaged versions of ace from the ace-builds repository by copying one of the src* subdirectories into your project, or you can load the contents of lib/ace with requireJS under the name ace. The pre-packaged route is the one described as easiest.

For a quick local look at the editor, the repository works out of the box with no build step. Start the bundled mini HTTP server with Node.js:

node ./static.js

The README says the editor can then be opened at http://localhost:8888/kitchen-sink.html. Note the port: 8888, not the 8080 you might assume.

Embedding in a page is three lines of HTML plus a script block. The first script tag loads the editor, and the second converts the element with id "editor" into an Ace instance:

<div id="editor">some text</div>
<script src="src/ace.js" type="text/javascript" charset="utf-8"></script>
<script>
    var editor = ace.edit("editor");
</script>

At this point you have a plain text editor. To give it a language, include the mode file and construct the mode against the session:

<script src="src/mode-javascript.js" type="text/javascript" charset="utf-8"></script>

var JavaScriptMode = ace.require("ace/mode/javascript").Mode;
editor.session.setMode(new JavaScriptMode());

Themes follow the same pattern: include src/theme-twilight.js, then call editor.setTheme("ace/theme/twilight"). The README's CSS example for the container is position absolute, width 500px, height 400px. Copy that shape even if the numbers differ. When you are done with an instance, the README gives the teardown: editor.destroy() followed by editor.container.remove().

Where Ace Editor gets in the way

The plain text default is a real cost, not a footnote. Every language you support requires its own mode file, and on a page with several editors or a mode switcher, that is a loading problem you own. Ace does not solve it for you.

The build story is the second friction point. The README says you do not generally need to build Ace, and that is true for embedding, because ace-builds maintains the latest build. But if you do build, the toolchain is not modern. Packaging uses dryice, described as the build tool developed by the Mozilla Skywriter team, and the documented options include -m for minification with uglify-js and a --target path for output. The package.json engines field declares node >= 0.6.0, a version line that has been obsolete for years. That number is unlikely to reflect what the project actually runs on, but it is what the manifest says, and it signals how old parts of this pipeline are.

TypeScript users get declarations through the typings field pointing at ace.d.ts, and there is a typecheck script and an update-types script in package.json. The declarations are generated by a tool in the repository rather than hand-written, which is worth knowing when a type looks wrong. The README does not document a rollback path for upgrades, and it does not describe a migration process between major versions. Release notes are where that would live; the README is silent.

Ace Editor versus Monaco and CodeMirror

The obvious comparison is Monaco, the editor extracted from VS Code. The difference is architectural rather than cosmetic. Monaco assumes a heavier runtime and is built around the TypeScript language service; Ace ships as a script you can drop into a page and starts as plain text with modes loaded separately. If your product already resembles VS Code and you want its IntelliSense behaviour, Monaco is the closer fit. If you want a small editing surface inside an existing page and you are willing to assemble languages and themes yourself, Ace's model is lighter.

CodeMirror is the other common alternative, and it differs in the same direction: it is a general-purpose embedding editor with its own extension model. Ace's distinguishing detail is the import path for TextMate and Sublime .tmlanguage and .tmtheme files, which lets you reuse an existing theme or grammar rather than rewriting it. CodeMirror does not advertise that compatibility in the same terms.

For React specifically, the related searches point at react-ace, a wrapper that is not part of this repository. Ace itself gives you a DOM element and an API; the component lifecycle is someone else's package. If you need Angular integration, the same applies: you are wiring a DOM element, not consuming a framework-native component.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-17. Releases are frequent enough to suggest the project is still moving: v1.44.0 on 2026-08-07, v1.43.6 on 2026-03-02, and v1.43.5 on 2025-12-02. The gap between v1.43.5 and v1.43.6 is roughly three months, and the gap to v1.44.0 is about five. That is a steady cadence rather than a frantic one, and the minor version bumps mean the upgrade surface between releases is usually small.

Licensing is the part to check carefully. The repository metadata reports the licence as NOASSERTION, while package.json declares "license": "BSD-3-Clause" and the README states the source is released under the BSD License, described there as simple and friendly to open source and non-open source projects alike. Those three statements are not identical in form, and the discrepancy between the metadata field and the manifest is the kind of thing an organisation with a licence scanner will flag. This is not legal advice; if your distribution model depends on the exact terms, read the LICENSE file at the repository root and get your own answer.

Upgrade cost is mostly the mode and theme files. Because they are loaded individually, a version bump means re-copying the src* directory you vendored, or updating the ace-builds package. There is a changelog script wired to standard-version in package.json, so release history is generated rather than hand-maintained.

Editorial conclusion

Ace suits teams that need a code editor inside a browser product and want to control the build, themes and keybindings themselves. It is the wrong choice if you want a full IDE, a React component out of the box, or a maintained language-server setup without adding ace-linters. Before adopting, verify two things in your own environment: that the container element is explicitly sized and positioned absolute or relative, and that the mode and theme files you need are actually loaded, since the base editor starts in plain text mode. Also confirm the licence terms your distribution requires, because the repository metadata says NOASSERTION while package.json says BSD-3-Clause.

Frequently asked questions

Official sources

1. ajaxorg/ace on GitHub
2. Issues
3. Project website
4. README
5. Releases