Seems rather fat. Fatter than what I've seen for Knockout, or Ember, or even Backbone.
As I suspected this idea of just dropping any package and bang it works depends on that package having been made available by the Meteor team, and the requisite wrapper/bindings made around the original package. Which means now using Meteor means you must use their package, which even with best intentions, means their team will have to keep up to date with every package you'd like to use, every new version, the bugs, etc.
What if my data comes from multiple sources ("the cloud" and "big data" and "3.0" means your apps don't all share the same persistence layer, and likely use several)
What if I push 1000 records of data to the client, in the html for efficiency and network reasons, to power my fancy D3 chloropleth, and the client interface allows manipulation of that (local) data. How do I take advantage of Meteor's data binding system? This is something almost every serious application does -- updating a local data structure and propagating that change to several views.
Overhead of having all these sockets open? If I want to change 20 items and then update my view, do I now have to write the boilerplate to store up 20 changes, then package, then send in one shot down the Meteor pipe? Do I make 20 calls via client DB bindings? Probably the former. Which means I end up doing a lot of work that I wouldn't have if I had a local model with CRUD methods (like Ember, Backbone, etc).
Latency compensation. Sounds great. So I say "pay my bill" and my interface updates with an optimistic confirmation. Great! Now I can drive my kid to the soccer game. Hope I notice that the number got switched back (server fail). How will I notice? Hope the developer implemented a noticeable notification system...
Security? Anyone with a browser can change my DB? How do you secure that? Log in? Now logged-in people can change my DB from their browser? Whitepaper is necessary, so this aspect can be tested.
Great team. Good ideas. But it is quite early yet.
Seems rather fat. Fatter than what I've seen for Knockout, or Ember, or even Backbone.
As I suspected this idea of just dropping any package and bang it works depends on that package having been made available by the Meteor team, and the requisite wrapper/bindings made around the original package. Which means now using Meteor means you must use their package, which even with best intentions, means their team will have to keep up to date with every package you'd like to use, every new version, the bugs, etc.
What if my data comes from multiple sources ("the cloud" and "big data" and "3.0" means your apps don't all share the same persistence layer, and likely use several)
What if I push 1000 records of data to the client, in the html for efficiency and network reasons, to power my fancy D3 chloropleth, and the client interface allows manipulation of that (local) data. How do I take advantage of Meteor's data binding system? This is something almost every serious application does -- updating a local data structure and propagating that change to several views.
Overhead of having all these sockets open? If I want to change 20 items and then update my view, do I now have to write the boilerplate to store up 20 changes, then package, then send in one shot down the Meteor pipe? Do I make 20 calls via client DB bindings? Probably the former. Which means I end up doing a lot of work that I wouldn't have if I had a local model with CRUD methods (like Ember, Backbone, etc).
Latency compensation. Sounds great. So I say "pay my bill" and my interface updates with an optimistic confirmation. Great! Now I can drive my kid to the soccer game. Hope I notice that the number got switched back (server fail). How will I notice? Hope the developer implemented a noticeable notification system...
Security? Anyone with a browser can change my DB? How do you secure that? Log in? Now logged-in people can change my DB from their browser? Whitepaper is necessary, so this aspect can be tested.
Great team. Good ideas. But it is quite early yet.