What happened to WYSIWYG ?

After 40 years, I am still typing “Magic Spells” into text based command windows. All the productivity provided by the “What You See Is What You Get” tools of the 1990's has disappeared.

the reasons that this had happened are probably due to:

• the code produced was difficult to distribute
• some of the tools posed a risk to the incumbents position
• the tools produced overly complicated OOP based code

React and other JavaScript frameworks solved the distribution, control and object oriented programming (OOP) issues.

However, nobody has yet built a WYSIWYG tool for these frameworks that hasn't been abandoned after a year or two.

How Development Has Changed in 40 Years

In order to answer the question “why are they important” we need to look back a few years to the early 1990's, this is what my screen would have looked looked like.

Lots has changed in the last forty years, this is what one of my screen looks like today.

Wow, I have colours!

We don’t have much to show for forty years of coordinated human development. I am still relying on a text editor, with a list of “magic spells” like “gcloud beta compute ssh ….” to get my work done in these terminal windows.

It was not always like this, back in the mid 1990’s, there was a plethora of amazingly productive WYSIWYG visual development environments:

• Delphi, PowerBuilder, Visual Basic and Blend

These tools allowed us to produce software at lighting speed, and hence at a lower cost to our clients. But we don’t use any of these tools today, what went wrong?

Software is hard to deliver

It’s really hard to get your software to work on someone else’s computer.

Back in the day with Delphi, every company used Windows and all their PCs had ComCtl32.dll on them. So we knew with confidence that a simple user interface we built would run, as that DLL was almost all that was needed to get it to run.

However the software I produced back then, looked like every other application, and they all looked like outlook. But this software did the job.

Then the “World Wide Web” made it’s way to the consumer, and the cool developers could make the screen look a lot more interesting.

In addition to looking good, these web pages had an advantage over the old applications. There was no more need to use complicated programs like installShield to get your software on the end device. They just worked.

This was the dawn of Server Pages. All we had to do was just get some HTML onto the client and we had an application running.

Around the same time the second disruption arrived. The introduction of the iPhone and the resurgence of Mac computer. Henceforth within the corporate world we could no longer rely on my trusted ComCtl32 to get our software to the user, as many people were no longer using a windows PC.

Silverlight could have given us the delivery route to all devices, but I have my suspicions it was sidelined as it could have undermined the need for Microsoft’s Windows OS.

Apple killed off Flash, my hunch here is it could have undermined their control of the walled garden.

But even if this corporate opposition had not happened, Silverlight and the other “Object Oriented” development solutions had another more serious and fundamental flaw.

The Trillion Dollar Disaster

Ilya Suzdalnitski explains this in his excellent article the trillion dollar disaster.

To sum it up, the basic problem is Complex vs Complicated. We need to build things that are complex as we need to achieve clever goals. But the things we build shouldn’t be so complicated that no one can understand how they work.

The problem with Object Orientated programming (OOP) is that it leads to complications. This is because OOP mixes data and transformations of that data in the same place, the object. This then results in complicated interactions between the objects and we end up building systems that are far too complicated for anyone to maintain.

React’s functional components, come at this issue from a different direction. Frameworks like React and Vue takes the mathematical approach;

• data + function = screen

You take a piece of data and drop it through a function then a screen comes out the other end. We can drop data through at 40 times a second and get animations. Alternatively when you touch your keyboard, there is a different piece of data to drop through the function, and we have an updated screen.

This function also ends up being very complex, so we break it down into a number of simpler functions and end up with a tree structured application. The tree structure results in order and more understandable path through the code.

• Simplicity is composed to make complexity

In an application these functions are usually broken down so that each function does something at a very simple. For example, on one recent project, I created a function to decide: should we draw a red box around text or no box at all.

The tree structure makes the complex is easy to understand. This allows us to walk through the code path without “frying our brains”.

Trying to do this with OOP, is more like walking through a maze. At one stage in 2004, I had the office walls covered with class diagrams from floor to ceiling, in order to manage the complexity of a 10 screen application!

Not once in the ten years I have been working with JavaScript have I needed to inherit anything. It’s composition all the way down.

There is nothing stopping us writing incomprehensible “Spaghetti” code with React or Vue. However, these frameworks can lead us down a better path towards more manageable code.

Along with this functional path, there is a new tech appearing called “Server Functions”, that takes this approach to the next level. This will allow us to reduce some of the running costs associated with React apps.

I hope “Functional React” sticks around longer than WYSIWYG did.