I want to render my pages client-side to help keep the load off the server and keep down traffic. I understand that the first call to the server normally results in that the server must render the page requested and then sends that page to the user. When the user interacts with the page the javascript takes over the routing, which sends requests to the server for a specific view which then is updated via javascript on the client.
I was thinking if this approach exists or not and if it is viable.
Let's say i wish to go to the address:
www.example.com/about
Is there an approach which attaches the /about as an argument to the html page/javascript code (same that serves www.example.com/) from the server. When the dom is ready on the client it sends a request to the server for the /about data, which with the response updates the clients views. This would mean skipping the server side rendering completely.
Or am I crazy?
No, you're not crazy. This is the way that most single page application (SPA) frameworks, like AngularJS work.
For example, the way that I typically configure a webserver for AngularJS is to have the following routes:
/pub/<relative_file_path> just serves the static file specified by <relative_file_path>, such as all the JS, HTML partials and CSS./api/<whatever> is where all endpoints which the client accesses via AJAX liveindex.html, which is a static file that contains the whole page with references to the JS, CSS and markup.Thus when you go to www.example.com/about, you will get the index.html page, which tells the browser to download the JS for the whole application, which includes the client-side routing configuration. Once the application starts, it sees that the location is www.example.com/about, and says "I know about /about, I will go to that page!".
Of course, by "go to that page", I mean "fetch the partial HTML for that page, and fetch any data via AJAX". No visible page refresh/change happens.