Skip to content

Instantly share code, notes, and snippets.

@Raynos

Raynos/x.md

Created August 15, 2012 03:55
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save Raynos/3355703 to your computer and use it in GitHub Desktop.
Save Raynos/3355703 to your computer and use it in GitHub Desktop.
Download ZIP
Meteor vs Libraries
Raw
x.md

Meteor vs Libraries

  • Meteor: spawn the meteor command to run your static web server
  • Libraries: spawn a static-style server like browserify-server
  • Meteor: the browser updates when you change your files
  • Libraries: browserify-server reloads your browser when you change files
  • Meteor: manipulate mongo from the client
  • Libraries: Manipulate a server-side database from the client using clientmongo or manipulate distributed state from any client using distributed-map
  • Meteor: reactive handlebar templates update in real time based on mongo changes
  • Libraries: DOM widgets update in real time based on crdt changes
  • Meteor: there is no client and server, there is just the meteor platform
  • Distributed: There is no client and server, there is just the client using distributed platforms
  • Meteor: you don't define end points on the server to persist, meteor wires it all up for you
  • Distributed: There is state, it exists. You simply get it from the distributed network
  • Meteor: changes between server & client are persisted in real time
  • Distributed: distributed changes are broadcasted between clients in real time
  • Meteor: A database on the client is great for querying
  • Libraries: A querying library can query arbitary in memory data sets for you. crdt with it's Set's and Seq's can do this
  • Meteor: Automatic sorting of lists handled for you based on sorting meta-data
  • Libraries: Automatic sorting of lists handled for you by sorting libraries like sorta
  • Meteor: Reloads the browser when javascript changes and state doesn't change
  • Libraries: Combine a remote reload library and distributed state and this just works out of the box
  • Meteor: templates magically figure out what data changes to listen on the re-render
  • Libraries: DOM widgets observing crdt rows explicitly listen on changes and explicitly change without magically figuring it out. It's just not needed
  • Meteor: "It just works" (TM) as long as you stay within a very small confined subset of functionality where the magic layer doesn't leak.
  • Libraries: It actually works for complex situation because it's based on modular composition rather then fragile ducktaped magic.
  • Meteor: deploy it with one command in meteor
  • Libraries: Deploy with any service you want. Nodejitsu has one line deployment
  • Meteor: has latency compensation. which "fully handles all of this for you"
  • TODO: Libraries: Use a latency compensation strategy / library that does just that, cleanly and without magic.
  • Meteor: is an ego system of packages (that are hard coupled to their magic layer and don't work outside it)
  • Libraries: already have an ego system of 13299 packages, it's called npm

Meteor

Is a monolithic tower of a framework with a fragile base. Fantastic if you use it within the limited subset that doesn't fall over or if you value the fact it prebundled a set of libraries and tools into one package for you

Libraries

Fully flexible, far more power, have no magic. Libraries can be composed to achieve exactly what you want in a power and efficient manner. The only problem is finding them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment