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

231–240 of 240 posts

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

#231

Post by criddell »

zzzcpan wrote: post #212
Derbasti wrote: post #157

Earlier quoted context omitted.

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.

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

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.

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

#232

Post by bazza451 »

criddell wrote: post #101
zzzcpan wrote: post #80

Earlier quoted context omitted.

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

Agree. Baffling how many developers spend 1/4 of their life programming yet are too cheap to spend money on tools...

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

#233

Post by bazza451 »

fletchowns wrote: post #73
meric wrote: post #66

Earlier quoted context omitted.

Sublime Text 3 is a commercial text editor. Atom is free; but I don't want to pay for Sublime Text 3, I had already paid for 2, and I don't like not using the latest...

Two things I feel compelled to mention: You can evaluate it for free, forever, just dismiss the nag screen. The other is, it's easily worth the $80 in my opinion.

Again baffling. yeah I bought it but I feel entitled to version 3 because I had version 2. Development costs money...why not pay for it to support people creating great tools.

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

#234

Post by tomc1985 »

codedokode wrote: post #70
jachee wrote: post #60

Earlier quoted context omitted.

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?

I even think it would be annoying if someone would just move cursor around when I edit something. And there definitely would be conflicts if they would try to edit the file at the same time. Who needs this feature?

Google Docs gives everyone their own cursors

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

#235

Post by rossy »

guessmyname wrote: post #86
asimpletune wrote: post #45

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

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

I don't think that's it. I could definitely manage without having a community around my editor. The only packages I have installed in Sublime Text are syntaxes and colour schemes. Sublime actually supports TextMate syntax for those (.tmLanguage and .tmTheme,) which was a good way to bootstrap a useful editor before it got a community of its own.

If you want linters or code intelligence, there's an emerging editor-agnostic solution for that as well. The guys behind the Language Server protocol[1] realized that making an editor plugin for each language in each editor was inefficient and it slows the adoption of new languages and new editors.

[1]: https://langserver.org/

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

#236

Post by tluyben2 »

KozmoNau7 wrote: post #192
paulryanrogers wrote: post #81

Earlier quoted context omitted.

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.

Sometimes the lack of capability was a good thing, meaning less distractions and more focus on the core functionality. The simplicity of Win3.11 and Win95 was great, and that isn't just rose tinted glasses speaking.

Simplicity yes, but as someone who worked in uni with both 3.11 and Solaris (SparcStation 5), stability wise 3.11 was one of the most frustrating experiences for a user that I ever went through.

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

#237

Post by KozmoNau7 »

tluyben2 wrote: post #236
KozmoNau7 wrote: post #192

Earlier quoted context omitted.

Sometimes the lack of capability was a good thing, meaning less distractions and more focus on the core functionality. The simplicity of Win3.11 and Win95 was great, and that isn't just rose tinted glasses speaking.

Simplicity yes, but as someone who worked in uni with both 3.11 and Solaris (SparcStation 5), stability wise 3.11 was one of the most frustrating experiences for a user that I ever went through.

Sure, and I would like to have the simplicity without the stability issues.

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

#238

Post by cztomsik »

com2kid wrote: post #148
pjmlp wrote: post #137

Earlier quoted context omitted.

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.

> 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

Not for long... This could make rust rewrite feasible https://github.com/nbp/holyjit

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

#239

Post by bradstewart »

TomMarius wrote: post #177
grzm wrote: post #159

Earlier quoted context omitted.

Tastes of course vary, but I find switching to a different app is easier than finding one of a number of windows or tabs within a browser.

Open Slack in Chrome, click browser main menu (the rightmost icon), hover on "More tools", click "Add to desktop". You get exactly the same benefits as you get with standalone Slack client but it still runs inside the browser.

How did I not know this was a thing. Thank you.

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

#240

Post by maximilianroos »

rattray wrote: post #122
nine_k wrote: post #96

Earlier quoted context omitted.

The v8 engine behind Atom is an incredibly efficient compiler, a just-in-time compiler. Without it, all current JS interfaces would be comically slow. The problem with JS is that its execution model is built around highly dynamic features that are hard to compile efficiently. It also lacks a nice type system, though Typescript helps a lot. The problem with Atom performance, I suspect , is mostly with its using a web…

Hmm, VSCode uses a web browser (and I think also the DOM) to display/edit text, and I find it to be perfectly snappy (Atom was unusably slow on my work codebase).

VSCode uses a Canvas layer, which allows it to skip some of the steps that slow down Atom's rendering

https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...

Post reply on HN