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

Download Episode

Transcript

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.

Sacha: This works great, and it was the way the Web in general worked for a really long time. But about 20 years ago the team at Netscape came up with a new feature that they called JavaScript.

Tom: You might have heard of it.

Sacha: What JavaScript is, is basically code that can be executed by the browser. With the introduction of JavaScript the browser wasn’t just parsing static HTML documents and showing you their content anymore. It could execute simple scripts to show an alert, move things on the page, or add a little bit of interactivity to websites.

Tom: We’ve come a long way since then, but a lot of the frameworks, and even the relatively recent ones when you talk about a 20-year scale, still view JavaScript as sort of bells and whistles on top of a site that’s essentially produced on the server.

The JavaScript might be used to improve user experience a little bit, it might be used to animate some things, to make some things a little quicker, but fundamentally all the real work is done on the server, and the server runs some other language such as Java, such as PHP, such as Ruby, such as Python.

Sacha: Fast forward to just a couple years ago, with the rise of client-side frameworks and single page apps.

Tom: What’s happening there is, people are now realizing the power of JavaScript and starting to want to do more and more of their app on the client-side. This started with Ajax, and this was a way of searching data on the server without having to do a full page reload. We moved to RESTful, JSON endpoints for that, and slowly over time the JavaScript has become more and more powerful to the point where these days JavaScript is doing a lot of rendering of the app on the browser.

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.

Sacha: When before we would have a Rails send some data to a JavaScript framework on the browser, now Meteor is sending data to Meteor. We have the same framework on both sides, and that’s really important to understand, because Meteor is the only framework out there that does that currently.

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.

It’s very instructive to think about Meteor like that when you compare it To compare it to backend frameworks such as Rails, PHP, or Django, they don’t really provide much, usually nothing at all, or very minimal amounts of JavaScript code. So they’re kind of agnostic as to what’s happening on the front end, and the backend server does its thing.

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.

Another big advantage of Meteor having both ends of the stack covered is isomorphism. What we mean by isomorphism isn’t just the fact that you run JavaScript on the client and on the server, although that is a huge advantage, and Node has really led the way in getting JavaScript on the server. But isomorphism is taking it to the next logical step and that means to have the same APIs or the same shape of APIs available to you on client and server.

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.

Sacha: Another nice feature provided by Meteor is Meteor’s whole tooling solution. You’ve got a command line utility that will install the server and database for you all in one package, Meteor will also compile all your HTML, CSS, JavaScript, minify it, bundle it for you, there’s also features like hot code reload which means that whenever you change something locally it will reload the page instantly so you can see the changes.

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.

Tom: DDP is a pure JSON data protocol, so if you look at the data that’s traveling over the wire it just looks like JSON which is quite nice if you’re a JavaScript developer. You might compare it to say a RESTful protocol that you might have over HTTP on the traditional Web application, but the difference here is that it’s a real time protocol. So as data changes, it gets pushed from the server to the client, not just requested by the client from the server. It runs over a Web socket, traditionally.

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.