InfoWorld: Why the name Meteor?
DeBergalis: We wanted something evocative. Look, programming got way too hard in the last 10 years. Web programming used to be very simple. The original Rails book was less than an inch thick, if I remember right. And that's all you needed to know. You could write a whole app. And we lost our way. Somehow in the last 10 years, it got incredibly hard to write these apps. Now you need to piece together a dozen technologies to have a modern application. And it stopped being fun somewhere along the way. Meteor is designed to be fun for developers. It's designed to be something that people can enjoy, that kindles a sense of curiosity and excitement. We really want it to be possible for many more people in the world to be able to write really great software, and the name is something that we just think reflects [that] it's cool, it's a little science-y, it's accessible, it's not supertechnical, it's not jargon, it doesn't scare you off if you're not an expert developer.
DeBergalis: The reason we wrote this is that there is a shift in the Web application platform, and specifically, people are starting to write a new kind of application, what we call a thick client, where most of the code is actually running inside the Web browser itself rather than in a data center. This is an architectural change from running the software in the data center and sending HTML on the wire to a model where we have data on the wire and the actual rendering, the displaying of the user interface, is happening on the client. That's the way Facebook and Google and Twitter are writing their apps now. Google+, for example, is a program. It's running in your browser. That's why it feels more interactive. It's not page-based like the old Web. It's much more engaging.
InfoWorld: Are you describing Meteor's live page updates feature, where developers write templates that automatically update when the database changes?
DeBergalis: That's one thing you end up needing. To build an interactive app like that, you end up needing a lot of infrastructure that you don't get in the last generation of frameworks, things like PHP and Rails, which were designed to send pages at a time from scratch to the browser. In a PHP app, you click a link, and you get a whole fresh page and the screen flickers and it changes and then you see something new. In these apps, you're constantly looking at new information. So the server is sending you new data, new pictures, new information, and as you swipe or click, your screen automatically redraws to reflect what's happened. We built Meteor as a current-generation solution to that problem because it turned out that it's really hard to write those apps using technology that was designed for this page-based presentation-on-the-wire era. That's how it differs.
You mentioned Node, for example, but Node is still a server-based environment for writing server-based code. A pure Node app has the same problem. So there's been this investment in components like Angular, which redraws the screen automatically as data changes. There's several things like that. Facebook has an open source library called React. It does the same thing. Meteor includes a component called Meteor UI, which does the same thing. What's different about Meteor is that's just one of the challenges where a developer or a team that sits down to write an application like this.