Pros and Cons of a 100% HTML / JavaScript Web Application


I'm seriously thinking of developing a web application, using only HTML / JavaScript in the client-side for performance gain and whereby any and all communication needed with the server is done through requests to a WebService (yes, it will contain my business rule).

I would like you to (technically) cite the pros and cons of this technique.

asked by anonymous 09.06.2015 / 19:08

4 answers



  • WebDesigners has great ease with this architecture.
  • Your application is easily integrated with other systems. So you have to create an API to connect to your frontend. It is then possible to create multiple frontends,
  • Ease of unit testing.


  • Duplication of Validations. More than ever, you need to develop server-side and client-side validations. Never rely on a validation that is just on the client side.
  • Beware of Javascript frameworks that are still in the mature stage, can generate rework.
10.06.2015 / 17:38

Obviously all the post and cons depend not only on the technique used but also on the actual implementation.


  • Better user experience responding faster and with no breaks in the flow of information. The user does not see the engine working.
  • Reduced server load that does not need to "render" pages. Just work with the data.
  • Lower volume of data trafficked (in most cases, not much difference). Usually there is a noticeable gain in performance.
  • There is a greater decoupling between what is on the server and the client. Give designer more freedom. Eventually you can increase security.


  • Obviously the JavaScript requirement is working correctly.
  • Problems with SEO (not the fact that Google interpreted JS, did not solve the problem).
  • It is common to have more security holes exposing things you should not (XSS mainly). Exposure can cause other problems as well.
  • An application of these running too long in the browser can be a devourer of resources, especially if there are resource leaks, which is common.
  • There are cases that need to duplicate server code on the client.
  • The initial load may be higher and cause frustration (bad UX).
  • It's not simple to do it right.

There are some things that people complain about that are not problems anymore.

Obviously I may have forgotten something.

08.12.2015 / 16:41

I had made a misunderstanding of the question, so I decided to restructure my answer. I hope it helps in solving your question.


  • Centralized access to the data source making it easy to analyze usage, performance.
  • Easy maintenance / update of the public part of the application
  • Code Sharing
  • Cons:

  • Processing overhead
  • Blocking architecture, since a process that uses shared resources expects a dependent process to finish before initializing another.
  • Difficulty equating visual behavior across platforms and devices
  • High coupling / dependency to the internet.
  • A hug.


    10.06.2015 / 17:30

    In my point of view, this is the best way to work on the Web, since most of the other working models carry HTML from the server pro client and that does not make much sense. This way you have a performance gain, only passing the necessary data.

    Working this way you can take advantage of your front code and package it with phonegap, so create web apps without having to re-program.

    For the sake of SEO as Afonso has put there are tools or ways of working that help you in this. For example if you use Angularjs which is something that really complicates SEO, you can use Prerender ( link ), which helps you in SEO.

    / p>

    I do not particularly see any cons in working this way.

    09.06.2015 / 21:14