Distributing Processing Loads via JavaScript Frameworks
For the longest time, web applications absorb processing loads on the server-side, leaving the client-side to mostly just rendering the response (i.e. HTML/CSS) from the web server. Now, with JavaScript frameworks like Angular, React, Vue, etc., the client-side is sharing the processing load.
JavaScript has leased new life with the many JavaScript frameworks that gained popularity in recent years. Overall, the goal of these products pretty much allows the client to provide a rich web UI/UX experience. It started with AJAX. Then there's SPA. Then there's jQuery. Next thing you know, front-end developer careers are trending again.
For the many JavaScript frameworks, in order to give web apps rich UI/UX features, most of the processing loads are actually performed at the client's PC or device. "Modern" browsers need to support this, and it can be taxing to the PC/device's available CPU/GPU, RAM and storage.
Meanwhile, the web server can use less of its resources from rendering mark-up. Instead, the web server can focus its resources more on receiving/providing data and to serving more concurrent request/response operations.
Whatever cost the server saved, the client pays for. Think equilibrium: Nothing can be gained without loss; likewise, nothing can be lost without gain. If you are wondering why devices need to be more powerful (and more expensive) every year, this is one reason why: more and more of what used to happen on the server-side are now actually being pushed to the client.
Regardless how well a modern browser can execute a JavaScript, if there's just too much, then there's just too much. This is something that developers should be careful about. There are limits... and developers should not forget.
Apps are not [JavaScript framework name] implementations. Just because you are using a JavaScript framework doesn't mean you should use it 100%, even if it doesn't make sense anymore. Just because you are not using it 100% shouldn't even raise the question "what's the point of using [JavaScript framework name]?" Developers shouldn't use an app project as the outlet of personal bias and/or loyalty. App development is not a religion. A mix of this and that may work better than forcing everything in a single opinion.
As much as possible, developers should balance how processing loads are distributed/split between servers and clients. Render and cache whatever can be rendered and cached on the server-side. If that XML or JSON data is big, trust the server to process it for the client -- in fact, consider paginating large data from the server-side. Note that some processes must stay at the server-side, so keep them there.
Front-end web development has never been more exciting than ever. However, it can also mean new pit falls and problems as data grow in size and the application scope becomes more complex. JavaScript frameworks enable distributing processing loads between server and client. The client parts are not suppose to take all the loads away from the server. Developers should be mindful about balancing what stays in the server and what goes to the client. Be ready. Be flexible. Be smart.
JavaScript has leased new life with the many JavaScript frameworks that gained popularity in recent years. Overall, the goal of these products pretty much allows the client to provide a rich web UI/UX experience. It started with AJAX. Then there's SPA. Then there's jQuery. Next thing you know, front-end developer careers are trending again.
For the many JavaScript frameworks, in order to give web apps rich UI/UX features, most of the processing loads are actually performed at the client's PC or device. "Modern" browsers need to support this, and it can be taxing to the PC/device's available CPU/GPU, RAM and storage.
Meanwhile, the web server can use less of its resources from rendering mark-up. Instead, the web server can focus its resources more on receiving/providing data and to serving more concurrent request/response operations.
Whatever cost the server saved, the client pays for. Think equilibrium: Nothing can be gained without loss; likewise, nothing can be lost without gain. If you are wondering why devices need to be more powerful (and more expensive) every year, this is one reason why: more and more of what used to happen on the server-side are now actually being pushed to the client.
Regardless how well a modern browser can execute a JavaScript, if there's just too much, then there's just too much. This is something that developers should be careful about. There are limits... and developers should not forget.
Apps are not [JavaScript framework name] implementations. Just because you are using a JavaScript framework doesn't mean you should use it 100%, even if it doesn't make sense anymore. Just because you are not using it 100% shouldn't even raise the question "what's the point of using [JavaScript framework name]?" Developers shouldn't use an app project as the outlet of personal bias and/or loyalty. App development is not a religion. A mix of this and that may work better than forcing everything in a single opinion.
As much as possible, developers should balance how processing loads are distributed/split between servers and clients. Render and cache whatever can be rendered and cached on the server-side. If that XML or JSON data is big, trust the server to process it for the client -- in fact, consider paginating large data from the server-side. Note that some processes must stay at the server-side, so keep them there.
Front-end web development has never been more exciting than ever. However, it can also mean new pit falls and problems as data grow in size and the application scope becomes more complex. JavaScript frameworks enable distributing processing loads between server and client. The client parts are not suppose to take all the loads away from the server. Developers should be mindful about balancing what stays in the server and what goes to the client. Be ready. Be flexible. Be smart.
Comments
Post a Comment