Live data from Hacker News

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

github.com

31–40 of 240 posts

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

#31

Also, I noticed that it requires WebGL so without modern and supported by WebKit graphic card it won't work. Why is OpenGL necessary for a text editor? I don't understand.

> Why is OpenGL necessary for a text editor?

Why not? Modern desktops are all hardware-accelerated anyway.

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

#33

Also, I noticed that it requires WebGL so without modern and supported by WebKit graphic card it won't work. Why is OpenGL necessary for a text editor? I don't understand.

consider how many pixels a 5k monitor has.

try drawing a 5k monitor full of true type fonts in software sometime.

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

#34

Also, I noticed that it requires WebGL so without modern and supported by WebKit graphic card it won't work. Why is OpenGL necessary for a text editor? I don't understand.

Hardware acceleration of rendering is more energy-efficient and less resource intensive than CPU-based software rendering.

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

#35
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…

Ahaha hahahahaha ‘wag their dicks..’ hahahahah

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

#36

Also, I noticed that it requires WebGL so without modern and supported by WebKit graphic card it won't work. Why is OpenGL necessary for a text editor? I don't understand.

consider how many pixels a 5k monitor has. try drawing a 5k monitor full of true type fonts in software sometime.

no need to be aggressive dude, op was just askin'

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

#37

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.

Check out Textadept. It's an editor written largely in Lua.

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

#38
post #11

Earlier quoted context omitted.

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?

Unfortunately it's not very good. Sometimes it works, sometimes there's regression. Acid2 is still broken sometimes.

https://github.com/servo/servo/wiki/ACID2-Status

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

#39

Earlier quoted context omitted.

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...

You may be committed to dying on this hill, but keep in mind that corpses left behind stink up the place. Please have a care.

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

#40

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?

On windows my current cygwin session with tmux and a single markdown document open in vim is about 25MB. Some of my chrome tabs (jira is the most complicated thing open) are nearing 200MB, somehow outlook is taking about 500MB and Visual Studio is eating many GB's.

It's extraordinary how wasteful some apps can be.

Post reply on HN