Devs won’t need to optimize their apps
The benefits of Abstraction
English version / Version Française ici
In this article, I’ll explain why devs won’t need to optimize their apps. It is related to the fact web development will evolve to become simpler, using Abstraction. I’ll first compare cars and dev tools evolutions, explain why I think we went the wrong way, and propose a way to solve modern development problems reconsidering devs’ roles and source code structure. I’ll then talk about a new way to use modern frameworks. I hope you’ll get my point.
Let’s compare cars and dev tools evolutions
Cars Evolution
Cars have evolved. They became faster, more secure, more efficient, more ecologic. We can say they’ve been optimized. Yet, has their USE changed ?
No, or not much. A 2020 driver more or less drives like a 1940 driver.
The driver doesn’t need to know HOW it is possible to get more speed, more security, more efficiency, or to be more ecologic. Its car deals with it, because a team of specialists worked on these matters and optimized it. There is no need for the driver to understand how it works to gain those benefits.
Dev tools Evolution
Dev tools too have evolved. They craft apps that are faster, more secure, less heavy, more reliable, responsive, etc. We can say they’ve been optimized as well. Yet has the USE of dev tools and languages changed ?
Drastically. A front-end dev in 2000 just needed to master HTML and CSS. He/she didn’t need to operate any framework, to set-up a NodeJS environment, to configure webpack, to understand what are promises, immutables, observables, design patterns, API calls, event delegation, hoisting, or to make TDD.
In 2020, a front-end dev has to master these tools and concepts, otherwise he/she won’t develop with the latest trendy techs and will be considered as someone who creates sub-optimized applications.
We went the wrong way
Why is there such a difference between cars evolution vs dev tools evolution ?
Car Users
For what concerns cars, the user of the car is clearly identified (Mr. Everyone) and separated from the makers of the car (engineers, mechanics, designers, etc.).
It is not conceivable to expect the user to know how its car works in order to operate it and to take advantage of its latests features and optimizations.
Dev Tools Users
For what concerns dev tools, both the users and the makers of those tools are developers.
Thus, it naturally feels much more conceivable to expect the users of these tools to understand dev tools magic, and to adopt the best coding practices that produce teamwork, maintainability, and optimization.
This is why currently, mastering a framework for example requires a long learning process: its implementation and its boilerplate must be demystified, the major CLI commands must be known, its organization and its design patterns must be clarified. It is also necessary to understand what are the main classes / functions used, and what key concepts it is necessary to adopt (the state must be immutable, the functions must be pure, etc.).
What’s wrong with modern dev
Asking dev tools users to understand ever-evolving concepts is just like expecting a car user to understand what kind of rubber its tire are made of to be safer, what frequencies its parking radars use, or how fuel injection works.
This should stay under the hood, even if the car user turns out to be an engineer and would be able to understand. Because taking the time needed to understand this incurs a cost in terms of efforts, training time, practice time, debugging time, and therefore in development cost.
Thus, it is underoptimized to expect the users of dev tools to acquire all this knowledge in order to benefit of better teamwork, maintainability and optimization.
Like the car makers, mastering those concepts should remain the job of a particular type of developer who specializes in making dev tools.
2 new types of devs
Instead of a distinction between front-end devs and back-end devs (which makes less sense anymore), I suggest you imagine a disctinction between dev. tools users and dev. tool designers.
Dev tools users
The dev. tools users are in charge of making the best websites and apps according to the specs/client needs. They know how to create relevant UI, describe their components, their features, and the interactions involved.
Dev tools designers
The dev. tool designers are specialists mastering the most optimized code structures, and the most relevant design patterns to solve a given problem. They are in charge of creating and upgrading dev tools to perform the same functions (event detection, interface modification, backup, authentication, etc.), but in an ever more efficient manner.
App vs Engine
It is possible to build apps that facilitate teamwork, are optimized and maintainable, without the requirement of mastering ever-increasing programming concepts and best practices. We can achieve this by separating app vs engine.
App
Dev. tool users should only take care of describing their apps (features, interactions, components, UI).
One way would be to describe apps visually. NoCode apps such as bubble.io propose to do so, and then translate each app visual description into a real app. Many devs think these are limited, but I suggest you try their 5min tutorials to see how much flexibility you can get.
Another way of doing this would be to use a single highly abstracted language that looks like writing specs, but in a much more programmatic (thus structured) way.
For example: There is the possibility of identifying the user via [email / pass / fingerprint / eye / etc.] materialized by [a login box with 2 fields / a device / etc.]. This box will use [db records / file records / etc.]. If successful, we will [access a page / add a database log / send an e-mail / etc.].
This language would be written in a single development tool, which would be configured to use an optimization engine among others. For the functionality of identifiying the user, each engine would offer many options for what concerns, for example, inputs [email / pass / borrows / retina / etc.], display [a login box of 2 fields / a device / etc.], relations [records in database / records in file / etc.], or output actions [access a page / add a log in database / send an e-mail / etc.].
Engine
Dev. Tool designers would actually work on the engines. They would be in charge of translating app descriptions into optimized, well structured, well tested, bug-free code. Once on a while there would be an update of an engine, for ever-better performances. Each update would not break anything because engines would be totally independant from app descriptions.
To get an idea of how it would work, you may think about what happened with PHP, since its core has been refactored many times. PHP7 is for example way faster than its predecessors, but as a PHP dev you don’t need to understand or care about what have changed internally. The new version allows for better perfs, even if you stick to the same app code. That’s all you need to know.
You may also think about relational databases, where the app / engine separation already exists as well. MyISAM, or InnoDB engines offer differences while being linked to the same SQL language.
Frameworks could become engines
Most framework are a result of quality work, given the numerous specialists involved in making them. Therefore, not using those tools would be a waste, and yet I believe relying on dev tool users to master so many concepts in order to operate those frameworks is underoptimized.
When you first read about a new framework on its official website, you soon come accross the Why this framework section. Most frameworks emphasize their low weight, reactivity, etc. While these features are certainly relevant for app engines, frameworks lack ease of use (even if some claim to be simple) because they are too low-level, which I believe don’t make them good candidates as app description tools.
Since we should separate app description tools from engines, we can imagine app description code could scaffold apps in different flavors (or frameworks). The same source code could create a React, Angular, Ember, or Vue app. Or it could generate a Laravel or Ruby app. All frameworks would become interchangeable engines as their code would be generated based on the dev choice.
This concept is close to hybrid phone apps. For example, PhoneGap or Ionic are capable, with almost the same base code, to generate Android or iOs apps.
Wrapping up
TRIZ laws of Evolution explain that every systems tends to an ideal, which means less costs. Pattern number five also states that systems increase in complexity and then get simplified.
App developement has already increased in complexity. Now it is time to simplify. What I suggest in this article is a response to this need of simplicity.
If developer roles get to be redefined, if apps get separated from their engines, and if we use a highly abstracted language describing apps, we obtain more efficiency.
And for every new tool / framework update, there would be no more learning costs. Just a pop-up in the dev tool.
With a button : [update engine].