Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building a hackable editor in the browser

bjenik.com

Post reply on HN
Print view View original

31–40 of 74 posts

Re: Building a hackable editor in the browser

#31

Post by crispinb »

XCSme wrote: post #10
Kaiyou wrote: post #9

Earlier quoted context omitted.

Probably because your desktop apps are bloated, too. Any software that needs longer than zero point two seconds reacting to user action (this includes starting the program) should be improved upon.

I think the only native apps that I use are Steam, Unity, Photoshop, SourceTree and VSCode. Out of those the only "fast" one is VSCode, which is actually written in JS. Even though you mentioned the browsers being "bloated", for me Chrome always starts up instantly and I have no responsivness issues when browsing sites, playing browser games or using browser apps.

Out of those the only "fast" one is VSCode, which is actually written in JS

Typescript I think? Anyway, much as Microsoft has done an amazing job with VS Code, it really doesn't have quite the snappy feel in all circumstances of a native app. Extension loading on start up is one example. If you use a keyboard mapping extension it's quite possible to start typing on launch and find the mapping hasn't kicked in yet.

That's not to say it isn't worth the tradeoff. The costs are inconsequential, and the benefits great. I'm mostly an IntelliJ Idea user, but the sheer speed with which VS Code is developed often tempts me towards it (eg. it's well ahead of Idea on wsl integration)

Re: Building a hackable editor in the browser

#32

Post by bin0 »

avmich wrote: post #23
arghwhat wrote: post #22

Earlier quoted context omitted.

If you think you browser is fast, you'd be blown away by any decent application. Too bad all apps are now electron.

> If you think you browser is fast, you'd be blown away by any decent application. In data centers, loading data from networked server, where it's in memory, can be used over loading data from a disk, because disk is comparatively slow. A web app can load JavaScript assembler, which isn't much slower than a desktop app written in C. Bigger - and slower - parts of the web app can be loaded after the app starts interac…

This is misleading as all get-out. "JavaScript assembler" is WASM, I assume? Running it in a browser still includes the overhead of a browser. The slowness is not from the wasm runtime (which has been implemented standalone and is fast), but in the browser-y gui stuff (which is what electron is good for). Also, WASM has less tooling etc. around it than JS, so JS is used for now. And jS is slow, but it's what is used by electron.

Your saying "electron could be made faster if we did all these huge things" is like me saying "but the c could be faster if we did great threading, really efficient code, inline ASM, and used intel's crazy compiler for maximum optimization". I get there's hope for the future, but not currently. In any case, implementing a custom graphics stack (like the web) will always be a heavy-weight task compared to one application.

Re: Building a hackable editor in the browser

#33

Post by lostmsu »

XCSme wrote: post #10
Kaiyou wrote: post #9

Earlier quoted context omitted.

Probably because your desktop apps are bloated, too. Any software that needs longer than zero point two seconds reacting to user action (this includes starting the program) should be improved upon.

I think the only native apps that I use are Steam, Unity, Photoshop, SourceTree and VSCode. Out of those the only "fast" one is VSCode, which is actually written in JS. Even though you mentioned the browsers being "bloated", for me Chrome always starts up instantly and I have no responsivness issues when browsing sites, playing browser games or using browser apps.

Steam UI is also just a webview mosly. You can see its WebHelper processes. I would check if SourceTree is too.

Re: Building a hackable editor in the browser

#34

Post by frutiger »

giancarlostoro wrote: post #18
stabbles wrote: post #13

Earlier quoted context omitted.

Your slow desktop app is an electron app

I was going to comment this. Typically these days a LOT of Desktop apps are Electron based: VS Code, Slack, Signal, probably Keybase, Skype, MS Teams, Discord, RamBox, IRCCloud, Postman, Insomnia, Light Table, Hyper, and... The list goes on. But those are apps I have used and know are Electron. Thats at least 10 different instances of Chrome on a system running at any given time.

It’s only ten instances of Chromium if you actually run all ten apps at any given time!

Re: Building a hackable editor in the browser

#35

Post by [deleted] »

crispinb wrote: post #31
XCSme wrote: post #10

Earlier quoted context omitted.

I think the only native apps that I use are Steam, Unity, Photoshop, SourceTree and VSCode. Out of those the only "fast" one is VSCode, which is actually written in JS. Even though you mentioned the browsers being "bloated", for me Chrome always starts up instantly and I have no responsivness issues when browsing sites, playing browser games or using browser apps.

Out of those the only "fast" one is VSCode, which is actually written in JS Typescript I think? Anyway, much as Microsoft has done an amazing job with VS Code, it really doesn't have quite the snappy feel in all circumstances of a native app. Extension loading on start up is one example. If you use a keyboard mapping extension it's quite possible to start typing on launch and find the mapping hasn't kicked in yet. Th…

[deleted]

Re: Building a hackable editor in the browser

#36

Post by TeMPOraL »

frutiger wrote: post #34
giancarlostoro wrote: post #18

Earlier quoted context omitted.

