Jspaint.exe – JS Paint as a cross-platform native desktop app | Hacker News Reader

Jspaint.exe – JS Paint as a cross-platform native desktop app

github.com

41 pointskiyanwang28 comments

This isn’t a native desktop app. It’s running Chrome in the background (even downloading it if Chrome isn’t found).

This isn’t meant as a criticism against this project though. Just that “native desktop app” means something specific and that’s not what this is.

Welcome to the Newspeak world. Web is "native", hypervisor-less is "bare-metal", CGI hosted by a third party is "serverless". I feel like a fossilized museum curiosity.

> “native desktop app” means something specific

honest question - what does it mean? Is a Qt app "native"? Or does "native" just mean "any language other than javascript"?

Native has different meanings, depending on context. In this context, it means: the binary has been compiled for the platform and the code is executed natively, that is without a VM or interpreter. JS in browsers is commonly not considered native, while QML somehow is. Don't ask me why :)

So is chrome a native app?

By that definition, yes, but not what runs inside a Chrome tab. I could imagine that the settings, history, etc. is not implemented natively. Didn't look into the code though.

As a rule of thumb: If it is compiled for a specific target architecture, it's native code. If not, it's not and you need some other native code to run/interpret your non-native code.

To me "native desktop app" means "written for that particular platform", i.e. something that integrates well with that platform. And for GUI apps, also something that uses UI libraries provided by that platform.

So, a website, which on Mac uses a bunch of native UIKit text inputs, buttons, checkboxes and selects is native?

"Native" is generally something that runs on a machine directly, in some way.

I think of it like this: What does *my code* target?

For example, if it targets x86_64, it's native (at least on x86_64). If it targets cpython (the python interpreter), then it's not native. The fact that cpython is native is irrelevant. Same with this project - it targets the browser's JS engine, V8.

Hope that

P.S: I don't think downvoting without commenting is constructive.

By that definition, there are close to zero native applications out there. Just about the only code that truly targets a specific CPU architecture, is assembly code. Even C++ programs don't target a CPU architecture, they essentially target a C++ virtual machine. Much like the JVM, recent versions of the C++ language define their own concurrent memory model. It's the C++ memory model that the programmer much reason about, not that of the target CPU. (Again, the same thing goes with Java, and with C#/.Net.)

The build model isn't the whole story as to whether a GUI counts as native. We don't much care whether Electron uses a caching JavaScript JIT, when discussing whether Electron UIs should be called 'native'.

'Native GUI' is one of those imprecise/overloaded terms that can't really be given a single definition. It could be understood to mean written using the language and toolkit preferred by the target OS, or it could just mean uses the GUI toolkit preferred by the OS, or these days it might be understood to mean doesn't use web technologies. Using the latter definition, even a JavaFX program might count as 'native'.

I am guessing it means something that is non-cross-platform. Would JVM be considered native?

Native, as far as I understand, tends to mean it's designed to run on that specific platform i.e. not cross-platform. Anything that is cross-platform is by default, not native.

Native means using the host APIs. You can be cross platform and still use host APIs, albeit that's typically a compile time option. But the same is true with Electron et al because they compile an PE (Windows) or ELF (Linux), etc and that PE wouldn't run on Linux any more than the ELF would on Windows.

You can also have applications that some might describe as native but they don't use the host OS's graphical widgets (for example using GTK+ on Windows). I think that's acceptable if you're using other host APIs eg for sound, multi-threading, file system access, etc. It should be clear that in those instances it's a native application with non-native widgets. The main reason I'm happy to accept that edge case is because of my previous history in game development. But for desktop applications some are stricter.

Web applications are not regarded as "native" because they all run inside a virtual machine (the browser) whereas the browser would be a native application.

What this does is pretty much exactly the same as Electron except instead of bundling Chromium with the website, it starts a webserver and then forks an existing Chrome install to access that local webserver. Either way it's still a web application rather than native application. However the benefit with this model is you arguably get some memory savings by not having to run multiple instances of Chromium.

Isn't Flutter supposed to be the default GUI framework for Fuchsia? In that case the native GUI framework would be non-native.

Binary sizes all around ~ 20MB

For comparison, the original Win9x mspaint.exe is 300KB, and if you thought that wasn't a fair comparison because that still needs the OS libraries etc., you can strip down the entire OS that boots and runs it to <5MB:

http://web.archive.org/web/20090209050149/http://www.etek.ch...

They fit both Chrome and the app itself into 20MB? Must be a miracle.

Chrome is an additional download if not locally present...

It won't be long until we write C++ to compile to WASM to run on V8 to be packaged with 15 layers of indirection to eventually be distributed as a "cross-platform native desktop app". I'm telling you, we will eventually go full circle.

From the README.md

> I guess I'm just in shock. Usually creating a new cool thing on the internets takes me days and stress.

Good on you OP. You made something and put it out there. That's already different from the vast majority of us who mostly just consume. Well done, you did pretty good. GraderJS looks interesting too. :)

For those who didn't reach the end of the README.md, it seems to use an electron-alternative called grader, from the same author:

https://github.com/i5ik/graderjs

It runs server and downloads Chrome (if not available already) and starts it in app mode.

This would make things a lot simpler, but that lack off app icon makes it really hard to consider.

It is either cross-platform or native. Can't have both.

Cosmopolitan?

wxWidgets would like a word.

Or Qt.

AFAIK Qt is only partly native. Unlike wxWidgets, Qt imitates system widgets, it doesn't use the system GUI libraries.

On KDE, Qt is native, but less so on Windows, even though it goes to great lengths to look like it.

Graderjs seems to be pretty nice idea. If you are already using Chrome, Graderjs apps weight around the same as a Chrome tab compared to Electron where each app will get its own Chromium instance.

This lead me to jspaint.app! I didn't know about it. It's awesome! Kids will like the GIF export too!

Ditto, hadn't heard about it before either: https://github.com/1j01/jspaint

Reply on news.ycombinator.com