I’m building my startup on Sails.js — you should too.
Getting started backend development is a complicated thing today. Even the most seasoned developers can get bogged down with the variety of frameworks — Ruby on Rails (Ruby), Helios (Ruby), Sinatra (Ruby), Django (Python), Revel (Go), Loopback (NodeJS), and ExpressJS (NodeJS) are some standouts off of the top of my head. This makes no mention of variety of universal solutions, such as Parse and Google Cloud Engine. Each framework offers it’s own level of abstractness, adding to the noise of the already overcrowded market. Even for an experienced programmer entering a new field (backend programming), the options are overwhelming.
Enter Sails.js.
Why should you choose Sails?
Sails.js is perfect for developers like myself — developers that don’t want to write boilerplate code. My philosophy is, unless you are directly involved in the development of a low-level framework, you should not rewrite code that likely thousands of developers have written before you. Low-level used to mean implementing the cornerstones of technology, such as the TCP/IP protocol stack. Today, low-level code is synonymous with boilerplate operations, such as handling user authentication and your standard REST APIs. Nine times out of ten, you just need some out-of-the-box solution with some minor tweaking.
A great bit of advice I got from a friend of mine who is very skilled at poker (I am not in the least). He said something to this effect: Don’t just play your hand, play the person sitting across the table. This idea is applicable to choosing a framework in your next project. I’d wager that almost any framework would be successful in the right hands, simply because great people only invest their time in great projects.
This is the biggest takeaway I have for you concerning Sails: don’t bet on Sails, bet on Mike McNeil and his team at Balderdashy. Mike said recently during a Sails course on Platzi that he would rather eat toothpicks off of the ground than give up on completely automating the backend, and I believe him. He has a knack for envisioning a future for development practices, while still being able to relate it back with what is possible/practical. Prolific development strategies with a low barrier of entry for new developers — you can go ahead and open the floodgates now.
But you shouldn’t just bet on Sails because of their lofty ideals and can-do attitude. Treeline.io (simply a GUI for Sails.js, also developed by Mike and his team) was recently acquired by Y-Combinator, which is no small feat. The Sails Github repo has almost 10,000 stars, almost triple the next best “MVC” repo on Github. This project is starting to gain national recognition from businesses and the open source community alike.
Where Sails falls short (for now).
In my opinion, Sails falls short in only one area: documentation. Sails seems to be concentrated completely on developing new features and extensions when they should be concentrating on letting developers understand how to use existing features. Much of the code base seems fragmented across their many team members repos without a clear roadmap to find exactly what piece of the puzzle you are looking for. For example, it took me forever to find a little known extension called sails-permissions to add a user login/access control list package for my database. Reading the docs for this project are not much help in understanding what’s going on under the hood, and the project did not initialize correctly when I added sails-permissions to my app.
Short and sweet, here is my point: for this project to be used in applications on a large scale, the Sails team should spend some time informing developers exactly how Sails is run and how they can contribute. Make supporting your open source community the second highest priority (behind a great product, of course) — that’s what will take Sails to the next level. Here are the things that stand out to me that Sails could improve on:
- Clean up the Github issues so developers can help. At the time of writing, there are 237 open issues and 34 unmerged pull requests. It’s beginning to look like an overgrown forest rather than a neatly kept lawn. I like Sails, and I would like to contribute. But what motivation do I have if there is no guarantee my pull request will even be seen?
- Write better documentation about what the different parts of a Sails application are and what it going on under the hood. Yes, I know about the current docs. But as a developer, I need more than an alphabetized index of terms. I need what Mike has been doing in his Platzi videos (going through each folder in the Sails app and explaining it’s purpose), but in text form.
- Document the different extensions Sails offers. Other than searching Github, I’ve found no way to know what’s available.
All in all, Sails is an amazing idea with an amazing team behind it. It’s just a few quick fixes from becoming one of the dominant open source frameworks out there. I’m building my startup on Sails.js, and you should too.
