seems like their selling point is data binding + client syncing. Considering I can do that with Ractive/React + Firebase, what's the advantage of using Meteor?
seems like their selling point is data binding + client syncing. Considering I can do that with Meteor, what's the advantage of using Ractive/React + Firebase?
The reasons I prefer Meteor (in no particular order):
* Fully automated build chain. No matter what kind of preprocessors I use, all my code is compiled, bundled, and hot reloaded into the application. CSS updates are automatically live injected into running applications without a browser refresh. I don't have to write any build chain code, just application code.
* Isomorphic client/server APIs, with code sharing built into the build chain. I'm using the same language with the same APIs in both environments, drastically decreasing redundant code. Clients can simulate server RPCs using the same function as the server while it waits for the server's response. If I want, I can easily make the client's simulation code different from the server's such as when I want to obfuscate something, or simply disable client simulation for certain RPCs. The package system incorporates both server and client assets, allowing drop-in full-stack components, such as...
* The Accounts UI component. A drop-in, automated SRP+OAuth authentication system that's easy to customize and restyle, or build from scratch using the simple JS authentication APIs. It takes minutes to make a web application with a fully-featured and secure authentication system with password-based and 3rd party OAuth login methods. And logging in never requires a refresh.
* Already glued together. Endpoints don't have to be hooked up; they're hooked up from default. Publish data on the server. Subscribe on the client. Add authorization rules, and I have a fully functional web application with realtime data updates, with virtually no glue code.
You still need JavaScript on the client, so you have to switch context between Python and JS if you're a single dev, or have different team members work on the client vs. the server. Meteor is JavaScript everywhere.
The way they handle client syncing is a bit different though. Meteor actually hosts a mini-mongo instance on the client allowing for better offline support.
I imagine it's just using localStorage under the hood, and it's selling point is that it exposes the mongo api you'd use for interacting with the db, or is there something else that I missed?
More that it fully simulates the mongo api. When you perform an insert/update on the client, the following will happen:
1. The command will be sent to the server.
2. The command will be performed on the local database, but backing up the original local DB state so that it can be reverted if needed.
3. Immediately, any helper functions used by templates which rely on data from the DB will react to the change in the local DB and inform their template instances to update just the relevant part of the DOM.
4. The server will eventually get the request, and authorize it based on allow/deny rules.
5. If the command was allowed, the server will update the actual DB, and use MongoDB's oplog to notify all other server instances that the data has changed.
6. Server instances will send the changed data down to all subscribed clients, which update the state of their local DBs, causing the templates to re-render the relevant parts of the DOM.
7. If the request was denied on the server, the server informs the requesting client, and the client patches up its local DB to the actual DB's state, also reverting the DOM state.
So you have built-in latency compensation and full-stack reactivity by default. The client anticipates the server's response, making the application feel extremely responsive. But if something goes wrong, the client patches itself up with the actual result. Of course you can avoid latency compensation altogether where you don't want it - just avoid using the isomorphic API on the client and use RPCs instead. The servers will still inform the other server instances and push the changed data down to all the subscribed clients, but the requesting client has to wait like everyone else before the DOM is updated.
Another point to add is Meteor's EJSON, which is a simple spec for defining how any complex, constructed or factory-made JavaScript objects should be serialized to JSON, and then deserialized back into a full JS object with behavior. Objects inserted/retrieved to/from the MongoDB or Session variables are automatically serialized/deserialized if you have made them EJSON compatible (quite easy to do, and built-in for Date and binary objects). By sharing EJSON definitions on the client and server, you have a flexible basis on which you can build an isomorphic model layer to your liking. The constructed model objects you're working with can easily be made identical (truly or superficially, depending on your needs) on both the client and server code.
seems like their selling point is data binding + client syncing. Considering I can do that with Meteor, what's the advantage of using Ractive/React + Firebase?