12 ms·

Visual Studio Code: Shipping One of the Largest Microsoft JavaScript Apps

208 points by eklavyaa 10y ago

tejinderss 10y ago
Personally I think it's a biggest mistake to use browser engine for a text editor. We already knew how slow and clunky the browsers are and thanks to vscode and atom our text editors are becoming the same. I would stick to sublime text and vim for as long as I could. /rant
- flohofwoe 10y ago
  Did you actually give VSCode a try before making such statements? I use both (neo)vim and VSCode (with vim key bindings, sacrilege!) daily. Vim starts up faster (vim is instantly vs about 1 second for VSCode), but once you're in the editor it depends what you do in it. For instance the standard python syntax highlighter in vim is much slower in vim for files with a few hundred to a few thousand lines of code compared to VSCode. Setting up a C++ dev environment and debugger via vim plugins is hit and miss, in VSCode it's just a few seconds to install the extension, and step-debugging is snappier then in 'native tools' (e.g. Xcode). TL;DR: it's not Electron or Javascript which makes editors slow, it's how the code is written.
  - tjoff 10y ago
    "TL;DR: it's not Electron or Javascript which makes editors slow, it's how the code is written." It would not have been humanly possible to get something like Spotify (we have lists of text and icon-sized images) so resource intensive in any other language. Now if you want to spend ten (hundred?) times the effort to actually make javascript do something decent I truly hope you get pleasure from that sadistic adventure.
    - flohofwoe 10y ago
      I don't know, writing extensions for VSCode in Typescript is actually quite pleasant. Sure it would be better to have a super-performant, super-small, cross-platform runtime environment. But what would that be? Qt? Java? .NET? Or another roll-your-own UI kit? PS: I think Spotify should have simply stayed in the browser, the desktop app is redundant.
      - tjoff 10y ago
        Why not Qt? And, since this is Microsoft, why not take this opportunity to develop the backend in .NET core. But I yes the biggest impact javascript will have on mankind is that noone will ever be bothered to create a good foundation for cross platform applications. The desktop app is absolutely paramount for Spotify to stay relevant. Not sure if I've seen or heard of anyone using it in the browser (not that that is relevant, but I'd stop using it the very second I can't use it as a standalone app).
        roblabla 10y ago
        Because Qt is a huge library. And it's not even really native outside of Linux KDE (though it's the closest we'll get cross-platform wise).
        Johnny_Brahms 10y ago
        I don't want to be a part of the anti-electron crowd,but for something like a text editor qt will most certainly be smaller than electron.
        mixedCase 10y ago
        It is huge, but so is Electron. It's as native as it gets, it imitates native widgets perfectly and allows the designer to easily recreate every element of a particular OS' HIGs with the use of stylesheets and native code. In before "doesn't look native in my macOS": Because the people writing in cross-plat tools usually don't care about getting every detail right, they just want their app to run well everywhere. But Qt does allow the developer to nail those details without too much effort if he actually cares. The only problem with Qt is C++.
    - z3t4 10y ago
      use a stepping debugger to see what it does. then remove stuff that dont add value.
    - derefr 10y ago
      Is Spotify's resource-intensiveness due to things it's actively doing in Javascript (i.e. a lot of procedural code running all the time), or is it due to things it sets up the DOM to do (i.e. a really complicated page that the renderer chokes on)?
  - Razengan 10y ago
    VS Code uses 13% CPU when idle due to blinking cursor rendering https://news.ycombinator.com/item?id=13940014 https://news.ycombinator.com/item?id=13940014 Edit: Ah a bug. I still hate apps that don't use my OS's native UI controls though; even if you can stomach the inconsistencies in look and feel, you DO most definitely lose out on many features that the OS would give you for free.
    - flohofwoe 10y ago
      That was fixed a few days later with the March update: https://github.com/Microsoft/vscode/issues/22900 https://github.com/Microsoft/vscode/issues/22900
    - maccard 10y ago
      That was a bug and can easily happen in native software too.
      - hashhar 10y ago
        And the biggest point is, it was a Chromium bug. Recently the Chromium team also breaked special keys (Home, PgDown, PgUp, End, Insert etc.) over RDP which caused a lot of issues for people using VSCode.
        Rapzid 10y ago
        Wow, how do you even break keys over RDP from inside your app?! Do you have a link; I'm curious about the root cause. Some here may recall that early VS Code had a but where drag to highlight and menu option highlighting on mouse-over was busted in Virtual Box. So crazy and also a chromium bug.
        hashhar 10y ago
        The issue contains a link to the related Chromium bug where I think you can follow up. https://github.com/Microsoft/vscode/issues/24107 https://github.com/Microsoft/vscode/issues/24107 I don't know for a fact that it is RDP but it's the common factor among other people with the same issue.
  - abrkn 10y ago
    I switched from Atom to VS Code a few weeks ago and find VS Code's performance to be excellent. Haven't used Atom since.
    - dolzenko 10y ago
      Any idea on what exactly VS Code did better to achieve that performance compared with Atom?
      - killercup 10y ago
        Plugins don't run on the UI thread IIRC
        Rapzid 10y ago
        You do. They also have some really smart people(I'm assuming more than one, but at least one has posted on HN about editor optimizations they have made) who seem to pull out all the stops on monaco to produce a very fast "smart" text editor. Lots of good architecture decisions made. The marriage with TypeScript has also worked out well; it's on fire and coffee is smouldering. This helps with getting people to jump in and contribute.
    - swozey 10y ago
      Were you a heavy Atom plugin user? I'm afraid I'll leave and all of the great plugins won't convert.
      - F2 10y ago
        Which plugins?
      - andrewguenther 10y ago
        90% of my Atom plugins were built-in for VSCode. * Terminal built-in * Sublime style Alt-O for header file switching * Minimap * Javascript/Typescript support made a lot of my plugins obsolete I have language plugins installed for Dockerfiles, protobuf, and a few others, but VSCode felt really complete out-of-the-box. I didn't feel the need to install a ton of plugins to make it useable like I did for Atom.
- mercer 10y ago
  Personally I think that trotting out this argument in every single post about VSCode/Atom/Electron/etc. serves absolutely no good purpose at this point (other than upvotes or the pleasure of expressing an opinion, perhaps), but I'm happy to be corrected. That said, I'm also still using Sublime Text / vim primarily because they do feel faster on startup and handle big files well. But I think rationally it would make sense for me to move to VSCode, because 1) my code editor is almost always open, and 2) I rarely need to edit really large files, and 3) VSCode is plenty fast for pretty much all other use cases and offers a whole bunch of advantages over ST. Atom I'm less sure of. It seems to get faster every few months that I give it a spin, but it still feels 'laggier' even in normal use, which is definitely a problem for me.
  - nottorp 10y ago
    Well, the main question is still "why oh why?". It's not like Microsoft can't afford to pay developers to do something native. Also, calling it Visual Studio is very deceptive. Most devs know VS to mean something completely different.
    - mercer 10y ago
      > Well, the main question is still "why oh why?". It's not like Microsoft can't afford to pay developers to do something native. Yeah I do share that question with you and would love an answer from the team! > Also, calling it Visual Studio is very deceptive. Most devs know VS to mean something completely different. Could you clarify what you mean with that? Accusing me of being 'deceptive' seems a bit unwarranted and disproportionately antagonistic, considering that as far as I can tell I've made a clear distinction between VSCode and VS (meaning Visual Studio proper), and considering that I can't think of any reason why I would choose to deceive in this matter. Where did I go wrong?
      - TeMPOraL 10y ago
        I think the parent didn't mean to accuse you, but Microsoft, for re-using the "Visual Studio" brand in a product so completely different that it deserves a distinct name. Reminds me of how pissed I was with Amazon calling their line of regular Android tablets "Kindle Fire". I don't know what the sales teams there think, but for customers, the "Kindle" brand was literally synonymous with "that e-ink screen thing".
