English version / Version Française ici
Les bénéfices de l’Abstraction
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].
Top comments (4)
Your metaphor for car usage is a false equivalency. Developers build things with their tools. No one builds something with a car. Contrarily, if you were to build a car on your own, you'd have to learn how to use all the various tools that are involved in building a car. That's not a simple task by any means.
Development of any kind is complex and complicated. Sure, the tools can be difficult to use, but learning how to use your tools is what makes you a better craftsperson and able to build better. The tools give us a means of creating, but it is our responsibility to learn how to best apply and use these tools and combine the resources available to create something out of nothing.
Lastly, I totally agree that the tools of the trade can be overwhelming and difficult to learn. This gives the impression that things have trended in the opposite direction of becoming simplified as they've become more complex. But think about how difficult it would be to prototype a complete single page web application with dynamic features that respond to the user without modern day tools and using only plain HTML, CSS, and JS. Now do the same thing using a framework like React or Angular. I think you'll find that the more complex task has been simplified.
I wouldn't go as far as to call it a false equivalency, it's there but it is half baked. I do believe in some cases we can expect this comparison to be true, and it is. Take windows, for example, those who knew the basics around Win 95 can still make their way around Win 10.
And instead of comparing users to drivers, comparing developers to car enthusiasts would be more apt. We are inherently able to ride our own car(framework/technology/language) with perfection, knowing exactly what kind of V8 engine with turbochargers and NOS and what not is under the hood. But if you give a muscle enthusiast something like a GT they would have a hard time at first, but given the base design of all cars tends to be the same, they can definitely make their way around it. I do agree with the rest of your comment.
Though applying the same paradigm here, I disagree with the last comment
"And for every new tool/framework update, there would be no more learning costs. Just a pop-up in the dev tool."
Any sophisticated tool has already achieved this state, only new and disruptive tools and frameworks are currently those with drastic shifts in their implementations. Here, every new tool that is coming out is going from 2 stroke engine to 4 stroke engine, you cannot just replace it without overhauling the entire engine, transmission, fuel pipeline, and gear assembly and when they do go from 2 stroke to 4 stroke, they only make the driver's life easier.
Gentlemen, thank you for having taken the time to read my article.
@ Stephen Gerkin
Would you say that tools have to be difficult when their purpose is to create/make/build stuff ? I believe any tool ergonomy should not be related to its actual purpose.
Many creative tools are simple to use : paintbrushes, lego, etc. Even if you take complex creative tools, often their user don't need to understand how they work.
Take a landscaper for example. Do you agree this is a creative job ? If a landscaper makes a garden, he may use a chainsaw. Chainsaw are complex but he doesn't need to care about how it is working. He just needs to know how to use/operate it.
Same thing applies to logic. Excel or Access users don't need to be devs to make stuff that sometimes look close to a little app. Yet they don't actually need to understand what's under the hood. Many times using Macros isn't required. Using those tools requires a little practice, but I wouldn't say it is overkill.
I agree though on the fact it would be difficult using only HTML/CSS/JS to make modern apps, with very high standards (on team collaboration, reactivity, loading time, tests, etc). You are right on this one. But I believe that :
1) nowadays standards are overkill : gaining some milliseconds of loading time might make sense for some high-traffic website, but not for the little store around the corner. Writing TDD doesn't make sense most of the time as well. We haven't for years and yet many apps were user tested and working fine. As for SPA, many times it is not needed as well.
2) one may think that as long as it is possible to reach perfection we should go for it. I'd be careful with the tradeoff : it is not free, it implies time, it creates bugs, quite some maintainance, and therefore costs.
Thus, I think devlopment became complex because Modern dev standards became The default standard. I would be fine with it (after all we wanna be proud of what we are making) if it wasn't for the new cost. Given what it costs to use those standards, I think there is yet a long road to go towards simplification (which has begun though, as we can see with svelte or parceljs for example).
@ Abdul Rahim Shaikh
I like your Windows example, and talking about Car enthusiasts like you suggests makes sense. I also agree on the fact drastic shifts are happening for disruptive tools and new frameworks. It happened to AngularJS -> Angular. Thanks for your comments and ideas.
@ D3vil-hunt
"What if developing an app could be as simple as using it. At least for some people. I guess thats the point the article is trying to make." I couldn't say it better. Actually you summarized my point of you. The new dev Role I refered to as "Dev tools users" will eventually disappear : pushed to an extent (but we are not there yet) the app makers won't not be devs, but regular users using tools made by devs. Bubble.io, Flash (back in the days), or Excel are good examples to realize users dev skills are not mandatory to make stuff.
Thanks to you all. We may have different point of views but it feels good debating on those matters :)
You have very well demarcated the role of a developer and how development is different from driving a car. If I may say what I reckon from you comment is, driving a car is like using an app and building an app is like building a car, thus developers need to understand all the subtleties which otherwise could be ignored by the users. But what if developing an app could be as simple as using it. At least for some people. I guess thats the point the article is trying to make.