The future of the internet is not on the server. The fight around php vs. asp vs. mvc-on-the-server is suddenly irrelevant, because the future for online-systems is JavaScript-Based. What really got me excited is that WordPress.com just redid their entire system to also go this way. Since we just spent around 100 days refactoring 2sxc into this architecture, I will write a bit about this, beginning with some background why and hows…
WordPress.com: Welcome to the Club!
We strongly believe that the future of UI development is pure JavaScript - and paid a high price to pursue this vision (ca. 100 days of free work). So what really got me excited is to see that even WordPress.com has just done the same move and gone all JavaScript. Now just to be clear: I wouldn't want to use WordPress for anything that exceeds a common blog. But the plain fact that this very popular Platform has decided to use this architecture is another piece of proof that the server side is becoming obsolete. So for WordPress.com this means no more PHP for the UIs (replaced by WebAPIs mostly based on node.js).
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."
The Future is JavaScript-Apps on the Client + a Small Server Api
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:
- An HTML-page hosting the JavaScript app. This page will commonly be either static (like the admin-UI in 2sxc 8) or served by a CMS (like a typical 2sxc-app placed on a normal page on DNN).
- 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 :)