Brace yourself

While the rest of the class became fascinated with AngularJS, Team Meinv decided to go one step ahead with exploring and using Meteor in Assignment 3.

Since we decided on the framework to use before actually finalizing our application idea, I will talk about Meteor first, so brace yourself for a long wall of text.

What I like about Meteor

• Meteor is a full-stack JavaScript framework. This means everything on the front-end and back-end is managed together. The same piece of code can work on both client and server side. There are no separate package managers for your back-end framework and front-end framework.
  
  Bonus points for JavaScript being the programming language! :D
  
• Setting up is super convenient and fast, aside from the fact that I chose to employ Vagrant (again) to run Meteor on an Ubuntu box. Live reloading is also coupled in Meteor, so there's no need to hit the refresh button or restart your server.
  
  The file and folder structure is simple to use and follow as well.
  
  Deploying to production is as simple as meteor deploy. Then your entire application works, just like that, no configuration hassle whatsoever. I think it is even more straightforward than using Heroku.
  
• Fibres and Futures. I am sure those who have used JavaScript would have come across the two terms synchronous and asynchronous. Meteor uses Fibres and Futures (Futures is an extension of Fibres, I think), which allows for asynchronous calls, in a synchronous manner, to avoid callback hell.
  
  Nifty, though I am not 100% clear how it works, but it does. Not exactly the same as Promises either, I guess.
  
• The availability of reactive variables, which is quite similar to data binding in AngularJS. Commonly used objects such as your database documents are reactive by default - there is no need to manually update your template views when a new document is added since Meteor handles it for you.
  
  
  {{Spacebars}}
  They call their templating engine Spacebars, inspired by Handlebars.
  If you remember my talent was supposedly riding my bike without using the handlebars... props.
  
  Having used both Meteor and AngularJS, I would say that Meteor is less confusing, but probably also less powerful when comparing the two "data-binding" services.
  

Why I may avoid Meteor

Other than the fact that meteors can kill you...

credits: meteor-accounts-ui-bootstrap-3

• In Meteor, there are a few magical components that do not require much code and setup may be wonderful, but I think it crosses the line of usability...
  
  ...especially so when accounts-twitter, the Meteor package for Twitter authentication, asks me to input the API key and secret in the browser with a "Configure Twitter" button (see image), which then converts to a "Sign in with Twitter" button after.
  
• I had trouble coming up with another reason to avoid Meteor (much awesome right), but this is probably only valid for the time being.
  
  Meteor relies on its own package manager, Meteorite/Atmosphere instead of npm even though it runs on node.js. This limits the use of external packages until they are imported into Meteorite.
  
  Likewise, there is only official support for one database, MongoDB, although there are SQL packages available for use.
  
  At the time of writing, Meteor is on version 0.9.3. It already is stable and great to use, but once they hit 1.0 I am sure it will be an awesome framework.
  

Feedeorite

As stated in my previous blog post, we were working on the idea that I "pitched" during my application to CS3216:

As a netizen and user of social media, I have several different websites that I follow, from Facebook to news, etc. For blogs and news website with feed readers, there exists RSS apps such as Feedly or Newsblur (the one I use) to aggregate all the articles in a single site. However, none that I know of extend this functionality to social media or other content based websites. Neither do they have flexible strategies for hiding articles/stories that I do not like to see. My idea will be to develop such an application to make it very convenient for users to digest updates and reports, together with a strong filtering system.

After considering the short time frame that we can work on this, we decided to implement only RSS feeds and Twitter. The "strong filtering system" may sound incredible, but in actual fact what we have implemented is merely something trivial that has a lot of room for improvement.

Like Stickats during Assignment 1, Feedeorite is pretty much a prototype, although it is usable. Everything is far from ideal however, given that it required more than simple CRUD, plus it was developed in a new framework with a different architecture from what we used to code in.

The latter half of CS3216

Stickats was promptly killed in two sentences during our visit to Asteroid (insert Meteor reference here), who delivered a more potent blow than whatever was discussed during the internal pitch session. Something along the lines of:

Have you seen Perx's upcoming update on their blog?

They are going to implement social stuff too.

While not exactly the same core idea, we decided that it will not be very feasible to work on Stickats now.

Finally, bracing myself for what is probably going to be the most epic 2 months of 2014, with Xuanyi on his new marvelous idea, and Wudi and Shixian!