Live data from Hacker News

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

github.com

11–20 of 240 posts

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

#11
post #4

>Bypassing the DOM means that we'll need to implement styling and text layout ourselves I really wish the Servo technology was available in something like Electron which would make this unnecessary

Servo is actually modular, and most of it is available as Rust libraries including the layout and rendering engines. There is not a full electron like solution available yet though.

And how easy is to actually to incorporate in other projects?

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

#12
post #6

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

If you edit files once in a blue moon, `notepad.exe` is more than sufficient.

If you work with hundreds of files per day as part of your profession, you are going to want something a bit better. I wouldn't call it over engineering if it solves a real problem.

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

#13

I've always felt like the inevitable conclusion of Atom and other electron based apps is the reversion to using low level compiled languages. I'm starting to get tired of how much of a resource hog Atom is.

If it weren't for the oddness of the language, Lua would be a perfect fit. Near-C speeds, super flexible, no recompiles. You'd lose type safety compared to Rust, but they don't have that with JS now anyway. I don't think the majority of the memory consumption is from JS though, moreso the embedded browser+DOM approach. Edit: Blaming electron for bloat more than JS.

> embedded browser+DOM

And also Node.

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

#14
post #6

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

If you edit files once in a blue moon, `notepad.exe` is more than sufficient. If you work with hundreds of files per day as part of your profession, you are going to want something a bit better. I wouldn't call it over engineering if it solves a real problem.

That hasn't been solved before, a thousand times over, by people who frequently like to coalesce into cliques that represent their choice...

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

#15
post #9

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…

Editing large pieces of text efficiently is a Hard Problem, especially collaboratively without conflicts.

In the case of editors like Xi and XRay, they use CRDTs, which doesn't look anything like how Notepad would represent text.

There's real work here that's actually useful, it's not just "another extensible text editor".

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

#16

I've always felt like the inevitable conclusion of Atom and other electron based apps is the reversion to using low level compiled languages. I'm starting to get tired of how much of a resource hog Atom is.

Agreed.... running Slack + Atom + Chrome is enough to kill a I'm on emacs and firefox for good.

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

#17

I've always felt like the inevitable conclusion of Atom and other electron based apps is the reversion to using low level compiled languages. I'm starting to get tired of how much of a resource hog Atom is.

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.

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

#18
post #17

I've always felt like the inevitable conclusion of Atom and other electron based apps is the reversion to using low level compiled languages. I'm starting to get tired of how much of a resource hog Atom is.

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?

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

#19

I've always felt like the inevitable conclusion of Atom and other electron based apps is the reversion to using low level compiled languages. I'm starting to get tired of how much of a resource hog Atom is.

Agreed.... running Slack + Atom + Chrome is enough to kill a I'm on emacs and firefox for good.

Firefox has started sucking battery like crazy for me in the last few days, though. Can't figure out what it is.

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

#20
post #9

Earlier quoted context omitted.

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…

Editing large pieces of text efficiently is a Hard Problem, especially collaboratively without conflicts. In the case of editors like Xi and XRay, they use CRDTs, which doesn't look anything like how Notepad would represent text. There's real work here that's actually useful, it's not just "another extensible text editor".

Yay, new products for a few bulletpoint features.

Not to discount the technical chops of the work they are doing, CRDTs sound sufficiently fancy.

But as long as it touches Electron, they are building on a foundation of mud. Popular, pretty mud, sure, but mud nonetheless.

Post reply on HN