October 13, 2013 at 19:05Node.js and the new frontend on the web
- Transfer
(The original date is October 7, 2013. The original has a very lively discussion in the comments)
Front-end developers have a rather long and complicated history in programming. It was so easy to display to the browser for so long that there was no real need for this specialization. Many believed that they were just graphic designers with slightly different expressive means. 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 both and have this job.
Javascript was a technology that began to change the idea of front-end developers, transforming them into interface engineers. This fun toy language, from which serious programmers turned their noses, became the driving force of the Internet. As new browsers appeared, CSS and HTML created cross-browser incompatibilities that quite clearly defined 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 hype with Ajax, the work of the interface developer was associated primarily with technology in the browser. HTML, CSS, and Javascript were the top priorities in which we only needed a web server to ensure that everything was properly displayed on the frontend. In a sense, there were two interfaces - one in the browser, and the other on the server, which generated the necessary data for the browser. There was very little control over the server layer of the interface, most often built by backend developers who rarely understood the needs of “front-end engineers”.
In this architecture, the interface layer in the browser was the only area of front-end work. The backend interface, where the interests of front-end and back-end developers 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 a server application for communication with the execution of business logic.
Thus, the frontend was the browser, and everything else was the backend, despite the presence of a contact at the background interface level. Basically, this was until recently.
At the first appearance, nodeJS generated a wave of enthusiasm among front-end vendors, 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 significant release. It was no longer necessary 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 I had to use it to work on Yahoo. I complained about the time when I had to do debugging, and about the stupid quirks of the tongue, with which it was easier to shoot yourself in the foot than it should have been. After 6 years of Java server I moved to the trough in PHP. I believed and continue to believe that statically typed languages are exactly what I would like to see in the insides of business logic. Despite how much I love Javaccript, there are things I don’t want to see written in Javascript - a shopping basket in an online store, for example.
In my opinion, nodeJS will never replace everything on the server with Javascript. Its delightful mechanisms and empowerment do not make it the only right choice. No, as for me, I mean something completely different: releasing 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 an interface backend on a separate server. If all business requests are executed through REST, then all that is needed is to be able to communicate through REST. Do backend engineers care about page-to-page transitions? About single-page or full page refresh? About running jQuery or YUI client? usually not always. They care primarily about the storage, processing and safe and error-free use of data.
And here nodeJS gives frontendors a lot of opportunities. Backers can write REST requests in any language. We, the front end, can use nodeJS to work with the server level in pure JS, performing the necessary functions through REST requests. Now there is a clear separation of responsibilities. The frontend has now expanded to the server, to the borders of the UI on nodeJS, and the rest of the tasks are left to the backend.
This infringement of the interface by the ancestral lands terrifies the knights of the "back end", many of whom still harbor the illusion of JS as a toy language. In my experience, they are the ones that disagree about whether or not nodeJs are accepted into the project. A backend is a disputed territory between two types of engineers. I see no other reason than the desire to leave "everything as it was." As soon as you receive the server - get the responsibility of the backend. Downtime and it is clear that this is a struggle for spheres of influence.
However, this should not be so. Separation of backend-UI and backend-business logic makes sense only in large systems. Why do front-runners care about performing critical business functions in the server language? Why do business functions fall into the backend UI? The needs of the interface are fundamentally different from the needs of the backend. If you follow architectural approaches, such as the principle of sole responsibility, separation of interests and modularity, it seems almost silly that until now you have not had such a separation.
In addition, nodeJS did not exist before. Not a good option for frontend developers to create a backend UI in their own language. If you wrote in PHP, why not write frontend templates on it? If you wrote in Java, why not use JSP? There was no better choice for front-end vendors 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 entire backend should be written on Noda just because it "can." However, I am convinced that nodeJS gives front-end providers the opportunity to fully control their area of responsibility (front-end and backend-UI), which allows us to do our work efficiently. We have experience in how to display a high-quality frontend and know little about how the data is processed on the backend. Tell us how to get the necessary data and how to tell the business logic what to do with the data, and we will be able to create a beautiful, productive, affordable interface that customers will love.
The use of Nodes for the backend user interface, moreover, frees the backend from a number of tasks and problems in the solution of which they have no interest. We can get to the creation of such web applications in which the front-end parts talk to each other without affecting the REST level, which allows us to have fast iterations of the interface 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 does not reflect the point of view of my employer, my colleagues, the publisher of the book publishing house where I am publishing, 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 history in programming. It was so easy to display to the browser for so long that there was no real need for this specialization. Many believed that they were just graphic designers with slightly different expressive means. 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 both and have this job.
Javascript was a technology that began to change the idea of front-end developers, transforming them into interface engineers. This fun toy language, from which serious programmers turned their noses, became the driving force of the Internet. As new browsers appeared, CSS and HTML created cross-browser incompatibilities that quite clearly defined 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 hype with Ajax, the work of the interface developer was associated primarily with technology in the browser. HTML, CSS, and Javascript were the top priorities in which we only needed a web server to ensure that everything was properly displayed on the frontend. In a sense, there were two interfaces - one in the browser, and the other on the server, which generated the necessary data for the browser. There was very little control over the server layer of the interface, most often built by backend developers who rarely understood the needs of “front-end engineers”.
In this architecture, the interface layer in the browser was the only area of front-end work. The backend interface, where the interests of front-end and back-end developers 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 a server application for communication with the execution of business logic.
Thus, the frontend was the browser, and everything else was the backend, despite the presence of a contact at the background interface level. Basically, this was until recently.
NodeJS implementation
At the first appearance, nodeJS generated a wave of enthusiasm among front-end vendors, 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 significant release. It was no longer necessary 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 I had to use it to work on Yahoo. I complained about the time when I had to do debugging, and about the stupid quirks of the tongue, with which it was easier to shoot yourself in the foot than it should have been. After 6 years of Java server I moved to the trough in PHP. I believed and continue to believe that statically typed languages are exactly what I would like to see in the insides of business logic. Despite how much I love Javaccript, there are things I don’t want to see written in Javascript - a shopping basket in an online store, for example.
In my opinion, nodeJS will never replace everything on the server with Javascript. Its delightful mechanisms and empowerment do not make it the only right choice. No, as for me, I mean something completely different: releasing 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 an interface backend on a separate server. If all business requests are executed through REST, then all that is needed is to be able to communicate through REST. Do backend engineers care about page-to-page transitions? About single-page or full page refresh? About running jQuery or YUI client? usually not always. They care primarily about the storage, processing and safe and error-free use of data.
And here nodeJS gives frontendors a lot of opportunities. Backers can write REST requests in any language. We, the front end, can use nodeJS to work with the server level in pure JS, performing the necessary functions through REST requests. Now there is a clear separation of responsibilities. The frontend has now expanded to the server, to the borders of the UI on nodeJS, and the rest of the tasks are left to the backend.
Not! Fearfully!
This infringement of the interface by the ancestral lands terrifies the knights of the "back end", many of whom still harbor the illusion of JS as a toy language. In my experience, they are the ones that disagree about whether or not nodeJs are accepted into the project. A backend is a disputed territory between two types of engineers. I see no other reason than the desire to leave "everything as it was." As soon as you receive the server - get the responsibility of the backend. Downtime and it is clear that this is a struggle for spheres of influence.
However, this should not be so. Separation of backend-UI and backend-business logic makes sense only in large systems. Why do front-runners care about performing critical business functions in the server language? Why do business functions fall into the backend UI? The needs of the interface are fundamentally different from the needs of the backend. If you follow architectural approaches, such as the principle of sole responsibility, separation of interests and modularity, it seems almost silly that until now you have not had such a separation.
In addition, nodeJS did not exist before. Not a good option for frontend developers to create a backend UI in their own language. If you wrote in PHP, why not write frontend templates on it? If you wrote in Java, why not use JSP? There was no better choice for front-end vendors 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 entire backend should be written on Noda just because it "can." However, I am convinced that nodeJS gives front-end providers the opportunity to fully control their area of responsibility (front-end and backend-UI), which allows us to do our work efficiently. We have experience in how to display a high-quality frontend and know little about how the data is processed on the backend. Tell us how to get the necessary data and how to tell the business logic what to do with the data, and we will be able to create a beautiful, productive, affordable interface that customers will love.
The use of Nodes for the backend user interface, moreover, frees the backend from a number of tasks and problems in the solution of which they have no interest. We can get to the creation of such web applications in which the front-end parts talk to each other without affecting the REST level, which allows us to have fast iterations of the interface 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 does not reflect the point of view of my employer, my colleagues, the publisher of the book publishing house where I am publishing, or anyone else. I speak only for myself, not for them. You can leave your answer in the comments.