We're writing a web app

Why write a web app #1

I wrote a lot about learning Linux tools and using them effectively. The question is what do we do with that? Or: what's next regarding personal development? What I've noticed, is that a lot of people tend to go into system administration, meaning setting up server applications. Here I should mention UbuntuPit as a great source for these projects. This path has a few drawbacks, although it's useful for learning what exists:

I think learning programming is beneficial regarding personal development, having new challenges, and so on. But why create a web app?

Why write a web app #2

For simplicity, we can distinguish the two app types: those intended for individual use and those intended for collaborating with others. It tends that people are hugely more productive when they collaborate (no, I don't mean boring Zoom meetings), while personal productivity is limited. If we have a new app, the more people use it, the more productive, potentially, they can get. So what types of apps exist to interact with each other:

The web apps are displayed in any standard-conformant browser, but they can also have a special mobile layout and they can be converted to mobile apps (or lite mobile apps) – being a mobile app, just cashing the assets for a faster display. At first, we could start even without that, and we'll be able to open our web app on any platform in any browser when the app and the browser stick to the standards. It motivated me to start, but to manage your expectations you should be probably aware of some drawbacks.

Why it's hard

It's just hard to make web apps, and the list of the reasons can be very long:

It's not that technically hard, but it puts a moral toll on you when you're moving not that fast or (what I did several times) you have to choose another framework for your app and rewrite everything.

The tools you have, again for simplicity, can be divided into the things you can easily get without and the things you should know. But in what order to learn them? Well, ...

Learning the web from a historical perspective

I came to this idea recently, and I think it makes some sense: you could learn web technologies in the order they evolved because that happened for a reason. A reason for that was that humanity (or developers) came to some limitations with technology, so they invented a new technology until they had a better idea. I suggest that you learn in this order and the sign that you learned something is that you feel the limitations of a technology. This means you are probably ready for the next step.

Roughly speaking, the sequence was like this:

  1. Static web meaning HTML and CSS, are the basics.
  2. Relational databases meaning SQL.
  3. Basic back-end framework, here I was quite happy to start with Flask.
  4. Opionated back-end framework, which gives you at least a variant, of how this could be done. I'm here now and I'm starting to feel the limits of Django.
  5. Non-opinionated modern back-end framework, it seems that Express JS is quite popular, and I'm targeting it now.

There are a lot of things like React/Angular/Vue or Next.js/Nuxt.js, I just don't understand what limitations would make me use them. Generally maintaining focus and taking one step at a time is a good idea, from my experience, for the reason I've already mentioned: the number of frameworks is overwhelming. And there's a bit of hype, too.

What I've learned so far

I'll go through the same list from the previous section to note my conclusions and let a lot of people laugh at them. :)

  1. Static means you can't change anything, but when you generate the static code on the server it's generally more stable, just because the client side is simple. Unless you need an interactive app like a game or an interactive map, you can go further with HTML and CSS. There are plenty of ready CSS styles as well.
  2. SQL databases are great when you understand what's going on. If you can model a data structure beforehand, I see no drawbacks, although I get the idea that NoSQL databases speed up the development. I'm just old, so I stick to SQL. Some frameworks have tools to write platform-independent SQL, I'm also happy to use that.
  3. I was stuck with Flask and the authentication task. The number of modules you have to find and include is a bit overwhelming just to do the basic things. It blurs a bit the whole picture of what's going on, but maybe it's a perfect place to start because you get the basics without too complicated concepts and you get a result fast.
  4. I'm working with a calendar app, and now the idea of having a very limited language in the templates doesn't feel right. Yes, you could use Django as an API for a front-end app, but I was eager to leverage all of its advantages, fast models and fast templates being among them.
  5. When you step on JS and Express territory, you again have to choose the modules and you also feel the absence of documentation, compared to pythonic tools and specifically Django. It sucks, but there's a reason it's so popular, and it's interesting to find it out, so my journey continues.