Hacker News Reader

I feel like a dinosaur because a "native" app to me means pretty much the exact opposite of an electron app.

I totally agree with you there, buuut, before this release VSCode on a Surface Pro X would be Electron running as a ia32 emulated app, which is not only web technologies but also the wrong ISA.

I'd love to have sublime text, textadept, or any other real native editor running under ARM64 on Windows but so far they are not available. This VSCode is the first editor shipping ARM64 binaries, even if Electron stuff.

Also it is important to notice that many developers using that machine are using the ia32 version of VSCode and this version will benefit them (and it more native to the platform).

Is it not possible to compile editors like emacs or Sublime Text for ARM64? I know very little about native programming but surely GCC/Clang/Visual C++ have ARM64 compilation targets?

It certainly is! Not sure what the situation is on Windows but Linux distros that have ARM versions typically have nearly all the same software that you’d expect on x86 in their repos. (I’m thinking of Debian in particular here, but I suspect others are similar.)

It is a chicken and egg problem. Many languages do not yet support Windows on ARM, so you can't rely on them to build stuff for the new platform. For example there is no official release of NodeJS, Python, Ruby, Perl, on the platform.

Lots of FOSS rely on gnu stuff which is usually compiled on windows using mingw/msys2/cygwin, all of which are not available for Windows on ARM. So you can't easily port stuff.

You can run Visual Studio and cross-compile from ia32 to arm64 on a Surface Pro X but that is unsupported by Microsoft who wants you to have two machines, one running x64 and compiling stuff and another running arm64 and testing stuff. That is unreasonable for small independent developers.

So until the development ecosystem is a bit better, porting stuff will still have a lot of friction and that is why for now, IMHO, every port needs to be cherished.

True, but remember when many apps were not made for Linux, because it was not worth it? With Electron at least we have apps like VSCode for Linux too. Not ideal, but better than nothing.

But then unfortunately, even then some companies do not provide their Electron app on Linux e.g. Notion.

Though, it is usually easy to rewrap the version from another platform using Electron on Linux. E.g. writing a Nix derivation for Notion on Linux isn't much more work than for any other Electron application:

https://github.com/danieldk/nix-packages/blob/master/pkgs/no...

