Episode 01: What Is Meteor?
Welcome to the first ever episode of the Discover Meteor podcast! In this episode, we’ll start by introducing Meteor itself: What is it? Why was it created? And what makes it so special?
- 00:30: The genesis of Meteor
- 01:48: Meteor vs the traditional web ecosystem
- 06:10: The advantages of Meteor’s architecture
- 10:40: The parts of Meteor
- 13:22: The Meteor community
The Genesis of Meteor
Sacha: Welcome to the first ever episode of the Discover Meteor podcast. In this episode we’ll talk about what is Meteor, and what makes it so special. So maybe you’ve heard about Meteor and it’s a brand new framework, it’s exciting, it’s modern, but you’re not quite sure what it is, exactly. Let’s go back first to the summer of 2011 and the origins of Meteor.
The Meteor team was part of the YCombinator incubator, and at the time they weren’t even trying to build a Web application framework, in fact they were trying to build a travel app. But they quickly realized that building a Web app was hard, and it was actually too hard for what they were trying to do. They started thinking there wasn’t a good reason for things to be so hard, and there should be a better alternative.
That was the genesis of Meteor. They decided to take on the challenge and make building Web apps easier for everybody.
Tom: The Meteor platform was called Skybreak at that point in time, as a little historical oddity. Yeah, they got a great reception, and eventually they formed the Meteor Development Group. They got some venture capital funding and here we are, four years later.
Meteor VS The Traditional Web Ecosystem
Sacha: To understand what makes Meteor so different from other solutions, let’s go back a little bit and talk about how traditional Web apps work.
Tom: By traditional Web apps we mean the Rails and the PHPs of this world.
Sacha: What all these app frameworks have in common is that they run on a server.
Tom: Right, and they run only on the server. So the job of the framework is to generate a string of HTML text that is served up to the browser, the browser will render that to the screen, and at that point the server’s job is done until the user comes back for the next page.
Tom: You might have heard of it.
Sacha: Fast forward to just a couple years ago, with the rise of client-side frameworks and single page apps.
Sacha: So we have two models. We have the traditional model where the server does most of the heavy lifting and sends static HTML data to the client – in other words the browser – and we have the more modern single page model where the server might just send JSON data and the clients – the browser – takes that data and renders it in a form that makes sense.
Tom: Right, even in that world we’re still usually looking at a situation where the server is a completely different technology to the client.
The Advantages Of Meteor’s Architecture
So Meteor’s different. In Meteor, the Meteor framework is both a client-side framework and a server-side framework.
Tom: What this means apart from feeling comfortable both in client and server, and not having to have a mental change of head space when you move between them, it also means to a large degree you don’t need to think about that connection between client and server in a way that you spend a lot of time thinking about it in a lot of frameworks. But we’ll get onto that when we start looking into the features of Meteor.
Meteor does very much care what’s happening on the other end, and the framework takes both roles.
Sacha: On the other side, frontend frameworks like Angular, Amber, React, usually only care about the front end, only care about the client, and don’t really have a solution for the server.
Tom: What does all this give you? What does Meteor running on the client and server give you? I alluded to this earlier, the really key number one feature that Meteor gives you is collections. Collections are, modeled on Mongo collections, Meteor at the moment only natively supports the Mongo database, although that may change, but at the moment, Mongo collections.
A Mongo collection lives in a database somewhere on your server side, but in Meteor you also have a collection, what’s called a Minimongo collection that lives on the client-side, in the browser.
Meteor takes care of the job, to what degree it can, of keeping the data synchronized between the two. It does this in a way that can be completely transparent to you, so that you can write data to your local database, and have that data appear in the local database of some other user that’s using your app without you having to write a single line of code, to palm that through. That’s a huge advantage that Meteor has, because it controls both ends of the stack.
Sacha: What makes this even cooler, is that Meteor is a reactive framework. So when something changes in the database, it also changes in the user interface in the actual HTML code that is rendered by Meteor. That principal extends everywhere, so routing can be reactive, variables can be reactive, basically any time you want you can have things react automatically to changes.
Tom: Reactive user interfaces are becoming more and more popular these days with the rise of client-only frameworks like React and Angular, and of course you can use these reactive frameworks with Meteor, but Meteor gives you so much more because it plumbs that reactivity all the way through your server and to other clients, which inevitably tends to be what users are doing, interacting with each other. So having the framework handle the plumbing of how data gets from one to the other is amazing.
Meteor has, where possible, attempted to do this, and you’ll see this in the APIs that you’ll use to access Mongo which look very similar on the client and the server. What this means that code that runs perfectly fine on the browser will also run on the server in many cases. The potential to share code is just magnified greatly, and that can be a huge productivity boost.
Sacha: Another benefit of sharing code between client and server is that it makes it easier to achieve what’s called optimistic UIs.
Tom: Optimistic UIs is a concept that’s fairly new in Web development. It refers to trying to solve the problem of waiting for the server to acknowledge that the user has done something, especially mobile applications where it can sometimes take a while to hear back from the server and where responsiveness and snappiness is really important.
If the user hits a like button you don’t want three seconds before you show them they’ve liked it, you want to optimistically update the user interface to put a tick next to the thing they’ve just liked. That practice is called optimistic UI. Basically what that means is that the client code, the browser code, has to guess what the server is going to do. Now in a traditional framework that basically means you have to write all your updates twice, once on the client side and once on the server side.
But the great thing about isomorphic code is that we can run the exact same code on the client, and with some clever stuff happening in the framework, it just works.
Meteor also comes with its own deployment system, just by typing Meteor deploy you can have your site running live on Meteor’s own free servers in a matter of minutes. So although Meteor’s strength is that it gives you a package that is ready to go and really simple to use, Meteor itself is actually made up of multiple smaller components that you can take out, or use separately, or even use in non-Meteor projects.
The Parts Of Meteor
So to give you a better understanding of how these pieces fit together, let’s go over each one of them. Starting with blaze. Blaze is the part of Meteor that is in charge of rendering the UI. In other words, it’s in charge of producing the HTML code that’s going to be fed to the browser, and in turn shown on your screen.
Tom: Blaze is built off tracker which is Meteor’s reactivity library, which drives all the reactivity in the client side of the stack. Another part of Meteor that’s built off tracker is Minimongo, which is merely a client side data cache. We talked about collections earlier, and the place that the data goes when it comes over the wire from the server to your browser, is it gets stored in Minimongo.
Minimongo, in order to achieve isomorphism gives you a nice simple API for querying that data that looks a lot like Mongo. The other thing that Minimongo does is it’s reactive, so queries will rerun automatically thanks to tracker when the data changes.
Sacha: Finally, another key component of the whole Meteor puzzle is DDP which stands for Distributed Data Protocol. DDP is the protocol that creates the link between the server and the client.
Sacha: We should note that when we say client and server, in the case of DDP the client doesn’t have to be a browser necessarily, it could be an iOS app, it could be a desktop app, DDP is actually a very flexible protocol and like everything else in the Meteor stack it’s open source, meaning anybody can use it.
The Meteor Community
Tom: Another interesting thing to know about Meteor is it has a pretty strong and vibrant community. There’s a lot of different places that you can go, a wealth of different places you can go to find out more information about it. We’ll probably do an entire podcast on this topic, but just to give you a flavor of points to start off, let’s just talk briefly about a few sites that you might want to check out.
Sacha: Sure. So a good place to start besides the Meteor site itself at Meteor.com would be the Meteor Forums at forums.meteor.com. They’re a great place to ask for help, to ask questions to the developers sometimes, and just to talk with the community in general. Another good place for discussing Meteor is Crater at crater.io which is also a forum like the Meteor forum, but more oriented to news and showcasing Meteor projects and special announcements, so a bit like hacker news for Meteor.
Tom: Another place you might want to check out is the packets repository for Meteor which is called Atmosphere, which is at atmospherejs.com. You might want to have a look around there and see some of the plethora of packages that people have written for Meteor, and get an idea of what a Meteor package can do and what sort of libraries there are available.
Sacha: Finally, if you like listening to podcasts, which I assume you do since you’re listening to this one, well you can check out the Meteor podcast hosted by Josh Owens at MeteorPodcast.com. So even with all this, you might still be wondering if it’s worth it for you to check out Meteor. Well, one thing that makes Meteor really fun is that it’s pretty easy to get started with it.
Meteor makes your life easier by providing an all in one command line utility, which installs your database, which runs your local server, there’s also an easy way to deploy. In just a couple hours you can already get started coding, and hacking, and deploying simple apps. That’s something that’s very cool and very fun to play with.
Tom: Meteor’s a really ambitious framework, so not only is it easy to use but it really enables a lot of powerful things as we’ve touched on in this podcast, and we’ll go into a lot more detail in future podcasts. It does require a bit of a change of mindset being reactive in the ground up, built off subscriptions and some of the things we’ve touched on, but it’s certainly easy to get started, so there’s really no reason not to at least give it a try and see how it feels for you.