This model works and it has distinct benefits. It also has drawbacks.
With the server responsible for much of the UI rendering, everything must be “baked” in one place (the server) and then shipped to another (the browser). It’s like trying to cook dinner at a nearby restaurant and then running the finished plates to your house. Dinner will be hotter and served faster if you just cook in your own kitchen.
Performance matters. The fastest car. The most powerful blender. The fastest search results. In all things, we want to have the best, fastest experience, especially in software.
One of the key bottlenecks in modern web development is network latency. The time it takes to make a request to the server and get the results can account for a huge portion of page load time, and with hit-and-miss mobile internet, the problem is magnified. Every byte that travels from server to browser matters. If your application can do more with fewer bytes from the server, it will feel faster to users.
For example, ASP.NET may make certain front-end tasks “drag-and-drop easy,” but it may not be the best platform for raw service performance (too much overhead). Maybe a lightweight NodeJS server would be a better simple, fast service provider.
Plug-ins will not power the next generation of rich mobile experiences. There are just too many devices and platforms for the plug-ins to ever achieve the necessary uniform distribution to be viable.
The same could be said for “native” apps. Businesses will tire of rebuilding an app 3 to 5 times just to make it accessible on devices. It’s a necessary evil of today’s phones and tablets (largely due to the app store distribution model), but there is growing momentum that suggests HTML5 could become the new “standard” in “native” app experiences, too.
And with supporting technologies like SVG, Canvas, and WebGL, standards-based development stands poised to have the power to do anything a plug-in or native app can do, with all of the reach a plug-in can never have and all of the convenience native apps can never offer.
For “web development” to replace the “desktop” platforms that have come before, it must provide experiences that work all the time, with and without active connections to the Internet. To use the classic scenario, the apps must work on a plane ride (and not some fancy plane with WiFi).
Server-side development has the crippling requirement to talk to the server after most user interactions. The moment you take the server away, the site or app is a paperweight.
@toddanglin on Twitter
Copyright © 2017, Progress Software Corporation and/or its subsidiaries or affiliates. All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.