The great part about Meteor is how it uses WebSockets to push updates out to clients instead of relying on AJAX polling, so it’s awesome for applications that need multiple users to collaborate on the same screen and see each other’s updates quickly.
The bad part about Meteor is that it’s not really obvious how anything works - you just follow the guides and API and it seems to sort things out. I haven’t ran into any issues yet that require me to dive into the core of Meteor, but I’m a little terrified of when that time comes. It also requires MongoDB, which for some people is a deal breaker.
On my first Meteor project I decided that I wanted to go with a different CSS framework than usual, and opt for Foundation over Bootstrap. I had a couple of reasons for doing so: It’s always nice to learn new things, and I’m a little tired of the “bootstrap look” that every Bootstrap app has. Foundation has its own default look and feel, but it’s more minimal and easier to customize.
My first reaction was to go out and get the Foundation SCSS files and copy them over to Meteor. That immediately didn’t work, and after some stubbornness I realized it really wasn’t worth trying to get to work. For some reason, Foundation by default wants you to install their framework using a command line tool. That seems extremely unnecessary for a CSS framework - it requires Git, NodeJS, and Ruby… just to install a CSS framework.
Luckily, or so I thought, there is a Manual Download section in the docs. This is barely more manual: you get to copy a couple of files yourself, but then you still need Ruby, Node, compass, and bower to actually install the rest of Foundation. I’m not sure why they don’t just create a repo with all the SCSS files. I, personally, prefer to manage those manually rather than using package management like Bower. They’re just static files that you include on a web page - having this much pomp and circumstance surrounding them just feels like overkill.
Regardless, even if these files were easily available, it would be difficult and unmaintainable to use them in Meteor. When a Meteor app is loaded up, it uses a set of rules to determine in what order files are loaded in:
From the Meteor docs:
- HTML template files are always loaded before everything else
- Files beginning with main. are loaded last
- Files inside any lib/ directory are loaded next
- Files with deeper paths are loaded next
- Files are then loaded in alphabetical order of the entire path
This moment was a bit of an epiphany for me, regarding Meteor. If you’re going to use Meteor for your project, you need to go all in on Meteor. This means either utilizing an existing Meteor package for what you need, or building your own. I’m a fan of installing my own JS and CSS dependencies, but not so much of a fan that I want to write my own package to do it, especially not when one already exists.
Atmosphere is a repository of Meteor packages. Think of it as the RubyGems of the Meteor world, except instead of using Bundler and a gemfile to manage your packages, it’s built into the core of Meteor: A simple
meteor add user:package will install the specified
package from the specified
user. Atmosphere should be the first place you go if you need a framework or library. It’s the place you upload one to if you’re the first to create it.
For reference, here are the two packages I ended up using as of this writing to get SCSS and Foundation installed with Meteor: