JavaScript Threading – The Magic Framework Problem

JavaScript Threading – The Magic Framework Problem: @Joseph Berg made an excellent comment in my last post (Stop Punishing the Users.  Eliminate the Wait.).  And it brings up a very valid issue, which deserves it’s own separate posting.

In my previous post, I identified two major OData issues that should be dealt with at design time: violating the MVC design pattern, and not making the browser smart enough to avoid long user wait times.  Joseph pointed out that SAP UI5 has controls that deal with both of those issues.  (Check out his reply, under the main post, for details.)

He is absolutely correct.  There are controls out there, for UI5, Angular, and React, which take care of all the issues I brought up in the previous post.  But, he also exposes a critical thinking flaw at the same time.  I call that flaw…

The Magic Framework Problem

This happens when two ways of thinking collide.

• The framework developers create lots of “super smart” components.  These components are so good at their job, because they hide the underlying complexity and deal with major issues very well.
• The designers have an imperfect understanding of the challenges they face.  This is normal – design usually happens before most challenges come up.  So they design with what they know, and often with a preconceived notion of how things work.

Mix the two together:  The designers assume the framework will deal with all the design issues automatically.  In other words, magic.

Getting back to fundamentals

To use those toolkits effectively, the designers and developers must have an understanding of the fundamental problems.  The fundamental problem I was describing in my article was about leaning on the OData protocol to do a lot of the “heavy lifting” and therefore forcing the user to wait for operations to complete.

I was trying (and maybe failing) to make a fundamental point.  Any designer who doesn’t include a model of every asynchronous operation that occurs in the program flow, is making this mistake.  Any call to an API, data source, or server, is going in incur some cost.  Those costs must be clearly identified – or the real experience won’t match the one in the blueprints.

Let’s take this even further, however.  Two major things:

• Don’t design around the frameworks.  The frameworks aren’t magic.  If the design is agnostic, and just discusses the implications, then the developers can solve those problems using the frameworks.  (TL;DR: Don’t put the cart before the horse)
• Focus on the user.  The user experience is often lost in the functional requirements.  Software that hits all the requirements, but is hard to use, is a maintenance nightmare.

The Frameworks are great, but they are just tools

In Joseph’s defense, the toolkit is doing exactly the right thing.  A toolkit works best when it has very powerful, advanced features.  Those features should take care of issues and problems, and even better if they take lots of code and centralize them.  This is definitely the case in asynchronous operations, like the ones I was describing.

I’ve also found the best way to discover the greatest, most hidden, features of a framework is to look for a way to solve a problem.

In conclusion, Angular, React, and UI5 can solve these problems for you.  But first, make sure you know the problem exists.