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.<p>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.<p>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.<p>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.
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.<p>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.<p>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.<p>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.<p>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.<p>T
I wrote about Meteor here: <a href="http://blog.jasoncrawford.org/meteor-demystified" rel="nofollow">http://blog.jasoncrawford.org/meteor-demystified</a><p>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.<p>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.
I want to clear some things:<p>0. Meteor is in version 0.6.6.4 so there are things not as good as they could/will be.<p>1. scaling: meteor is 100% scalable. There are meteor smartcollections which use the MongoDB optlog. Nice read: <a href="http://meteorhacks.com/lets-scale-meteor.html" rel="nofollow">http://meteorhacks.com/lets-scale-meteor.html</a> .<p>2. Right now you have to stick to MongoDB this will change in a later version.<p>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.<p>4. You can use meteor with phonegap right now.<p>Will meteor solve all your problems? No!<p>Will meteor will make you not think? No!<p>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.
... or Derby [1]. I'm curious about things the HN crowd has been building with this kind of stack.<p>[1] <a href="http://derbyjs.com" rel="nofollow">http://derbyjs.com</a>
> Do you think it's worth learning?<p>Everything(almost) is worth learning , the question is , is it worth using ? you give 0 clue as to why you'd need that stuff.
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.<p>I built <a href="http://opentalk.me" rel="nofollow">http://opentalk.me</a> with it
Its lots of fun learning with it. It tries to remove as much boilerplate as possible.<p>They have packages to take care of most of the stuff for you such as their accounts-ui package.<p>One helpful place to learn meteor from beginner to advanced is via the screencasts on.<p><a href="http://EventedMind.com" rel="nofollow">http://EventedMind.com</a>
Of Course Yes.
Just spend few hours with DiscoverMeteor[0] book. You'll be amazed.<p>[0] - <a href="http://www.discovermeteor.com/" rel="nofollow">http://www.discovermeteor.com/</a>
Our company has doubled down on Meteor. We start all greenfield apps in meteor now.<p>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.<p>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.<p>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.<p><a href="http://differential.io/blog/the-current-challenges-of-building-a-meteor-app" rel="nofollow">http://differential.io/blog/the-current-challenges-of-buildi...</a><p><a href="http://differential.io/blog/meteor-killin-rails" rel="nofollow">http://differential.io/blog/meteor-killin-rails</a>
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:<p>- 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!)<p>- 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.<p>- 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.<p>- 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.<p>- 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.
Yes, it's worth learning.<p>3 good reasons why:<p>1. It's ambitious.<p>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).<p>2. It's as easy or as complex as you want it to be.<p>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.<p>3. It embraces the eco-system.<p>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.<p>Biggest upcoming updates:<p>* Meteor UI.
Better approach then any other UI framework out there (including Facebook's react or FTLab's fruitmachine)<p>* Galaxy.
Deploy and scale your app on your own infrastructure or in the cloud by pressing a few buttons.<p>To counter a few of the cons in this thread:<p>* 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.<p>* 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.<p>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: <a href="http://docs.meteor.com/#sevenprinciples" rel="nofollow">http://docs.meteor.com/#sevenprinciples</a>
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.<p>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.<p>Either way, awesome tool!
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.<p>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.<p><i>Pros:</i><p>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).<p>1. It's also the least complicated way of sharing code between the browser and the server that I've seen to date.<p><i>Cons:</i><p>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.<p>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.<p>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).<p>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.)<p>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.<p>Generally, I love working with Meteor. I know I've written more cons than pros, but the pros I've listed are <i>huge</i>, and they've allowed me to work on cool stuff. You just need to know what you're getting into.<p><i>Footnotes/Links:</i><p>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.<p>1. <a href="http://stackoverflow.com/questions/10165978/how-do-we-or-can-we-use-node-modules-via-npm-with-meteor" rel="nofollow">http://stackoverflow.com/questions/10165978/how-do-we-or-can...</a><p>2. <a href="https://github.com/meteor/meteor" rel="nofollow">https://github.com/meteor/meteor</a>
I've played with meteor a bit and and also hacked on drorm's mysql back-end:<p><a href="https://github.com/drorm/meteor-sql" rel="nofollow">https://github.com/drorm/meteor-sql</a><p>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.<p>I also added meteor support to a leaflet-draw package to allow users to share drawing on a map:<p><a href="http://leafletdraw.meteor.com/" rel="nofollow">http://leafletdraw.meteor.com/</a><p>Powerful and fun!
I have dabbled in it. I found it hard to learn and mysterious, but when things work it is amazing.<p>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.<p>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.<p>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 <a href="http://sailsjs.org/" rel="nofollow">http://sailsjs.org/</a> 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.