What Does It Mean to Be a JS Front-End developer Nowadays?
Review JS evolution when jQuery was still alive until nowadays
What was before
Recently, JS has been called a toy language, the business logic mainly implemented on the backend side. JS is used only for adding some kind of simple interactivity with users that aren’t required a massive knowledge base.
In the past, FE JS developers should have known only the jQuery library and some basic knowledge with asynchronous requests to the server. Probably, the main challenge was to provide the same look and behavior across all browsers including older versions of Internet Explorer. FE JS developers sometimes didn’t even know about common patterns which are commonly used on the server-side. It is a time when most projects include separate HTML/CSS developers and JS developers.
All old applications were Multiple Page Applications. The main way to interact with an application was the browser on a computer or laptop. In this case, the server was responsible for building the HTML layout and putting data inside of it, the server is responsible for all business logic. Model-View-Controller (MVC) pattern shined on the back-end. On the front-end side, we just needed to implement some kind of modal windows and primitive animations, forms and upload those scripts in head section or before closed bodytag.
From Multiple Page Application to Single Page Applications
Everything has been changed so far with spreading smartphones and the Internet Of Things. It’s time when development moves from Multiple Page Applications to Single Page Applications. I believe that this transition drastically changed what means to be a JS Developer. Single Page Applications move a significant part of business logic from the server-side to the client-side.
The server is responsible only for a bunch of APIs, which should be called from the client as RESTfull API. The server isn’t building an HTML layout anymore. It’s time when JS developers have to know what the MVC pattern is. Moreover, it gets their modification and sometimes you may hear that on FE it may be called a Model-View-Whatever (MVW)
Big Three birth
JQuery library was getting a legacy library and new players come into play: Angular, ReactJS, VueJS. Compare with Java development, for example, the most popular framework which is used defacto is Spring, in our case, we constantly should choose which framework we need to tie our career. We need to participate in some kind of buttles, which framework is more suitable for a new upcoming project. It’s time when we need again and again to surf across articles with titles: Angular vs React vs Vue. It’s time when you’re a React developer today, but you have to be an Angular developer tomorrow chasing your dream project.
JS Bundlers and Package managers
The FE codebase is constantly growing which is split into thousands of separate files and we need some extra tools which would help to build a bundle for the application. It made develop a bunch of bundlers like gulp, webpack, rollup and etc. From now, we don’t need to have developers who are only responsible for the HTML/CSS part, it’s getting an integral part of any JS developer.
We also don’t want to find any CDNs of an external library, we should have our own package manager like Java developers are equipped with Maven. No problem, here is npm. You may say that besides Maven, Java developers have alternatives for Maven like Grudle. We already have an alternative for npm — yarn.
Recently, we just put all scripts in head section of the HTML layout. But it’s pretty a tedious task since if one script depends on another one, we need to track the particular order of included script in head section. It’s time for inventions, and JS land has been replenished with new patterns: CommonJS, AMD, RequiredJS. Finally, the best approaches from the module system have been reflected in ES6 Modules.
Design patterns
Since the main part of business, logic moved into the front-end part, we should take care of application scalability and it forces us to learn all patterns which are previously used only on the backend-side. We already know what the Gang of Four means right now and during FE development we start following SOLID principles and equip the application with such design patterns as Observer, Builder, Factory, Strategy, Adapter, Fasade, and so on.
New JS challenges
Developing the Single Page Application adds new challenges. A memory leak is a new word in our vocabulary. Despite the fact that JS is a high-level language and it has Gabarge Collector which is responsible for releasing memory automatically, it’s pretty easy to accidentally introduce memory leaks without basic knowledge. You may ask whether the memory leak existed for Multiple Page Applications, and the answer is YES. But the difference here is that as soon as we request a new page of the Multiple Page Application, JS releases all memory in Heap which has been allocated for the previous page. It’s unlikely that we come across with memory leak in this case even if it exists.
In a Single Page Application, we route between pages using Browser History API, which means that if we introduce a memory leak on one page, it gradually accumulates in JS Heap during page navigation quicker and we may run out of memory, and the application crashes.
Another issue which we need to sort out is SEO optimization. Classic SPAs have their content rendered client-side (in the browser). When your app loads, your server sends the browser an empty HTML shell and some JavaScript code to execute. It’s an issue since so far search engines aren’t able to take it into account. It makes us introduce new approaches — Service Side Rendering (SSR) and Static Site Generations (SSG). It’s time to invent new frameworks basing on existed ones. Let me introduce Gatsby, NextJS, NuxtJS.
If we’re implementing SSR, we couldn’t deliver all JS and CSS files as static content anymore, we should have a separate NodeJS server that would render all pages on the server-side. It probably means that we need to dive into some DevOps things, like how we suppose to deploy this on the server. Probably we also need to dockerize our application?
Testing
Oh, I forgot again, probably because I started work when JQuery was still alive 😎, but we already should know how to test our application. It’s not a tiny script anymore. It discovers the whole area of testing techniques and we put a new book on our bookshelf with a title like that: “Testing JavaScript Applications”. It brings new frameworks in our arsenal: Jest, Jasmine, Cypress and etc. When we provide a rough estimate to implement the particular feature, we also know that we need to take into account extra time to cover it with tests. Recently, only backend developers know what is Test Driven Development (TDD) or Behavior Driven Development (BDD), but this time has passed.
TypeScript birth
JS comes to us with dynamic types. On the one hand, it gives a lot of flexibility, on the other hand, it’s a source of a lot of bugs. We couldn’t put up with it, we are not worse than Java developers, who have fewer run-time errors than us since Java is a strictly typed language and they may discover a lot of issues on the compiler stage. We hadn’t had such kind of luxury before Microsoft introduced TypeScript. It helps us to write more expressive and less prone code, of course, we still don’t have the compiler stage, but we are equipped with the transpiler phase, which may expose a lot of bugs before it becomes a run-time error.
Microservice architecture
Time goes and a new tendency appears — transition from Monolithic Applications to Microservice Applications. At first, it affected only the server-side, but now we are equipped with tools that allow doing the same for the front-end as well. Webpack 5 introduced a Module Federation Plugin enabling multiple, independently built, and deployed bundles of code to form a single application. This is the foundation of Micro-Frontend Architecture and the Module Federation Plugin makes implementing such an architecture much simpler.
Conclusion
Frontend development has evolved a lot over the last decade, today any developer should know not only some specific details of vanilla JS, we need to know tons of extra tools. It’s an infinite process of gaining new knowledge, there’s no day when nothing happens in JS evolution. On the one hand, it doesn’t make our life easy, on the other hand, each day is an opportunity to find out about something new which we haven’t known before.
