Skip to content

Instantly share code, notes, and snippets.

@queso
Last active August 29, 2015 14:02
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save queso/e76f5b30ba9e17443483 to your computer and use it in GitHub Desktop.
Save queso/e76f5b30ba9e17443483 to your computer and use it in GitHub Desktop.
The (not so) real problems with meteor.js

The FUD around the Meteor.js platform

I ran across a post on reddit the other day asking why Meteor.js wasn't everywhere, and the amount of FUD surrounding meteor.js made me chuckle a little.

Let's dive into some of the reasons people cited.

Meteor is too much magic

Any sufficiently advanced technology is indistinguishable from magic. - Arthur C. Clarke

This always gets a smile from me, this is the same argument that people had about rails back when it first came out. When you first get started, will it be hard to understand new concepts and figure out how to debug things? Maybe, but no harder than picking up a new framework like Angular, Ember, etc.

The comment in regards to this did seem to focus on debugging, which is easily done using something like Chrome developer console or if you want node-debug, just use that to do debugging on the server side right in your browser.

Meteor doesn't have testing available

Yes, they did push off an official testing framework until 1.1, but this really gave the community a chance to step up here. I am part of a group Velocity that is working on a new test runner that easily plugs in any testing package that you want and it makes sure that the tests are run and they get reported back.

If anything, we will see the envelope pushed forward on testing with Meteor.js. We now have a fully reactive test runner and reporter! Now we are starting to focus on things like the ability to parallelize your tests easily if that is something you want - I remember that always being a holy grail of rails because a lot of test suites were slow. Be sure to check out meteor-cucumber or jasmine-unit if you want something easy to get started with on testing.

I love this stuff so much that I've been writing the book on testing meteor for the last month.

Meteor doesn't use NPM

This used to be true, but Meteor now supports NPM system 100%. You have two easy options for using packages from NPM:

  1. Write your own package and specify that you depend on an NPM.
  2. Use the npm package and manage the packages you need from a packages.json - just like plain ole' node.

Yes, Meteor has its own packaging system, but it's used to package both client and server code, so Meteor doesn't ONLY use NPM.

I don't need to share code between the client & server

This one really made me chuckle. Perhaps I come from the rails land of Fat Models and Skinny Controllers, but we love our collections and we use Minimongoid to make them even more useful. We have before/after hooks, relationships between collections, code for easily doing queries, and helper methods on our data objects.

This type of setup allows our code to be more DRY and easily tested in one spot, instead of having code and tests for multiple spots in our codebase.

Meteor doesn't work well with SEO

Another fallacy. Our entire website, including this blog, is built on Meteor and gets hundreds of sessions per day from Google Organic search traffic. All we had to do was install the spiderable package and tell our Modulus deploy we needed phantomJS. While the solution isn't 100% perfect right now, I know that things will get even better when options like server side rendering get built into Meteor.js.

I rarely need anything Meteor offers

Meteor is ahead of the curve in building brand new paradigms here, so I can see why some people might feel this way. Thinking and building a realtime UI are fairly new concepts and can be tricky since we have less past to draw knowledge from. I like being on this cutting edge and welcome the trickiness that comes with it right now. Give designers a few years to really experiment and you will see great things - look at the various native platforms and think about their version 1 and what is out now, a very big difference.

Just because you use Meteor doesn't mean you need to use every part of it. Don't like Iron Router or Blaze? Just use React or something else, plenty of people are going that route. Want to use Angular on the front end for the client side? Go ahead, packages for that too.

Meteor isn't for building real apps, just prototypes

The comment focused on the fact that most people in the reddit chat might be freelancers. Differential is a dev shop and we have only had one client walk away because they didn't want Meteor.js, so far. We've built well over 30 apps and have 25 client apps in production right now on Modulus.io. We find that it cuts our development time in half compared to rails or other frameworks.

While I appreciate other people chiming in from what they see on the outside, it makes me sad that people don't take the time to really inform their opinions on how Meteor really works.

Double dog dare ya!

Give yourself 2-3 hours and try building a little app to get started, I promise it is easy!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment