24 ms·

It just doesn't go in my head that we are building text editors inside a web browser! I get it, there are many good use cases for Electron and it's easy to get

It just doesn't go in my head that we are building text editors inside a web browser! I get it, there are many good use cases for Electron and it's easy to get started with cross platform support, but why is everybody going crazy about text editors in them? Because you can write plugins in JS? Wouldn't it be better to make native application, especially for code editors, where developers spend most of their time, where every noticeable lag and glitches are not appreciated. Edit: Many people here think that I am attacking this web based kind of technology, which I am not, and sorry for not being clear enough, but why chose something so high up the stack for dev tool? Edit2: For non-believers in nested comments, look -> https://github.com/jhallen/joes-sandbox/tree/master/editor-perf https://github.com/jhallen/joes-sandbox/tree/master/editor-p...

jablan 10y ago
I believe making native application for the three platforms would be considerably more effort.
brilliantcode 10y ago
well if you've ever built a cross platform native desktop application, you will appreciate Electron. Java Swing. Never again. edit: Do people downvoting even know what it's like building cross platform desktop applications using Java Swing? It's fucking awful, and that's a fact. Even the end result UI design look & feel is butt ugly. Sure you can spice things up with JavaFX but why? Do you not realize how masochistic it was back then vs now with thin web browser clients? Can't believe people are still thumping Java Swing in 2017.
- krzyk 10y ago
  Why? With JavaFX where you can customize it using CSS it looks nice, and you don't need to use a scripting language to do it.
  - brilliantcode 10y ago
    Why use JavaFX when you can change the CSS in a web app which is indistinguishable? Here's a easy way to get a job done but people refuse to do it because of philosophical/ideological indoctrination. ex. the world is made of objects therefore our languages and how we build software should now mirror it.
- TeMPOraL 10y ago
  Swing was at least meant to do UI. Web stack is not; webapps are essentially a pile of ugly hacks on top of a document rendering engine, and it really, really shows - especially when you have webapps pretending to be native (e.g. webview-based apps on mobile). Also, for Java there's JavaFX (a de-facto standard UI toolkit for Java), which is very nice to work with.
  - Spivak 10y ago
    And yet that hacked together document rendering engine manages to be less painful to use than the the current show of UI toolkits. I think we'll get there eventually but until a native toolkit presents an interface as easy to use as the web developers are going to take the path of least resistance.
    - mbel 10y ago
      > I think we'll get there eventually but until a native toolkit presents an interface as easy to use as the web developers are going to take the path of least resistance. Like Qt did with QML? http://doc.qt.io/qt-5/qml-tutorial1.html http://doc.qt.io/qt-5/qml-tutorial1.html
      - ryanpepper 10y ago
        Yeah, but Qt has licensing costs for commercial use...
        uzoodoo 10y ago
        Qt is LGPL, so unless you need to link to it statically or make proprietary modifications to Qt itself, you don't need to pay licensing costs.
        ryanpepper 10y ago
        Ah right, I wasn't aware of that.
- bitmapbrother 10y ago
  Is the IntelliJ UI "butt ugly"? No, but you'll probably say it is as to not contradict yourself. Blame the craftsmen not the tool. >Even the end result UI design look & feel is butt ugly You know what else is butt ugly? Programmer art and UI.
- pjmlp 10y ago
  > Even the end result UI design look & feel is butt ugly. Only when developed by those devs that never bothered to read books like "Filthy Rich Clients".
- Insanity 10y ago
  I was extremely skeptical of using Swing for a really large hospital application. But after working in it for quite some time, I have to say that with the right approach it is quite manageable. There is plenty of power in there and a lot of good things can be done. (I do prefer the webstack over Swing)
paulddraper 10y ago
> easy to get started Yes. > cross platform support Yes. > Because you can write plugins in JS? Yes. --- As much as I prefer native programs as a user, it's impossible to ignore the benefits of cross-platform development and plebeian hackability/debuggability.
- dekhn 10y ago
  you can do all of this in Qt, too. Without the overhead of the inner platform effect.
  - cle 10y ago
    You can do it, but it's significantly harder. And with Electron, you can leverage the same skills that are used to build web applications to modify your environment and text editor as well. Those are very significant advantages. Note: I don't use VS Code or any other JS editor, I use emacs. But I can definitely appreciate the major benefits of the architecture.
    - josefx 10y ago
      So does it have a NoScript plugin to kill the unavoidable 200 tracking and ad scripts from Google, Facebook and who knows what running in the background? I am sorry if I offend someone with this, however the current Web experience is something I want as far away from my dev. tools as possible.
      - deleted 10y ago
        [deleted]
      - y4mi 10y ago
        tracking or ad scripts by facebook or google are in neither atom nor VSCode. both projects are open source if you care to verify
        fs111 10y ago
zanny 10y ago
We have a lot of native GUI text editors. Gedit, Geany, Kate, and Notepad++ are free options, and then you have Sublime Text as a proprietary one. They all support plugins and extensions, they are all super efficient in CPU usage, etc. The thing is they aren't new, and because they are all C/C++ codebases developers wanting to add new features to text editors don't want to touch C++98 / ANSI C code from two decades ago. Then you want to start talking about a C++17 / Go / Rust / etc text editor, but that is starting from scratch, and when you consider the time investment to develop the infrastructure of a text editor today vs just using Electron, the time investment makes less sense for hobbyist devs doing this stuff in their free time.
- fao_ 10y ago
  > developers wanting to add new features to text editors don't want to touch C++98 / ANSI C code from two decades ago. As I understand it, sublime has tight enough integration with python, such that python can do literally everything you would ever need
- thomastjeffery 10y ago
  > when you consider the time investment to develop the infrastructure of a text editor today vs just using Electron, the time investment ...is exactly the same. No matter what gui toolkit you use, you still need to develop the infrastructure. Electron doesn't know how to handle keyboard and mouse events, it doesn't have a text buffer implemented, has no understanding of different text encodings, how to parse different languages, and draw different colored text accordingly, or format it, etc.
- digi_owl 10y ago
  CADT, all the way down...
