8 ms·

I like Meteor.js because I'm lazy

89 points by halisaurus 13y ago

jumpman222 13y ago
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!
nonchalance 13y ago
Have you tried similar frameworks like Derby (http://derbyjs.com/ http://derbyjs.com/)? If so, can you compare your experiences?
- deleted 13y ago
  [deleted]
  - deleted 13y ago
    [deleted]
- hansgru 13y ago
  > Have you tried similar frameworks like Derby (http://derbyjs.com/ 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)
  - andersnolsen 13y ago
    Did you check out the meteor package "spiderable"? It might need to mature a bit but it might do the trick
    - hansgru 13y ago
      > Did you check out the meteor package "spiderable"? It might need to mature a bit but it might do the trick Of course I did :). It's not usable at all :). It's also not reducing the initial loading time (very high for any public webpage).
- akbar501 13y ago
  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.
wc- 13y ago
It was fun developing the MVP for https://lawyermatch.me 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.
muraiki 13y ago
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 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).
prezjordan 13y ago
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.
- ilaksh 13y ago
  If you build a working system with Meteor and then re-implement some or all of it, doesn't that mean you are in fact re-inventing the wheel?
  - mercer 13y ago
    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.
oddshocks 13y ago
Stop it, JavaScript. Stop it. Stop being used for application programming. Stop.
- collypops 13y ago
  Why?
  - javis 13y ago
    Because god forbid people write code in language he doesn't like.
  - sfjailbird 13y ago
    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.
    - Kiro 13y ago
      JavaScript is my favorite language. I love everything about it.
    - dashoffset 13y ago
      Meteor already supports CoffeeScript and a few other languages that compiles to JavaScript.
    - tete 13y ago
      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!
omarrr 13y ago
Always amazes me how some posts like this one have zero comments in the blog itself but a dozen in HN.
- flylib 13y ago
  that's pretty common, HN threads usually get more comments then on the actual site, comments on actual sites usually don't do that good at all
dpearce 13y ago
We (http://differential.io 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. An example app: http://assistant.io http://assistant.io
rglover 13y ago
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 https://properapp.com) and it's running pretty well. The latest dev shop outlines what's in store for the 1.0 release (http://www.meteor.com/blog/2013/10/01/geoff-schmidt-at-devshop-8-getting-meteor-to-10 http://www.meteor.com/blog/2013/10/01/geoff-schmidt-at-devsh...) and based on where they're at now, it's exciting to think of what will be possible. Definitely not a toy, though, and something that should be evaluated carefully.
- dalerus 13y ago
  Just checked out your service, looks great. 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.
  - rglover 13y ago
    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.
  - rglover 13y ago
    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 http://vimeo.com/75510644 (a bit out of date, though, as it's missing the audit trail and permanent agreement features).
- creamyhorror 13y ago
  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.
sgdesign 13y ago
If you're curious, here's another example (open-source) Meteor app: http://telesc.pe http://telesc.pe
ilaksh 13y ago
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.
- miloszf 13y ago
  I definitely agree with your main point. 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.
- eatmyshorts 13y ago
Herbert2 13y ago
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?
joecarpenter 13y ago
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. This pretty much sums my experience with Meteor.

89 points by halisaurus 13y ago

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!

nonchalance 13y ago

Have you tried similar frameworks like Derby (http://derbyjs.com/ http://derbyjs.com/)? If so, can you compare your experiences?

deleted 13y ago
[deleted]
- deleted 13y ago
  [deleted]
hansgru 13y ago
> Have you tried similar frameworks like Derby (http://derbyjs.com/ 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)
- andersnolsen 13y ago
  Did you check out the meteor package "spiderable"? It might need to mature a bit but it might do the trick
  - hansgru 13y ago
    > Did you check out the meteor package "spiderable"? It might need to mature a bit but it might do the trick Of course I did :). It's not usable at all :). It's also not reducing the initial loading time (very high for any public webpage).
akbar501 13y ago
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.

wc- 13y ago

It was fun developing the MVP for https://lawyermatch.me 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.

muraiki 13y ago

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 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).

prezjordan 13y ago

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.

ilaksh 13y ago
If you build a working system with Meteor and then re-implement some or all of it, doesn't that mean you are in fact re-inventing the wheel?
- mercer 13y ago
  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.

oddshocks 13y ago

Stop it, JavaScript. Stop it. Stop being used for application programming. Stop.

collypops 13y ago
Why?
- javis 13y ago
  Because god forbid people write code in language he doesn't like.
- sfjailbird 13y ago
  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.
  - Kiro 13y ago
    JavaScript is my favorite language. I love everything about it.
  - dashoffset 13y ago
    Meteor already supports CoffeeScript and a few other languages that compiles to JavaScript.
  - tete 13y ago
    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!

omarrr 13y ago

Always amazes me how some posts like this one have zero comments in the blog itself but a dozen in HN.

flylib 13y ago
that's pretty common, HN threads usually get more comments then on the actual site, comments on actual sites usually don't do that good at all

dpearce 13y ago

We (http://differential.io 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. An example app: http://assistant.io http://assistant.io

rglover 13y ago

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 https://properapp.com) and it's running pretty well. The latest dev shop outlines what's in store for the 1.0 release (http://www.meteor.com/blog/2013/10/01/geoff-schmidt-at-devshop-8-getting-meteor-to-10 http://www.meteor.com/blog/2013/10/01/geoff-schmidt-at-devsh...) and based on where they're at now, it's exciting to think of what will be possible. Definitely not a toy, though, and something that should be evaluated carefully.

dalerus 13y ago
Just checked out your service, looks great. 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.
- rglover 13y ago
  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.
- rglover 13y ago
  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 http://vimeo.com/75510644 (a bit out of date, though, as it's missing the audit trail and permanent agreement features).
creamyhorror 13y ago
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.

sgdesign 13y ago

If you're curious, here's another example (open-source) Meteor app: http://telesc.pe http://telesc.pe

ilaksh 13y ago

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.

miloszf 13y ago
I definitely agree with your main point. 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.
eatmyshorts 13y ago

Herbert2 13y ago

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?

joecarpenter 13y ago

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. This pretty much sums my experience with Meteor.