- simion314 10y ago
  I am wondering if they can switch the UI part, say use the Canvas and WebGL(there are some libs for GUI with GL but I do not test them)
  - simooooo 10y ago
    Well they're currently using Dom elements with CSS. So would likely be a massive effort to reimplement all it as proper web GL. Which is kinda what a browser does internally anyway
  - 13years 10y ago
    There is likely no need. Hopefully a technology like Servo will get built into Electron. If that happens, there shouldn't be any issues related to performance. Servo in theory can be even faster than native libraries thanks to its use of retained mode. https://air.mozilla.org/bay-area-rust-meetup-february-2016/#@25m50s https://air.mozilla.org/bay-area-rust-meetup-february-2016/#...
    - hashhar 10y ago
      Servo is quite good actually. If you haven't already, try using browser.html from Mozilla which uses Servo and HTML for the UI.
      - epoch1970 10y ago
        I wouldn't consider Servo to be "quite good", at least in its present state. The Browser.html UI is quite minimal, in the sense that it really doesn't do much at all. It's basically a list of tabs along the right side. I also find it quite laggy, and sometimes it locks up completely. I'm not sure why you think people should be impressed with it. As for Servo itself, there are noticeable rendering problems with pretty much every web site I've ever tried with it. Even the servo.org home page had rendering glitches when I last tried it several days ago! The scrolling is very broken under macOS. I've also had it crash now and then. Maybe it will get better in the future. But at this time I'd consider Servo to be pre-alpha quality software. Trying to impress people with it would probably do more harm than good. They'll likely encounter problems with it right away, and it won't leave a good impression on them.
- 9935c101ab17a66 10y ago
  Your comment adds nothing new to the frequent and tired war (native vs electron). I get it, you prefer Vim and Sublime (I find this quite funny because I can only suppose critics attacked Sublime Text with the same arguments you use now) Either way, Atom/VSCode have developed a large following which encompasses lots of talented and smart people. They both cannot be completely summed up with the description "slow and clunky." They are absolutely not perfect, but if you really cannot see any of the many reasons people use them, you're being left behind and I strongly suggest you refrain from commenting.
- mrmondo 10y ago
  I could not agree more, this is why every time I try atom I go back to sublime, that's really only one example of many - there's a massive difference between javascript 'desktop web app frames' and native applications written in ObjC/Swift/QT etc... between the terrible perceived(?) latency of javascript apps and the memory usage to be honest I just delete the app and find something else when I come across them.
  - jdub 10y ago
    Sublime is mostly written in Python. Yes, there are some native elements, particularly where performance is paramount.
    - mrmondo 10y ago
      Sublime is actually mostly native c++, but it has python bindings for its API
  - Ardren 10y ago
    I put off even looking at VS Code for a while because of the poor performance of Atom. But when I tried it, I was really surprised at how much faster VS Code was. It's changed my opinion of electron based programs.
    - tracker1 10y ago
      I had the same experience... after atom and brackets, I was like, sure... I installed it to make fun of it... but it actually ran well. It's been my daily driver ever since, and better with each release. The integrated terminal is far and away my favorite feature, second would be the git+diff integration... though merging/rebasing needs a good story.
- pcarolan 10y ago
  This is called hacker news. Things that work well should be elevated, by trial, above all else. Try it. Seriously.
- josteink 10y ago
  > Personally I think it's a biggest mistake to use browser engine for a text editor. We already knew how slow and clunky the browsers are and thanks to vscode and atom our text editors are becoming the same That's an interesting claim, given that Visual Studio (not VS Code) is native through and through and still it's orders of magnitude slower to work with on any sizable code-base compared to the "slow" editor VS Code. It's almost as if you could say that on modern hardware the architecture of the application dictates overall performance much more than the technology used to implement it. But yeah, that would certainly be madness, so let's not go there, eh?
  - saurik 10y ago
    Just because you can make a slower text editor doesn't really demonstrate anything unless the person you are arguing against would have used that slower one (and "architecture" is definitely something constrained by an implementation decision as critical as "implemented using a web browser").
    - josteink 10y ago
      Sure. Any concrete implementation detail constrains your architecture and freedom to some extent. But VS Code first and foremost uses a web-browser for UI. How much does the choice of a UI-technology really constrain the rest of your application and its architecture? I would argue that with a good architecture, the choice of UI-platform should place near zero effective constraints on the rest of your application, how it's structured and how it performs. It should certainly not be a critical component of your overall design, it should be an implementation detail. Are you arguing otherwise? Can you come up with some concrete examples where the choice of UI-library causes troubles other places in the application? If not, it seems you're more or less agreeing with my original statement. And as such, I don't see any fundamental problems using a web-browser in a text-editor.
    - tracker1 10y ago
      Then go ahead and "do it better"... so far VS Code has how many plugins? and how many users compared to other editors (excluding the cli editors vim/emacs etc). Yeah, sublime is faster and has a lot of aging plugins that haven't kept up... and there are IDEs that do more. Those IDEs are all much slower in my experience, and even Sublime is outmatched in terms of plugins. Because it's just so damned accessible with VS Code. If it runs good enough on the hardware you're using, wtf does it matter?
- deleted 10y ago
  [deleted]
- hliyan 10y ago
  Historically, I have found that dismissing an otherwise effective technology due to performance is a bad idea. Fifteen years ago I dismissed Java in favour of C++ because at the time the JVM was about 25 times slower than native. Now I regret not investing more time learning Java. I suspect the same will be true of HTML/JS apps in the next few years. Hardware and performance improvements will likely erase any differences.
  - rco8786 10y ago
    Yes! Right now Electron is the easiest way to build cross OS desktop apps, bar none. Just like Java was the easiest way to write cross platform code back then. Dismissing it for performance reasons is a fool's errand. The performance issues are fixable and we're already seeing them get fixed. Bold prediction - JavaScript(or rather, a future incarnation of it resembling es7/es8) will be the lingua franca for all platforms(web, desktop, and mobile) within a decade.
  - psyc 10y ago
    15 years ago, I believed that one day, generational garbage collection would be so good that I wouldn't have to think about it. I'm no longer holding my breath for that day.
  - blub 10y ago
    I also dismissed Java for a long time until a few years ago when I developed a mobile project in Java and unfortunately did encounter over-architecting and lack of interest in performance as expected. On the other hand, I can't say I disliked using the language, even if I found it quite restrictive. Java is a pragmatic tool, it's not about fun or expressiveness but making a team of average or better engineers build something that works. And it does that very well. Now that I've had that experience, I know it's not for me, but I can understand when a tool like Java makes sense. JavaScript vs anything else is not the same as C++ vs Java, because JavaScript is not an effective technology to build software applications in. It never was and likely won't become one. It has a weak type system and non-existant standard library. Must be run in a packaged browser. Anything UI-related must be done by using a document markup language and style sheets. The fact that any app developed in it is guaranteed to be inefficient and sluggish is just the cherry on top.
- psyc 10y ago
  I'm a long-time game developer, and plenty smug most of the time about the absurd waste of resources in modern software development. However, aside from the principle of the thing... I use VSCode all day, every day. Most of the time, I'd have no way of telling that it wasn't native. It's fast and responsive. I can't think of anything about it that seems laggy, and that's on a 4 year old laptop. HOWEVER, I have several times seen it get into a state where it's unusably slow. As in, type a character, and it shows up 500 ms later. Now, maybe this is a bug that can be fixed. Or, maybe it's a fundamental problem with trying to make an app that forces you to effectively work in a VM, all the time. Anyway, I still wouldn't have believed, 5 years ago, that a JS/HTML/CSS app in a browser could be so snappy, overall. Maybe it's just a matter of time before perf is great across the board. Or, maybe, like heap-walking GCs, they will always be fundamentally prone to pathological cases, because the whole idea was fundamentally flawed from the start.
- 13years 10y ago
  Actually, its the other way around. The web platform is the future even within the realm of performance. Once technologies like Servo and Web Assembly become part of the standard platform, it will be the preferred platform for performance reasons. There will likely be nothing that can give you the same performance and also be cross OS platform.
  - thomastjeffery 10y ago
    There will always be portable C. There will always be GTK/Qt/etc. The only thing that is really incompatible is Windows, and Microsoft working hard to make that less and less true. Servo will be a drastic improvement, though.
- johnfn 10y ago
  As usual for hacker news, the top comment on a really insightful article has nothing to do with the article whatsoever and is instead a surface level criticism about something vaguely related.
- city41 10y ago
  VS code is free and available on all three major OSes. Download it and give it a shot, you may be pleasantly surprised.
- GordonS 10y ago
  I would have said the same - before actually trying it. Turns out VS Code is actually surprisingly fast! Startup time is only marginally slower than notepad (and I have several plugins added), and performance when running for things like search and replace is super fast. Try it, it will surprise you.
- deleted 10y ago
  [deleted]
pasta 10y ago
What I don't get is why they just arent using a stripped down version of Visual Studio for this. But maybe VSC is more like a test product for Microsoft to see how development in Javascript works out.
- paavohtl 10y ago
  Visual Studio's codebase is 20 years old, and it wasn't built with cross-platform support in mind. It uses WPF as the UI toolkit, which is only supported on Windows. Stripping it down would most likely take an order of magnitude more work than just writing a new editor from scratch.
  - TomMarius 10y ago
    Do you have a source on the usage of WPF? Since it's a really new product compared to Visual Studio itself, I'd be surprised. Anyways, implementing something like a WPF-Gtk shim is not hard, especially for someone as big as Microsoft. The problem, AFAIK, lies in the usage of Windows API.
    - contextfree 10y ago
      Core parts of VS's UI (editor, shell) were rewritten in WPF in VS2010, and it's been the default framework for anything newly added or overhauled since then. Some parts of VS still use other UI frameworks though, which makes it even harder to port. (and as you say the UI stuff is just one aspect of VS's very broad Windows API usage).
    - mappu 10y ago
      >Do you have a source on the usage of WPF? Since it's a really new product compared to Visual Studio itself, I'd be surprised. The parent comment was talking about Visual Studio itself, not VS Code.
      - y4mi 10y ago
        Heh, yes and he did understand that as well. I actually had to look up the release dates because of your comment :) > Windows Presentation Foundation (or WPF) is a graphical subsystem [...] was initially released as part of .NET Framework 3.0[...]. > .NET Framework 3.0. release date >> 2006-11-06 > Visual Studio Release Date >> First entry on Wikipedia is Visual Studio 97 (1997). It was already Version 5 at that point. So even older I guess. Professionally speaking WPF is still pretty young. Or at least a lot of developers think like that . There is still a lot of Software being maintained in Visual Basic, Windows Forms and whatever previous Frameworks existed. though it is pretty mainstream at this point, so most people just starting with the Microsoft SDKs never touch anything earlier than WPF.
z3t4 10y ago
commonjs modules have lifetime cache ability. the more popular a module is the more likely it will already be stored locally. they can also be pushed by the server via package.json
jafingi 10y ago
There is a spelling mistake in the module registration ;-) mimetype, not minetype.
z3t4 10y ago
the small benefit of minifying is out weight by using a "compile" to JS language that usually produce much more code :P
jalfresi 10y ago
Love VSCode but still getting 100% cpu usage for php process on OSX. Great for Go dev though!
- chrisper 10y ago
  For Go I prefer Gogland
Jazcash 10y ago
I switched to VSCode in a heartbeat after many years of Sublime. I love Sublime, but there are countless more benefits to using VSCode over it, and having 1 second slower startup time is well worth them.
- AtticusTheGreat 10y ago
  Such as?
  - ggregoire 10y ago
    - A major patch every month - The amazing support on GitHub: https://github.com/Microsoft/vscode/issues https://github.com/Microsoft/vscode/issues
    - tomc1985 10y ago
      "A major patch every month" is a plus?
      - kylecordes 10y ago
        Not patch in the sense of fixing a pile of brokenness, rather a rapid, ongoing series of improvements. The ecosystem is evolving fast, a slowly changing tool falls behind.
        tomc1985 10y ago
        I guess I am of the camp where I don't want my software changing very often.
        hdhzy 10y ago
        Then sublime is just perfect for you looking at their release schedule...
        Rapzid 10y ago
ChrisCinelli 10y ago
A little more than 1 year ago, I started experimenting with new editors. I move through Sublime, VSCode and Atom. VSCode felt very good but at that time it was missing a few features I needed it. I end up sticking with Atom. So far I think it is great. If I have some time for another exploration I will take another look at VSCode and diving in WebStorm.
pperusse 10y ago
Was I the only one surprised with the variable minetypes: ['application/x-php'], focus on minetypes instead of mimetypes. I guess they have a reason for keeping it that way, although if such a typo exists unfixed in the codebase, that gives you a general hint of the overall codebase quality.
- pperusse 10y ago
  Well, I went into the source code and indeed it was mimetypes in the source. It seems just a typo that went in when writing the post.
- oblio 10y ago
  You're extrapolating from 1 minor typo in a presentation. If I were to judge you based on just this comment, my impression about you would be far worse than your opinion about their code base quality :) On a more serious note, Microsoft is one of the biggest software companies. It also consistently delivers high quality products to its customers. Products of incredible complexity such as Windows, Office or .NET. They couldn't do that without good engineering practices. And specifically in this case, the Visual Studio Code team wouldn't be able to deliver very complex features so often if their code quality and overall engineering wasn't solid. Have you ever read any of their release notes? Have you noticed the frequency of their releases? Those alone should make you ponder for a while ;)
matwood 10y ago
I like VSCode and use it often, but Intellij is still so 'smart' it is hard to leave. Editing Terraform configs across many files? Intellij is the best I have seen at remaining context aware, following variables and marking errors. Same thing with JS, or even random things like nginx configs.
- carussell 10y ago
  Sounds like a good way to identify deficiencies in the Language Server Protocol[1] and/or the server implementations themselves. 1. https://code.visualstudio.com/blogs/2016/06/27/common-language-protocol https://code.visualstudio.com/blogs/2016/06/27/common-langua...
- Achshar 10y ago
  idk, I personally think if you need that kind of deep learning in your code then you are repeating yourself too much. I wrote a 30k line project with sublime and never faced any issues. Everything is as snappy as it was at 1k lines. Never needed intellij level code context awareness. I also worked on some android app some time ago and I probably could not have gone far without intellisense. So I think it depends on the language. Java is a lot more verbose than say php or javascript.
tmsldd 10y ago
I know there are a lot of fans of VSCode (and also VisualStudio).. I use it frequently .. My problem with them is that no matter how fast computers get and how much memory it have, VScode and VStudio will be still slow.. I mean, the tools are great but I'm just wondering if java script was really the right approach...
Timothycquinn 10y ago
For naysayers, Electron only has to support one browser flavor and one version, which eliminates one of the biggest disadvantages of building Web based apps. With Electron and similarly with nw.js, the performance can be close to par with native apps without the cross compilation issues of native c++ frameworks like Qt. And with Electron, if you want to write some native code in C/C++, you can integrate that also. The only downsides I see is protecting closed source code and the lack of Mobile support, which is not coming any time soon due to Apple blocking Google V8 engine from their platform due to V8's use of JIT compilation.
- deleted 10y ago
  [deleted]
- m0a0t0 10y ago
  "the performance can be close to par with native apps" That has not been my experience with any electron app. They are dog slow across the board
  - thomasrognon 10y ago
    Does that include VS Code? VS Code feels very responsive to me. I even replaced notepad++ on my Windows machines with it.
    - thomastjeffery 10y ago
      VScode is the best electron app I have used, but it still feels a little bloated, even on my very high latency display. We're just so spoiled with super responsive GUI toolkits, and that's how it should be, especially in an editor. I'll stick with emacs for now, until I finish writing my own editor.
- tomc1985 10y ago
  Though at the cost of a ridiculous amount of processing overhead because you've chosen to forsake nearly every native programming feature the OS provides, in favor of an HTML engine
deleted 10y ago
[deleted]
thomastjeffery 10y ago
Interesting article. VScode shows off a fantastic design by being responsive enough to use, and still using electron for drawing. It's a great editor, but a lot of us (myself included) care a great deal about latency and performance in a text editor. It's our home, and we like it to be clean and organized. Kudos to the VScode team for doing such a great job minimizing the headache that is electron, and building a very usable editor, but I'll stick to Emacs for now.

