DEV Community: matthewekeller

Click Fraud Is Impossible To Police

matthewekeller — Fri, 03 May 2024 01:42:01 +0000

The majority of large advertising networks, such as Google and Adsterra, bill by click and or impression.

An advertising campaign works as follows. The advertiser creates an advertisement, often an uploaded image with their logo and something appealing about their product. Clicking on this advertisement will lead a prospective customer to their website. They then set a daily budget maximum and indicate how much they are willing to play per click and then launch their advertising campaign.

The advertiser returns the next day to find all of their money up to their budget limit has been spent and sometimes a little more. Yet, often they have no engagement, nothing purchased. How are they to know that any of these clicks were real customers genuinely interested in their product? They really have nothing but trust in the advertising network to ensure them that this fire house of money leading away from their business had potential. Anyone who has tried online advertising is very familiar with this feeling.

Firstly, let's go over how the bad guys that are known to exploit advertising networks work the system. There are criminal organizations that stand up websites for the sole purpose of making advertising revenue through fraudulent clicks. They enroll in an advertising network, build up some trust serving ads but then they start to pay contractors to surf their website and click on advertisements. These contractors obviously have no intent to buy anything, they are paid pennies to click, but they do make money and so does the advertising host and wait for it ..... so does the advertising network. The big loser is of course the advertiser.

Secondly, let's discuss the motivation that ad networks have to police this kind of activity. They make money when this happens so the only motivation they have to prevent it is their reputation. Let's give them the benefit of the doubt and say they do everything they can to prevent it which leads to the third point.

Thirdly, it is super hard to prevent this. Things they can do are to be careful about enrolling websites in their system that aren't legitimate. How impossible is that? Maybe a website has been clean for years but suddenly decides they need more revenue and enrolls in a click network. The only way to detect that would be a suspicious pattern of dramatically increasing revenue. This of course is very subjective, and so easy to make mistakes. I think it is obvious that there is no perfect way to do this. Especially since a very sophisticated click network would consist of bots all over the world and these bots could be organized to gradually increase traffic and clicks on a website.

So the creepy feeling you get when your money goes down the drain and you don't see any increase in business... Trust your feelings.

So what is the solution to this? The solution is to pay for advertising the traditional way, by paying for time. Time on a billboard, time on a television show etc, or time on a website.

This is where AdsP2p.net comes in, because all advertising is purchased on a monthly basis. There is no pay per click so there is no click fraud. It's just not possible. You know exactly what you are getting for your money, and rest assured the new traffic on your website will be real people with real interest in your product.

Police lights image borrowed from ledequipped

Automated Web Application Code Testing On A Budget

matthewekeller — Tue, 23 Nov 2021 01:56:37 +0000

This post has been moved to https://webrocketx.com/automatedTesting.html

How does the browser magically see React changes in development?

matthewekeller — Sat, 13 Nov 2021 01:27:51 +0000

Several months ago I was new to React. As an experienced developer of classic javascript, one of the most objectionable things about the newer thick client frameworks such as React and Angular is the need to build the client side application to see changes. Let's face it, we are used to only having to refresh the browser page. Fortunately for us the community has has helped us out with this issue, specifically the Create React App community.

Following the instructions on the Create React App website, you will install Node.js, follow all their instructions and just like magic suddenly the browser refreshes every time you make a change, but how does this happen? The answer is more simple and more complex than you think.

1) Node.js, React, and Webpack are watching your code and transpiling it - It's no secret that React delivered to the browser is quite different than what you wrote. Your tsx code has to be changed to jsx and your jsx code has to be changed to javascript, and this javascript has to be packed up for delivery to the browser. Since you don't feel like doing this on your own some automation is in order, fortunately you will not have to think about this, just know that it is happening.

2) A socket has been created on the browser back to the server - This is where the real magic is because by creating a socket with the server, communication can be pushed to the browser instead of having the browser poll the server, which would be far more messy. So everytime you change your code, the chain reaction described in step one happens and then a message is sent up the socket to tell the browser to refresh the page.

There is a really interesting wrinkle to step 2. If you load your page and then fire up your DOM inspector you will not see this socket, which is super confusing. However, if you force a refresh of your browser page with the inspector open you will then see the socket. A bug perhaps in Chrome?

So there it is, a peak behind the curtain. Happy coding.

For more information on the latest frameworks, check out this article Common Frameworks for 2022.

Most Popular Web Application Frameworks

matthewekeller — Sat, 13 Nov 2021 00:49:09 +0000

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.

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) 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.

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.

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 Popular Frameworks and associated tools

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) 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.

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) 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.

Let's list what Type Of Web Frameworks are being used

matthewekeller — Fri, 29 Oct 2021 19:57:09 +0000

I think we all know that web application frameworks are quickly evolving, and that it often feels like a fashion industry. I think a good way to cut through the hype is to list our favorite websites and try to figure out what they are using. I appreciate anyones help, so post your findings in the comments and I will transfer them to my table. Often it is hard to tell what server side frameworks are being used so if we see html coming down in requests we will mark as server side rendering and take it from there. Client side javascript frameworks can usually be indentified by taking a look at the source. Remember, this is not what "companies" are using but what each specific web application is using. If a website is a mix of server side rendering and another js component framework, we will list that too.

For reference, here is a list of Common Frameworks for 2022.
Below is a table of our results so far.

Website	Server Side HTML	Primary Framework	Complimentary Framework
AirBnb	Y	Ruby On Rails	React
Irs.gov	Y	Unknown
Instagram	Y	Django	React
Spotify	Y	Django	Jquery, WebRocketX
Stack Overflow	Y	ASP.net
Facebook	N	React
VRBO	Y	Unknown
Taco Bell	Y	ASP.net
Microsoft	Y	ASP.net
Choice Advantage	Y	Spring MVC	Jquery
Github	Y	Ruby on Rails
Booking.com	Y	Unknown	Jquery
Amazon.com	Y	Unknown	Jquery
Amazon Web Services	N	Unknown
Gmail	N	Google Closure Library
Google Search	N	Google Closure Library
American Airlines	Y	Spring MVC	Jquery
Bestwestern Hotels	Y	AEM CMS
Twitter	Y	Ruby On Rails
Hulu	Y	Ruby On Rails
Paypal	N	Angular
dev.to (this site)	Y	Ruby On Rails
Turbotax	Y	Spring MVC
Zillow	Y	Spring MVC
Linkedin	N	dust.js
Wells Fargo	Y	Spring MVC	Jquery
Delta Airlines	N	Angular
AutoClerk	Y	Struts 2	Jquery
GoToMeeting Web	N	React
Toyota SalesConnect	Y	Spring MVC	Jquery, WebRocketX
WordPress	Y	RokkoMVC	Jquery
Washington Post	Y	Django
Nasa	Y	Django
Reddit	Y	Django

Web Application Frameworks 2022

matthewekeller — Wed, 27 Oct 2021 01:50:14 +0000

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

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

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.