5 ms·

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

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
  > 10x faster and 10x more memory/battery efficient editor? Except for the startup time --- with which I can live with --- I never felt a difference in speed between native text editors ans VSCode. There is one, but I don't notice it. Human are much more slower than computers, so as long as it is not taking more time that I need to notice it, I don't care. Nowadays my computer has enough memory so I can afford to not care about the 116M that VSCode is currently using, especially in regard to what my browser consumes, and in regards of the wide range of features it offers. Battery could be problematic indeed, but before looking at my text editor, I would probably first switch from KDE to i3, and then use a lightweight web browser. This would impact it much more than my text editor. > If a native editor just gave you a webview that can run JS extensions... But then you start loosing all the benefits of faster/memory/battery points you mentioned. Anyway, I'll happily try something like this if you develop it ;-)
  - dom0 10y ago
    > Battery could be problematic indeed, but before looking at my text editor, I would probably first switch from KDE to i3, and then use a lightweight web browser. This would impact it much more than my text editor. This item is about VS Code consuming 13 % CPU when idle, which is bigger than the difference in idle CPU between KDE and i3 (if you don't have fancy widgets, it's about ~nil).
    - StreakyCobra 10y ago
      Indeed, this bug is pretty nasty for the battery. I don't have it though, so my remark was about non-buggy battery usage. Web-based text editors consumes more battery, but the difference is not significant from my point of view.
  - coldtea 10y ago
    >Except for the startup time --- with which I can live with --- I never felt a difference in speed between native text editors and VSCode. There is one, but I don't notice Try editing anything larger than a simple program file (from a large JSON to a CSV as devs often do) and you'll do. Try hex editing a large binary. And many other tasks.
Philipp__ 10y ago
One of the nicest replies here. Thanks! :)
rvern 10y ago
> Doing the same with native technology would have took several weeks of coding, and it wouldn't have been cross-platform. Actually, it would take one hour because you would use Poppler, and it would be cross-platform. It would also be faster than pdf.js.
- StreakyCobra 10y ago
  > Actually, it would take one hour because you would use Poppler, and it would be cross-platform. It would also be faster than pdf.js. I don't really know poppler. If there are Poppler bindings for the language you are developing in, I believe you that this is possible. This is only one use case though, I'm not sure you will find native libraries in your language for all features that VSCode can offer almost for free, like live markdown preview for instance.
  - mixedCase 10y ago
    I don't think the implication you're making here is valid. In Electron you're forced to use JavaScript or a compile-to-JavaScript language. In the desktop it's pretty much the same deal but with C. And we've been doing C FFI since way before JavaScript was conceived.
  - spdionis 10y ago
    > I don't really know poppler. Exactly. Web developers live in a bubble, and because they don't know much about native alternatives, they assume they don't exist. Note: I'm a web developer and I don't know poppler.
digi_owl 10y ago
That depends on all the code running locally...
captainmuon 10y ago
> 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 could have done that 20 years ago with COM components already. There was a thriving ecosystem where you could get a component for just about everything. Similar technologies were available on other platforms than Windows, like Bonobo (Gnome), Kparts (KDE), and whatever Mac had. It's a bit of a shame that component frameworks have gotten such a bad reputation (for complexity and insecurity), I think they are very misunderstood.
- z3t4 10y ago
  You also had to pay 100$ per copy of the COM component. Most of the web stuff is free, and you can just right click and view source. In NodeJS and NPM there are hundreds of thousands of components/modules that you can use for free.
