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

141–150 of 240 posts

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

#141

Post by pjmlp »

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.

All the compilers I bought during the 90's, using student discounts, would allow me to buy several copies of Sublime Text in today's money.

It is that mentality that killed the market of nice tools for developers.

Now everyone that wants to live from software tools has to target the enterprise market, where the tool won't cost $80 but a few hundred if not thousands.

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

#142

Post by braderhart »

petee wrote: post #140
tamrix wrote: post #91

Earlier quoted context omitted.

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

Haha... Wait until you've seen some wizard use Ed.

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

#143

Post by [deleted] »

meric wrote: post #66
s4vi0r wrote: 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…

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

[deleted]

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

#144

Post by y4mi »

ehsankia wrote: post #51
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.

...and extensible, with at least vim mode!

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

#145

Post by pjmlp »

krisroadruck wrote: post #115
stephenr wrote: post #100

Earlier quoted context omitted.

Most laptops top out at 16GB of ram. Unless you’re only using your editor, you need resources for other things too. VM based dev environments via vagrant, docker etc are very common. What I don’t understand is why if you’re going to use an editor that’s resource heavy, you wouldn’t just use an IntelliJ product. Sure, they’re jvm based and “heavy”. But they’re also fucking amazing, and have functionality none of these…

Is it common to code on a laptop instead of a desktop? I'd find it style cramping. Need the extra screens, full keyboard and mouse. But I work in digital marketing so my notions may be way off base.

My last personal desktop was in 2002.

At work we switched to Thinkpads with docking stations back in 2006.

Never used a desktop again, only once an abandoned tower re-purposed as server.

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

#146

Post by WalterGR »

pjmlp wrote: post #139
WalterGR wrote: post #131

Earlier quoted context omitted.

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…

That may well be true. Are we calling Java "native" now? This is my first time hearing it.

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

#147

Post by boomlinde »

moosingin3space wrote: post #8
tomc1985 wrote: post #6

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

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?

Messy and simple are orthogonal characteristics. A terminal is simple in that cursor movement, colors and style are all the result of a bunch of escape sequences. Once you have a list of the escape sequences you want to parse or emit, implementing a terminal or an application targeting the terminal is not hard. It's messy because there are historically a bunch of different terminals that implement different escape sequences. It's not easy and it's not clean and beautiful, but it's still simple.

It's a bit weird to bring up scripting languages. The problem is that people want a customizable and scriptable editor. Solving that problem by providing a script language to its users is not overengineering, it's simply meeting a demand.

Looking at this, it uses some native facilities simply to setup a web browser view. Within that, it doesn't even use the built-in functionality of a browser to render the text you're editing, but resorts to custom rendering and layout using webgl. This isn't simple or clean. It's a convoluted waste of resources in that regard. Why not use one of the smaller cross-platform OpenGL wrappers?

Maybe it'll be a fine editor, but it's much more complex than it needs to be. I guess that because they set a "Web-compatible build artifact" as a goal on the roadmap, it makes sense, but is that really an interesting goal? What problems will be solved once the editor is a tab in Chrome?

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

#148

Post by com2kid »

pjmlp wrote: post #137
com2kid wrote: post #106

Earlier quoted context omitted.

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.

> 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

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

#149

Post by hota_mazi »

WalterGR wrote: post #131
earenndil wrote: post #95

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?

Probably just a few percents, which are likely written in Kotlin.

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

#150

Post by pjmlp »

WalterGR wrote: post #146
pjmlp wrote: post #139

Earlier quoted context omitted.

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…

That may well be true. Are we calling Java "native" now? This is my first time hearing it.

Java has always been native to those that knew where to buy native code AOT compilers.

Unless you mean D, Go, Haskell, OCaml aren't native.

Post reply on HN