2

In the past few years, 'client-side' web applications have become popular. A common approach nowadays is to have the backend as thin as possible, mostly exposing an API for the client-side Javascript app to consume.

What I'm interested in is not the advantages of this approach, as this seems to be the preffered approach today and its pros have been discussed on this site.

I'm interested in the advantages of the more traditional, backend-based approach. Where the templating and routing of pages happens on the backend, and the frontend logic is thin.

Please note, that this question refers to standard 'CRUD' applications, not to specialized video-editing software or programs executing intense algorithms (this kind of computation obviously needs to happen on the backend).

I'm referring to the advantages of a backend architecture for your 'typical web app'.

Improve this question
4
  • recommended reading: Why do 'some examples' and 'list of things' questions get closed?
    – gnat
    Commented Nov 14, 2015 at 13:40
  • 4
    @gnat I don't think that this question falls under this category. It's clearly about advantages of "thick back-end, thin front-end" over "thick front-end, thin back-end" architecture.
    – scriptin
    Commented Nov 14, 2015 at 13:59
  • If you want to go client side you pretty much have to go javascript. That may be a pretty big disadvantage for some people. Server side gives you choice
    – Richard Tingle
    Commented Nov 14, 2015 at 23:04
  • 1
    Asking for "the advantages" of X is almost always a list question (@gnat probably should've linked the "pros and cons" post for this one). As the existing answers have already demonstrated, you end up with a list of example applications for which X is a good thing, and then everyone has to debate in the comments whether those examples are valid because the original question wasn't sufficiently well-defined to make it clear what would or wouldn't count.
    – Ixrec
    Commented Nov 15, 2015 at 13:22

2 Answers 2

Reset to default
1

The benefit appears every time you hit the constraint of the client-side execution. Consider three cases:

  • A video processing application. What would be the constraint? Right, the CPU and memory constraints of a browser running on a client machine. You'll rapidly notice that many actions are either practically impossible to run, or take hours instead of seconds.

  • Anything which uses gigabytes of data. A search over billions of records in the database could take milliseconds when done by the server. If done by the client, it will take seconds to hours, depending on the internet speed.

  • A smart algorithm that you want to hide from your competitors. Anyone can read JavaScript. By moving the logic to the server side, you make it difficult to impossible to reverse engineer.

Another benefit of having the logic on server-side is, of course, the fact that you can control exactly the run time environment. You can chose the operating system, the programming language, even the underlying hardware. In client-side scripting world, you don't have this freedom. Your code can end up running on an ancient PC with Windows XP and IE7, or a tablet, or a smartphone, or a device used by a person with vision disability using text-to-speech and speech-to-text interfaces.

Improve this answer
3
  • 1
    2. Strawman. No application transfer gigabytes of data to search on client side. Thin backend can include this functionality as well.
    – Ginden
    Commented Nov 14, 2015 at 18:23
  • 3. CRUD applications typically don't use any smart algorithms. It applies to video processing too.
    – Ginden
    Commented Nov 14, 2015 at 18:28
  • @Ginden: that is exactly my point. Is Google Search a client-side application? Well, it does some stuff on client side, but everything of actual interest happens on the servers.
    – Arseni Mourzenko
    Commented Nov 14, 2015 at 19:39
1

There are tasks which can only be done on a server, and some which can only be done on a client. In other cases, there are some reasonably clear advantages of implementing something on back-end over front-end:

  • Better caching options, e.g. Varnish and similar technologies
  • Often, speed - as benchmarks show, typical Java/C# code is still faster than JavaScript. However, SPA wins in cases when a bottleneck is the networking vs calculations
  • Simpler development for one platform vs. developing for 8+ different browsers, and hence simpler maintenance
  • "Hiding logic" and cheating prevention. For example, if you're building an online game, some parts you may want to be done on a server to prevent cheating/hacking by modifying a game logic on a client. Also, if you want to hide some algorithm from your users, you do the same
  • Often, lack of some features in browsers, or inefficiency of such features. For example, building a report on big amount of data using various data aggregation functions can be done efficiently in SQL, but not in JavaScript
Improve this answer

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