lorenzfx 10y ago
I don't think this would have been any harder had it been written in C(++) for someone comfortable in C(++). But I do believe there are more people comfortable with web technologies these days.
zigzigzag 10y ago
> Doing the same with native technology would have took several weeks of coding, and it wouldn't have been cross-platform. I wrote a PDF viewer in Java(FX) in about one evening using PDFbox. There are also PDF components for practically any other desktop app framework you care to name, most of them older and more mature than pdf.js The fact that so many devs express amazement at things considered utterly routine for decades is one of the reasons the entire web dev community is so often treated as a joke. HTML has very few redeeming features as an app platform. It's way past time it gets killed by something better.
framp 10y ago
This is wrong. The world on the other side is so much greener. https://wiki.qt.io/Handling_PDF#Using_QtPDF https://wiki.qt.io/Handling_PDF#Using_QtPDF

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
> 10x faster and 10x more memory/battery efficient editor? Except for the startup time --- with which I can live with --- I never felt a difference in speed between native text editors ans VSCode. There is one, but I don't notice it. Human are much more slower than computers, so as long as it is not taking more time that I need to notice it, I don't care. Nowadays my computer has enough memory so I can afford to not care about the 116M that VSCode is currently using, especially in regard to what my browser consumes, and in regards of the wide range of features it offers. Battery could be problematic indeed, but before looking at my text editor, I would probably first switch from KDE to i3, and then use a lightweight web browser. This would impact it much more than my text editor. > If a native editor just gave you a webview that can run JS extensions... But then you start loosing all the benefits of faster/memory/battery points you mentioned. Anyway, I'll happily try something like this if you develop it ;-)
- dom0 10y ago
  > Battery could be problematic indeed, but before looking at my text editor, I would probably first switch from KDE to i3, and then use a lightweight web browser. This would impact it much more than my text editor. This item is about VS Code consuming 13 % CPU when idle, which is bigger than the difference in idle CPU between KDE and i3 (if you don't have fancy widgets, it's about ~nil).
  - StreakyCobra 10y ago
    Indeed, this bug is pretty nasty for the battery. I don't have it though, so my remark was about non-buggy battery usage. Web-based text editors consumes more battery, but the difference is not significant from my point of view.
- coldtea 10y ago
  >Except for the startup time --- with which I can live with --- I never felt a difference in speed between native text editors and VSCode. There is one, but I don't notice Try editing anything larger than a simple program file (from a large JSON to a CSV as devs often do) and you'll do. Try hex editing a large binary. And many other tasks.

Philipp__ 10y ago

One of the nicest replies here. Thanks! :)

rvern 10y ago

> Doing the same with native technology would have took several weeks of coding, and it wouldn't have been cross-platform. Actually, it would take one hour because you would use Poppler, and it would be cross-platform. It would also be faster than pdf.js.

StreakyCobra 10y ago
> Actually, it would take one hour because you would use Poppler, and it would be cross-platform. It would also be faster than pdf.js. I don't really know poppler. If there are Poppler bindings for the language you are developing in, I believe you that this is possible. This is only one use case though, I'm not sure you will find native libraries in your language for all features that VSCode can offer almost for free, like live markdown preview for instance.
- mixedCase 10y ago
  I don't think the implication you're making here is valid. In Electron you're forced to use JavaScript or a compile-to-JavaScript language. In the desktop it's pretty much the same deal but with C. And we've been doing C FFI since way before JavaScript was conceived.
- spdionis 10y ago
  > I don't really know poppler. Exactly. Web developers live in a bubble, and because they don't know much about native alternatives, they assume they don't exist. Note: I'm a web developer and I don't know poppler.

digi_owl 10y ago

That depends on all the code running locally...

captainmuon 10y ago

> 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 could have done that 20 years ago with COM components already. There was a thriving ecosystem where you could get a component for just about everything. Similar technologies were available on other platforms than Windows, like Bonobo (Gnome), Kparts (KDE), and whatever Mac had. It's a bit of a shame that component frameworks have gotten such a bad reputation (for complexity and insecurity), I think they are very misunderstood.

z3t4 10y ago
You also had to pay 100$ per copy of the COM component. Most of the web stuff is free, and you can just right click and view source. In NodeJS and NPM there are hundreds of thousands of components/modules that you can use for free.

lorenzfx 10y ago

I don't think this would have been any harder had it been written in C(++) for someone comfortable in C(++). But I do believe there are more people comfortable with web technologies these days.

zigzigzag 10y ago

> Doing the same with native technology would have took several weeks of coding, and it wouldn't have been cross-platform. I wrote a PDF viewer in Java(FX) in about one evening using PDFbox. There are also PDF components for practically any other desktop app framework you care to name, most of them older and more mature than pdf.js The fact that so many devs express amazement at things considered utterly routine for decades is one of the reasons the entire web dev community is so often treated as a joke. HTML has very few redeeming features as an app platform. It's way past time it gets killed by something better.

framp 10y ago

This is wrong. The world on the other side is so much greener. https://wiki.qt.io/Handling_PDF#Using_QtPDF https://wiki.qt.io/Handling_PDF#Using_QtPDF