Meet The JavaScript Framework That Might Save HTML5 From Itself

HTML5 was supposed to replace Flash by making Web pages work more like apps. But when its performance fell short, HTML5’s stock with app developers fell.

Famo.us is a small company that rushed to fill the gap. It has developed its own framework that essentially sidesteps the poky elements of HTML5 in order to render both 2D and 3D effects quickly—potentially making it possible to develop fast, cross-platform apps that don’t suffer from HTML5’s lags and stutters.

The trick is that the Famo.us framework relies on JavaScript, an extremely fast, widely used computer language that already works in every browser out there. Unlike Flash, it doesn’t rely on users downloading a browser plug-in—or on browser makers supporting it. (Apple effectively killed Flash three years ago by refusing to support it on the iPhone’s Safari browser.)

See also: Why JavaScript Will Become The Dominant Programming Language Of The Enterprise

“The premise of Famo.us is, ‘What if we made a rendering engine and an animation engine, and did it in JavaScript?’” said founder and CEO, Steve Newcomb. “JavaScript is turned on by default in all browsers. It’s available without an install or plugin. There’s no problem with Apple, Google, or anyone else liking or disliking it, because JavaScript is just everywhere.”

The Promise Of HTML5

HTML5, of course, has plenty of room to improve on the display front. For now, though, it’s a serious disappointment to developers who expected it improve on Flash.

See also: How HTML5 Crashed, Burned, And Rose Again

“Flash was perfect but for a few things,” said Newcomb. “It could render things very quickly and beautifully. But it required an install or a plugin to run. It wasn’t accepted by the browsers as a default way of doing things. That was its downfall.”

After Steve Jobs memorably announced that Apple’s mobile devices wouldn’t support Flash in April 2010, many developers pinned their hopes on HTML5. Unlike Flash, HTML5 would be compatible with every browser and every device. It didn’t require a plugin to work. Soon, Facebook publicized its plan to base all its apps on HTML5.

Unfortunately, the technology just wasn’t there yet. HTML5 was designed to work on top of the browser’s default rendering engine. Developers quickly realized that apps built in HTML5 were slow, shaky, and looked a decade out of style.

“The renderer in the browser was initially built to render a document with links—not apps,” Newcomb said. The solution? Circumvent the browser’s rendering engine with one of his company’s own creation.

Instead of WebKit or other browser-based renderers, Famo.us uses JavaScript to render graphics, theoretically in whatever way works best for the device it’s running on. (For instance, Newcomb said, Famo.us could display graphics via HTML, the WebGL JavaScript API, or an HTML5 canvas element.) The result is an engine that handles graphic display better than HTML5 currently can.

“A lot of people think we’re an HTML5 company because we do solve performance issues for HTML, but that’s not exactly correct,” Newcomb said. “We’re a JavaScript company, and one of the things we render to is HTML. In famo.us, you can write your app and we virtually render it in our engine. It can build apps in HTML and solve HTML5’s biggest problems.”

An Engine For Everyone

When HTML5 didn’t live up to expectations, developers at Facebook and elsewhere turned back to native apps—that is, programs built specifically to run on a particular operating system like iOS or Android. Native apps, like much application software, are compiled into machine language for speed and compactness, which also ties them to particular hardware and software platforms.

See also: Why The HTML5 vs. Native Debate Obscures The Real Challenge Of Mobility

In some ways, native apps are great. Not only are they fast, they can take advantage of specific OS and hardware functions in ways that device-independent apps often can’t. But a native app developed for one platform can’t run on others, which complicates development because apps for various platforms have to be developed—and maintained—in parallel.

Newcomb sees native apps as a temporary fix in other ways. “What made the Internet great was that anybody could right click on a Web page, view the source, and learn to code in HTML,” he said. “Native apps are a closed environment. You can’t right click on them and see source code.”

That’s why Famo.us is working to combine the best of all worlds. Like Flash, it can be used to build games, apps, ads, animations, art, and interfaces. Like native apps, it works on mobile. And like HTML5, it works in the browser without a plugin.

To demonstrate, Newcomb showed me an interactive lightbox gallery built in Famo.us, which I could recode in real time:

See the Pen Lightbox by famo.us (@befamous) on CodePen

Browsers have used JavaScript performance as a benchmark for overall speed since the middle of last decade. Famo.us could not have existed back when JavaScript was a slower language. But inter-browser speed rivalries have resulted in JavaScript that runs so quickly that it can support a powerful rendering engine.

The result: fast animations delivered with the speed of a native app that can run in any browser on any device. And like HTML5, anyone can right-click and see how it was built.

Case in point: Famo.us recently partnered with Hack Reactor, a 12 week coding bootcamp in San Francisco. For the beginning engineers’ final project, they were given private beta access to Famo.us and told to build their own versions of Twitter.

“Instead of having a small group of senior engineers coding on Objective C, you can have high school kids coding in JavaScript,” said Newcomb. “The fact that we were able to build this engine in JavaScript is a really big deal for teaching. It’s incredibly empowering to everyone.”

At its core, Famo.us is for professional developers. It already has 70,000 of them signed up for its private beta. But Newcomb hopes that the free, open source engine will also pave the way for the aspiring builders of the future.

“I’m not a traditionally trained engineer at all,” he said. “I was just a dude who learned how to code by right clicking and viewing the source. This deeply affected me in my career. I want to make it so people like me can build awesome stuff. I want to make it accessible.”