Hacker News new | comments | show | ask | jobs | submit login
Show HN: Visual Studio Code for ARM, submitted to core (github.com)
236 points by headmelted 8 days ago | hide | past | web | 83 comments | favorite





Great to see. I use VS-code on my Arm Chromebook and it makes for a nice on-the-go dev environment.

Also nice to see ARM getting some attention. Still too many places offer Linux builds in 32 and 64 bit where It's like the Blues brothers line "we have both kinds of music here, County _and_ Western"


Great to see another Chromebook Coder!

(There are some of us, we do exist, world) :-)


I don't have one, but I am bit curious how is a development workflow on a Chromebook. Do you know any article which shows it?

I run Debian in a chroot on my Asus Flip via Crouton. It works brilliantly. Chrome manages the hardware, power management, networking, etc; and then I can pull up a terminal and it's a full Debian system. There is X integration, but I don't use it, so I can't comment there.

If you don't want to install Crouton, it's possible to do some moderately clunky development using Chrome Developer Tool's little-known IDE feature; you can point it at a local directory and edit files there. That allows HTML/JS development directly on an unmodified Chromebook, including the integrated debugger. It's not brilliant, though. If you want to go that route your best bet is a cloud development platform (which requires a network connection, of course).

I wonder if its possible to port vscode to run inside Chrome as a downloadable webapp?


I discussed this here this morning. There's a few roadblocks to this:

https://github.com/Microsoft/vscode/issues/1031


