This is the start of the series where I will blog about development of the new community website that I started just recently for my quiz game Askutron.
The website will primarily be a platform for players to create and share their own quizzes for the game. These posts will follow along as I develop the website, both frontend and backend.
The Project 📓
This project is about the development of the new community website for my quiz game – Askutron. In case you don’t know, Askutron is a multiplayer trivia game for PC inspired by Buzz! that I have been developing together with my brother for the last couple of years.
Up until now the game has had a built-in standalone quiz editor that is shipped via Steam. The advantage is that players can edit quizzes even when offline. The downside is, that even though they can share their creations using Steam Workshop, they cannot collabortate on quizzes easily.
The goal of the new community website is to create a platform where players can work on quizzes together and share them with other players. This way it’s not up to one person to create and maintain a quiz for any particular topic. The result will hopefully be better and more questions for everyone.
The Tech ⚙️
I’ve been mulling over the tech choices for quite a while. There were various small prototypes based on differing programming languages, including Java, JavaScript, Python, and Flutter. Other contendors were Ruby and C#.
The only thing I was certain about was that I wanted to use React for the frontend. Not Angular, not Vue, not plain HTML. React! Because it’s simply my preferred paradigm for frontend application development. It’s just JavaScript all the way, and a very elegant, basic concept.
One prototype that I liked in particular was the one based on Next.js, because with its isomorphic architecture it allowed me to use the same code in frontend and backend, including server-side rendering.
There aren’t really many (any?) “full-stack” web frameworks for modern web applications which encompass both backend and frontend. And those that exist are far from complete. Therefore my next inclination was to start one myself, naturally. 😉
At some point, however, I had resign myself to reason and consider that I should focus on getting done as quickly as possible rather than having nice technical properties or the latest tools.
Backend
Keeping the above in mind, my choice eventually fell onto Python and Django for the backend. Other than Ruby on Rails there aren’t many other frameworks (I know of) that get close to the massive number of built-in features. It’s truly batteries included. And then there’s the massive ecosystems of both Python in general and Django in particular. Sure it’s not the latest, sexiest stuff. But it get’s things done.
The Python source distribution has long maintained the philosophy of “batteries included” — having a rich and versatile standard library which is immediately available, without making the user download separate packages. This gives the Python language a head start in many projects.
Currently the most important dependencies include Django itself, as well as the Django REST framework. This is a solid base for a Single Page Application. It allows me to easily define the data model, generate an admin panel and interact with the data using REST. Many details like migrations are already taken care of. This really made it possible to get started quickly.
The downside, of course, is that server-side rendering is not an (easy) option. Why is server-side rendering important? Ideally it gets the finished web page to the user more quickly by showing the final page immediately, rather than first having to fetch data and constructing the HTML on the client side after the page has already technically loaded.
React being based on JavaScript would require an additional service to render the views on the backend using the data from Django. Since my primary goal was speed of development I opted for the most simple solution, that is rendering on the client side only. While this is a slightly worse experience on the initial page load, where users will likely see a brief loading screen, on consecutive “page loads” it will be less of a problem when the frontend is a Single Page Application, like I am planning.
Frontend
As mentioned above React was already a given. I also already decided to use TypeScript instead of plain JavaScript, because I want to be able to keep updating this project in 2 years without having to wonder what the hell I was doing here. Personally I just find type annotations and type checking indispensable. With its “compile-time only” type system TypeScript offers a great compromise between JavaScript’s dynamic nature and static typing as found in other languages like Java or C#.
Given React the next choice was which UI framework to choose. There are many great choices out there with varying degrees “completeness”. The one that looked most promising to me in the beginning was PrimeReact. It offers quite the extensive library of components, offers great documentation and theming capabilities. However, relatively quickly I ran into bugs and, the framework being one of the less popular ones overall, a lack of community content that could have helped me.
Another framework I considered was Ant Design, which also offers an impressive number of components. It comes with great documentation and a well thought-through design language. However, unfortunately in some places I came across documentation which was only available in Chinese. It’s a great framework, but for the sake of saving time I didn’t want to risk developing myself into any deadends caused by the language barrier.
Eventually I decided to go with one of the most popular, if not the most popular choice for React-based UI frameworks which is Material-UI based on Google’s Material design language. Just like the other frameworks it has a massive number of components out-of-the-box. In addition there is a large ecosystem of community-created content around it, including custom components and themes.
The Details 🔎
So far this has been a relatively abstract overview of the tech that I considered and have chosen for the project. For more details stay tuned for more posts in this blog series, where I will more closely go over the backend and frontend as I develop it.
In the next post I will talk about the basic setup of the backend using Django, the data model, REST API and admin dashboard.