
Xray – An experimental next-generation Electron-based text editor - seanwilson
https://github.com/atom/xray
======
feep
A 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.

[1] [https://github.com/google/xi-editor](https://github.com/google/xi-editor)

~~~
thinkMOAR
xi editor, when i tried it, would crash upon opening minimised css of
fontawesome

A 3 line file, be it long lines, shouldn't happen

~~~
feep
> A 3 line file, be it long lines, shouldn't happen

No. It should not.

But that’s completely unfair. Xi does not even claim to be beta. I haven’t
touched it in months. But when I did, it was a good (start of) a Mac frontend
that was clearly not finished.

The only people I imagine using it now probably use it to dogfood the backend
and piece together a solid plugin API.

I would prefer Xi-style win the mind share. Native front ends that tie to a
common solid backend that a large community can share to build strong plugin
support.

I’ll settle for xray-style, a better cross-platform frontend that doesn’t
redraw large portions of the DOM quite so often. Javascript is fast enough. A
good (heh) extension language. The drawing layer is what makes Electron a
slow, bloated choice for a text editor.

Since Atom came out, I have had a backgrounded dream that once things settled,
they would write a faster front end for the text. But that is difficult to do
if your API is “can you do it in the DOM with javascript?

But they are atom.io. They can change their API if they need to.

VS Code, with its well-bounded API is a much better candidate. And I would
love to be surprised by a Microsoft skunkworks non-Electron release.

Xi, is a solid idea. Don’t know if they can build a community out of nothing.
I am worried that an API of ”here is a JSON firehose, hook up whatever you
want to it” will fragment the backend.

I think Xi would be well served by saying “Here is your firehose, but, the
official way is our VS Code emulation plugin.” Or something solid and well-
defined.

It is unclear where Xi is going so far, that may happen.

~~~
thinkMOAR
oh yeah, i will give xi another chance, what it didn't crash on it reacted
nicely and fast. But no reason to trade in my sublime text yet :)

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

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

~~~
zero_iq
I always think back to when I had a 120MB hard disk in the early 90s. It
contained multiple editors, raytracers, games, music editors + music, images,
paint programs, multiple programming languages and development kits, a multi-
tasking operating system... and room to spare.

90s me would be absolutely floored by a text editor needing 438MB RAM.

Wait, what am I saying? 2018 me is pretty flabbergasted by it, but perhaps
less surprised (and more cynical) than 90s me.

~~~
paulryanrogers
My rose-tinted glasses are cracked, so I don't want to go back. Software was a
lot less capable back then. And APIs were often incredibly obtuse, bespoke, or
both.

~~~
com2kid
> Software was a lot less capable back then.

Some was.

WinAmp came out in 1997, 2.x was released in 1998. Real time streaming media.

Visual Studio 6 came out in 1998, had most of Intellisense up and running. The
refactoring stuff wasn't there yet, but it could do remote debugging.

The Windows APIs were obtuse, but incredibly well documented.

It'd take a long time before a lot of things we take for granted got
commoditized though. A streaming video player (+ server) was still an idea
that a billion dollar company could be founded on.

It wouldn't have been hard to write a Slack competitor then. It wouldn't have
had streaming video, and the client would have been native, but you could have
gotten 80% of the functionality in there, and watched as people still
complained it was just a fancy wrapper around IRC.

Web forums sucked though. Slashdot figured out the right idea, the entire
conversation loaded at once, one big page, it took the rest of the web a lot
time to catch up.

20 years later, I'm writing code, managing files, and have a chat app or two
open. The monitor is higher res, and a lot larger. Hardware plug and play
finally works, and printing is, on Windows at least, pretty much a solved
problem. (Heck even Wi-Fi network printer works almost flawlessly!)

The APIs for writing code have gotten easier to use, but it seems like
everyone's documentation is now 5, small, steps above garbage. Also APIs break
more often nowadays.

My computer has dozens upon dozens of services running, most of which I don't
know what they are. And individual websites take up more RAM than my entire OS
used to.

That last part isn't even a joke. To load a few paragraphs of text, hundreds
of megabytes of RAM.

It is cool that web browsers can natively play video. 99.9% of the time I
don't want them to. I kinda just want that paragraph sitting in the <div
id="content"> </div> tag.

~~~
TeMPOraL
> _WinAmp came out in 1997, 2.x was released in 1998. Real time streaming
> media._

Related to GP's "Software was a lot less capable back then." \- somehow,
WinAmp 2.x seems to be peak capability of music players; I don't recall any
player made later that would be comparable in features for playing local music
(with maybe the exception of Foobar2000).

