Matt DeBergalis (@debergalis) gave the coolest talk so far at Throne of JS, where he gave a fun live coding demo after a brief overview of the real-time framework Meteor, released just a few months ago.
“The web is wearing out” he claims… we see shifts in technology periodically. Our apps are now running right next to the user, instead of right next to the data. This back-and-forth server-to-client-to-server-to-client migration of where our software runs has been going on for years…
…and Meteor is a response to this, based on the idea that with this latest shift we need real-time applications. I think there’s a step I missed in the causal link there. I think it has more to do with our “always on,” perpetually connected set of devices that run software these days, rather than where the smarts of the software live, but nonetheless, we’re seeing a lot of popular apps with real-time features, collaboration, and data sync — from Facebook to Google Docs.
HTTP is a stateless request/response: poor fit for real-time apps. REST is also a poor fit. We need a session-based *data* protocol. We need completely new app platforms. Enter Meteor.
- Data on the wire, not HTML
- One language on client & server: Javascript
- Developers don’t have to task switch in thinking about the client & thinking about the server
- Continuous deployment: Hot code push… need to do it differently when there is client-side app state
- Rethink packaging — not just a tarball
Embrace the real world, understand that different databases, different protocols, different presentation layers exist for a reason. We can’t paper over those differences.
On the command line he types a few quick lines to create & run an app:
|
1 2 3 |
meteor create throne
cd throne
meteor |
Matt then deletes the boilerplate and creates a tiny app on-the-fly to vote up different server-side frameworks. With just a few lines of code, he makes a Frameworks object — which has client- and server-side data storage that is automagically sync’d with other clients:
|
1 2 |
Frameworks.insert({name:'Rails', score: 10})
Frameworks.find({score: {$gte: 5}).fetch() |
Session is client local storage, a Collection persists on the server. There’s a tiny Mongo implementation on the client, so you can use the same syntax on both sides. The app refreshes automatically when you change your code, never have to reload the browser — this is the “hot push” feature he introduced at the beginning.
”data at the center of the world”
but you don’t want all clients to have access to all the data at the same time. Back on the command-line, Matt introduces another trick:
|
1 2 |
cd throne
meteor remove autopublish |
Meteor model of subscribing to some data. At first everything is automatically published to the client, which is great for getting started and experimenting. When you turn it into a real app, then you want to only publish some of the data to the client like this:
|
1 2 3 4 5 |
if (Meteor.is_server) {
Meteor.publish('all-frameworks', function() {
return Frameworks.find()
}
} |
Meteor can have both client- and server-side code in the same file. Everything is Javascript with Node.js on the back end and a web browser on the front end. Later Matt admits that in practice, especially for small apps, code isn’t shared as much as they expected. We saw this too when we built the Flash Media Server (nee Flash Communication Server) back in 2000. Interfaces are shared between client- and server-side models. Sometimes you want to copy-and-paste logic that starts on the client before you realize it needs to be on the server, but mostly client-side objects feel like they ought to be the same as their server-side counterparts, but they are implemented differently.
What about security?
This a a PREVIEW of what’s coming out shortly (remember, this is brand-spanking-new tech)
|
1 2 |
cd throne
meteor remove insecure |
Similar to scaffolding in Rails, their out-of-the-box insecure model is great when you are just experimenting with an idea. When you develop real apps, you want to define methods (like RPC) — this is back to the pre-web client-server model of computing.
Then with one command-line install of two packages and a line or two of code in his app, Matt adds login via Google:
|
1 |
meteor add accounts-google accounts-ui |
In response to a question from the audience about the size of the client-side code, Matt reports that they ship a lot of code to the client, Mongo implementation is very small, but they have not yet optimized for size. The real question that the Meteor team is seeking to solve is how do we deliver applications really quickly? how do we update them incrementally? People load your app once and keep it open in a browser tab for days on end… how do we deal with that reality?
One Comment
I have a few more questions:
* How does it scale?
* How does it work on mobile?
* How does it work across browsers?
* How does it work in a context of very high traffic?
* How does it work with broken connections?
* How long the phone battery last?
It would be interesting to see tests for these questions.
Meteor is a good experiment with a neat command line UI for developers—might be part why devs were cheering in the room, but there are many issues which come into play when you put that out of the lab into the hands of diverse users in different contexts.