DEV Community: Alexey Boyko

DGRM.net whiteboard / Blocks have become more compact

Alexey Boyko — Thu, 19 Mar 2026 12:53:40 +0000

DGRM.net

Previously, blocks were expanded by 2 cells, now by 1.

DGRM.net whiteboard / You can now set text alignment

Alexey Boyko — Sat, 31 Jan 2026 04:07:04 +0000

You can now set text alignment. Useful for large blocks.

Flowchart editor dgrm.net / Now text fits into shapes automatically

Alexey Boyko — Thu, 17 Jul 2025 14:56:52 +0000

If the text does not fit, the shape is enlarged. Works for all shapes and text.

DGRM.net is the only board with text fitting into figures. Compare text fitting of competitors.

Check it out yourself - DGRM.net

JavaScript. How to Make a Blazingly Fast Multithreaded Data Grid for 1,000,000 Rows. Part 2/2: working with threads

Alexey Boyko — Mon, 05 May 2025 16:02:12 +0000

Demo | GitHub

Fast Data Grid features:

Incredibly Fast
Multithreaded
Only 523 Lines of Code
No Dependencies
Vanilla JavaScript

Try scrolling and searching through 1,000,000 rows — Fast Data Grid.

In this article I will talk about working with threads.

The main idea: to move the search to a separate thread. Show search results in parts as they are ready, without waiting for the search to complete

Long calculations block the UI.

Tasks in a thread are executed sequentially. Until the current task is completed, the next task will not be executed. Processing mouse clicks, scrolling — these are also tasks.

Searching for 1,000,000 lines is long. While the search is in progress, the browser will not respond to user actions. The browser will “freeze”. To eliminate the freeze, you can move the search to a separate thread.

Simply putting the search in a separate thread is not enough. The UI will not freeze, but the search results will also take a long time to display. You need to show the results in parts as they are ready. Fast Data Grid displays the first 100 rows at once. While you scroll, Fast Data Grid searches for the next rows in a separate thread.

Data transfer between threads takes a long time. Only some types of data can be transferred by reference. Such types are called “Transferable objects”

Only the main browser thread has access to the DOM. This means that only the main thread can display the search results. Therefore, the results from the search thread must be passed to the main thread.

Data transfer between threads takes a long time, so transferring an array of grid rows with all the data for display is inefficient.

Only some types of data can be transferred efficiently. These types of data are called “Transferable objects”. Transferable objects are not cloned when transferred between threads, but are passed by reference. Uint32Array is a “Transferable object”. We can use Uint32Array to pass grid row indices.

setTimeout puts tasks at the end of the queue. With setTimeout, you can split a long operation into subtasks and not block the thread

Searching a million lines takes a long time. If the user changes the search string, you need to interrupt the previous search as soon as possible and start a new one. There is no way to interrupt the operation. But you can break the search into subtasks. Between subtasks, check whether the search string has changed.

setTimeout puts a task at the end of the queue. See Listing 1.

setTimeout(_ => console.log(1), 0);
console.log(2);

result
2
1

Listing 1. setTimeout puts tasks at the end of the queue. At first, the console will show 2, then 1.

Listing 2 searches over blocks of 5,000 lines. At the end of the block, setTimeout allows the thread to react to the change in newStr.

export const wait = () =>
    new Promise(resolve => setTimeout(resolve, 0));


await arrForEachChunk(
    data,
    // chunkSize
    5_000,
    // forEachCallBack
    (row, index) => { /* search */ },
    // chunkEndCallBack
    async () => {
        await wait(); // let other tasks go


        if (_str !== newStr) {
            return false; // stop search
        }


        return true; // continue search
    }
);

Listing 2. The search is performed in blocks of 5,000 lines. At the end of the block, setTimeout allows the thread to react to the change in newStr

arrForEachChunk is my utility, it is in the repository.

Self-promotion

I am making the most beautiful flowchart editor DGRM.net.
Check it out yourself.

Give it a star on GitHub.

JavaScript. How to Make a Blazingly Fast Multithreaded Data Grid for 1,000,000 Rows. Part 1/2: The Nuances of Working with DOM

Alexey Boyko — Sun, 01 Dec 2024 06:28:05 +0000

Demo | GitHub

Figure 1. Data Grid with 1,000,000 rows

Fast Data Grid Features:

Incredibly Fast
Multithreaded
Only 523 Lines of Code
No Dependencies
Vanilla JavaScript

Try scrolling and searching through 1,000,000 rows - Fast Data Grid.

In this article I will list the nuances of working with DOM. About multithreading in the next article.