ehsankia 10y ago
Most of these don't support it (yet?), but I personally love the idea of having my editor of choice on the web with all my settings and with no install/permission issues. The real reason to me though seems that it's just the easiest way to make a cross-platform UI. And in this web powered world, everyone knows how to code html/css, so why relearn a bunch of new tools?
Touche 10y ago
> Wouldn't it be better to make native application Better in what way? The market has voted with their downloads, they don't agree that the problems with Electron apps are as bad as you feel that they are.
- Philipp__ 10y ago
  Are you kidding me? Look at the raw performances and benchmarks of Vim/Sublime/Emacs, compare it to VSCode and Atom and you will see. If you don't believe the numbers then use both side by side, open 250MB file in all of them and look at the screen. And I still see native editors used more (for example latest StackOverflow survey, showed that Notepad++, Vim and Sublime combined are used much much more than VScode and Atom combined). I don't want't my editor to crush mid session, or have to write bunch of gulp files and npm commands to do one simple modification.
  - prolly_a_moron 10y ago
    >If you don't believe the numbers then use both side by side, open 250MB file in all of them and look at the screen. Maybe I don't have any 250MB files to open? If VSCode doesn't fit your use case, don't use it. There are innumerable alternatives. But what purpose does it serve to tell the rest of us (who like it) that it sucks?
  - sodawater 10y ago
    GP: The market has voted with their downloads You: But I prefer xyz! :( You didn't respond to the argument. What you consider valuable doesn't align with the market.
  - therealmarv 10y ago
    I usually never deal with 250MB code files. The right tool for the right task. The Electron programs deal with code in a directory (and btw. VSCode is totally different beast than Atom) and I also would not edit a 250MB file with both of them. Never had a crushing VSCode here... but I always have a better Python and HTML and JS support than e.g. in Sublime+good plugins.
  - 10y ago
therealmarv 10y ago
I think you have answered it yourself partly. Creating a highly configurable, UI/UX predictable cross plattform editor is not an easy task. If you start from scratch on a native platform you have to code a ton of code (pretty sure more than VSCode has) just to get started. Editors on web platforms can be modified with CSS, JS (or TypeScript like on VSCode), HTML. Try to be that configurable on a native platform... you literally have to code something equivalent to CSS, HTML, JS to reach that level of modularity. It's good to stay on the shoulders of giants and start there ;)
- nottorp 10y ago
  Pray tell, sir, have you heard of the Qt library? There is a whole world outside Javascript :)
  - therealmarv 10y ago
    So you think hacking QT libraries like this (and not from the outside, I mean internally) and using C++ would make a good community editor? http://doc.qt.io/qt-5/qtwidgets-richtext-syntaxhighlighter-example.html http://doc.qt.io/qt-5/qtwidgets-richtext-syntaxhighlighter-e... When using QT for a highly modular editor be prepared to code QT components from the lowest level. It's not like you take a QT widget and modify it on a simple way. Trust me. If you think it is easy to code editors look e.g. at the people who write letters and their custom editor tool: Microsoft Word. Now look at the many competitors this program had and how many behave super speedy on all plattforms.
    - nottorp 10y ago
      I've written low level GUI components for several UI frameworks before, thank you very much. It's not that bad and a lot smoother for the end user. The real problem is this new generation of "developers" that only know Javascript. When all you have is a hammer...
      - deleted 10y ago
        [deleted]
dheera 10y ago
Yep. I also can't wrap my head around the fact that we are now constructing buttons, drop-down boxes, tagged text boxes using dozens of nested <div> layers instead of a native widget that writes directly to the screen. My 486 rendered UIs with nearly imperceptible lag. Google Docs takes a good 2-3 seconds to spin up a UI on my i7.
- therealmarv 10y ago
  Would be better to compare it to transfer a state/screen over the wire/internet on 486 vs. doing the same nowadays ;)
  - msh 10y ago
    Well a x server on a 486 was probably also faster...
  - TeMPOraL 10y ago
    Besides the X-server point, it's not just the state transfer that's causing web UI to lag.
- onion2k 10y ago
  Google Docs takes a good 2-3 seconds to spin up a UI on my i7. I doubt much of that time is spent building the DOM tree for the UI. Google Docs does a lot more than a simple text editing widget - there's a networked file system, a multi-user collaboration engine, a realtime notification system, etc that all get initialised. Instantiating all that over a network in 2-3 seconds is really fast.
  - cr0sh 10y ago
    ...a whole 2-3 seconds! Sometimes I think that comments like these arise out of not having experienced text-only rendering at 300 baud... I know that's a generalization, and most likely unfair - but damn, today's phones, to this old man, are pocket super-computers (for that matter from my vantage point, an Arduino is a wonder, and a RasPi is utterly amazing)!
deleted 10y ago
[deleted]
awinder 10y ago
I switched to vscode from webstorm, for performance reasons. Building a native editor / ide is a great idea. But since a lot of options in this area had already chosen some cross-platform toolkit for development, why not build it as an electron app?
tomc1985 10y ago
The current state of Javascript is very much, "just because you can, doesn't mean you should"
- FridgeSeal 10y ago
  For sure. Half the responses in this thread are people defending the stupid idea of "let's just use js everywhere, just because we can and fuck better suited tools". Js is not the be all and end all of tools, just because it is used a lot in web doesn't mean it is the best (or appropriate) tool for other spaces. It sort of seems like js/js ecosystem is built around hacky solutions to things, so I guess it makes sense that the community doesn't seem to see any issue with shoehorning in their language of choice into entirely inappropriate spaces.
013a 10y ago
Yeah! We should go back to native editors, like Eclipse or IDEA!
- nottorp 10y ago
  HN could use a "funny" upvote option...
- ethelward 10y ago
  Seeing the resources taken for a simple text editor, I crave to see what a full-blown IDE (whic is what Eclipse and IDEA are) written with web technologies would eat up.
koolba 10y ago
Because if we don't build it inside a web browser, we'll have to add plugin support to add a web browser inside of it. Then you have two problems.
- JdeBP 10y ago
  Actually then, in accordance with Zawinski's Law, one will be able to use that web browser to read mail. (-:
whazor 10y ago
As someone who is literally building a IDE in Electron, the biggest reason is JavaScript itself. If you look to the stackoverflow yearly overview, you can observe that JavaScript is currently the most used language. Also do not forget about all the integrations you could do with for example devtools. An additional feature is that you can run the IDE in the web browser, so that you can have an online code editor. Think for example about configuration files on the Azure website, or a cloud IDE with multiple people using it. Honestly I think Visual Studio Code is not slow enough for people to switch. A long web page is very similar to a long code document, all the keywords are just span's with a colour. Furthermore, it is not like Visual Studio or IntelliJ are known for low CPU or smoothness.
- cr0sh 10y ago
  I personally wish Github would incorporate a full-feature Electron-based IDE into their system; they do have an online editor, but it is fairly simplistic. Good enough for quick edits, but I wouldn't want to dev in it (then again, I started my professional career in software development sitting in front of a VT220 using a line-based editor; it got bad enough that me and my mentor had a "contest" on who could write a better full-screen code editor - honestly, we both won in a way).
- haldean 10y ago
  The SO survey (while super interesting!) conflates "most used" with "most asked about on Stack Overflow"; I'm skeptical of anyone who claims to know which programming language is the most popular. The TIOBE index, which has its own problems, has Javascript coming in 8th, with the top 4 being Java, C, C++ and C#; my experiences and my confirmation bias suggest that's more accurate. https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/
  - whazor 10y ago
    I agree that tiobe is more established, especially as they look to companies being involved and to the job market. One of the reasons why I am interested in Javascript is that many people are learning it, even non-developers. Think about people without education.
