22 ms·

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

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++.
        roblabla 10y ago
        Been doing some research about my problems with qt. I found some interesting stuff. In qt6, there will be "native components" that use the actual underlying OS widgets[0]. They'll be less stylable, but will integrate better with the native look and feel. That should take care of the annoying cross-platform problems. The other problem left is how big it actually is. As it turns out, it's possible with the LGPL to statically link your program and still comply with the license[1]. Basically, you just need to provide a way to download the .o files so they can be relinked against a different version of Qt. Thanks to this, it should be possible to create (relatively) lightweight, statically-linked binaries of Qt software. As far as the C++ is involved... There are qt bindings for just about every other language out there. Just today, bindings for go were released[2]. The future is bright for qt and cross-platform apps. [0] http://blog.qt.io/blog/2017/02/06/native-look-feel/ http://blog.qt.io/blog/2017/02/06/native-look-feel/ [1]: https://news.ycombinator.com/item?id=4302517 https://news.ycombinator.com/item?id=4302517 [2]: https://news.ycombinator.com/item?id=14068525 https://news.ycombinator.com/item?id=14068525
  - 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]

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++.
        roblabla 10y ago
        Been doing some research about my problems with qt. I found some interesting stuff. In qt6, there will be "native components" that use the actual underlying OS widgets[0]. They'll be less stylable, but will integrate better with the native look and feel. That should take care of the annoying cross-platform problems. The other problem left is how big it actually is. As it turns out, it's possible with the LGPL to statically link your program and still comply with the license[1]. Basically, you just need to provide a way to download the .o files so they can be relinked against a different version of Qt. Thanks to this, it should be possible to create (relatively) lightweight, statically-linked binaries of Qt software. As far as the C++ is involved... There are qt bindings for just about every other language out there. Just today, bindings for go were released[2]. The future is bright for qt and cross-platform apps. [0] http://blog.qt.io/blog/2017/02/06/native-look-feel/ http://blog.qt.io/blog/2017/02/06/native-look-feel/ [1]: https://news.ycombinator.com/item?id=4302517 https://news.ycombinator.com/item?id=4302517 [2]: https://news.ycombinator.com/item?id=14068525 https://news.ycombinator.com/item?id=14068525
- 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]