Live data from Hacker News

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

github.com

101–110 of 240 posts

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

#101
post #80
post #63

Earlier quoted context omitted.

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

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

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

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

#102

Earlier quoted context omitted.

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

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.

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

#103
post #57

Earlier quoted context omitted.

Let's see if someone able to code complex application only using Notepad.

It's better than Edlin. That was my first text editor.

My first editor was a keypunch.

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

#104
post #46

Earlier quoted context omitted.

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…

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.

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

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

#105
post #46
post #17

Earlier quoted context omitted.

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.

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…

> I always think back to when I had a 120MB hard disk in the early 90s.... 90s me would be absolutely floored by a text editor needing 438MB RAM.

That isn't RAM, that's 438MB of drive space. Even the compressed zip download for Atom is bigger than would have fit on that entire hard drive (Atom 1.24 is 123MB zip download).

Though the RAM usage is pretty close, with no files loaded it was using 360MB RAM here.

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

#106
post #27

Earlier quoted context omitted.

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

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

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.

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

#107

Earlier quoted context omitted.

Firefox has started sucking battery like crazy for me in the last few days, though. Can't figure out what it is.

Are you on a Mac? Had same, but fixed it with some prefs changes. Before that FF was stuck at 8-10% CPU.

YES YES what prefs changes were these? Please share!

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

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

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

#109

Earlier quoted context omitted.

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…

Im probably super out of the loop but I always wonder about these kind of comments. Even if electron uses say 500% more resources than vim, why in the world would that matter beyond personal irritation for anyone making 6 figs doing software development? I get the impression from these arguments that people are trying to do serious software development on 5 year old budget hardware. In any profession, investing in yo…

> I get the impression from these arguments that people are trying to do serious software development on 5 year old budget hardware.

Mac Mini 2012 here, what's the problem? I just don't use bloated text editors or chat apps and it works fine.

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

#110

Earlier quoted context omitted.

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

Are 5k monitors that popular? Do they even exist? I think it makes sense to make editor available on maximum number of platforms. Things like filling rectangles or scrolling have been hardware optimized for years on Windows without using any OpenGL and it works even on ancient graphic cards. So I think it might be a better technology for a text editor.

> Are 5k monitors that popular? Do they even exist?

Yes - for example, Apple has been shipping 5K 27” displays in iMacs for three years now.

Post reply on HN