This presentation is made in English to be presented at one of the meetups, again in English, probably at MetaPex. Many of those who saw the screenshot of the first slide I posted online asked me to make this presentation in Russian and record a video about it. So here it is. This video presentation is titled They Are Killing Frontend, and I don't want to say that frontend development will cease to exist; it will remain. I will just discuss the main trends currently observed in the market and how they affect what is happening with frontend development. 

Let's look at the presentation plan. We will start with how it all began, then I will talk about how we built this monster, and we will discuss how we are trying to fight this monster. We will learn how, in fighting this monster, we are killing frontend, and we will draw some conclusions. We will begin with how it all started. Surely, you remember or you...

Have you heard or perhaps read about how frontend development was from the very beginning? It was something quite simple: there was HTML, CSS, and a bit of JavaScript. The task of frontend developers at that time often involved taking a file from Photoshop and replicating it in the browser using HTML, CSS, and some primitive JavaScript. The main problem for frontend developers back then was the difference in how HTML and CSS were rendered in different browsers. We had vendor prefixes, and we needed to know how they differed and how to write correctly because many things were even written differently. For instance, gradients for backgrounds were implemented differently in various browsers, and so on. We also faced issues with JavaScript because it was implemented differently across browsers. For example, even AJAX requests had to be made differently in Internet Explorer compared to Firefox. In Internet Explorer, there was XMLHTTP and some ActiveX solution.

Related to ACX, in Firefox there was an XMLHttpRequest, which is used now. Yes, at first we struggled with it and suffered, and we had to remember and write some of our own functions that checked for certain browsers and used the necessary API. But then a library like jQuery and its analogs appeared, and everything became much simpler, making development straightforward again. Of course, we constantly tried to improve development in one way or another, and at one point, for example, we came up with an AX, which now feels like we are loading the site immediately. However, if we need to get some additional data, we make a request to the server, receive a JSON with information, and render it on the page using JavaScript. Nevertheless, JavaScript and front-end development remained simple, and there wasn't much functionality, so we didn't really look towards any changes because it seemed fine that way. This was the first part of the presentation, where I talked about how NN&D originated. Well, it’s difficult.

to say that it was born earlier than what I am talking about, but what it was like in the early 2000s, how simple it was. Of course, it couldn't stay that simple for long, and at some point, it began to transform into a monster. We already talked about how we initially had graphic files in HTML, then we had different browsers with various prefixes for CSS, and there was different functionality in JavaScript. Then we came up with AJAX, which allowed us to simplify development and make websites seem faster for the end user, which, in reality, they were not. But that was not enough. And of course, front-end development, like any other industry, continued to evolve. The main areas of development were how to make user interfaces better so that they would be more enjoyable and convenient to use, and how to simplify interfaces so that users wouldn't have to navigate back and forth, searching. In general, instead of these beautiful, super complex designs, we were moving towards...

the focus was on simplification. This applied not only to the final result but also to the development process. We wanted the development to be better and easier. And how can we make development easier? By creating some frameworks, perhaps even more than one. At some point, in JavaScript, the era of numerous frameworks began. If we look at the timeline, we can see how everything evolved. We had Internet Explorer, some version of Firefox, and maybe another browser, then libraries started appearing that simplified working with JavaScript across different browsers. Because, as I mentioned, they are different; JavaScripts are the same, but the way they work varies, and some APIs are also different. Such libraries included jQuery, YUI, Dojo Toolkit, and many others. Write in the comments which of them you used if you did, and which ones you still use because...

We are still alive, but after that, we entered, as I said, the era of frameworks. XJS, Angular, Knockout JS, Backbone JS, Ember, Meteor, React, Angular—there were so many. We even created our own framework when I worked at Y-Pame; it was called X Framework and was based on BK Bona, working through events and templates in the form of regular HTML files. Overall, it was quite interesting, and many laughed at JavaScript because, they said, a new framework appears every day that you need to learn. While it seemed funny from the outside, it was not so amusing from the inside because, yes, you really had to learn. And if you constantly have to learn something new, it means you are always busy not only with development but also with studying something to continue developing in the future. It became very difficult to be a frontend developer, or it started to become very difficult to be a frontend developer, and even the architecture of frontend applications changed completely.

Now we have various components, some high-ordered components on top of that. Each component had its own service, its own adapter, its own library. Plus, instead of writing something ourselves, we constantly used third-party libraries, and this also influenced our architecture. It turned into something like what you see on the screen. Previously, we had HTML, CSS, and JavaScript, and we created a separate HTML file for each page. Now we have this frightening structure, which also implies that there is front-end. If we look at how our applications appear today in the code inspector of the same browser, we can see a huge amount of JavaScript that gets loaded in there, and there is indeed a lot of CSS as well. But the main problem with JavaScript is that since we have completely moved into frameworks, we started to fully rely on rendering the interface using JavaScript. Therefore, we write our JavaScript files, and we use...

Third-party libraries have third-party JavaScript files, and thus we are loading megabytes of JavaScript onto the page, even though the interface may not be very complex. Since working in the frontend has become much more challenging than before, the workload has increased, and so have the salaries. As a result, more and more people have been drawn to frontend development, often lured by the promise that the work is relatively easy. However, we have already encountered this monster that is difficult to work with. It's unclear what framework to use when starting a new project, or which build tool to choose, whether it's Vite or some Create React. We have no idea. In general, we choose something here, then we decide which UI libraries to use, and we also download libraries for that. Overall, everything has become complicated, and salaries have risen alongside this increasing complexity. The learning curve has become quite steep.

Studying frontend development is actually not easy. The number of frontend developers has grown because everyone kept saying that it was simple. In reality, you can see what you are doing right away, and this also attracted people because it motivated them during their learning process. Of course, this growth in developers couldn't last forever. We developed JavaScript, but we realized that we were somehow overloading it. We decided to tackle this issue, and we already discussed in the previous part how we arrived at this point. There are many frameworks to make work easier, but this complicates learning, complicates development, increases salaries, and attracts more people. So how did we decide to deal with this situation? We came up with many options. For example, we decided to implement code splitting. The idea is that instead of loading one JavaScript file, we load a small main file and then load only the JavaScript files necessary for that specific page. This solved the problem of speed, whether it was fast or slow.

Initially, we made the loading a bit faster, but that did not solve the problem of the websites still being slow. We constantly see those silly spinners on the site, indicating that something is loading somewhere. Even today, there are open-world games with a huge amount of graphics, and they don’t have these lags. You simply drive around in a hypothetical cyberpunk city, and it loads in the background without you noticing. However, in the frontend, which is super simple and lightweight, we suddenly encountered a huge number of spinners. We decided to split the code, and then various other approaches to application architecture emerged. At one time, we loaded everything from the server, meaning all the information and templates were rendered on the server. Then we got frameworks, and we started doing this on the frontend using JavaScript and templates from different frameworks. Now we are asking ourselves, what if we combine them?

Let's do server-side rendering in different ways. The initial loading happens on the server, while the rest of the application's work is done through API requests. It's cool and convenient, but it turned out that there isn't much information that needs to be displayed to the user right away. So, we decided to load some dynamic information immediately and fetch other parts of our site, our web application, separately. This is how we got various isomorphic architectures, different progressive hydration techniques, and everything else that is supposed to speed up application performance and simplify development. However, in reality, nothing worked as intended, and now developers have to learn what SSR is, what progressive hydration is, and what isomorphic architecture is. As a developer, you can't just know one thing; you need to know everything. In the past, there was nothing, and you didn't have to learn all this nonsense, but now all of this has emerged to simplify things.

I have to work, and I need to learn all of this. The work doesn't get any easier, and at some point, all our experiments with frontend development, all this evolution of frontend, the improvement of development, and the simplification of interfaces have led us to the point where we couldn't overcome the monster. At some point, we started doing everything to actually kill the front, because frontend is that very monster. We have already figured out why this monster appeared. We talked about how we invented frameworks, how we tried to combat these frameworks, and how we attempted to manage our complex applications, but it didn't really help us in their development and acceleration. And now we have started creating other tools that are supposed to replace frontend development. Here I have three contenders for the title of killer, or they are doing this together: no-code or low-code solutions, the movement towards SDK development, and messengers.

Let’s go step by step. First of all, today there is a huge number of low-code and no-code solutions on the market. I will talk about one example, which is a Dutch solution. It may not be the most well-known worldwide, but through this example, I can explain how everything is developing and where it is heading. 

So, there is this solution called Diks; you can put any name really, it doesn’t change much. The goal of Diks is to simplify the development of interfaces and data interactions. For this, a developer, if they wish, can create a vast library of components with their own design, functionality, and interactive features. Then, other developers, whom we call Diks developers, can simply reuse these components by dragging them onto the page using a graphical interface, connecting them with arrows, and possibly adding some type of interaction. If there is any authentication, you can easily drop it onto this canvas.

A special element for two-factor authentication requires you to input the necessary data, such as a Secret Client ID and some URL. Everything else can be handled by the system itself, and there's no need for additional effort. This way, you can create a huge number of interfaces very quickly. The bank I work for is actually doing this; they are starting to move away from developing front-end applications using React or other tools, and are transitioning to a system where all the components are already available. As I mentioned, you can quickly assemble the components linked to our APIs, and your site will be fully operational. The components can be of any type; they can be simple text headers, checkboxes, radio buttons, or they can be complex graphics, maps, or beautifully designed pages with a picture in the background. When using a component, you just need to provide the path to the image and the text.