I use Caret[0] where my project is saved in an SFTP folder on a server, so it's kept off the machine in any case (and guessing you can set up some kind of deployment hook from it?). If you've not tried Caret, do give it a go, really speedy and whilst not as good as VSCode, makes development on a Chromebook (and work laptops that don't let you install 3rd party programmes, but do allow Chrome extensions ;) )

[0] https://chrome.google.com/webstore/detail/caret/fljalecfjcio...


I do the exact same thing (Caret with SFTP folder) on my chromebook for lightweight dev (when I only have access to my chromebook at a coffee shop and only have to do some light work, not really deep stuff). Caret is passable but VSCode or even Sublime are better. My main issue though is flakey internet (which is often the case in coffee shops that are not starbucks) makes life really hard. Connections to the SFTP folder keeps dropping, etc.

I've been waiting forever for a good local Git client for chromebooks but it seems like there's just no one working on it. The few that are on the chrome app store haven't been updated since 2013-14 and are full of bugs and don't actually even work. If one existed, I would be able to clone a repo locally and at least edit code in a stable way even when internet is flakey.


I don't understand why people run Linux on a Chromebook. The point of a Chromebook is ChromeOS. If you're running Linux it's just another Linux computer.

I develop on a Chromebook some times. I use a DigitalOcean VPS, using tmux + vim to code and ChromeOS to debug.


Because i wanted a cheap ($250) semi-disposable laptop to use when travelling. Has 1080p screen; great battery life; HDMI output (to present at conferences). I use it mainly on long plane flights (3-23 hours), in hotel rooms and at conferences.

Why shouldn't I buy a chromebook and put linux on it?


It's totally fine if you use Linux with whatever hardware you want. It's just a bit frustrating for a Chromebook user when discussion of Chromebooks is dominated by people who don't use ChromeOS. As though the hardware is the thing, but it's not the thing.

I guess it is the thing though if that's the dominating motivation?

Which Chromebook model are you using? That does sound good for $250

Acer Chromebook 14 http://amzn.to/2oICxpa I bought it last year

Thanks!

Because there are Linux sellers selling laptops on that price range.

I got an Asus delivered with Linux for 300 €.


I couldn't find any at the time; especially ones with long battery life and a 1080p screen. Also 300 euro is more than $250.

Do you have links to models you'd recommend?


I got the Eee 1512B with 8GB and is still able to hold about 6h working time, which is plenty of time for my plane travels.

Sure it doesn't have 1080p, but most apps aren't able to use it anyway.


I use the C201 because it's a cheap computer that supports Libreboot and, using ARM, avoids issues with Intel ME:

https://libreboot.org/faq.html#intel

I replaced ChromeOS with a fully free Debian system.


I'm still flabbergasted by how we (all) could let Intel ME happen. It's, imo, one of the real Damocles' swords above our heads.

This in itself proves one of my previous points, Intel has no serious competition, even the big industrial players can't bend Intel.


When I did develop on a Chromebook (I switched to a Dell XPS 13), crouton was an attractive option since it let you stay in ChromeOS most of the time, while popping out a lightweight Linux environment when you needed it. It got even better when it supported xiwi running in a window, so that the chroot could look just like another Chrome tab. You could even run just one app out of the chroot in its own window, so it was not uncommon that I'd have all of my other stuff in Chrome windows, with SublimeText from the linux chroot running in its own window as my code editor.

Out of curiosity, what's the performance of VSCode on ARM compared to X86?

I've got a Asus C201 (4GB, only $185) and it runs quite smoothly. This is with Redis and Postgres running in the background.

Well, it's Electron...

I swear Electron is incredibly fast in every instance I've used it. Unless you're doing heavy computation with complex algorithms, it's really nice. I don't believe VS Code has to do any computationally expensive computations, and it enables many more people to work on a project (JavaScript being a truly universal language).

I'm currently working on a Mail application and my benchmark test case is an email account with 20,000 emails to be displayed. Noting we currently have no lazy loading and all these are loaded from an on-disk database and put inside their own Shadow DOM it truly did surprise me when it took just over 400ms for an entire page load on my development laptop (~3 years old with an i5, nothing special).

Even if you need to do complex algorithms, just write that particular part in C and use it in the rest of your JS code like normal.


> I swear Electron is incredibly fast in every instance I've used it

That's really surprising to me, I've had completely the opposite experience. Just resizing a window shows how slow it is to repaint and scrolling is often pretty poor too, and this is on a moderately powerful desktop machine. I really hate to think how it'd cope on an embedded device with an ARM processor. There's a marked difference to me between Atom and e.g. Sublime Text.

> I'm currently working on a Mail application and my benchmark test case is an email account with 20,000 emails to be displayed.

Is this benchmark open source? I'd be really interested to try it compared to something similar build in Qt or Gtk+.

> Even if you need to do complex algorithms, just write that particular part in C and use it in the rest of your JS code like normal.

This might speed up complex background processing, but the fact remains that the UI is built on the DOM with interactions handled by JS. It's just not ideal for a desktop application.

With all that said, I totally understand why a lot of applications are built with these sort of technologies. It's much easier to build a cross-platform application than anything else. The price you pay is that the UX is poor.


Don't let Atom be your electron example, it is actually slow. Try VS Code instead.

- signed, former Atom user.


Faster how?

In my experience, VSC's cold boot startup time is just as bad as Atom, and it's not immune to interface jank - for example, when unfolding the "tree view" on one of my projects, I can actually see the folders being painted top to bottom.

But I don't use VSC day-in-day-out (since it's missing multiple project root folder support), so perhaps I'm missing something.


> Is this benchmark open source? I'd be really interested to try it compared to something similar build in Qt or Gtk+.

Afraid it's not, currently the only working copy is closed-source whilst I work on rewriting it all into an open source repository. Having said that, I'm in no doubt that Qt or Gtk+ would be significantly faster than rendering what is essentially a local website.

> I really hate to think how it'd cope on an embedded device with an ARM processor. There's a marked difference to me between Atom and e.g. Sublime Text.

Reminds me of a joke told by a friend of mine:

Friend: "The thing I like about Atom is that it encourages you to write small files."

Me: "How does it do that?"

Friend: "Well, it crashes if you write more than a couple hundred lines."

Personally, I too do use Sublime Text. Not entirely sure how Atom is so slow, but it takes ten times longer to startup and five times longer to search through my files. Definitely caused me to switch away from it.

> but the fact remains that the UI is built on the DOM with interactions handled by JS

Excellent point, but I think if you're doing complex interactions that require a large amount of computing time then you shouldn't be using a program like Electron. For something like a mail application, not much changes. We actually never remove mail items, simply hide them from view, so we have one large render time at start-up and then almost none after that (displaying and hiding an element from view is incredible efficient). For something like atom, you have a significant amount more happening and you want just about everything to be instantaneous. Plus the fact that it's expected to be able to deal with large files consistantly without any hiccups.