208 points by eklavyaa 10y ago

Personally I think it's a biggest mistake to use browser engine for a text editor. We already knew how slow and clunky the browsers are and thanks to vscode and atom our text editors are becoming the same. I would stick to sublime text and vim for as long as I could. /rant

flohofwoe 10y ago
Did you actually give VSCode a try before making such statements? I use both (neo)vim and VSCode (with vim key bindings, sacrilege!) daily. Vim starts up faster (vim is instantly vs about 1 second for VSCode), but once you're in the editor it depends what you do in it. For instance the standard python syntax highlighter in vim is much slower in vim for files with a few hundred to a few thousand lines of code compared to VSCode. Setting up a C++ dev environment and debugger via vim plugins is hit and miss, in VSCode it's just a few seconds to install the extension, and step-debugging is snappier then in 'native tools' (e.g. Xcode). TL;DR: it's not Electron or Javascript which makes editors slow, it's how the code is written.
- tjoff 10y ago
  "TL;DR: it's not Electron or Javascript which makes editors slow, it's how the code is written." It would not have been humanly possible to get something like Spotify (we have lists of text and icon-sized images) so resource intensive in any other language. Now if you want to spend ten (hundred?) times the effort to actually make javascript do something decent I truly hope you get pleasure from that sadistic adventure.
  - flohofwoe 10y ago
    I don't know, writing extensions for VSCode in Typescript is actually quite pleasant. Sure it would be better to have a super-performant, super-small, cross-platform runtime environment. But what would that be? Qt? Java? .NET? Or another roll-your-own UI kit? PS: I think Spotify should have simply stayed in the browser, the desktop app is redundant.
    - tjoff 10y ago
      Why not Qt? And, since this is Microsoft, why not take this opportunity to develop the backend in .NET core. But I yes the biggest impact javascript will have on mankind is that noone will ever be bothered to create a good foundation for cross platform applications. The desktop app is absolutely paramount for Spotify to stay relevant. Not sure if I've seen or heard of anyone using it in the browser (not that that is relevant, but I'd stop using it the very second I can't use it as a standalone app).
      - roblabla 10y ago
        Because Qt is a huge library. And it's not even really native outside of Linux KDE (though it's the closest we'll get cross-platform wise).
        Johnny_Brahms 10y ago
        I don't want to be a part of the anti-electron crowd,but for something like a text editor qt will most certainly be smaller than electron.
        mixedCase 10y ago
        It is huge, but so is Electron. It's as native as it gets, it imitates native widgets perfectly and allows the designer to easily recreate every element of a particular OS' HIGs with the use of stylesheets and native code. In before "doesn't look native in my macOS": Because the people writing in cross-plat tools usually don't care about getting every detail right, they just want their app to run well everywhere. But Qt does allow the developer to nail those details without too much effort if he actually cares. The only problem with Qt is C++.
  - z3t4 10y ago
    use a stepping debugger to see what it does. then remove stuff that dont add value.
  - derefr 10y ago
    Is Spotify's resource-intensiveness due to things it's actively doing in Javascript (i.e. a lot of procedural code running all the time), or is it due to things it sets up the DOM to do (i.e. a really complicated page that the renderer chokes on)?
- Razengan 10y ago
  VS Code uses 13% CPU when idle due to blinking cursor rendering https://news.ycombinator.com/item?id=13940014 https://news.ycombinator.com/item?id=13940014 Edit: Ah a bug. I still hate apps that don't use my OS's native UI controls though; even if you can stomach the inconsistencies in look and feel, you DO most definitely lose out on many features that the OS would give you for free.
  - flohofwoe 10y ago
    That was fixed a few days later with the March update: https://github.com/Microsoft/vscode/issues/22900 https://github.com/Microsoft/vscode/issues/22900
  - maccard 10y ago
    That was a bug and can easily happen in native software too.
    - hashhar 10y ago
      And the biggest point is, it was a Chromium bug. Recently the Chromium team also breaked special keys (Home, PgDown, PgUp, End, Insert etc.) over RDP which caused a lot of issues for people using VSCode.
      - Rapzid 10y ago
        Wow, how do you even break keys over RDP from inside your app?! Do you have a link; I'm curious about the root cause. Some here may recall that early VS Code had a but where drag to highlight and menu option highlighting on mouse-over was busted in Virtual Box. So crazy and also a chromium bug.
        hashhar 10y ago
        The issue contains a link to the related Chromium bug where I think you can follow up. https://github.com/Microsoft/vscode/issues/24107 https://github.com/Microsoft/vscode/issues/24107 I don't know for a fact that it is RDP but it's the common factor among other people with the same issue.
