Take the 2-minute tour ×

In the past few months, I recognized a big excitement about client-side scripting in web development. But while server-side technologies are mature, stable and well accepted by backend-developers, client-side technologies are immature (i.e. compared to big server-side framework) and disliked by many long-established developers. Nevertheless everyone is doing client-side development these days. I personally expect those big server-side frameworks to disappear in like 2-5 years, watching the current trend.

Why is that so? How could the new and "diffuse" client-side developing in HTML5/JS possibly be superior to big and well thought server-side solutions?

share|improve this question
Do you have any sources to verify your assumptions? Javascript is almost as old as the internet itself, and I don't see server-side programming going anywhere anytime soon. –  tdammers Aug 24 '12 at 6:57
To clarify, my assumptions are limited to front-end. I see a shift towards the client-side, in UI logic, rendering and stuff like that. Of course server-side will never be gone, but reduced to an REST-api (or SOAP for that matter). –  Vain Fellowman Aug 24 '12 at 7:05
This shift comes and goes. Usually front-end development gets more popular once new cool technologies are introduced (Shockwave, Flash, JavaFX, Flex) or big new js frameworks are trying to "take over the world" (motools, jquery, etc.) –  Andrzej Bobak Aug 24 '12 at 7:27
@VainFellowman: You really don't want to use SOAP in client-side script. There is way too much overhead, parsing it is a pain, and you don't win much because Javascript with its dynamic typing discipline won't be able to make much use of SOAP's type information anyway. –  tdammers Aug 24 '12 at 7:51
@tdammers I don't want, really I don't. I don't see any point in using SOAP over HTTP. REST is suitable for nearly everything. –  Vain Fellowman Aug 24 '12 at 7:56
show 3 more comments

8 Answers

up vote 6 down vote accepted

This is true:

Rush to client-side in web development

But it is not confined to client-side, it is a full stack movement.

I know this may be surprising. Please, hear me out.


First of all, both are well thought out.

Secondly, Because it is better.

Good question.

But "better" is subjective, so the answer to your question is, what specifically is better?

Re-visit the question:

How could "diffuse" client-side developing in HTML5/JS possibly be superior to big server-side solutions?

Because small is nimble.
And big is clunky.

It is flexibility.

Doesn't seem like a big deal. Does it? Flexibility.

However, flexibility underlies everything. One improvement in flexibility - improves everything.

Maintainability. Extensibility. Scalability. Modularity. Usability. UX.

And it is faster to implement. This is the reality. Faster and Better.

This is why Windows 8 made JS a first-class citizen.

HTML5 - JS, is not a fad and it will not go away. We are only seeing the seeds of a technology that will grow to provide computing content and interaction behavior to tablets. Tablets.

Smart phones were the fastest mass-media adoption since the TV in the 1950's. Now, not only do we have smartphones - we have Tablets.

Already in development at Mozilla and Windows the OS that will run on future devices in their markets -> HTML/JS.

Many solutions and innovations remain.

A full stack of JS is emerging, based on flexibility.

I hope that helps.

share|improve this answer
Great answer! But server-side frameworks promise the same benefits, don't they? –  Vain Fellowman Aug 25 '12 at 7:24
Yes Sir, server-side frameworks promise the same benefits, yes. What needs to be known is that there are additional benefits, found unexpectedly, in emerging technology. It is at the lowest level (c) in the io. The threads wait. In JS it has a callback. It does not wait. So there is an io optimization at the lowest level. This realization is now, quietly, adopted in a large way by Microsoft. Which is why their OS is JS. Final point, this yields optimization and meta optimizations - at all levels. Because the language is flexible. A simple-invisible thing. Not known. Hope that helps. –  ClintNash Aug 26 '12 at 0:12
I chose to accept this answer, because it is the most complete one. All the others have good points, but this is the most conclusive. Thanks everyone! –  Vain Fellowman Aug 27 '12 at 6:10
add comment

Server side will always be around. You can't sit on client-side for everything. For example, you wont want to use a Backbone.js MVC design for your micro-controller sending you parameters in real time from a production floor overhead crane.

Don't believe the hype.

