WordPress.com: Welcome to the Club!
Server-Side Application-Rendering is Dead on All Platforms
We Microsofties used to believe that we're great because we have this cool server-side technology called ASP.net which takes care of HTML rendering for us. We knew we're better than PHP or Java Server Pages. We created cool server-side applications which merged database records with html, handled clicks and view-changes and pages and more. Our system even had really awesome server side controls. This led to the development of many awesome server-side standalone components like charts-tools, login-dialogs and more. We were happy and fairly efficient.
Then the world changed, giving us AJAX, mobile devices cloud-services and complexity. Our customers didn't want to wait for page reloads, they wanted a feeling which "just worked" on the page itself at decreasing cost. They didn't want to think in pages any more, they just wanted it to "flow". That's when server-side model faltered - for asp.net but also for php, ruby, etc. All were badly equipped for it. Some systems were less bad than others - interestingly the unsophisticated systems were better because they didn't abstract so much. But they too just delay the inevitable, namely: the demise of Server Generated Uis.
The Demise of Server Generated User Interfaces
Remember Telnet-style applications in which the server generated the UI and sent it across the wire? This "server generates the screen and sends it" was replaced by client-based software exchanging just the data with the server in the 90s. This is over now.
"Now server-based web UI rendering is going the way of Telnet applications...
...with big emphasis on going."
How does this work? Well basically every UI will be client-side rendered and switching between dialogs will mostly be handled by the JS stack. Separating the concerns we'll have:
- The JS-App which runs in the browser, contains all kinds of views and services and makes sure the UI looks and responds the way it should - and retrieves/saves data through a JSON-WebAPI
- A web server hosting the parts of the JS-App like the HTML-Views, the JS-code, some JS-libraries and assets like logos and CSS - in our case this is usually something in the /Portals/…/2sxc/Your-App-Name-Here/dist
- A web-api delivering data to the JS-App - very often also on the same web server (in our DNN case this is so) - for example in 2sxc it's in /Portals/…/2sxc/Your-App-Name-Here/api
Server Programming is Only 90% Dead
So to be fair - the server still needs a few developers - mainly for creating the engines in the background like the DNN system and database or the EAV-system (Entity-Attribute-Value) which powers 2sxc. It's also still needed for server-side work like image-resizing or for special data-retrieval. But compare it to common tasks we used to do like:
- Creating application UI - I'm 100% convinced that it's over
- Creating forms for user input - just as convinced - 100% it's over
- Document management - the storage-component still needs some code, UI will be 100% JS
- Content-Page rendering (the user-view of a web site) - not yet over, but two trends are killing it as of now - especially since Google can now index content created in JS on the client (I'll write more about that later)
- Security relevant operations - yes, this still needs the server
Want to know more?
I'll write a bit more about this in the next few days, till then you may want to check out my blogs about
Love from Switzerland (yep, I'm back :)