The smaller the DOM, the better. Changing the contents of a DIV is faster than deleting a DIV and creating a new one.

The browser is slow in rendering a large DOM tree. The browser won't render 1,000,000 lines of 20 px height at all - the maximum height of a DIV in Chrome is 15,000,000 px. The fewer HTML elements, the better.

Fast Data Grid adds as many rows to the DOM as will fit on the screen.

const rowsCount = Math.ceil(viewPortHeight / rowHeight);

Listing 1. Counting how many lines fit on the screen

When new data needs to be output, the row DIVs are reused. New data is written to the same DIVs. Changing the contents of a DIV is faster than deleting a DIV and creating a new one.

When scrolling, the position of the DIV rows is calculated using JavaScript.

Maximum DIV height is 15,000,000 px

To make the scroll work, Fast Data Grid makes a big DIV. The scroll event is attached to this DIV. The scroll event handler calculates the position of the row DIVs.

Figure 2. Large DIV for scrolling

If the total height of the rows is more than 15,000,000 px, then the row DIVs should scroll faster than the big DIV. When the big DIV scrolls to the end -> the row DIVs should also scroll to the end.

When scrolling DIV rows, a coefficient must be applied.

const scrollYKoef =
    // if {allRowsHeight} > 15 million -> we have to applay koef on scroll
    // if {allRowsHeight} <= 15 million -> {scrollYKoef} = 1
    (allRowsHeight - viewPortHeight) / (scrolHeight - viewPortHeight);


listen(scrollOverlayDiv, 'scroll', /** @param {Event & {target:HTMLDivElement}} evt */ evt => {
    const scrollTop = evt.target.scrollTop * scrollYKoef;
    rowsDiv.style.transform = `translateY(${scrollTop}px)`;
});

Listing 2. Using the coefficient when scrolling

CSS transform translate is faster than CSS top

When scrolling, the position is set via transform translate. CSS transform translate is faster than CSS top.

<!-- transform faster-->
<div style="transform: translateY(-16px);"></div>

<!-- than top -->
<div style="top: -16px;"></div>

Listing 3. CSS transform translate is faster than CSS top

Read DOM first, then modify DOM. It's bad to read DOM after modification

The browser displays frames on the monitor like this:
First, JavaScript is processed, then styles are calculated, then layout, then rendering.

Figure 3. Standard order of operations when outputting a frame to the monitor

If the standard order is not violated, the browser will render the frame as quickly as possible.

At the beginning of the cycle, the DOM parameters are already calculated and correspond to the parameters of the previous frame. For example, box.offsetHeight is already calculated at the beginning of the cycle. But if you change the DOM and then read the DOM -> the browser will have to break the standard order. It will be necessary to calculate the layout again.

box.classList.add('super-big');

// Gets the height of the box in pixels and logs it out:
console.log(box.offsetHeight);

Listing 4. Modifying DOM before reading DOM. Bad. Leads to layout thrashing.

Excessive recalculation of Layout is called “layout thrashing”.

A visual demonstration of how modifying the DOM before reading slows down the browser:
https://wilsonpage.github.io/fastdom/examples/animation.html

Great article on the topic:
Avoid large, complex layouts and layout thrashing | Articles | web.dev.

Self-promotion

I make the most convenient flowchart editor DGRM.net.
It is also the most convenient service for business: Excel + business process diagrams.

Give stars on GitHub.

Diagramming Tool DGRM.net / Team Subsriptions

Alexey Boyko — Fri, 19 Jul 2024 06:44:31 +0000

Now you can pay your colleagues for a subscription

Pay for exactly as many subscriptions as you need. You can delete your subscription at any time. Flexible setup is better than “subscription packages”.

Flowchart editor dgrm.net / ChatGPT plugin for diagramming

Alexey Boyko — Thu, 16 May 2024 16:14:11 +0000

ChatGPT plugin for diagramming
https://chatgpt.com/g/g-LSaf72err-dgrm-net

Flowchart editor dgrm.net / touchpad gestures

Alexey Boyko — Tue, 19 Mar 2024 06:38:20 +0000

Improved work with the touchpad on laptops.

There is now excellent support for touchpad gestures. With two fingers you can smoothly move and zoom the diagrams.

WebRTC. How to establish a p2p connection between browsers

Alexey Boyko — Thu, 14 Mar 2024 15:31:23 +0000

Fig 1. Simultaneous work in the flowchart editor

WebRTC allows browsers to communicate directly without a server. You can transmit video, sound and data. You can establish a WebRTC connection in different ways. The article describes how a WebRTC connection is established between users of the dgrm.net flowchart editor.

