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.

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?

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.

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.

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.

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.

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.

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.

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.

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.