Programming language hypes Frameworks, libraries and mega abstractions - Is there any room for simplicity?

"Simplicity is the ultimate sophistication" Leonardo Da Vinci
"Dealing with complexity is an inefficient and unnecessary waste of time, attention and mental energy. " Edward de Bono

Programming languages are something for Elite people. Frameworks generate hypes.
Libraries could be used but we shall use mega abstractions.
Is there any room for simplicity?

See The World is drowning in redundant code The global wheel reinvention convention

I have some questions:

Once upon a time long ago, before hypesters began taking mainstream pills.
IN a land long forgotten happy programmers developed complex software with simple tools.
They practiced their crafts from the basics.
Then one day a very enlightened group of people started inventing frameworks.
They thought that a framework that did everything could help you in faster development.
Soon after hipsters invaded and you had a framework that made other frameworks.
Or in Java terminology, you first need to build a factory that builds your classes before you can add 2+3.

What happened to proper programming?
What's wrong with using battle proof design patterns?
Why the heck are there so many programming languages, frameworks, libraries that do the same thing?
Why are people becoming web developers and not software engineers?

NOTE: This article mainly analyzes JavaScript frameworks. However it also criticizes backend frameworks for most other programming languages.

The following is a pamphlet, treat it likewise.

Version 1

Tired of plain programming? Tired of your boss picking on you for not using the newest framework?
we've got good news for you. We've developed a new shiny framework called ToughJoyFax.js
Yes, you've figured it out. ToughJoyFax.js can do what you do in plain programming code in 5 lines in just 3 lines!
A 60% improvement! It's 1.5x faster than the OldStupidFramework.js and has less overhead!
And what's the most important part it's fully backed by Pear, MacroShaft and Goggles!
Come on and tell all your friends to join the bandwagon!

We have a special section on StackOverflow for those moments when you just can't figure out how to do it.
No, you really dont need to write pain old vanilla code.
Why would you even try proper programming and good old design patterns when you have ToughJoyFax.js ?

Dear creators of ToughJoyFax.js:

A friend of mine said he can do what you can do with ToughJoyFax.js in 50 lines of code!
How is this possible? Your tech support assured me that the 200 lines with ToughJoyFax.js is the shortest and fastest way possible!\\

Yours truly,
Framework Enthousiast

Dear ToughJoyFax.js developer:

No, you really have to understand that the 50 line plain code is different than our 200 line code with ToughJoyFax.js
Even if it does the same thing, trust us! It's different, it doesn't use our internal implementation and it's missing some of the coolness of updating the state on the fly.
You need to redraw the canvas 20 times a second. No, the refactor pattern is not needed at all!

With regards,
DemiGod developer of ToughJoyFax.js

UPDATE Version 2

Dear users

We're happy to inform you that after 12 months of hard work we've released ToughJoyFax.js version 2.
It brings new enhancements with it. Thanks to our internal team efforts we can now make the leap to the new Web 8.5.3
Due to changes in the way we think and because the interwebs is changing so fast we have made efforts to keep up with everything for you our dear users.
Some of our choices where not easy here is a list of the most notable changes.

Our code has been rewritten by oversea monkeys from scratch to better serve your needs. If you think Shakespeare was great, wait untill you read our documentation!
We've deprecated all API calls from the previous version. This way we want to test our true fans, those who will follow us to the end of the world.
We've also discovered 5 severe security issues in version 1.0 which have now been fixed by an external security firm who audited our code.
We will no longer support version 1.0 starting 30 days from today.

Please read our 200 page manual on how to upgrade your applications. It should only take a few weeks to rewrite all your code.

We hope you'll have restless nights learning it and cursing as we did when we developed it.
Don't forget to give it to your friends and tell your managers it's for their own good to upgrade to the newesr version!

Thanks!

Version 3

Dear users,

3 years have passed since the initial release of our first version and we're now glad to announce version 3.0 alpha!
After further market analysis we have decided to stop the development.
We've moved the code to a github account and created a special community version 3.0 which you, the community will always maintain it!

We've only deprecated 50% of the API calls from version 2.0.
The number would have been higher and ranged between 70 %to 100%.
However due to the large number of e-mails we kept receiving and people imploring us not to change everything we had a rough decision ahead.
So we did what we do best, we flipped a coin and figured out that 50% of the code needs to be rewritten anyway.

Some of our best developers left the team during this process.
Some where kicked out for their radical ideas. This has been a though decision.
Can you believe some of our most radical developers?
They said that our framework is no different from any other!
BLASPHEMY!
They even claimed they could do what our framework does in fewer lines of code with zero overhead!
ANATHEMA!

How can TravaillerLentement.JS be better than ours?
Yet we have to accept the facts that Ventosanzap.js performs better than our framework.
But it's only due to the fact that they've tested only 50% of our functionality!
They forgot that our framework is great and it doesn't matter if it's slow@

We thank all of you for your support!

And now back to reality.

The world goes on

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to build bigger and better idiots. So far, the universe is winning."
- Rick Cook

Still think it's funny?
No, it's the state of today's world.

