Ask HN: Thoughts on Meteor.js?
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 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.
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.
T
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.
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.
0. Meteor is in version 0.6.6.4 so there are things not as good as they could/will be.
1. scaling: meteor is 100% scalable. There are meteor smartcollections which use the MongoDB optlog. Nice read: http://meteorhacks.com/lets-scale-meteor.html .
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.
Everything(almost) is worth learning , the question is , is it worth using ? you give 0 clue as to why you'd need that stuff.
I built http://opentalk.me with it
They have packages to take care of most of the stuff for you such as their accounts-ui package.
One helpful place to learn meteor from beginner to advanced is via the screencasts on.
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.
http://differential.io/blog/the-current-challenges-of-buildi...
- 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.
3 good reasons why:
1. It's ambitious.
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.
Why is it better? I've used Meteor UI and it blows (so far). I'm interested in knowing why the new one will be better than react or say angular.
Angular is better by a long shot
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.
Either way, awesome tool!
Was it worth learning? I'd say yes, it has a low barrier to entry and is great for practicing front-end development.
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.
1. http://stackoverflow.com/questions/10165978/how-do-we-or-can...
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.)
[1] https://github.com/meteor/meteor/blob/devel/packages/livedat...
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.
It's basically a lock-in, which I don't find appealing. If Meteor fails or moves on, you're stuck. You can't just swap some NPM modules around.
> There's not really any SEO capability
There is a spiderable package that does allow SEO. It uses Google's AJAX guidelines (added using meteor add spiderable) : https://developers.google.com/webmasters/ajax-crawling/
> 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.
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.
You can build phonegap apps in Meteor. There are tools that bundle it very quickly such as https://github.com/SpaceCapsule/Meteor-cordova.
Cool! I hadn't seen that before.
I use 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.
Awesome. Is that documented anywhere?
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.
The webapp stuff is mentioned on their blog:
http://www.meteor.com/blog/2013/08/14/meteor-065-namespacing...
+ I prefer something that's open source.
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.
I never run into SEO issues. With iron router you have normal routes and with the spiderable package google finds everything very well.
https://github.com/drorm/meteor-sql
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:
http://leafletdraw.meteor.com/
Powerful and fun!
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".
If real time collaboration is at the core of your web app, then you'll love Meteor.js.