- abrkn 10y ago
  I switched from Atom to VS Code a few weeks ago and find VS Code's performance to be excellent. Haven't used Atom since.
  - dolzenko 10y ago
    Any idea on what exactly VS Code did better to achieve that performance compared with Atom?
    - killercup 10y ago
      Plugins don't run on the UI thread IIRC
      - Rapzid 10y ago
        You do. They also have some really smart people(I'm assuming more than one, but at least one has posted on HN about editor optimizations they have made) who seem to pull out all the stops on monaco to produce a very fast "smart" text editor. Lots of good architecture decisions made. The marriage with TypeScript has also worked out well; it's on fire and coffee is smouldering. This helps with getting people to jump in and contribute.
  - swozey 10y ago
    Were you a heavy Atom plugin user? I'm afraid I'll leave and all of the great plugins won't convert.
    - F2 10y ago
      Which plugins?
    - andrewguenther 10y ago
      90% of my Atom plugins were built-in for VSCode. * Terminal built-in * Sublime style Alt-O for header file switching * Minimap * Javascript/Typescript support made a lot of my plugins obsolete I have language plugins installed for Dockerfiles, protobuf, and a few others, but VSCode felt really complete out-of-the-box. I didn't feel the need to install a ton of plugins to make it useable like I did for Atom.
mercer 10y ago
Personally I think that trotting out this argument in every single post about VSCode/Atom/Electron/etc. serves absolutely no good purpose at this point (other than upvotes or the pleasure of expressing an opinion, perhaps), but I'm happy to be corrected. That said, I'm also still using Sublime Text / vim primarily because they do feel faster on startup and handle big files well. But I think rationally it would make sense for me to move to VSCode, because 1) my code editor is almost always open, and 2) I rarely need to edit really large files, and 3) VSCode is plenty fast for pretty much all other use cases and offers a whole bunch of advantages over ST. Atom I'm less sure of. It seems to get faster every few months that I give it a spin, but it still feels 'laggier' even in normal use, which is definitely a problem for me.
- nottorp 10y ago
  Well, the main question is still "why oh why?". It's not like Microsoft can't afford to pay developers to do something native. Also, calling it Visual Studio is very deceptive. Most devs know VS to mean something completely different.
  - mercer 10y ago
    > Well, the main question is still "why oh why?". It's not like Microsoft can't afford to pay developers to do something native. Yeah I do share that question with you and would love an answer from the team! > Also, calling it Visual Studio is very deceptive. Most devs know VS to mean something completely different. Could you clarify what you mean with that? Accusing me of being 'deceptive' seems a bit unwarranted and disproportionately antagonistic, considering that as far as I can tell I've made a clear distinction between VSCode and VS (meaning Visual Studio proper), and considering that I can't think of any reason why I would choose to deceive in this matter. Where did I go wrong?
    - TeMPOraL 10y ago
      I think the parent didn't mean to accuse you, but Microsoft, for re-using the "Visual Studio" brand in a product so completely different that it deserves a distinct name. Reminds me of how pissed I was with Amazon calling their line of regular Android tablets "Kindle Fire". I don't know what the sales teams there think, but for customers, the "Kindle" brand was literally synonymous with "that e-ink screen thing".
simion314 10y ago
I am wondering if they can switch the UI part, say use the Canvas and WebGL(there are some libs for GUI with GL but I do not test them)
- simooooo 10y ago
  Well they're currently using Dom elements with CSS. So would likely be a massive effort to reimplement all it as proper web GL. Which is kinda what a browser does internally anyway
- 13years 10y ago
  There is likely no need. Hopefully a technology like Servo will get built into Electron. If that happens, there shouldn't be any issues related to performance. Servo in theory can be even faster than native libraries thanks to its use of retained mode. https://air.mozilla.org/bay-area-rust-meetup-february-2016/#@25m50s https://air.mozilla.org/bay-area-rust-meetup-february-2016/#...
  - hashhar 10y ago
    Servo is quite good actually. If you haven't already, try using browser.html from Mozilla which uses Servo and HTML for the UI.
    - epoch1970 10y ago
      I wouldn't consider Servo to be "quite good", at least in its present state. The Browser.html UI is quite minimal, in the sense that it really doesn't do much at all. It's basically a list of tabs along the right side. I also find it quite laggy, and sometimes it locks up completely. I'm not sure why you think people should be impressed with it. As for Servo itself, there are noticeable rendering problems with pretty much every web site I've ever tried with it. Even the servo.org home page had rendering glitches when I last tried it several days ago! The scrolling is very broken under macOS. I've also had it crash now and then. Maybe it will get better in the future. But at this time I'd consider Servo to be pre-alpha quality software. Trying to impress people with it would probably do more harm than good. They'll likely encounter problems with it right away, and it won't leave a good impression on them.
9935c101ab17a66 10y ago
Your comment adds nothing new to the frequent and tired war (native vs electron). I get it, you prefer Vim and Sublime (I find this quite funny because I can only suppose critics attacked Sublime Text with the same arguments you use now) Either way, Atom/VSCode have developed a large following which encompasses lots of talented and smart people. They both cannot be completely summed up with the description "slow and clunky." They are absolutely not perfect, but if you really cannot see any of the many reasons people use them, you're being left behind and I strongly suggest you refrain from commenting.
mrmondo 10y ago
I could not agree more, this is why every time I try atom I go back to sublime, that's really only one example of many - there's a massive difference between javascript 'desktop web app frames' and native applications written in ObjC/Swift/QT etc... between the terrible perceived(?) latency of javascript apps and the memory usage to be honest I just delete the app and find something else when I come across them.
- jdub 10y ago
  Sublime is mostly written in Python. Yes, there are some native elements, particularly where performance is paramount.
  - mrmondo 10y ago
    Sublime is actually mostly native c++, but it has python bindings for its API
- Ardren 10y ago
  I put off even looking at VS Code for a while because of the poor performance of Atom. But when I tried it, I was really surprised at how much faster VS Code was. It's changed my opinion of electron based programs.
  - tracker1 10y ago
    I had the same experience... after atom and brackets, I was like, sure... I installed it to make fun of it... but it actually ran well. It's been my daily driver ever since, and better with each release. The integrated terminal is far and away my favorite feature, second would be the git+diff integration... though merging/rebasing needs a good story.
pcarolan 10y ago
This is called hacker news. Things that work well should be elevated, by trial, above all else. Try it. Seriously.
josteink 10y ago
> Personally I think it's a biggest mistake to use browser engine for a text editor. We already knew how slow and clunky the browsers are and thanks to vscode and atom our text editors are becoming the same That's an interesting claim, given that Visual Studio (not VS Code) is native through and through and still it's orders of magnitude slower to work with on any sizable code-base compared to the "slow" editor VS Code. It's almost as if you could say that on modern hardware the architecture of the application dictates overall performance much more than the technology used to implement it. But yeah, that would certainly be madness, so let's not go there, eh?
- saurik 10y ago
  Just because you can make a slower text editor doesn't really demonstrate anything unless the person you are arguing against would have used that slower one (and "architecture" is definitely something constrained by an implementation decision as critical as "implemented using a web browser").
  - josteink 10y ago
    Sure. Any concrete implementation detail constrains your architecture and freedom to some extent. But VS Code first and foremost uses a web-browser for UI. How much does the choice of a UI-technology really constrain the rest of your application and its architecture? I would argue that with a good architecture, the choice of UI-platform should place near zero effective constraints on the rest of your application, how it's structured and how it performs. It should certainly not be a critical component of your overall design, it should be an implementation detail. Are you arguing otherwise? Can you come up with some concrete examples where the choice of UI-library causes troubles other places in the application? If not, it seems you're more or less agreeing with my original statement. And as such, I don't see any fundamental problems using a web-browser in a text-editor.
  - tracker1 10y ago
    Then go ahead and "do it better"... so far VS Code has how many plugins? and how many users compared to other editors (excluding the cli editors vim/emacs etc). Yeah, sublime is faster and has a lot of aging plugins that haven't kept up... and there are IDEs that do more. Those IDEs are all much slower in my experience, and even Sublime is outmatched in terms of plugins. Because it's just so damned accessible with VS Code. If it runs good enough on the hardware you're using, wtf does it matter?
