Live data from Hacker News

Building a hackable editor in the browser

bjenik.com

41–50 of 74 posts

Re: Building a hackable editor in the browser

#41
post #27

So AFAIK Electron is built on V8 JS engine. Last I looked that has a JIT compiler, then I’d expect performance to increase as that ‘warms up’

It does, but you've still got to keep around the optimizing JIT compiler, its JavaScript metadata, and a hundred other things around even after the JavaScript has been partially compiled to native code.

Re: Building a hackable editor in the browser

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

I've been thinking a lot about this lately and I'm trying to compile some information on how others think it should work.

Can you elaborate on what you mean by an all-native solution on top of a powerful modern language?

The way I see it is that a new toolkit like GTK or Qt is required in the target language.

Re: Building a hackable editor in the browser

#43
post #37
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://ww…

Qutebrowser is really amazing and I'm using it for lots of my browsing, too. What keeps me from going all in is the lack of something that can match ublock+umatrix. Sadly, the Internet has become a harsh place, where these things are needed.

Re: Building a hackable editor in the browser

#44

Earlier quoted context omitted.

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.

Flutter is drawing a native style UI elements on an OpenGL (like) surface, and that is pure binary running on the device processor. Platform-specific features like Bluetooth, WiFi, etc. are bridged just like in ReactJs.

Re: Building a hackable editor in the browser

#45
post #11
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 write moderately complex web apps and I have to say 200ms for a user interaction sounds like far too long. All apps regardless of where they're running should be managing a solid 60fps, which gives you a budget of 16ms for the UI to react to a user event. Obviously starting the app is going to take longer, especially from cold, but if you ignore things like DNS resolution and download time then 200ms is more than e…

It shouldn't be obvious that startup is slower and I didn't mean UI reaction, but the more broader reaction time. For example from typing a location and hitting enter, it should take something like Google Maps zero point two seconds at most to completely load the page and be done with everything. The user shouldn't have a concept of "loading time" and that includes starting the application.

Re: Building a hackable editor in the browser

#46
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 do like performant apps, but I've never understood the emphasis on startup time for most of them. There's the odd utility (eg. screenshotting) where an instant start is desirable. But the main things I use (terminal, editor/ide, browser etc) are started once per week at most. I personally wouldn't want the developers of the software I depend on most to waste resources speeding up something of such marginal signific…

I have a workflow where I spawn and close terminals depending on whether I want something done. If my terminal startup wasn't instantaneous, I'd be switching to one that was. (Currently using urxvt). The only reason I keep my browser open is because it doesn't start instantaneously. Imagine a world where your computer and all your apps can start instantaneously. It would be viable to shutdown your computer when leaving the room instead of just locking it.

In this reality, however, I would already be happy if tabs in a browser could load that fast, so I wouldn't have to keep hundreds of them open all the time.

Re: Building a hackable editor in the browser

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

Yes that would be awesome!

Unfortunately the providers of the OS'es we use don't bother with this.

What would the world be like if you could run anything anywhere and most importantly: how would you decide that you prefer a mac to a windows-machine?

I think web technologies are a bridge that many like to use because of the sad state of things in the UI domain.

Re: Building a hackable editor in the browser

#48
post #21
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.

What desktop programs do you use that take fewer than 0.2 seconds to start?

fyi, I'm on Linux.

Here's a list: ranger, urxvt, sxiv, w3m, xev, vim, feh and qutebrowser.

Re: Building a hackable editor in the browser

#49

Earlier quoted context omitted.

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

Flutter is drawing a native style UI elements on an OpenGL (like) surface, and that is pure binary running on the device processor. Platform-specific features like Bluetooth, WiFi, etc. are bridged just like in ReactJs.

"Native" in context of UI toolkits is "using system-provided UI controls through system APIs". The opposite of that is drawing your own controls, which then usually don't integrate well with the OS and don't support the interoperability and accessibility features that are expected of UI controls on that OS.

Re: Building a hackable editor in the browser

#50

Earlier quoted context omitted.

Flutter is drawing a native style UI elements on an OpenGL (like) surface, and that is pure binary running on the device processor. Platform-specific features like Bluetooth, WiFi, etc. are bridged just like in ReactJs.

"Native" in context of UI toolkits is "using system-provided UI controls through system APIs". The opposite of that is drawing your own controls, which then usually don't integrate well with the OS and don't support the interoperability and accessibility features that are expected of UI controls on that OS.

That's what native used to be, but nowadays it's "not electron". Qt or wxWidget apps are considered native as well.
Post reply on HN