I'd take the overhead of a client-server architecture over the overhead of rendering the whole UI in HTML (electron apps) any time.

Also I think that the marshalling you need for IPC is not so different than the boxing and conversion that you have under the hood if you write in an interpreted language, e.g. Python or JavaScript.

I was 100% in your boat after experiencing Atom. I have a 8 year old re-purposed Linux box (OpenSUSE) for work. That took a LONG time to be okay with our Windows based IT Department.

I changed my mind over two electron editors/IDE. I use RStudio and it is really been getting so fast on my old computer that I can't tell anymore. VS Code by Microsoft is so fast and nimble that I have been using it 75% of the time with no felt overhead. It really is an amazing piece of software in terms of speed, now the ram usage is still much higher but for my uses I don't notice it at all on my 8 year old Dell corporate computer.

Serialization alone is like, at least one order of magnitude slower than dynamic typing, and IPC has other os-specific overheads on top of that. Remote calls are so costly the whole architecture of a system has to be designed with them in mind.

> I'd take the overhead of a client-server architecture over the overhead of rendering the whole UI in HTML (electron apps) any time.

It's not an either/or problem though.

It's important to note that here the client server architecture is asynchronous and multiple. This allows it to actually decouple slow interactions as auto-completion from things that need low latency such as typing.

You actually see this in many IDEs that more features make editing feel more sluggish. This shouldn't happen with this structure.

> It's important to note that here the client server architecture is asynchronous and multiple.

Both can (and have) been achieved without a client server architecture.

Is auto completion really useful, if it's a lot slower than the rest of the program? Maybe if a part is too slow, you should either optimize it or get rid of it?

Well, considering that as far as developer tools are concerned many of the best sellers are IDEs with Intellisense (intelligent code completion, based on syntax and semantics)...

Sometimes you want the autocompletion, sometimes you don't. You can do it in synchronous style, where you have 2 choices: a) delay the typing when the user doesn't care about the autocomp, b) require an extra action to activate autocomp when the user wants it.

You can also do it async style and have neither of the drawbacks - if the user types too quickly, the autocomp just doesn't show up.

What is the performance overhead like? I can't access the app right now but I'd be highly surprised if it caused a noticeable input latency.

Or are you talking out of your ass?

It's a whole lot of unnecessary serialization and deserializtion, even if the performance is not noticeable it's a waste of cpu cycles.

From looking at similar projects, overhead tends to be in the millisecond range per call, so performance depends on the ammount of back and forths.

Add in all the overhead for serialization and IPC and in practice it looks a lot like the round trip in same data center latency here:

https://people.eecs.berkeley.edu/~rcs/research/interactive_l...

> even if the performance is not noticeable it's a waste of cpu cycles.

If the performance hit is not noticeable, nobody really cares about the waste of CPU cycles. Especially since a text editor uses something like 1/10 the resources a large, complex program uses anyway.

Well, you would care if you're on a battery for any appreciable amount of time.

Some IDEs go as far as to offer low power modes where they throttle external plugins.

And when everyone thinks that we end up with the same performance we had 20 years ago on vastly improved hardware.