Of course electron is fast, it builds on years of work making v8 fast.

My main issue is battery life. I just need to open one electron app (Discord, Slack, Spotify even though that's CEF, but close enough) to have powertop drop from 10 hours expected battery life to 3-4.


That means it isn't fast. Your CPU is fast and electron is making it consume an insane amount of resources to do trivial things. If it were truly fast, it would not affect your battery life.

Hey, have you used Powertop's --auto-tune flag? Is there any way you know of to selectively enable flags. I don't like that my disks spin up and park too frequently because I have some spinning disks too.

I'm sorry, what's CEF? I haven't come across that acronym before.

Chromium Embedded Framework

startup, memory use, and cpu use are typically the issues.

Of course, atom is a specific case that lagged behind vscode for a while. I have no idea whether that's still true.


Wow, I haven't tried vs-code until today after I read this post. I'm surprised how well it works on my mac and it is so far awesome with VIM plugin. I might actually change from my exVIM environment to this one.

Btw, nice to have ARM support as well :)


I actually just went back to it yesterday after dropping it six months ago in favor of JetBrains WebStorm. I was a pretty early user of VS Code and it felt really clunky. The whole tabs vs. sections thing was a fierce debate at the time I started using it and took me a while to get used to it.

Looks as though they continue to integrate full Visual Studio functionality and have added in tabbed navigation, which is great. I'm going to stick with it for a while now since it feels much snappier and easy to use.


Also just tried it on my Mac as well just a couple of days ago, and was pleasantly surprise. I am using it to do python and Javascript tom foolery at the moment and found its support for these two language to be quite good.

There are some quirks that I need to get use to, ie when searching, I had to click on the left and right arrows to go to the next found items. Intuitively, it should be the up and down arrow, unless the found item is literally on the left or right of current position of your cursor.


If you are used to vim, the highest rated vim plugin works like a charm with search etc.

What is exVIM?

A kit of bundled plugins for vim. https://exvim.github.io

Thanks so much for this, headmelted. I've been using your ARM builds of VS Code on my Pine64 for quite a while now; glad to see it's finally made its way to the core.

It's good to know that some folks are getting use out of the builds. Hopefully the releases can be a bit more consistent once it's in the main repository (sorry about that!) :-)

How do you find the performance of the Pine64? I looked at it previously and was interested in getting one, but wasn't sure of how well supported it would be with drivers etc.


The performance is tolerable on the Pine64. It would run much smoother if it had better driver support on Linux.

Sadly, I'd only recommend the Pine64 if you're going to run Android on it, or use it as a server/something to tinker with on Linux.


Wow, very nice!

I think this comment on issues is also relevant: https://github.com/Microsoft/vscode/issues/1031#issuecomment...


Thanks for the support :-)

> be to re-implement the Electron API's that Code uses in HTML5 Javascript with local storage, such that VS Code could run entirely as a HTML5 web application.

This does not look fancy. Microsoft uses VSCode for their online Editor in Azure and VSS: - https://channel9.msdn.com/Series/Visual-Studio-Online-Monaco

Or to say it differently, at least the Editor part is working directly inside the browser: - https://github.com/Microsoft/monaco-editor

(P.S.: I'm not related to Microsoft, I just tumbled upon while trying to work with App Services on Azure)


Totally agreed, the Monaco component is already in place and pre-dates VS Code.

It raises queries about what you do after the editor is running though (i.e. where does your terminal live? What about your interpreters/compilers?).

It quickly gets to the point of looking at SSH to another box like Cloud9 does it, at which point you may as well just run Code there and remote to it.


Not really buying it. Sending each keystroke and paint update over the network isn't a great experience on slow networks; even just ssh has noticeable lag. (Mosh is designed to fix this, but it's not trusted in most places yet.)

Being able to run the UI locally and using ssh to load/save edits to files seems like a better way to deal with latency.


Huh? For an editor in the browser you don't send every keystroke and paint update over the network. The UI is effectively local, you would only need to send regular network updates for 'autosave', and it wouldn't be to keystroke granularity.

