The site is intended to be used to share small snippets of math in a way
One reason I wanted to do the project anyway was that I felt I could make a
site that projected a more fun atmosphere. The real reason, though, was
to see if the Meteor framework would be viable for more serious projects.
The answer to that question is...
There are some very compelling reasons to use Meteor:
- Reactive programming style
- Complete code-reuse
- DB API from the client (you heard right)
- One-Command deployments to meteor.com from the command line (Similar to Heroku)
However there are also some serious issues. Take this with a grain of salt as the Meteor project is still very young and they just got funded.
- Very poor error reporting
- Lag in some key rendering areas
- No simple way to set server-side configuration that isn't stored in the source
- It's own package system as opposed to using NPM
- Security appears to work in the Auth Branch, but it isn't battle tested yet.
It's hard to describe the feeling of developing on the Meteor platform, but it's extremely compelling. Due to the reactive design, you don't have to deal with propagating changes - AT ALL. This is the number one key selling point for me and it doesn't really have to be part of a framework to work. The workflow is as follows:
- Define your database collections
- These are MongoDB collections
Define your templates
- These are HandleBars tempates
- It helps to make these quite granular
- Add event listeners to your templates
- Make changes to your session / collections based on these events
That is seriously about it for a basic application. There are three more things to do for the real-world though:
- Define your subscriptions explicitly
- Define your security whitelist behavior
- Add client-side routing with Backbone.js or something similar
Check out MathFriends for sharing a snippet of Latex encoded mathematics today!