As a developer and someone who works on side projects, I often come across articles and forum discussions that asks or discusses what the best tech stack is for a project.
Most of the time these discussions will go back and forth about why one framework or stack is better than the other one. Personally I'm tired of reading them and have wasted too much time allowing choice paralysis to interfere with the joy of making.
I believe the best tech stack for projects is the one that helps you move toward from what's in your mind into something that's a built project. A tech stack should get out of your way and let you focus on building that itch you've been obsessed with scratching.
For example, when it came to deciding which front-end framework to choose to build out an electronic health record system at my previous job, I chose Ember.js. Why? Although Angular was the bees-knees at the time, I personally couldn't read the documents, follow any of the tutorials I came across and the community around Angular were going through a painstaking reality that version 2.0 wasn't backwards compatible with version 1.0.
I also found Ember.js' documentation to be quite easy to follow along and was a great reference for me when I was building something. I read through the docs once and was immediately productive.
If you're currently looking to start a project and you're stuck because you can't decide what tech stack to build it with. I'd suggest, first taking a moment and taking inventory of what you do know. From there, see if you can use what you already know and build the simplest form of your project with just what you know.
For example for my latest project, Spell It Out, I built it entirely with Jekyll, a static-site generator that let's me take HTML, CSS and JavaScript and build a website with it. Paired with Netlify and Algolia, I was able to create a site that took form submissions and provided search for various tech acronyms. Although I could've chosen to build Spell It Out with a back-end system with a database and host it on a service like Digital Ocean, the barrier to get up and running was in my opinion a bit high.
By using Jekyll, I was able to focus on a design and get that up and running quickly, then focus on the meat of the site, which was filling it with acronyms. Within a couple of weeks of working on the site, I had about 200 acronyms and used it to submit for the first time to Product Hunt. It was featured and got over 200 upvotes, and it boosted the acronym count because of the submissions by about 150 acronyms.
So does that mean all my projects will be built entirely with Jekyll? Absolutely not. I'm actually rebuilding Spell It Out to be a dynamic web application. For this to happen, I'm using Hapi and hooking it into a SQLite database. I'm familiar with Hapi, but unfamiliar with SQLite. So why did I choose SQLite, when it seems to go against what I said above?
I chose SQLite because for my previous projects where I had setup a back-end server, I used MongoDB and although I really enjoy the query syntax a lot, I personally found setting up a MongoDB instance and managing it to be a little too much and realizing I had a lot of relationships between my data, figured I should look into a SQL db. I didn't want to go overkill with a RDBMS like MySQL, so chose SQLite as the setup is quick.
I've also been enjoying the SQL query language a lot. I took a database course in college that taught about SQL databases, but have always shied away from them. But in setting up the database for the next version of Spell It Out, I've enjoyed learning SQL and the ins and outs of SQLite.
As for the front-end, well there isn't any front-end. I'm letting the back-end handle on the rendering of the pages on the new Spell It Out app. This is because I could use Ember.js, but I wanted to focus on again, getting something up a running. At this time, I wanted to get an app up and running that has feature parity with the current Spell It Out site.
In focusing on getting feature parity, I'm able to cut out the unnecessary for now, and focus on what's most important which is the acronyms. Once I've gotten that out of the way, I can focus on swapping out parts of my tech if I decide to.
So the next time you are thinking about starting a project, start with what you know, build out the simplest idea, use what makes sense to you. Because the best tech stack is the one that gets out of your way and lets you take what's in your mind and make it a reality.
Top comments (0)