Show HN: Visual Studio Code for ARM, submitted to core
github.com
github.com
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"
(There are some of us, we do exist, world) :-)
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 develop on a Chromebook some times. I use a DigitalOcean VPS, using tmux + vim to code and ChromeOS to debug.
Why shouldn't I buy a chromebook and put linux on it?
I got an Asus delivered with Linux for 300 €.
Do you have links to models you'd recommend?
Sure it doesn't have 1080p, but most apps aren't able to use it anyway.
https://libreboot.org/faq.html#intel
I replaced ChromeOS with a fully free Debian system.
This in itself proves one of my previous points, Intel has no serious competition, even the big industrial players can't bend Intel.
[0] https://chrome.google.com/webstore/detail/caret/fljalecfjcio...
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'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.
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'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.
- signed, former Atom user.
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.
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, atom is a specific case that lagged behind vscode for a while. I have no idea whether that's still true.
Btw, nice to have ARM support as well :)
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.
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.
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.
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.
I think this comment on issues is also relevant: https://github.com/Microsoft/vscode/issues/1031#issuecomment...
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)
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.
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.
Although it does speak to the benefits of FOSS in this case I guess :-)
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?
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.
^ 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.
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.
At least with current ST the 'tutorials' for this tend to involve hex editors or scripts that can be quietly subverted by the author.
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.
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.
> 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.
What provision of the GPL, specifically, provides this supposed protection?
So, no, it doesn't protect nag screens at all.
> 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.
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.
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).
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.