511–520 of 777 posts
Earlier quoted context omitted.
Mainly due to them being both more tightly integrated to C++/Python than JS/TS for building desktop apps.
Yeah, but, honest question, why would you want to use JS if you didn't have to? It's like, the worst language possible.
Earlier quoted context omitted.
A Pentium II could barely process DVD-resolution MPEG-2 in realtime. According to http://www.vogons.org/viewtopic.php?p=423016#p423016 a 350MHz PII would've been enough for DVD, and that's 720x480@30fps; videoconferencing would more commonly use 320x240 or 352x288 which has 1/4 the pixels, and H261 or H263 instead as the codec. Being able to Zoom call and see up to 16 live video feeds simultaneously is an amazing adv…
Don’t think it can be an MCU box. You can select an individual stream from the grid to make it larger almost instantly. The individual feeds can display both as grid and a horizontal row. I’m assuming they send individual feeds and the client can ask for feeds at different predefined resolutions.
As a long-time Win32 developer, my only answer to that question is "of course there is!" The efficiency difference between native and "modern" web stuff is easily several orders of magnitude; you can write very useful applications that are only a few KB in size, a single binary, and that same binary will work across 25 years of OS versions. Yes, computers have gotten faster and memory and disks much larger. That does…
You are looking back at the past with rosy goggles. What I remember from the time was how you couldn’t run that many things simultaneously. Back when the Pentium II was first released, I even had to close applications, not because the computer ran out of RAM, but because the TCP/IP stack that came with Windows 95 didn’t allow very many simultaneous connections. My web browser and my chat were causing each other to er…
Earlier quoted context omitted.
> Meanwhile, your web app may not be as good as native apps, but at least you don't have to write it 6 times. I must be living in a parallel world because I use a ton of desktop apps that aren't "written 6 times" - and write a few, including a music & other things sequencer ( https://ossia.io ). Just amongst the ones running on my desktop right now, Strawberry (Qt), Firefox (their own toolkit), QtCreator (Qt), Telegr…
In my experience Java GUIs are consistently even more laggy and unresponsive than Electron apps. They may be lighter in terms of memory, but they never feel lighter. Even IntelliJ and family - supposedly the state of the art in Java apps - feel like mud on a brand-new 16" Macbook Pro.
As a long-time Win32 developer, my only answer to that question is "of course there is!" The efficiency difference between native and "modern" web stuff is easily several orders of magnitude; you can write very useful applications that are only a few KB in size, a single binary, and that same binary will work across 25 years of OS versions. Yes, computers have gotten faster and memory and disks much larger. That does…
You are looking back at the past with rosy goggles. What I remember from the time was how you couldn’t run that many things simultaneously. Back when the Pentium II was first released, I even had to close applications, not because the computer ran out of RAM, but because the TCP/IP stack that came with Windows 95 didn’t allow very many simultaneous connections. My web browser and my chat were causing each other to er…
Earlier quoted context omitted.
Qt may not 'look' native, but it has native performance, whereas Electron really doesn't.
The difference between "Qt native" and " native native" (e.g. Win32 or Cocoa) is still noticeable if you pay attention, although it's not quite as obvious as between Electron and the former. (Likewise, applications using the JVM may also look very convincingly like native ones, but you will feel it as soon as you start interacting with them.)
Web apps come from a tradition of engaging the user. This means (first order) to keep people using the app, often with user-hostile strategies: distraction, introducing friction, etc.
Native desktop apps come from a tradition of empowering the user. This means enabling the user to accomplish something faster, or with much higher quality. If your app distracts you or slows you down, it sucks. "Bicycle for the mind:" the bicycle is a pure tool of the rider.
The big idea of desktop apps - heck, of user operating systems at all - is that users can bring their knowledge from one app to another. But web apps don't participate in this ecosystem: they erode it. I try a basic task (say, Undo), and it doesn't work, because web apps are bad at Undo, and so I am less likely to try Undo again in any app.
A missing piece is a force establishing and evolving UI conventions. It is absurd that my desktop feels mostly like it did in 1984. Apple is trying new stuff, but focusing on iPad (e.g. cursors); we'll have to see if they're right about it.
The exception to this is something either so simple that it only has one button (e.g. some file format converter) or so large (e.g. Photoshop, Bloomberg, AutoCAD, Mathematica, Visual Studio) that it surpasses the capabilities of the web platform.
Most things like chat, music, or word processing absolutely can and should be done with Electron or (imo) a WebView.
The reason Slack etc. is slow is not because of Electron but because the JavaScript is probably very poor, bloated, and not optimized. I used to hate Electron for being slow but after using it have changed my mind. The bottleneck is never on the Electron side; it slow because of your code. VS Code is an Electron app and is snappier than many "native" editors.