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.
I love Sublime (it's my daily driver) but I've found that language support for VS-code is generally much better than Sublime. Node/ES6 support is generally much cleaner. PHP debugging in particular is very painful in Sublime (not-worth-the-hassle level painful), though to be fair PHP debugging is awful-by-default. The VS code plugins for it are pretty great though.
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.
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
Native programming features the OS provides are also not free: it's still similar code drawing things on the screen, making sure they are properly aligned. HTML/CSS is a pretty flexible, and it indeed has some overhead compared to most native UI frameworks, but the "ridiculousness" of this overhead is imaginary.
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.
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
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.
"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.
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.
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.
It serves a very important point: showing that mediocrity will not be silently tolerated.
I understand that productivity is important and a significant number of web developers can't seem to learn anything else except JavaScript or worse, don't want to, but such things as professional pride, craftsmanship and excellence do exist and are very appreciated.
Those things represent the opposite of building software applications in JavaScript. I don't know why others criticize such apps, but that's why I do it: they are normalizing flawed software and a lousy experience and mixing it with extreme arrogance.
I've had this deep disagreement with various people ever since web apps were invented. The best of the best of these apps sucked then and they still suck now and are a waste of everybody's time.
I just opened a 9.75mb JavaScript file in VS Code and it edits it quite well. It syntax highlights the top of the file immediately, and it does take quite a while for the highlighting to work its way down the file (I'd say about 20 seconds). But as far as editing goes, you can jump anywhere in the file and edit without any hesitation, instantly.
People invest quite a bit of time into their tools. When something new comes along and gains traction, it threatens that investment. Maybe VSCode gets so popular that $EDITOR stops getting updated?
Otherwise, there really isn't any reason why I should care what tools you use.
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.
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.
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.
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.
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.
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.
> 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?
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").
Visual Studio is not native, large parts of it are built in .NET. Hence the slowness.
Note: native means the platform's native toolkit, running with the best performance on that platform.
E.g: Java or C and C++ for Android, C and C++ for Linux, C and C++ and Obj-C for macOS, C and C++ for Windows, etc.
Things that are not native: Python, .NET, Xamarin, JavaScript, Java on anything except Android, etc
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.
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.
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.
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.
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/#...
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
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.
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.
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.
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.
I think the reason this was created was to see if the Monaco editor (the one OneDrive and Azure use to edit files - it's great BTW) in the browser could be put to use to create a general purpose IDE.
Also, stripping down Visual Studio to be cross-platform isn't an easy task.
1. It's WPF and hence depends on Windows only components.
2. It's a lot of C# which covers some assemblies not provided by .NET Core yet.
3. The codebase itself is over 20 years old at this point.
Visual studio is a number of very windows specific COM systems stacked on top of each other. Not to mention that it's a win32 GUI app.
It's not leaving windows. I'm guessing it would be easier to grow vs code into a "full" platform independent IDE than it would be to strip VS into a platform independent VScode equivalent.
VSCode is based upon another project, the Monaco Editor. As best I can tell, it was introduced in late 2013[1]. Creating VSCode on Monaco was probably heavily about reuse at that point since Microsoft specifically wanted an editor for websites anyways.
That assumes that it is possible to strip down Visual Studio without refactoring to an extent that disturbs the development of the main product and causes more work than just developing VS Code from scratch - and that Visual Studio is portable to other platforms.
I'm not sure if this came from the TypeScript team or if it was just a HN commenter, but I remember reading (a theory) that VSCode is, at least to a degree, meant to eventually become a clean rewrite for Visual Studio, or at least reach some degree of feature parity, and that this is why so much energy is put into this (which strikes me as noteworthy, the amount of energy that is).
I'm not experienced with projects as large as this, but I could see how the work they're doing on VSCode would be worthwhile even if they eventually swap the web-based parts with more performant approaches (as the project expands to 'become' VS).
They could use any native GUI toolkit, but then they would not be able to capitalize on the popularity of HTML/CSS/JavaScript for configuration/plugins.
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.
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.
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.
Readit News
- built in terminal
- git integration
to just name a few on top of my head
Sublime fell a sleep to be honest. I have a paid for license and I never use it anymore.
- The amazing support on GitHub: https://github.com/Microsoft/vscode/issues
That has not been my experience with any electron app. They are dog slow across the board
Deleted Comment
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.
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.
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.
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.
I understand that productivity is important and a significant number of web developers can't seem to learn anything else except JavaScript or worse, don't want to, but such things as professional pride, craftsmanship and excellence do exist and are very appreciated.
Those things represent the opposite of building software applications in JavaScript. I don't know why others criticize such apps, but that's why I do it: they are normalizing flawed software and a lousy experience and mixing it with extreme arrogance.
I've had this deep disagreement with various people ever since web apps were invented. The best of the best of these apps sucked then and they still suck now and are a waste of everybody's time.
I just opened a 9.75mb JavaScript file in VS Code and it edits it quite well. It syntax highlights the top of the file immediately, and it does take quite a while for the highlighting to work its way down the file (I'd say about 20 seconds). But as far as editing goes, you can jump anywhere in the file and edit without any hesitation, instantly.
Otherwise, there really isn't any reason why I should care what tools you use.
Also, calling it Visual Studio is very deceptive. Most devs know VS to mean something completely different.
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.
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.
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.
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.
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?
Note: native means the platform's native toolkit, running with the best performance on that platform. E.g: Java or C and C++ for Android, C and C++ for Linux, C and C++ and Obj-C for macOS, C and C++ for Windows, etc.
Things that are not native: Python, .NET, Xamarin, JavaScript, Java on anything except Android, etc
It's changed my opinion of electron based programs.
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.
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.
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 Comment
Deleted Comment
Also, stripping down Visual Studio to be cross-platform isn't an easy task.
1. It's WPF and hence depends on Windows only components.
2. It's a lot of C# which covers some assemblies not provided by .NET Core yet.
3. The codebase itself is over 20 years old at this point.
It's not leaving windows. I'm guessing it would be easier to grow vs code into a "full" platform independent IDE than it would be to strip VS into a platform independent VScode equivalent.
[1]: http://www.itorian.com/2013/11/visual-studio-online-monaco-e...
I'm not experienced with projects as large as this, but I could see how the work they're doing on VSCode would be worthwhile even if they eventually swap the web-based parts with more performant approaches (as the project expands to 'become' VS).
Deleted Comment
If I have some time for another exploration I will take another look at VSCode and diving in WebStorm.
1. https://code.visualstudio.com/blogs/2016/06/27/common-langua...
Deleted Comment