Osmose 10y ago
> Wouldn't it be better to make native application, especially for code editors, where developers spend most of their time, where every noticeable lag and glitches are not appreciated. The lesson here is that our assumed bars of quality for what makes a text editor good are inaccurate. It turns out that the minimum performance bar is lower than you think, and that ease of customization is, in fact, much more important than you think.
m_fayer 10y ago
Because Microsoft and Apple have both dropped the ball on their native UI toolkits. Right now I'm doing web frontend with TS+VueJS+nice CSS toolkit. Yes there's plenty of complaining to do about the fragile convoluted toolchain and crappy performance. But I still gladly take it over WPF (promising, abandoned for some reason) or Cocoa (feels a decade out of date). No major OSS community, no Material Design/Bootstrap/etc. toolkits, slow develop/run loop, no good UI automation, crappy/no inspection capacity, etc. I don't need x-plat UIs, I just need a good UI toolkit period, and that's why I'm looking real hard at Electron for future desktop work.
- kitsunesoba 10y ago
  Cocoa has its issues, but I find it much more pleasant to use than anything based on front end web tech despite that. I find myself wishing I could use it on Windows and Linux. I find many of the frustrations people have with desktop Cocoa come from the bizarre need to reinvent the wheel with a custom UI theme. If you stop fighting the system and instead go with a native look with well chosen accents, life is much easier. Native can look great with a little attention to detail.
- zigzigzag 10y ago
  You can also look at JavaFX. It's pretty good.
Kiro 10y ago
Have you used VS Code? Feels much more performant than any native editor or IDE I've ever used.
- ovao 10y ago
  What native editors have you used?
  - Kiro 10y ago
    Primarily Sublime Code, Notepad++, PhpStorm and NetBeans.
    - ovao 10y ago
      That's an unusual experience. Based on a handful of benchmarks[0] done by the author of JOE, VS Code is sometimes an order of magnitude slower than Notepad++ and Sublime at some tasks. I use VS Code pretty much exclusively these days myself, so I'm not picking on it by any means. [0]: https://github.com/jhallen/joes-sandbox/tree/master/editor-perf https://github.com/jhallen/joes-sandbox/tree/master/editor-p...
      - iaml 10y ago
        I have the same experience on my pretty slow laptop. Granted, my projects aren't big, but I would take vs code over sublime any day. Interestingly, atom feels much slower compared to both.
        FridgeSeal 10y ago
        That's because, unequivocally, atom is slower. https://pavelfatin.com/typing-with-pleasure/ https://pavelfatin.com/typing-with-pleasure/
        iaml 10y ago
        Surprising part isn't that atom is slow, it's that vs code isn't and they both use electron.
rayiner 10y ago
The web is in just a shameful state. Even with 300 mbps fiber internet most websites are not snappy. As in, pages are so slow to render that I'll start reading, but then lose my place when the page reflows as it continues to load. Or click on the wrong thing because the page reflowed while I was trying to click on something. As far as I can tell I'm actually CPU-limited, because I noticed no real difference from when I had 50 mbps internet. This is on a quad-core Macbook Pro that boosts up to 3.5 GHz...
- monkpit 10y ago
  So you just assume that changing between 50 meg and 300 meg service actually should give you a 6x speed up during browsing? I think that's a very flawed assumption to make. Just because your connection is capable of a certain advertised speed doesn't mean you're getting that speed from any given server as you browse the Internet.
  - rayiner 10y ago
    No, I'm assuming that because it didn't give me a noticeable speedup that bandwidth isn't the bottleneck. Also, the bottleneck isn't my connection out to the internet because I can get more than the advertised speed any time of day to speedtest.net servers. I suppose the bottleneck could be on the other end, but aren't these sites all hosted on major platforms these days? Like AWS/Google/etc.?
- quicklyfrozen 10y ago
  It takes a while to source all the ads, and the reflow that leads you to click on the wrong thing (e.g. an ad) is most likely intentional.
gregmac 10y ago
Building a plugin system is hard. Building one that allows creating complex UI elements, modifying other UI elements (from either the core app or other plugins) or changing the way literally anything is rendered is particularly hard. You not only have to build the code that supports all this, you also have to create and document an API and/or markup format to build all this out, plus document all your internal integration points. If you want other developers to really take it up and build plugins, you have to make it easy to get into, so that means not just documentation, but great documentation, plus tutorials, examples and tooling to help. You get a big chunk of that for free when you use HTML/CSS/JS. Fire up VS Code, go to Help > Toggle Developer Tools, and poke around for a few minutes. Imagine the amount of time it would take to build a similar experience to just this one aspect if you were doing this from scratch.
- fao_ 10y ago
  Or you could use Lisp, and have the UI be S-Expressions. Everything can edit a list
  - striking 10y ago
    Can you give me an example of a Lisp UI library like that?
    - shakna 10y ago
      Two come close but aren't quite there... Seesaw [0] - A nice-ish way of using Swong in Clojure. Iup [1] - One of the friendliest GUIs I've used, hands down. Just feels like Scheme. However, I'd expect that QML and X-Expressions could go hand in hand to make something much closer, with a bit more flexibility. [0] https://github.com/daveray/seesaw https://github.com/daveray/seesaw [1] https://wiki.call-cc.org/iup-tutor#hello0scm https://wiki.call-cc.org/iup-tutor#hello0scm
- rvern 10y ago
  > Fire up VS Code, go to Help > Toggle Developer Tools, and poke around for a few minutes. Imagine the amount of time it would take to build a similar experience to just this one aspect if you were doing this from scratch. Don't do it from scratch then. You can use GtkInspector to poke around with any GTK+ application, by pressing Ctrl+Shift+I.[1] [1]: https://wiki.gnome.org/Projects/GTK%2B/Inspector https://wiki.gnome.org/Projects/GTK%2B/Inspector
StreakyCobra 10y ago
By making a text editor out of web technologies, you can reuse all the web ecosystem the web has, and enjoy also its customizability. For instance I wanted to be able to display PDFs directly in VSCode. I went to look for a plugin, and there was one. People simply used "pdf.js" to integrate PDF support in VSCode. Because it is web based it should have been straightforward to do. Doing the same with native technology would have took several weeks of coding, and it wouldn't have been cross-platform. Imagine all the web-based open-source tools that could potentially be integrated in these editors. Integrating a SVG editor in native text editors would be a nightmare. With web-based text editor you can potentially just incorporate an existing tool like [1]. There are lot of other examples like this: Live markdown preview, mini-map, color-picker, integrated VSCode debug panel, … It is also quite easy to add visual stuff. For instance adding a vertical bar at 80 characters in the background is quite easy to do with web technologies. On the other side emacs has still not managed yet to make the html-mode work nicely with this "fill-column-indicator". It is also probable that it would be much more easy to integrate web services (trello, github, …) directly within VSCode. At the end people wanting performances have already quite a lot of choice in native text editors (vim, emacs, sublime…), and people who prefer functionalities can go with web-based text editors (atom, vscode, …) [1] https://svg-edit.github.io/svgedit/releases/svg-edit-2.8.1/svg-editor.html https://svg-edit.github.io/svgedit/releases/svg-edit-2.8.1/s...
- coldtea 10y ago
  >By making a text editor out of web technologies, you can reuse all the web ecosystem the web has, and enjoy also its customizability. For instance I wanted to be able to display PDFs directly in VSCode. I went to look for a plugin, and there was one You know where else you could do the exact same thing AND have a 10x faster and 10x more memory/battery efficient editor? If a native editor just gave you a webview that can run JS extensions...
  - Philipp__ 10y ago
    Ema... Ok ok, I will shut up. :)
  - StreakyCobra 10y ago
fenomas 10y ago
Your question seems backwards. VS:Code is an absolute dream to use, for me at least - powerful, hackable, and performs great. If there are native editors that leave it in the dust, what are they? If there aren't, surely it would make more sense to ask why that is, rather than asking why Code isn't native?
yatsyk 10y ago
> Wouldn't it be better to make native application Actually there are such editors. I use vim instead of vscode or atom. And I think my installation of vim is slower then vscode because of some plugin that I've not found yet. Applications like vscode very useful because they help to find performance and other bugs in browsers. Same way as browser improved when gmail and sites like this appeared. I would support appearance of IDEs, large games, VR, image and video editors in browsers as they help improve web platform. If you don't like it, just use other option. It could be faster, but may be not. Not sure that vscode is slower then visual studio for most tasks.
sfifs 10y ago
Actually I find the consistency and simplicity of using well established, widely supported and rich third party ecosystem available with using HTML5/CSS/JS based UI very liberating vs. the incompatible mess of native UIs. Personally I script all front-ends in web technologies irrespective of platform and back end tech. The browser rendering engines and JS engines are reasonably fast in most platforms.
parenthephobia 10y ago
> Wouldn't it be better to make native application, especially for code editors, where developers spend most of their time, where every noticeable lag and glitches are not appreciated. I think it'd be better to improve Electron so that native applications don't have so much of an advantage. WebAssembly is a big part of that. Another useful part would be an alternative layout mode that eschews legacy HTML/CSS cruft, for more predictable and performant GUIs.
williamle8300 10y ago
I think their bet is that the web stack won't be "so high up the stack" in the near future.
brulard 10y ago
I switched from sublime to Atom maybe 2 years ago. I'm completely happy with the speed. I see no disturbing lags and it works/looks the same on every platform. There is a great extension system and I can develop my own extension quickly if I ever needed to. I believe for the developers it was much more productive to create it with web technology and therefor I don't see any reason why it shouldn't be done like that. I guess there are people that need much faster this or that, and as low memory footprint as possible, but it is not an average user/developer. I believe for most of us these editors work well
pcarolan 10y ago
Have you tried VS code? It seems your arguments about performance are theoretical but in my experience i have run into none of what you're describing could happen on a 5 year old macbook air. A 14% cpu idle due to a cursor is a bug that will be squashed. The software experience, in practice, is quite impressive.
hasenj 10y ago
I used to think the same, until I started using VS code and it completely blew me away! I don't care if it's written on to of a browser or in assembly. I just know it's the best text editor I've used so far.
watty 10y ago
It just doesn't go in my head how so many people have trouble understanding why things like VSCode or Atom are popular. They're sexy, they are powerful (extensions for everything), portable, and extremely easy to extend thanks to Javascript being pervasive. I don't know for certain but I'd also assume writing an Electron app is easier than writing a similar app in a lower level language. Is it really that hard to grasp? Performance has to be perceptible by the average person for it to affect user base. I prefer WebStorm but I've had absolutely no issues using VSCode on my laptop - which feels even faster than WebStorm.
- ConceptJunkie 10y ago
  I've played around with VSCode and what it can do seems impressive, but I want to do one simple thing. I want to make the background black. Every dark theme I can find makes the background dark gray, not black. I actually looked into what it would take to make a new color theme and I simply don't understand all the steps, and definitely don't want to deal with the hassle. It very quickly goes off into the weeds of TextMate themes (huh? Why are we referencing a Mac editor? Yeah, I know it's a de facto standard, but really?), editing XML (complete with hex codes for colors) and installing something called "Yo Code". Dude, I just want to change one friggin' color! In every native app I've ever used, I can just go into the Options and make the background black, period. Just because it's a programmer's editor shouldn't mean you need to be a programmer to make the simplest configuration.
  - jes5199 10y ago
    I don't know about VSCode, but in Atom you'd just write one line of CSS
watty 10y ago
It just doesn't go in my head how so many people have trouble understanding why things like VSCode or Atom are popular. They're sexy, they are powerful (extensions for everything), portable, and extremely easy to extend thanks to Javascript being pervasive. Is it really that hard to grasp? Performance has to be perceptible by the average person for it to affect user base. I prefer WebStorm but I've had absolutely no issues using VSCode on my laptop - which feels even faster than WebStorm.
dragonwriter 10y ago
> Wouldn't it be better to make native application, especially for code editors, where developers spend most of their time, where every noticeable lag and glitches are not appreciated. There are plenty of native-application (or JVM/CLR) text editors and IDEs, too. For lots of usage patterns, the browser-engine-based ones have acceptable performance, and the number of people with expertise building for web contributes to the speed of development on those editors and their plugins. But, sure, if you don't like Electron-based editors, there are plenty of other actively-developed editors for you to choose from.
dualogy 10y ago
> It just doesn't go in my head that we are building text editors inside a web browser! I felt the same until I actually tried it out. That changed my mind: now I'll take any platform that those developers & contributors choose for their cross-platform products. Because this for an Electron app, this is a rock-solid 'old-school' (as in, fully as neat smooth helpful-yet-staying-out-of-the-way and somehow "ergonomic" as it was ever since at least oh late 90s, v6 or so) "Visual Studio experience". After a few years of sitting listlessly in front of subjectively inferior editors, I'm prepared & willing to give this Electron stuff more time to further mature improve and speed up. There's no intrinsic reason it can't get there. Lots of seemingly native apps are just live Lua/Python interpreters under the hood with widget bindings in place of a DOM. In that case, well-engineered JavaScript (terribly time-consuming to produce & pretty rare out there for those who like to rely blindly on a huge pile of unscrutinized 3rd-party snippets/script um-I-mean "repos" --- but not impossible) can fully deliver the same, in principle. Seeing how VScode took off, that could even propel MS to invest unprecedented energies & talent into rounding up the JS "rich client app" performance story further. Who knows.
sigzero 10y ago
No, you are correct. It is insane.
deleted 10y ago
[deleted]
payonel 10y ago
the benchmark you linked is outdated, I reran those tests just now with vscode and could perform all open, edit, close operations in the test in fewer than 2s.
- deleted 10y ago
  [deleted]
pix64 10y ago
You could write a native text editor which can use JS plugins. Sublime Text uses python plugins and is nice and snappy.
userbinator 10y ago
Wouldn't it be better to make native application, especially for code editors, where developers spend most of their time, where every noticeable lag and glitches are not appreciated. I agree. However, as someone who has used Visual Studio (the one that costs $$$, not VSCode) which is a native application (AFAIK --- it probably has some .NET and web components too), I can attest to the fact that even native applications can be extremely resource-consuming and slow.
mvindahl 10y ago
VSCode runs nicely on my MacBook. It doesn't feel like a web application to me, in the same way that IntelliJ IDEA doesn't feel like it's written in Java. I'm sure that both VSCode and IDEA could run even faster if they were ported to, say, C, but in both cases that would be a large investment for improvements that I wouldn't even detect. So I guess it makes sense to optimize for maintainability i this case, i.e. not having one codebase per native OS.
joshwcomeau 10y ago
I really like that I can edit my editor. A few times, I've disliked how something looked or wanted to add a feature. So I tweaked the stylesheet, or wrote an Atom plugin. There's a beautiful poetry to being able to do web dev inside a web application. I still have Sublime text for when I need to view/edit files with tens of thousands of lines, since Atom chokes on large files, but otherwise I have zero regrets :) I'm as productive in Atom, and it's a more pleasant experience.
nonsince 10y ago
Agreed. If you're looking for easy extensibility, a simple core and a flexible GUI, I can't imagine what could put VSCode above emacs, except for the button marked "sort by CPU usage"

jablan 10y ago

I believe making native application for the three platforms would be considerably more effort.

brilliantcode 10y ago

well if you've ever built a cross platform native desktop application, you will appreciate Electron. Java Swing. Never again. edit: Do people downvoting even know what it's like building cross platform desktop applications using Java Swing? It's fucking awful, and that's a fact. Even the end result UI design look & feel is butt ugly. Sure you can spice things up with JavaFX but why? Do you not realize how masochistic it was back then vs now with thin web browser clients? Can't believe people are still thumping Java Swing in 2017.

krzyk 10y ago
Why? With JavaFX where you can customize it using CSS it looks nice, and you don't need to use a scripting language to do it.
- brilliantcode 10y ago
  Why use JavaFX when you can change the CSS in a web app which is indistinguishable? Here's a easy way to get a job done but people refuse to do it because of philosophical/ideological indoctrination. ex. the world is made of objects therefore our languages and how we build software should now mirror it.
TeMPOraL 10y ago
Swing was at least meant to do UI. Web stack is not; webapps are essentially a pile of ugly hacks on top of a document rendering engine, and it really, really shows - especially when you have webapps pretending to be native (e.g. webview-based apps on mobile). Also, for Java there's JavaFX (a de-facto standard UI toolkit for Java), which is very nice to work with.
- Spivak 10y ago
  And yet that hacked together document rendering engine manages to be less painful to use than the the current show of UI toolkits. I think we'll get there eventually but until a native toolkit presents an interface as easy to use as the web developers are going to take the path of least resistance.
  - mbel 10y ago
    > I think we'll get there eventually but until a native toolkit presents an interface as easy to use as the web developers are going to take the path of least resistance. Like Qt did with QML? http://doc.qt.io/qt-5/qml-tutorial1.html http://doc.qt.io/qt-5/qml-tutorial1.html
    - ryanpepper 10y ago
      Yeah, but Qt has licensing costs for commercial use...
      - uzoodoo 10y ago
        Qt is LGPL, so unless you need to link to it statically or make proprietary modifications to Qt itself, you don't need to pay licensing costs.
        ryanpepper 10y ago
        Ah right, I wasn't aware of that.
bitmapbrother 10y ago
Is the IntelliJ UI "butt ugly"? No, but you'll probably say it is as to not contradict yourself. Blame the craftsmen not the tool. >Even the end result UI design look & feel is butt ugly You know what else is butt ugly? Programmer art and UI.
pjmlp 10y ago
> Even the end result UI design look & feel is butt ugly. Only when developed by those devs that never bothered to read books like "Filthy Rich Clients".
Insanity 10y ago
I was extremely skeptical of using Swing for a really large hospital application. But after working in it for quite some time, I have to say that with the right approach it is quite manageable. There is plenty of power in there and a lot of good things can be done. (I do prefer the webstack over Swing)

paulddraper 10y ago

> easy to get started Yes. > cross platform support Yes. > Because you can write plugins in JS? Yes. --- As much as I prefer native programs as a user, it's impossible to ignore the benefits of cross-platform development and plebeian hackability/debuggability.

dekhn 10y ago
you can do all of this in Qt, too. Without the overhead of the inner platform effect.
- cle 10y ago
  You can do it, but it's significantly harder. And with Electron, you can leverage the same skills that are used to build web applications to modify your environment and text editor as well. Those are very significant advantages. Note: I don't use VS Code or any other JS editor, I use emacs. But I can definitely appreciate the major benefits of the architecture.
  - josefx 10y ago
    So does it have a NoScript plugin to kill the unavoidable 200 tracking and ad scripts from Google, Facebook and who knows what running in the background? I am sorry if I offend someone with this, however the current Web experience is something I want as far away from my dev. tools as possible.
    - deleted 10y ago
      [deleted]
    - y4mi 10y ago
      tracking or ad scripts by facebook or google are in neither atom nor VSCode. both projects are open source if you care to verify
      - fs111 10y ago

zanny 10y ago

We have a lot of native GUI text editors. Gedit, Geany, Kate, and Notepad++ are free options, and then you have Sublime Text as a proprietary one. They all support plugins and extensions, they are all super efficient in CPU usage, etc. The thing is they aren't new, and because they are all C/C++ codebases developers wanting to add new features to text editors don't want to touch C++98 / ANSI C code from two decades ago. Then you want to start talking about a C++17 / Go / Rust / etc text editor, but that is starting from scratch, and when you consider the time investment to develop the infrastructure of a text editor today vs just using Electron, the time investment makes less sense for hobbyist devs doing this stuff in their free time.

fao_ 10y ago
> developers wanting to add new features to text editors don't want to touch C++98 / ANSI C code from two decades ago. As I understand it, sublime has tight enough integration with python, such that python can do literally everything you would ever need
thomastjeffery 10y ago
> when you consider the time investment to develop the infrastructure of a text editor today vs just using Electron, the time investment ...is exactly the same. No matter what gui toolkit you use, you still need to develop the infrastructure. Electron doesn't know how to handle keyboard and mouse events, it doesn't have a text buffer implemented, has no understanding of different text encodings, how to parse different languages, and draw different colored text accordingly, or format it, etc.
digi_owl 10y ago
CADT, all the way down...

ehsankia 10y ago

Most of these don't support it (yet?), but I personally love the idea of having my editor of choice on the web with all my settings and with no install/permission issues. The real reason to me though seems that it's just the easiest way to make a cross-platform UI. And in this web powered world, everyone knows how to code html/css, so why relearn a bunch of new tools?

Touche 10y ago

> Wouldn't it be better to make native application Better in what way? The market has voted with their downloads, they don't agree that the problems with Electron apps are as bad as you feel that they are.

Philipp__ 10y ago
Are you kidding me? Look at the raw performances and benchmarks of Vim/Sublime/Emacs, compare it to VSCode and Atom and you will see. If you don't believe the numbers then use both side by side, open 250MB file in all of them and look at the screen. And I still see native editors used more (for example latest StackOverflow survey, showed that Notepad++, Vim and Sublime combined are used much much more than VScode and Atom combined). I don't want't my editor to crush mid session, or have to write bunch of gulp files and npm commands to do one simple modification.
- prolly_a_moron 10y ago
  >If you don't believe the numbers then use both side by side, open 250MB file in all of them and look at the screen. Maybe I don't have any 250MB files to open? If VSCode doesn't fit your use case, don't use it. There are innumerable alternatives. But what purpose does it serve to tell the rest of us (who like it) that it sucks?
- sodawater 10y ago
  GP: The market has voted with their downloads You: But I prefer xyz! :( You didn't respond to the argument. What you consider valuable doesn't align with the market.
- therealmarv 10y ago
  I usually never deal with 250MB code files. The right tool for the right task. The Electron programs deal with code in a directory (and btw. VSCode is totally different beast than Atom) and I also would not edit a 250MB file with both of them. Never had a crushing VSCode here... but I always have a better Python and HTML and JS support than e.g. in Sublime+good plugins.
- 10y ago

therealmarv 10y ago

I think you have answered it yourself partly. Creating a highly configurable, UI/UX predictable cross plattform editor is not an easy task. If you start from scratch on a native platform you have to code a ton of code (pretty sure more than VSCode has) just to get started. Editors on web platforms can be modified with CSS, JS (or TypeScript like on VSCode), HTML. Try to be that configurable on a native platform... you literally have to code something equivalent to CSS, HTML, JS to reach that level of modularity. It's good to stay on the shoulders of giants and start there ;)

nottorp 10y ago
Pray tell, sir, have you heard of the Qt library? There is a whole world outside Javascript :)
- therealmarv 10y ago
  So you think hacking QT libraries like this (and not from the outside, I mean internally) and using C++ would make a good community editor? http://doc.qt.io/qt-5/qtwidgets-richtext-syntaxhighlighter-example.html http://doc.qt.io/qt-5/qtwidgets-richtext-syntaxhighlighter-e... When using QT for a highly modular editor be prepared to code QT components from the lowest level. It's not like you take a QT widget and modify it on a simple way. Trust me. If you think it is easy to code editors look e.g. at the people who write letters and their custom editor tool: Microsoft Word. Now look at the many competitors this program had and how many behave super speedy on all plattforms.
  - nottorp 10y ago
    I've written low level GUI components for several UI frameworks before, thank you very much. It's not that bad and a lot smoother for the end user. The real problem is this new generation of "developers" that only know Javascript. When all you have is a hammer...
    - deleted 10y ago
      [deleted]

dheera 10y ago

Yep. I also can't wrap my head around the fact that we are now constructing buttons, drop-down boxes, tagged text boxes using dozens of nested <div> layers instead of a native widget that writes directly to the screen. My 486 rendered UIs with nearly imperceptible lag. Google Docs takes a good 2-3 seconds to spin up a UI on my i7.

therealmarv 10y ago
Would be better to compare it to transfer a state/screen over the wire/internet on 486 vs. doing the same nowadays ;)
- msh 10y ago
  Well a x server on a 486 was probably also faster...
- TeMPOraL 10y ago
  Besides the X-server point, it's not just the state transfer that's causing web UI to lag.
onion2k 10y ago
Google Docs takes a good 2-3 seconds to spin up a UI on my i7. I doubt much of that time is spent building the DOM tree for the UI. Google Docs does a lot more than a simple text editing widget - there's a networked file system, a multi-user collaboration engine, a realtime notification system, etc that all get initialised. Instantiating all that over a network in 2-3 seconds is really fast.
- cr0sh 10y ago
  ...a whole 2-3 seconds! Sometimes I think that comments like these arise out of not having experienced text-only rendering at 300 baud... I know that's a generalization, and most likely unfair - but damn, today's phones, to this old man, are pocket super-computers (for that matter from my vantage point, an Arduino is a wonder, and a RasPi is utterly amazing)!

deleted 10y ago

[deleted]

awinder 10y ago

I switched to vscode from webstorm, for performance reasons. Building a native editor / ide is a great idea. But since a lot of options in this area had already chosen some cross-platform toolkit for development, why not build it as an electron app?

tomc1985 10y ago

The current state of Javascript is very much, "just because you can, doesn't mean you should"

FridgeSeal 10y ago
For sure. Half the responses in this thread are people defending the stupid idea of "let's just use js everywhere, just because we can and fuck better suited tools". Js is not the be all and end all of tools, just because it is used a lot in web doesn't mean it is the best (or appropriate) tool for other spaces. It sort of seems like js/js ecosystem is built around hacky solutions to things, so I guess it makes sense that the community doesn't seem to see any issue with shoehorning in their language of choice into entirely inappropriate spaces.

013a 10y ago

Yeah! We should go back to native editors, like Eclipse or IDEA!

nottorp 10y ago
HN could use a "funny" upvote option...
ethelward 10y ago
Seeing the resources taken for a simple text editor, I crave to see what a full-blown IDE (whic is what Eclipse and IDEA are) written with web technologies would eat up.

koolba 10y ago

Because if we don't build it inside a web browser, we'll have to add plugin support to add a web browser inside of it. Then you have two problems.

JdeBP 10y ago
Actually then, in accordance with Zawinski's Law, one will be able to use that web browser to read mail. (-:

whazor 10y ago

As someone who is literally building a IDE in Electron, the biggest reason is JavaScript itself. If you look to the stackoverflow yearly overview, you can observe that JavaScript is currently the most used language. Also do not forget about all the integrations you could do with for example devtools. An additional feature is that you can run the IDE in the web browser, so that you can have an online code editor. Think for example about configuration files on the Azure website, or a cloud IDE with multiple people using it. Honestly I think Visual Studio Code is not slow enough for people to switch. A long web page is very similar to a long code document, all the keywords are just span's with a colour. Furthermore, it is not like Visual Studio or IntelliJ are known for low CPU or smoothness.

cr0sh 10y ago
I personally wish Github would incorporate a full-feature Electron-based IDE into their system; they do have an online editor, but it is fairly simplistic. Good enough for quick edits, but I wouldn't want to dev in it (then again, I started my professional career in software development sitting in front of a VT220 using a line-based editor; it got bad enough that me and my mentor had a "contest" on who could write a better full-screen code editor - honestly, we both won in a way).
haldean 10y ago
The SO survey (while super interesting!) conflates "most used" with "most asked about on Stack Overflow"; I'm skeptical of anyone who claims to know which programming language is the most popular. The TIOBE index, which has its own problems, has Javascript coming in 8th, with the top 4 being Java, C, C++ and C#; my experiences and my confirmation bias suggest that's more accurate. https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/
- whazor 10y ago
  I agree that tiobe is more established, especially as they look to companies being involved and to the job market. One of the reasons why I am interested in Javascript is that many people are learning it, even non-developers. Think about people without education.

Osmose 10y ago

> Wouldn't it be better to make native application, especially for code editors, where developers spend most of their time, where every noticeable lag and glitches are not appreciated. The lesson here is that our assumed bars of quality for what makes a text editor good are inaccurate. It turns out that the minimum performance bar is lower than you think, and that ease of customization is, in fact, much more important than you think.

m_fayer 10y ago

Because Microsoft and Apple have both dropped the ball on their native UI toolkits. Right now I'm doing web frontend with TS+VueJS+nice CSS toolkit. Yes there's plenty of complaining to do about the fragile convoluted toolchain and crappy performance. But I still gladly take it over WPF (promising, abandoned for some reason) or Cocoa (feels a decade out of date). No major OSS community, no Material Design/Bootstrap/etc. toolkits, slow develop/run loop, no good UI automation, crappy/no inspection capacity, etc. I don't need x-plat UIs, I just need a good UI toolkit period, and that's why I'm looking real hard at Electron for future desktop work.

