I recently read a lot about Meteor.js and its excellent packaging system. I went through their site also, but not my info give a holistic view on it. Do you think it's worth learning?
I've been using Meteor in paid gigs for over a year now. I don't regret giving it a try. It was hard to get my mind around for a few weeks. But then it clicked and I saw a lot of possibilities. I've never been happier as a developer. But that's me. It fits me.
I started using Rails in professional work in late 2005. That turned out to be a good decision. There is hype around Meteor in the same way there was hype around Rails in 2004/2005. The praise and objections are similar. Meteor is not Rails, so don't go looking for too many parallels. And the development climate in 2013 is not the same as 2005. You won't be able to predict Meteor's success or failure in five years, so it's not worth speculating.
When Rails came out, I was ready for it, technically speaking. My skills were in the right place and I was ready for a change. Similarly, I felt I was in a good spot to learn Meteor last year.
So the real question is, are you excited, ready, and able to learn it? If so, go for it. The worst that will happen is you will learn a new programming paradigm (perhaps) and it will inform any other development work you do.
Where are you finding paid gigs for it? I'm a freelance rails dev right now doing meteor stuff on the side and wouldn't mind doing some real work with it.
I'd recommend writing a few sample apps just to get a peek in to the awesomeness of where web technology could be going. It's hugely different to the Rails, .NET and Node stuff I've worked with to date.
Meteor buzzed me out - the auto-updating views, syncing data across client & server. Your app can achieve amazing real-time capabilities with very little code.
But now I'm a few thousand LOC into an application, admittedly I've pretty much hit the "wall". The magic baffles me. I'm struggling to solve problems in performance, code organisation and security.
I've been disappointed by the progress and the team behind it. All that funding and I can't see it progressing quickly. The docs are quite weak, there's not many example apps, progress seems slow.
So... on one hand it's awesome and well worth learning. But I'm reluctant to back it for the long term, as I don't see the team/framework moving in the right direction.
Core dev here -- I've been doing some work here and there on framework security and I'd love to talk about the security problems you're running into, if you wouldn't mind shooting me an email sometime.
Bottom line: Very interesting platform; nicely done in many ways; some concerns about architectural choices; not quite ready for prime time (production use) but probably will be soon.
My biggest issue with all of the frameworks is their lack of maturity. If you're working on a large platform with a team of people, you're going to want database migrations, localisation/i18n, asset management, proper testing framework, continuous integration and general proof of scale.
Meteor.js seems great but is still a bit of a gimmick in my eyes. But If I'm pressed to pick one, I have to say I'm much more interested to see what happens with Go and web frameworks like martini.
2. Right now you have to stick to MongoDB this will change in a later version.
3. Meteor will get a new rendering engine which will allow you to put angularjs( god only knows why ) or haml or some other templating thingy in meteor.
4. You can use meteor with phonegap right now.
Will meteor solve all your problems? No!
Will meteor will make you not think? No!
It's a great new piece of technology and you will learn new pattern and things. the livedata package and ddp package are great packages on their own.
Using the oplog of a single mongodb server limits you to the write capacity of one server. This is not scalable at all in the use of scalable that means more machines== more throughput.
+1 for this point. In the end, you've only spent time if you learn a technology that you end up not using. Meteor.js might teach you lots about modern web apps. That knowledge will be transferrable, even if you don't end up working on web apps.
Reading 'Discover Meteor' and consulting the docs will give you all you need to create a great realtime application in short time. It's a real pleasure to work with Meteor and the realtime web feels just a few steps away.
Our company has doubled down on Meteor. We start all greenfield apps in meteor now.
The biggest negative is simply the immaturity of the ecosystem. Everyone has different standards. There are no de facto standard packages (yet). Everything is changing rapidly. What worked well last week may not work well this week. The bleeding edge truly bleeds.
From a pure technology perspective, I'm excited about meteor because (to use a cliché) it shifts the paradigm. I wouldn't compare it to Rails/Ember/Backbone/etc because meteor is full-stack. There is no client/server. There's no ajax. Everything is one codebase. Even though it's built on top of node, it doesn't even feel like node because of the reasons above, and most of meteor is synchronous.
We wrote a couple blog posts about making the jump to meteor. I think the 1st one directly answers your question. The 2nd caused quite a stir here on HN.
I looked at it pretty heavily about 6 months ago (version 0.6.3 I think), so things have certainly changed some, but my thoughts were:
- It's nice that it comes with pretty much all the grunt work done, out of the box (asset packaging, live reload, deployment bundles, even the database!)
- It reminds me of early Rails, as it is still in a bit of a "hacky" phase. The level of commenting in the code is very low, there's TODO's everywhere, lots of things are shoved into the global namespace, etc. This is a sharp contrast with Angular or Ember, which have codebases I'd be proud to have my name on.
- The template binding is done in a simple-yet-effective way, which works without being too complicated but if your data isn't just a simple key/value map you'll need to learn a bit about it.
- Perhaps due to the simple binding, it's possible to use legacy code (e.g., jQuery plugins) in a lot of places where it would be tricky with Angular/Ember.
- It's very opinionated and you certainly wouldn't want to stray from the "happy path" of what's included in the stack (e.g., mongodb.) This was pretty much a deal killer for my app, though every case is different.
Meteor is not yet another nodeJS web-framework or client side JS framework. It also doesn't stop at combining the both (with a beautiful DDP to share data between C/S). Meteor' s architecture will make it possible to use it's components for all sorts of applications (other then the obvious web-apps).
2. It's as easy or as complex as you want it to be.
You can write a meteor app in 4 files or in a complex packaged structure. No need to overcomplexify, if you dont't want to. But you cán write large, complex, stable and maintainable code.
3. It embraces the eco-system.
You can rely on all of the NPM packages out there for your serverside logic and use all of the available frontend UI libraries and scripts. It will also enable writing complete reusable components in 1 package: servers-side logic, data-model, client-side logic, UI, ... all in one.
Biggest upcoming updates:
* Meteor UI.
Better approach then any other UI framework out there (including Facebook's react or FTLab's fruitmachine)
* Galaxy.
Deploy and scale your app on your own infrastructure or in the cloud by pressing a few buttons.
To counter a few of the cons in this thread:
* It's not reached 1.0 and it is therefor not production ready. I'd suggest writing your new applications in meteor anyway. Meteor matures quicker then any other framework out there. Is is well funded and here to stay.
* It is not scalable. Maybe not easy right now to make it scalable. But it certainly will be soon, when using mongodb oplog and galaxy will make it really easy to scale your service.
I run an agency in Belgium (redandivory.com) and we switched completely to meteor for all of our new projects. I think it's the framework of the near future.
Meteor is one of the most comprehensive and smooth frameworks for making web applications available today. It solves a ton of problems with a few overarching concepts: http://docs.meteor.com/#sevenprinciples
How well does Meteor scale? Could a multiplayer game written with Meteor handle the HN crowd hitting it? I'm thinking of writing something like this and Meteor would be perfect if it's amenable to authoritatively sharing state between thousands of connections.
If you are familiar with front-end JS frameworks like Backbone/Ember/Angular, then learning Meteor is as simple as a read through the docs and building a sample app.
If not, then learning Meteor would be a great way to become familiar with JS frameworks, and make the move to more complex frameworks (Angular FTW!) in the future.
As a developer I think "Wow, impressive". They have serious creativity and brainpower on that team. But, as a developer I also think how much magic must be going on there. I've always been a lightweight framework kind of guy Sinatra over Rails, Backbone over Angular. I'm not their target.
I use Meteor for a dashboard app and this seems to be the ideal use case for this stack: take JSON documents via third-party APIs, aggregate them (hence MongoDB is fine for the job) and push to clients.
Was it worth learning? I'd say yes, it has a low barrier to entry and is great for practicing front-end development.
Meteor is good, but not at everything, so it's very important to understand the trade-offs.
Pros:
0. Obviously, its major strength is its "real-time"[0] nature: I have built multiple chat systems (and presumably so has anyone else who's used Meteor, because it's an example of something that's fun and easy with Meteor but relatively hard with a traditional stack) as well as a map application that tracked the motion of a company's employees in relation to their destination (as part of a dispatching system).
1. It's also the least complicated way of sharing code between the browser and the server that I've seen to date.
Cons:
0. It's non-npm package manager feels like NIH to me (although I'm sure the team had valid reasons, I've never looked into it). Apparently it's still possible to require npm modules[1], although I've never tried it.
1. You're more or less stuck with MongoDB for the time being, which I guess a lot of people like but it's not really my thing.
2. There's not really any SEO capability, but that's sort of a given. Just don't use Javascript frameworks for that sort of project (or do, and do all sorts of weird shit to help Google).
3. It's kind of too auto-magic for me sometimes. The documentation is generally very good, but I occasionally run into weird variable scoping issues and the like, without any way of really figuring out what's happening. Of course, the source code is available[2] if I had time to read it. (Well-written, but big, and I find reading Node code to be mentally more taxing because of all the callbacks.)
4. The biggest con, for me, is that Meteor is basically limited to web applications. I really enjoy the typical single-page web app approach of building an API first, which you can access from other apps later (ie. mobile/tablet). I have no idea how I'd do that with Meteor. I'm experimenting with bundling a Meteor project and inserting the client-side code into a Phonegap app, for a mobile chat thing I'm working on, but that's obviously not ideal.
Generally, I love working with Meteor. I know I've written more cons than pros, but the pros I've listed are huge, and they've allowed me to work on cool stuff. You just need to know what you're getting into.
Footnotes/Links:
0. The scare quotes are for the people familiar with embedded real-time systems who seem to always find these comments and complain about how that word has an entirely different meaning when it comes to web applications.
[core dev] If you like to think about your application starting with its API, I think you'll really like learning more about DDP [1], the websocket JSON-based protocol that Meteor clients and servers speak. This is one of my favorite parts of the stack.
Rich clients built against a REST API tend to need some sort of client-side cache so that clients can avoid repeated RTTs back to the server for data, and thus some sort of websocket-based invalidation system so that the server can push fresh data into that cache in real time. That's doable, but a total bummer for interoperability and shared tooling. Since the implementation of those things is usually custom to each app, it's rare to see one real-time app connected to another the way we can bolt server-based REST apps together. And there's no `curl` for this kind of endpoint.
DDP is actually quite simple. The spec is just a couple pages of markdown. It lets servers publish changing data sets to the client and it implements once-and-only-once remote procedure invocation. It runs over a websocket or over SockJS. Eventually we'll also define a binary TCP/TLS mapping for use between servers.
When you write `Meteor.publish` in a Meteor server, you're defining a real-time DDP endpoint, like a streaming version of GET. The server makes the common cases easy -- publishing a realtime MongoDB query to a client is a one-line function in Meteor -- but you also have access to the low-level DDP messages if you want to do something more advanced like publishing the output of a GPS sensor or a stock ticker.
There aren't any special bindings between Meteor clients and servers, just the standard DDP messages that go back and forth. So you can implement either side of the wire using something else. And there are some third-party implementations of both the client and server in the field now. You can write a Meteor front-end against a Java DDP backend. You can connect a native iPhone app to a Meteor backend. Or you can have two Meteor server processes, one subscribed to the other. (There's been discussion of all these cases on the mailing lists. We use server-to-server DDP heavily in Galaxy, the hosting product we're working on.)
Very cool! I had seen the DDP notes in your repo when Meteor was first announced, but wasn't sure how established that protocol was, and how closely Meteor intended to follow it (I didn't realise it came from the Meteor team). Sounds like it's time to take another look :)
Cons: 0. It's non-npm package manager feels like NIH to me
I was initially put off by this as well, and it compelled me to check out Derby.js as an alternative since it looked like Derby wasn't ignoring widely adopted tools like grunt and NPM. But after using Derby for a bit, I noticed that I was back to doing more boilerplate coding than I'd like and I decided to give Meteor another chance.
Now I see the the benefits of the closed ecosystem. In Meteor you are dramatically constricted in choice, but everything that is available to you works effortlessly together. If you install a package, you pretty much know it's going to work.
It's almost like if you imagined Meteor as a Ruby framework (god forbid), and we ignored all of the client-side magic, this philosophy alone would provide value. Because this framework might include pared down versions of capistrano, Mongoid, Devise, Unicorn, Heroku and others and integrates these tools together into one well-thought-out holistic whole. And all of the pieces of this project moved forward in unison, instead of forcing developers to play whack-a-mole with all of the moving parts.
So beyond the beauty of no-fuss reactivity, the benefits of tight front/backend coupling, being able to code in Coffeescript from top to bottom (which is a big selling point to me), I really think that what is currently seen as a negative regarding the ecosystem is going to develop into one of its over-riding strengths.
Suffice it to say, I'm sold on Meteor. :) Both in its current state given its youth, and in the direction it is moving.
> The biggest con, for me, is that Meteor is basically limited to web applications
You can build phonegap apps in Meteor. There are tools that bundle it very quickly such as https://github.com/SpaceCapsule/Meteor-cordova. While technically a web app it goes a step further than other platforms can do since you can have an offline web app with offline data (in a cordova app).
I've also used the DDP backend for C# applications. In fact you can remove the entire web-app functionality of Meteor and use it just as a back-end to store data like a reactive database.
> I occasionally run into weird variable scoping issues
Typically you have to make sure your global variables aren't shared by different closures. There are articles that explicitly deal with this with the Meteor.bindEnvironment method.
There is a spiderable package that does allow SEO.
Google's AJAX guidelines don't really mean much (at least as of the beginning of this year, I haven't done SEO work in a bit). I mean, for SEO purposes using the guidelines is better than not using them, but competitive SEO sites don't depend on the Javascript execution of Google's crawlers.
I do admit I have a couple of problems with the spiderable package. Google indexes a 'loading page' but I think I've implemented it incorrectly since others don't have the issue.
Google's crawlers don't execute the javascript. A phantomJS script captures the raw text of the page by calling itself then when google crawls the page it gives this pre-rendered html back.
if "Meteor is one of the most comprehensive and smooth frameworks for making web applications available today." then how could you be stuck with just mongodb? or without seo?
not a dig at you, but at the guy who posted it below. it's actually nice to see someone posting that something actually has downsides.
In defence of that statement (although I'd agree it's a bit strong wrt Meteor's current state) the vast majority of web apps can get by with Mongo and without SEO (Google can't cache pages behind a login anyway). For a young framework it's come an exceptionally long way, and I haven't hesitated to use it in production for those use-cases that fit. It's just... yeah, important to note that not all use-cases fit (and they probably don't need to--I'd rather see them focus on what they're good at and be upfront about it).
creating a another driver for Meteor is really big task. Need a lot of time and commitment.
For now think Meteor as the easy way(may be the best) to build apps ontop of the MongoDB.
It works for some cases, but it quite limited in the type of database tables it will support. And in the end it's polling mysql for changes to feed to meteor clients.
I also added meteor support to a leaflet-draw package to allow users to share drawing on a map:
I have dabbled in it. I found it hard to learn and mysterious, but when things work it is amazing.
Meteor is a combination of handlebars, jquery, mongo, sockets, and a handful of other technologies. It can be hard to debug or develop unless you are familiar with those technologies. I think meteor would benefit from more transparency, make it clear which frameworks provide which features.
You will find more applicable documentation by searching "Handlebars Templates" instead of "Meteor Templates".
It's really great technology and a lot of fun to program in! My only problem with it is its so closely tied to Mongo. There are ways around this already I believe. However official SQL support is coming soon, which I'm very excited about.
If real time collaboration is at the core of your web app, then you'll love Meteor.js.
If you're looking for an alternative thats much more versatile and less opinionated I would recommend Sails.js http://sailsjs.org/ which is basically Rails for JS based on Express.
As other have hinted at, it's definitely worth learning, like most things. Get roughly familiar with it and other projects, that way when it comes time to pick a tool for a project, you'll have a better set of options to pick from.
I would like it to be supported on my RaspberryPi, but it isn't (apparently), so I don't use it. There are other nodey frameworks out there that just require node itself, so I'm looking at those for the moment.
after reading some github issues and some source code... There is also sails, and probably tons of other express/socker-io boilerplate frameworks. But meteor has this facebook guy on the homepage. Your boss will love it.
Simply put, express is a server-side node library, Meteor is everything possible. Server-side, client-side, database, different package system, different philosophy.
I started using Rails in professional work in late 2005. That turned out to be a good decision. There is hype around Meteor in the same way there was hype around Rails in 2004/2005. The praise and objections are similar. Meteor is not Rails, so don't go looking for too many parallels. And the development climate in 2013 is not the same as 2005. You won't be able to predict Meteor's success or failure in five years, so it's not worth speculating.
When Rails came out, I was ready for it, technically speaking. My skills were in the right place and I was ready for a change. Similarly, I felt I was in a good spot to learn Meteor last year.
So the real question is, are you excited, ready, and able to learn it? If so, go for it. The worst that will happen is you will learn a new programming paradigm (perhaps) and it will inform any other development work you do.