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

171–180 of 240 posts

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

#171

Post by yorwba »

braderhart wrote: post #129
JeremyBanks wrote: post #72

Earlier quoted context omitted.

This reads like you haven't paid attention to anything Microsoft has done for the last five or so years, including VS Code. The strategy around VS Code is entirely consistent with the more open-source-supportive angle the company has been taking, and the editor is very performant and well-engineered compared with Atom.

Haha, please enlighten me. Let's see what open source license Microsoft picked for their generous efforts to restore socioeconomic equality: https://code.visualstudio.com/license

From that page there's a trail of links to this explanation for the licensing: https://github.com/Microsoft/vscode/issues/60#issuecomment-1...

TLDR: Visual Studio Code is a Microsoft-branded product that is made available to users under a Microsoft-y license. However, the "vscode" project containing almost all code for that product is open-sourced under MIT.

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

#172

Post by suprfnk »

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.

SSH into a box with tmux and vim? Or is that too minimal?

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

#173

Post by dvfjsdhgfv »

ahtu123 wrote: post #17
toomanybeersies wrote: post #5

I've always felt like the inevitable conclusion of Atom and other electron based apps is the reversion to using low level compiled languages. I'm starting to get tired of how much of a resource hog Atom is.

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.

Many today's developers are web developers, they had no experience of a feature-rich, intuitive, smooth and efficient but relatively lean IDEs - at most something like the most recent versions of Visual Studio and Xcode which are huge beasts. For them, Atom is just a nice editor and they don't even notice the problem.

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

#174

Post by giancarlostoro »

It's funny they want to rewrite some of the core functionality in Rust and make it available through an N-API binding. I've mentioned on HN (and gotten plenty of hate for it) that another approach to gain performance with Electron is to use a back-end language to serve up a local web page, I can only imagine just using a Rust or D web framework that can handle heavy data traffic, only running on 127.0.0.1 serving up some of the content the Editor (or whatever application) needs and doing some heavy lifting from Node itself. In fact I think there's already an open source mail client I don't remember the name that does this, it feeds Electron from a Python back-end, would not surprise me if they're doing pretty well performance wise, let back-end people do their thing, and let front-end people do theirs. Of course things will also get interesting whenever WebAssembly becomes another way to build an Electron application (really can't wait for WebAssembly to become totally mainstream). If my website had half of the stuff on the front-end that my back-end is supposed to handle yeah people would call me out for shoving so much into the DOM / front-end and suggest I offset some of the heavier stuff into the back-end.

Long before Electron I saw applications that ran on localhost in your own browser (think SlickBear, CouchPotato and Headphones) and they were highly responsive regardless of browser used! They were all coded in Python too, so I can only imagine if some of those native API's could just be done as a web api instead to keep things simpler, then you just need to identify a REST framework to handle some of those things. Anyone could add on to a RESTful API for the editor / call said API as well, though it should be locked down securely for obvious abuse reasons.

I used to like the idea of taking nw.js and making something like Atom (before it was even a thing) but using D as a back-end language for it, but never really got through doing it. Ah well.

Edit:

I also find it funny they're ditching CSS for JavaScript when Firefox redid their CSS engine in Rust. I have to wonder if and when Electron will deviate from Chrome altogether and become it's own forked browser engine, but maybe that's a thought a bit ahead of it's time.

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

#175

Post by Corrado »

Derbasti wrote: post #155

So, they replace backend JS with rust, and frontend DOM/CSS with WebGL. Then all that's left of Electron is the V8 JS engine for scripting. For the desktop, they could cut out Electron entirely and replace it with V8 and some minimal OpenGL bindings. I wonder how that would improve performance!

I was just thinking that this effort is a real departure from the earlier stuff. The original Atom project was to build a text editor using the core of a web browser to do all the heavy lifting and use web technologies (HTML, CSS, JS) to provide the GUI.

It looks like this latest effort is ditching most of the web browser stuff, and some of the web technologies to build something performant and extensible. Just like Sublime Text (and others). Have we come full circle?

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

#177

Post by TomMarius »

grzm wrote: post #159
enraged_camel wrote: post #156

Earlier quoted context omitted.

I haven't understood why people use the Slack app, as opposed to just running it in a browser tab. It uses up significantly less RAM, and has basically the same features.

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.

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

#178

Post by alexyoung »

nurettin wrote: post #120
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.

A year ago I tried incorporating typescript language server into vim. The experience was an unpleasant stutter. I guess some editors just aren't meant for some things.

It's got better recently. I'm using https://github.com/autozimu/LanguageClient-neovim for work without any obvious issues, but https://github.com/natebosch/vim-lsc is also good

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

#179

Post by z3t4 »

grzm wrote: post #159
enraged_camel wrote: post #156

Earlier quoted context omitted.

I haven't understood why people use the Slack app, as opposed to just running it in a browser tab. It uses up significantly less RAM, and has basically the same features.

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.

Try a window manager, for example i3

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

#180

Post by gr__or »

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.

To be charitable, I'm gonna interpret this as hyperbole. If you meant this as its written, it'd be an immensly ignorant statement.

Almost by definition, there CAN always be a faster implementation in C++ but there are also more ways to shoot yourself in the foot (or as they saying with C++ goes, shoot your leg off).

Post reply on HN