Transcription
In this video, I will look at the roadmap of a frontend developer and talk about which things from it were useful to me in my career, and which were not. My name is Lyosha Kripav, I have been working as a programmer since the late nineties. I have been doing web development for the last 11 years, since 2013. This video will be based exclusively on my personal experience, and what from this list will be useful to you personally will depend mainly on your luck. What is a roadmap? It is a list of technologies that, in our case, a web developer needs to learn in order to work in the profession. In Russian, this is called a "dorozhnaya karta" (road map). Many recommend using a roadmap when studying web development so as not to miss anything important. I found this version of the roadmap on the roadmap.sh website, and in my opinion, it looks quite sensible. The first point is "How the Internet Works." In my opinion, this is too broad a question. It covers absolutely everything I will talk about in this video. I think that here, in the first approximation, it is necessary to describe what a browser and a server are, where web applications are executed, and so on. There are plenty of videos on this topic on the internet, and I even have a couple on my channel. The next question is "What is HTTP?" HTTP is the main protocol by which data is transmitted on the web. There are a huge number of protocols in general. Here is a picture showing the main ones. When I searched for this picture, I was horrified by its size, because 90% of it you will never need, and for starters, it is enough to remember that web pages are sent from the server to the browser precisely via the HTTP protocol. A web developer should know that in HTTP there is such a thing as requests, that they go from the browser to the server, and the server sends back some data. That there are GET, POST, and some other types of requests. That there are headers in the request, and there is also HTTPS, in which all data transmission is encrypted so that it is impossible to decrypt even if you intercept this data. The next point is "What is a Domain Name?" If you have ever used a browser, you already know that this is possible. This includes the concept of national domains, how to register a domain, what domain names of different levels are, and what will happen if you don't pay for a domain on time, and what your boss will do to you if you are unlucky and it is your responsibility to renew domains. The next point is "What is Hosting?" Perhaps here you just need to know that a server application will run on some server that is somehow hosted somewhere in some company. The next question is about DNS. DNS is a system that associates domain names, for example, google.com, with the IP address of a server on the internet. All interaction between computers on the internet, between servers, and between a browser and a server occurs using IP addresses. An IP address is a server identifier. It is difficult for people to remember IP addresses because they are numbers, and it is much easier to remember a domain name, for example, google.com. In general, a beginner frontend developer does not need to know how DNS works. Personally, I have a general idea that there is some kind of tree-like structure of DNS servers. I once had to configure DNS for our company, but by and large, this is not frontend work. Of course, they will ask you about it at an interview, especially if the interviewer himself recently read an article on this topic, but in daily work, it is useful quite rarely. But the next question about browsers and how they work is important. And since you are a frontend developer, the better and more detailed you know how they work, the more impression you can make at an interview. For example, if you know in detail how web page rendering happens, if you know about JavaScript APIs, how they differ, about some internal architectural details, all this gives you more points as a frontend developer. In everyday work, this knowledge is useful to me at a fairly superficial level. It is enough to know what affects the performance and rendering speed of a web page. It is also important to understand that different browsers may follow standards differently, and that some things may work in one browser and not in another. The next point is HTML. Of course, you need to know the basics of HTML, because all your work as a frontend developer will consist of developing applications that generate HTML code as a result. Regarding the semantic web, as far as I understand, it is just a set of special HTML tags that show and reflect the structure of your document. In my practice, I have never directly encountered the semantic web. I have had to use ready-made HTML frameworks, and they use semantic tags under the hood, so having an idea of what these tags are and what they are for is useful. Next, regarding forms and validation, personally, I don't encounter forms very often in my daily work. All I need to know is what controls exist and how, for example, a checkbox differs from a radio button. I use all this at a fairly basic level. The next point is Accessibility. This is everything related to the ability of people with disabilities to use your website. This is one of those topics that I have not encountered in my professional career, and it seems to me that the smaller the company, the less likely they are to get around to dealing with it. At the last company where I worked, we only talked about the need to pay attention to this. At the current company, which is larger and more serious, all this is handled at the level of the web framework that we developed in-house, and I don't directly encounter it again. The next point is SEO basics, Search Engine Optimization basics. Whether you will have to deal with this in your professional career depends on the company you work for and the project you are working on. Personally, I don't have to deal with this in my current company because we are developing a web service that does not require being found through Google. At the previous company where I worked, exactly one person was engaged in this, who was responsible for the main website. The next point is CSS. I want to say right away that despite all my web development experience, I know CSS very poorly. In everyday work, I don't need much CSS knowledge, for example, because frontend can be done using various frameworks that can abstract HTML and CSS at different levels, and you can create quite decent-looking websites knowing CSS at a very basic level. If we look at the roadmap again, CSS has several sub-points, in particular, "Making layouts" about how to arrange and position elements on a page. Over the last 20 years, as I have followed this process, several approaches have appeared. A long time ago, in antiquity, we used tables for layout, then blocks and positioning appeared, and now, as far as I understand, CSS Grid layout or Flexbox layout is used. In the framework that we use at work, we use the Flexbox approach, and you will only encounter table layout when creating email newsletters. The next point is Responsive Design. This is everything related to the behavior of your page when the browser window size changes. This includes how your page will look on smartphones, as well as on different devices in general. In my opinion, this is a fairly important area, especially in the last 5-10 years when people increasingly visit your websites from mobile devices. The next point is JavaScript. "Learn The Basics" includes everything related to the language itself, its syntax, variables, loops, classes. "DOM manipulation" is how you can change the appearance of an already loaded page in the browser using JavaScript. In real life, you will very rarely have to do this directly. Now these operations are performed using frameworks, and many web developers don't even remember how to find an element with a specific ID in the DOM. The next point is Fetch API or AJAX. This is everything related to requests to the server from your web page. This is an important and deep topic, because your application, by and large, consists of its appearance and how it interacts with the server. If we are talking about a single-page application, of course, all interaction with the server usually happens via the Fetch API, which includes security aspects, different types of requests such as POST, GET, headers, and so on. The next point is Version Control Systems. There is only one sub-point here: Git, because in fact, it is the most popular system, and probably about 95% of developers have not used and will not have to use any other systems. Personally, for the last 11 years, I have exclusively used Git. Before that, we used a system called CVS at work, and I must say that Git is 100 times more convenient. This is also a very important topic, because without a version control system, you simply cannot work in a team. A version control system is an application that allows you to work with your source code, but this source code also needs to be stored somewhere. Therefore, the next section is VCS Hosting, i.e., hosting for your code. There are several sub-points here: GitHub, GitLab, and Bitbucket. These are the three most popular services that can host your code. Usually, it is enough for a web developer to be familiar with at least one of these systems. I wouldn't say this is a super important topic. If you have used pure Git and have never used any of these systems, for example, GitHub, it is usually not a reason for rejection for a frontend role. The next topic is Package Managers. Your application, as a rule, consists of a small amount of code written by you and your colleagues, and a huge number of libraries, modules, or packages written by other people and published on the internet for general use. Special applications called package managers are used to manage these dependencies and packages. The most popular is npm, and I think the second most popular is yarn. You, as a frontend developer, will definitely need to know npm; other managers are optional. The next point is Framework Choice. This is a very big topic, probably the biggest in the entire roadmap. A framework is a set of libraries that abstract low-level tasks, such as directly manipulating DOM elements or ensuring that the correct page is displayed depending on the URL entered in the browser. Frameworks significantly speed up the web development process. Choosing a framework that you like is probably as important as choosing a programming language that you like. If you have chosen one framework and worked with it for several years, it may take a significant amount of time to retrain for another. For example, for the last 8 years, I have been writing in React. Yes, I know that formally it is not a framework but a library, but it doesn't matter. When I came to my current job, part of the code was written in Angular. I did a few tasks using Angular, but it was quite difficult for me to do these tasks, and during code reviews, I received a huge number of comments about what needed to be corrected simply because I didn't know this framework. To my great fortune, after some time, we rewrote the part that was written in Angular to React, and now I continue to work with what I am used to. The next point is CSS Frameworks/Libraries. These are libraries that simplify the use of CSS. When you use such a library, instead of describing the appearance of each element, you can assign them ready-made classes that are in this library, and the appearance of these classes is designed to make everything look beautiful. I don't think it's necessary to know all the frameworks listed here. Personally, I don't know any. A long time ago, I used a library called Bootstrap. Well, now at my current job, we have a library written based on Ant Design. Next are CSS Preprocessors. Two of the most popular are listed here: Sass and PostCSS. I have used Sass a little. What are they for? For example, when you write your CSS, you have to specify element colors in many places to make the site look beautiful. You need a limited number of colors to be used everywhere, and when writing CSS, you have to repeat the same colors several times in different places. To get rid of such duplication, a preprocessor is used. You define a variable, assign it a specific color, and use this variable in different places. Plus, preprocessors allow you to include one style file in another, can have a more convenient syntax for nested classes, and many other useful things. In the next section of the roadmap are Build Tools, in particular, bundlers. When you write code, you end up with many JavaScript or TypeScript files that need to be combined into one or more files that will be loaded into the browser as a single block. This is exactly what bundlers are used for. Personally, in my career, I have used Webpack, which is probably the most popular of all those listed here. I think this is an important topic, but it's usually not something you have to deal with every day. When you start working on a new application, the bundler and all these tools are configured once, and then for many years, while you develop and maintain this application, you only occasionally change something in them. Therefore, personally, I know this topic quite superficially, and when I have to change something, I usually read the documentation for a long time and figure it out. Regarding Task Runners, the only option here is npm scripts. This is how you run various operations when developing an application, for example, locally run a web server, or check if your code is formatted correctly, or perform other auxiliary operations like running unit tests, and so on. These operations are described in package.json, a special file describing your project, and npm has a special command to run them. As a rule, these scripts are written once and then are edited from time to time during the life of the project. This is also not something you have to deal with every day. The next point is Linters and Formatters. If you work in a large team, you usually agree in advance on a code standard, for example, where to put spaces, how many indents to make at the beginning of a line, and so on. If you don't agree in advance, then during code review, it can come to a fight, and we don't want that, right? There are special utilities that automatically format your code or check if it is formatted correctly. This is a very convenient feature, although again, it's not something you have to deal with every day. Usually, linters or formatters are configured once, and personally, to change something, I also have to read the documentation for a long time. The next point is Testing. Writing unit tests, integration tests, and end-to-end tests. In my opinion, this is a very important topic. Personally for me, if I write tests, it gives me confidence that I won't break anything when my code is deployed to production. Therefore, tests are written not because the boss is so mean and wants everything to be covered by tests, but for your own peace of mind. There are many libraries for testing. For unit tests, I usually use Jest, and I think it's probably the most popular of these libraries. For end-to-end testing, we initially used Cypress at our current company. We didn't like it very much because of the syntax, so now we have switched to Playwright, and overall we are very happy with it. The next point is Authentication. This is everything related to authentication, tokens, protocols, and so on. This is already an advanced topic. If you are a Junior Frontend Developer, you can know nothing about it. The next topic is Web Security. This is everything related to making your website, your platform, difficult to hack. Guys who develop web browsers are quite concerned about this topic. For example, there are special restrictions that prohibit a web page from loading data from a server located on a different domain, or do not allow access to the camera if the user does not click a special button in a window whose appearance cannot be changed. All this is done so that, for example, if you are building a social network, users of this social network cannot post on their page and embed some JavaScript code into the page that will steal other users' passwords or photograph you at the most inopportune moment. Security is an advanced topic, and beginner developers encounter it very rarely. There are companies that don't bother with security at all, so if you're unlucky, you might not encounter this topic at all until a certain point. The next topic is Web Components. In the roadmap, it is again marked as optional, and in my practice, I have not encountered them. Type Checkers. And here the only sub-point is TypeScript. Very often, TypeScript is mentioned as a separate programming language, although in reality, it is a superset of JavaScript that allows you to explicitly work with data types, for example, to explicitly specify what type of data you are declaring a variable as, and TypeScript will ensure that you do not later assign a value of a different type to this variable. It sounds like a fairly simple and harmless thing, but it simplifies the programmer's work so much that TypeScript is one of the most beloved programming languages in the world, and this is understandable because poor souls who wrote in JavaScript then switch to TypeScript and are simply delighted with these capabilities. If you want to do something well, do it badly first, and then return it as it was. I also belong to this group, and I have a very high opinion of TypeScript. The next section of the roadmap is marked as optional, and then comes Server-Side Rendering. What is it? Your web application, if it is a Single Page Application, should normally be rendered in the browser. Server-Side Rendering technology allows you to render the application on the server, and this is necessary so that when you first open a page with your application, it should appear in the browser as quickly as possible. Well, and all subsequent changes, when you click on some buttons in your application, they are already rendered in the browser as usual. As for me, I am lucky, and I have not had to deal with server-side rendering in my work. Next comes GraphQL. This is a protocol for interaction between the client application, usually your application in the browser. GraphQL is a common alternative to REST API, and GraphQL differs from REST, for example, in that you can specify which fields you want to receive back in the request itself. I have a feeling that this technology is quite promising, but it seems that it is not very successful. If you are a frontend developer, you don't necessarily need to know GraphQL until you try to get a job at a company that uses this technology. Static Site Generation is another popular approach that, in my opinion, has gained popularity because technologies are becoming more and more complex, and frontend applications are becoming more and more cumbersome, and in contrast to this, many libraries have appeared for generating static pages, because for many cases, this is quite enough. In my career, I have not encountered the need to use any of these libraries, and if you are an average frontend developer, there is a high probability that you will not have to deal with this either. Next comes the big topic of Progressive Web Apps. Conceptually, I think this is an attempt to replace mobile applications for smartphones and, to some extent, desktop applications with web applications. The fact is that browsers are becoming more and more complex, they provide more and more capabilities, for example, rendering 3D graphics via WebGL, or accessing Bluetooth devices via Web Bluetooth, accessing USB devices. Therefore, with the help of web applications, you can do more and more complex things, and the next logical step, it would seem, would be to replace ordinary applications with web applications. So far, this is not going very well, but the topic is very interesting and relatively popular. At my previous job, we used this technology quite a lot, but unfortunately, not much at the current one. So, as I said, this is an optional technology, and for beginner frontend developers, there is absolutely no need to delve into this. The next topic is Mobile Development, and it includes platforms such as React Native, Flutter, Ionic, or NativeScript. I am interested in this topic, and at my previous company, where I was involved in mobile development, among other things, all our mobile applications were developed in React Native. Personally, I believe that mobile applications developed using these technologies, although they may not always compare in quality, performance, or other characteristics with native mobile applications (i.e., developed using Swift or Java), for very many companies, it is much faster, more profitable, and quite sufficient to write a mobile application in React Native. It will be no worse than a native application, and it will take half the time to develop. But in general, to be honest, I am surprised that this section is included in the frontend development roadmap. I would classify it as a separate section, more like mobile development, and for me, requiring a frontend developer to know mobile development in React Native or Flutter sounds quite strange. The next point is Desktop Applications. Yes, using web technologies, you can also write applications for Windows or Mac. A well-known classic example is the Visual Studio Code development environment, and the editor used there is called Monaco Editor. You can also use it in your web applications on a website, for example, in the web application that I am developing at my current job, we use this editor for editing SQL queries. But again, in my opinion, desktop application development is a separate topic and has no direct relation to web development. Okay, what's next? Next, if you have mastered these topics and don't know where to grow, you can move towards backend development on Node.js. The roadmap also shows that you can continue to study TypeScript. I can also add from myself that you can go into mobile development because it is a separate large area, and it is also, in my opinion, quite popular, and there are a decent number of vacancies there, especially for React Native. You can go into backend development, but this topic is less popular, and I think there are not so many vacancies there. But I want to say thank you for watching this video to the end. Once again, I suggest subscribing to the channel and finally starting to study all these technologies. This was Lyosha Kripav. Goodbye everyone.