I was going to comment this. Typically these days a LOT of Desktop apps are Electron based: VS Code, Slack, Signal, probably Keybase, Skype, MS Teams, Discord, RamBox, IRCCloud, Postman, Insomnia, Light Table, Hyper, and... The list goes on. But those are apps I have used and know are Electron. Thats at least 10 different instances of Chrome on a system running at any given time.

It’s only ten instances of Chromium if you actually run all ten apps at any given time!

Which is like, the reason people invented multi-tasking operating systems, somewhere around 1960s.

Which is why current disregard for application performance really irks me. A computer is meant to run a lot of things at the same time. To some point, the utility of a computer scales with the number of things you can run simultaneously on it. Your Electron chat client that thinks it own 100% of CPU and RAM essentially puts a soft limit on that. It's less of a problem for power users, who know how to work around such problems, but it is a deal for regular people, who'd love to run a few things at a time but can't, because one or two apps grinds their cheap computer to a halt.

Re: Building a hackable editor in the browser

#37

Post by dijit »

Kaiyou wrote: post #6

...how about moving things out of the browser? It's cramped as it is. And then people wonder why their browser is so slow... "it's just displaying documents!"

This is what I do, ^E opens a vim buffer with the contents of whatever I’m editing.

Make my changes, save/quit and it appears in my text box in the browser. Obviously doesn’t work on my phone (why would I want it to?) but it’s a super nice workflow (if a bit jarring to have another program/terminal pop open).

I’m using qutebrowser for this, and this mechanism is an officially supported part of the browser.

https://www.reddit.com/r/qutebrowser/comments/780u6a/how_to_...

Re: Building a hackable editor in the browser

#38

Post by TeMPOraL »

avmich wrote: post #23
arghwhat wrote: post #22

Earlier quoted context omitted.

If you think you browser is fast, you'd be blown away by any decent application. Too bad all apps are now electron.

> If you think you browser is fast, you'd be blown away by any decent application. In data centers, loading data from networked server, where it's in memory, can be used over loading data from a disk, because disk is comparatively slow. A web app can load JavaScript assembler, which isn't much slower than a desktop app written in C. Bigger - and slower - parts of the web app can be loaded after the app starts interac…

> In data centers, loading data from networked server, where it's in memory, can be used over loading data from a disk, because disk is comparatively slow.

Most people however don't live in a data center. On regular computer and with regular Internet connection, even spinning rust blows the network out of the water. And computers increasingly ship with flash memory these days.

> A web app can load JavaScript assembler, which isn't much slower than a desktop app written in C.

A desktop app has already loaded that assembler at build-time, and when executed, it loads and runs native code.

(Well, sorta. Scripting is a huge thing for modularity and extensibility, and people do frequently choose slow languages like Python for that. Then again, some languages (like some Python implementations) let you compile scripts on first run and execute binaries later on. I actually wish more languages were designed like Common Lisp is, where you keep a seamlessly integrated compiler available at runtime and are expected to take advantage of it - in case of SBCL (a CL implementation), this means a fast to-native compiler, which on occasions can make an application faster than it would be in an otherwise ahead-of-time compiled language.)

> Bigger - and slower - parts of the web app can be loaded after the app starts interacting. So - at least in principle - no sizeable speed difference, which would blow somebody away.

So can desktop apps. Except they rarely need that, if huge, because it's harder to make them slow by default.

I mean, take Slack - a frequent target of performance complaint. They have a bloated web client, an even worse Electron app, and here I am, using Ripcord[0] on both Windows and Linux (and it has a Mac version too), getting the same functionality at a fraction of the resource use, and there's literally nothing slow there. Nothing. Not a thing (except connecting) takes a perceptible delay. That's how fast you can make a modern chat client, if you care.

> Advantage of web app is cross platform uniformity. Write once, run everywhere.

That's a big advantage, true. It's easier. Though it does come at a cost.

--

[0] - https://cancel.fm/ripcord/

Re: Building a hackable editor in the browser

#39

Post by saagarjha »

ajconway wrote: post #29
Kaiyou wrote: post #6

...how about moving things out of the browser? It's cramped as it is. And then people wonder why their browser is so slow... "it's just displaying documents!"

For that we’ll need an adequate cross-platform (-ish) way of doing UI. I’m not a fan of React Native, but it seems to be the technology we’re looking for, though it doesn’t seem to be as ready for the desktop yet. An all-native solution on top of a powerful modern language (rust?) would be ideal, but that doesn’t seem to be the direction things are moving. We’ll probably end up with Flutter/Native.

Flutter isn't "native" as you would use that word in the context of UI design toolkits.

Re: Building a hackable editor in the browser

#40

Post by saagarjha »

lostmsu wrote: post #33
XCSme wrote: post #10

Earlier quoted context omitted.

I think the only native apps that I use are Steam, Unity, Photoshop, SourceTree and VSCode. Out of those the only "fast" one is VSCode, which is actually written in JS. Even though you mentioned the browsers being "bloated", for me Chrome always starts up instantly and I have no responsivness issues when browsing sites, playing browser games or using browser apps.

Steam UI is also just a webview mosly. You can see its WebHelper processes. I would check if SourceTree is too.

Sourcetree is a native app.
Post reply on HN