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.
Background
Web development is all about communication. In this case, communication between two (2) parties, over the HTTP protocol:
- The Server - This party is responsible for serving pages.
- The Client - This party requests pages from the Server, and displays them to the user. In most cases, the client is a web browser.
- The User - The user uses the Client in order to surf the web, fill in forms, watch videos online, etc.
Each side's programming, refers to code which runs at the specific machine, the server's or the client's.
Basic Example
- The User opens his web browser (the Client).
- The User browses to http://google.com.
- The Client (on the behalf of the User), sends a request to http://google.com (the Server), for their home page.
- The Server then acknowledges the request, and replies the client with some meta-data (called headers), followed by the page's source.
- The Client then receives the page's source, and renders it into a human viewable website.
- The User types Stack Overflow into the search bar, and presses Enter
- The Client submits that data to the Server.
- The Server processes that data, and replies with a page matching the search results.
- The Client, once again, renders that page for the User to view.
Programming
Server-side Programming
Server-side programming, is the general name for the kinds of programs which are run on the Server.
Uses
- Process user input.
- Compiles pages.
- Structure web applications.
- Interact with permanent storage (SQL, files).
Example Languages
- PHP
- Python
- ASP.Net in C#, C++, or Visual Basic.
- Nearly any language (C++, C#, Java). These were not designed specifically for the task, but are now often used for application-level web services.
Client-side programming
Much like the server-side, Client-side programming is the name for all of the programs which are run on the Client.
Uses
- Make interactive webpages.
- Make stuff happen dynamically on the web page.
- Interact with temporary storage, and local storage (Cookies, localStorage).
- Send requests to the server, and retrieve data from it.
- Provide a remote service for client-side applications, such as software registration, content delivery, or remote multi-player gaming.
Example languages
- JavaScript (primarily)
- HTML*
- CSS*
- Any language running on a client device that interacts with a remote service is a client-side language.
*HTML and CSS aren't really "programming languages" per-se. They are markup syntax by which the Client renders the page for the User.
Best Answer
I had a similar problem where we needed to display information about cars and other products that was structured like a tree (car brand -> model -> type -> build year). Even if the browser would hold that much data (not sure about that) it would take forever to download it.
What I did: Load the first level and load other levels via Ajax only when actually needed for display. Since we needed to display this as a menu and show the next level very fast on mouse over the possible results where cached on the server (if you need specific sorting this may become a problem).
Same goes for searching and sorting. Let the server do it and load the results. You won't sort over the whole structure in a tree view, but only on one level. Obviously this may be the most difficult part depending on how exactly your data is structured and what types of searching and sorting you want to do.
Also in a tree view people won't have open all nodes at once, this makes it bad to handle and you would need to scroll all the time. You could still load the first two levels if the amount of data allows it and then load level three if level two is opened for some item. So this can be handled as you need it.
Even if loading on demand would not work for you, you could still just load level one and after that when the document is loaded start some process in the background that loads the deeper levels one by one. This would most likely work faster than the user can scroll down.