deleted 10y ago
[deleted]
hliyan 10y ago
Historically, I have found that dismissing an otherwise effective technology due to performance is a bad idea. Fifteen years ago I dismissed Java in favour of C++ because at the time the JVM was about 25 times slower than native. Now I regret not investing more time learning Java. I suspect the same will be true of HTML/JS apps in the next few years. Hardware and performance improvements will likely erase any differences.
- rco8786 10y ago
  Yes! Right now Electron is the easiest way to build cross OS desktop apps, bar none. Just like Java was the easiest way to write cross platform code back then. Dismissing it for performance reasons is a fool's errand. The performance issues are fixable and we're already seeing them get fixed. Bold prediction - JavaScript(or rather, a future incarnation of it resembling es7/es8) will be the lingua franca for all platforms(web, desktop, and mobile) within a decade.
- psyc 10y ago
  15 years ago, I believed that one day, generational garbage collection would be so good that I wouldn't have to think about it. I'm no longer holding my breath for that day.
- blub 10y ago
  I also dismissed Java for a long time until a few years ago when I developed a mobile project in Java and unfortunately did encounter over-architecting and lack of interest in performance as expected. On the other hand, I can't say I disliked using the language, even if I found it quite restrictive. Java is a pragmatic tool, it's not about fun or expressiveness but making a team of average or better engineers build something that works. And it does that very well. Now that I've had that experience, I know it's not for me, but I can understand when a tool like Java makes sense. JavaScript vs anything else is not the same as C++ vs Java, because JavaScript is not an effective technology to build software applications in. It never was and likely won't become one. It has a weak type system and non-existant standard library. Must be run in a packaged browser. Anything UI-related must be done by using a document markup language and style sheets. The fact that any app developed in it is guaranteed to be inefficient and sluggish is just the cherry on top.
psyc 10y ago
I'm a long-time game developer, and plenty smug most of the time about the absurd waste of resources in modern software development. However, aside from the principle of the thing... I use VSCode all day, every day. Most of the time, I'd have no way of telling that it wasn't native. It's fast and responsive. I can't think of anything about it that seems laggy, and that's on a 4 year old laptop. HOWEVER, I have several times seen it get into a state where it's unusably slow. As in, type a character, and it shows up 500 ms later. Now, maybe this is a bug that can be fixed. Or, maybe it's a fundamental problem with trying to make an app that forces you to effectively work in a VM, all the time. Anyway, I still wouldn't have believed, 5 years ago, that a JS/HTML/CSS app in a browser could be so snappy, overall. Maybe it's just a matter of time before perf is great across the board. Or, maybe, like heap-walking GCs, they will always be fundamentally prone to pathological cases, because the whole idea was fundamentally flawed from the start.
13years 10y ago
Actually, its the other way around. The web platform is the future even within the realm of performance. Once technologies like Servo and Web Assembly become part of the standard platform, it will be the preferred platform for performance reasons. There will likely be nothing that can give you the same performance and also be cross OS platform.
- thomastjeffery 10y ago
  There will always be portable C. There will always be GTK/Qt/etc. The only thing that is really incompatible is Windows, and Microsoft working hard to make that less and less true. Servo will be a drastic improvement, though.
johnfn 10y ago
As usual for hacker news, the top comment on a really insightful article has nothing to do with the article whatsoever and is instead a surface level criticism about something vaguely related.
city41 10y ago
VS code is free and available on all three major OSes. Download it and give it a shot, you may be pleasantly surprised.
GordonS 10y ago
I would have said the same - before actually trying it. Turns out VS Code is actually surprisingly fast! Startup time is only marginally slower than notepad (and I have several plugins added), and performance when running for things like search and replace is super fast. Try it, it will surprise you.
deleted 10y ago
[deleted]

pasta 10y ago

What I don't get is why they just arent using a stripped down version of Visual Studio for this. But maybe VSC is more like a test product for Microsoft to see how development in Javascript works out.

paavohtl 10y ago
Visual Studio's codebase is 20 years old, and it wasn't built with cross-platform support in mind. It uses WPF as the UI toolkit, which is only supported on Windows. Stripping it down would most likely take an order of magnitude more work than just writing a new editor from scratch.
- TomMarius 10y ago
  Do you have a source on the usage of WPF? Since it's a really new product compared to Visual Studio itself, I'd be surprised. Anyways, implementing something like a WPF-Gtk shim is not hard, especially for someone as big as Microsoft. The problem, AFAIK, lies in the usage of Windows API.
  - contextfree 10y ago
    Core parts of VS's UI (editor, shell) were rewritten in WPF in VS2010, and it's been the default framework for anything newly added or overhauled since then. Some parts of VS still use other UI frameworks though, which makes it even harder to port. (and as you say the UI stuff is just one aspect of VS's very broad Windows API usage).
  - mappu 10y ago
    >Do you have a source on the usage of WPF? Since it's a really new product compared to Visual Studio itself, I'd be surprised. The parent comment was talking about Visual Studio itself, not VS Code.
    - y4mi 10y ago
      Heh, yes and he did understand that as well. I actually had to look up the release dates because of your comment :) > Windows Presentation Foundation (or WPF) is a graphical subsystem [...] was initially released as part of .NET Framework 3.0[...]. > .NET Framework 3.0. release date >> 2006-11-06 > Visual Studio Release Date >> First entry on Wikipedia is Visual Studio 97 (1997). It was already Version 5 at that point. So even older I guess. Professionally speaking WPF is still pretty young. Or at least a lot of developers think like that . There is still a lot of Software being maintained in Visual Basic, Windows Forms and whatever previous Frameworks existed. though it is pretty mainstream at this point, so most people just starting with the Microsoft SDKs never touch anything earlier than WPF.