In DGRM, clients do not connect “everyone to everyone”. Events are sent to clients by the browser of the meeting initiator

When a user adds a shape, changes colour, or moves the cursor, event data is sent via WebRTC to the browser of the meeting initiator. The initiator forwards the data to other users.

Fig 2. Clients are not connected “each to each”. Clients send events to the meeting initiator. The initiator forwards events to other clients.

To connect via WebRTC, browsers must exchange connection parameters

When a client connects to an initiator, it must inform the initiator of the connection parameters: connection requirements and its network addresses.

Example of connection requirements: should the connection support video, what codec to use, etc. DGRM only transfers JSON strings.

A client can have several network addresses. For example, one address is on the local network, the other is on the external network. If the client and the meeting initiator are on the same local network, the local network address will be used for the connection. The browser itself cannot find out the address on the external network. To obtain its external address, the browser makes a request to a special STUN server. The STUN server returns its external addresses to the browser. There are free STUN servers, for example from Google.

The connection parameters that the client passes when connecting are called SDPOffer. The meeting initiator generates SDPAnswer based on SDPOffer. And sends SDPAnswer to the client. SDPAnswer contains the network addresses of the initiator.

Fig 3. To connect via WebRTC, the client must pass the SDPOffer connection parameters to the meeting initiator. Based on the SDPOffer, the initiator generates an SDPAnswer and transmits it to the client. After this, the browsers recognize each other’s addresses and a WebRTC connection is established.

Exchange of WebRTC connection parameters via your server

You can exchange connection parameters in different ways. For example, manually via messenger. SDPOffer and SDPOffer are strings. Using JavaScript and the browser API, you can get SDPOffer/SDPAnswer, display it on the page, copy it and send it to the messenger.

v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0 8 97
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 51372 RTP/AVP 31 32
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000

Listing 1. SDPOffer example. SDPOffer and SDPAnswer are strings

DGRM uses its own server to exchange connection parameters.

Fig 4. Creating an online meeting in dgrm.net

When the meeting initiator clicks “Live collaboration”:

The initiator’s browser sends a “create meeting” request with a random meeting id to the DGRM server.
The server remembers the meeting id.
The initiator sends a link with the meeting ID via messenger.
The client follows the link.
The client browser generates SDPOffer. Sends the meeting id, your client id and SDPOffer to the server.
The server remembers SDPOffer.
The initiator’s browser periodically queries the server “give SDPOffers for the meeting id.”
The initiator’s browser, when receiving SDPOffer, generates SDPAnswer. Sends the meeting id, client id and SDPAnswer to the server.
The server remembers SDPAnswer
After a pause, the client browser requests SDPAnswer from the server.
As soon as the client receives SDPAnswer, a WebRTC connection is established.

Fig 5. Scheme for exchanging WebRTC connection parameters via your server

Clarifications to the diagram

Why aren’t websockets used for SDPOffer/SDPAnswer exchange?

Here we use periodic server polls. WebRTC connection is established in a couple of seconds. If you use web sockets or server-events, the WebRTC connection will be established faster. But in this scheme there are fewer requirements for the server.

Why can’t the initiator send SDPAnswer to the client directly via WebRTC?

The initiator received SDPOffer. SDPOffer contains client addresses. Why not send SDPAnswer directly to the client? I don’t know. I could not get. I asked in WebRTC groups, they say this is not possible.

Why is SDPOffer made by the client and not the initiator?

The initiator can make one SDPOffer for all clients. Then the exchange scheme will be simplified. Why didn’t you do so? The initiator must have a WebRTC connection with each client. One SDPOffer cannot be used in multiple connections.

I don’t want to make my own implementation. Are there ready-made solutions?

There are services for developers that not only exchange SDPOffer/SDPAnswer, but also offer a TURN server. If the p2p connection cannot be established, data begins to be sent through the TURN server. TURN is a fallback option.

Flowchart editor http://dgrm.net / images

Alexey Boyko — Mon, 26 Feb 2024 07:12:08 +0000

Now you can add pictures.

You can add pictures by dragging and dropping, using Ctrl + V or with the context menu.

Flowchart editor dgrm.net / Rights for schemes

Alexey Boyko — Mon, 18 Dec 2023 17:43:43 +0000

You can give viewing and editing rights.
Now you can work with common schemes together with your colleagues.

Flowchart editor dgrm.net / DGRM cloud

Alexey Boyko — Tue, 28 Nov 2023 16:12:16 +0000

You can now store charts in the DGRM cloud. To do this, you need to log in to DGRM with Yandex.