I propose to detail these 5 trends and see how they allow us to foresee dev evolution. As an example, I will then forecast the evolution of unit tests.
Ergonomic visualization
Ergonomic visualization = user-friendlyness
Linux is free, open-source, fast, and secure compared to Windows or OSX which yet are much more popular for regular users.
This is no coincidence. Windows and OSX are much more visually ergonomic, more user-friendly, and more compatible than Linux, whether used as a command line or as a GUI. Their well-thought-out graphical user interface simply makes them simpler to use, which is a real asset for a tech to be adopted, especially for regular users.
On the other hand, CLI requires most of the time a learning process, and/or a reference document, and is not intuitive. Yes, it is useful in some cases, even unavoidable for some operations that are much faster to do with a good command line than with UI. But I'm convinced that too often, CLI is not the right choice, and is a feature implementation that didn't go all the way: it lacks a graphical layer.
Ergonomic visualization = less errors
Furthermore, a graphical user interface avoids errors that could be made via code or via a command line. This is due to the fact UI can easily constrain the possible actions or options. This is seen, for example, in No or LowCode apps. In bubble.io, if we assign an action to a button, it looks like this:
Bubble.io
There is a drop-down list that allows you to choose the type of event to detect (click), and several others that allow you to choose the actions to be performed (identify, send an e-mail, redirect to reception). Not only is it intuitive, but these drop-down lists, unlike code or commands, prevent syntax errors, as well as calling inappropriate functions, or passing inconsistent params.
Ergonomic visualization = time saving
User-friendly interfaces also save time. They can even save time for devs, even though they could do without UI because they have the ability to learn CLI or languages.
Because that's not the point: we are here trying to find out what is the most efficient way to master an API starting from 0. If you are a shell master frameork CLI master, then I have no doubt you can do things quickly.
But you had to learn these commands, which represents a significant cost in terms of time. And when we talk about Code Ergonomics, we are trying to reduce this cost. It turns out an unknown API is much faster to master when it is visual than when it is operable by code or by a CLI.
Let's take the example of setting up a dev environment. Currently, you can use a first command line to clone a git project, or to start creating a starter project. Then you need to run another command to start importing modules. Then another one to serve the project, with in the meantime a possible modification of webpack or other bundler config to fit our requirements in terms of transpilation, linting, hot-reloading, etc... In codesandbox.io, all this is visual, and requires 3 clicks. Simply put, we save time.
Env. setup with codesandbox.io
Is it devs job to make efficient UIs?
It's not ideal, but when working on a solo project or in a small team that doesn't have a graphic designer or UX expert, devs have to design well thought-out interfaces.
All too often, however, they tend to neglect UI ergonomics, considering that it is not their responsibility and that their added value lies in the implementation of functionalities. There is an "inappropriate partition" between engineering and graphic design.
However, in the Renaissance, there was no partition between Science or Art. People tried to be complete, to master both. So I think devs would benefit from trying to create efficient and well thought Uis.
Leonardo Da Vinci : scientist, engineer, inventor, anatomist, painter, sculptor, architect, urban planner, botanist, musician, poet, philosopher and writer
Abstraction
Using a high-level language, and separating app description from its engine, allows us to benefit from the permanent evolution of patterns and syntaxes without having to train continuously: because apps remain optimized without having to be rewritten. This matter needs its own article which you can find here.
Unification
In TRIZ's laws of technical systems evolution, there are multiple trends. One of them concerns the merging of system components. Please refer to the "Using dissimilar Elements" or "Using Similar Elements" trends in this graph.
From Karen Gadd's excellent book Triz for Engineers on page 444
The many dev tools will unify to become an all-in-one programming environment, kind of like Flash years ago (although server-side was missing), Meteor, Unreal Engine, or Unity.
Unreal engine
This will merge the multiple tools that are currently used separately: bundler, module manager, versioning, transpiler, CLI, etc. Everything will be integrated into the code editor, most often in the form of options, parameters and menus.
Again, we can already see it in codesandbox.io as well as in visual studio code which integrates a terminal, a debug console, and all kinds of modules.
Visual Studio Code
The 6th TRIZ law of evolution - Transition to the supersystem, also specifies that a system will become part of its supersystem, i.e. its environment.
So the programming environment (system) will be integrated into the cloud (super-system). There will no longer be any local / remote separation. Everything will be online.
We already can see it with CodeSpaces from GitHub (still in beta version) which is a cloud IDE:
Codespaces
Automation
This is probably the most important point. Thanks to automation, most configs can be avoided.
No more env. config
Like codesandbox or thanks to the tree-shaking of parceljs, dev environments will be able to self-configure by analyzing projects source code and the dependencies.
No more versioning commands
Using the command line can be improved. Backups can be partially automated, similar to the incremental backups in Synology Cloud Backup or Apple's TimeMachine :
Apple Time Machine allows to browse the timeline on the right and find the past state of a project displayed through multiple overlay windows
On a side note, I'd like to specify that visually, versioning could be inspired by WordPress or Adobe Suite's history managers, but with the added capabilities of forking, merging and other subtleties of git. There is a lot of room for improvement, but in the meantime, tools such as Git Kraken or Git Tower offer somewhat improved UIs.
Git Kraken
No more cloud configuration or tedious deployments
Like softaculous, which allows to set up or clone a WordPress or other system project in one click, clouds could be automated.
Softaculous
WebHosts could technically detect app boilerplates and config files, deduce all dependencies, auto-load them and set them up. After all, we mentioned Parcel is already able to do this for dev environments.
In addition, easy deployment could be done via a single Deploy button in the IDE. Like in Codespaces.
Cloud services still have a lot of room for evolution, as they didn't adapt well to the new practices of front-end development. They should be automated, as this would provide a real service to developers, who are their typical users and customers. They would thus considerably improve their market share.
No more unit tests programming
Beyond the debate on the usefulness of unit testing, which we didn't have to deal with for decades while many applications were still of high-quality (thanks to user testing), we are still too low-level when we code them.
These tests could be partially automated as well. I will discuss this case in more detail in the last part of this article.
But above all: less, or not at all, code.
Apps could be described either through a high-level language or visually. Then this description could be translated by an interpretation engine.
Here we can also refer to No or Low-code platforms. The best example in my opinion is still bubble.io which is very flexible and not only limited to the creation of showcase websites as many might think. I invite you to try their 5min tutorials to get an idea of its flexibility.
This Description / Engine separation is the prerequisite for efficient automation. It can be found, for example, in DBMS, with SQL that can be combined with the MyISAM or InnoDB engines.
There is much to be said on this matter, which I approach along with Abstraction, in this article.
Delegation
Currently devs are taking care of almost everything: architecture, environment configuration, development, testing, debugging, versioning, server configuration, and online releases. How can they master everything? Is it possible to become a specialist in all those matters? Do we accept not to be specialized in anything? Or can we make changes to optimize this situation?
Devs tasks will be reduced: what can't be automated will be simplified. What can't be simplified will be left to specialists.
I'm particularly thinking about cloud management, which I mentioned earlier: if a webhost offers a real one-click deployment, adapted to the most common project architectures and framework, he will win a lot of market share.
Last but not least, within the dev. community itself, I think that a distinction between devs who make apps vs devs who make devtools will be necessary, in order for them to specialize and learn what is actually useful regarding their needs. I'd like to avoid repeating myself, so I invite you to read this article for more details.
Example: unit testing evolution
Let's try to see through this example how these 5 trends allow us to imagine the evolution of unit testing.
The problem
In addition to being boring, writing unit tests roughly doubles the time and therefore the cost of development.
Possibilities of evolution, based on the 5 principles
Tests would be integrated into the IDE, which would be able to self-test a project (unification of components and delegation of tests to the IDE) by pressing a button rather than by a CLI (abstraction, visualization).
The IDE would automatically test (automation), for each UI component, all possible events (a button would be clicked, double-clicked, hovered, while a form would be sent, reset, etc.). The reactions to those events would be analyzed and this would highlight any inconsistencies or conflicts in the application.
For example, the IDE might show that the same function is invoked several times but with arguments of different types, or that its return values are of different types.
The result would then be a list of these inconsistencies, display in an interface (visualization), which would ask us to decide on the input/output really expected. This would be similar to GitKraken when it asks us to decide on a merge conflict, but here, the choice would most often be made though simple drop-down lists.
Conflict resolution would thus automatically apply changes to the tests description files we currently create by hand.
2009, Berlin: Usain Bolt beat the 100m Mens World Record in 9.58 seconds. Please take a look at how simple it seemed for him:
2012, Beijing: Lang Lang plays La Campanella. It looks so simple for him it actually looks like he is playing around:
Despite the underlying complexity of these crafts, despite all the time and efforts that have been required to reach their top level, when you take a look at the way they do stuff, it actually looks simple.
Too often, we think that what looks simple is not optimized
Long before my first articles on Dev. Simplicity, I had many talks with devs who master current complex modern frameworks such as Angular or React, as well as their related environment tools.
Most of the time, they didn’t agree that development will and should become simple. To them, mastering tech is naturally complex and it should stay this way.
They were saying it is part of our job to keep learning stuff in order to keep up with modern tech evolutions. Because this is how apps can evolve and can keep being optimized.
Most of them didn’t feel the need for tools or frameworks to become simple. We should adapt. We should learn. Because as devs or as engineers we can.
Top-level code is simple code
Usain Bolt and Lang Lang reached the top-level of their fields.
When Usain Bolt runs, it looks simple, but it’s not. When Lang Lang plays, it looks simple, but it’s not. Under the hood, it has been very complex for them as they’ve been learning and training for thousands of hours.
It is possible to imagine simple, top-level dev tools, that would allow us to reach top-performance as well, by generating the most optimized apps. First-class tools that look simple, but which are not. Tools that we can operate in a simple way, but which are performant because of their underlying complexity.
You are not a bad developper for prefering simple, highly-abstracted and readable syntaxes and patterns, over overly-complex and mystified trendy syntaxes and patterns. Because if tools were well-thought, they could offer both simplicity and performance. It is technically possible.
And besides optimization, Simplicity means better readability, better maintainance, better evolutivity, better teamwork, less training time, and less overall development cost.
But it also leads to something more.
Something you’ll find in simple people’s way-of-being.
Something you’ll find in rare mathematical demonstrations.
Something you’ll find in programming, in science, in fashion, or in design.
It leads to Elegance.
As a web developer and trainer for the past 15 years, I have not been spared by the “Javascript Fatigue”. My search for a “cure” to this fatigue, drove me to think about programming absurdities, and what could be the ideal programming environment.
In this introductory article, I would like to talk about my conviction: development will become simpler. Thereafter, I will prepare a series of articles describing in detail the reasons for my opinion. This will hopefully give you a glimpse of what the next development environments, as well as web programming, will look like.
My opinion is inspired by TRIZ
Imagining the future is easier if you use a method. On several occasions, I will refer to TRIZ, a Soviet method that I have been inspired by, which allows us to solve innovation problems as well as to innovate by anticipating the evolution of technologies.
TRIZ has proven its worth: for example, Samsung has been using it for years and it allowed the company to register numerous patents. In addition, this method is taught in schools in South Korea, a country that is highly innovative.
The first thing to know, according to the Law of Evolution N°4 — Growth of Ideality, is that programming tools, like any system, will tend towards an ideal. The ideal, in the sense of TRIZ, is defined as follows:
A system is ideal if it offers maximum benefits, without cost, and without harms.
This simple equation therefore challenges a widely held belief among many developers that if today’s tools make it possible to create applications that are more secure, more reliable, more team-oriented, more scalable, and more responsive, they should definitely be used.
These are indeed many benefits brought by modern tools and frameworks. Except that the ideal is not reached for a simple reason:
Current tools and frameworks have a cost and cause some harms
Don’t you think so? Here is a non-exhaustive list:
confusion in the technical choices due to the multiplication of competing tools (frameworks, libraries, and tools/modules of the environments)
lack of apps durabilities, due to these uncertain technical choices, as well as the frequent changes in syntaxes, patterns, and best practices
need to have extensive knowledge and constant (self-)training to master all the best practices required to produce structured, secure, tested and optimized apps
difficulty in recruiting expert and versatile developer profiles, as well as difficulty in finding jobs for developers who are not familiar with the latest tech trends
increase in the overall production time due to the increased needed time for training, environment setup, development, optimization, debugging, testing, building, etc.
increase in the overall production cost due to this increase in the overall production time, and because of the high salaries of the few star developers mastering all of the required techs
loss of money when obsolete apps need to be refactored because of hype techs, hype tools, and good practices frequent shifts
This list could be extended and detailed. But we shoud simply understand that according to the TRIZ laws of evolution, these current problems will find a solution.
Shouldn’t we just learn stuff?
Some of you may think the solution is just to go ahead, and learn the latest syntaxs, patterns, tools, and frameworks. Others may say we should specialize in using one tech, taking the time it takes. Because after all, it’s part of our job. Devs need to keep up to date. Because that’s the way it is.
But asking developers to continually be trained or self-train is under-optimized. Precisely because training represents a cost in terms of time and/or money.
And it is a significant cost, even for experienced developers. Here, I wanted to refer to an article about javascript fatigue but there are too many I can’t choose. Something just doesn’t feel right.
Thus, the cost of expecting devs to continually be trained or self-train reduces ideality. It is not efficient enough. On the other hand, there is another solution that I would like to propose.
Let’s simplify dev.
It is interesting to note that the SIMPLIFICATION of development alone makes it possible to solve each of the problems above mentioned.
If the many current competing tools (frameworks, libraries, bundlers, languages, etc.) offer similar levels of flexibility and efficiency, the simplest will become the most popular, simply because it is by definition less costly in terms of efforts, training time, development time and therefore production cost.
For a while this rule was not totally true because companies and developers were orienting their choice towards tools promoted by references such as Google (Angular) or Facebook (React). Indeed, the popularity of the creators of these tools reassured companies, who saw in them the benefits of durability, reliability, and optimization. Their complexity certainly represented an investment (in terms of training in particular), but a safe investment with many benefits.
However, the AngularJS to Angular switch scandal, and the new popularity of “challengers” frameworks such as VueJS or Svelte, shows that this criterion of popularity tends not the be the most determining factor on tech choice anymore. Because we came to realize that we actually can make things just as well, but in a (little) more simple way.
Thus Simplicity little by little becomes a determining criterion because it increases ideality: allowing us to reach the same benefits, with less costs.
Simplification
= less training time and fewer competing tools
= less development time and less headaches on tech choices
= less development cost, less recruitment difficulties and increased app durability
Thus, there are many reasons to believe that with similar performances, simpler solutions will gradually replace more complicated ones.
Wrapping-up
Rather than continually learning, we should change paradigm by simplifying dev. Simplifiying solves many problems caused by current practices and habits.
However, this simplification will only be effective and useful if we maintain the same flexibility and performance offered by current tools.
But this question deserves to be discussed in more detail in my next articles. This one was meant to be introductory: as recommended by TRIZ, I here wanted to specify our goal, keeping in mind the ideal.
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.
, inventeur de TRIZ](https://techmeup.org/wp-content/uploads/2020/11/post-2353-5faf8d5b78fa8.)
, par Karen Gaad](https://techmeup.org/wp-content/uploads/2020/11/post-2353-5faf8d5ba9ee3.png)
](https://techmeup.org/wp-content/uploads/2020/11/post-2223-5fa66ebde6cd5.)
 uses Cordova to scaffold different flavors apps based on HTML/CSS/JS](https://techmeup.org/wp-content/uploads/2020/11/post-2223-5fa66ebe475b3.png)