I meant the part about "may as well just run Code there and remote to it". Running in the browser reduces latency when it avoids a round trip.

Ah I missed that, sorry.

While VS Code will support ARM, paid solutions such as Sublime Text aren't. This is why I love FOSS.

VS Code is subsidized by Microsoft. Sublime Text is a single guy. FOSS in this case is a big company copying a single individual and destroying their business by doing a better job than that single individual.

I'm using VS Code (and I also bought Sublime) but I am a little reserved about championing FOSS here. Maybe if Sublime had gone open source it might be different, but then what would his revenue source be?


>FOSS in this case is a big company copying a single individual and destroying their business by doing a better job than that single individual.

That's competition for you. Also, I like how you use the word "copying", as if the guy was the original creator of the text editor.


Atom and VS Code are copies of the successful Sublime app. Although it may be more accurate to say that VS Code is a copy of Atom and Atom is a copy of Sublime.

Which ones copy TextMate and Notepad++ in this scenario?

Textmate yes, Notepad++ not a bit.

What's more, the VS product line predates Sublime Text by over a decade.

I think VS and VS Code are about as similar to each other as Java and JavaScript. In other words, the names are similar, but everything else is not so similar.

UX defines products, not underlying tech. VS & VS Code share default keyboard shortcuts, UI look & feel, Intellisense, refactoring tools, and in-editor debugging. As a long-time, long-ago user of VS, VS Code immediately felt familiar to me. That's no accident.

As a long time user of VS.NET and VS before (yes, I started coding a long time ago), VS Code is clearly patterned on Sublime's and Atom.io's UI concepts.

> As a long time user of VS.NET and VS before (yes, I started coding a long time ago)

^ Same here. VB5, ASP ("Classic,") FoxPro... up to ASP.NET MVC & C#4.0. Then Sublime was my primary editor for several years after I left the Windows ecosystem for Mac.

> VS Code is clearly patterned on Sublime's and Atom.io's UI concepts.

It'd be more accurate to say that it's a hybrid of VS & Sublime/Atom's UI concepts. An elegantly executed hybrid, at that.

My original (if implicit) claim was simply that VS Code is a member of the VS product line. I stand by that.


Interesting that everybody has instantly forgotten TextMate, which was the original inspiration for Sublime, and also suffered from the 'single developer === single point of failure' issues as Sublime.

> if Sublime had gone open source it might be different, but then what would his revenue source be?

The revenue would be the same of today. You can sell licenses of an open source software. One might argue that nobody would buy because you can get for free, but it's not different today with the infinite trial.


Sublime, last time I used it, had a nag window every x saves(?) if unlicensed, which I'm sure encouraged a lot of people to pay. I doubt so many users would convert if it was totally open source and they could easily install a nag-free build.

A custom license may forbid nagware removal. It would make forks impractical while granting SublimeHQ benefit from contributions.

Just because the code might be opened up doesn't mean the nagware would have to go away. One underlooked option is to keep it and release under GPL. It's not well known, but GPL more or less protects nag screens. No one would be able to patch and distribute modified versions for the express purpose of disabling the nag screen without violating the license. The author would be able to sell his or her own builds without the nag screen, just like today.

> It's not well known, but GPL more or less protects nag screens

What provision of the GPL, specifically, provides this supposed protection?


Sections 1 and 2 of GPLv2.

Section 1 is the verbatim copies permission, section 2 merely requires your derived version to have an appropriate copyright notice (and the creator of a derivative work is the copyright owner of the derivative), not to preserve the pre-existing copyrigut notice of the original one, much less to include any other information besides a notice of copyright that might appear in a pre-existing a "nag screen".

So, no, it doesn't protect nag screens at all.


I'm not sure why you think your slanted summary is a better argument than what the license actually says. If it supports your position, just point to the text of the license itself where that support comes from. Your words are not an adequate substitute.

> Section 1 is the verbatim copies permission, section 2 merely requires [...]

