Concerning evolution of web development

Published in Miscellanious

So some time ago I've seen this tweet:

Translated into English, it would roughly read like this:

Do you think web development is all right or has it made the wrong turn somewhere? And could you point out when and where this wrong turn occurred? Thank you!

And this tweet here really made me think about my experiences as someone who might not be terribly experienced with web development, but who nevertheless does this for a living.

Perspective

So before we start, I think that, for the sake of fairness, I should shine some light on my perspective with the subject.

I've started doing web development (as a hobby) about five years ago. Sure, before that I had a couple forays in the worlds of HTML, CSS, JavaScript, PHP, and even server-side Java, but I wasn't really interested in them. HTML and CSS were confusing, JavaScript even more so, and PHP and Java were quickly forgotten once I've discovered Ruby.

My interest in web development was sparked anew by Ruby on Rails. The whole experience was pretty smooth and simple, allowing me to build web applications based on solid conventions and concepts, that were fun to make and were reasonably stable.

Since then, I've tried multiple web-related technologies, both client-side and server-side. I've done some web development in Perl. I've tried Django (and liked it okay). I've tried Flask and Sinatra (this blog's first version was even built with Sinatra). I have looked at Backbone.JS and the famous React, and even tried out the React + Redux combo!

What I'm trying to say is, that despite having limited experience, I'm still interested in various areas of the web development industry and try to keep up with the latest trends in it.

The complexity of web development

So the tweet asks us whether or not web development has "made a wrong turn" and… I can't really answer that question. The thing is, web development is a big industry. It has a big rift in the middle dividing it between frontend and backend. There are some technologies that kinda bridge that gap (like ReactJS's server-side rendering) but ultimately most of the web development can be assigned to one of those two fields. And those fields, in turn, split into smaller fields, concepts and technologies.

So the way I see it, the best way to talk about "wrong turns" is to try and look at the trends that are happening within the backend, the frontend, or both. Some of those trends I like, others, not so much.

The yays

Base platforms improving

This is kind of obvious, isn't it? And yet, I think it deserves a mention.

Throughout the years I've had with web development, I've seen the base platforms (the languages and the frameworks) constantly improving. It's especially noticeable on the frontend. We have JavaScript (or ECMAScript if you want to) having a nice selection of new syntax constructs and standard library objects added. CSS has also received several strong improvements, like Flexbox, Grid and custom properties (aka variables).

And on the backend side, I've seen Ruby transitioning from 1.9 to 2.5, gaining features like keyword arguments and safe navigation operator. I've seen Python 3 gaining much more traction, to the point where the Python developers are comfortable to give a hard date of deprecating Python 2. I've seen Ruby on Rails becoming more streamlined and even gaining Websockets support.

Third-party addons improving

I feel like there has been a lot more focus on addons provided by the community. Addons that enhance the experience of a framework, and those are many. From template engines like Haml and Slim and Pug, to development enhancements like pry and ipython, to even mini-frameworks like Redux.

And I think it's a good thing. A framework doesn't have to provide everything one might long for. Even if it tried, it would quickly become big and bloated and hard to learn. I like the approach of making the base framework solid and extensible, allowing addons to further improve the platform.

Focus on the domain

When I started web development, the most prominent paradigm was MVC, as well as its variations (such as MVVM or Django's MTV). Those concepts advise splitting an application "horizontally", into a number of layers. Each layer contains components that implement a particular area of functionality.

However, recently a new trend has emerged: splitting an application "vertically", in a way that reflects the domain. That way we gather components in tightly-knit domain-related groups. Which, in my opinion, makes sense, as those groups tend to be smaller and more manageable than quickly inflating "horizontal" layers.

The nays

H Y P E

The web seems to be really into hype. Really really into hype.

The best example of overhyping a thing to the max would be the NoSQL train. Suddenly, NoSQL databases were hot stuff, and people were predicting the death of relational databases. Eventually people realised that NoSQL databases are situational and should be used sparingly, but this event has shown everyone how dangerous it is to overhype.

Single-page applications (EVERYWHERE)

Modern frontend frameworks and UI libraries are pretty great. They allow you great deals of control over your application's presentation and its interaction with its users. That said, quite a lot of them are focused on building your whole front-end as a single-page application. A single page application (aka an SPA) is an application that only loads the actual web page once, and then relies on JavaScript to fetch the data from the server, send the data to it, update the webpage and even do the routing.

Even lightweight libraries that can be plugged into server-generated HTML still expect you to build an SPA. Lightweight libraries like React, or custom elements frameworks like Polymer still heavily feature SPAs in their documentation.

Now to be fair, SPAs have their uses. If you need an element that stays permanently active while letting the user interact with your app in other ways (like a music player), SPAs are downright indispensible. And they do reduce the amount of data the client loads from the server.

However, SPAs are quite hard to do right, since you basically have to reimplement a big chunk of browser functionality (form sending, routing, etc). And if you don't make it right, you're likely introduce irritating quirks to the user experience. And, of course, if the user doesn't have JavaScript enabled, your SPA is basically useless.

There are ways around those problems, sure. I know that React has a server-side rendering option, for instance. But it seems so contrived. You're making a big JavaScript-powered application and still have to render HTML on the server because of the problems the approach introduces.

Focus on generating DOM from scratch (instead of enhancing and refining existing DOM)

Modern frontend frameworks and UI libraries are pretty great. That said, almost all of them revolve around the concept of building DOM from data, or, as DHH put it in his article:

Almost all [frameworks] are focused on turning JSON into DOM elements via a template language of some sort.

It's not a new approach by any stretch of the imagination. Nor is it necessarily bad. It is very straightforward: data goes in, DOM goes out. And with the virtual DOM technology it's become pretty fast too.

However, I find this approach frustrating. Since I don't generally build SPAs, I want my frontend and my backend to play nice together, and I want my backend to be mostly in the driving seat. Over the years, Rails and Django has developed quite an ecosystem for generating HTML, from template engines to various helpers to form builders. But if you want to add a sprinkle of React to your newly made form, you have to throw it all away. React has to build one from scratch so that it can implement all the awesomeness.

See, Rails and Django started in the age of jQuery. And jQuery is mostly about adding functionality to existing DOM elements. The problem is, we've barely had any improvement on that front! And it is sad. JQuery features a lot of utilities that are frankly unneeded in the modern JS ecosystem, like promises or advanced loops. Heck, even AJAX isn't strictly needed in jQuery since we have much better alternatives in the new Fetch API and libraries like Axios.

That's why I'm excited about the new Stimulus framework so much: it's exactly what I ( a mostly backend developer who likes to dive into frontend every once in a while) need and feel the most comfortable working with.

That's all folks!

And this is it folks, my opinion regarding modern web development. There's a lot I like, some annoyances I'm bothered with, but overall I think the industry is growing, improving, becoming more powerful, accessible and generally fun to work in. That's why I'm still doing it!

Thank you very much for reading this piece. Please leave the comment down below and, if you liked the article, be so kind to circulate the link! Thank you very much!