Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Xray – An experimental next-generation Electron-based text editor

github.com

Post reply on HN
Print view View original

21–30 of 240 posts

Re: Xray – An experimental next-generation Electron-based text editor

#21

Post by bluedino »

moosingin3space wrote: post #8
tomc1985 wrote: post #6

How disappointing that text editors require such... abstraction. Overengineering at its finest?

Every text editor beyond the most basic is incredibly complex. Terminals are a complete mess, so every terminal-based text editor certainly can't be called "simple", and that's not even beginning to consider extensibility! Emacs and Vim have entire interpreters embedded into their codebases, for instance. Maybe text editors with an extensible feature set really are more complex than we've been led to believe?

What's the memory footprint of Terminal.app and vim + plug-ins?

Re: Xray – An experimental next-generation Electron-based text editor

#22

Post by bluedino »

tomc1985 wrote: post #9
moosingin3space wrote: post #8

Earlier quoted context omitted.

Every text editor beyond the most basic is incredibly complex. Terminals are a complete mess, so every terminal-based text editor certainly can't be called "simple", and that's not even beginning to consider extensibility! Emacs and Vim have entire interpreters embedded into their codebases, for instance. Maybe text editors with an extensible feature set really are more complex than we've been led to believe?

A longer version of my first comment originally admitted that Notepad's tech stack probably looks a lot like Xray's.... But then I would bet the Notepad engineers didn't wag their dicks on a blog post telling the world how special they are because they figured out how to make the Win32 message pump performant.... I'm happy they're finally treating Electron performance seriously... oh wait, they aren't! Just writing t…

>> Does the world really need another extensible text editor?

People said that when Sublime was released

Re: Xray – An experimental next-generation Electron-based text editor

#23

Post by Prefinem »

bluedino wrote: post #21
moosingin3space wrote: post #8

Earlier quoted context omitted.

Every text editor beyond the most basic is incredibly complex. Terminals are a complete mess, so every terminal-based text editor certainly can't be called "simple", and that's not even beginning to consider extensibility! Emacs and Vim have entire interpreters embedded into their codebases, for instance. Maybe text editors with an extensible feature set really are more complex than we've been led to believe?

What's the memory footprint of Terminal.app and vim + plug-ins?

Not sure, but I have had vim lock up my MacBook Pro with 16GB of RAM and force me to do a hard reboot

Re: Xray – An experimental next-generation Electron-based text editor

#25

Post by codedokode »

> For all interactions, we shoot for the following targets on the hardware of our median user:

> 8ms Scrolling, animations, and fine-grained interactions such as typing or cursor movement.

I don't believe that. Either they use expensive powerful hardware or they measure performance only on start with empty documents. Because even Sublime Text starts lagging after long use and typing several pages of text. There is no way HTML page can be faster than optimized native code.

Especially with React (which adds even more overhead and which was never made for high performance) and these weird ideas:

> a CSS-in-JS approach that automatically generates atomic selectors so as to keep our total number of selectors minimal.

Re: Xray – An experimental next-generation Electron-based text editor

#27

Post by fwip »

codedokode wrote: post #25

> For all interactions, we shoot for the following targets on the hardware of our median user: > 8ms Scrolling, animations, and fine-grained interactions such as typing or cursor movement. I don't believe that. Either they use expensive powerful hardware or they measure performance only on start with empty documents. Because even Sublime Text starts lagging after long use and typing several pages of text. There is no…

Sublime Text isn't necessarily "optimized native code."

Re: Xray – An experimental next-generation Electron-based text editor

#28

Post by wmf »

paultopia wrote: post #18
ahtu123 wrote: post #17

Earlier quoted context omitted.

I'm always amazed when I see the size of the Atom executable on my computer(438MB). It's the size of a game! It's also pretty much the worst performing text editor (in runtime for most operations) and a memory hog. I really don't get the hype.

Yeah, I wonder about how this Rust thing is going to work. I had always thought that the Atom perf problems didn't come from the underlying language but from the fact that it basically creates a massive DOM for every document... so how much is changing the backend language going to achieve?

They're also using WebGL instead of creating a massive DOM for every document. There are three kind of unrelated things here: Rust, CRDTs/collaboration, and WebGL so it may be hard to disentangle where the performance gains are coming from.

Re: Xray – An experimental next-generation Electron-based text editor

#29

Post by codedokode »

fwip wrote: post #27
codedokode wrote: post #25

> For all interactions, we shoot for the following targets on the hardware of our median user: > 8ms Scrolling, animations, and fine-grained interactions such as typing or cursor movement. I don't believe that. Either they use expensive powerful hardware or they measure performance only on start with empty documents. Because even Sublime Text starts lagging after long use and typing several pages of text. There is no…

Sublime Text isn't necessarily "optimized native code."

It is faster than all other editors I've used, especially startup time and scrolling smoothness. So I think it is optimized.
Post reply on HN