By the time you've read this a new programming language came out.
2 new frameworks have been updated to a newer version.
A new library has been developed for something that already exists out there.
And of course 10 new security issues have been identified with old unmaintained code.

Ah and yes, a new person has reinvented the wheel claiming that his framework is better, new edge, faster, etc than the previous 100.

"Things evolve to become ever more complex — not more simple.
Those who have got used to the complexity no longer notice it and even add more elements, so increasing the complexity even further." Edward de Bono

What i've described earlier is just a way of making simple things complex.
All programmers should be required to have a copy of Edward De Bono's Simplicity book on their desk.
Reading most of his books and maybe even taking a CoRT course to improve thinking and creativity.

A way of making the software stack confusing for everyone involved.
Adding abstractions to something that is already exremely simple only makes it complex.

Long ago I believed that excessive frameworks added bloat but that using frameworks was also a great way to develop something.
College and work forced me to adopt the way of thinking that "frameworks simplify".
Up untill 2015~2016 I tried my best to use frameworks to "simplify".
But ended up spending a considerable amount of time to reimplement the simple in complicate ways due to the nature most frameworks work (talking about backend & frontend here).
I eventually realized that frameworks DO add bloat. They drown the programmers. They overcomplicate the hiring process. Oh, yo udon't know x, y z frameworks, sorry we want someone who does know all these things.

Frameworks are great for to be sure that everyone around the world that might work on a project knows a set of constraints, logic and understands what it's all about.
But frameworks have become an evil that can no longer be tamed. Because the moment you chose a framework you impact every single development and engineering decision for the future of your project.

Algorithms + Data Structures = Programs

So a Program is created by a unique combination of Altorithms and Data structures.
This is the essence of programming since the 1950's

A few quick questions to think about, try writing the answers on paper.
What happens if you design bad data structures, do you need to change your code too when you change the data structures?
If you design bad code but good data structures, do you need to change your datastructures with your code redesign?
What's the most important asset in the life of your product or business?

The truth is that these questions are difficult and depend upon context, environment, people, culture.
The one unifying answer is "data" is the most important asset.

If you ONLY have bad code, you can rewrite that.
If you have bad data structures then you need to change them AND change the code.

"There is often a much simpler way of doing things — if you make the effort to look for it. Simplicity does not just happen." Edward de Bono

To better comprehend the idea let's analyze a little more.
Imagine a table of employees in a SQL database (nope, no noSQL here).
It;s NOT normalized in any way. The naming conventions are weird, data is stored in duplicate ways.
Of course the best programmer will generate some code.
Later if one changes the datastructures then the code will also have to change once again.

Imagine you had a normalized database with a way to add new data anytime without adding new columns.
If you even have a bad programmer write code, a great programmer can rewrite the code and you won't have to touch the code.

To (mis)quote Linus Trovalds:
"git actually has a simple design, with stable and reasonably well-documented data structures. In fact, I'm a huge proponent of designing your code around the data, rather than the other way around, and I think it's one of the reasons git has been fairly successful […] I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important."

"I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important.
Bad programmers worry about the code. Good programmers worry about data structures and their relationships."

Or better:
"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious. "
Fred Brooks

Why you don't need mega frameworks

There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.”
- C.A.R. Hoare

You do NOT need a framework to do your job.
No, unless you at least a few projects made in the the language of your choice using only the PURE builtin functions and standard libraries.
You don't even have to touch a framework. For if you start working with a framework before you understand the advanced intricacies of a language you will fail miserably.

You do NOT need a framework to do your job.
What you need is proper experience and knowledge. You may need a library or two but keep it at that.
Add a single call to a simple library function. Do this only if it would take you more than a few hours to program that specific function.
Frameworks move complexity around. You end up writing more code and come at the same code level than if you hadn't used a framework.

One of the most cited example of using a framework is :
But why waste time writing everything yourself, you're reinventing the wheel?
You can read more about my thoughts on reinventing the wheel in this post.
If you've never written a project in it's purest form in a plain programming languages by just using basic libraries you won't understand the abstractions behind how a framework actually works.
This means that every time you use a framework you spend time figuring out WHY simple things don't work how you expect them to behave.

When you use a framework you tend to do everything in the way the framework does it.
Simple things become complex and you end up not being able to see the forest for the trees.

Is this a fallacy ? Does the argument stand on itself?
"Simplicity is easy to use but can be hard to design. You may need some creativity." Edward de Bono

No framework can come close to good programming skills. By using a framework without understanding how the underlying system works you're doomed to create bad software.
Bad software creates a bad world. Think about the following question for a while:
Why is it that there are so many frameworks and libraries for JavaScript and PHP than there where frameworks for C?

It's quite simple. Newcomers to the web don't even bother learning how the system works.
link to being a true PROgrammer
Instead they jump the bandwagon of whatever new trend exists. A trend that might not exist 2-3 years from now.
But C programmers need to learn how the system works before they can even try to use a library or framework.
If a C programmer doesn't know how a pointer works or forgets to deallocate memory then all his or he projects are doomed.

Using a framework is pretending to know your tool and pretending to be cool by following the herd.
If you can't implement something that a framework does yourself then you are not simply pretending, you are babooing your way into life.