To clarify an important point of fact: Section 2 is additive. It builds upon the terms enumerated in Section 1. You only get to exercise the right to make modifications if you satisfy the extended provisions from Section 2 on top of your obligations from Section 1. To wit, Section 2 allows you to "distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions".

That is, you cannot perform actions under Section 2 without also fulfilling your obligations from Section 1.

> not to preserve the pre-existing copyrigut notice of the original one

This is not true. It would be true if the GPLv2 required that you merely maintain some form of fair attribution. But that's not what it says.

You are obligated under Section 1 to "keep intact all the notices that refer to this License". (And you are not allowed under Section 2 to shirk your obligations from Section 1. See above.) If the original author includes a notice as simple as, "This copy of Sublime Text Community Edition is based upon Sublime Text Pro and made available to you under the GNU General Public License, version 2", then no provision of the license permits you to distribute modifications where you've replaced the notice with one of your own, even if you think it's fair. Anyone getting away with this today is only able to do so in cases where the original author is looking the other way because the downstream modifications are more or less in the spirit of the license, even if they aren't technically following it to the letter.

That GPLv2 allows for this should not even be surprising—it's similar to the philosophy behind including provisions for Invariant Texts in the GFDL. It's only if you view things through the hazy lens of history where licenses like Creative Commons have shown up and maybe distorted one's general understanding that this comes off as unexpected.

Finally: I constantly find that I want to kick myself when I get involved in licensing discussions here that deal in anything other than the most blunted, obvious aspects of FOSS licensing. So this will be my last comment in this thread.


> No one would be able to patch and distribute modified versions for the express purpose of disabling the nag screen without violating the license

This is wrong - the GPL only requires that the source code of the modified versions be made available. The nag text could be put in the license notice text itself (the original license should be preserved in modified versions), but that might change the license from GPL to GPL-based/GPL-compat. IANAL.


Nice in theory but in reality, top Google result for 'no nag sublime' would be a snippet of how to git clone and patch out the nag, widely distributed from day one.

At least with current ST the 'tutorials' for this tend to involve hex editors or scripts that can be quietly subverted by the author.


Sure. And how much of a dent in revenue to the author would this lead to?

Keep in mind the context of this conversation is a conjecture that Sublime's nag screen led to purchases out of convenience for the users making those payments (who could've easily patched the binaries but didn't). Disagree with that premise if you want, but if so, clarify that you're doing that.


Huh, I started that premise and I'm continuing to argue it. You might be thrown off by HN's busted comment nesting.

If my last comment wasn't clear, I think the dent in revenue would be considerable for fully open-sourcing Sublime as it would make it too easy for people to patch out the nag.


Distributing those patches would be against the license. I'm looking for any indication that the set of people willing to a) download a patch; and b) use tools to apply it on their own; and c) build it; and d) be unmoved about the ethical implications of the whole thing; is at all significantly larger than the set of people willing to open a hex editor to poke at some bytes for the same purpose.

> Huh, I started that premise and I'm continuing to argue it. You might be thrown off by HN's busted comment nesting.

I'm asking that your argument is internally consistent—that you're not trying to advance some thought, and the backtrack to a position where you advance another one that's at odds with the original. I don't see how this suggests that there's confusion about how to read threaded comments.


One could make an argument that you could get enough via a donation subscription service like patreon and offer your backers something extra like a set of plugins or the newest build compiled for their platform.

Sublime is like 2 people. VSC is an open source project with a strong backing from Microsoft.

I should mention that I don't work for Microsoft. I just wanted this for a long time.

Although it does speak to the benefits of FOSS in this case I guess :-)


Yep, but you are building on top of stuff built by paid people, I guess.

I wouldn't say you can really compare the two. Sublime Text is different in many ways, not my cup of tea even if it were free. I was using Brackets before and Monaco in the browser and when I saw the VSCode preview I knew that was what I had been waiting for.

Of course it helps a lot that Microsoft is behind it as they can spend a lot of resources on polish and features while they also have a strong history in making good tooling (VS).


I adore VS Code and everyone on the team that is cranking it out has my deepest respect.

It really is a phenomenal piece of work and is just getting better and better.

Looking forward to see how it performs with Chakra Core as the script engine one of these days.


Nice work mate!



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: