Visual Studio Code: Shipping One of the Largest Microsoft JavaScript Apps(realm.io)
realm.io
Visual Studio Code: Shipping One of the Largest Microsoft JavaScript Apps
https://realm.io/news/GOTO-Alex-Dima-Visual_Studio-Code-JavaScript-Typescript/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+realmio+%28Realm+News%29
147 comments
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.
There might be some places where you could say Sublime still beats VSC, but none of them are worth $60 to me.
Such as?
- built in debugger with consistent/same usage experience regardless of language you are using it with.
- 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.
- 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.
I'm a spacemacs guy, but the debugger in VS Code is freaking excellent. I've never seen a nicer cross-language debugging experience.
- A major patch every month
- The amazing support on GitHub: https://github.com/Microsoft/vscode/issues
- The amazing support on GitHub: https://github.com/Microsoft/vscode/issues
"A major patch every month" is a plus?
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.
I guess I am of the camp where I don't want my software changing very often.
Interestingly, VS Code doesn't feel like it changes fast. Most new features are there to use, but not in your face.
I just realized the other day(as someone using Code since a few months after its initial pub release) that I've actually fallen far behind on the new features. I need to go back through the release notes and try out a lot of the new stuff.
I update every month and it never feels intrusive. Although I usually end up updated after any recovery release(path release) would hit haha :D
I just realized the other day(as someone using Code since a few months after its initial pub release) that I've actually fallen far behind on the new features. I need to go back through the release notes and try out a lot of the new stuff.
I update every month and it never feels intrusive. Although I usually end up updated after any recovery release(path release) would hit haha :D
Then sublime is just perfect for you looking at their release schedule...
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.
> but the "ridiculousness" of this overhead is imaginary.
A few weeks ago:
VS Code uses 13% CPU when idle due to blinking cursor rendering
https://news.ycombinator.com/item?id=13940014
A few weeks ago:
VS Code uses 13% CPU when idle due to blinking cursor rendering
https://news.ycombinator.com/item?id=13940014
As someone who has been hit by every single one of these bugs[1][2][3] but somehow didn't get the VS Code problem I'm not at all convinced that is somehow inherent in using Electron.
I don't think I ever had a "IDE causing high CPU load in" problem in Delphi 2, 3, or 5. I did in Delphi 4, and I have in PowerBuilder, Sybase PowerJ (although there were much worse problems with that!), VB6, Eclipse 2, and I'm sure there are some I've missed.
Bugs suck, but they happen.
[1] http://ridikulouse.blogspot.com.au/2015/02/visual-studio-hig...
[2] http://stackoverflow.com/questions/1369487/speeding-up-tomca...
[3] http://stackoverflow.com/questions/38601171/intellij-idea-20...
I don't think I ever had a "IDE causing high CPU load in" problem in Delphi 2, 3, or 5. I did in Delphi 4, and I have in PowerBuilder, Sybase PowerJ (although there were much worse problems with that!), VB6, Eclipse 2, and I'm sure there are some I've missed.
Bugs suck, but they happen.
[1] http://ridikulouse.blogspot.com.au/2015/02/visual-studio-hig...
[2] http://stackoverflow.com/questions/1369487/speeding-up-tomca...
[3] http://stackoverflow.com/questions/38601171/intellij-idea-20...
That was a bug in Chrome (http://crbug.com/361587), it's not inherent to the technology. VS Code ended up implementing the logic in JS to work around it.
"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
That has not been my experience with any electron app. They are dog slow across the board
Does that include VS Code? VS Code feels very responsive to me. I even replaced notepad++ on my Windows machines with it.
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.
I'll stick with emacs for now, until I finish writing my own editor.
[deleted]
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.
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
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.
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.
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.
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.
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.
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]
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.
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.
Were you a heavy Atom plugin user? I'm afraid I'll leave and all of the great plugins won't convert.
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.
* 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.
Which plugins?
Any idea on what exactly VS Code did better to achieve that performance compared with Atom?
Plugins don't run on the UI thread IIRC
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.
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.
"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.
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.
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.
PS: I think Spotify should have simply stayed in the browser, the desktop app is redundant.
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).
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).
> the biggest impact javascript will have on mankind is that noone will ever be bothered to create a good foundation for cross platform applications
Why isn't Electron a good foundation for cross platform apps? The only possible negative to Electron is that the runtime is gigantic. A decent tradeoff if it means for example the VS Code team can support three OSes and push out rapid updates. I really can't see any downside to this, what am I missing?
Why isn't Electron a good foundation for cross platform apps? The only possible negative to Electron is that the runtime is gigantic. A decent tradeoff if it means for example the VS Code team can support three OSes and push out rapid updates. I really can't see any downside to this, what am I missing?
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).
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++.
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++.
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/ [1]: https://news.ycombinator.com/item?id=4302517 [2]: https://news.ycombinator.com/item?id=14068525
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/ [1]: https://news.ycombinator.com/item?id=4302517 [2]: https://news.ycombinator.com/item?id=14068525
> As far as the C++ is involved... There are qt bindings for just about every other language out there.
Absolutely not. And the ones that do work are ginormous. The Go bindings are LGPL licensed, meaning they aren't an option for most people until Go plugins are available across the board, at least.
With that said, QML does have plenty of bindings, thankfully. And indeed, Qt's future looks bright, while Gtk's uncertain, so the former is definitely the saner option.
Absolutely not. And the ones that do work are ginormous. The Go bindings are LGPL licensed, meaning they aren't an option for most people until Go plugins are available across the board, at least.
With that said, QML does have plenty of bindings, thankfully. And indeed, Qt's future looks bright, while Gtk's uncertain, so the former is definitely the saner option.
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.
VS Code didn't start out like you think it did. More akin to life forming in a petri dish vs sitting down to design the Visual Studio replacement.
From what I recall piecing together it came about internally as MS due to monaco and TypeScript. I'm under the impression it was a TypeScript dogfood/dev environment project. It worked out well and they threw it over the fence to the public where it caught fire.
From what I recall piecing together it came about internally as MS due to monaco and TypeScript. I'm under the impression it was a TypeScript dogfood/dev environment project. It worked out well and they threw it over the fence to the public where it caught fire.
What's the user benefit of a (JavaScript) "desktop" (Electron, nw.js) app vs the same app as a web (browser) app , given that the web app has all the features of the desktop app, when the app won't work without the server ? (if you can't run the server yourself)
Benefits for a web app (non-desktop):
Benefits for a web app (non-desktop):
* User don't have to download the "browser" (Electron or nw.js)
* The user don't need "install" permissions
* The app can be accessed via an URL
* The app runs in a VM (a browser) that don't give full (root) access like a Electron/nw.js app does.
Not à Spotify user but in general:
- a native app can have global shortcuts (very important for a media player)
- you don't accidentally refresh a native app
- native apps don't get purged from memory at random
- UI is generally better, keyboard shortcuts are more consistent
As a web developer that has never touched electron I would imagine the benefit is simple:
* One API that "just works"
* Guaranteed caching of necessary assets
* Access to native features (such as simplified access to the file system)
I could totally see all of this on the browser. But then the file system needs to go to the cloud, we need to consider hipster browsers (like k-meleon and omniweb), and we have to deal with the browser determining how our assets are cached and evicted.
I could totally see all of this on the browser. But then the file system needs to go to the cloud, we need to consider hipster browsers (like k-meleon and omniweb), and we have to deal with the browser determining how our assets are cached and evicted.
It is much easier to navigate to the desktop app than to hunt through browser tabs to change the song etc.
[deleted]
A browser has very limited access to the file system. That's a death knell for a text editor.
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)?
use a stepping debugger to see what it does. then remove stuff that dont add value.
VS Code uses 13% CPU when idle due to blinking cursor rendering
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.
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 was fixed a few days later with the March update: https://github.com/Microsoft/vscode/issues/22900
That was a bug and can easily happen in native software too.
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.
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.
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.
The issue contains a link to the related Chromium bug where I think you can follow up.
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.
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.
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.
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 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.
Come on. There are lots of JS developers who care a lot about "professional pride, craftsmanship and excellence".
Building desktop (or mobile) apps in JS is not compatible with craftsmanship, nor is it compatible with excellence.
To those that truly care about excellence and don't merely pay lip service to it, there is only one way of building: using that platform's native toolkit. For project or ideological reasons one can make a compromise and use something like Qt, Xamarin or wxWidgets, etc.
This leaves JS native-like apps for those that care about doing things fast by only using the knowledge they already have. That would perhaps be understandable, if they admitted that it's a big quality and performance compromise. Yes, we tried our best, but this is the only thing we could do with this budget/team/whatever. Totally fine.
Instead we get uppity devs claiming that desktop apps will be killed and bragging about how they're delivering the best experiences. It's this toxic cocktail of arrogance and lack of ability that is intolerable.
To those that truly care about excellence and don't merely pay lip service to it, there is only one way of building: using that platform's native toolkit. For project or ideological reasons one can make a compromise and use something like Qt, Xamarin or wxWidgets, etc.
This leaves JS native-like apps for those that care about doing things fast by only using the knowledge they already have. That would perhaps be understandable, if they admitted that it's a big quality and performance compromise. Yes, we tried our best, but this is the only thing we could do with this budget/team/whatever. Totally fine.
Instead we get uppity devs claiming that desktop apps will be killed and bragging about how they're delivering the best experiences. It's this toxic cocktail of arrogance and lack of ability that is intolerable.
> This leaves JS native-like apps for those that care about doing things fast by only using the knowledge they already have.
What about the devs who care about shipping a lockstep-feature-parity multiplatform app, and are willing to go through whatever hassles it takes to get "write once, run [with platform-conformant controls + behaviors] anywhere"? Because that—and not "doing things fast" or "only using the knowledge they already have"—is the argument I hear for developing Electron apps.
What would you suggest for those developers? Just give up on their desires and do 10x as much work (likely meaning being 10x as many people) to ship for every platform, like Facebook? Or go through months/years of initial effort to develop a cross-platform UI toolkit abstraction to build their app upon, like the browser chrome of Firefox and Chrome is targeted at? Use something like Java's Swing, and pretend that's better just because "at least it's not Javascript"? Ship a GTK or QT app that doesn't look/work natively on half your platforms?
What about the devs who care about shipping a lockstep-feature-parity multiplatform app, and are willing to go through whatever hassles it takes to get "write once, run [with platform-conformant controls + behaviors] anywhere"? Because that—and not "doing things fast" or "only using the knowledge they already have"—is the argument I hear for developing Electron apps.
What would you suggest for those developers? Just give up on their desires and do 10x as much work (likely meaning being 10x as many people) to ship for every platform, like Facebook? Or go through months/years of initial effort to develop a cross-platform UI toolkit abstraction to build their app upon, like the browser chrome of Firefox and Chrome is targeted at? Use something like Java's Swing, and pretend that's better just because "at least it's not Javascript"? Ship a GTK or QT app that doesn't look/work natively on half your platforms?
When I've worked on multi-platform apps, the case for "write once, run anywhere" has always boiled down to developer hours and current knowledge. Sometimes someone suggests that a single GUI will mean less code and fewer bugs, but the ones with cross-platform GUI experience know that's optimistic.
"10x as much work" is a huge overstatement, especially when platform conformance is a goal.
For native look and feel, I'd pick Qt over Electron any day. The catch is that no toolkit can abstract away all the platform-specific details. A minimum-effort Electron app looks like a web page; a minimum-effort Qt app falls into the uncanny valley.
There can be good reasons to choose Electron! But it also has drawbacks, and it isn't the only option.
"10x as much work" is a huge overstatement, especially when platform conformance is a goal.
For native look and feel, I'd pick Qt over Electron any day. The catch is that no toolkit can abstract away all the platform-specific details. A minimum-effort Electron app looks like a web page; a minimum-effort Qt app falls into the uncanny valley.
There can be good reasons to choose Electron! But it also has drawbacks, and it isn't the only option.
> To those that truly care about excellence and don't merely pay lip service to it, there is only one way of building: using that platform's native toolkit.
Since you are clearly an expert here, can you explain to me how an immediate-mode API from the 1980s in which all painting is done via the painter's algorithm and context switches to kernel mode on every operation is superior to a declarative model that allows for global optimizations to minimize state changes and batch draw, in addition to using hardware Z-buffers to minimize overdraw?
Since you are clearly an expert here, can you explain to me how an immediate-mode API from the 1980s in which all painting is done via the painter's algorithm and context switches to kernel mode on every operation is superior to a declarative model that allows for global optimizations to minimize state changes and batch draw, in addition to using hardware Z-buffers to minimize overdraw?
I'm not an expert and I don't want to be one, I just want to have access to quality tools (preferably open source) and I want the majority of developers to use those tools.
Native UIs are efficient, web UIs aren't. It doesn't matter to me that they're built using painters, batch drawing or pixie dust as long as the API is sane and performant.
I think your post is a nice summary of the thinking that got us here in the first place: experts always looking at the possible future optimizations and not stopping to think at the present quality or if it's at all reasonable to build complex UIs in a document mark-up language.
I think your post is a nice summary of the thinking that got us here in the first place: experts always looking at the possible future optimizations and not stopping to think at the present quality or if it's at all reasonable to build complex UIs in a document mark-up language.
Aren't you the guy behind this https://github.com/pcwalton/libui-rs ?
Kind of strange to write bindings to something you hate so much. Or was it a changed of mind in the last 11 months?
With that said, I do agree with you, but there's not a single solution out there that does this efficiently, a browser is a ginormous level of indirection after all.
But if you want to spearhead such a thing I'm sure as hell interested.
Kind of strange to write bindings to something you hate so much. Or was it a changed of mind in the last 11 months?
With that said, I do agree with you, but there's not a single solution out there that does this efficiently, a browser is a ginormous level of indirection after all.
But if you want to spearhead such a thing I'm sure as hell interested.
What is this comp sci politico? Somebody writes a few bindings and that's evidence of their UI party affiliation?
What the hell? I knew the bindings because I've been investigating GUI solutions for Rust for the past few days, and was very surprised to see the author speak so poorly of a solution he poured time on; now people treat technical doubts as some sort of witch hunt?
I apologize if I miss-read that. At first it seemed like you were questioning his opinion based on his binding work.
This whole section has a very polarized/aggro vibe that's putting me on guard against false dichotomies and dogmatic arguing :| I need a chill pill myself.
This whole section has a very polarized/aggro vibe that's putting me on guard against false dichotomies and dogmatic arguing :| I need a chill pill myself.
Yeah, I wrote those bindings, though they're incomplete, and libui's memory management is so broken that I lost interest in finishing them.
It's a fair point, however. :) Much of my interest in libui was (a) to provide platform support for the browser engine; (b) to provide a solution for simple projects that don't want large dependencies. I've always believed the native UI frameworks from the '90s to be poor fits for modern graphics hardware. But sometimes your workload is so simple you don't care about whether your UI is as fast as possible, and minimizing dependencies is a more important criterion. That's where simple native UI layers can be a good fit.
It's a fair point, however. :) Much of my interest in libui was (a) to provide platform support for the browser engine; (b) to provide a solution for simple projects that don't want large dependencies. I've always believed the native UI frameworks from the '90s to be poor fits for modern graphics hardware. But sometimes your workload is so simple you don't care about whether your UI is as fast as possible, and minimizing dependencies is a more important criterion. That's where simple native UI layers can be a good fit.
> I've always believed the native UI frameworks from the '90s to be poor fits for modern graphics hardware.
Is there anything out there taking a better approach that works for native desktop? React Native and Flutter look like interesting solutions, but RN attempts to do all the hard work with JS, which is far from ideal; and Flutter is limited to Dart (which not that much better) and isn't getting any traction on desktop outside of the experimental Fuchsia.
Is there anything out there taking a better approach that works for native desktop? React Native and Flutter look like interesting solutions, but RN attempts to do all the hard work with JS, which is far from ideal; and Flutter is limited to Dart (which not that much better) and isn't getting any traction on desktop outside of the experimental Fuchsia.
To me, "native toolkit" means standard UI elements, not the lowest-level API.
In today's world of text editors, I'd take VS Code over anything. Anything at all. This notion that webapps must be bad is ludicrous.
How large of a file are you talking?
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.
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.
Otherwise, there really isn't any reason why I should care what tools you use.
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.
Also, calling it Visual Studio is very deceptive. Most devs know VS to mean something completely different.
As a VSCOde user on both Mac and Windows, I'm not sure they needed to do anything native. Seems like wasted work, when what they've ended up with is plenty fast and looks good in both environments.
I'm not using VSCode to edit one-off files from my terminal. The use case is for your folder-based projects. I generally open it once/week or reboot, etc, and finds it loads, mounts my folder and I'm done in the amount of time it takes me to grab a sip of coffee.
I think too many people base speed because they're used to one-off editing files directly from their filesytem. At this point in time, I only do this when editing config on remote servers and such.
EDIT: I just went and opened VSCode from my terminal and it took about 3.5 seconds to load up an entire React Native project on a three year old 11" MacBook Air.
I'm not using VSCode to edit one-off files from my terminal. The use case is for your folder-based projects. I generally open it once/week or reboot, etc, and finds it loads, mounts my folder and I'm done in the amount of time it takes me to grab a sip of coffee.
I think too many people base speed because they're used to one-off editing files directly from their filesytem. At this point in time, I only do this when editing config on remote servers and such.
EDIT: I just went and opened VSCode from my terminal and it took about 3.5 seconds to load up an entire React Native project on a three year old 11" MacBook Air.
Yeah, "Visual Studio" is a big, slow, bloated mess, that when working on a typical project, especially web projects will just freeze out regularly and plugins will stop the world, doing who knows what.
VS Code actually loads faster, doesn't freeze as much, and in general runs faster than any IDE I've ever used. And I've used a few. There are faster code editors, but VS Code is a bit more than most of them, but less than a full IDE typically is.
VS Code actually loads faster, doesn't freeze as much, and in general runs faster than any IDE I've ever used. And I've used a few. There are faster code editors, but VS Code is a bit more than most of them, but less than a full IDE typically is.
They have done something native...for many, many years. It's called Visual Studio.
VSCode has found a place in my workflow now and I don't care what language or platform they've used. It's proven to be more full-featured than competing editors and they are improving it much faster than other editors (based on my completely non-scientific, possibly biased observations).
VSCode has found a place in my workflow now and I don't care what language or platform they've used. It's proven to be more full-featured than competing editors and they are improving it much faster than other editors (based on my completely non-scientific, possibly biased observations).
Probably to not have to write a cross platform UI library and encourage contributions by using a wildly popular language
> 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?
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?
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".
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".
The editor "Monaco" was already written... it was for VS Online. They took the already written editor, Electron (Atom Core, etc) from the Atom project (another editor) and grafted the two together. Atom's editor at the time was horribly slow... Electron + Monaco actually worked well.
They've spent the time since then working on actual features... while they'd probably have just barely released anything if they had to do it all in C++, and wouldn't have nearly the depth of extensions they do.
They've spent the time since then working on actual features... while they'd probably have just barely released anything if they had to do it all in C++, and wouldn't have nearly the depth of extensions they do.
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)
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/#...
Servo is quite good actually. If you haven't already, try using browser.html from Mozilla which uses Servo and HTML for the UI.
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.
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.
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
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.
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.
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.
It's changed my opinion of electron based programs.
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.
The integrated terminal is far and away my favorite feature, second would be the git+diff integration... though merging/rebasing needs a good story.
This is called hacker news. Things that work well should be elevated, by trial, above all else. Try it. Seriously.
> 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?
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").
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.
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.
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?
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?
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
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
[deleted]
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.
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.
> It has a weak type system
Dynamic typing is useful. The "native" Objective-C is dynamically typed, for example. Static typing is useful too. If history has shown anything, it's shown that both dynamic typing and static typing have their places, and trying to argue that one is superior to the other in all circumstances is one of the most boring arguments imaginable.
> non-existant standard library
This is more or less a deliberate design choice, because there are many implementations of JS and that multiplies the probability of incompatibility. Consider the headaches that have arisen between Microsoft's STL and GNU's STL...
> Must be run in a packaged browser
Node? This is obviously false.
> Anything UI-related must be done by using a document markup language
It's an effective retained mode tree of nodes, with a whole lot more optimizations than any native toolkit I know of. (Look at how the childNodes array is implemented sometime, for example; no native toolkit does the kind of caching that browsers do...)
> style sheets
Style sheets are a great idea. They're becoming increasingly popular for native development nowadays (Qt, GTK, etc.)
> The fact that any app developed in it is guaranteed to be inefficient and sluggish is just the cherry on top.
I'm as much of a critic of current browser design as anyone, but this is mostly the fault of old browser designs. The Web platform has a lot more potential for performance than things like the Win32 API, as I've elaborated on in many other posts.
Dynamic typing is useful. The "native" Objective-C is dynamically typed, for example. Static typing is useful too. If history has shown anything, it's shown that both dynamic typing and static typing have their places, and trying to argue that one is superior to the other in all circumstances is one of the most boring arguments imaginable.
> non-existant standard library
This is more or less a deliberate design choice, because there are many implementations of JS and that multiplies the probability of incompatibility. Consider the headaches that have arisen between Microsoft's STL and GNU's STL...
> Must be run in a packaged browser
Node? This is obviously false.
> Anything UI-related must be done by using a document markup language
It's an effective retained mode tree of nodes, with a whole lot more optimizations than any native toolkit I know of. (Look at how the childNodes array is implemented sometime, for example; no native toolkit does the kind of caching that browsers do...)
> style sheets
Style sheets are a great idea. They're becoming increasingly popular for native development nowadays (Qt, GTK, etc.)
> The fact that any app developed in it is guaranteed to be inefficient and sluggish is just the cherry on top.
I'm as much of a critic of current browser design as anyone, but this is mostly the fault of old browser designs. The Web platform has a lot more potential for performance than things like the Win32 API, as I've elaborated on in many other posts.
It's useful, but when that's the only tool one has, it becomes a liability. I like using both JS and Python where it makes sense, but building a medium-sized or large app in such languages is asking for trouble.
Some teams make enough of an effort that they are able to deliver such an app. That should not be encouraged, but rather criticized as encouraging development practices. To be clear: they can do whatever they want in their projects. I have a problem when they recommend such methods to others, without being honest about the pitfalls and effort involved.
Re standard library: the STL is currently working great! JS would kill to have something as stable and high quality as the STL.
Re node: I am not aware of any desktop or mobile apps using node. Isn't that a server-side technology?
Re markup: does it matter how much optimized it is and how much caching it does when in the end it's still slow?
Re style sheets: they're great when used for styling, like in Qt (not sure what GTK is doing). But that doesn't scale when building widgets and doing positioning.
pcwalton, web apps have had the potential to do X, Y and Z better than native apps for the past decade. At one point web developers need to talk less and deliver.
Some teams make enough of an effort that they are able to deliver such an app. That should not be encouraged, but rather criticized as encouraging development practices. To be clear: they can do whatever they want in their projects. I have a problem when they recommend such methods to others, without being honest about the pitfalls and effort involved.
Re standard library: the STL is currently working great! JS would kill to have something as stable and high quality as the STL.
Re node: I am not aware of any desktop or mobile apps using node. Isn't that a server-side technology?
Re markup: does it matter how much optimized it is and how much caching it does when in the end it's still slow?
Re style sheets: they're great when used for styling, like in Qt (not sure what GTK is doing). But that doesn't scale when building widgets and doing positioning.
pcwalton, web apps have had the potential to do X, Y and Z better than native apps for the past decade. At one point web developers need to talk less and deliver.
> I like using both JS and Python where it makes sense, but building a medium-sized or large app in such languages is asking for trouble.
There have been tons of reliable large apps written in dynamically typed languages. This is, again, a tiresome argument.
> the STL is currently working great! JS would kill to have something as stable and high quality as the STL.
The STL took nearly a decade to get hash tables. And for years, users suffered from Microsoft and other vendors taking very different approaches to template expansion, causing no end of ifdef hell. JS never had such issues.
> But that doesn't scale when building widgets and doing positioning.
Huh? How does flexbox "not scale"? Positioning is just one aspect of style.
> At one point web developers need to talk less and deliver
I've been working on browsers for 7 years, and on most of those weekends, thanks.
There have been tons of reliable large apps written in dynamically typed languages. This is, again, a tiresome argument.
> the STL is currently working great! JS would kill to have something as stable and high quality as the STL.
The STL took nearly a decade to get hash tables. And for years, users suffered from Microsoft and other vendors taking very different approaches to template expansion, causing no end of ifdef hell. JS never had such issues.
> But that doesn't scale when building widgets and doing positioning.
Huh? How does flexbox "not scale"? Positioning is just one aspect of style.
> At one point web developers need to talk less and deliver
I've been working on browsers for 7 years, and on most of those weekends, thanks.
The tide seems to be turning against dynamic languages because developers are getting tired of the poor performance, fragility and maintenance difficulty. We just needed to see some innovation in the static typing camp: the transition from Objective-C to Swift is a great example.
A typical app can be made pretty reliable with enough testing effort and a good process, so I'm not surprised that large apps have been written in dynamically typed languages, although I am now curious which apps you had in mind. Can't think of anything the scale of e.g. Photoshop, Oracle or Linux.
Re STL: Really? :) I'll take missing hash-tables (dictionaries are fine) any day over no library. I don't know which period you're referring to with the ifdef hell, but at least for the past decade I can't think of any STL compatibility issues. Perhaps you can be more specific here? In any case, JS never had such issues because back then it was being used to make text blink. Now that it's facing more challenges we start seeing the issues.
Re working on browsers: you're not a web developer. I will say though that Mozilla pushing this web-everything agenda is disappointing. The FirefoxOS lesson has not been learned...
A typical app can be made pretty reliable with enough testing effort and a good process, so I'm not surprised that large apps have been written in dynamically typed languages, although I am now curious which apps you had in mind. Can't think of anything the scale of e.g. Photoshop, Oracle or Linux.
Re STL: Really? :) I'll take missing hash-tables (dictionaries are fine) any day over no library. I don't know which period you're referring to with the ifdef hell, but at least for the past decade I can't think of any STL compatibility issues. Perhaps you can be more specific here? In any case, JS never had such issues because back then it was being used to make text blink. Now that it's facing more challenges we start seeing the issues.
Re working on browsers: you're not a web developer. I will say though that Mozilla pushing this web-everything agenda is disappointing. The FirefoxOS lesson has not been learned...
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.
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.
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.
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.
VS code is free and available on all three major OSes. Download it and give it a shot, you may be pleasantly surprised.
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.
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).
>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.
The parent comment was talking about Visual Studio itself, not VS Code.
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.
> 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.
Funny, I thought WPF is at least three years younger. Sadly, there are still schools (at least in Europe) that teach Windows Forms exclusively.
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.
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.
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.
[1]: http://www.itorian.com/2013/11/visual-studio-online-monaco-e...
[1]: http://www.itorian.com/2013/11/visual-studio-online-monaco-e...
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).
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).
VS Code also had a huge headstart in that they already had the editor code, as well as the node+chrome workspace (electron/atomshell) to use. Not to mention cross-platform from the start.
At this point, they actually have a lot of the core functionality in place for a full IDE, they just need a prettier means of editing configuration, and creating build-able projects.... It's a bit manual at this point, which makes it a good fit for node and go workflows, and decent for others.
It will get better.
At this point, they actually have a lot of the core functionality in place for a full IDE, they just need a prettier means of editing configuration, and creating build-able projects.... It's a bit manual at this point, which makes it a good fit for node and go workflows, and decent for others.
It will get better.
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.
[deleted]
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.
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.
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-langua...
1. https://code.visualstudio.com/blogs/2016/06/27/common-langua...
[deleted]
There is a spelling mistake in the module registration ;-) mimetype, not minetype.
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
the small benefit of minifying is out weight by using a "compile" to JS language that usually produce much more code :P
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...
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.
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.
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.
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 ;)
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 ;)