kitsunesoba 10y ago
Cocoa has its issues, but I find it much more pleasant to use than anything based on front end web tech despite that. I find myself wishing I could use it on Windows and Linux. I find many of the frustrations people have with desktop Cocoa come from the bizarre need to reinvent the wheel with a custom UI theme. If you stop fighting the system and instead go with a native look with well chosen accents, life is much easier. Native can look great with a little attention to detail.
zigzigzag 10y ago
You can also look at JavaFX. It's pretty good.

Kiro 10y ago

Have you used VS Code? Feels much more performant than any native editor or IDE I've ever used.

ovao 10y ago
What native editors have you used?
- Kiro 10y ago
  Primarily Sublime Code, Notepad++, PhpStorm and NetBeans.
  - ovao 10y ago
    That's an unusual experience. Based on a handful of benchmarks[0] done by the author of JOE, VS Code is sometimes an order of magnitude slower than Notepad++ and Sublime at some tasks. I use VS Code pretty much exclusively these days myself, so I'm not picking on it by any means. [0]: https://github.com/jhallen/joes-sandbox/tree/master/editor-perf https://github.com/jhallen/joes-sandbox/tree/master/editor-p...
    - iaml 10y ago
      I have the same experience on my pretty slow laptop. Granted, my projects aren't big, but I would take vs code over sublime any day. Interestingly, atom feels much slower compared to both.
      - FridgeSeal 10y ago
        That's because, unequivocally, atom is slower. https://pavelfatin.com/typing-with-pleasure/ https://pavelfatin.com/typing-with-pleasure/
        iaml 10y ago
        Surprising part isn't that atom is slow, it's that vs code isn't and they both use electron.

rayiner 10y ago

The web is in just a shameful state. Even with 300 mbps fiber internet most websites are not snappy. As in, pages are so slow to render that I'll start reading, but then lose my place when the page reflows as it continues to load. Or click on the wrong thing because the page reflowed while I was trying to click on something. As far as I can tell I'm actually CPU-limited, because I noticed no real difference from when I had 50 mbps internet. This is on a quad-core Macbook Pro that boosts up to 3.5 GHz...

monkpit 10y ago
So you just assume that changing between 50 meg and 300 meg service actually should give you a 6x speed up during browsing? I think that's a very flawed assumption to make. Just because your connection is capable of a certain advertised speed doesn't mean you're getting that speed from any given server as you browse the Internet.
- rayiner 10y ago
  No, I'm assuming that because it didn't give me a noticeable speedup that bandwidth isn't the bottleneck. Also, the bottleneck isn't my connection out to the internet because I can get more than the advertised speed any time of day to speedtest.net servers. I suppose the bottleneck could be on the other end, but aren't these sites all hosted on major platforms these days? Like AWS/Google/etc.?
quicklyfrozen 10y ago
It takes a while to source all the ads, and the reflow that leads you to click on the wrong thing (e.g. an ad) is most likely intentional.

gregmac 10y ago

Building a plugin system is hard. Building one that allows creating complex UI elements, modifying other UI elements (from either the core app or other plugins) or changing the way literally anything is rendered is particularly hard. You not only have to build the code that supports all this, you also have to create and document an API and/or markup format to build all this out, plus document all your internal integration points. If you want other developers to really take it up and build plugins, you have to make it easy to get into, so that means not just documentation, but great documentation, plus tutorials, examples and tooling to help. You get a big chunk of that for free when you use HTML/CSS/JS. Fire up VS Code, go to Help > Toggle Developer Tools, and poke around for a few minutes. Imagine the amount of time it would take to build a similar experience to just this one aspect if you were doing this from scratch.

fao_ 10y ago
Or you could use Lisp, and have the UI be S-Expressions. Everything can edit a list
- striking 10y ago
  Can you give me an example of a Lisp UI library like that?
  - shakna 10y ago
    Two come close but aren't quite there... Seesaw [0] - A nice-ish way of using Swong in Clojure. Iup [1] - One of the friendliest GUIs I've used, hands down. Just feels like Scheme. However, I'd expect that QML and X-Expressions could go hand in hand to make something much closer, with a bit more flexibility. [0] https://github.com/daveray/seesaw https://github.com/daveray/seesaw [1] https://wiki.call-cc.org/iup-tutor#hello0scm https://wiki.call-cc.org/iup-tutor#hello0scm
rvern 10y ago
> Fire up VS Code, go to Help > Toggle Developer Tools, and poke around for a few minutes. Imagine the amount of time it would take to build a similar experience to just this one aspect if you were doing this from scratch. Don't do it from scratch then. You can use GtkInspector to poke around with any GTK+ application, by pressing Ctrl+Shift+I.[1] [1]: https://wiki.gnome.org/Projects/GTK%2B/Inspector https://wiki.gnome.org/Projects/GTK%2B/Inspector

StreakyCobra 10y ago

By making a text editor out of web technologies, you can reuse all the web ecosystem the web has, and enjoy also its customizability. For instance I wanted to be able to display PDFs directly in VSCode. I went to look for a plugin, and there was one. People simply used "pdf.js" to integrate PDF support in VSCode. Because it is web based it should have been straightforward to do. Doing the same with native technology would have took several weeks of coding, and it wouldn't have been cross-platform. Imagine all the web-based open-source tools that could potentially be integrated in these editors. Integrating a SVG editor in native text editors would be a nightmare. With web-based text editor you can potentially just incorporate an existing tool like [1]. There are lot of other examples like this: Live markdown preview, mini-map, color-picker, integrated VSCode debug panel, … It is also quite easy to add visual stuff. For instance adding a vertical bar at 80 characters in the background is quite easy to do with web technologies. On the other side emacs has still not managed yet to make the html-mode work nicely with this "fill-column-indicator". It is also probable that it would be much more easy to integrate web services (trello, github, …) directly within VSCode. At the end people wanting performances have already quite a lot of choice in native text editors (vim, emacs, sublime…), and people who prefer functionalities can go with web-based text editors (atom, vscode, …) [1] https://svg-edit.github.io/svgedit/releases/svg-edit-2.8.1/svg-editor.html https://svg-edit.github.io/svgedit/releases/svg-edit-2.8.1/s...

coldtea 10y ago
>By making a text editor out of web technologies, you can reuse all the web ecosystem the web has, and enjoy also its customizability. For instance I wanted to be able to display PDFs directly in VSCode. I went to look for a plugin, and there was one You know where else you could do the exact same thing AND have a 10x faster and 10x more memory/battery efficient editor? If a native editor just gave you a webview that can run JS extensions...
- Philipp__ 10y ago
  Ema... Ok ok, I will shut up. :)
- StreakyCobra 10y ago

fenomas 10y ago

Your question seems backwards. VS:Code is an absolute dream to use, for me at least - powerful, hackable, and performs great. If there are native editors that leave it in the dust, what are they? If there aren't, surely it would make more sense to ask why that is, rather than asking why Code isn't native?

yatsyk 10y ago

