>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.
Xray – An experimental next-generation Electron-based text editor
11–20 of 240 posts
Re: Xray – An experimental next-generation Electron-based text editor
#12How disappointing that text editors require such... abstraction. Overengineering at its finest?
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
#13I'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.
And also Node.
Re: Xray – An experimental next-generation Electron-based text editor
#14How 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
#15Earlier 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…
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
#16I'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
#17I'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
#18I'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
#19I'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
#20Earlier 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".
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.