Node.js and new frontend on the web
(Original date - 10.10.2013. The original has a very lively discussion in the comments)
Front-end developers have a rather long and complicated programming history. For a long time being sent to the browser was so easy to display that there was no real need for this specialization. Many believed that they were merely graphic designers with slightly different means of expression. The idea that they could one day specialize in web technologies, HTML, CSS, Javascript was ridiculous; at best, the user interface is their destiny or, in the end, someone could specialize in one and the other and have this job.
Javascript was a technology that began to change the concept of front-end users, transforming them into interface engineers. This funny toy language, from which serious programmers turned up their noses, has become the driving force of the Internet. As new browsers appeared, CSS and HTML created cross-browser incompatibilities, which rather clearly determined the need for front-end developers. Today, front-end specialists are the most sought-after job candidates in the world.
Even after the start of the hype with Ajax, the work of the interface developer was associated primarily with technologies in the browser. HTML, CSS and Javascript were the main priorities, in which the web server was needed only to make sure that everything was displayed to the frontend properly. In a sense, there were two interfaces - one in the browser and the other on the server that generated the necessary data for the browser. There was very little control over the server layer of the interface, most often built by the backendators, who rarely understood the needs of "front-end engineers."
In this architecture, the interface layer in the browser was the only work area of ​​front-end vendors. The backend interface, where the interests of front-end vendors and backendors met, were the insides of the server application. There you will find caching, authentication and other critical parts of the application. The backend interface, often in the form of templates, was a thin layer of the server application to communicate with the execution of business logic.
')
Thus, the frontend was the browser, and everything else was a backend, despite having a contact at the background interface level. Basically, it was until recently.
At the first appearance, nodeJS generated a wave of enthusiasm among the front-runners, which has not been equal since the appearance of the term “AJAX”. The idea of ​​writing javascript on the server as a goal was a major release. There was no need to get out of PHP, Ruby, Java, Scala, or any other language in addition to working on the frontend. If the server can be written in Javascript, then our full knowledge is limited to HTML, CSS, JavaScript to get the full application. He promised such prospects, and it was very interesting.
I have never been a fan of PHP, but had to use it at work on Yahoo. I complained about the time when I had to debug, and about the silly quirks of the language, with which it was easier to shoot myself in the foot than it should have been. After 6 years of Java server, I moved to PHP trough. I believed and continue to believe that statically typed languages ​​are exactly what I would like to see in the guts of business logic. Despite how much I love Javaccript, there are things that I don’t want to see written in Javascript - a shopping cart in an online store, for example.
In my opinion, nodeJS will never replace everything on the server with Javascript. His amazing mechanisms and empowerment does not make him the only right choice. No, as for me, I have a completely different meaning: the release of the server UI from the rest of the server part.
With the transition of many companies to service-oriented design and REST, it is possible to allocate the backend of the interface on a separate server. If all business requests are executed via REST, then all you need to do is be able to communicate through REST. Do backend engineers care about moving from page to page? About one-page or full page refresh? Is it working on a jQuery or YUI client? as a rule, not always. They mainly care about storing, processing and safe and error-free data usage.
And here nodeJS gives the front end a lot of opportunities. Bekers can write REST requests in any language. We, the interfacers, can use nodeJS to work with the server level on pure JS, performing the necessary functions via REST requests. Now there is a clear division of responsibility. The frontend has now expanded to the server, to the borders of the UI on nodeJS, and the rest of the tasks remain backenders.
This encroachment of frontier guards on ancestral lands terrifies knights of the “rear end”, many of whom still harbor illusions about JS as a toy language. In my experience, it is they that cause controversy over the acceptance or non-acceptance of nodeJs into the project. The backend is a disputed area between two types of engineers. I see no other reason than the desire to leave "everything as it was." As soon as you get the server - get the responsibility of the backendors Simple and simple, this is a struggle for spheres of influence.
Nevertheless, it should not be so. The separation of backend-UI and backend business logic makes sense only in large systems. Why do the front-runners take care of performing critical business functions in the server language? Why should business functions get into backend UI? The needs of interfacers are fundamentally different from those of the backend If you follow architectural approaches, such as the principle of sole responsibility, division of interests and modularity, then it seems almost silly that you haven’t yet had such a division.
In addition, nodeJS did not exist before. Not the best option for front-end vendors is to create a backend-UI in your own language. If you wrote in PHP, why not write templates for the frontend on it? If you wrote on Java, why not use JSP? There was no better choice for frontendders to reluctantly take what was used on the server. Now it is.
I love nodeJS, I love all the possibilities that it opens. I definitely do not believe that the whole backend should be written on Noda just because it “can”. However, I am convinced that nodeJS gives front-end users the ability to fully control their area of ​​responsibility (front-end and backend-UI), which allows us to do our work effectively. We have experience in how to output a high-quality frontend and know little about how data is being processed on the backend. Tell us how to get the necessary data and how to tell bmznes-logic what to do with the data, and we can create a beautiful, productive, accessible interface that customers will love.
The use of a node for a backend user interface, moreover, frees backends from a variety of tasks and problems that they are not interested in solving. We can get to creating such web applications in which the frontend parts talk to each other without affecting the REST level, which allows us to have quick interface iterations without changing the business logic. Jump into it, the water is great!
Disclaimer Any point of view and opinion in this article belongs to Nicholas C. Zakas, and in no way reflects the points of view of my employer, my colleagues, the editorial staff of the publishing house, where I publish, or anyone else. I speak only for myself, not for them. You can leave your answer in the comments.
Front-end developers have a rather long and complicated programming history. For a long time being sent to the browser was so easy to display that there was no real need for this specialization. Many believed that they were merely graphic designers with slightly different means of expression. The idea that they could one day specialize in web technologies, HTML, CSS, Javascript was ridiculous; at best, the user interface is their destiny or, in the end, someone could specialize in one and the other and have this job.
Javascript was a technology that began to change the concept of front-end users, transforming them into interface engineers. This funny toy language, from which serious programmers turned up their noses, has become the driving force of the Internet. As new browsers appeared, CSS and HTML created cross-browser incompatibilities, which rather clearly determined the need for front-end developers. Today, front-end specialists are the most sought-after job candidates in the world.
Two levels of user interface
Even after the start of the hype with Ajax, the work of the interface developer was associated primarily with technologies in the browser. HTML, CSS and Javascript were the main priorities, in which the web server was needed only to make sure that everything was displayed to the frontend properly. In a sense, there were two interfaces - one in the browser and the other on the server that generated the necessary data for the browser. There was very little control over the server layer of the interface, most often built by the backendators, who rarely understood the needs of "front-end engineers."
In this architecture, the interface layer in the browser was the only work area of ​​front-end vendors. The backend interface, where the interests of front-end vendors and backendors met, were the insides of the server application. There you will find caching, authentication and other critical parts of the application. The backend interface, often in the form of templates, was a thin layer of the server application to communicate with the execution of business logic.
')
Thus, the frontend was the browser, and everything else was a backend, despite having a contact at the background interface level. Basically, it was until recently.
Implementation nodeJS
At the first appearance, nodeJS generated a wave of enthusiasm among the front-runners, which has not been equal since the appearance of the term “AJAX”. The idea of ​​writing javascript on the server as a goal was a major release. There was no need to get out of PHP, Ruby, Java, Scala, or any other language in addition to working on the frontend. If the server can be written in Javascript, then our full knowledge is limited to HTML, CSS, JavaScript to get the full application. He promised such prospects, and it was very interesting.
I have never been a fan of PHP, but had to use it at work on Yahoo. I complained about the time when I had to debug, and about the silly quirks of the language, with which it was easier to shoot myself in the foot than it should have been. After 6 years of Java server, I moved to PHP trough. I believed and continue to believe that statically typed languages ​​are exactly what I would like to see in the guts of business logic. Despite how much I love Javaccript, there are things that I don’t want to see written in Javascript - a shopping cart in an online store, for example.
In my opinion, nodeJS will never replace everything on the server with Javascript. His amazing mechanisms and empowerment does not make him the only right choice. No, as for me, I have a completely different meaning: the release of the server UI from the rest of the server part.
With the transition of many companies to service-oriented design and REST, it is possible to allocate the backend of the interface on a separate server. If all business requests are executed via REST, then all you need to do is be able to communicate through REST. Do backend engineers care about moving from page to page? About one-page or full page refresh? Is it working on a jQuery or YUI client? as a rule, not always. They mainly care about storing, processing and safe and error-free data usage.
And here nodeJS gives the front end a lot of opportunities. Bekers can write REST requests in any language. We, the interfacers, can use nodeJS to work with the server level on pure JS, performing the necessary functions via REST requests. Now there is a clear division of responsibility. The frontend has now expanded to the server, to the borders of the UI on nodeJS, and the rest of the tasks remain backenders.
Not! Fearfully!
This encroachment of frontier guards on ancestral lands terrifies knights of the “rear end”, many of whom still harbor illusions about JS as a toy language. In my experience, it is they that cause controversy over the acceptance or non-acceptance of nodeJs into the project. The backend is a disputed area between two types of engineers. I see no other reason than the desire to leave "everything as it was." As soon as you get the server - get the responsibility of the backendors Simple and simple, this is a struggle for spheres of influence.
Nevertheless, it should not be so. The separation of backend-UI and backend business logic makes sense only in large systems. Why do the front-runners take care of performing critical business functions in the server language? Why should business functions get into backend UI? The needs of interfacers are fundamentally different from those of the backend If you follow architectural approaches, such as the principle of sole responsibility, division of interests and modularity, then it seems almost silly that you haven’t yet had such a division.
In addition, nodeJS did not exist before. Not the best option for front-end vendors is to create a backend-UI in your own language. If you wrote in PHP, why not write templates for the frontend on it? If you wrote on Java, why not use JSP? There was no better choice for frontendders to reluctantly take what was used on the server. Now it is.
Conclusion
I love nodeJS, I love all the possibilities that it opens. I definitely do not believe that the whole backend should be written on Noda just because it “can”. However, I am convinced that nodeJS gives front-end users the ability to fully control their area of ​​responsibility (front-end and backend-UI), which allows us to do our work effectively. We have experience in how to output a high-quality frontend and know little about how data is being processed on the backend. Tell us how to get the necessary data and how to tell bmznes-logic what to do with the data, and we can create a beautiful, productive, accessible interface that customers will love.
The use of a node for a backend user interface, moreover, frees backends from a variety of tasks and problems that they are not interested in solving. We can get to creating such web applications in which the frontend parts talk to each other without affecting the REST level, which allows us to have quick interface iterations without changing the business logic. Jump into it, the water is great!
Disclaimer Any point of view and opinion in this article belongs to Nicholas C. Zakas, and in no way reflects the points of view of my employer, my colleagues, the editorial staff of the publishing house, where I publish, or anyone else. I speak only for myself, not for them. You can leave your answer in the comments.
Source: https://habr.com/ru/post/197358/
All Articles