06 Jun 2020 - tsp
Last update 05 Jul 2020
Note: This is an opinion article on the future of web development. Currently there is a trend about building more and more logic into the client - even for simple tasks. That trend has been there previously and it has been a bad idea back then. This article tried to present a few arguments why I don’t think that this is or should be the future of the web.
As usual this article might be extended in case of more ideas coming to my mind or getting external feedback.
Just as a short summary as not everyone will reach the end of this article - the main features that the web offers in my opinion are:
But first let’s look at some history of computing and the web.
Basically first it all started before the web with having some big mainframe computers and a number of remote dumb terminals. The terminals just had been capable of displaying or printing out data, all computations have been made at the mainframe centrally. This has been done that way since computational power and storage have been pretty expensive and took up way much more room than one can imagine today. A hard-disk that could store an megabyte of data filled the space an refrigerator did today and a computer with the calculation power of and today’s smartwatch would have filled a whole building, required massive electric and cooling infrastructure and planning and was error-prone to a huge set of errors starting from being interrupted by static electricity up to bugs crawling into the machine - which they liked because of the higher temperature - and causing shorts inside the circuits. Funnily the word bug naming an error originates exactly from this behavior.
Note that the Internet was already in existence at that time - the internet started at 1st January 1983 with the adoption of TCP/IP for ARPANET. All of the core features that are now holding the Internet together have been developed back then - the core features of the network have been it’s decentrality and robustness as well as easy expansion. Features that are in place still of today even if there is every few years someone who proposes to exchange that infrastructure for a centralized “modern” approach which fortunately never happens.
So back in the 1970 to 1980 we had a scenario that one could describe as having a smart server and dumb clients.
Then the time of personal computers started in the 1980. Computational power and storage became more cheap and more compact. Computers moved into the households - at the beginning they’ve been a nice toy for geeks but starting with the x86 architecture - that we still use today - and especially the 80386 in the year 1985 the personal computer gained way more computational power and an major 32 bit computational environment. On the other hand communication over long distances was rather expensive and slow - since the 80s there existed dial up network connections with speeds of about 40 kBit per second - so that’s about a factor 1000 to 10000 slower than the internet connections used by many people today. The first commercial dial-up connections started in the early 1990’s and people started to build the web on top of the Internet during that time.
The web started to be a simple idea of being a global information medium on which people are capable of hosting their HTML documents that provide easy and standardized, human readable markup that can be rendered by a browser that provide metadata and link between each other. The concept goes back to the 1946 but was - in it’s today’s form - proposed 1989 by Tim Berners-Lee who also implemented the first webserver speaking HTTP, the specification for the HTML markup language and the first browser which also supported editing directly inside the browser in 1990 at CERN. In 1991 the server went online and was reachable for everyone on the web. Note that the first webbrowser supported a feature that most of the time is hacked into today’s webpages by using a huge bunch of server-side and client side code - it allowed direct editing of webpages. You could simply point your cursor somewhere in the webpage, edit it’s content like you’re editing in a word processor and then - if you had the FTP permissions - upload the document via either FTP or an HTTP PUT request to the webserver (HTTP PUT being a supported method in modern HTTP even if still not widely used or sometimes used in a different way to upload information to backend APIs in REST patterns).
Webpages have been rather simple and just have been rendered by the browser. So they contained just some dumb markup. Servers have been rather dumb and only delivered the data. So the web has been a little less interactive than one would imagine today. Applications ran as native code on the client side (like most programs still do today). During the same time stuff like transferring files using FTP and discussions in Usenet using NNTP have still been the way to be interactive on the web.
So back in the 1990’s we had a scenario that one could describe as having a dumb only file-serving server and smarter clients (but nearly no interactivity on the web; running local applications).
The main advantages of the web that one can still have today have been:
Soon after the emergence of the Windows operating system and ActiveX in 1996 the idea emerged to host ActiveX components inside the browser - namely inside Internet Explorer. Note that ActiveX is an API that has been built for componization of applications - the basic idea back that still lives today in many popular office suites was that a document can be composed of components from different applications like for example the ability to embed a spreadsheet into a word processor without the word processing having any knowledge about spreadsheets. This has been done by launching an spreadsheet processing component in the background - which is the ActiveX/OLE component and rendering it’s result inside the word processor who only knows that it has to launch a component of a given type. The same idea expanded to the web - including the ability to download components. This allowed on to download whole applications into the browser, support interactive forms and database access and animations. Other technologies that emerged at a similar time had been Java applets, Flash animations and applications and some other browser addons.
Logic moved to the browser with all it’s side effects: Not all browsers supported this rather complex logic, one had to install extensions that have been just available for some platforms so the portability of the web got lost. On the other hand most platforms had - because of their complexity - massive security problems so malware targeting users machines by this mechanisms emerged. The higher demand on calculation power as well as memory on client machines did the rest and so these technologies did not really survive long outside of some specific bubbles like flash games or some Java applet based remote interfaces for machines or telephony exchanges.
To counter that server side scripting and programming emerged. First there has been CGI that simply
instructed an webserver to execute an arbitrary binary or script in case a web request has been
made to a specific address - so the webserver got something like the
inetd daemon that
just launched applications on demand, passed request information and passed returned information
from the application towards the browser, wrapping it inside HTML. The most accessible way
when using CGI back then for the average user has been to use Perl scripts - which was and still is
somewhat a hassle to program with even if there are really potent and powerful string functions
supported compared with many other languages. Then PHP emerged. This language simply looked like
a hack but it allowed mixing HTML markup and code inside the same file which made thinking about
and building pages much easier. PHP has been the language of choice for every hobbyist web
developer who wanted to add interactivity on his site, later on paired with the MySQL database
system. Interaction with webpages followed a strict request-response pattern normally using
either links for non state-changing GET requests as well as forms that could pass selected
options and content of text fields and areas to the server site using potentially state changing
POST requests. After every action triggered by the browser data got sent to the server,
the server processed the request and returned new information towards the client.
If one for example would’ve implemented a simple solver for linear equations one would provide a nice input form for the user. After the user has filled the form he’d transmit the form to the server. The server then would perform input validation - in case of an error he’d return a error message to the user and potentially allow correction of the input or he’d perform the calculation and return the result. Each and every request of course would require a complete page reload which is not much of a problem for simple page designs but in case there are some complex layouts that was still somewhat feeling clumsy for some users - especially on slow connections.
One had again a smart server - doing computations - and mostly dumb client - doing only the display - situation as back in mainframe times. On the other hand the main advantage was that one also had the server as a gatekeeper into internal databases and internal state so this is also (still) the area in which one is validating user input, managing most of the access permissions, etc.
Having a smart client and a rather dumb or mixed server again, but relying on a rather error less and high bandwidth internet connection since one loads the application and data over the network on demand.
So a short summary to show the effect I’ve always been fascinated with:
Now what’s the problem I see with this approach?
Funnily many applications do not even correctly detect all features they require but simply fail in some unpredicted way in case something is missing or in case some API has evolved.
When loading multi megabytes of JS libraries this might be a huge problem over high latency and low bandwidth links - it takes time to download all resources associated with an JS application, it takes time to interpret and compile the code, then it takes time to load the data asynchronously that should be displayed to a user. And on every asynchronous load a high loss link might fail and trigger a retry or load failure. Loading times are - in contrast to the expectation - for the initial load normally way higher than for plain HTML and server side logic solutions.
Just beware that any single load or request may fail and might need a retry. And that every single load over a low bandwidth connection takes much time.
What does it mean to distribute your backends onto multiple different service providers? It means that you:
You have to perform access control on each backend service. Basically this is an approach that I somewhat like since I also try to perform access control additionally using the users identity at all backend services that I call out from my webservers. But on the other hand you loose this additional gate keeping point that can do at least some input parameter validation and will normally only produce internal specific requests - although your services should be hardened of course.
Of course there is an advance in technology that one currently sees such as more major languages such as TypeScript. But on the other hand native and server side application development offers just a huge bunch of major tools. This starts with static analysis, compile time error detection, being capable of doing intensive unit tests, etc. As I’ve written before there are some advances in languages such as TypeScript and having automated testing tools such as Selenium available - but it’ll be a long road till they reach the maturity level of existing tools for server side languages such as Java and even PHP.
This of course leads to less error-resistant code being in existence - and since there is this idea of fast changing web the error rate within web applications is just larger than in most other areas. This combined with the previously mentioned inconsistent environments makes developing client based applications way more error prone and hard to debug than any other environment.
In my opinion each and every website whose main objective is to present information just has to work without any scripting at all. If the main objective is to substitute and desktop application on the other hand the required scripting is of course alright. But this is not the case for a simple database frontend or for example a reporting application in my opinion. This has nothing to do with a modern or antique approach - it has something to do with keeping up the most basic properties of the web:
Please again keep in mind that this is an opinion based article and everyone might have a different one.
This article is tagged:
Dipl.-Ing. Thomas Spielauer, Wien (firstname.lastname@example.org)
This webpage is also available via TOR at http://rh6v563nt2dnxd5h2vhhqkudmyvjaevgiv77c62xflas52d5omtkxuid.onion/