> Wouldn't it be better to make native application Actually there are such editors. I use vim instead of vscode or atom. And I think my installation of vim is slower then vscode because of some plugin that I've not found yet. Applications like vscode very useful because they help to find performance and other bugs in browsers. Same way as browser improved when gmail and sites like this appeared. I would support appearance of IDEs, large games, VR, image and video editors in browsers as they help improve web platform. If you don't like it, just use other option. It could be faster, but may be not. Not sure that vscode is slower then visual studio for most tasks.

sfifs 10y ago

Actually I find the consistency and simplicity of using well established, widely supported and rich third party ecosystem available with using HTML5/CSS/JS based UI very liberating vs. the incompatible mess of native UIs. Personally I script all front-ends in web technologies irrespective of platform and back end tech. The browser rendering engines and JS engines are reasonably fast in most platforms.

parenthephobia 10y ago

> Wouldn't it be better to make native application, especially for code editors, where developers spend most of their time, where every noticeable lag and glitches are not appreciated. I think it'd be better to improve Electron so that native applications don't have so much of an advantage. WebAssembly is a big part of that. Another useful part would be an alternative layout mode that eschews legacy HTML/CSS cruft, for more predictable and performant GUIs.

williamle8300 10y ago

I think their bet is that the web stack won't be "so high up the stack" in the near future.

brulard 10y ago

I switched from sublime to Atom maybe 2 years ago. I'm completely happy with the speed. I see no disturbing lags and it works/looks the same on every platform. There is a great extension system and I can develop my own extension quickly if I ever needed to. I believe for the developers it was much more productive to create it with web technology and therefor I don't see any reason why it shouldn't be done like that. I guess there are people that need much faster this or that, and as low memory footprint as possible, but it is not an average user/developer. I believe for most of us these editors work well

pcarolan 10y ago

Have you tried VS code? It seems your arguments about performance are theoretical but in my experience i have run into none of what you're describing could happen on a 5 year old macbook air. A 14% cpu idle due to a cursor is a bug that will be squashed. The software experience, in practice, is quite impressive.

hasenj 10y ago

I used to think the same, until I started using VS code and it completely blew me away! I don't care if it's written on to of a browser or in assembly. I just know it's the best text editor I've used so far.

watty 10y ago

It just doesn't go in my head how so many people have trouble understanding why things like VSCode or Atom are popular. They're sexy, they are powerful (extensions for everything), portable, and extremely easy to extend thanks to Javascript being pervasive. I don't know for certain but I'd also assume writing an Electron app is easier than writing a similar app in a lower level language. Is it really that hard to grasp? Performance has to be perceptible by the average person for it to affect user base. I prefer WebStorm but I've had absolutely no issues using VSCode on my laptop - which feels even faster than WebStorm.

ConceptJunkie 10y ago
I've played around with VSCode and what it can do seems impressive, but I want to do one simple thing. I want to make the background black. Every dark theme I can find makes the background dark gray, not black. I actually looked into what it would take to make a new color theme and I simply don't understand all the steps, and definitely don't want to deal with the hassle. It very quickly goes off into the weeds of TextMate themes (huh? Why are we referencing a Mac editor? Yeah, I know it's a de facto standard, but really?), editing XML (complete with hex codes for colors) and installing something called "Yo Code". Dude, I just want to change one friggin' color! In every native app I've ever used, I can just go into the Options and make the background black, period. Just because it's a programmer's editor shouldn't mean you need to be a programmer to make the simplest configuration.
- jes5199 10y ago
  I don't know about VSCode, but in Atom you'd just write one line of CSS

watty 10y ago

It just doesn't go in my head how so many people have trouble understanding why things like VSCode or Atom are popular. They're sexy, they are powerful (extensions for everything), portable, and extremely easy to extend thanks to Javascript being pervasive. Is it really that hard to grasp? Performance has to be perceptible by the average person for it to affect user base. I prefer WebStorm but I've had absolutely no issues using VSCode on my laptop - which feels even faster than WebStorm.

dragonwriter 10y ago

> Wouldn't it be better to make native application, especially for code editors, where developers spend most of their time, where every noticeable lag and glitches are not appreciated. There are plenty of native-application (or JVM/CLR) text editors and IDEs, too. For lots of usage patterns, the browser-engine-based ones have acceptable performance, and the number of people with expertise building for web contributes to the speed of development on those editors and their plugins. But, sure, if you don't like Electron-based editors, there are plenty of other actively-developed editors for you to choose from.

dualogy 10y ago

> It just doesn't go in my head that we are building text editors inside a web browser! I felt the same until I actually tried it out. That changed my mind: now I'll take any platform that those developers & contributors choose for their cross-platform products. Because this for an Electron app, this is a rock-solid 'old-school' (as in, fully as neat smooth helpful-yet-staying-out-of-the-way and somehow "ergonomic" as it was ever since at least oh late 90s, v6 or so) "Visual Studio experience". After a few years of sitting listlessly in front of subjectively inferior editors, I'm prepared & willing to give this Electron stuff more time to further mature improve and speed up. There's no intrinsic reason it can't get there. Lots of seemingly native apps are just live Lua/Python interpreters under the hood with widget bindings in place of a DOM. In that case, well-engineered JavaScript (terribly time-consuming to produce & pretty rare out there for those who like to rely blindly on a huge pile of unscrutinized 3rd-party snippets/script um-I-mean "repos" --- but not impossible) can fully deliver the same, in principle. Seeing how VScode took off, that could even propel MS to invest unprecedented energies & talent into rounding up the JS "rich client app" performance story further. Who knows.

sigzero 10y ago

No, you are correct. It is insane.

deleted 10y ago

[deleted]

payonel 10y ago

the benchmark you linked is outdated, I reran those tests just now with vscode and could perform all open, edit, close operations in the test in fewer than 2s.

deleted 10y ago
[deleted]

pix64 10y ago

You could write a native text editor which can use JS plugins. Sublime Text uses python plugins and is nice and snappy.

userbinator 10y ago

Wouldn't it be better to make native application, especially for code editors, where developers spend most of their time, where every noticeable lag and glitches are not appreciated. I agree. However, as someone who has used Visual Studio (the one that costs $$$, not VSCode) which is a native application (AFAIK --- it probably has some .NET and web components too), I can attest to the fact that even native applications can be extremely resource-consuming and slow.

mvindahl 10y ago

VSCode runs nicely on my MacBook. It doesn't feel like a web application to me, in the same way that IntelliJ IDEA doesn't feel like it's written in Java. I'm sure that both VSCode and IDEA could run even faster if they were ported to, say, C, but in both cases that would be a large investment for improvements that I wouldn't even detect. So I guess it makes sense to optimize for maintainability i this case, i.e. not having one codebase per native OS.

joshwcomeau 10y ago

I really like that I can edit my editor. A few times, I've disliked how something looked or wanted to add a feature. So I tweaked the stylesheet, or wrote an Atom plugin. There's a beautiful poetry to being able to do web dev inside a web application. I still have Sublime text for when I need to view/edit files with tens of thousands of lines, since Atom chokes on large files, but otherwise I have zero regrets :) I'm as productive in Atom, and it's a more pleasant experience.

nonsince 10y ago

Agreed. If you're looking for easy extensibility, a simple core and a flexible GUI, I can't imagine what could put VSCode above emacs, except for the button marked "sort by CPU usage"