Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

51–60 of 240 posts

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

#51

Post by ehsankia »

moosingin3space wrote: post #3

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 bin…

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.

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

#52

Post by tomc1985 »

Prefinem wrote: post #48
PrimHelios wrote: post #42

Earlier quoted context omitted.

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

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.

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?

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

#54

Post by ayyyyylmao »

codedokode wrote: post #25

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

webgl is used to render the text buffer

react/html/css/js is used for extensions and probably menus, etc.

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

#58

Post by Prefinem »

tomc1985 wrote: post #52
Prefinem wrote: post #48

Earlier quoted context omitted.

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.

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?

The irony is that sublime text doesn’t slog down

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

#59

Post by braderhart »

regnerba wrote: post #50
amingilani wrote: post #43

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.

Any reason you haven't tried visual studio code?

Can't speak for op of comment, but everyone suggests this... yes I've tried it and no I really don't want it no matter how many times it is mentioned.

I am happy with Vim for myself now, and am glad that I moved beyond the bloated IDE way of thinking, including Visual Studio Code. Yes, Atom had its shortcomings in that arena, but I'd still prefer to use Atom over Visual Studio, due mostly in fact that the project has contributed more to the community. Microsoft has made a single exception to abandon their native language frameworks and to use a bloated JavaScript jungle of software dependency hell that no one ever audits, in order to build a text-editor in a web browser that performs like Crysis and makes you feel that they are mining cryptocurrencies in some encoded javascript module. Vim on the other hand is pure text editor built in quality-optimized C and comes with pretty much every feature baked in. Atom is created and maintained in large by GitHub, and they have a much better reputation towards open source.

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

#60

Post by jachee »

lpghatguy wrote: post #15
tomc1985 wrote: 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".

I have never, even once, in my nearly-20-year career had the desire to collaboratively edit a single, specific text file.

Isn't collaboration without conflicts what version control systems are made to do?

Post reply on HN