91–100 of 100 posts
Earlier quoted context omitted.
> Native widgets feel primitive and dated to me. Compared to what? I honestly don't know what other people consider state of the art interfaces if native apps are excluded.
Compared to the web. I consider apps like Linear to be ones spearheading UI paradigms at the moment.
Earlier quoted context omitted.
> VMs like Python and Java require huge effort to embed. As a (backend) Java dev, I couldn't let that stand. And indeed I found out java now offers a tool called jlink with first class support, that will create a system native (e.g. .dmg on my macbook) executable with the JRE embedded. The javafx example project* I found could be downloaded, built and run from its native release all within less than 5 minutes. Mind y…
Let's please not justify bad/bloaty plugin/extension runtimes with "at least it's not as bad as Electron". A framework producing a Hello World application, even if it has a GUI, with a double- or triple-digit size in MB and memory consumption on the same order, is doing something very wrong.
Earlier quoted context omitted.
>ugly, and doesn't conform to native interface expectations These are not strictly a result of targeting browsers for desktop applications, it's strictly down to design decisions that have nothing to do with how its implemented. I've seen plenty of wonky desktop/native applications that took way too many liberties with design whimsy that end up being a worse user experience than any webpage. I also can't complain abo…
> These are not strictly a result of targeting browsers for desktop applications, it's strictly down to design decisions that have nothing to do with how its implemented. It's not "strictly" down to this; even if you want to implement interfaces that fit in with native ones, web browsers simply don't expose many native features via the DOM/CSS. It's a question of actual capabilities, not of this hypothetical design p…
In an application like VS Code, or anything built on Electron or other similar frameworks, the web browser actually can have access to anything and everything a desktop application has. Electron is a fusion of a Chromium web browser with Nodejs, so you can call Nodejs functions from the browser, and if you really need OS API access, you can also have C++ addons for Nodejs that can do the work and the browser interface can be used to call those functions.
The web browser is simply the user interface, it communicates with a nodejs back-end which can definitely also access OS level APIs if you really want it to.
So yes, the capabilities are there, you just didn't know about them because you think it's simply a web browser, when it's much more than that.
And I know for a fact that you're wrong, because I worked on a desktop application in 2006 that used Internet Explorer as the user interface (Windows was our target, for reasons), and it had a C++ "back end", which was used for burning DVDs (the first legal DVD burning application). The browser could call C++ functions that we chose to expose to the browser to do all sorts of OS-level things. There was nothing that the browser front-end couldn't access at the OS level if we chose to expose it to the front-end. So I know for a fact that you're wrong about your assumptions about desktop applications that use a web browser as the front end.
Earlier quoted context omitted.
> The DOM has two different APIs, a batch and a piecewise ones. The batch one is incredibly optimized in all the browsers, while the piecewise one usually do not receive any attention at all. What are you talking about?
I'm going to go out on a limb and guess that they mean that if you want to modify the DOM with JS, you cannot batch your updates into an atomic transaction; every modification is applied immediately. However, presumably there is something, somewhere, that can collect modifications and apply them concurrently, because this would be such an insanely obvious optimization to miss for non-JS-driven updates to the DOM (suc…
For example imagine we are trying to move one element to the location of another one. This code will be slow because the read of `leader.offsetTop` will need recalculate the layout to see if that write of `follower.style.left` changed the position of `leader`.
let x = leader.offsetLeft;
follower.style.left = `${x}px`;
let y = leader.offsetTop;
follower.style.top = `${y}px`;
let x = leader.offsetLeft;
let y = leader.offsetTop;
follower.style.left = `${x}px`;
follower.style.top = `${y}px`;
The assumption is that javascript is bad and that the solution is to not fix it. asm.js was another example.
asm.js was the opposite of an alternative to JavaScript: It was a performant JavaScript dialect used as a compilation target for various languages otherwise targeting emscripten. WASM is the spiritual successor to that, getting rid of the (in retrospect quite hilarious) "embedded backwards compatibility layer".
edit: for the record, I think having only one doc type (html) and only one scripting language (js) in the browser is a terrible idea.
I don't know what the other doc types and programming languages should be but performance alone seems like a poor idea. A compile target seems even worse. :)
Earlier quoted context omitted.
Let's please not justify bad/bloaty plugin/extension runtimes with "at least it's not as bad as Electron". A framework producing a Hello World application, even if it has a GUI, with a double- or triple-digit size in MB and memory consumption on the same order, is doing something very wrong.
The example in question is very much a "include-more-than-you-need-by-default" problem. So, bloat. Java lets you include only the parts of the JDK that you need for your app. These parts are called modules. Unfortunately, all modules MUST include the base module (java.base), which is ~22MB. And if you add a GUI (java.desktop), that's another ~13MB. And since the linked example uses Java FX, there is yet another layer…
Last time I checked, jlink tool refused to make use of those "automatic module" dependencies when creating an image.
Earlier quoted context omitted.
The example in question is very much a "include-more-than-you-need-by-default" problem. So, bloat. Java lets you include only the parts of the JDK that you need for your app. These parts are called modules. Unfortunately, all modules MUST include the base module (java.base), which is ~22MB. And if you add a GUI (java.desktop), that's another ~13MB. And since the linked example uses Java FX, there is yet another layer…
May I ask how do you solve the problem that almost none of the 3rd party libraries in Java ecosystem use modules? Last time I checked, jlink tool refused to make use of those "automatic module" dependencies when creating an image.
And your comment about `jlink` MIGHT be true if your application is nor modular/ does not use modules with a well-formed `module-info.java`. I haven't tried an automatic module in a long time. If your application is modular, everything happens as expected. I do this for all the builds for all of my projects. Last build from last night confirms that it still works, and works well.
Earlier quoted context omitted.
Let's please not justify bad/bloaty plugin/extension runtimes with "at least it's not as bad as Electron". A framework producing a Hello World application, even if it has a GUI, with a double- or triple-digit size in MB and memory consumption on the same order, is doing something very wrong.
With all due respect, that’s just a dumb conclusion. Optimizing for hello world is dumb - if the primary use case of a given framework is larger scale, than it is more than right with such a size.
Earlier quoted context omitted.
I have high hopes for wasm on the desktop for app plugins. Loading a whole binary DLL/SO is such a risk. VMs like Lua don't give you enough performance. VMs like Python and Java require huge effort to embed. Once the SIMD stuff is in, it may even have enough performance for music plugins. wasm codecs would be real cool too. Nobody likes having to build and install ffmpeg. `ffmpeg-4.0.wasm`... just imagine.
> VMs like Python and Java require huge effort to embed. As a (backend) Java dev, I couldn't let that stand. And indeed I found out java now offers a tool called jlink with first class support, that will create a system native (e.g. .dmg on my macbook) executable with the JRE embedded. The javafx example project* I found could be downloaded, built and run from its native release all within less than 5 minutes. Mind y…