Xray – An experimental next-generation Electron-based text editor
1–10 of 240 posts
Re: Xray – An experimental next-generation Electron-based text editor
#2A higher performance backend with the undeniable community momentum that Atom has?
I want this to work.
Also excited to see the discussion and possible cross-pollination with Xi[1] and raphlinus.
Re: Xray – An experimental next-generation Electron-based text editor
#3The strategies being employed here look similar to those of xi (CRDTs for multithreaded buffer representation) and neovim (separable backend and frontend). This is definitely a project I'll be keeping my eye on.
Another thing that's interesting is that if they're targeting a web-embedded editor (mentioned as a goal), they could possibly reduce the need for a full Electron install, possibly using the Rust web-view bindings[1] to link with the system web engine.
Re: Xray – An experimental next-generation Electron-based text editor
#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
Re: Xray – An experimental next-generation Electron-based text editor
#5I'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.
Re: Xray – An experimental next-generation Electron-based text editor
#6How disappointing that text editors require such... abstraction. Overengineering at its finest?
Re: Xray – An experimental next-generation Electron-based text editor
#7>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.
Re: Xray – An experimental next-generation Electron-based text editor
#8How 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?
Re: Xray – An experimental next-generation Electron-based text editor
#9How 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?
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 the hard parts in Rust instead :/
It would seem Electron adds far more complexity to projects than its adopters are lead to believe.
Perhaps I am biased against Electron and web-tech-on-the-desktop but there are far better ways to skin this particular cat, to say nothing of the fact that it has already been skinned a thousand times before.
Does the world really need another extensible text editor?
Re: Xray – An experimental next-generation Electron-based text editor
#10I'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.