Rendering text to screen such that it is editable seems to me to be a delicate operation. Usually this is not a big deal for good text editors with small amounts of text upto even 8MB as modern processors have gotten faster and more efficient. However, this starts posing a problem the moment a huge amount of text warrants rendering.
Case in point, the classic Windows Notepad perhaps does not implement chunk by chunk loading and tries to load the entire file text content and send it to render all at once, causing GUI thread block even on moderately sized files.
If one were to read file via a buffer, and on each read send that text to render and clear the buffer itself for the next read, it becomes noticably faster, and RAM efficient - and if the process is run on another thread, the GUI won't even block and the whole thing is much smoother.
I would think to enter some text in the middle of a bunch of text in some GUI textarea of some sort, the under the hood implementation would be some form of memmove to shift the right side content to make space while only updating the visible section on the screen. Is this somewhat a correct idea?
In case of HTML and JavaScript though (for example in a textarea), some people usually perform a string division, append the content to the first part, then append in the last part and set the entire resulting string = to textarea.value which seems heavily inefficient on the surface.
Is this process for browser text updates as inefficient as it appears to me? Do browsers implement these direct assigning to internal HTML internally?