121–130 of 199 posts
Instead of wrapping the application with something like Electron, why not install as a service and connect to a localhost port using your default browser? I know this is not the same UX as installing an app. But why isn't this technique more standard? Besides more efficient resource usage, another benefit is that it keeps the client/server architecture.
> There are just too many levels, and JavaScrip is an interpreted language, not a compiled one, so by default, it will be orders of magnitude slower than an app written in Swift, Rust, or C++. JavaScript isn't as fast as C++ or Rust, but it's pretty fast. Around the speed of Java and Go in some cases, which are compiled. For a web app the speed of the language is rarely the bottleneck anyway, other than some exceptio…
> JavaScript isn't as fast as C++ or Rust, but it's pretty fast. Around the speed of Java and Go in some cases, which are compiled. Sorry, not even remotely close. I want to see some serious evidence. JS id as unoptimizable as can be, thanks to its hyper dynamic nature. And js developers without any clue about memory will happily allocate hundreds of thousands of unnecessary objects to save a line of code. Completely…
And yet it has been optimized.
> Sorry, not even remotely close. I want to see some serious evidence.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
JS is ~30% slower than Java or Go.
Go is a lot closer to JS perf than to C++ perf.
---
For real-world applications....compare IntelliJ, Eclipse, Visual Studio, or Sublime against VSCode.
One thing that makes me use a web-app rather than a native one on PC is that I know for a fact that the browser app will be very limited in tampering with my computer, something I'm not so sure about when installing native applications. Often I see Nvidia's or Microsoft's or Discord's own services snooping in my installed applications, but it can go much further with, e.g., applications like grammarly that have acces…
In addition to the massive benefit of running browser-sandboxed, web apps are also:
1. Easier to start and stop (open/close a tab)
2. Less permanent (clear your browser's local storage and no data is left to stagnate on your hard drive)
3. Portable - no installation required
4. Cross-platform by nature of being a website
And you're totally right about companies pushing desktop apps because they're more invasive. It's outrageous that a desktop app can access virtually anything on your system in a totally opaque way.
Desktop computing needs a massive push towards finely-grained privacy/security controls in a similar way to how browsers work.
Not a fan of Electron or native-ified apps in general but I usually have a very easy decision matrix: If it's one of my main productivity drivers (IDE, Browser, E-Mail, Messenger, Note-taking app, whatever) it can be massive and I am willing to update it constantly. If it's a tiny tool that sometimes offers one functionality and otherwise sits in the tray: No, I don't want it to gobble up 200MB of RAM if you can quit…
Will add that where possible, I’ll use the PWA version instead of the Electron version now that Safari on macOS can install PWAs that launch independently from the browser itself (unlike Chrome and its numerous cousins which require the full browser to be open). This sidesteps some of the native access concerns that come with Electron versions and is easier on the battery than the Electron version or a Chrome tab.
Earlier quoted context omitted.
Quake 1 (about 100k lines of C) runs in the browser just fine: https://www.netquake.io/quake Yes, it's a 30 year old game but the typical CRUD web app doesn't have close to the complexity of quake. Good C++ code is significantly faster than JS, that's true, but JS is also much, much faster than you'd think.
That quake demo is surely running on the WASM runtime which isn't really related to JavaScript: https://en.m.wikipedia.org/wiki/WebAssembly
Earlier quoted context omitted.
> I've always wondered what kind of apps these are. The vast majority of web apps I use are all CRUD. I can't think of a single webapp or electron app I use which performs heavy computation. Figma Teams (the web version) Outlook (the web version) MS Word (the web version) MS Excel (the web version) Google Documents Google Sheets Google Earth (similarly the iCloud versions for Pages, Numbers, etc) Canva Lightroom (the…
Google Sheets is a big one. It really does seem like CRUD when compared ti Excel.
Earlier quoted context omitted.
Quake 1 (about 100k lines of C) runs in the browser just fine: https://www.netquake.io/quake Yes, it's a 30 year old game but the typical CRUD web app doesn't have close to the complexity of quake. Good C++ code is significantly faster than JS, that's true, but JS is also much, much faster than you'd think.
That quake demo is surely running on the WASM runtime which isn't really related to JavaScript: https://en.m.wikipedia.org/wiki/WebAssembly
Here's the Unreal engine demo from 10 years ago: https://www.youtube.com/watch?v=XsyogXtyU9o
> There are just too many levels, and JavaScrip is an interpreted language, not a compiled one, so by default, it will be orders of magnitude slower than an app written in Swift, Rust, or C++. JavaScript isn't as fast as C++ or Rust, but it's pretty fast. Around the speed of Java and Go in some cases, which are compiled. For a web app the speed of the language is rarely the bottleneck anyway, other than some exceptio…
That’s not to say that all code written in Rust or Swift is all AAA grade or anything, but to write those to the point of being able to publish a product that functions reasonably well, a deeper level of understanding is required which acts as something of a filter.
It would be interesting to see what would happen if all browsers added support for a sort of “JavaScript Next Gen” that were much more strict, sitting somewhere between TypeScript and Swift without the various escape hatches that TS currently has. My bet is that sites and web apps written with this would be on average of higher quality than their legacy JS counterparts.
> There are just too many levels, and JavaScrip is an interpreted language, not a compiled one, so by default, it will be orders of magnitude slower than an app written in Swift, Rust, or C++. JavaScript isn't as fast as C++ or Rust, but it's pretty fast. Around the speed of Java and Go in some cases, which are compiled. For a web app the speed of the language is rarely the bottleneck anyway, other than some exceptio…
> JavaScript isn't as fast as C++ or Rust, but it's pretty fast. Around the speed of Java and Go in some cases, which are compiled. Sorry, not even remotely close. I want to see some serious evidence. JS id as unoptimizable as can be, thanks to its hyper dynamic nature. And js developers without any clue about memory will happily allocate hundreds of thousands of unnecessary objects to save a line of code. Completely…
I have an app that has one pretty frequent cpu intensive call (it computes the lcs for diffing). I decided to benchmark a rust wasm bindgen implementation against the js one I was using and found that ironically enough, node did perform better than rust. To be fair to the rust version, I think the JS implementation was slightly better optimized. I then looked into parallelizing LCS, (which is possible) but bindgen and almost all node:rust ports don’t support multithreaded calls, I can think of a myriad of ways to overcome this but not in a browser context. At that point I gave up on worrying about porting to lower level languages for cpu intensive work because if you’re forced into a single threaded context the gains of a memory managed language are going to be trivial at best and add ipc overhead at worse.
The main culprit of poor JS performance in native contexts is almost always bridges and the serialization/deserialization that comes with them. Electron apps don’t really suffer from the bridge problem. While, I’d never claim that JS is as fast as GO or Java (objectively it isn’t), it’s seems equally naive to suggest that using memory managed languages without exploiting multicore is going to lead to significant performance gains in a native app or web app.
I think the real power of wasm is the power of virtualization, it won’t be performance unless web APIs decide to break the single thread paradigm.
Earlier quoted context omitted.
Where is this magical market that has an iPhone AND Android tablet? I would wager that ihat is a pretty rare user, and even rarer to be using the same native apps on both.
Leave tech world and look at what people have. Most iPhone users have Windows machines.