012 - choosing technology to build on
When I was in grade 6, I really wanted to learn how to program computers so I could make video games. I didn't know anyone who knew much about computers so I would go to Chapters and look at the "Programming" shelf where there were lots of big books on the popular programming languages in the year 2000. I saved up some money and bought a book called "Teach yourself C++ in 21 Days". I picked this book because it was very thick. I read the book pretty much cover to cover. Unfortunately, I didn't know how to actually reproduce the examples in it on the computer I had at home. The pictures in the book looked different than what was on my screen. So I gave up and just went back to merely playing video games.
When I was in undergrad, a friend and I decided to start a business where students could sell their notes online. We called it Studybunny. I was doing an English degree but thought it might be cool to figure out how to make an ecommerce website. I went online and found a YouTube video where someone wrote a blog from scratch using a language called PhP with a framework called CodeIgniter. It was a really good video and I was confident I could copy exactly what he was doing. I carefully followed this video, second by second, and was able to get my computer to do the exact same thing.
Now that I had written this code, I could see how to tinker with it to make it a bit less like a blog and a bit more like an ecommerce site. By making small adjustments one at a time, I was able to ever so slowly transform the blog into a website where students could sell notes online.
Studybunny's growth wasn't exactly parabolic, but we kept it running on the side as we continued with university. At some point, I learned about this web framework called Django which was written in Python. I thought the word "Python" sounded very cool and was pretty sure I'd read hackers use Python. I had also read that Instagram was built in Django. So I decided to rewrite Studybunny in Django as a side project during my first summer of law school.
Django had good documentation with a nice tutorial that I was able to stumble through. There were some similarities to the things I learned with PhP and CodeIgniter. All I had to do was take something I had already written in PhP/CodeIgniter and figure out how to write the same thing in Python/Django. I did this one small piece at a time and by the end of the summer I had a working ecommerce site built in Django.
After I completed articling (a 10-month training contract all Canadian lawyers have to complete), I was given about half a year off work before my full time job started. A friend of mine was interested in starting a software company and we began talking about collaborating. We decided I would write a prototype of the software and then we would raise some money to hire real developers to build the real software. Since I knew Django I decided to write the prototype in that.
At some point around this time, I went to a networking event in Toronto and ended up chatting to someone who told me all about this exciting new thing called a Javascript framework. On the internet in 2013, it was now possible to have webpages do all kinds of crazy fantastical things. You could even have an entire application inside of a single web page!
I spent the next few days learning all about these magical new javascript frameworks. At the time, there were three frameworks to choose from: Angular 1, Backbone and Ember.js. I read that Trello used Backbone. My wife and I were using Trello to plan our wedding and it was pretty cool. But Ember.js was more cutting edge and it had a cute hamster on the logo. I deliberated for a day or so and then picked Ember.js because it seemed the easiest to get started with. As it turned out, this is largely because I had no idea how to write javascript code and Ember.js required the least amount of Javascript code to be written.
Well, it took us three years to hire our first full time developer and in the meantime that prototype ended up becoming the actual product of our company, Closing Folders. As a result, I spent the next TEN YEARS writing Django and Ember.js code, every. single. day. These technologies I picked, pretty much on a whim, turned out to have a massive sustaining impact on the future of my work and business. Today, Closing Folders still runs on Ember.js and Django and, while I no longer have anything to do with it, I wouldn't be surprised if it still does another ten years from now.
Django ended up being a pretty good choice. It is still a widely used technology today. Ember.js was, unfortunately, the wrong choice. The right choice would have been React.js. The only problem is React.js hadn't been released yet and wouldn't become popular for 1-2 years after. Some might argue Angular was the right choice but actually, at the time, it was Angular 1 which Google would later sunset in favour of Angular 2. All to say, I think Ember.js was as good a choice as any of them at that time. The other great part about Ember.js was there was a local meetup in Toronto where I ended up meeting a lot of cool people.
All of this was running through this week when I found myself in a similar position: kicking the tires of huge software libraries that I need to bet the company on. Except, now I am not naive enough to make these decisions so flippantly. Instead, I am paralyzed by their enormity.
When I announced eno, I said I would write it "from scratch" - my hope was to never have to make these hard decisions. If I just write everything myself, then I can control my destiny for the next decade or more.
Unfortunately there are some wrinkles with this. The first is that, in 2024, you probably want to make an application that can run on Mac, Windows and in a web browser. The most common way to do this is to write the application to run in a browser and then use something called Electron to package it as a desktop application for Windows and Mac. Inside that package, is literally a copy of Google Chrome that runs behind the scenes when you launch the application. The performance is terrible, the file sizes are giant and you are stuck building with browser APIs which, for my purposes, are unsuitable. So, as you can see, I'm not a big fan of that.
There is a fairly recent technology called WASM that allows you to run compiled code in the browser. This means it is now possible to take code you wrote for native applications on Windows and Mac and run them in a browser. Unfortunately, it's not quite that simple. You need to write Javascript code to bridge interactions between your WASM module and the browser's canvas environment (which you draw your graphics on). Additionally, many things you can do in a native desktop are not possible in a web browser, like saving files to disk and opening certain types of network connections.
Even if you can get your code to run on all three platforms, each of these platforms has a completely different graphics API: Metal on Mac, Direct3D on Windows and WebGPU on Web. That's crazy, so Google has a project called Dawn, which aims to take WebGPU shaders and recompile them to work natively on the other platforms. Alternatively, there is an API called OpenGL which works on all the platforms except Web. On Web, there is WebGL, which is similar to OpenGL but not the same. OpenGL has 4 versions and each version has a different API. Only OpenGL 4 is supported on Mac. I could go on.
The "from scratch" approach would be to write pieces of code to interact directly with each of these native platforms, implementing three different graphics backends and three different app runtimes (used to create windows and receive input events). The non "from-scratch" approach would be build on top of a library that abstracts all these differences away. A bunch of these libraries exist but the ones that support web are pretty nascent. I feel a bit like I am back in 2013 picking a Javascript framework again. This time I know what's at stake.
What's my solution? I'm not sure yet. It comes down to a tension between two heuristics: (1) use as few extra software libraries as possible and (2) spend most of my time building my own unique software.
Now that I think about it, I have actually made a big technical decision like this with eno already: deciding to write it in Zig. Why did I pick zig? Well, honestly, it just seemed cool and I was excited about it. Maybe I'm still more naive than I think.
If you enjoyed this post, subscribe below to get notifications for the next one.
We also have an RSS feed