Companies are in dire need of software engineers,

Companies are in dire need of software engineers, Yet all they get is hipsters.
Why is this happening?
This is a dual problem, companies get what they ask for. They ask for people who have experience in hunderds of various frameworks and things. Yet they want the best people. This is virtually impossible on multiple levels:
It's economically impossible since a person who invests time learning a framework can't invest that time in something else.
It's better to have someone who knows how to work with the barebones of a programming language than someone who possesses knowledge about 10 different frameworks yet can't work with the bare minimum.

Take for example someone who is an ace in working with any scripting language. Give them a project in C and they'll stumble.
Ask them to do any devops work and most will not know where to start.

Take a C programmer who has Linux experience and ask them to learn a new programming language or framework, it won't be a problem.

More and more experienced software engineers are migrating away from frameworks and bloated API's to simple functions anyone can understand and maintain.
I call them Software Engineers because they are Engineers. They understand how the system works and behaves.
Coming from the low level CPU instructions, going through how the TCP/IP stack works with the operating system up to the higher level programming languages.
Having an proper understanding of everything is required before you can become a engineer.
In the software world most people start with webdevelopment and go down. They take a topdown approach.
This is fine if you'd think they will ever go down to learn the basics, but this never happens.

The programmer code debt is getting higher by the day and hiring a new programmer in 2018 is 10x as complex as it was 10 years ago.
This complexity is the cause of the software bloat complexity and abstractization of simple notions.
If it was enought to know a programming language 10-15 years ago now you need to master 3-5 programming languages, 5 frameworks and a great deal of bloatware.
Not mentioning specialized software which you need to know, software that exists only to fill certain bad engineering tasks.

This way people and companies spend tremendous amounts of energy and money in training. Training for things that change so often it's tragic to even think about.

We;re creating such a complex world that we don't need a global catastrophe to occur to wipe us out.
We just need to put all of our valuable data in a start-up;s data center which then fails.

It may be better to simplify a process rather than train people to cope with the complexity. Edward de Bono

I've taken a good look on how Elixir/Erlang works and I am sometimes amazed by the simplicity with which you can implement things.
You can do things which require an abstractization of 10 different tools and programming languages with only ONE programming language and maybe a few packages.

How?
"There is always the possibility that there is a simpler way to do some- thing. Even if that is not always the case it is always worth investing some thinking time and creative effort in trying to find a simpler approach." Edward de Bono

Elixir and Phoenix

"Good design adds value faster than it adds cost."
- Thomas C. Gale

We're going to talk about Elixir. Analyzing the way it was built.
Everything in Elixir is modulable.
Take a look at the Phoenix Framework. It's a web framework built for Elixir.
Even though it's called a "framework" it;s actually an amalgam of extremely well written libraries.
This means that Phoenix was built by people who thought long about the data structures and layered everything out just right.
They don't try to reinvent the wheel nor do they try to use 100 different obscure frameworks to do the job.
What happens is that each functionality can be used stand alone and each library can be used in Elixir projects that don;t have ANYTHING to do with the Phoenix framework.
This is a proper example of how all libraries/frameworks should be built.

Phoenix is more like a proper library than a framework. It has the basics you need to build modern web apps.
Yet it doesn't includ everything nor forces you to adopt a certain mindset. You can use whatever library you want to add extra functionalities.
This is what I call great design.

I can use the Ecto and Plug packages in any project I like as long as I follow the Ecto guidelines and the Plug guidelines.
Furthermore, basic things like templates, documentation and testing are all incorporated into Elixir.
This means that you can use the same templating system for websites, json, TCP/IP, etc.

This article tries to express a deep concern I have about programming in general.
However, I could have just sent you to read http://motherfuckingwebsite.com/.
The post neo modern poettry might have inspired the same thoughts as this article.

About the blog design and future redesign

I've always been a fan of using lightweight tools to do the job.
This blog was rebuilt from scratch with Elixir/Phoenix and using the pure minimum of CSS and JavaScript components.
It ended up using PureCSS and a few native JS implementations. No jquery no other big library.
The CSS side including the theme was using 38.1 KB while the js size ended up being somewhere around 58KB including websocket support from Phoenix.
Excluding ckeditor for the blog/page editor and highlight.js for the code highlighting.

A lightweight blog resulted which fulfilled it's job. I had already started a PureCSS design and I can say that I'm impressed. I will however be converting the blog to use a different CSS framework/library.

The choice comes from the fact that I want to expand the blog system to add more complex backend functionalities for which I want to  use a unified frontend theme.

Now I know how easy it is to build lightweight dynamic websites that can get huge amounts of traffic

Conclusions

Use micro libraries and micro frameworks to get the job done, CSS, javascript and HTML have some neat small libraries

http://microjs.com/#
https://purecss.io
https://bunnyjs.com/

Always try to simplify everything you do especially if you provide an API or just need basic functionality.

Frameworks do have theyr benefits for fast protyping and building small scale apps. Whenever you need power, speed and extensibility try going after a lightweight library and do the job well.