Many companies large and small fret over which web application framework to use to create a new application. Listed below are the main categories of choices, products within those choices, and the pros and cons of each choice.
The solutions architects first choice is to decide if they want to use server side or client side HTML rendering.
1) Server side rendering
Originally all web application frameworks had the UI rendered server side. This is because the world wide web started out as static content, consisting of HTML pages. If you wanted to update your static website you would upload a newer version of your HTML file to your web server. Very quickly the need to make the web page dynamic, for example to render your bank account contents, became obvious so frameworks and entire programming languages were written to make this possible.
Pros
1) Highly intuitive - Code the static html and indicate places in it where dynamic content will be inserted.
2) Complete artistic design freedom - The look and feel of your web page is only limited by your ability to layout html and css. Many frameworks sell themselves as being component based, when the truth is that HTML already consists of components. They are called HTML input tags. The only drawback is that a good web designer can be hard to find, and they are usually a different breed than a web developer, usually experts in photoshop rather than javascript. So, if you want a truly beautiful and interactive web application you will often need both a web designer and a web developer.
3) Rendering is physically close to resources - When HTML is rendered server side, it is usually done on a server that is physically close to the database and/or service calls. In the modern world of cloud computing, this means it is done within the same virtual private cloud. The speed of light is fast but it is still much faster when servers are 20 feet apart instead of being located on different parts of the planet.
4) Inherently secure - Authenticated users have their authorization (aka access rights) stored server side where they cannot manipulate them. Furthermore, resources such as service endpoints and databases are beyond the reach of any bad actors. Vulnerable servers are behind the application server, out of site.
5) Strongly typed languages - Server side code is mostly written in strongly typed compiled programming languages, which minimizes programmer errors and provides a rich selection of interactive IDE choices. Client side languages will be used to interact with the user browser side, to provide a richer experience, but client side script is a much smaller percentage of the code.
6) Mature technology - Being over 20 years old, server side rendering and the libraries that support it are very complete and highly tested.
7) Large community - The majority of enterprise web applications are still built on server side UI rendering. Many companies are shifting to client side UI rendering for use cases that better fit that pardigm, but server side rendering is still the norm and the labor force that can work on these systems is the most abundant. Furthermore, extensive libraries of client side components and styling are available that are designed to work with this architecture.
8) Asynchronous communication - Early server side application architecture forced developers to refresh the entire page every time new information was needed. This is no longer the case. New information can be brought into the page using ajax calls, allowing any combination of data and layout to be refreshed without ever leaving the page. Single page applications can be easily written even when the layout is dynamically combined with the data server side.
9) Efficient Internationalization - Server side rendering is usually coupled with an in memory language Resource Bundle. Large web applications can have 1000's of translated phrases. By rendering the html server side the layout can be infused with these translations in thousandths of a second. On the other hand, client side rendering would require downloading of all of these translations client side and sewing the translations into the layout as another type of server side data, which best case can cause noticeable delays in rendering and worst case causes the user to believe the application is hung.
Cons
1) More bandwith - Since HTML has to be returned with every request, server side rendering sends more data. However, good HTML design that excludes inline styling and defines all styles instead in style sheets, and furthermore caches all of the static content browser side, greatly reduces the amount of layout that is transmitted, making the HTML very thin. Combine this good design with the stratospheric speed of modern networks and this con becomes more academic than a real world concern.
2) More memory usage on server - Server side rendering relies on user sessions to keep track of who a user is and to potentially cache other useful data. This means that the minimum footprint of a logged in user is their authentication and authorization state. It is up to developers to decide just how large a user session can become. Careless handling of session state can cause resource problems on the server, but good management can also keep the session size insignificantly small, especially if each server is not expected to handle more than 500,000 users at a time.
2) Client side rendering
Server side rendering has come a long way since 2000, but there are still use cases where it falls short. In particular, applications like Facebook are a collage of components that need to update independently from each other, yet all are displayed to the user at the same time. Even more demanding is the requirement that some subsets of these components aren't fully independent but need to work together. This kind of website is a very different animal from an airlines site or a bank site where the user generally does one thing at time, and therefore requires a different solution.
Pros
1) Full logical isolation of components - Components in client side frameworks aren't just parts of the page, they are more like independent web pages. They have their own independent layout, state, css, and transactions with the server.
2) Libaries of standard components - Just like server side rendering communities, the client side community has also created libraries of standard components with the vision of making web development become a plug and play development experience. The fuller logical isolation of components makes these widgets more portable especially since they carry their css along with them. Interestingly this does create the inverse challenge of having to figure out how to make components work with each other. The boundary that makes them more isolated also makes them harder to integrate.
3) Backing of some major technology companies - Angular is backed by Google and React is backed by Facebook. This means that these companies are throwing a lot of money at their frameworks as well as cultivating a fan base. While Facebook uses React in its major public facing applications, Google does not use Angular in any of its major public facing applications.
4) Integration with Node.js - Client side javascript frameworks appear to go hand in hand with the Node.js community. In fact, they have been so tightly integrated that it is actually hard to imagine developing a React application outside of Node.js. Many libraries and command line interface commands have been cobbled together to make development faster and more intuitive. It is interesting that Node.js has become the foundation of a lot of this development while it by itself remains the best server solution for only a subset of use cases. Node.js works best with web applications that have very short transaction times because it is single threaded.
5) Less memory usage on the Server - Since ideal client side javascript frameworks require very little to no server side memory state, this memory footprint is reduced on the servers, which makes client side applications potentially better scaling. However, some sort of authorization state still needs to be kept on the server side to verify who a request is coming from and what the user is allowed to do. So, the most accurate statement is to say that the server side memory footprint of a user is very small but it still exists.
Cons
1) Difficult to secure - The user's authentication and authorization has to be kept on the client since the server is ideally stateless, consisting of nothing more than service calls. Browser clients are inherently insecure because they are under the control of the user, and running on the user's machine. Therefore, complex encryption schemes need to be implemented to keep the credentials on the user's machine but not open to manipulation by the user. Furthermore, since all layout is cached on the browser, regardless of the user's role, pages that a user should not see are cached there. So, a sophisticated bad actor will have the entire attack surface of all other roles laid out for them.
Some companies solve the authentication issue by authenticating the user through a web server (not application server) and then using the web server as a reverse proxy to all the services. However, this is in affect maintaining a server side session on the web server instead of on an application server and defeats one of the "benefits" of a client rendering framework.
2) Complexity - Client side rendering requires much more javascript on the client than server side rendering. While server side rendering delivers the layout using HTML and the role of javascript is only to power some client side widgets and validation, client side rendering requires an entire ecosystem of javascript including a model, a view, and a controller. Angular out of the box, for example, delivers 30,000 lines of javascript code to the browser. The raw size of this stack is just the beginning of the complexity because these frameworks completely abstract the developer away from direct browser DOM operations. All layout, data, and flow control is done through a custom API. Developers no longer learn how to code javascript in a browser. They instead learn to code to the client side framework API. The learning curve for all of these API's is rather steep and therefore an entire industry of online and in person classes has sprung up to support these tools.
3) Difficult to debug - The debugging of client side javascript frameworks is generally difficult. The loose typing of javascript and the sheer size of the libraries leads to cryptic error messages that tell little of what the real problem is. The code running on the browser is often transpiled into a different form than what the developer wrote to begin with. For example, the developer wrote typescript and the compiler transpiled this to javascript and delivered it to the browser. There have been browser plugins specifically written to help with the debugging, but the complexity of the entire paradigm still often leaves the developer in a trial and error loop, wondering why things don't work.
4) Proprietary - Large client side javascript frameworks are very specific solutions that are almost impossible to port to another framework. While, server side rendering is far more standards based. To contrast, going from Struts to Spring MVC is fairly trivial whereas going from Angular to React would be a complete rewrite. In fact, Angular recently went from Angular 1 to Angular 2, and it was not backward compatible. Many compaines are spending millions of dollars making the Angular upgrade. HTML, CSS, and raw javascript are universally available and portable, whereas specific opinionated client side API's are not.
5) Integration with Node.js - While this can be a pro, it can also be a con. Some javascript frameworks are so integrated with Node.js that using them in the absence of Node.js is difficult.
6) Difficult to internationalize - Resource bundles have to be downloaded to the client and treated as data instead of being seamlessly included in the HTML at the server. Therefore, pulling down labels will need to be done as service calls, greatly slowing the performance of the application and making UI development more complex.
List of Frameworks and associated tools for 2022
Server side rendering frameworks
1) Ruby on Rails - Backed by a very enthusiastic and vibrant community and designed for web application development.
2) Spring MVC - The most popular choice for a java based serverside rendering framework, and supported by an enthusiastic and extensive java community.
3) Django - Python based rapid development framework, which is becoming more popular because of its simplicity, performance, and small footprint.
4) Struts 2 - Also a popular java based framework. Backed by the Apache Foundation and built to easily integrate with Spring. This is the easiest choice when converting from a Struts 1 framework to a more modern and secure framework.
5) ASP.net - Microsoft's product is used by many large corporations, and typescript originated and is still maintained by this stack.
6) Laravel - The most popular PHP based server side framework.
Server side rendering, associated client side tools
1) Jquery - Provides a single api interface for DOM manipulation in all major browsers
2) Jquery UI - Provides library of widgets backed by Jquery, such as drag and drop, dialogs, autocomplete, datepicker, progress bar, and more.
3) WebRocketX - A javascript based client side API that facilitates Single Page Architecture including navigation, partial page rendering, and structured error handling.
4) Animejs - Add animations to your javascript.
Client side rendering frameworks
1) Vue.js - The fastest rising star in the client side world. Provides a fairly intuitive paradigm compared to the other client side frameworks.
2) React - Created by Facebook to meet their needs for a scalable collage type user interface.
3) Express - The server side of Node.js hosted client side frameworks. Often hosts the static content and services.
4) Angular - Created by Google to create a client based UI that talks to stateless services.
Top comments (4)
ASP.net with C# is really exciting. The facts that large corporations use it should draw more attention.
Btw, how about Go frameworks like Gin, Fiber, etc and Go itself as a programming language ? I have seen a few jobs requiring it.
Nice!!
Thanks Liftoff. :)
np :)