(Not tested more recently though, I don't use Notion a lot.)

> But then unfortunately, even then some companies do not provide their Electron app on Linux e.g. Notion.

Add Figma to the mix. Since I moved to Linux exclusively, I've abandoned plugin authoring. Granted, there is a Linux-Figma[0] app, but every time I try it, it doesn't take long before something essential (e.g. fonts) breaks.

[0]: https://github.com/Figma-Linux/figma-linux

> True, but remember when many apps were not made for Linux, because it was not worth it? With Electron at least we have apps like VSCode for Linux too. Not ideal, but better than nothing.

and yet on Linux you had already the entirety of debian already available in native ARM64 years ago, which is a lot more than what you have on windows ARM64.

Blender, Photoshop, Premiere, Maya, ZBrush, CATIA, AutoCAD, and hundreds of other specialized tools are not moving to Electron anytime soon...

My point is that we shouldn’t embrace for Electron just because we want applications in Linux.

In addition, Election is not a guarantee of a Linux port either.

AutoCAD has a web version. I wouldn't be surprised to see an Electron version sometime. (One wonders how feature complete it would be though.)

In any case, I personally embrace Electron due to its development value. I can use the same codebase on all platforms, using technologies that my colleagues and I are already very familiar with (TypeScript/React/etc), with a supporting cast of a mind-shatteringly large ecosystem of FOSS packages. The speed at which I can turn out features in Electron just vastly outpaces anything else we've worked with. And that seems to be worth more to users than the 200MB footprint.

> AutoCAD has a web version

A shitty version, you mean. Same as Office 365 vs. the native Office.

The web versions of most native apps are very, very bad at the moment.

> I can use the same codebase on all platforms, using technologies that my colleagues and I are already very familiar with (TypeScript/React/etc), with a supporting cast of a mind-shatteringly large ecosystem of FOSS packages.

Everything you wrote here applies to most languages, including .NET, Java, C++, Rust and others.

The fact that you and your colleagues know other technologies does not mean they are the right approach.

> The speed at which I can turn out features in Electron

I think that is exactly what users don’t want. Users want stability and quality, not feature churn.

> A shitty version, you mean.

Indeed, hence the parenthetical.

> Everything you wrote here applies to most languages, including .NET, Java, C++, Rust and others.

Superb! Direct me to a rich Rust GUI application which targets the web, Linux, and iOS. Speaking to team tech familiarity, our front-end web engineers will be thrilled to get cracking with Rust. That'll be a sight!

> I think that is exactly what users don’t want. Users want stability and quality, not feature churn.

I'm glad you know what users want. I generally prefer them to tell us, and incidentally, "feature churn" never comes up in such discussions. What user stories do come up can be completed remarkably quickly in our Electron stack with stability and quality too.

Eventually we're going to just have a means of saying: Save this webpage as an app.

I mean, we do already. It's called PWAs, and I have many of my favorite sites saved as an app. But it's featureless and lame.

Point being, Electron is just a stopgap while PWAs are figured out. And with the advent of WASM, we'll be able to run some pretty heavy stuff.

https://wasm.continuation-labs.com/d3demo/

My long term strategy: Learn rust for WASM, keep an eye on PWAs

Wasm is still very early and lacks a lot of features. It is also not as fast as a native application.

The browsers also lack many APIs to compete with native applications, and those are not coming soon either.

Web apps are just fine, even nowadays, for many things. But for heavy lifting, no, they are still way, way behind.

(By the way, you can compile to Wasm with almost any popular language, not just Rust).

I feel like even more of a dinosaur then because "native" to me means compiled for the target processor architecture vs being emulated (which is exactly what this is about).

Electron is running natively. What is running in electron is not.

> VSCode is using about 300MB+ and Sublime Text (working under built-in ia32 emulation) is using 15MB.

On my mac VSCode sits at ~380MB without any files open, but opening one empty plaintext file brings that up to 460MB, opening one tiny Lua (a language known for being especially small and efficient) file makes that 500MB, and opening a second tiny Lua file makes that 535MB. Does Sublime increase like that?

Ram usage will increase in Sublime Text as syntaxes are loaded into memory. The last time I checked on a Mac, loading every single default syntax would get you in the low 200MB range.

A large part of that with the current stable builds is syntaxes that embed others - so Markdown fenced code blocks and LaTeX files. For simpler syntaxes you’ll see a much smaller jump in ram usage.

There are advantages to having VSCode in Electron. I run VSCode as a web application on my server that I access remotely using a browser on a number of different machines. That instance has access to the file system on my server, allowing me to use any machine to do my work without installing anything. Try doing that with Sublime.

Microsoft is leveraging this by allowing you to open up VSCode in Github for any file, no installation necessary. Amazon is doing the same with Cloud9 on AWS that they acquired earlier.

You don't actually need to install VSCode on the server - the SSH extension lets you use VSCode locally.

https://code.visualstudio.com/docs/remote/ssh

That's useful, but I think the person you were replying to doesn't just use the host machine as a remote file system but also as a build host and to have a single workspace with all its settings available from any machine.

I recently set this up as well using code-server [1], which works brilliantly. I have a VM running on a powerful hypervisor host, which has all the source code, the workspace configuration with all my customisations, build tasks, etc. Compilation is fully on the host side, which is a 12-core with 32GB memory, way beyond any of the computers I use as clients, and all I need to access it is an SSH connection to it. Code-server has a progressive web app mode that makes it pretty much indistinguishable from running a local installation. First time I have had to acknowledge it wasn't such a bad idea to implement VSCode as an Electron app to be honest.

[1] https://github.com/cdr/code-server

The ssh extension actually does all of that as well, but it does mean the frontend runs in the Electron app vs in a browser. The first thing the ssh extension does is install the VS Code server backend in the remote host, enabling the remote host to run extensions, the terminal, and so on.

That instance has access to the file system on my server, allowing me to use any machine to do my work without installing anything.

Many editors have had remote editing support for a while. It requires that you have installed the editor locally, but why wouldn't I have an editor on my laptop or desktop?

(Tramp + LSP all the way ;).)

Though being able to open VS Code in GitHub is a really nice feature!

