Next Thursday, I’ll be in Minneapolis, Minnesota speaking at the Midwest JS conference. To make it less stressful—this is my first big talk—I decided to focus on the topic of why Meteor is important and how it can empower front-end developers who (up until now) have spent most of their time working only at the interface level. This post is more-or-less the “release candidate” version of the talk. I hope you enjoy! If you have any feedback, I’d love to hear it in the comments.
Superpowers
When I first started working with Meteor a few years ago, my development experience (back-end) was limited to building WordPress themes. At best, I understood a trickle of PHP, but building an entire application? Forget it. I was more or less Peter Parker to the development world.
Fortunately, Meteor changed that. Big time. Around June of 2013, I got the bite in the form of Discover Meteor, a book that went in-depth into Meteor and how to build a real-world app. From then on I was hooked! I ended up building my first app WhatWhen in about 2-3 weeks. At that point, my mind was blown. I went from having zero idea of how to build a database connected app to having a working, live version in less than a month.
After that, I decided to bite off a little more. Though I decided that the business wasn’t right for me in the end, I built and launched an app called Proper that helped freelancers to prepare, send, and get contracts signed. This one took me a little bit longer…about three months. But, again, with little experience of building applications I was able to go from idea to production with Meteor!
Though I decided that Proper wasn’t right for me, I did realize that I really enjoyed Meteor and had picked up a fair bit of knowledge on how it worked. I also loved teaching people how to make use of it. So, in November of 2014, I launched The Meteor Chef. A site dedicated to helping Meteor developers solve day-to-day problems in their projects through practical recipes and snippets. I’ve been building up the site slowly over the last ten months and it’s been exciting to see the community of developers grow around the site. During that time, I came to discover something really unique about Meteor: its ability to act as a multiplier of existing skills. Let’s keep that in the back of our minds for now.
What is Meteor?
Meteor’s introduction came at a weird time when JavaScript frameworks—the one’s that attempt to give your front-end JavaScript some structure—were flooding on to the development scene. As a result, Meteor quickly (and unfortunately) got lumped in with these frameworks. Hell, even the Meteor Development Group referred to Meteor as a framework in the early days. But as time moved forward, it became clear that Meteor was best thought of as a platform: an allied group of technologies that help you build software, not yet-another-way to structure your application. I like to think of Meteor as a set of pre-made decisions that have been tied together in an easy to understand way.
In order to understand what Meteor really helps us to accomplish, we need to understand how Meteor thinks about the web vs. how we’ve thought about the web for the last twenty or so years.
Starting in the early 90s, we had this concept where a user would click a link on a web page (or document). That click would trigger a request to the server for some other document. The server, then, would say “okay,” pull in all of the data it needed and build that into HTML, and then send that back to the client as a complete “snapshot.” This is where we get that familiar “flash” or loading between pages. We’re waiting for the server to give us the full HTML that responds to our request.
Now, we’ve shifted into this era where we’re using the web to build entire applications, not just static documents. We need a way to keep our data in sync—in real-time—just like we might expect our desktop or device applications to work. When we click one of the tabs in an app on our iPhone, the page doesn’t refresh. Why should our web apps have to?
This is where Meteor starts to think a little differently. It acknowledges the idea that we have all of these different ways of connecting to and interacting with data. Instead of getting back full, static web pages, we need a way to make our applications responsive. Because we have these distributed systems in the form of “the cloud,” the it makes more sense to have our clients handle the stuff like rendering HTML on the machine and using a live connection to the database to handle synchronization of data.
When our user first loads up our application, instead of sending a single page, we send all of the code we need on the client as a bundle in the form of a single JavaScript file. The code in this file, then, is responsible for reacting to data changes. So instead of just rendering our HTML on the server and sending pages back one at a time, we have a single page that updates as things change directly on the client.
On the client we can use JavaScript to do things like render our HTML and “watch” for data changes in the database. To make this really click, we setup a local database on the client that stores only the data that is needed for that client (or user). When data changes either on the client or the server, that local client database is synced with the server database.
Okay, great. What does this actually mean? Well, because everything is based on JavaScript, we can deploy this application to (in theory) any device. Because each client is responsible for handling the presentation of that data, this means that we can push a change to our database and each client will update on its own (a user isn’t required to “click” something or refresh to get data). In other words, our clients “react” to data changes.
How Meteor pulls it all together
So, we see this similar behavior in frameworks of updating HTML when data changes (e.g. Angular or React) but how is Meteor different? This is the cool part. Meteor isn’t just focused on the wow factor of updating a page as the underlying data changes. Instead, Meteor also focuses on how apps likes this are actually built, or, what I like to think of as the “development experience.”
Simplified down, Meteor is made of two parts: a command line utility and an ecosystem of packages. Let’s take a look at both and wrap our heads around how they work and why they’re important.
Command Line Tool
When we install Meteor, we’re given access to a command line tool called—surprise, surprise—meteor. This tool is best thought of as the command center we always wanted for our apps. Instead of having to build custom scripts to wrangle multiple command line tools, Meteor gives us a neat and tidy tool with a handful of commands to make life easy.
As you can see there are quite a few, but let’s review some of my favorites to see what we get.
Terminal
A quick and easy way to start up a new app. No need to pull in all of the JS we need for Meteor ourselves, one command and we’re ready to go. Nice!
Terminal
With this single command (an alias for meteor run) we get:
A built version of our application.
A web server running on port 3000.
Live reloading of the client when client code changes and live reloading of the server (without refreshing the client) when server code changes.
Neat! Notice, this is out of the box with zero extra work. We get this for free: no strings attached. I love Grunt, but not having to manage a script to do all of my bundling/building is a welcomed sigh of relief.
Terminal
This is the best part. As we’ll learn, Meteor has a thriving ecosystem of packages contributed by the core team and community members alike. To add some new stuff, we just run meteor add and we’re on our way. Pretty cool, right? We can even use NPM packages too with a little more effort. Using some handy community tools we can add dependencies to a file called packages.json and get access them into our app with a quick command on the server in our app:
Terminal
packages.json
server-example.js
The Meteor Way
We can also do this directly in Meteor, but to get access to NPM packages we need to make use of Meteor’s package system. Instead, we make use of Meteor’s package community and pull in meteorhacks:npm which has written the code to automate this process for us. Teamwork!
This is incredibly powerful and makes it really easy to build apps using both Meteor packages and those that we’ve come to love when working with Node.
Terminal
This is one of those “super handy for local development” tools. When we’re testing out our data and want to nuke our database we can run a quick command: meteor reset. Done! Simple, but easily one of my favorite features when I’m in the dregs of development.
Terminal
This is almost as magical as it seems. Though still just in preview mode, the Meteor Development Group is working on a service called Galaxy. Right now, we can test this out by using their free, preview version of the service. Want to get your app up and running on a server? Just run meteor deploy <url> and the URL you want it to live at on <subdomain>.meteor.com. This isn’t production-grade just yet, but it’s great for prototypes and early beta’s where you want to give more people access to your app.
Once Galaxy is live, this same process will be accessible for production-grade apps. Crazy! No configuration, no extra steps, just a single command and you’re up and running.
Production Deployments Today
The good news: we don’t have to wait for Galaxy to go into production with Meteor. Services like Modulus offer tools like Demeteorizer to help us deploy our Meteor app to any PAAS provider that supports Node!
Okay…so we can see that Meteor gives us a serious leg up with their Meteor Tool. Plus one for our workflow, yeah? That’s great and all, but what do we have access to to actually write our applications? Enter packages.
Packages
Packages, package managers, and all of that are nothing new. But Meteor is one of the first platforms to come with its own package manager built in. When we talk about packages in Meteor, we think of two kinds: core and community.
Core Packages
What’s unique about Meteor itself is that it is actually made out of packages. Everything in Meteor is a modular piece and can be added or taken away at will depending on your needs. This is unique because it means that we can deliver a whole new class of applications for a bunch of devices and have them tailored to that environment. Only need a server side component for say, your iOS app? Pull out all of the client-side stuff and communicate to your app using Meteor’s Distributed Data Protocol, or DDP.
More importantly for browser jockeys like us, by default Meteor ships with everything we need to build a traditional web app. Made up of several other packages, when we use the meteor create command earlier, Meteor installs three packages for us: insecure, autopublish, and meteor-platform. The first two packages, insecure and autopublish make it easy for us to start interacting with the database as soon as we create our app (though, when we move to production we strip these out for security purposes).
That last one, meteor-platform gives us a front-end framework, a server and client database (using MongoDB), live querying on that database, reactive data sources, and a lot of other goodies. Zero configuration, zero need for scratching your head. The decisions have been made and made to work together by default.
In addition to these default packages, though, Meteor ships with a handful of other core packages for adding functionality like parsing Markdown, adding a quick UI for signing up and logging in users, and yes, for you CoffeeScript nerds: CoffeeScript support.
Okay, okay. That’s cool. But…and this is my favorite part of Meteor: anybody can write a package.
Community Packages
Born out of an early project known as Meteorite, Meteor quickly came to support packages made by other developers. What started out as a community project, in the fall of 2014, Meteor added full support for both core and community packages using the meteor add syntax from the command line. To host those packages, Meteor relies on a service called Atmosphere built by the company Percolate which was recently acquired by Meteor. Gobble, gobble.
You, me, anyone who works with Meteor can write a package and deploy it to Atmosphere. This means that we can get all kinds of stuff into our app quickly and easily. Need client side validation? There’s a package for that. Need help scheduling cron jobs? There’s a package for that. Want to use Bootstrap and all its goodies? There’s a package for that.
Generally speaking, we see two classes of packages in Meteor: wrappers for existing code like handy jQuery plugins and Meteor-specific packages that simplify tasks like adding a schema to our MongoDB collections. As of this talk, there are 6,651 packages with that number growing daily. If we add the ability to use NPM packages, too, that brings us up to over 177 thousand packages. Oh, and you can develop your own private packages locally, too.
The Combo
Alone they don’t seem that special. But together, the command line tool and the ecosystem of packages we get from Meteor can make us insanely productive. I call back to my story from earlier about writing and shipping my first Meteor app in two weeks. That wasn’t bullshit. With nothing more than my front-end development skills, I was able to build an entire application using Meteor. Pardon my French, but that’s nucking futs.
So…what does Meteor code actually look like? I’m not going to show you! Yes, seriously. Why not? Because I think it’s far too easy to judge something and put it on your “meh” list without actually using it first. I want you to form your own opinions about Meteor through exploration. A well-formed opinion based on a weekend of tinkering is worth its weight in gold. To motivate you to play with Meteor, I’ve put an example application and tutorial on GitHub (to be released closer to the talk) that you can download and play with after this talk.
Let’s pump the brakes on tech, though. I want to focus on something more important: accessibility.
Accessibility
So when we talk about superpowers, we’re actually talking about taking our current skillset and giving it a sort of 10x multiplier. Whereas before we could only build the interface portion of our application, now, we can build the entire application using the same technology.
Why is this important? It’s less weight on our brains. There’s a great book by Peter Bevelin called “Seeking Wisdom: From Darwin to Munger” that talks about mental models and how we can make more wise decisions in our lives. In the book, Bevelin suggests the importance of focus:
It is impossible for our brain to think too many things at the same time and expect to do well. Shifting our mental attention between tasks costs time and comprehension, especially when we switch between more complicated and unfamiliar tasks.
— Peter Bevelin
Thinking about this in the context of web development, how difficult do you think it is for our brain to jump between different languages? Different APIs? Different ways of doing stuff? From experience I can say wholeheartedly: pretty difficult. It’s not that learning two different languages or “stacks” is impossible, but it’s certainly challenging. This is why we see developers grasping onto their decided technology and not letting go. Learning multiple things is tricky, time consuming, and trying to use all of those technologies together at once has a serious impact on our productivity.
Meteor helps us with that through its use of isomorphic JavaScript, or, JavaScript everywhere. What this means is that we can use the technology we understand right now to write the code we need at the interface-level as well as at the server (or back-end) level. It also means that we can write code to power applications that run on devices like iOS and Android, too. The same codebase, everywhere. That is huge. This means that front-end developers can take their existing skills and build full-blown applications on their own. Let that sink in.
You might say, “well, yeah, we can do that already,” and I’d say “you’re right.” But how much effort does it take to assemble all of those different parts? To bet on the “correct” technologies? To write the code that makes those different pieces work together? To maintain that code? That is the beauty of Meteor: we can focus our efforts on building great software, that works across all devices, using one language that we already understand without the need to wire together all of these independent systems.
Let me emphasize that point: focus on building great software.
As geeks, we’ve all fallen prey to that fantasy of inventing a new great way to build our software. “Basecamp? Ha! I’ll build my own project management software. But first, I’m going to write my own front-end framework…” take this project and flash forward a few months and what happens? No progress is made. We may have a “killer new framework” for building stuff, but we haven’t accomplished our actual goal. A quote that explains the shortcomings of this circuitous practice all too well:
Don’t confuse motion and progress. a rocking horse keeps moving but does not make any progress.
— Alfred A. Montapert
This is what blew my mind about Meteor. Instead of talking about ideas, I actually made them a reality. I shipped software. I did stuff. With nothing but your front-end development skills, so can you.
Implications
So this idea of using one language, of having all of these independent pieces put together in a meaningful, accessible way…what does it mean? It means more people, building more things, and (hopefully) getting things more fortunate folks like us enjoy into the hands of people who don’t. Despite the phrase being worn out: it means connecting more people with less effort.
When I say “fortunate folks” I don’t just mean people living in first world countries either. Instead, I also suggest that the people like us who live on the cusp of technology are incredibly fortunate to work with modern software. With tools like Meteor that act as an “equalizer,” we can save those people slaving away in cubicles, using generic one-size-fits-all software out of circumstance. Because their internal development teams struggle to produce custom software. Because it takes too much time and involves a convoluted process.
With something like Meteor acting as an “equalizer,” we start to see a lot more opportunities open up for developers, their co-workers, and their customers, too. Because it’s easier to produce quality software, we see more projects being not just greenlit, but actually being shipped in a reasonable amount of time—between a month and a quarter—not a year or more. That’s beautiful.
Even more beautiful is this photo. Apologies to the guy in the picture, Rahul Choudhury, I just took a screenshot of him speaking:
That message on his shirt is everything. “Software is about people.” That this is a picture of a fellow Meteor developer wearing this t-shirt is convenient, but don’t let that spoil the message. Software is about people. Not just the people using the software, but the people making that software, and more importantly how they make it.
At both ends of the spectrum, Meteor gives us something that—from what I’ve seen—no other platforms have achieved: it delivers a thoughtful experience to both the person making the software as well as the person consuming the software. As developers, Meteor doesn’t ask us to spend hours configuring an environment before we write any code. It doesn’t ask us to decide how third-party dependencies should be pulled into our application and how to manage those dependencies. It also doesn’t tell us how to use it. It simply says “here’s everything you need to start building an app, we’ve made it work well together” and gets out of the way.
The Future
Before we part ways, I should talk about the future of Meteor as that may be a little murky as an outsider. Where exactly is Meteor headed? How can we trust it? Is it “the one?”
Not to burst your bubble, but nothing will ever be the one. That’s the nature of what we do. As I see it, right now Meteor is the best option for building “cloud friendly” applications and will continue to be a valid option for years to come. Does that mean you’ll never have to learn anything else ever again? Of course not. In more concrete terms, there are a few things in the works that will help Meteor to grow and become more ubiquitous.
ES2015 support
First, the Meteor Development Group has made a commitment to supporting the latest JavaScript standard, whatever that may be. Soon, that means supporting ES6/ES2015 in full by default. As JavaScript continues to evolve and add new features, MDG will be focused on making sure those features are accessible and usable to write your applications with. From Meteor version 1.2 onward (due later this summer), all applications will ship with a package called ecmascript that will give us support for ES2015 out of the box.
Support for Angular and React
One a lot of people here will care a lot about: other front-end frameworks. By default, Meteor ships with its own front-end framework, Blaze. Coming in 1.2, Meteor will have full support for both Angular and React. You can play with these now using a mix of official preview packages and community packages. I haven’t spent too much time with these, however, because they’re being implemented by the core team, we can expect the quality of integration to be top notch.
More databases than MongoDB
Next up and another popular topic: databases. MDG is working on bringing full support for SQL into Meteor core. There’s no official ship date yet, but this is happening and you will be able to use Meteor with more than just MongoDB in the future. If you’re adventurous, you can make this happen right now using community packages.
Well invested project
A unique feature of Meteor is that, even though it’s an open source project, it has had significant investments made in its future by several venture capital firms like Andressen Horrowitz. As of writing, the total amount invested in the project is somewhere around ~$40M USD. To say the least, the Meteor Development Group has a decent bit of cash in the bank to dedicate resources to the continued development and support of Meteor.
Final Thoughts
Take a deep breath. All of those years of hacking away on the front-end are about to pay off big time. Now, whenever you’re hanging out with your developer friends and they’re bragging about their cool new Rails application, or how they just wired up React to a PHP app, kick back and smile. You have Meteor on your side now. You can build entire applications with nothing but JavaScript.
Up, up, and away!