z3t4 10y ago

commonjs modules have lifetime cache ability. the more popular a module is the more likely it will already be stored locally. they can also be pushed by the server via package.json

jafingi 10y ago

There is a spelling mistake in the module registration ;-) mimetype, not minetype.

z3t4 10y ago

the small benefit of minifying is out weight by using a "compile" to JS language that usually produce much more code :P

jalfresi 10y ago

Love VSCode but still getting 100% cpu usage for php process on OSX. Great for Go dev though!

chrisper 10y ago
For Go I prefer Gogland

Jazcash 10y ago

I switched to VSCode in a heartbeat after many years of Sublime. I love Sublime, but there are countless more benefits to using VSCode over it, and having 1 second slower startup time is well worth them.

AtticusTheGreat 10y ago
Such as?
- ggregoire 10y ago
  - A major patch every month - The amazing support on GitHub: https://github.com/Microsoft/vscode/issues https://github.com/Microsoft/vscode/issues
  - tomc1985 10y ago
    "A major patch every month" is a plus?
    - kylecordes 10y ago
      Not patch in the sense of fixing a pile of brokenness, rather a rapid, ongoing series of improvements. The ecosystem is evolving fast, a slowly changing tool falls behind.
      - tomc1985 10y ago
        I guess I am of the camp where I don't want my software changing very often.
        hdhzy 10y ago
        Then sublime is just perfect for you looking at their release schedule...
        Rapzid 10y ago

ChrisCinelli 10y ago

A little more than 1 year ago, I started experimenting with new editors. I move through Sublime, VSCode and Atom. VSCode felt very good but at that time it was missing a few features I needed it. I end up sticking with Atom. So far I think it is great. If I have some time for another exploration I will take another look at VSCode and diving in WebStorm.

pperusse 10y ago

Was I the only one surprised with the variable minetypes: ['application/x-php'], focus on minetypes instead of mimetypes. I guess they have a reason for keeping it that way, although if such a typo exists unfixed in the codebase, that gives you a general hint of the overall codebase quality.

pperusse 10y ago
Well, I went into the source code and indeed it was mimetypes in the source. It seems just a typo that went in when writing the post.
oblio 10y ago
You're extrapolating from 1 minor typo in a presentation. If I were to judge you based on just this comment, my impression about you would be far worse than your opinion about their code base quality :) On a more serious note, Microsoft is one of the biggest software companies. It also consistently delivers high quality products to its customers. Products of incredible complexity such as Windows, Office or .NET. They couldn't do that without good engineering practices. And specifically in this case, the Visual Studio Code team wouldn't be able to deliver very complex features so often if their code quality and overall engineering wasn't solid. Have you ever read any of their release notes? Have you noticed the frequency of their releases? Those alone should make you ponder for a while ;)

matwood 10y ago

I like VSCode and use it often, but Intellij is still so 'smart' it is hard to leave. Editing Terraform configs across many files? Intellij is the best I have seen at remaining context aware, following variables and marking errors. Same thing with JS, or even random things like nginx configs.

carussell 10y ago
Sounds like a good way to identify deficiencies in the Language Server Protocol[1] and/or the server implementations themselves. 1. https://code.visualstudio.com/blogs/2016/06/27/common-language-protocol https://code.visualstudio.com/blogs/2016/06/27/common-langua...
Achshar 10y ago
idk, I personally think if you need that kind of deep learning in your code then you are repeating yourself too much. I wrote a 30k line project with sublime and never faced any issues. Everything is as snappy as it was at 1k lines. Never needed intellij level code context awareness. I also worked on some android app some time ago and I probably could not have gone far without intellisense. So I think it depends on the language. Java is a lot more verbose than say php or javascript.

tmsldd 10y ago

I know there are a lot of fans of VSCode (and also VisualStudio).. I use it frequently .. My problem with them is that no matter how fast computers get and how much memory it have, VScode and VStudio will be still slow.. I mean, the tools are great but I'm just wondering if java script was really the right approach...

Timothycquinn 10y ago

For naysayers, Electron only has to support one browser flavor and one version, which eliminates one of the biggest disadvantages of building Web based apps. With Electron and similarly with nw.js, the performance can be close to par with native apps without the cross compilation issues of native c++ frameworks like Qt. And with Electron, if you want to write some native code in C/C++, you can integrate that also. The only downsides I see is protecting closed source code and the lack of Mobile support, which is not coming any time soon due to Apple blocking Google V8 engine from their platform due to V8's use of JIT compilation.

deleted 10y ago
[deleted]
m0a0t0 10y ago
"the performance can be close to par with native apps" That has not been my experience with any electron app. They are dog slow across the board
- thomasrognon 10y ago
  Does that include VS Code? VS Code feels very responsive to me. I even replaced notepad++ on my Windows machines with it.
  - thomastjeffery 10y ago
    VScode is the best electron app I have used, but it still feels a little bloated, even on my very high latency display. We're just so spoiled with super responsive GUI toolkits, and that's how it should be, especially in an editor. I'll stick with emacs for now, until I finish writing my own editor.
tomc1985 10y ago
Though at the cost of a ridiculous amount of processing overhead because you've chosen to forsake nearly every native programming feature the OS provides, in favor of an HTML engine

deleted 10y ago

[deleted]

thomastjeffery 10y ago

Interesting article. VScode shows off a fantastic design by being responsive enough to use, and still using electron for drawing. It's a great editor, but a lot of us (myself included) care a great deal about latency and performance in a text editor. It's our home, and we like it to be clean and organized. Kudos to the VScode team for doing such a great job minimizing the headache that is electron, and building a very usable editor, but I'll stick to Emacs for now.