My rose-tinted glasses have some scratches on them, but I still maintain that
software of today didn't gain many meaningful features over the late 90s /
early 2000s, and yet it grown tremendously in size and resource use.

~~~
KozmoNau7
WinAMP 2.x was nothing short of a miracle, it was a revolution in audio
players. I wasn't a huge fan of the skin-based interface, and the playlist did
some odd things once in a while, but on the whole, it was a damn good piece of
software.

These days I'm using Foobar2000 and Quod Libet, and have looked at other
"music library" type apps, but I'm considering just going with a simple player
such as DeaDBeeF, and handle everything else through the file manager, since
I've taken the time to properly plan the folder layout. I don't need ratings
or playback statistics or all kinds of other things. I need a simple playlist
to add music to, with basic playback controls. If I need to add tracks, I'll
drag and drop from the file manager.

Basically, I don't need in-between applications between simple WinAMP 2.x
style and the all-singing all-dancing streaming services such as Spotify, that
do a much superior job with ratings and especially smart playlists.

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

[1]: [https://github.com/Boscop/web-view](https://github.com/Boscop/web-view)

~~~
ehsankia
I've been waiting for a proper web editor that allows me to easily access my
configured workspace anywhere easily. c9 and a few other web IDEs come close
(though that former one is in the hands of Amazon now...), but I want
something simpler and more lightweight, similar to Sublime Text.

~~~
suprfnk
SSH into a box with tmux and vim? Or is that too minimal?

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

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

~~~
saagarjha
Sublime Text is written in C++. Not sure how much closer you can get to
"optimized native code" than that.

~~~
com2kid
All the best, highest performance AAA games have been written in C++.

So have all the slow, under-performing, crash prone, unoptimized AAA flops.

C++ isn't a magic bullet that gives instant speed. Indeed a long running
native app that isn't properly written, will fragment the heck out of memory
and get slower and slower. (With 64bit address spaces, at least they don't
crash now days!)

The choice of algorithms and data structures is of utmost importance.
Optimizing around one's run time is choice #2. C++ doesn't provide some magic
hyper optimized environment. Heck C++ doesn't provide much of anything. You
need to build a threading model and concurrency model that works, and performs
well on different platforms. File I/O performance is different based on the
file system in use, NTFS for example hates lots of small files, other file
systems have less issues with that usage model.

This goes on and on and on. With C++, every decision has to be made, and each
one of those decisions can, if made incorrectly, lead to a poorly performing
app.

~~~
pjmlp
A badly written C++ application will still be faster and consume less memory
than anything written in JavaScript.

C++ has a defined threading model and libraries since 2011.

~~~
com2kid
> A badly written C++ application will still be faster and consume less memory
> than anything written in JavaScript.

JavaScript engines are written in C++. :-D

~~~
cztomsik
Not for long... This could make rust rewrite feasible
[https://github.com/nbp/holyjit](https://github.com/nbp/holyjit)

------
Derbasti
So, they replace backend JS with rust, and frontend DOM/CSS with WebGL. Then
all that's left of Electron is the V8 JS engine for scripting.

For the desktop, they could cut out Electron entirely and replace it with V8
and some minimal OpenGL bindings. I wonder how that would improve performance!

~~~
Corrado
I was just thinking that this effort is a real departure from the earlier
stuff. The original Atom project was to build a text editor using the core of
a web browser to do all the heavy lifting and use web technologies (HTML, CSS,
JS) to provide the GUI.

It looks like this latest effort is ditching most of the web browser stuff,
and some of the web technologies to build something performant and extensible.
Just like Sublime Text (and others). Have we come full circle?

~~~
sbarre
Could we look at it as putting out an MVP to drive adoption and get community
feedback on what matters to developers and how they want to use it, and now
that they know exactly what they want to build, they are re-factoring and re-
building to that?

I feel like the original Atom, as you described, was almost the internal
prototype that got out in the wild, and now we're going to get the production-
ready one eventually..

------
giancarlostoro
It's funny they want to rewrite some of the core functionality in Rust and
make it available through an N-API binding. I've mentioned on HN (and gotten
plenty of hate for it) that another approach to gain performance with Electron
is to use a back-end language to serve up a local web page, I can only imagine
just using a Rust or D web framework that can handle heavy data traffic, only
running on 127.0.0.1 serving up some of the content the Editor (or whatever
application) needs and doing some heavy lifting from Node itself. In fact I
think there's already an open source mail client I don't remember the name
that does this, it feeds Electron from a Python back-end, would not surprise
me if they're doing pretty well performance wise, let back-end people do their
thing, and let front-end people do theirs. Of course things will also get
interesting whenever WebAssembly becomes another way to build an Electron
application (really can't wait for WebAssembly to become totally mainstream).
If my website had half of the stuff on the front-end that my back-end is
supposed to handle yeah people would call me out for shoving so much into the
DOM / front-end and suggest I offset some of the heavier stuff into the back-
end.

Long before Electron I saw applications that ran on localhost in your own
browser (think SlickBear, CouchPotato and Headphones) and they were highly
responsive regardless of browser used! They were all coded in Python too, so I
can only imagine if some of those native API's could just be done as a web api
instead to keep things simpler, then you just need to identify a REST
framework to handle some of those things. Anyone could add on to a RESTful API
for the editor / call said API as well, though it should be locked down
securely for obvious abuse reasons.

I used to like the idea of taking nw.js and making something like Atom (before
it was even a thing) but using D as a back-end language for it, but never
really got through doing it. Ah well.

Edit:

I also find it funny they're ditching CSS for JavaScript when Firefox redid
their CSS engine in Rust. I have to wonder if and when Electron will deviate
from Chrome altogether and become it's own forked browser engine, but maybe
that's a thought a bit ahead of it's time.

------
hartator
Looking for some advice.

I want to build a text editor where git history is displayed as first class
files directly in the file tree. Like a page named landing.html would have
landing.html.v0, landing.html.v1, landing.html.v2, etc. directly as regular
files. With maybe the git commit message also in the file name for more
context.

What would be the best way to make this happen? Build an app from scratch with
something like Electron? Build an extension for an existing text editor like
Sublime, VSCode, or Atom?

~~~
klibertp
Get Emacs and Neotree[1] and start hacking. You'll learn a Lisp, and you'll
have a working demo in under a week.

[1] [https://github.com/jaypei/emacs-neotree](https://github.com/jaypei/emacs-
neotree)

------
adambrenecki
Here's something that's buried right at the bottom, but sounds really
exciting:

> More concretely, our goal is to ship a high-performance standalone editor
> component suitable for use in any web application, something we could
> eventually use on GitHub.com. This standalone editor will give us a chance
> to test a limited set of critical features in production scenarios without
> building out an entire desktop-based editor. We plan to develop this new
> editor in the context of a prototype Electron application, but we'll offer
> the standalone component as a separate build artifact from the main app.

~~~
polskibus
What about MS Monaco, that's used in VS Code? I heard it's very good compared
to atom, VS Code Is receiving much praise on HN.

------
13years
>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

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

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

~~~
qarioz
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](https://github.com/servo/servo/wiki/ACID2-Status)

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

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

~~~
codedokode
Is it really so? Can OpenGL update only a small part of a framebuffer (for
example, when a single letter is typed) or will it rerender the whole text?

~~~
zaarn
Depends on how you render.

I've written a OpenGL engine for a university course that use partial frame
updates to reduce the number of redraws per frame.

IIRC the partial rerender variant was about 3 times faster than the full
render.

------
asimpletune
Why doesn’t someone make a better native editor? (That’s not sublime)

~~~
guessmyname
> _Why doesn’t someone make a better native editor?_

I can make it.

In fact, there are many native text editors out there.

The problem is not creating the editor itself but the community around it. If
your editor doesn't supports the most common/basic plugins like linters,
debuggers, painters, formatters, code intelligence, etc then it becomes
another one in the pile.

Atom became the popular piece of software that is today because of the
JavaScript community. Hundreds of high school, college and university students
with several hours of free time during the week, writing code in a language
that overflows on the Internet, to extend the functionality of a program baked
by one of the most popular companies among software developers [GitHub]. This
is the type of community that you need to build around your editor in order to
make it popular.

Take a look at TextMate [1] which used to be one of the most popular code
editor with a graphical interface for Mac years ago. It was open-sourced [2]
after its developer put it in maintenance mode. And while it is still being
maintained today, not many people are well versed in C++ and Objective-C to
contribute to the project at the same speed as a JavaScript programmer would
do with Atom.

[1] [https://macromates.com](https://macromates.com)

[2]
[https://github.com/textmate/textmate](https://github.com/textmate/textmate)

~~~
nurettin
>> Hundreds of high school, college and university students with several hours
of free time during the week, writing code in a language that overflows on the
Internet

Citation definitely needed.

------
asdjlkadsjklads
I love new editors, but i have to ask every time - what is this one doing new?

I'd kill for new editors trying new and interesting methods of text _(or
code)_ navigation and editing, but so often i don't feel like i see...
anything, new. The only one i can recall offhand is Kakoune, which is
basically Vim-like but changes the verb order a bit. It's a nice attempt, i
like it.

Yet with things like Atom, Xi, Xray, i don't get what they're doing special?

I totally get that focusing on easy plugins could be a major selling point.
I'm not disputing that or ignoring it. I'm merely trying to.. well, i guess
understand, why so many new editors pop up but don't try anything new. They
just try.. speed, generally.

Am i alone here? I want more Kakounes of the world.

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

~~~
moosingin3space
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?

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

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

~~~
PrimHelios
That sounds like an OS/hardware problem, honestly. There's no reason vim with
_any_ setup should lock up a machine.

~~~
Prefinem
The linter was the issue.

I actually have better performance with Sublime Text and JavaScript than I do
with vim and JavaScript. I wish that weren’t the case.

If you know if any better ways to get vim working with Syntastic for linting
(eslint), I would love to know.

~~~
tomc1985
Agreed, if anything will slog a text editor it is usually the linter

Also, you can choke vim with large (>5gb) test files. Or is that fixed now?

~~~
Prefinem
The irony is that sublime text doesn’t slog down

~~~
Turing_Machine
Sublime Text and TextMate will both choke big time if you feed them a large
enough file without any line breaks. I have some largish machine-generated
(5-10 MB) JavaScript data files that will reliably bring either editor to its
knees if I accidentally click on one of them. The XCode editor also chokes.

I seem to recall (though haven't tried it for a while) that the Visual Studio
Code editor handles them okay.

It's not a big issue -- since these are machine-generated, it's not normally
necessary to edit them by hand. Every once in a while, though, I'll
accidentally click on one of them in the file tree. Then I'll curse and kill
the editor process.

------
dikiaap
raphlinus said that many of the design decisions are similar to xi.[1]

[1]
[https://www.reddit.com/r/rust/comments/7qszkz/xray_an_experi...](https://www.reddit.com/r/rust/comments/7qszkz/xray_an_experimental_nextgeneration_electronbased/dsrpg63/)

~~~
bronson
They're talking:

[https://github.com/atom/xray/issues/4#issuecomment-359483293](https://github.com/atom/xray/issues/4#issuecomment-359483293)

~~~
raphlinus
Indeed. I'm open to the idea of even joining forces, but if the goal is to
explore technology choices, it does make sense for them to do their own thing.
In the meantime, xi is making progress, and I think will be a pretty viable
choice for people who prefer native to Electron.

------
wasx
Another next generation Electron-based editor? What generation are we at now?

~~~
imron
Infinity + 10

------
qwtel
I didn't see it mentioned in the docs, but I assume the idea is to compile the
rust core to webassembly to make this web-compatible?

------
amingilani
I always felt like the Atom team should scrap their work and start afresh. I
love Atom, and have used it as my primary editor since its inception, but it's
been the worse performing text editor I've ever encountered.

I almost switched to Vim a few months ago, but the impact to my performance
was too high for me to keep it up for long enough.

I'm definitely going to be using Xray the moment it becomes stablish.

~~~
s4vi0r
...why not sublime?

I don't understand why these electron editors are popular at all. With all due
respect to the people working on them (because it really isn't their fault for
the most part), they're bloated slow pieces of shit. I don't like electron in
general, but its an especially bad choice for a text editor intended for
developers.

If you don't like vim or emacs, sublime does what the electron editors do but
better. Its probably the most performant of all the text editors I've used;
vim and emacs both don't like gigantic logfiles, but sublime handles them
without issue. The only bad things I can say about it are lacking vim
emulation and worse dev experience than Emacs. But then again, I've never used
an editor anywhere near as nice as Emacs in terms of language integration for
a lot of the languages I work with.

~~~
zzzcpan
> I don't understand why these electron editors are popular at all.

I would like to understand this better too. I'm guessing vim and emacs take
too much time to learn, since they drag the whole unix ecosystem with them.
Sublime might be a decent easier to learn editor, but it's a non-free product
that could disappear one day, you have to go through the hassle of buying it
and it's expensive one too. So sublime is not even a choice for most people.
This leaves us with electron based editors as an acceptable choice. But
obviously bloat, performance still matter and people will choose something
better if available.

~~~
criddell
> it's expensive one too

It's $80. If you work in text all day, then that's practically nothing.

It's kind of disheartening to see how little value people place on excellent
software.

~~~
Derbasti
That's easy for you to say, as a (presumably) rich American developer. It's a
different story in, say, India or Africa, or students or poor folks. $80 can
be several days or weeks of sustenance.

~~~
zzzcpan
True. Most of the world cannot afford to pay $80 for a text editor.

~~~
criddell
We're lucky that there are lots of excellent text editors available for free.
People that can't afford $80 for a text editor aren't really disadvantaged.

Tools generally cost money. Most people can't afford welding equipment but if
you want to be a welder, you need it.

