Often times a topic comes up during design phase of a project that with regards to choice of form technology, it is better to go for client side rendering technologies like HTML 5, JQuery, CSS or server side technologies like ASP.Net and which one is better for content based webpages Vs digital forms
Difference Between Content and Dynamic/Digital Forms
| Content Forms | Digital/Dynamic Forms |
| In content form the primary focus is to load the first part of content as soon as possible so that user can start reading the content and when user clicks on any navigation controls like sections fresh content can be downloaded for e.g. SharePoint home page, News content etc. | In dynamic forms, the form has to be rendered dynamically based on data coming from backend systems. Such forms will have controls of different types instead of just images, text and hyperlinks. Also these forms invariably will have business rules, lookups to external system to dynamically display the content on the UI. Also styling and validations is applied to the rendered form on the fly to make it more pleasing and responsive |
| Page structure is pretty much static so can be rendered immediately and data can be bound as page structure would remain same. | Page structure and styles are dynamic. Based on data different parts of forms need to be displayed or hidden, marked read only etc. so all controls and rules on form needs to be processed before it is displayed else users would start seeing a flicker where controls appeared blank and then disappeared as rules were applied to them. |
| For pages where the initial page load has to be very fast (e.g. for E-Commerce pages or Content pages or social network with users in remote countries) Server side rendering is the better solution. | Client side rendering is usually recommended and that is the trend all products are moving towards. If you want to offer an app with a fancy page transitions, lazy loading of content and less traffic you can consider client side rendering.
|
| Initial rendering of form is faster as HTML is generated on server side using pre-compiled code and uses server resources and very less logic on browser side. However once form loads, every subsequent click like clicking a section or a dropdown will have to make a trip back to server even with AJAX calls which deteriorates the user experience somewhat specially when using on mobile and tablets. | Initial loading of forms is slower compared to server side rendering as these apps load entire payload upfront including data, business logic which is necessary for user interaction. However once form is loaded the whole UI experience is very fluid and fast as it does not have to make callback to server to get the additional information unless new data is needed. All rules, display decisions, calculations etc. are made on client side itself which gives very good user experience for users working on forms for longer time filling the data. |
| This involves more data transfer as whole page is always rendered on the server and transferred over the network everytime which is bad for mobile and tablet kind of devices which have access to limited bandwidth | This involves smaller chunks of data to be transferred over the wire in form of JSON and the cached Javascripts can boot up the whole UI with lesser network traffic. This is very important as Enterprises usher in the new era of smart devices and need to build apps for next few years. The server only needs to send small JSON objects and the JavaScript code on the client has the responsibility to create the html structure. |
| Gives better performance during page load phase | Gives better performance and user experience after page loads. |
| You can control performance of the server hardware to control page rendering | Client side rendering is dependent of the performance of the device on which it is rendering and hence can differ between old and new hardware |
| If you are very performance conscious as far as initial page loading is concerned, go for server side rendering but it will take more effort and complexity. The traditional approach of sprinkling JavaScript on top of server-rendered HTML was fine for a long time, but the more AJAX and other ad-hoc dynamic behavior you have, the more it turns into a giant ball of mud. This is what client side rendering addresses. Server side rendering comes at complexity cost because while all of the issues above can be eliminated with code, the solutions will add very significant complexity to your project.
|
If you want to create an application with a few lines of code and performance is a nice to have feature client side framework is the perfect framework for you.
|
| If you don’t start building for client-side rendering today, your app is going to feel like legacy in just a few years’ time. This is going to be the norm for all sites, and in the not-too-distant-future, server-rendered stuff will feel very “legacy.” And will have to be rewritten | Prepares you for future app maintenance as workforces will transform into using smart devices, apps will be ready for it and would not have to be redesigned. |
| High maintenance effort as more functionality needs to be added as time passes | Less maintenance effort |
| A lot of previous generation of products and apps were built using server side forms for e.g. SharePoint, Salesforce Classic etc. which focused on fast loading times as pages were pre-compiled and kept in the server. However this resulted in more network bandwidth and lesser to no support for mobile/tablet devices. | Most products are already moving or have moved on to client side rendering to get much more modern and fluid user experience once form is loaded as that is what users have started expecting due to mobile devices experience. Like most mobile apps it is ok to show loading data initially but once loaded user wishes that swipes and gestures just work fast even on slow network. Salesforce kind of systems made a huge move towards Salesforce Lightning UI (client side rendering) to achieve this so that they can work better on these modern devices and cater to the needs of apps over next few years. |