> why wouldn't I have an editor on my laptop or desktop

Because it's not just the editor. It's the toolchain. I get remote terminal inside the editor. All my tooling lives on the server and can be specific to the project I'm working on, instead of gumming up my local machine.

Have you heard about Emacs? It has all the features and more. Plus had them for long long time. 44 years on.

Indeed I have. I just don't want to party like it's 1976.

Yet, you are probably deploying on an operating system that is a clone of another operating system that was started in the early 70ies.

Just because I sometimes go through a tunnel doesn't mean I want to live in a cave.

If you use e.g. the Emacs LSP package and edit files remotely through Tramp, you are using the remote toolchain, language server, etc. [1]

(Though for me it doesn't really matter, because I can reproduce exactly the same environments between server and local with Nix.)

[1] https://emacs-lsp.github.io/lsp-mode/page/remote/

Your setup sounds really intersting, do you have any links for tutorials on how to setup something similar?

Not sure if the parent poster has a custom setup, but there's now tooling to set this up yourself and use Microsoft as a secure proxy so you can access your host from anywhere in the world: https://docs.microsoft.com/en-us/visualstudio/online/referen...

You can also "cheat" and instead of registering your VS Code server instance with Microsoft and find the path in your ~/.vscode-server or whatever directory, and there should be a shell script that starts it and runs VS Code on port 8000. You can then set up any reverse proxy/TLS/auth layer in front of that and access it similarly.

I think the VS Online (now called VS Codespaces) experience is a bit better but the process of creating an account and logging in is messier.

I just used https://github.com/cdr/code-server

It doesn't grow like that in my experience.

I just loaded the source for Luarocks on Sublime Text and my RAM usage while browsing some Lua code in it is 31MB, pretty decent.

If you're doing Lua, there is always Zero Brane Studio (https://studio.zerobrane.com/) which is built with Lua and very nimble (uses wxLua which is wxWidgets + Lua), unfortunately it is not playing well with my hidpi screen. Another good option for Lua developers is TextAdept (https://foicica.com/textadept/) which has wonderful support for extending it using Lua, IMO it is like an Emacs but with Lua. Those editors are available as ia32. I didn't succeeded in compiling ZeroBrane studio for arm64 even though I managed to compile both Lua and wxWidgets for it. As for TextAdept it uses GTK and that is not available for Windows on ARM.

For the past week I've been using sublime text and am quite happy with it. I also use VSCode when I need some more intelisense help.

No. Once I reached 750 MB but that was because I was working on a JS project with a `node_modules` of 110 MB and by default ST indexes the text contents of all files so I can do find all across files. After that folder was excluded, it took 250 MB and it was indexing 20 MB.

Good thing Raspberry Pi now comes in 8GB models! https://www.engadget.com/raspberry-pi-4-now-available-with-u...

I kind of want to compare this to some older laptops I've been given before.

Can you install Windows on Raspberry Pi?

Yes.

https://www.microsoft.com/en-us/download/details.aspx?id=550...

This is not "full" Windows 10, not even close. He means an full installation like what this can provide:

https://github.com/WOA-Project/WOA-Deployer-Rpi

It does not work on Rpi 4 and it is not full Windows environment.

Yes for full Windows 10 see https://github.com/WOA-Project/WOA-Deployer-Rpi although targetted for RPi3 some success with 4 has been had but currently RAM is limited to 1Gb slightly less exciting.

In addition to what the others have said, we've had good experience with Windows 10 IoT on Raspberry Pi 3B (a few dozen units deployed in daily use) for some sensor data capture applications.

However, based on our experiences with the Pi 3B+ and Microsoft's promise to get an update out "real soon now" (probably over year late at this point), we've concluded that Microsoft is not serious about Windows on the Pi. So we decided to not do any more development on the RPi Win10 IoT platform, and move future development to .NET Core running on Linux which they seem far more enthusiastic about supporting.

I can't seem to find the link, any help? The Insider win64 downloads are x64 only still at https://code.visualstudio.com/insiders/

That issue link contains the links for download for many different versions. If you go to https://update.code.visualstudio.com/latest/win32-arm64-user... you'll get a direct download of it as well.

That reader is me, thanks.