Creating a Side Project: Step 1: Picking a Language and Framework

Posted: May 7, 2020

Hello, and welcome to Step 1 in the side project series. Last time in step 0, I discussed my project goals and a basic execution plan.

In this step, I’ll explain my thought process on picking a language and framework for my side project.

Oops…

I actually cheated a little bit. Before I started this project, I already knew I wanted to use Python. Why?

I have some experience in Python, and the language is intuitively appealing to me. Almost everything in the language has been well-thought-out, in comparison to PHP, which I use at work. Everything is consistent.

It also has a stable API, a large community, and a great security track record. I prefer an explicit approach over implicit.

For me, Python is almost a perfect language. There are some things about it that annoy me, but by and large, it’s fantastic, and I’m not aware of any better alternatives.

The main downside to Python is speed, but it’s basically comparable to PHP and Ruby. Twitter used to run on Ruby. Facebook still runs on PHP. So there ya go.

On to the frameworks

Python used to have a lot of competing frameworks, but most of the dust has settled, and the winners are Django and Flask.

I used Django the last time I built this project a few years ago. I didn’t find anything too rotten about it, and I think it’s improved since then.

What do I want out of a framework for this project?

Why do I want those things? It’s simple:

Boring is good. I’m results oriented, and I don’t want to spend my valuable time on unproven tech.

Oops, there’s more…

It turns out that both Django and Flask meet all four criteria above. So how should I choose which framework to use?

I ended up reading this article, which really helped me: https://testdriven.io/blog/django-vs-flask/

If you’re choosing between some other frameworks, it helps to read a detailed breakdown of the pros and cons of each one.

I really jive with the UNIX philosophy - do one thing, and do it well. I use Arch Linux because I like to explicitly choose each and every package installed on my system. I like having the flexibility to use exactly the packages I want.

Flask sells itself as a minimalist framework, while Django is “batteries included”. Flask wins on this front.

Another advantage is that the Flask codebase is much smaller. What this means to me is that I have a chance at understanding the codebase and modifying it if it’s ever deprecated.

A further advantage is that I can choose the extensions that I want, instead of being coerced into using Django’s built-in features. I can be picky with technology, and I appreciate the flexibility of choosing my favorite approach.

One disadvantage to this philosophy is that I will have to find and vet a variety of extensions to get some basic functionality going. The authors of various extensions are probably not as reliable as the Django Project. If you look at recommendations for Flask modules, you might find that many of them are no longer maintained. We’ll talk about all this in the next step.

I’m going to write this project as a Single Page Application with a REST API backend. I won’t need a lot of Django’s features. Flask is known for being a good, lightweight API backend.

My choice

In the end, I chose Flask. I’m sure Django would have made a fine choice as well.

What about the frontend?

There’s really not a lot of flexibility on the frontend in 2020. You must use Javascript.

If you’re still using Coffeescript, please just stop.

ECMA6 was finalized in 2015.

IE is dead.

Javascript is now beautiful.

What about a frontend framework?

Choosing the right frontend framework is also quite important. The only two that really matter today are Vue.js and React. They’re mostly interchangeable - you should just try one out and see if you like it.

I don’t take Angular seriously since it’s run by Google.

At my work, we use Vue.js, and I really like it. I’m going to use Vue. It’s elegant and simple with a low learning curve.

I’ve never used React, but I find JSX to be extremely ugly and unnecessary. I also don’t like that Facebook is the owner. Facebook’s technology track record is somewhat abysmal. Remember “move fast and break things”?

Svelte is a really intriguing frontend framework, but like I said, I prefer boring technology. I hope that Svelte catches on in the commercial sector sometime - I’d love to try it out, perhaps on a toy website.

Coming up

In step 2, we’ll choose the rest of the technology stack for this project. This will include:

Looking forward to it!