which are written, boom, you have a beautiful thing right away. And all of this, of course, directly affects the frontend because in our bank, we no longer need frontend developers. I am conditionally firing all of them. Backend developers are completely different people with different knowledge, and our new backend developers, who are much cheaper, simply sit and drag elements in the graphical interface. The next potential killer, or one of the killers of frontend development, is LSTK development. Today, we can see how the market is generally moving towards LSTK development. There are many vacancies today where knowledge of, conditionally, Node.js and React is required; this is a full-stack developer, and most likely, they will be doing something related to server-side rendering and APIs, and so on. Plus, we can see that the frameworks themselves are starting to move towards LSTK development. That very server-side rendering, for example, means that now a backend developer not only writes...

Components in React, if it is done using the same React, now it should know how Ken works. It should be able to make requests from the backend, process them, and understand what Hydra is in the same React, because now data from Ken comes and the frontend can request it. This is all quite complex, but the developer now needs to at least understand something and be able to work in the backend because they are now working with the end of React. By default, React has already added support for SSR (Server-Side Rendering) because many use React specifically for server-side applications. Now, there are components for server-side rendering right in React, meaning React itself suggests that you learn it, as it will be useful. Additionally, there is one of the three most popular libraries today for frontend development called HTMX. HTMX is not just a JavaScript library; it is a JavaScript library that also encourages us to learn Ken because now, from the backend, we are not loading JS to render from our AJAX requests, but we are loading HTML.

The first rendering always happens on the server, and you can use React for this. However, it's not very convenient. You could use some Kendo templates, which means we need to learn the backend templates as well, especially if Python is used, for example, Handlebars or something else. We also need to learn the programming language used on the backend because now we will likely need to write something there. 

Many of you have probably seen this screenshot or something similar. The company Vercel added support for database queries in Next.js, which is a framework for server-side rendering applications based on React. Now, you can write complex SQL queries directly in the frontend and execute them. This means that developers working with Next.js will have to learn how SQL works, which is also part of the backend. So, the backend will need to be learned as well. 

And the third potential killer...

One of the killers of the frontend is messengers, and there is always an example from China: WeChat. WeChat in China replaces everything; you can communicate, make calls, send money, buy tickets, order taxis, and order food and grocery deliveries—all in one app. Essentially, in China, they created a single messenger from which users do not need to exit. In this direction, Telegram is currently moving as well. We have HTML applications within Telegram, we can handle payments, cryptocurrencies, channels, bots, calls—everything. In fact, there are many such messengers. Meta is trying to do the same with its Facebook Messenger, and Snapchat is also attempting similar things. Additionally, Facebook has Instagram, which is gaining features, so now it serves as a messenger, allows for calls, and users can post photos, videos, and everything else.

I think that other chatbots that we use today will also try to do the same. This means that a person will no longer need to visit a specific website; they will be able to open a bot or a channel of that website in Telegram and do everything directly from there. This means that now the development of that website is essentially unnecessary because in a chatbot, you work with primitive graphics that are very simple. If you have an HTML application opening or you do everything using buttons and the standard interface of Telegram itself, you are programming a bot that will perform the functions of a chatbot, but you are no longer programming the frontend. 

Here are some examples: This is Messenger; you can guess by the icon that now it includes money, purchases, and some HTML pages. The same goes for Telegram. This is a screenshot from a promotional video showing how to create an online store in Telegram using HTML, so to speak. In general, by using a web application, you can create a full-fledged store where you can...

ordering goods and paying for them immediately. Invoices will be issued for these goods, and various cards are supported, with payments also possible in the same cryptocurrency. In general, all of this exists, and as I mentioned, it means we won't be focusing on front-end development. Instead, we will be creating back-ends to implement bots in Telegram. Now, let's summarize what this could mean for us as front-end developers and what we should do. I believe that front-end development will change again; it always does. It will simply become different. Some may say it will now become full stack, but I think that front-end development will still remain relevant. Not all websites are complex and interactive, but even this aspect is likely to change, probably simplifying the development process for simpler front ends. This will be done with the help of No Code or Low Code services, and as developers, we must keep up with these changes. We need to understand and see how front-end development is evolving and how it affects...

Our career and work, and consequently our happiness, money, and everything else, require us to be ready to constantly learn something new. We already know this because we remember when new frameworks and libraries appeared every day, and we had to be familiar with them to get employed when needed. We also need to understand that we must now step outside the confines of the front-end box we are in, beyond this comfort zone, because it is possible that front-end development will change significantly. As developers, we may need to transition from front-end developers to conditional full-stack developers. We must recognize this and continually try to experiment on our own within this conditional band so that in the future, if we need to switch to it, we already have some skills and knowledge. That's basically everything. If you have any comments on this, please write them below. Like this video.

If you liked the video, subscribe to the channel so you won't miss my other videos. But I’m not saying goodbye; this is the internet, and we’ll see each other soon.

Кто и почему убивает Фронтенд?

Кто и почему убивает Фронтенд?

스크립트