What you're looking for is called Single Page Application (SPA). Start digging around about this concept.
At the end of the day, most SPA implementations render views entirely in the client-side and they switch from one view to other loading data as JSON and binding it also in the client-side.
Take a look at the home page of Angular UI Router and you'll get a good idea about what you need to make your first steps on SPA world.
OP said:
I beleve I understand the core concept of a spa, even if it's a little
bit --- what I don't really get is - how to display the correct
content when the href link is directly visited (instead of a click)
This is also done in the client side. When the SPA is first accessed it reads the path in the URL and opens up the right view with the desired state automatically. Imagine that the action that would get you to some view using a click handler can be also triggered programatically.
When I say automatically I mean that some JavaScript code must handle this scenario. Usually you use a SPA UI framework like Angular UI Router or any other one since they already handle this issue for you.
Answering to wrong Quentin concerns...
@Quentin said:
"When the SPA is first accessed it reads the path in the URL and opens
up the right view … When I say automatically I mean that some
JavaScript code must handle this scenario." — Don't do that. That
completely misses the point of using the history API which is that you
build a hybrid client-side/server-side app so that when JS fails it
still works, and the URLs work for search engines, etc. If you make
the whole thing depend on JS you might has well use hashbangs
- Not all SPA are SEO aware.
- Not all SPA are hybrid.
- Not all SPA have a public surface. The SPA can be entirely accessed using authentication and authorization. For example, does a 100% SPA private social network or an administration panel would be partially loaded from the server-side? Wrong!.
- Not all SPA are browser-oriented. No one should miss the point of a SPA when developing a mobile hybrid application using a SDK like Apache Cordova.
- If the server fails, it's fine that the client application continue working. Since the advent of local storage, Indexed DB and other HTML5-related APIs, and the chance to run an HTML5 app in offline mode, a SPA can still work with the server down and synchronize data or queue server actions until the server goes up again.
- This approach doesn't defeat the purpose of HTML5 History API. How it does? If the history is still there, the SPA can restore its state entirely in the client-side and request the missing data to the server if it's available!.
- Final point: how do you open up a SPA from the server side in the right state if it's not an hybrid SPA like you said? If you develop a true Web app, the server mightn't be required in all operations and if the server is required, I would double-check my 5th point.
- A true SPA/Web app defines that the server (i.e. a RESTful API) is a dependency rather than an integral part of the application. The application is just a mix of client-only operations plus server-side ones.
It seems like both @Quentin and who thought that my answer address the issue in the wrong way, while I believe that it's out of question that current and future HTML5 Web app development goes beyond just working with dynamic views that can be both server from the browser or server.
Let's put here a simple sample. If Adobe ports Photoshop to HTML5 (using canvas' 2D/3D rendering), and it requires the server for heavy graphic filter processing and storing files in the cloud, would you use the server to open up the last edited file or the client would access its client-side history using History API, local storage and/or IndexedDB to request the server the latest version of the file or maybe a saved draft?
For me SPA isn't just parallax scrolling or loading content in containers dynamically: it's the new era of Web apps.