Hacker News Reader

> 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.

> 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.

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.

> 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.

> 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.

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.

>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...

Ema... Ok ok, I will shut up. :)

> 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 ;-)

> 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).

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.

>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.

Sooner this evening I had to open a 144'000 lines CSV file, 3.5MB. This is not big, but it is the kind of file I have to open from time to time for my work. No noticeable delay to open the file in VSCode, the cursor moves smoothly, and scrolling with the minimap through the whole 144'000 lines is also smooth. The VIM plugin for VSCode start to have troubles over 10M it seems, but if I have to edit files bigger than this I can open them with spacemacs anyway. I spend most of my time in small text files like Python, CSV or Makfiles, so this is not a problem. Of course if you have other requirements, like you are passing a lot of time in big files, then VSCode is not the correct tool.

I would suggest you to try VSCode for curiosity, if you have not done it yet. You could be surprised. Maybe it is not the right tool for you, but it is quite well made, and compared to atom, bracket or other web-based text editor, it feels like a supersonic jet.

> 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.

One of the nicest replies here. Thanks! :)

This is wrong. The world on the other side is so much greener.

https://wiki.qt.io/Handling_PDF#Using_QtPDF

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.

That depends on all the code running locally...