Iāll give you 3.
My app is a unit calculator. Not a unit converterāthere are plenty of those around. What I mean by unit calculator is that you can put ā5 inch + 6 cmā and get the answer in pica (pica is a typographic font size unit) if you wish. Or add US gallon to UK pint and get a result in litre. Whatever. You donāt convert, the calculator takes care of it. You enter what you have and specify in what unit you want your result, and it handles the rest.
In keeping with the Pareto principle, there are units that someone will be using a lot more often than others (my app has almost 400 units, including 90 currencies ā and m and cm are NOT two different units. both cm and m are metre. The ācā is a prefix. There are 24 metric prefix defined; so if one wanted to count cm and mm as separate units, weād be talking thousands of units), and the ones a user considers popular are likely to change over time (if you are on a trip, you will use currency conversions, but when you start working on the deck in your backyard, you will be more heavily using linear measures).
So, in order to speed up access, the app offers a āfavoriteā key that keeps tabs on the recently frequently used units. This implies sorting the frequency of use score. And that is where it gets tricky.
The best algorithm for sorting is heapsort. Coding this in Thunkable Classic blocks was shown in my test to take over 3 seconds to sort the unit usage and display the 20 most popular ones in order for the user to pick. Evidently, 3 seconds delay after clicking a button is very long if the intention is providing the means of avoiding going through two scrollable menus (one for the type of unit, one for the unit from the type); that saves little time, if any.
But taking all the unit frequency scores, putting them in a webviewer string, sending this to a webviewer component (it does not even have to be visible!) that loads a file with the same heapsort logic coded in HTML/Javascript, and returns the resulting sequence for the front end to display in a menu; well, that was running about 700 times faster. I actually had to make mock tests with list of thousands of entries to accurately measure the speed gain, because it was going so fast. I would have been happy with half a second, but I got 4 millisecond.
Another case was with the trigonometric functions. Sine of 30 degree is supposed to be 0.5.
Except that the āsinā function in Classic Thunkable returns something that displayed as 0.499999999482 on the 12 decimals display. So, I modified my code to send the trigonometric functions to be processed by a Javascript code using the webviewer string. Now, I have sin(30 degree) = 0.499999999999999944489 which renders as 0.5 up to 16 digits. Problem gone.
I told you about those 90 currencies?
The app has a page that shows the exchange rate, allowing someone to tweak them (suppose that the rate needs to be the one from last week for instance, or needs to include some processing fee, or whatever ā anyway, just looking at them with their little flags is kind of neat). I could never put 180 text fields (2 for each currency, conversion from and conversion to US dollar) logically linked so that changing the ātoā rate changes the āfromā rate in the reverse proportion, in a scroll table (since you only have the room to show a dozen currencies at a time) with the processing required using thunkable blocks, that would have been crazy complicated. But with HTML and Javascript? A cinch.