The Monaco Code Editor

I understand that Atom is doing a lot, but if you need 16 GB of RAM to run your text editor, this simply means that the developers have not been using the right data structures to manage the state of the application or maybe the new code editors have an implementation of an AI coding for you so you can outsource yourself.

I had no issues whatsoever.

Interestingly enough, Atom seems to really struggle on my Windows laptop, it's often incredibly choppy. It actually runs better in a Linux VM than natively on Windows.

In what kind of world is that a sensible metric to decide if a function can be inlined?

I've actually never tried to compute a diff and apply it inside a line, maybe I'll try it tomorrow :). A line is basically a list of spans, each having a certain class name and a certain text content. I've just always assumed that iterating over the previous spans, adjusting their class names, adjusting their text content, appending new spans or removing extra left overs would be slower than a big fat innerHTML call (given that each dom read/write access leaves the JS VM and I always thought there's a certain penalty associated with each dom call). But I will definitely try it out!

Here is what we do now - https://github.com/Microsoft/vscode/blob/master/src/vs/edito...

[It might not be the best method, but it was guided by measuring]:

* if there is no overlap between frames (e.g. you jump to a completely different location), the whole thing does a single innerHTML call

* otherwise:

* all the old lines that leave the viewport are removed via multiple domNode.removeChild

* all the new lines that enter the viewport are added via a single domNode.insertAdjacentHTML

* all the old lines that have changed are parsed in one single off-dom innerHTML and then cherry picked via multiple domNode.replaceChild

That is what I could come up with in my attempts to minimize the count of dom calls and not pay for reparsing/repainting the entire viewport on each frame. Maybe there are better ways?

If I remember correctly, we ended up not using native browser scrolling for multiple reasons:

* [if we would not set scrollTop ourselves] the browser would just happily jump to a certain scrollTop, painting nothing (white), then we'd get an `onscroll` and we'd be able to paint the lines. But you'd always get this white flash.

* if we would set scrollTop ourselves:

* AFAIK setting the scrollTop causes a stop the world sort of synchronous layout - I don't know why

* We wanted to have an overview ruler that sits inside the scrollbar and highlights things (find matches, diffs, etc.)

* IE has or had a limit around 2.5M px. That meant we would have had to do something special anyways around 80.000 lines @ 19px line height

The scrollbars are custom implemented (https://github.com/Microsoft/vscode/tree/master/src/vs/base/...). Quick tip: do not implement custom scrollbars.

PS:

Some anecdotal evidence I got that making less calls with larger chunks of data might be better was when I was investigating why creating an editor buffer was slow for very large files (100k+ lines). One of the first things the model (buffer) code did was to split the text into an array of lines.

I implemented this as any sane person would, with a nice for loop, iterating over the string, grabbing the character code at each offset and checking if it was \r or \n or a \r followed by a \n. I would then remember the last cut off index and do a simple substring to extract each line, building an array of lines. I thought that must be the best way one could possibly do this (I don't know a better way than a for loop even in C++).

If I remember correctly, that was taking 50ms in some browser for a pretty large string. I replaced that simple for loop with a lame split with a regex! - /\r\n|\r|\n/ - and the time dropped to 3ms. I can only think that looping in C++ must be a lot better than looping in JS [here's the code today - https://github.com/Microsoft/vscode/blob/master/src/vs/edito...]

And obviously creating issues on the github repo for things you're missing is a big help for me. I try to have a fast turnaround on these things.

I'm ok with whatever browser works for him, and I will choose whatever browser works for me if IE/Chrome/Firefox does not perform optimally to my own standards.

Perhaps one token screenshot to get the message across isn't a bad idea, especially if everything else is chrome - webdevs sometimes seem to think chrome is good enough for everyone, and if there are compat issues in modern sites, it tends to be due to chrome-specific design (IME, but I bet if you've got a particularly windows or apple focus things may be different).

[1] https://en.wikipedia.org/wiki/Principal–agent_problem

Startups can merely fully dedicate themselves to exploring new spaces that open up because they're not burdened by things such as being already occupied with doing something, especially something that's profitable.

So when something new appears like VR/AR a startup can jump right in at first opportunity without having to think too much about it. This has the potential to be an advantage and means that startups are "faster" (really just earlier) to certain things.

Github is a profitable business that has nothing to do with editors, so I'd argue that it's not a startup anyway, certainly not in any far that gives them advantage in developing editors or IDEs.

Quite frankly I really don't get why they even bother. It doesn't differentiate their actual business in any useful way and it doesn't make money. In the meantime they're actually facing competition from Gitlab, a company that's adding features so powerful you can and other people have build entire business around them.