Tom Coleman and Sacha Greif today published Discover Meteor, an introductory book on Meteor, a JavaScript-based web framework to simplify the development of real-time web applications. The book uses the application "Microscope", a simple real-time version of a Hacker News/Reddit-like site, as guiding example to demonstrate the features of Meteor as well as its ecosystem. In the book, the Microscope application is built from scratch into a functional application with relatively little code -- a clear demonstration of the power of the Meteor framework.
The book is consists of core and sidebar chapters. Core chapters take the reader through building the Microscope application, whereas sidebar chapters tackle the more fundamental aspects of developing with Meteor, including deployment, the pub/sub architecture and reactivity.
The core chapters are most useful to programmers just starting out with Meteor and wanting to learn the framework step by step. They work best when the reader follows along. The sidebar chapters are interesting to readers to gain more insight into the mechanics of the framework: what happens behind the scenes? How is application development with Meteor different than with other frameworks, like AngularJS? These chapters are useful even to those who are not interested in Meteor itself, but would like to get a better understanding of the mechanics and challenges of real-time programming.
Any book should kick off convincing the reader that the book is worth reading. In the case of Discover Meteor this means answering the question: why should I be interested in Meteor at all? Discover Meteor does this well, by starting the book with a compelling argument that consisely demonstrates the future of web applications as seen through Meteor glasses:
- Do a little mental experiment for me. Imagine you're opening the same folder in two different windows on your computer.
- Now click inside one of the two windows and delete a file. Did the file disappear from the other window as well?
- You don't need to actually do these steps to know that it did. When we modify something on our local filesystems, the change is applied everywhere without the need for refreshes or callbacks. It just happens.
- However, let's think about how the same scenario would play out on the web. For example, let's say you opened the same WordPress site admin in two browser windows and then created a new post in one of them. Unlike on the desktop, no matter how long you wait, the other window won't reflect the change unless you refresh it.
- Over the years, we've gotten used to the idea that a website is something that you only communicate with in short, separate bursts.
- But Meteor is part of a new wave of frameworks and technologies that are looking to challenge the status quo by making the web real-time and reactive.
To learn more about Meteor and its community, InfoQ spoke to the authors of Discover Meteor: Sacha Greif and Tom Coleman.
How did you get involved with Meteor? What got you excited about it?
Sacha: I first got involved with Meteor when working on what became Telescope. At the time, I wanted to build something like a "Hacker News for designers", so I looked into open-source social news apps. Since I couldn't find any good options, I decided to get someone to help me build my own, and started working with a Node.js developer.
Around that time, I heard about Meteor from a friend who knows the team personally, and told my developer about it. We decided to give it a try so we switched the app from Node.js to Meteor. In turns out that about one week after that that developer got busy and quit the project. I didn't want to go through the whole process of finding someone to work with again, I decided to simply take matters into my own hands and develop the app myself. Since I had no experience with either Node.js or Meteor, I figured I might as well continue with Meteo
Working with Meteor on Telescope turned out to be very interesting, and once I had a working app I decided to open-source the results of my work in the hopes of finding other like-minded people to help me with the project. And in fact, this is exactly how I met Tom.
Tom: I had been interested in trying out some server-side JavaScript frameworks for some time when I initially heard about Meteor. After doing more and more front-end code (and thus hating JavaScript less) I'd come to realise that there were really great benefits in using JavaScript server-side both for a experienced developers (code reuse and maintainability) and beginners too. I was really excited about lowering the barrier to entry into web application development for people with limited programming experience.
I hadn't really been thinking about it from a realtime perspective, but when I read up on Meteor's list of core features I realised how easy realtime could be, and how amazing the future of apps is! So the next chance I had, I built a side project in Meteor and started to get involved in the nascent community.
Sacha came along at a point where I had some free time and asked me to help him with Telescope. I thought the project looked great and doing something open source really appealed to me both to help the community and to deepen my knowledge. It was a great experience and led to other things..
In the book you use Meteorite to install Meteor packages. What is Meteorite exactly and what is its relation to Meteor as a product, is it a community effort or an officially "blessed" initiative?
Tom: Meteor has a smart package system that lets your use bundles of server and client side code as well as other resources in a really reusable way. However, up until a few weeks ago there was no easy way to write your own packages and (there still isn't) any built in way to share packages in a open source way.
So Mike Bannister and I distilled the fairly complex process that you needed to go through to integrate 3rd party packages into a wrapper script around Meteor (which we called Meteorite), and created a repository for people to post their packages to, which we called Atmosphere.
Meteorite is by definition a temporary project as the core developers plan to integrate it's features into the core project eventually. But for now I think for some degree it's enabling them to focus on other priorities as it's "good enough" for now.
There's definitely a transition plan for Atmosphere and I think that it will continue in some form, eventually being run by the Meteor folks themselves. I know that they'll do their best to make the transition as smooth as possible.
What does the Meteor community look like? Is it primarily JavaScript programmers, or do you see usage from other communities as well (e.g. Java, .NET, Python)?
Sacha: I think the Meteor community is pretty diverse. There's of course a lot of JavaScript programmers, but since you can hardly develop for the web without knowing JavaScript anyway, I think the framework is pretty approachable even for developers used to Rails, Django, or other web frameworks.
Tom: I think most web developers have in the past been X + JavaScript programmers, where X can vary; and there aren't that many people who have lived in a JavaScript-only world. Of course, frameworks like Meteor are changing that, which I think has advantages.
In character I think the Meteor community is great and people are very supportive of each other. It's been great watching it grow and seeing more and more voices chiming in and helping each other.
Meteor seems to be strongly tied to MongoDB, is it possible and practical to use Meteor with other database systems?
Sacha: As of right now other databases are not officially supported, but members of the community have been working on such packages, and the Meteor team has put better database support on the roadmap (including MySQL, Redis, etc.).
In the deployment chapter in the book you mention that on Heroku you can only run in a single dynamo (a single process). Is this also the case in other types of deployments, or a Heroku-specific limitation?
Tom:In order for Meteor's realtime features to work properly, each user needs to remain connected to the same web server for their entire session. There's fairly standard ways to do this (called "sticky sessions"), but the Heroku platform doesn't support them.
However, it's fairly trivial to set up when you have more control over your servers, for instance there's a fairly well mapped out process for getting it done on AWS.
There is a second downside with this approach at the moment -- there is a delay in data propagating between webservers (so if you and I are connected to different webservers there will be an up to ten second delay in me observing changes you make to data), but this is an area that the core team is actively working on and will be solved for the 1.0 release of Meteor.
Beside your own Telescope application, are you aware of any other know Meteor applications?
Sacha: You can find a list of many Meteor apps and experiments at madewith.meteor.com. Apart from these, bigger Meteor apps include FriendTrumps (a Facebook game), Gander (an email app), ShareWith911 (an emergency contact app), PiJS (an app that helps you deploy code to your RaspberryPi), and many more.
The Discover Meteor book does an good job both as a tutorial and as a source of gaining a little understanding of the "magic" that happens behind the Meteor scenes. It is a good resource for any beginning Meteor programmer.
About the Authors
 |
Tom Coleman is one part of Percolate Studio, a web development shop with a focus on quality and user experience. He's also the co-creator of Meteorite and the Atmosphere package repository, and is also behind many other Meteor open-source projects (such as the Router). |
 |
Sacha Greif has worked with startups such as Hipmunk and RubyMotion as a product and web designer. He's the creator of Telescope and Sidebar (which is based on Telescope), and is also the founder of Folyo. |