I started to develop web applications not so long ago, and therefore there are a lot of unknown things in this field for me. My question concerns web development using the Java language. Assume that we need to develop a client-server application, where the client is a browser. As far as I know, there are at least two ways to communicate.

  1. An HTTP server work on the server side and a container for a Java application (back-end). The HTTP server redirects requests to another port, which is binded with the Java application. The Java application sends to the client pages with dynamic content from a database, for example, as a response to a concrete client's request. The application uses a template enginge for this. Timeleaf or Velocity, for example.

  2. An HTTP server sends only static files (HTML pages, CSS and Javascript files), and further a client starts to send asynchronious requests to the server using Javascript code. Requests are sent via HTTP/HTTPS in the JSON format (or XML). This approach uses REST principles. A server application written in Java takes these requests from a certain port, processes them and sends responses in the same manner. A page refreshes dynamically on the client side, without reloading.

Though I wrote about Java, these approaches are used with other programming languages, Python, for instance.

I was told that the first apprach is considered as bad in the Java community. But I haven't heard concrete arguments. I would like to know them.

Many thanks for your time and answers.

  • see What is the problem with “Pros and Cons”? (also, resource recommendations are off-topic per help center) – gnat Aug 2 '18 at 14:26
  • I edited the question. – Sergey Gatich Aug 2 '18 at 14:35
  • Is the information that you base the conclusion on that the first approach is considered bad, available on the Internet somewhere? If so, can you provide a link to it. – Bart van Ingen Schenau Aug 2 '18 at 14:58
  • #1 seems to be a description of the use of a reverse proxy such as Apache or NGINX. This is a pretty standard approach and doesn't really change the way your application behaves functionally. The Velocity project is basically abandoned and I would not advise using it for new applications. Perhaps that is what was considered 'bad' here. My understanding is that Freemarker is the offshoot of the Velocity project. – JimmyJames Aug 2 '18 at 15:22
  • @JimmyJames: It's not that complicated. See below. – Robert Harvey Aug 2 '18 at 15:26

The implementation details (i.e. the use of Java) you're describing in your question are less important than the architecture you're trying to describe, so let me simplify your descriptions a bit.

Here are the two approaches, in a nutshell:

  1. The web server sends web pages fully populated with data to the client. This approach is called server-side rendering.
  2. The web server sends an empty web page to the client, and the web browser requests data from the server and populates the web page with it. This approach is called client-side rendering.

Neither approach is "good" or "bad." The difference is in the degree of interactivity between the user and his device that each approach enables. The approach you choose (and ultimately the technologies you employ) will depend on your software project's specific requirements.

With server-side rendering, user interactivity is limited to page posts. Each time a user enters data into the web page, they must submit the page to the server in order for the application to proceed to the next step.

With client-side rendering, interactivity is expanded to include real-time interactions on the same page. A user can do partial data submissions, and the page can request data updates without asking for a brand new page. This approach makes web pages feel more like desktop applications, and supports the development of multiple client types (such as native mobile).

But not all web pages need this level of interactivity. If you're designing a configuration page for a router or other embedded device, for example, it is very unlikely that you will use client-side rendering. Nor does your application necessarily need the full rigor of an enterprise-grade infrastructure.

In the past, all of the complexity of building web application was concentrated on the server. But web applications have been evolving towards client-side rendering for years. Excessive complexity has always been a real problem in these kinds of applications, but there's some evidence that the development techniques are becoming more "standard," and that web applications are becoming both simpler and more powerful to develop. Things that used to be very complicated (like data binding and page styling) have become much more straightforward, because very good Javascript libraries are now available that can perform much of the heavy lifting.

In short, your choice will be based on suitability, not someone's vague notion of what they consider "good" or "bad."

  • +1 for nicely separating the core of the question from the specific technicalities. – Avner Shahar-Kashtan Aug 2 '18 at 18:00
  • Thanks, this is exactly what I tried to find out. The persons that told me these opinions work on enterprise projects, so this explains, why they think server-side rendering is a bad idea. – Sergey Gatich Aug 2 '18 at 20:22
  • If you don' mind, I have another particular question. I'm not trying to start a long dispute, and I'm not a native speaker, but as I understand, rendering means displaying or painting, am I right? Thus, can the one say that rendering is always proceeded on the client side (in a browser or a desktop application)? – Sergey Gatich Aug 2 '18 at 20:28
  • I think a hybrid approach would be best. Use server side for the bulk of things and AJAX for the little, interactive parts! This is how we do it in our company and it just werks! – Aphton Aug 2 '18 at 20:57
  • 1
    @SergeyGatich You're technically correct that “rendering” means “drawing”, but in the context of web development it has the more narrow meaning of “creating the HTML structure”. Rendering can mean filling in a textual HTML template (on the server or the client), or can mean manipulating the DOM of a loaded page (through JavaScript APIs on the client). Drawing the DOM to a screen is done by the layout engine and compositor which use CSS rules. – amon Aug 3 '18 at 8:18

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.