Modern Web Development Hell - Roots
đ Wiki page | đ Last updated: Jan 21, 2022Simple and clean (probably the most important words in software development) are the last words that comes to mind when we're talking about modern web development. In fact, it's the opposite of that.
But why is that, where does all this complexity and mess comes from? Let's start from the bottom, from the foundation.
Web is based on the idea of Hypertext.
Hypertext and Document Model
So, what is hypertext? Simplest definition would be "a text which is not constrained to be linear". It may take a while to sit in, but it's a very simple and powerful concept. Along your textual content, you can encode pretty much any semantic and presentational meaning.
HTML (HyperText Markup Language), as the name says, is the implementation of hypertext as markup language. It gives us a nice foundation, but it's important to mention that we're not limited to the included tags and attributes and we can extend it (i.e. node.getAttribute("custom-attribute") and custom elements in the browser). We're going to explore this in more details in the future topics.
HTTP (Hypertext Transfer Protocol), as the name says, is the transfer protocol which HTTP client (i.e. your browser) uses to request that hypertext (HTML) from the server.
And the final piece is HTTP URI, which is an identifier of the resource which client will use to make the mentioned request. Be very careful with naming your resources, as they should be future-proof. See Cool URIs don't change.
Extremely important characteristics of HTTP is also its stateless nature.
How it all fits together
When your server receives a HTTP GET request for /my-resource, you should return a nice hypertext (HTML) document which can be easily understood by various HTTP clients - browsers, bots (search engines, social media sites, etc.), screen readers and other assistive technology devices, etc.
Note: from the perspective of the protocol, there are stateful parts (i.e. Keep-Alive, parts of HTTP/2), but this are abstracted implementation details and from our perspective everything stays stateless
Important things to mention here:
- Try to keep your HTML as clean as possible and progressively enhance things with CSS and Javascript as you need
- Try to use semantics tags whenever you can (you don't have to be too religious about it - classes/divs (with the help of aria attributes) are fine if there's no appropriate semantic tag) - beside helping others, you'll also help yourself (semantic tags are more readable and easier to debug) and you'll be rewarded by search engines
- Try to return your response as quickly as possible - try to design things in a caching-friendly way and try to serve pages directly from cache whenever you can (without touching expensive parts - i.e. DB) - beside obvious advantages, fast sites are also rewarded by search engines
So far, things are pretty simple, we're a good web citizen (our pages are very light, very fast and accessible) and everything is reliable.
A lot of people would be surprised how far you can get by staying close to these core web principles, but if you try to make this website more and more interactive with javascript, you're going to face some challenges.
The most popular "modern" answer to these challenges is the (in)famous thick-client SPA architecture, which in the desire to make highly interactive webapps easier, breaks all these core web principles (which comes at great cost). We're going to get into more details in the next topic - Thick-client SPA Architecture.
Ask me anything / Suggestions
If you find this site useful in any way, please consider supporting it.