Back to Web 1.0?

My current main project is the next major version for the Distrochooser. Distrochooser 5 is built using a multi component stack:

• Frontend: Nuxt.js (Vue.js)
• Backend: Django
• Database: PostgreSQL
• Caching for the backend: Redis

Page sizes in comparison

Both versions are running in production modes.

It's clearly visible that the new version will almost double the data needed to be downloaded. And large parts are not the webfonts (50 KB) or the distrochooser logo (6 KB). It's JavaScript files!

As somebody working with a quite bad internet connection, download sizes are mission critical, even below 1 MB.

I know that most of the data will be compressed during the page load, but the client will have to uncompress the data again to process it at some point.

It's hard to optimize a page when you move the majority of the frontend into the client, requiring a download at any point. You can turn some switches, like non-blocking/ lazy-loading, but you won't fix the base problem. Personally, ths causes me to think about reworking the frontend as a server-side app again.

Complexity

I must admit, I really start to dislike the request size and the fact that the complexity of Node.js applications seem to increase without limits. When I started using Vue, it was a easy and lightweight alternative to Angular.js. But now, it feels clunky, even still being lightweight compared to competitors.

The node_modules of the frontend module has 154 MB(!). I know that there can be potential to decrease that size, but the core issue will remain.

The whole Node application development process is really far away from the KISS principle, which I was following at the start of the project. And I feel that I have to fix that for following reasons:

• maintainability
• scaling

Fixing the dilemma?

Writing the complete app again is not a real option. I will finish the current version on the current stack as I plan to release it's final version at the end of the year.

For Distrochooser 6, I will take a look on different approaches, especially for utilizing server-side rendering. Unless like version 4, the current beta frontend purpose is only to collect the answers. The calculation will be done on the backend. This allows some experiments as the "logic" of the frontend is not that complex.

What are the options?

Why not TS?

TypeScript has some interesting features, but it remains still a hat on top of JavaScript. And the error messages are terrible to read, seriously.

Java and Dotnet

As I really want to work again with strictly typed languages (not TS!), some of the candidates are Java and Dotnet. We all know that Java is quite common, but it comes with a resource usage malus. Also I will take a look at Kotlin, as it's following more modern approaches compared to the "plain old Java".

Dotnet still feels like a niche platform for the web. But I learned coding on Dotnet, maybe it's time to close that circle again. And my final project of my apprenticeship was a web app. Using dotnet.

Rust

Distrochooser 4 had two backends at some point (Waldorf and Statler). Statler was already using Rust. But it was ditched after I had issues understanding some of the concepts of Rust back then to prevent security issues. Restarting that idea could be an option, aswell.

Python

This alternative could cause the project to become a monolith, as the backend is also running Python using the Django project.

Conclusion

There is none! Time will show where the project will lead to. But first: Finish the beta before starting the next construction site.

Photo by Jim Wilson on Unsplash