share|improve this answer
Tell me. Is JS in Windows 8, hype? -1. I agree with first point, but your second point on hype, needs clarification. –  ClintNash Aug 30 '12 at 17:15
JS isn't exclusive to the client-side and hasn't been for a while. –  Erik Reppen Apr 18 '13 at 21:59
@ClintNash ya, actually. Ms enabled j's to build win8 apps to increase the potential number of developers for their platform. Its a response to people choosing to learn those technologies over desktop technologies. But as a rev that already knows c#/wpf, I see no reason to build a win8 app with html/js. –  Andy Jan 24 at 2:42
@ErikReppen this is true, but js alone doesn't cut it on the server, you need a framework to build in. Frankly the desire to use script on the server baffles me. We did that already, it was classic ASP, and I don't really have a desire to repeat that experience. –  Andy Jan 24 at 2:45
@Andy On classic ASP (web forms in particular) you will find no end of agreement with any JS dev whose had the misfortune to have a run-in with those tools that we definitely don't want to go back there again. But that's yesterdecade's least-fondly-remembered tag-based server-side scripting tool and probably the most vehemently despised thin-client solution that ever saw any level of popularity. Comparing that to something like Python and now JS on the server-side is bordering on telling people to get a horse. –  Erik Reppen Jan 28 at 2:58
show 2 more comments

This story has always had two sides to it; both server-side and client-side code have their pros and cons.

Advantages of client side scripting include:

  • Can be made more responsive, extensive changes are possible without server round-trips.
  • Code runs on the client, reducing resource usage on the server.
  • Separation between logic and presentation becomes physical.
  • Sometimes easier to load-balance, especially if per-request authentication is used.

But server-side script has a lot of advantages too:

  • You control the machine the code runs on.
  • Pretty much anything is possible - if your server can do it, so can your script.
  • Users cannot modify your script before running it.
  • Users cannot use script blockers to prevent your script from running.
  • Users cannot see what your script does, they can only observe the output.
  • The code will work reliably with every client you can imagine, including screen readers, textual web browsers, search engine spiders, scrapers, accumulators, IRC bots, super-low-end machines, scriptblocked browsers, you name it.
  • User plugins are less likely to break.

For highly dynamic web applications, the client-centric approach has always been a popular choice, because it's the only way to provide a decent responsive desktop-like user experience: without client-side scripting, every one of the user's actions requires a round-trip, which means at least half a second delay, typically more. But for an informational site that is basically just a bunch of static pages served from a database (say, wikipedia), the advantage is marginal, while the benefits of server-side scripting are still overwhelming.

The observed hype comes from a combination of two recent developments:

  1. HTML5 and its corona of related technologies. It took way too long, but now we finally have a standard that contains everything you need to make those dynamic desktop-like web applications without piling up hacks, and mainstream browsers that implement them properly.
  2. Available processing power. Today's commodity desktop PC's are just as powerful as an entry-level web server, customer-grade cellphones are practically 2005's desktop computers, and modern javascript implementations are efficient enough to tilt the performance balance: by now, client-side resources are cheaper than server resources.

In fact, nothing has changed in terms of what the server-centric and client-centric approaches are good at; what has changed is that client-centric is now easier and cheaper to do and performs better than a few years ago, making it a viable choice for a lot more applications than it used to be.

share|improve this answer
hard truths... +1. –  ClintNash Aug 25 '12 at 6:05
add comment

I've made the switch in 2009 from a server-side PHP framework to a client-side ExtJS solution tied to server-side web services.

Reasons for the migration for me were:

  1. Better security by reducing the amount of endpoints and code on the server.
    By moving to web services you validate input at the web service boundary and have more exact control over your server's I/O. There is no server-side UI layer to muddle up your security architecture.
  2. Improved performance because of fewer server roundtrips
    The architecture changes so data fetches can happen less often and data can be cached locally with the UI rendering not requiring a roundtrip at all. Roundtrips are what kill web app performance.
  3. Improved performance because of cacheability of UI
    The UI layer can be hosted on a CDN completely. I've even built offline web apps by shoving the UI code into HTML5 app cache.
  4. Higher fidelity of UI (rich client-side controls)
  5. 3rd party developers can use the same API as my own front-end is using, and I can easily reuse API's across modules if they share features.
    This means less development, QA, documentation, ...
  6. I like programming in JavaScript better than PHP, Python or Java

But, make no mistake, what's happening now is a hype. It will blow over and many web apps will use a server-side UI architecture again.

share|improve this answer
What, hype? -1 Good luck with that when Windows 8 makes JS a first-class citizen. Yes, server-side UI architecture written in node.js maybe. We need to learn it because it is non-blocking. –  ClintNash Aug 25 '12 at 6:07
I don't think we'll be returning to thick-client solutions any time soon. But if I were saddled with ExtJS for any problem that got more complicated than pooping out pre-fab web UI (i.e. all problems regardless of the original plan), I could see why the alternative might seem less than ideal. –  Erik Reppen Feb 6 at 16:24
add comment

