6 Must-Use Meteor Packages for (Almost) Every Project

Originally published at: http://www.sitepoint.com/6-must-use-meteor-packages-almost-every-project/

There are already thousands of packages for the Meteor JavaScript framework, so no matter what feature you want to add to your web application, someone’s probably gone ahead and made a package that slickly implements that precise ideas. Convenient, right?

But of course, with more choice comes the paradox of choice. It can be overwhelming to figure out which packages might come in handy.

Here’s a run-down of what I consider to be the few most helpful:

1. Iron Router

A question I’ve received a few times from beginning developers is, “How do I create a multi-page application with Meteor?”

Because, when someone’s never built a web application before, it’s not immediately intuitive that creating a new page isn’t as simple as creating a new file. What I introduce them to, then, is the wide world of routing.

Routing allows developers to make muti-page applications with less code and a flexible project structure. They have many other advantages, most of which become apparent as you build bigger and more complicated applications, but for the moment, there’s two main points to understand:

  1. The vast majority of Meteor applications will use routing in some way.
  2. To handle this routing, the Iron Router package is the best option.

Iron Router is everything — friendly, deep, and well-supported — and you can add it to a project with the following command:

meteor add iron:router

Once installed, create a route inside a JavaScript file:


Then create a template of the same name:

<template name="about">

You’ll now be able to visit the http://localhost:3000/about path and see the “about” template.

This, however, is a very simple example of routing. For a deeper introduction, watch this video I made for Learnable.

2. Collection2

Most Meteor applications will interact with a database in some way. By default though, you’ll have to manually validate the data that users are inserting, editing, and removing from the database.

Collection2 helps with this process by extending Meteor’s functionality, allowing it to “provide support for specifying a schema and then validating against that schema when inserting and updating.” For example, you can make it so a “Books” collection has a title field that must be a string, and a lastCheckedOut field that must be a date.

Here’s an example schema:

Continue reading this article on SitePoint

Could someone explain me to which purposes the JavaScript Server Side frameworks can be used? It seems to I slept something because there are more and more articles about js serverside frameworks and I dont know when I should use these frameworks :wink: Please give me the ‘real’ example when these frameworks should be used. On a daily basis I’m using the PHP on the serverside. This is the alternative to the PHP frameworks (but I don’t think so)? Thanks! :slight_smile:

Thanks for sharing! More lists like this would be very much appreciated by me :smile:

Collection2 seems very interesting!
Meteor is my favourite way of making websites! Fun, logical, fast and gives a great result!

One of my favourite packages is the Semantic-UI package. Even though you most likely would not want that for every project, it is pretty cool!

Visiting these guys site https://www.meteor.com/ with javascript turned off, just gives you a completely blank page.


In 2015!

That pretty much tells you all you need to know, about whether you should use it or not.

Well admittedly, Meteor is a platform built on top of JavaScript, so there are certain expectations involved.


Yes. But I’d say it operates in the same space as Ruby, Python, Java, Scala, etc. Not really PHP. It requires a VM, some CLI, and an active server. It’s designed more for web apps.

[quote=“MatsSvensson, post:4, topic:111461”]javascript turned off

In 2015!

There’s your problem.

1 Like

I just disabled HTML in my browser and the internet didn’t work.


A site that’s capable of falling back to only HTML with no scripting can be an admirable achievement, but the lack thereof should not be used as a source of denigration.

I am curious about what others think on this. Should a JavaScript framework site be capable of working without JavaScript, and if so, why?

We actually just had a big thread on this. It wasn’t in the JavaScript forum though.


Disabling JS is dumb. But simple sites like blogs should at least have progressive enhancement. Web Apps are fair game.

Which is also my opinion, so that may not be unbiased. :smile: But nobody really presented anything to the contrary that wasn’t based in misunderstanding.

[quote=“mawburn, post:9, topic:111461”]
Disabling JS is dumb. But simple sites like blogs should at least have progressive enhancement. [/quote]

But what if your audience is “dumb?” …and disabled JS? I guess you just dismiss them as ignorant?

Never mind.

Clearly I was the one who broke the site, by using view-source and thereby moving all the content on all the pages into the head-tag, leaving the body completely empty.

Im sure all search-spiders and html-validators has already been upgraded to handle the Observer effect In modern quantum webdesign.

@AngC, I’m curious. Could you please summarize the reasons that you have JavaScript disabled in as few words as possible? I re-read the other thread, but it is somewhat convoluted.

Then they probably don’t what JavaScript is.

I dismiss those who disable it as being less than 1% of the internet and not worth my time.

Idk why we have to beat this dead horse again. I’ve already said this in as many ways as possible. I don’t even know why we are having this conversation on a forum built entirely in JavaScript. Anyone who’s reading this on the other side of the coin is unfortunately a hypocrite.

Does meteorhacks:npm still required to use npm package ?
When creating a package i succeed to load npm package using :

    "iconv-lite": "0.4.6",
    "request": "2.51.0"

So i’m not sure when i have to use meteorhacks:npm

Sure. In as few words as possible (not meaning to sound shitty) but it’s my computer; I bought it; I paid for it; I want the choice of who/what does whatever to it.

No need to beat any dead horses. I was just proffering my opinion (as a consumer.)

I understand that you have to make a decision to dump some consumers in the pursuit of design efficiency. My opinion is that you’re not too smart by doing so, based on your slavish adoration of JS. I speculate that most business web-sites exist either to sell a product or to provide information about a product. I feel that I am a pretty good target audience, because I buy everything on the internet… the only exceptions are fuel type products and groceries. And if somebody had a website where I could click for a refill, I’d have them out here filling our vehicles with fuels.

I may be kinda’ senile, but I’m a shopper, and so is my husband. To my dismay, he recently discovered he could buy firearms on the internet and have them delivered. We spend a fair chunk of change online; why would you dismiss us so casually? In my opinion, your focus, Mawburn, is to dictate to your potential consumer. Wouldn’t it make more sense to contemplate what your target audience might prefer???

Mawburn’s point is that users with JS disabled represent a tiny minority of customers. A similarly tiny minority will visit the site and decide not to buy for some other reason (perhaps the price was too high or the business in question doesn’t delivery to Outer Mongolia), but it wouldn’t be financially viable to make the changes necessary to please that small segment of users - the cost would outweigh the potential increase in sales.

1 Like

But isn’t this like buying a car, removing the wheels (because you can), then being surprised that you can’t drive it?

I’m not trying to get on your case, rather I’m genuinely interested in your motivation.
I know there are some folks around here that disable JS so that they don’t have to suffer animated advertising (which they find cognitively debilitating) and there are some that disable JS to make it more difficult for their online activity to be tracked. This is fair enough.

However, in my opinion, three pillars of the modern web are HTML, CSS and JS. It is not reasonable to disable one of these and expect things to work flawlessly (after a point).

1 Like

This isn’t exactly the best example. Tires are a neccessary part to a car. Javascript isn’t (shouldn’t) be.

Well, for web apps it is. Nobody likes to reload a page for every minor action anymore.

1 Like