Forem: DataTableDev

Pseudo-multithreading in Web Development | DataTableDev

DataTableDev — Fri, 19 Jan 2024 15:09:33 +0000

We continue working on DataTableDev (check out our new demo with a new dataset)👐 , and we want to give you a glimpse of the backstage. In this article, we’ll explain how we used pseudo-multithreading and some callbacks to implement it.

It’s crucial to improve the user experience when working with data tables. It will boost productivity and lead to better results in analysis. Smooth navigation and animation, even with huge data volumes, are very important and are totally achievable!

If you haven’t read our previous articles, we recommend you to check them out as they explain a bit more about 💡how we came up with the idea of such a tool and what frames have to do with the optimization of data analytical processes. Since we explained the theory of frames and general approaches in the first two parts, we would like to delve into the practical implementation of some details this time.

To achieve smooth navigation (e.g., scrolling), the result needs to be rendered in a smooth and even fashion. Also, for the display to be graceful, a steady frame rate must be kept, therefore requiring maintaining each frame’s length alike. That way, the display won’t be choppy, jerky, or uneven without sudden jolts. While building our approach, we used pseudo-multithreading with two callbacks to help us.

☝️Avoiding extra redraws

requestAnimationFrame() is a method used to execute the rendering code on the next available screen repaint to avoid possible reflows caused by the recalculation of previously rendered elements. This means the drawing process is performed when changes are ready to be made, thus providing a more efficient repaint, resulting in smoother and more pleasant user interaction.

This is a great place to run code that doesn't deal with handling user input before redrawing directly. However, certain calculations should be avoided in the method, as this can lead to forced layout synchronization. In this phenomenon, the layout change happens before the styles are recalculated.

⚙️Optimizing the free time

requestIdleCallback() is an elegant way to identify the moment most appropriate for executing under-the-hood tasks, as well as predict how much time is left until the idle stage changes. Therefore it makes it possible to estimate whether a certain process can be completed at the given moment, then carrying out the procedures explicitly during idle times.

The main idea is to use the browser's time and resources as efficiently as possible; that way, we'll prioritize event handling, rendering, etc., and the script we pass to execute in
_requestIdleCallback()_will run when possible and have a lower priority than other processes.

In combination, these methods allow us to prioritize and optimize the execution of the tasks and fit in the constraint of 16.7 milliseconds per frame and maintain a steady frame rate. Nothing extra is done, and free time is used as productively as possible.

💡Why do we call it pseudo-multithreading?

The browser does not create a new thread, and the entire script (both main and secondary) is executed in one main thread. Suppose we schematically depict the order of calls. In that case, we will notice that the browser seems to switch between the main task and requestAnimationFrame() or requestIdleCallback() and executes them in its "free" time, and everything that does not have time is postponed until the next frame.

Both methods are open, and you can read the documentation to learn more about how they work.

😸What’s next?

You can check the real power of these ideas on one of our DataTable.dev demos and share some suggestions on how to improve it if you have some.

Frames in Web Development | DataTableDev

DataTableDev — Fri, 28 Apr 2023 08:57:55 +0000

In the previous article, we talked about how to give users a sense of direct manipulation over interface elements. We have also highlighted the frame rate of 60 fps and an almost identical frame length of 16.7 milliseconds.

As you can see, our concept is built on the frame and its structure.

Why are frames so important in web development?🚀

We have each frame with a limited time of 16.7 milliseconds to perform various calculations, update styles, rewrite layouts, and render all changes onto the screen. However, the complexity of web operations can sometimes overwhelm frames, causing delays and preventing them from completing their tasks on time.

This can result in frames being dropped or "missing," which appears as glitches on the screen. When frames are delayed or lost, the user experience suffers. The picture on the screen becomes jagged and disjointed, causing distraction, irritation, and a lack of visual appeal. Therefore, maintaining a stable frame rate is crucial for delivering a smooth and seamless UX.

What happens behind the scenes when a frame is dropped?👇🏻

This can happen when complex calculations or tasks requiring significant time and resources are performed. Although the reasons for this can vary, delayed frames can inhibit subsequent tasks, eventually resulting in insufficient time for rendering.

