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’
Building a hackable editor in the browser
41–50 of 74 posts
Re: Building a hackable editor in the browser
#42...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.
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...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…
Re: Building a hackable editor in the browser
#44Earlier 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.
Re: Building a hackable editor in the browser
#45Earlier 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…
Re: Building a hackable editor in the browser
#46Earlier 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…
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...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.
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
#48Earlier 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?
Here's a list: ranger, urxvt, sxiv, w3m, xev, vim, feh and qutebrowser.
Re: Building a hackable editor in the browser
#49Earlier 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.
Re: Building a hackable editor in the browser
#50Earlier 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.