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, popular products within those choices, and the pros and cons of each choice.
Here is a rundown of the latest stats provided by statista
The solutions architects first choice is to decide if they want to use server side or client side HTML 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.
2) Highly intuitive - Code the static html and indicate places in it where dynamic content will be inserted.
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.
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.
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.
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.
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.
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.
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) Laravel - The most popular PHP based server side framework.
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) Django - Python based rapid development framework, which is becoming more popular because of its simplicity, performance, and small footprint.
6) ASP.net - Microsoft's product is used by many large corporations, and typescript originated and is still maintained by this stack.
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.
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) Angular - Created by Google to create a client based UI that talks to stateless services.
4) Express - The server side of Node.js hosted client side frameworks. Often hosts the static content and services.