Why I chose Meteor JS
My first journey into the web-dev world
I’ve been coding since the nightly build of Code Igniter with PHP 5.4, and still, I can remember that large repository of a CRUD web-app I built to enhance my coding skills also for other developers in the world I can share with. Same goes to other language and frameworks I have fiddled with, like Yii, Laravel, Django of Python, Ruby on Rails, and some other I might forget already.
Generally, PHP once gave me the ease because the community has me assured that I’m standing on the giant shoulder of StackOverflow, so whenever I faced a bug, chances are they had it solved long before. I thought that I can do everything with PHP, then I realized that I’ve never been so wrong when my challenges came from client upped and found no proper solutions for them.
So I took a backstep and found some other communities offer a wide range of choices on either language or frameworks of web development. the first hand which grabbed me out of PHP language was Python. a rather peculiar language that forces me to code tidily, and after fiddled with Django and create a rather simple CRUD, I gave up for a significant amount of lines of codes I had to write was more than I’d need than my old good framework.
A month later I gave Ruby Language a try along with Rails framework, turned out that it’s not quite up to my liking, and surely I need to cope with several javascript libraries managed with npm. Thanks to Ruby which introduced me to npm and Node JS, I dive into the Node website and found out that JS is runnable on the server side.
I look for a web app framework that utilizes the Node engine and found that the most common setup mentioned is MEAN. It’s an abbreviation of Mongo, Express, Angular, and lastly Node. The first time I heard and read the news, reviews, and forums talk about it, I know that the world of web development is having quake shifts significantly.
The PHP Apache engine I used to work on, shall be replaced by NodeJS. The Laravel framework I used to work with, shall be replaced by Express. The Spacebar templating engine I used to display my contents with, shall be replaced by Angular. And lastly, the MySQL relational database engine I used to store all my data in, shall be replaced by MongoDB which is a completely a different beast of its own NoSQL turf.
This stark difference was a huge makeshift that requires my sound reasoning and complete commitment to jump over into this new pool of web-dev environment. So I spent a week to watch over and clone many repositories until being confident enough to build a new one of my own version.
Getting wet with MEAN
Presumably, like many newbies, I stumbled upon several problems related to npm dependency packages, be it conflicts of dependencies or unknown errors I can’t find the solutions on the internet. To set up a boilerplate of a proper CRUD environment is a chore for me to start with because like many have rambled upon, I need to set and wire up all the libraries manually in minute details. After all the hurdles, I finally have my own boilerplate worked and started working on some simple CRUD projects.
Opposed to the old PHP framework I used to work with, the existence of npm along with its large collection of modules does give me a new perspective of what this MEAN stack can do. After fiddling with the MEAN stack for a while, my curiosity drove me to find an alternative of this stack and it brought me to a framework named MeteorJS.
This framework promised me a better approach than MEAN stack by eliminating the trouble of wiring up the infrastructures of libraries with a simple command of ‘meteor create yourApp’. This simple command will get you a fully working boilerplate which you can modify to any extent of complexity you may think of. They even have their own dedicated package manager called Atmosphere which contains community maintained libraries, though one can still include npm packages at will.
The framework website says that MeteorJS is an isomorphic framework, which means we can use the same context of code for both client and server sided codes. The inclusion of MongoDB as the default database means that we no longer need to tie up the database and our codes with credentials manually, its just there each time you create a new collection with its collection method.
The standard rendering engine MeteorJS offers to newcomers are BlazeJS, which is a templating engine that works and smells like the Spacebar or Mustache I used to work with Rails long ago, but now Blaze is no longer the default, you can choose to integrate the framework with the latest rendering engine like VueJS and ReactJS, though I’d prefer MithrilJS than most virtual dom libraries around.
What amazed me the most is how well MeteorJS can cope with language compilers like CoffeeScript. In my perspective, this is simply a language that ticks all the boxes of what a language should feature (I’ll have it explained in the future article). And better yet, any errors lead to the CoffeeScript line of code that contains the error, not the JavaScript lines it produced.
Leaning my trust on MeteorJS
From that moment on, I have been coding with MeteorJS for all of my clients need, from simple apps like finance and productivity reporting, GeoJson map rendering with the help of LeafletJS, to the latest and current works of mine, an integrated hospital information management system for the publicly owned hospital in Indonesia. That last one no longer uses CoffeeScript though, but LiveScript, the continuation of CoffeeScript ide of simplicity maintained by another group of developers.
With the help of libraries like aldeed:simple-schema and its autoform, I could create a working prototype of most of my client requirements in a matter of hours, something I wouldn’t dare to imagine if I were to stay in MEAN stack. The trick is, you only need to define the object structure of that form of information with SimpleSchema and pass the object to the autoform library, then you’ll have a fully working form that resembles the information structure defined.
I went on with the autoform library for more than a year and done several projects with it and soon realized that I need a lot of parts to be modified and failed to do so for the autoform library itself contains more than 10k lines of codes. It also tightly coupled with the BlazeJS library that no longer resonance with most developer movements to migrate to virtual dom based rendering engine.
Both situations no longer satisfy either me and my clients, so I took my step back again and began to think the bigger picture of what I’m going to do next. I was so captivated by how versatile yet small MithrilJS library is, I can build more complex apps with significantly fewer codes to write. At this time of writing, if I should count up amount of lines of each repository I have on my GitHub, the GeoJson web uploader I mentioned before only consists of less than 300 lines of codes, and the integrated hospital information management system itself only consists of less than 2k lines for both server and client sided codes combined.
All of my repositories of MeteorJS based web apps are available for all to read, comment, and clone. If I can make my own ‘real world’ complex apps with it, so will you. And if you are also happened to be a MeteorJS developer, please share me some of yours as well.
