Skip to Content
Author's profile photo Jonathan Baker

Stop punishing the users. Eliminate the wait.

I just finished a talk at Defrag – a conference in Denver, Colorado – and talking with the attendees always leaves me with great insights and discoveries.  This conference was no exception.

My current talk is called “The Race Condition”.  It’s about the multi-threading options in JavaScript, and how to use them.  It’s advanced stuff – most people don’t even start thinking about this kind of development issue until they are dug in to SAP UI5, React, Angular.JS, or any of many other frameworks/libraries.  And the reason should be obvious…

JavaScript is single threaded.

At least, that’s the prevailing wisdom.  What’s even more interesting is how fast you can knock that theory apart.

Try out the following GIST, and see what you think:  Thread-test.html GIST

During the Q&A after this session, a great questions came up:  Does this matter when you are using OpenUI5/SAP UI5?

The answer, of course, is obvious.  But it’s also a deep concern.  The SAP UI5 framework does a lot of the work for the developer, helping them whip up a quick application.  But it’s not entirely optimal, and it’s easy to forget the framework isn’t everything.

For example:

  • Data sorting/filtering.  The default way to accomplish this is to use the OData service.  Pass the sort or filter parameter as part of the query, and the database or middle tier does all the work.There are two inherent problems here.   First, you just dumped MVC design out the window.  Data presentation is the Visual tier’s job.  We have smart browsers, super-fast CPU’s, and plenty of memory.  Even a 2-3 year old smart phone has runtime power greater than a 10 year old PC.And, to make matters worse, we then introduce network lag.  Which means a LOT of this:
    UI5 Busy indicator
    And this drives me NUTS.  We just offloaded a second of work on the front end to 3-10 seconds of network hold.  Oh, yeah, that’s efficient.Why did we decide more waiting was the solution?
  • Loading additional rows.  Another aspect of OData loading is the pagination.  The OData server will send out a limited number of top rows, and then the client can ask for more.The default for this is to load the data “as necessary”.  Except we then get back to the same wait.Why?  The client knows exactly where the user is on a list.  It knows how far they have scrolled.  And it has memory to spare.But, loading additional rows in the background (and then merging them) is hard.  So we don’t do it.  More waiting.

So, I think the idea of background processing should be part of the design process from the beginning.  If you are mocking up your application, or using Build, follow these steps:

  1. Take notes on when a “load icon” will appear on each screen, and then create a total.
  2. Look at the most common pathways through an application.  How long does it take?  How many “wait” states occur during that flow from beginning to end?
  3. Create a “pass 2” list of items to optimize.  In the first pass of an application, especially in Agile, it can be best to just build the Least Common Denominator.  That’s OK, but make sure that the time is there to get back to the waiting.

And here is the most important of all:

Use named functions, and break them up.  
Writing all of your code as one big method, and using lots of anonymous inline function definitions may look cool, but it’s very fragile.  If you separate out all the work in to discrete steps, it’s much easier later to wrap them up and move them to an asynchronous process.
Just a few thoughts.  Thanks for reading.  Feel free to email if you have any other ideas!

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Frederic Berg
      Frederic Berg

      Hi Jonathan,

      just a few remarks about the pagination and client side operation issues you mentioned above.

      SAPUI5 supports a mode in which the typical list operations like sort and filter can be done completely on the client, not requiring another round trip to the server, here’s the documentation of the OData List Binding. Check out the setting for the operationMode.

      Another issue you brought up is that of efficient paging within large data sets. While OData supports this nicely on the protocol level, SAPUI5 also has specialized controls which make efficient use of this feature. Have a look at the following example:

      The control will start to fetch additional rows while the user is scrolling down already in the background in an async task. Ideally, the user won't even notice that there's a network operation happening at all. Certainly, there's no busy indicator in this case. 

      There is even the option to switch to the client-mode where you can see how the client-side operations look and feel.

      Hope this helps to clear things up a bit and thanks for your post!


      Author's profile photo Jonathan Baker
      Jonathan Baker
      Blog Post Author

      Thanks for the response!

      I think you just brought forward a very good point, but probably not the way you intended.  I call it the…

      Magic Framework Problem

      This happens when two concepts meet.  First, the framework provides very advanced options to deal with major language issues – like threading.  Second, the developer has an imperfect understanding of the problems they might encounter.

      This leads to one place:  “The framework takes care of that for us”.  In other words, it’s magic.

      I’m really glad you brought this up, because it’s a great segue in to my next blog post.  I’ll post a link to it when I get done, but I think the follow up should be “the framework can fix it.  But first, you have to acknowledge the problem exists”.

      More soon…

      Author's profile photo Jonathan Baker
      Jonathan Baker
      Blog Post Author

      Here you go:

      The Magic Framwork Problem