Do all business logic on the client using JavaScript?

History look

The first applications were running on “the” computer. There was nothing like “client” and “server”. There was the computer and the punch card input, printer output. Later the mainframe came and the clients were terminals. Looking back, we can say that this was a two tier architecture with lightweight clients. This was practically the same with the mini computers (PDP, VAX and their clones) until the PC was introduced.

The PC architecture introduced the two tier paradigm that contained a fat client and file server or database server. Three tier architecture was supposed to replace the two tier architecture to have a no-so-fat client, server supporting business logic and storage on the third tier. Then came the web and the browser and the client was replaced by web page. Thin client was invented. At least the terminology was born that time. And during the last 20 years the web technology evolved and with HTML5 we have something on the client side that is very powerful and in functionality and in capability comparable to the thick client of the early PC era. If we consider the memory and CPU power we currently have an HTML5 capable browser fairly overcomes any early PC fat client.

Time to think about what is implemented in what tier. As we see the functionality, storage and code were dangling back and forth between the client and various server components. The optimal distribution of functionality was determined by the distribution and availability of CPU power in the different tiers, storage capabilities and network latency as well as bandwidth. Technology evolving changing the ratio between these changed where we put parts of the functionality.


Today clients are so powerful that we are tempted to put everything on the client. It is not only the available top-notch client, which is so powerful. We can also expect good cpu power, memory and bandwidth on the average client. Why not to put all functions on the client? Could we do all business logic on the client? Almost. There are some features, not mentioned above, that a client does not implement and is not likely to implement in the near future with the current architectures. Some of these are features like:

  • persistence
  • search
  • transactions
  • trust

Let us look at these features.


You can not store data reliably on the client. Backup, archive, audit logging are functions that are naturally live on a server. If ever any of these are implemented on a client machine that machine is operated as a server some way. If not impossible then probably expensive to do it on a client. Individual clients can not simply backed up and they have to communicate with each other to see the same state of the data that reflects the actual state of the modeled world.


Search is also something not likely to be implemented on the client. Search needs the data to search in. In some cases the data set can be copied to the client and thus the search can be implemented on the client, but in most of the cases the client will work only with a subset of the data, therefore search is implemented on the server.


Transactions are tied to data. If you sell airplane tickets you may not want to have a system that asks all other client terminals if the seat A in row 13 is still free on a certain line. That would be a total noise like a room full of people. Perhaps something like the old stock trading rooms may resemble to that.


Clients are owned by the person having physical access to the machine. Steve Halls’ talking moose said: “Never trust a computer you can not lift.” When it comes to physical security it is crucial the other way around: Never trust a computer somebody else can lift. In an application you can not trust any communication that comes from a certain client unless you established some trust. Password, card access whatever. But the trust to maintain is up to the server, which some bad guy can not nick.

Where does it come?

Single page applications contain static HTML, CSS and JavaScript. The server communicates with the client using Ajax, REST, JSON. The users identify themselves using some authentication, probably OAuth. After that the client application displays whatever the functionality of the application needs and the server provides only data functionality. All the server should do is CRUD with access control. Whenever a client wants to access some data the server has to check if the said user has the rights to read and/or to write the data. Other than that the server need not know anything about the business functionality.

Persistence services, like MySQL or MongoDB (to name one of SQL and NoSQL) are providing REST interface and the interfaces obviously do require authentication. However the authorization scheme of these interfaces are very weak. The usual approach is: if you authenticate you are authorized. There is no document or record level access control, which I see will come in the future. First we will have applications that work as a front-end to these persistence applications that check the authorization and based on that let or deny the operation to perform. However this solution is not optimal from the performance point of view. The logical implementation of such logic is where the data is: in the database.

If and when the databases will support such a record level authorization schema we can write all our code, or almost all code in JavaScript running on the client. Applications will be developed in JavaScript. Java will only remain for enterprise integration, connection handling to legacy systems. Java will be what Cobol is today. Will it?


8 thoughts on “Do all business logic on the client using JavaScript?

  1. chomnoue

    Even if you can let the client securely have access to the data base, how will you do if you want them to access from different devices and technologies? will you implement one version of the business logic for each technology ( browser, android, ios, linux and windows desktop)? How will you let other applications access your business logic?

    Liked by 1 person

    1. Peter Verhas Post author

      I do not say that the technology is ready and smooth, uniform and can be developed once and deployed anywhere. But technology goes into that direction. Browsers, android, ios, linux and windows desktops all can be programmed in JavaScript as well as server side.

      If you separate the business logic from UI in your JavaScript code the same code can be deployed on a server using the CRUD rest interface as well as on any user facing client.


  2. Greg Brown (@gk_brown)

    Putting business logic in the client is arguably fine if you are only going to have a single client app. However, if you plan to support multiple client apps (e.g. native desktop/mobile in addition to HTML), you’d need to duplicate that logic across all of your client implementations. That’s going to require a lot of extra development and testing. Placing business logic in the middle tier allows you to implement and test it once for all clients. It also allows you to more easily add support for additional clients in the future.

    Liked by 1 person

    1. Peter Verhas Post author

      The question is if that middle tier could be written in JavaScript and also executed on the browser. Considering that a browser becomes available on all platforms as native operating system application or embeddable into an application as a component it could be possible.


      1. Greg Brown (@gk_brown)

        I think that certain types of applications could benefit from the approach you describe. But I doubt that this type of approach will ever become a “universal” solution. As always, use the right tool for the job…


  3. Burak

    Hi Peter, I think there is much need for what you describe and a lot of people moving on that direction but on the other side still a lot of companies and individuals invest considerable amount of time and money to the business logic and from compettion perspective moving this investment to a tier that can easily be obtained by competirors is still a lot of risk.


  4. tvk

    My anticipation:
    The diversity in languages will remain, so Java will remain as in server side as in client-side (say Android). Even if new languages will appear, some of them will carry on Java’s heritage. The more important thing IMHO is, that clients will be more like microservices. They’re not tied to a particular server, they survive if the network is down, etc.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.