Another factor which is driving enthusiasm for client-side solutions is the growth of mobile apps. If you make a website heavily based on client-side JavaScript and AJAX, and also build native iOS and Android apps, there's a good chance that all three can use the same REST services to do all of their data to'ing and fro'ing.

share|improve this answer
Well said... +1. –  ClintNash Aug 25 '12 at 6:03
Very good point indeed. –  Vain Fellowman Aug 27 '12 at 6:09
add comment

First of all, the user doesn't see (and sometimes even doesn't care) what is no the server. No matter how well the server-side code is written, the users won't appreciate the application if the client part isn't done well. Sometimes even the nice UI is more important than the functionality.

A big and powerful server hosting is quite expensive. It is much cheaper to implement some of the logic (except validation) on the client-side. So you could use a smaller (therefore, cheaper) server hosting, since it would not be loaded that much.

These are the reason that, despite the instability, client-side technologies are gaining more popularity. Besides, JS and HTML/CSS are supported by (almost) all modern browsers.

These two parts of applications cannot exist separately. And the Internet doesn't seem to be leaving anywhere in the near future.
I don't think that big server-side frameworks are likely to disappear either. There will always be companies that can afford them, and will use their significant advantages.

share|improve this answer
add comment

Client-side web development is strongly coupled with web browsers and changes in them over time. The solution you provide now may not work in a couple of months due to significant changes in the page rendering engines of web browsers. Some browsers are/were incompatible with standards and therefore required even more extra effort from the developers just to achieve expected result.

There are some solutions trying to fix this issue. For example if you use jquery you get assured your script will work on the browsers supported by this particular jquery library. But it's only up to its authors to provide you compatibility with some/most/all the browsers. The question is which team will support you better. Will it be motools team, jquery team, other team? If they don't provide support to a particular web browser, your project may not work in that browser.

The excitement you seem to have has been around for a long time. I saw it when Shockwave and its successor Flash were introduced, there was a "big comeback" of rich user interfaces once complex js libraries were shipped, first with motools, then with jquery (I started using them in this order). There was Flex and JavaFX. But none of them can get a big share in the market. Some require plugins which in time often expose end user to security vulnerabilities, others may not work on client side due to some custom settings (e.g. JavaScript disabled in clients' browser).

On the other side, server-side solution is usually written only once. You don't need to worry that everything will fail and will have to be rewritten once new Firefox/Chrome/IE/Opera gets shipped. You don't also need to worry that client will try to tamper your app and/or corrupt the data.

share|improve this answer
Isn't that pure imagination? You will possibly have to change your server-side stuff when clients change, as you wont get round generating HTML/JS/CSS at some point. –  Vain Fellowman Aug 24 '12 at 7:07
One more thing, 'Client-side web development is strongly coupled with web browsers' - Web-technologies are official standards, as long as you stick with it you are implementing a standard, not coupling your application to a browser. While not too long ago this was not really true, it seems to be at the moment. –  Vain Fellowman Aug 24 '12 at 7:12
First of all read how some browsers just don't follow the standards (Internet Explorer for example). SOme things have changed over time, but even with IE7 I had horrible problems due to its own way of interpreting what I wrote. Also read a few articles about cross-browser compatibilities. This issue would not exist if every web browser vendor would follow the standards. Second of all if the data set changes, you have to change your business logic, that's obvious.But when new IE gets shipped and you have to rewrite around 30% of code just to make the code work on new browser - something's wrong –  Andrzej Bobak Aug 24 '12 at 7:16
Of course I know how painful it is and was to make everything work in every browser. But this work has to be done regardless server- or client-side (as you have to use a browser in the end anyway). I certainly agree on your second point. However, I don't see 30% to be rewritten. Some alterations possibly are needed, but I doubt it is as bad as in the old days. On the other hand you have to redo everything based on the service layer, if you want to replace your server-side stack. So you are VERY tightly coupled to your server side implementation. Possibly from the top of the UI to the model. –  Vain Fellowman Aug 24 '12 at 7:43
add comment

Absolutely agree with your sentiments. I also believe that beyond what you're saying we're going to see a dramatic drop in REST and massive upsurge in websockets for the main way we see sites communicate back to their servers. Vert.x, Node.js etc.. the entire server side, as well as client side, is moving to event driven programming. Java EE, PHP, Rails, etc.. they all need to adapt or they'll lose very quickly.

share|improve this answer
Without an explanation, this answer may become useless in case if someone else posts a differing opinion. For example, if someone posts a claim like "we'll not going to see a dramatic drop in REST and massive upsurge in websockets", how would this answer help reader to pick of these differing opinions? Consider editing it into a better shape –  gnat Apr 17 '13 at 16:12
add comment

Your Answer


