What do we still lack to develop web apps?
Two weeks ago I published a blog article thinking about what a web app actually is, or what it shall be. I’m deeply convinced that web apps shall not be developed like docs, and three-to-five programming languages are too much in a process where one language is more than enough.
Well. An obvious conclusion could be choosing one language, for instance JavaScript, and implementing app architecture like Model-View-Controller instead of a set of pages. Right? But, I think we have missed one important and fundamental thing in this approach.
TechTerms says: “Web apps have several advantages over desktop applications. Since they run inside web browsers, developers do not need to develop web apps for multiple platforms”. So, apps are developed for target platforms. What is a target platform? It consists of a hardware and an operating system, or OS. We can use different operating systems running on the same hardware, like Linux or Windows, or hardware specific systems like macOS. Anyway, all of them are an intermediate layer between a hardware and applications.
Matthew Sinclair gave a good definition for OS — “An operating system is more than just a set of software APIs for hardware. To create leverage for application programmers it needs to provide conceptual abstractions over the hardware that make programming easier.”
Can you imagine an app without OS? Do you remember early days of computers when apps were being developed in a machine code, or an assembler, specific for a target hardware where OS was very poor or missed at all? In most cases, programmers were forced to create their own implementations of such functions as memory management, storage control and input/output. For instance, great popularity of the game ‘Doom I’ was provided by an excellent built-in video library, which wasn’t a part of DOS operating system. Finally, Doom’s video library ceased to be a part of any operating system.
Modern operating systems consist of multiple inner abstract layers and provide the development tools with a lot of specific frameworks, foundation classes and libraries to help a programmer to be focused on application’s solution, instead of studying the particularities of a specific hardware. Actually, the development tools translate your code written in a high-level programming language to the OS, not to the specific hardware.
Shrek: Ogres are like onions.
Donkey: They stink?
Shrek: Yes. No.
Donkey: Oh, they make you cry.
Shrek: No.
Donkey: Oh, you leave em out in the sun,
they get all brown, start sproutin’ little white hairs.Shrek: No. Layers. Onions have layers. Ogres have layers.
Onions have layers. You get it? We both have layers.Donkey: Oh, you both have layers. Oh.
You know, not everybody like onions.
Imagine compiler translating sources written in a single high-level programming language to an executable web app (it’s easy, if you try). It is easy when we know exactly what a web app and a target web platform really are, especially a web platform.
TechTerms’s definition of a web app is not complete. It says nothing about servers. Really, web servers are not only a URL-addressable storage for web apps. They also run a part of a web app’s executable code and store web app’s data. It means that an ideal compiler shall produce a server-executable code as well, including support for interaction between a server and browser parts of the web app.
Ok. What shall a web platform be in this case? I guess that a web platform includes three components: a browser, a server and HTTP protocol. JavaScript, HTML and CSS ‘run’ on browser, PHP and a database supported by the server and HTTP protocol is interaction glue. What do you think, what parts of such platform could be considered as a ‘web hardware’ and ‘web OS’ respectively? I didn’t mean LG’s webOS, of course. In my opinion all the parts listed above are a ‘web hardware’.
HTTP is an only common independent part. Browsers and servers could be quite different and not fully compatible. It means that we need an additional abstraction layer between the browsers, servers and web apps. This layer is a missing fundamental thing that I mentioned before — an ‘operating system’ for web apps.
We develop our web apps absolutely the same way as we did it for old-fashioned computers without OS. We still write sources directly in executable machine code (JavaScript, HTML, CSS, PHP and SQL for web apps), we still think how to make our web apps compatible with different browsers and spend time inventing and re-inventing ‘useful’ libraries containing data how to implement CSS overscroll-behavior for Safari or Opera, and we still cannot move our apps from mobile and desktop platforms to web platform and vice versa, because it requires the same efforts as when you try to modify your Linux app to run directly on your notebook without Linux.
I think the reason why we have no clear unified high-level concept of a web app at the moment is a hazy understanding of what a target web platform is and what ‘web operating system’ we need to support the development process.
Conclusion: We have to build a ‘web operating system layer’ and make web apps closer to native apps before any development tools. It’s just what we try do here in AplextorLab. Aplextor is not just a yet-another-dev-tool for web apps. It’s exactly this missing layer.
