5 ms·

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?

rco8786 12y ago
You can ask it either way. 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?
- findjashua 12y ago
  For starters: 1. You can reuse your existing API, or choose the stack you're comfortable with (I prefer Python to Javascript and Postgres to Mongo) 2. They are being used in production by high traffic websites (Guardian and Instagram respectively), so they're more battle tested 3. Their press releases aren't loaded with buzzwords and hyperbole
  - dandv 12y ago
    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. Anyway, Meteor offers much more than data binding and client syncing. See http://www.meteorpedia.com/read/Why_Meteor http://www.meteorpedia.com/read/Why_Meteor
  - sbking 12y ago
    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.
    - anonfunction 12y ago
      Great overview of the benefits!
- philsnow 12y ago
  This is a completely fair question to ask, from either direction.
rgoomar 12y ago
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.
- findjashua 12y ago
  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?
  - sbking 12y ago
    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.
    - 12y ago

rco8786 12y ago

You can ask it either way. 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?

findjashua 12y ago
For starters: 1. You can reuse your existing API, or choose the stack you're comfortable with (I prefer Python to Javascript and Postgres to Mongo) 2. They are being used in production by high traffic websites (Guardian and Instagram respectively), so they're more battle tested 3. Their press releases aren't loaded with buzzwords and hyperbole
- dandv 12y ago
  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. Anyway, Meteor offers much more than data binding and client syncing. See http://www.meteorpedia.com/read/Why_Meteor http://www.meteorpedia.com/read/Why_Meteor
- sbking 12y ago
  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.
  - anonfunction 12y ago
    Great overview of the benefits!
philsnow 12y ago
This is a completely fair question to ask, from either direction.

rgoomar 12y ago

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.

findjashua 12y ago
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?
- sbking 12y ago
  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.
  - 12y ago