Another Chrome wrapper...
Deno Desktop
301–310 of 418 posts
Re: Deno Desktop
#302Earlier quoted context omitted.
I want to have both linux and mac users (but maybe also android, ios, windows). You clearly see the issue.
> You clearly see the issue I don’t. VLC is available everywhere, so your requirement is clearly not a problem. Jetbrains is available on all major desktop OS.
Well, getting a hardware-accelerated blank buffer onto a screen to render video content is hardly the epitome of graphical user interfaces. VLC has very few and basic UI elements.
Jetbrains is a better example, using Java with Swing which is not a common choice. As seen from my other comment, I do think this is a good direction, but it ain't any more native than Flutter or for what it's worth an Electron app, none of these are "what the OS provide". FYI Jetbrains has to do quite a few platform-specific tweaks to make them better citizens on each platform.
Re: Deno Desktop
#303Earlier quoted context omitted.
Depends on the region, no one where I work has an iPhone or a current Mac, so stuff gets tested on FF and Chrome, and Safari gets thoughts and prayers. We would test on Safari if it were simple, but alas.
Skipping testing on 15% of all devices to save $600? Sounds like a poor business decision.
We are a very small company, and have always had far more Firefox than Safari users. And though they get by via dominance, IE style bundling of the browser to the OS is toxic, so good riddance.
Re: Deno Desktop
#304> Bindings are not IPC. The Deno runtime and the rendering backend run as threads / processes inside the same address space (CEF) or coordinated process group (WebView). Calls go through in-process channels, and the backend dispatches them from its run loop. -- https://docs.deno.com/runtime/desktop/bindings/ I don't understand how the coordinated process group works. Doesn't that mean in this multi-process mode it mu…
this is what I wonder as well.
Re: Deno Desktop
#305How is this better than Electron?
These from the comparison table stick out to me:
- Can use "raw, system WebView, or bundled CEF" vs "bundled Chromium"
- The size can be smaller in the Raw/WebView cases.
- Built-in automatic differential updates
- Built-in cross-compilation (+the compilations just come built into Deno itself rather than as a 3rd party package).
And, of course, the same lists as one would generate when comparing the base Deno vs Node themselves.
Re: Deno Desktop
#306Earlier quoted context omitted.
I have nothing against java. But for some reason in my experience all the developers using it are low quality, and gave it the reputation it has.
I think this is a selection bias speaking rather than a reasonable reflection of what goes on in the Java world. Some insanely sophisticated and high quality technologies are written with Java. The problem is like with JS or PHP, it is ubiquitous in many settings. There are a lot of people who can use it because it was the default language taught in CS programs, many corporate settings for decades, or similar. It’s t…
When I started to use elastic search I found out that with some incorrect queries you could "poison" the process entirely and it would respond incorrectly to every single query from that moment on, until you killed it and restarted it.
They responded to my issue several years later. I had changed jobs and I couldn't care less any longer.
If that's your example of quality… well…
Re: Deno Desktop
#307> Bindings are not IPC. The Deno runtime and the rendering backend run as threads / processes inside the same address space (CEF) or coordinated process group (WebView). Calls go through in-process channels, and the backend dispatches them from its run loop. -- https://docs.deno.com/runtime/desktop/bindings/ I don't understand how the coordinated process group works. Doesn't that mean in this multi-process mode it mu…
My guess is that it's not using IPC on OS level, like D-Bus on Linux, but rather a supervisior process starts and orchestrates child processes as needed. And all these processes use a shared memory model.
Here's the CEF docs on processes: https://chromiumembedded.github.io/cef/general_usage.html#pr...
EDIT: ...and the CEF docs on IPC: https://chromiumembedded.github.io/cef/general_usage.html#in...
Re: Deno Desktop
#308I'm happy to see this I see that this provides CEF, Webview and Raw * backbends but it would be nice if there was also a launch in browser option (like WebUI has). To me that has the best tradeoffs if you want to avoid the mess that is webkitgtk but still not ship (and be in charge of updating) a chromium engine with your app. * https://docs.deno.com/runtime/desktop/backends/
> I'm happy to see this I see that this provides CEF, Webview and Raw They beat Tauri at their CEF support. Webviews are a mistake in most cases. They're too platform-specific, and certain Webviews (Safari/Webkit) are buggy as hell, making platform support a nightmare. (Linux, ironically, is even worse due to how underbaked webviews are on the major desktop Linuces - Tauri is barely functional on Linux.) Deno Desktop…
I think that my Sciter is better option when you need HTML/CSS/JS native application running on
Windows (XP and beyond), MacOS and Linuxes.
Sciter SDK [1] contains scapp[.exe] - standalone Sciter engine that can be attached to HTML/CSS/JS bundle making standalone (single exe file) and portable executable. https://quark.sciter.com/ tool allows to compile such apps.
Size of "hello world" is a size of scapp.exe binary + size of compressed HTML/CSS/JS bundle.
On Windows scapp.exe is of ~14 Mb. On Linux ~18 Mb.
Linux version at startup detects GTK4, Wayland or X11 and uses those as windowing backends.
On all platforms Sciter provides out of the box: HTML/CSS/JS runtime, libuv based Node.JS alike runtime, GPU accelerated rendering, WebGL 3D runtime, JS built-in persistence (NoSQL DB).
It does not have TS compiler built-in as Deno, but that TS-to-JS compiler is better to be outside anyway as it is used only once - at app loading.
Re: Deno Desktop
#309The overall feature seems really solid, but I'm impressed they couldn't reduce the average package size further from 40MB even when not using CEF. I guess that wasn't a huge focus when developing this feature? Tauri and Dioxus can easily hit less than 5MB for package sizes.
I find the feature matrix comparison to be extremely well done and the sections beneath explaining advantages and disadvantages to be some of the best docs I've read recently.
Re: Deno Desktop
#310I'm happy to see this I see that this provides CEF, Webview and Raw * backbends but it would be nice if there was also a launch in browser option (like WebUI has). To me that has the best tradeoffs if you want to avoid the mess that is webkitgtk but still not ship (and be in charge of updating) a chromium engine with your app. * https://docs.deno.com/runtime/desktop/backends/
Wouldn't that just be "Raw"? I.e. start a webserver and ask the system to open the URL. There is no "special stuff" to do in this case like avoid sockets in favor of IPC to a well known webview or package CEF and no real integration to make with dev tools etc after - it's just open socket and serve from prebuilt binary.
No. As I understand it, the Raw backed just gives you a Window with input handling and you have to embed something like Skia, WebGPU for the graphics. So basically you have make your widget library yourself.
Now you can just start a server with deno pretty easily and serve a website. But WebUI will actually also manage opening the browser window for you as well a make the communication between backend and frontend just like using a Webview or electron.