There is an unfortunate belief that any programming system which is significantly easier to use must automatically have caveats that make it unfit for 'production' use. And another similar belief that such systems are unfit for use by 'real' engineers. For example, if AngularJS had come up with an easier-to-understand way of creating components (directives) then it may have been dismissed as just another tool for novices. But some aspects of AngularJS are sufficiently complex that it is acceptable to 'real' engineers.
These are false beliefs and one of the reasons that (this is obviously an estimate off the top of my head) about 95% of programmer time is wasted solving problems that have already been solved numerous times. I see people hinting at security or other concerns related to using Meteor in production, but I have yet to see an example where one of these concerns actually caused a production issue.
I would be very interested to hear if anyone had actually tested Meteor in production, or had specific concerns related to security or anything that leads them to the conclusion that they must come up with their own different/more complex solutions to problems that Meteor solves.
Taking advantage of a system that solves 90% of your problems rather than reinventing six wheels is not lazy. Its just sane and mature.
The psychology of programmers related to tools and frameworks is childlike. Its as if everyone is in a playroom with a bunch of tiny blocks of different shapes. Every once in awhile a kid figures out how to construct generally useful connector shapes or recognizable objects from the smaller blocks. Then when another kid wants to use the larger pre-composed structures to play with, everyone makes fun of him because he is 'cheating' and must be too dumb to use the tiny blocks.
I've used it on a production site. There still is a learning curve, as with any new technology, but I've been very happy with it. I hope to do more with it. I'm working on a CMS built with Meteor, as my clients tend to be less than technically proficient.
The main problem I've had with it relates to IE7/IE8. The standard password encryption results in a JS error on those browsers due to the password encryption taking too long. We run the whole site on top of HTTPS, though, so we took a little hack to remove the extra client-side encryption on IE7/IE8. It's not ideal, but then again the default encryption for passwords is there primarily for those that don't use HTTPS (passwords are sent over the wire hashed such that HTTP sessions still maintain safety with the passwords...this hashing is slow by design, and the IE7/8 javascript engine isn't good enough to do it in a reasonable time frame).
I have deployed app written in meteor serving an API, and while it's a solid framework already, it still has some issues. Form handling is a bit of a hassle, compared to the rest, because it's still all done manually, and deployment on a custom server, while relatively straightforward, is a bit of a pain, because you end up having to manually reinstall some npm packages every time you update code. None of that are fundamental issues with the design of the framework, though. There's some quirks that aren't yet worked out, because it's a young tool, but it's already extremely powerful.
I've been learning programming for about a year and Meteor was the first Javascript framework that I used. I found it remarkable how quickly and easily I was able to get something up and running, given that I had relatively little experience with Javascript (I read most but not all of Eloquent Javascript).
I used it to make an online multiplayer Go board where you can see your opponent moving the pieces, for the purpose of teaching games: https://github.com/muraiki/senseinogoban Being able to make something like this as a beginning programmer was really exciting! Since I'm pretty new to programming I don't know if the code is that great but it might give some ideas to people who are interested in using Meteor in a graphical way (as opposed to something like a To Do list).
I'm a big fan of Meteor. As a front-end dev that got his start in JavaScript with jQuery, it's been really easy to settle into. I did a pre-release of a Meteor app into production today (https://properapp.com) and it's running pretty well.
I'm surprised that you're using Meteor for what would seem to be a single-user use-case. Meteor's strength seems to be multi-user real-time apps, but this looks more like a job for Angular/Ember plus an API backend.
I was looking toward Meteor for a similar project because of its handy client-server syncing capability, but decided not to use it because it didn't seem to suit the more traditional webpage model and the click-to-save-changes paradigm. But your site is making me reconsider this. I've been learning and implementing my site in Angular/Restangular, which involves me writing code to POST to/GET from my Rails backend. I'm aiming to let users add and remove nodes in a plan/document and rearrange their ordering - would that be easier to do in Meteor? I'd love to make use of Meteor's object syncing and other features. What's your experience been like? Did you try Angular or other JS MV* frameworks?
By the way, I love your site's design and iconography. If you built the whole service alone, I'd be very impressed.
Re: the choice for Meteor, this was somewhat of a fluke. I'm not a traditional developer, and only dabbled with Rails and the like on an anecdotal basis. My past experience with things like jQuery made it easy to pick up Meteor and its basic concepts, so I just started building the app above (it's something I really wanted/needed and I didn't want to waste a lot of time inner-bickering about what tech to build it with).
I guess for your idea I'd have to see a sketch, but on the surface, yes, I'd say something like that would be pretty easy. The cool thing about Meteor is that it takes a lot of the thinking/logic out of the loop. So for example, you would have the nodes as a Mongo collection and for each plan/doc, just store their position info. Meteor/Mongo update automatically, so if say you used something like jQuery UI drag/drop, you would just have it update the given object in Mongo when you pick it up or put it down. Make sense?
My overall experience has been that I haven't gotten frustrated with Meteor like I did with other frameworks. It's not as rigid, sure, but if you take the time to develop a good design practice, it can be really efficient. Plus, having both front and backend code in JS is a serious time saver.
Thanks for the complements on design. Save for the octopus, logo, and animated gifs outlining the process (oh, and the nice header on the blog), this was a 100% solo effort.
It's cool how it does the multi-user realtime stuff, but if you think about it, that's solving problems that almost every networked application deals with (latency, consistency, etc) but in more subtle ways. I'd say really its strength is just how amazingly simple and easy it is to get something going.
It's been a year since I played with it, but at least at the time the weak side seemed to be integrating with any existing systems you may have, whether front or back or middle or sideways. In those cases the magic doesn't work for you and you've got to figure out how to plumb it. (Again this may have improved in the past year.)
I would sign up, but I really want to see a service before giving over my information. Screenshots, video, really anything. I dug around a bit hoping that you might have some screenshots in the KB or blog, but no luck.
Working on this. I released the app to my mailing list a bit ahead of the public (just wanted to get it out the door). Going to add in a tour of the service and some demo videos this week. Email me your info (email address/twitter) and I'll shoot you an update when there's more available: ryan@properapp.com.
Actually, I take it back. I do have something you can look at.
Here's a video I sent out last week going over the signature process: http://vimeo.com/75510644 (a bit out of date, though, as it's missing the audit trail and permanent agreement features).
Off topic, but if you're in pre-release, how do you have enough metrics to say "most developers" pick the Coffee Shop plan or is it just marketing fluff?
I really like the color scheme and if I wasn't in a "boring" contract I'd be looking directly into your services.
Combination of marketing fluff and early feedback. It's by no means scientific. Just anecdotal "yeah, I'd pick the middle plan," or "the mid-level price seems right." Something I plan to update as I get more data, but felt like a good starting point (also the plan I have myself on).
Thanks for the response! I was kind of wondering if you'd had a lot of pre-release devs or not, I'm always curious at what point people release.
I'm on what I'll call a floater business operations contract. It's an ongoing thing at 40 hours a week (at a great company) working on several different projects and providing assistance where needed. As far as stack, it's mainly a Microsoft establishment with other things sprinkled in (and getting more so with newer projects).
While Meteor and Derby deliver similar functionality, the approach used by each is so different that people will likely choose one vs. the other based on the style of programming they are used to.
Meteor: Meteor is a tightly integrated full stack framework where you program in a synchronous style. Meteor will likely be the solution of choice for people who want to build real-time applications in pure JS in a synchronous style.
Derby: Derby on the other hand also delivers a real-time development framework. However, Derby allows you to program in Node's traditional asynchronous callbacks style. Derby will likely be the solution of choice for developers who want to build real-time applications in pure JS using an asynchronous style.
I intentionally glossed over feature differences because the approach of each team is different enough that people will likely select one vs the other based on preferred programming styles (assuming neither team drops the ball...unlikely given the skills of the devs on each team).
SailsJS: It's also worth mentioning SailsJS b/c they are delivering the rapid development benefits of Meteor and Derby, but from a vastly different approach. Sails has a very cool evolutionary design and is a project worth following.
The big win for developers will be that these teams (and I'm sure other will emerge) are pushing the boundaries of development speed. This genie is now out of the bottle.
The other thing that's obvious is that there's a gaping hole for someone to fill with a package-oriented approach vs. the framework approach. True, Meteor/Derby/Sails are all a bunch of packages, but what I mean is there is an opportunity for someone to collect a bunch of standard NPM modules into a comprehensive development environment. The end goal would be to deliver similar benefits as a framework, except that devs would have no abstraction layers to deal with (more complex, but more power).
SignalR: One last solution to mention. For .NET devs, Microsoft released SignalR.
> Have you tried similar frameworks like Derby (http://derbyjs.com/)? If so, can you compare your experiences?
I tried Derby.js because of one important for me missing feature of Meteor: serverside HTML rendering - required for search engines and also for CMS or content like applications. IMO Derby.js got it right there.
Unfortunately Derby.js is seriously lacking professional documentation of any kind: Meteor already has books and 2 very good and long enough video courses (from pluralsight and tutsplus)
It was fun developing the MVP for https://lawyermatch.me on top of Meteor. Would I recommend meteor in its current form (v0.6.5 or so) for a large production website? No, but neither do the core meteor devs. Would I use it again for a quick prototype? Absolutely, especially if you are already planning to use mongo, node, handlebars, or the other core meteor technologies.
I saw one of the core devs speak in Chicago a week or two ago, and the main feeling I came away with was that the Meteor team has a well planned roadmap of features, solid funding, and a plan for generating revenue, all of which will hopefully mean Meteor isn't going anywhere.
Edit - I think this article hits on some of Meteor's strengths re: ease of development, but some of the features Meteor uses to accomplish this turn into gotchas later. For example, the autopublish and insecure packages are awesome for a 5 minute demo but for anything further they should be removed. Without them, devs are back to thinking about queries and what clients receive what data, permissions, etc. These are very important things obviously but it might be a little misleading for someone using Meteor for the first time.
Totally acceptable to use Meteor first because you don't want to "reinvent the wheel" so to speak. It's fantastic for prototyping real-time concepts.
If your idea works, then you can "mature" your codebase a little. But, from the get-go, you'll want to make something usable, to see if your idea works at all. Meteor is perfect for that sort of thing.
Maybe it's more like custom-building a wheel to the exact specifications that you figured out when using a 'normal' wheel. Sometimes customization matters.
I really like Meteor too. It makes developing a sophisticated app incredibly easy. Even though it is only in preview mode, it is extremely polished. I can't wait to see what version 1.0 has in store!
Interesting enough, I found that Meteor is not production ready, in both current implementation (not mature) and some design decisions. I was thinking about writing blog post about it, but no idea when I'll have time to do it, so I decided to stop by.
I have experience with Meteor in production and had some serious performance-related problems. Not that they're not solvable, but some solutions kill some core design decisions of Meteor. Just in case - I didn't pick Meteor for the project, I was asked to help with it.
Anyway, here's short list:
1. Collection synchronization does not really work even for relatively small amounts of data (say 10k records).
- It does not make much sense to send few MB of initial data to the client. Paging API was moved to some distant future and you end up writing REST-like API on top of Meteor, which breaks idea of collection synchronization, which contradicts statement on their website - "no need to write REST APIs anymore". I don't say it is not usable at all, you just need to be really-really careful about what you send to client and it is easy to fail at this.
- SockJS (transport protocol used by Meteor) does not have rate-limiting built-in. If client connects using one of the polling transports and payload is too large to be received in 30 (? - vanilla SockJS uses 5) seconds, server drops connection thinking that client timed out. Partially, it is SockJS problem and partially it is Meteor problem, as Meteor will just send all outgoing data without caring if client is on slow connection. But because of previous point, generally it is bad idea to send large amount of data anyway.
- Server-side subscription API is very limited. Official documentation has following sample: reactively count number of admins in collection. This is done by listening on collection changes and counting admins by incrementing (when admin is added) and decrementing (when admin is removed) single variable. If there are 10k admins in database, increment function will be called 10k times.
2. Minimongo is interesting concept, but fails on many levels:
- It is MongoDB written in JS, but slow
- Does not have indexes ("client won't handle amounts of data for indexes to be viable"), aggregation, map reduce, etc. There's no official API to create index on server-side either.
- Its reactive - whenever model is changed, Meteor figures out which fields were changed and broadcasts changes to all listeners. And this is _not_ fast. Inserting 10k items to collection will take around 2 minutes on AWS large instance with node executable using 100% CPU.
- Because MongoDB is not "reactive", Meteor just polls collections every 5 seconds to see if they changed by outside application. I really hope it only tracks addition/deletion of records and not scanning through all rows in database during each polling iteration
- Meteor API is hiding MongoDB handle, but there's a way to get it (through hack) and use it directly. And it takes 3 seconds to insert same 10k items
3. Client-side is not as convenient as current MV* frameworks
- Meteor is using non-reactive templating engines and attempts to make them reactive. And this might be performance bottleneck, especially on mobile devices. When single variable changes, Meteor will re-render whole template. If you have some 3rd party plugins (like WYSIWYG editor, which injects own DOM markup), you have to wrap it with special blocks, which prevent Meteor from re-rendering them.
- As a result of previous point, DOM is not stable.
- Unlike AngularJS/Ember/etc, Meteor does not track individual variables. AngularJS does it by checking if variable changed in digest loop, Ember uses property-like system, etc. Meteor has global, flat namespace called "Meteor.session", where application stores _all_ reactive variables that can be referenced by their name. `Meteor.session.set('mymodule.hello', 10)`. It is hard to structure application, when core reactive part is just a singleton dictionary.
- Once you get used to bidirectional data binding between forms and models, it is hard to get away with events. But that's minor.
4. Overall architecture (nitpicking):
- Meteor API likes singletons. `Meteor.session`, `Meteor.methods`, `Meteor.templates`, etc. Single, flat namespaces everywhere
- Even though code can be written in a way it can run on both client and server, there are subtle core API differences. Like it is not possible to use `HTTP.get` on the client without callback, but it works on the server, just blocks the fiber. If you use callback on the server, you need to block the fiber manually (using future or fiber API), etc.
- No server-side templates. Yes, there's crawlable package for Meteor, but it is just PhantomJS (WebKit) that runs on the server and renders pages for crawlers. Yikes.
Joe, your criticisms are spot-on (I work at Meteor), though I feel you are not comparing Meteor to any existing framework, but rather to Meteor in a couple years. Most web developers are quite used to getting by without reactive templates, bidirectional binding, and server-side rendering (which are only just starting to be used together), and in what framework do efficient client-side database indexes (which we haven't implemented yet) come standard, let alone map-reduce? What's wrong with a better-than-REST protocol that is more or less like REST in the worst case?
If you're objecting to the principle of offering the Mongo API or HTTP.get on the client when it's not exactly the same API, we feel the benefits outweigh the costs. The client-side functionality will only get better over time, though there will always be some things you can only do on the server.
Since 3 touches on my area: We're fixing the unstable DOM problem with fine-grained DOM updates. Also, the flatness of Session is not related to how dependencies are tracked. Meteor has a better dependency-tracking system than Angular or Ember; it's more flexible and doesn't require annotations to tell the framework what's happening.
I'm running a Meteor production app myself and found similar performance bottlenecks.
However, the Meteor community has really done some great work in solving some core issues and others are on the 1.0 roadmap.
Some comments on this below based on our own experience.
> 1. Collection synchronization does not really work even for relatively small amounts of data (say 10k records).
The issues around polling and how the server side cursors/observe works is definitely not perfect. Started using the SmartCollections package which ditches polling altogether and goes with the MongoDB OPLOG for synchonization. Has been performing well for us so far and solved many issues around performance.
>2. Minimongo is interesting concept, but fails on many levels:
Really depends on the usecase. I'am not sure if there is any other alternative to MiniMongo at the moment for other frameworks.
The key thing is you really shouldn't expect to do many MB's of client data storage in your app.
>3. Client-side is not as convenient as current MV* frameworks
The key issue here is the how the DOM is re-written with the current rendering engine.
The new 'Meteor UI' rendering engine and component architecture is promising to solve this issues with html element level reactive-rendering as well as an method for proper UI components delivering similar capability to what Angular offers.
---
The framework is still growing up, but we are hard pressed to find something that delivers similar developer productivity.
Once you understand the framework and IF it fits your needs, Meteor can work well for production.
> Started using the SmartCollections package which ditches polling altogether and goes with the MongoDB OPLOG for synchonization.
Yes, I'm aware about this package. However, in my case, I had to reactively count number of items in collection. SmartCollections does not have `observe` for server-side cursors and core Collection implementation is slow, so I decided to use `setTimeout` to check collection size every few seconds, which turned out to be much faster than generic collection implementation.
> The key thing is you really shouldn't expect to do many MB's of client data storage in your app.
Plus, I was also referring server-side. Application does not work with node.js MongoDB driver, it still goes through thin minimongo layer, which hides most of the driver API. And it is not fast either (due to reactivity) - see insert performance example.
Overall, I don't say it is not possible to run Meteor app in production (I have one). It is just there are alot of different quirks and gotchas in Meteor that should be worked out manually or with help of community-created packages. And all this information is mostly scattered around StackOverflow, Meteor bugtracker or in Meteor source code itself.
It is quite unpleasant to stumble upon collection synchronization performance when you have most of the application in place.
Joe, thanks for providing details...it's very helpful.
Would you be willing to share a sample of the document schema that was causing problems when syncing 10k documents? I'm very curious to know if these were large or small docs, single schema vs. varying schema, etc.
It is mostly number of documents and their size. Single schema.
There are no indexes, so whenever client wants to find something in synchronized collection, it'll have to scan through all documents. With 10k documents it was locking up DOM (it was very noticable).
If documents are large, client won't be able to connect to the server with any of the polling transports - initial synchronization time exceeds 30 seconds and SockJS will drop connection. This is partially solvable by having reverse-caching proxy (i.e. nginx) forcibly compress all polling SockJS responses.
We (http://differential.io) have been using Meteor.js almost exclusively since switching from rails about 5 or 6 months ago and are very excited about where the framework is headed.
Obviously, it's still new and has some kinks but 1.0 is around the corner, and we've found the ease of development is well worth the few issues we've had to work around.
I was hoping some of meteor's users could answer a few questions about it.
Can meteor use Postgres instead of MongoDB? Could meteor do sync with the database through a server-side rest client (instead of mongodb)? Is TDD possible? Is CoffeeScript possible?
Because JavaScript sucks in a multitude of ways? I don't think anyone with experience developing in a few different languages disputes this, nor do I probably have to namedrop A-list developers who have renounced JavaScript for large systems.
It used to be the only choice for cross-platform web applications, but with cross-compilation emerging as a real alternative that is no longer true, so the sentiment has merit, and it is a proper criticism of a framework that relies entirely on writing everything in JS.
I am sorry, but this sounds like you simply don't know the language.
Javascript has one big problem and that is that most people either know it from front end people who are NOT really into programming and on the other side there are many people that just don't know JavaScript and use it like C-style languages, just because it might have some similarities with it.
That's actually a problem a lot of multi-paradigm, flexible, expressive and powerful languages suffer. People want to use it like the language they mostly used, get frustrated about how it's a different language and not just a slightly different syntax.
So either you do it like Python and force people into something or you have to deal with a lot of people, complaining about something they don't understand, which simply is easy with JavaScript, because it has a lot of features.
I mostly blame it to the fact that most people learn Java and a certain style of Java as their first language. It's actually saddening, because it causes computer science to become more and more a "just good enough" thing. It's sad, because it started with people (and with that I mean Ada Lovelace, just like various scientists in nearly every decade of the last century) who did what they did not because it was cool and well-paid to do computer stuff, have your own startup, etc., but because they had enough enthusiasm and imagination to make this possible. Lovelace in the 1th century(!) imagined that there could one day be "calculating machines" used to draw paintings!
These are false beliefs and one of the reasons that (this is obviously an estimate off the top of my head) about 95% of programmer time is wasted solving problems that have already been solved numerous times. I see people hinting at security or other concerns related to using Meteor in production, but I have yet to see an example where one of these concerns actually caused a production issue.
I would be very interested to hear if anyone had actually tested Meteor in production, or had specific concerns related to security or anything that leads them to the conclusion that they must come up with their own different/more complex solutions to problems that Meteor solves.
Taking advantage of a system that solves 90% of your problems rather than reinventing six wheels is not lazy. Its just sane and mature.
The psychology of programmers related to tools and frameworks is childlike. Its as if everyone is in a playroom with a bunch of tiny blocks of different shapes. Every once in awhile a kid figures out how to construct generally useful connector shapes or recognizable objects from the smaller blocks. Then when another kid wants to use the larger pre-composed structures to play with, everyone makes fun of him because he is 'cheating' and must be too dumb to use the tiny blocks.