A few years ago, Stuart Mitchell’s job would have been impossible.
The product director at edu-tech startup Verso needed to build a sophisticated “flipped classroom” app that would work in the browser and across gadgets like iPads, iPhones, and Android devices. It would need to be laser-fast, cross-generationally intuitive, and capable of scaling to many users without a hiccup. Crucially, it needed to update in real time, like the apps we’re familiar with–and whose creation is made to look so easy by the likes of Facebook and Google.
But Verso is not Google. This three-person startup needed to slap together a highly functional, cross-platform app in just a few months, a task that would normally require several more people and a collective proficiency in about a dozen technologies. Then Meteor came along.
It’s relatively young, but Meteor is already making quite a splash among developers. A hit on Hacker News when it was launched in beta in 2012, and since backed by an $11.5 million series A investment led by Andreesen Horowitz, the San Francisco-based company that oversees Meteor’s development just pushed out version 1.0 at the beginning of October. Meteor’s ambitions could hardly be, well, more meteoric, even if it’s only just reaching 1.0.
“Given that we started development of Verso back in May 2013, choosing Meteor was a bit of a gamble,” says Mitchell. “Back then it was at about version 0.5!”
So why roll the dice on a new, unproven technology? For Mitchell, Meteor had a few key benefits: Meteor is open source, which he preferred. When building an app for use in an educational setting (and thus by a wide range of people), cross-device support is a must. Check. And since the user base for such an app can balloon pretty quickly, it needed to be built with something that scales easily. Check.
But to Mitchell, like so many others eyeing up Meteor for their projects, one of the biggest perks was the simplicity of its code.
“Having managed large web app teams over the past 15 years I’ve been frustrated where the database, functional code, and front end are in different development languages,” says Mitchell. “In my experience it leads to differences in thinking and communication issues between the different team members.”
With little in the way of direct competition–DerbyJS is another full-stack app development framework built on Node.js, but with smaller adoption–Meteor was a no-brainer choice for the project.
The end result is a fast, cleanly designed education app that lets students learn and interact with teachers in a new way regardless of which device each of them is using. Teachers push prompts and related multimedia to students, who then send their responses back through the app. Students can also communicate among themselves. All of this happens in real time and the students’ progress can be evaluated from a high level using a separate app called Verso Campus, complete with data visualizations. It all works on Android phones and tablets, iPads, iPhones, iPads and any modern web browser.
“That’s just not possible otherwise,” says Meteor founder Matt DeBargalis, referring to the Verso project. “If you proposed building something like that in the traditional way, the fact of the matter is that it wouldn’t get built.”
Indeed, coding this type of functionality in a way that works across devices would normally require a huge budget and a team of developers with a range of skill sets. “That’s nuts,” says DeBargalis.
He would know. In 2011, DeBargalis and his then-cohorts were toiling away at an app of their own as members of that summer’s batch of startups at Y Combinator. But their idea–a real-time travel companion that was sure to disrupt the way people explore new places–turned out to be an epic pain in the ass to build, technically speaking. By 2011, the web had evolved from a series of static, linked documents into sleek-feeling, live-updating, collaborative slivers of software. But while coding this type of thing was a breeze for the tech giants, smaller upstarts struggled.
“We looked around the room at Y Combinator and realized every single other team was having the same problem,” says DeBargalis. “You’ve got all these teams of good developers, but they’re still stuck.”
The technical knowledge required to build a truly modern app isn’t, in and of itself, a barrier for somebody with enough time, money, or both. But when you factor in the need to deliver a product to whatever device a person happens to be using, things get drastically more complicated. And the problem goes well beyond startups.
“Every CIO has a wish list of 100 apps they want and they have a budget for 10,” says DeBargalis. “Every company needs a lot more software. And the biggest limit in doing this is the talent. Because today to write that software you need A+ talent.”
To meet the bare minimum requirements for cross-platform support–let’s say iOS, Android, and the good old fashioned web–one needs to find a front-end expert well versed in CSS and all the latest scripting frameworks, a backend expert, and one developer for each of the two dominant mobile platforms.
All told, you need a team of people well versed in 10 or 12 different cutting-edge technologies just to get something off the ground. “That puts a real drain on productivity,” says DeBargalis. “It limits how much good software people can write.”
For developers, this means coding lots of individual components to a given piece of software and then finding ways to glue it all together and keep it maintained.
“As it turns out, the glue is substantial,” says DeBargalis. “You end up writing a lot of glue and now it’s something that you’re forced as a company or a developer to maintain yourself.”
“The idea is basically that the APIs that you use should be exactly the same whether you’re talking about code running inside the phone, or inside the browser, or in the cloud,” says DeBargalis. “If you can unify all those APIs, it becomes much faster to write code because you’re not constantly switching gears in your mind.”
Meteor’s primary way of doing this is through the use of packages. These thousands of community-developed, functionality-specific bits of code are what make up the modular guts of Meteor. They’re built to translate their intended functionality across whatever platform the end user is on. The camera package, for example, knows how to behave when running in a native iPhone app (take a photo with the hardware’s camera and whatever camera software tools are available through that SDK), as opposed to working in the browser (use the HTML5 APIs that let you access the camera on the desktop).
This being an open source project, the vast majority of these packages are coded by developers out in the wild. At Meteor headquarters, they see their job as spot-checking things, managing official releases, and maintaining the larger community.
“It’s really about creating an ecosystem where people can write code that works everywhere,” says DeBargalis. “And a small team here at Meteor can ensure that the key pieces of that story are all tested together so that developers have a very smooth experience with it.”
Hyped as it may be, Meteor isn’t for everybody. For one thing, it’s a full-stack framework and third-party compatibility is an ongoing effort, so for developers already immersed in the multi-flavored stack of their choice, Meteor is not the kind of thing that can be easily jammed into an existing environment.
Some developers have criticized Meteor as something that’s best equipped to handle smaller projects and “prototypes.” While the latter jab is a bit of an exaggeration, it’s true that any project this young is going to inevitably come with a list of limitations. (Venture-funded, the company has yet to demonstrate a steady revenue stream, though it plans, among other things, to offer a cloud hosting service specifically tailored for Meteor apps.)
For now, the Meteor team is plowing forward with its technical road map (which is public, naturally) and prioritizing the various requests that pour in from the community. Meteor for Windows is a big one. And until the framework moves beyond MongDB for its database layer, some devs are going to be turned off.
But most of all, in DeBargalis’s eyes, the organization’s biggest role to play is as the leader of what he idealistically calls “a movement.” Part of that is nurturing the community and ensuring that curious developers feel comfortable joining it.
“If I pick Meteor, I’m making a big professional commitment,” DeBargalis says. “I want to know that I’m going to like the people. That they’re going to like me. I want to know that there are jobs, there are professional opportunities.”
Some Meteor developers, he points out, have built businesses not just on top of the framework itself, but on their own reputation within the Meteor community.
“The guys who wrote that router? They give conference talks on it,” he says. The same developers have amassed enough credibility to get work consulting and training others on Meteor, he says. “I think a lot of developers see that and they’re attracted to being able to do that.”
The developers behind Meteor, which is only a month and a half past its 1.0 release, and the company overseeing it have their work cut out if they’re to come anywhere close to reaching the ambitious goals they’ve set for themselves. Rightly so or not, DeBargalis seems confident.
“What we’re left with is the fundamental question of whether or not people are going to want to keep building software out of parts,” he says. “The promise here is that if we can all settle on a consistent, open source standard, then everybody is better off.”