So, frames must adhere to a strict structure to achieve smooth and stable animations. If any task exceeds its allocated time interval and overlaps with another, it displaces all the subsequent parts of the frame. Since rendering is one of the last actions performed, it is often the one to be dropped. The delayed frame then displays an outdated state, and the browser has no reason to show it, leading to missing frames and degraded animation quality.

Moreover, browsers require significant processing power to load and analyze data, especially for larger datasets. Some machines may struggle to handle large datasets, leading to lagging due to overload. On the other hand, loading and displaying data within 100 milliseconds by parts-on-demand can ensure smooth workflow and real-time effect.

Now we are closer to the main question!🎉

How to make sure all the frames are in their places and there is no shift in the actions inside?

These recommendations can help you avoid impacting the visual representation. Most of these points we have successfully implemented in our approach.

Firstly, it's essential to keep in mind that browsers have a lot to do but with limited resources. Therefore, all tasks and actions must be prioritized to ensure everything is done on time.

The second piece of advice is to use every millisecond. This means that loading and calculation processing should be performed during the browser's idle states to optimize spare free time.

Thirdly, rendering should be taken into account, and unnecessary redraws should be avoided. Some actions with the DOM or individual attributes of visual elements may require additional changes to styles and layouts, which takes time and breaks the clear sequence of frames.

Fourthly, it's best to avoid resource-intensive tasks, and if these tasks are necessary, they should be divided into smaller subtasks and performed gradually, considering that the browser still needs time to update the screen and perform other tasks. For example, only go through part of the iterations in one execution of the script, and the rest should be performed in subsequent ones to avoid delaying other steps of a frame.

Lastly, when working with large data sets, it's not necessary to load the whole dataset at once into the browser. Instead, the data should be loaded by parts on demand during runtime to ensure optimal performance.

Each of these small tips can significantly impact the final work of the component and the overall user experience. But how to implement them in life? Well, stay tuned for next articles in this series. And don't forget to test the demo and leave us your feedback!

🫶DataTableDev Live Demo

New grid library for instant big data processing- DataTableDev🚀

DataTableDev — Mon, 13 Mar 2023 19:38:11 +0000

We are happy to present the launch of our new product we've been working on for over a year.

For 14 years, we've been developing components for data visualization and data analytics and noticed a need for a component that can work fast with enormous datasets. We gathered all our experience and expertise to create new technology that easily handles this task. The new approach responds immediately and smoothly to any user interaction, regardless of file size.

We decided to show our technology in the form of a grid, as it's a straightforward but effective instrument to work with data. We also have ambitious plans to develop this technology further and go beyond the grid functionality, but today we want to tell you about DataTableDev.

DataTableDev - is a grid library for instant big data processing🚀

Diving into the topic deeply, we challenged ourselves with a more complex task - to save users' time.

So our goal was to get end-users to access the data instantly despite the volumes, without time spent on reloading data & redrawing the grid each time the user interacts with it.

How did we get there? 🎉

Considering core stages when working with big data - data loading, preprocessing, and then its visualization on the web - we are developing a unique technology that optimizes all these steps and helps not to overlap them.

As stated in multiple studies on how the human brain perceives information when it comes to web-based applications, there are three primary time limits within which the app should respond to user input:

0.1 seconds - people regard it as an immediate action😊
> 1 second - users can spot an intermediary😐
> 10 seconds - people start losing attention😔

So our grid should load, show & interact with gigabytes of data in less than 0.1 seconds.

Well, we did it. And that’s how.🎉👇

When the screen is updated and repainted by the browser, everything is encapsulated in a frame.

The frame rate target is 60 frames per second to be perceived as responsive. Plus, the frames need to be equal in length to ensure a steady frame rate. It helps steer clear of jaggy and rigid animations.

We managed to specify the structure of frames and different behaviors in different situations, define each task's execution time and sequence, and use requestIdleCallback() and requestAnimationFrame() to optimize free time in frames.

But in fact, behind all this work is even greater efforts that we have invested in the server part of the technology. Thoughtful and optimized work with data transfer and operations strongly supports the approach developed on the client side and makes it possible to use it on other software as well.

We are still working on our product, but you already can try a demo showing 11 million rows from a 1,6 GB file with primary grid features that also work instantly. As we developed this product for developers, we are open to your feedback or suggestions that will help us to improve our product further.

If you want to stay updated with our latest news, subscribe to our early-bird list.

Give it a try, and let us know what you think.

Watch about DataTableDev on Youtube