Live data from Hacker News

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

github.com

131–140 of 240 posts

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

#131

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

Vim? Emacs? Anything from jetbrains (although technically that's an IDE)?

How much of Jetbrains' IDEs are not written in Java?

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

#132

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

> Why doesn’t someone make a better native editor?

There are plenty of people who keep trying to do that, but a lot of people have moved away from it because “native” means one of:

(1) excluded important platform for developers, or

(2) multiplies maintenance effort and new feature development difficulty by requiring the project to maintain large amounts of platform-specific code for several different platforms (which ends up turning into a platform abstraction layer.)

It's a lot more efficient, in developer time, to choose an existing, well-supported engine that already abstracts the native platform, and focus on developing and maintaining the unique features of your editor instead.

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

#133

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…

Well, usually poor resource utilization means bad design all around. You can always buy more powerful hardware, but it won't fix something that is fundamentally flawed. Text editors are very personal to me. I spend a lot of time learning shortcuts and tricks that are easily cross-platform and portable, and Vim is very easy to do that and is still actively maintained by a great community of well-versed developers that aren't just getting another paycheck from a mega-corporation pretending to do some social good.

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

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

As with most things when it comes to software engineering, it's just a trade-off, and depending on your use case, you may fall on either side of it. They sacrifice memory usage for development pace. Using Javascript/CSS allows them to not only get some of the most powerful pre-existing tools, but also allows the 3rd party community to move at a much faster pace too. Atom already has twice the number of packages as Su…

> Atom already has twice the number of packages as Sublime Text while being half the age.

Somehow I think it has more to do with developers not wanting to pay for software than anything else.

XAML coupled with Blend studio is a powerful UI design tool, or stuff like Adobe XD. HTML/CSS not really.

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

#135

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…

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

It would cost me several thousand dollars for a laptop with enough storage to make me happy, or I could get one with a hard disk from dell for under a thousand, or stick with an older machine for nothing. The difference goes into my home loan for me, for others it goes into a number of other things, from hobbies to investments. Just because you are making good money doesn't mean you should waste it on top of the line everything.

It also puts you much more in touch with your users. MS used to enforce the concept of dogfooding but it seems they only do this on top of the line surface pros these days. At least that's the only reason I can think of that allowed windows 10 to get out the door in such a broken state. If they'd had my cheap dell they surely would have noticed the multiple seconds that it can take for the start menu to load with a spinning disk in the mix.

> If the tool is good and doesn't touch your limits why does it matter if it's as slim as a demoscene release or as hungry as a browser tab?

Yes, the bloated one will slow down the rest of my system, we might have multiple GB available but they are still competing over other extremely finite resources like processor cache, disk buffers, etc.

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

#136

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.

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

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

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

#137

Earlier quoted context omitted.

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

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.

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

#138
post #57
post #6

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

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

As of 2007, Arthur Whitney was developing k [0] and kdb [1] in notepad [2].

[0]: http://kparc.com/

[1]: https://kx.com/

[2]: http://archive.vector.org.uk/art10501320

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

#139

Earlier quoted context omitted.

Vim? Emacs? Anything from jetbrains (although technically that's an IDE)?

How much of Jetbrains' IDEs are not written in Java?

Java is more "native" than anything with Electron.

Starting by the fact that not only there are commercial native compilers, Java 9 also started the road to have AOT compilation support with the long term plan to replace the C++ parts with Java (aka System Java, Project Metropolis).

Also there are hooks in Swing and JavaFX to interact with the host GUI, or if using something like SWT a pure native wrapper to host GUI controls.

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

#140
post #91

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…

You're a bit late to the party lol. vim is dead. All us 'cool elite programmers' as you so blindly follow, have moved onto to use neovim.

leet programmers use vi

:P

Post reply on HN