Вернуться к статье

Sing Li: What inspired the creation of Meteor — especially with so many development frameworks around already?

Matt DeBergalis: Meteor is a new platform designed for writing high-quality applications in pure JavaScript where most of the code runs on the client — inside the browser — instead of in the data center. This "thick-client" architecture is how modern apps like Gmail, Asana, Twitter, and the photo browser in Facebook are built. But those apps were written by large teams of expert developers, who each invested years of development into the technical underpinnings of client-side web apps.

Meteor is a complete platform for writing apps in this style. Because it uses a single language and a consistent API across all parts of an application, developers can juggle fewer technologies and work faster. That's why developers who know Meteor can build applications in hours that would otherwise take weeks.

Sing Li: Why the choice of JavaScript?

Matt DeBergalis: JavaScript is the language of the web browser. No other language has wide client-side support. And JavaScript is used by both experts and beginners, making it an ideal choice for a major new platform.

Sing Li: Does the team have experience in the architecture and design of large systems?

Matt DeBergalis: The core Meteor development team has deep architecture and design experience. Some of the team's credits include authorship of AppJet and Etherpad, key contributions to Asana's Luna framework, work on the DAFS and NFSv4 protocol specifications, and contributions to the Subversion and SVK source-control systems, the StreamBase complex event processing platform, and the Data ONTAP and NetBSD kernels.

Sing Li: How easy will Meteor development eventually become? Do you have plans for drag-and-drop visual components/IDE?

Matt DeBergalis: Application development is too hard today, and it is limited to far too few people. We want to make writing high-quality applications as easy as possible, for as many people as possible. Today we are focused on the core open source Meteor platform. To reach even greater numbers of developers in the future, we will need more, including a visual editor and a library of drag-and-drop components.

Sing Li: Where in the Meteor architecture is the best coupling point for existing back-end subsystems — one that you intend to support moving forward?

Matt DeBergalis: In the future, all APIs will be streaming, because intelligent clients will need servers to push updated data to them as it changes. Unlike other systems that use an ad-hoc communication channel for this, the Meteor client and server communicate using a standard protocol we built called DDP. DDP combines a publish-subscribe model for data transfer with a reliable RPC facility that clients can use to call privileged methods on the server. DDP is language- and database-agnostic, so an existing back end can speak to a Meteor client — or to another server component — using DDP. In fact, developers in the Meteor community have already written third-party DDP clients and servers in other languages.

Sing Li: Windows and non-Intel architectures (such as ARM) support — are these important to Meteor? Or are you depending on the community for their support?

Matt DeBergalis: We are lucky to have strong community support for Windows already (win.meteor.com) and early efforts at running Meteor on ARM. They are both critical: Windows still commands a large share of app developers, and Meteor and DDP are excellent fits for the Internet of Things and the rise of embedded networked devices. We have both on the roadmap for official support in core.

Вернуться к статье