Is it compatible with Deno? Nice project.
Show HN: Electrico – Electron Without Node and Chrome
61–70 of 78 posts
Re: Show HN: Electrico – Electron Without Node and Chrome
#62Earlier quoted context omitted.
It might be a minor compatibility pain, but I don't think it'd be any worse than developing for the web in general.
The alternative to Tauri isn't the web - it's Electron which has a specific Chrome version. One big reason people go for delivering their web apps through Electron is so they can guarantee that they are on a specific modern version of Chrome. This is something you lose with Tauri. You gain some tighter memory consumption, but you do trade one thing in for another.
> they are on a specific modern version of Chrome.
For some value of "modern", usually "horrifyingly outdated".
Re: Show HN: Electrico – Electron Without Node and Chrome
#63Looks like a thin wrapper around Tauri. The README doesn't do a good job at explaining why one should use this over Tauri itself. From what I understand, this project attempts to implement a subset of the Electron API so that the library can act as a "drop-in replacement" for simple enough Electron apps. If this understanding is correct, then I think Electrico has the potential to significantly boost adoption of Taur…
an operating system's "native web view" (WRY) Isn’t that just a randomly abandoned version of something of uncertain origin, on average? Why would one want use it? I guess to save distribution space. I don’t have a “top”-deps itch, but using an arbitrary webview sounds compatibility hell even to me.
The target you're thinking of with outdated OS webviews is probably Android. Tauri doesn't even support Android; it's a desktop framework.
On both Windows and macOS, the "OS webview" is just a framework binding to the OS-shipped browser (i.e. Edge, Safari); and both Edge and Safari get updated with pretty much every release of the OS (which, in turn, are kept up-to-date in a pretty pushy way these days by Microsoft and Apple.)
Also, in both of these cases, by relying on these OS webviews, you're "sharing" the renderer and other global context with the actual browser (if the user happens to use it), and with all other OS webviews on the machine — rather than each new app needing its own renderer and global context, wasting 1GB+ of memory per app and creating thousands of redundant files on disk for the app's own cache et al.
It's really a pure win vs. Electron for these cases.
On Linux, what you get depends on the distribution format. If distributed as a package, you get a dynamic binding to WebKitGtk — which requires the package manager to resolve and install this (and that might not work, if the distro doesn't ship that package.) If distributed as an .AppImage, you get a vendored-in copy of WebKitGtk — which is basically the same as what you get from Electron.
Re: Show HN: Electrico – Electron Without Node and Chrome
#64Earlier quoted context omitted.
In the case of Electron, there is a "main process" that is a Node.js process. This process has the capability to spawn "renderer processes", each browser window is a "renderer process". Through ipcMain and ipcRenderer, Node and Chromium have bidirectional comminication. I don't think renderer processes run Node. Per the documentation, [C]ode ran in renderer processes should behave according to web standards ... [T]he…
Renderers can access Node APIs via the ‘node integration’ setting or via a preload script.
Aren't these just IPCs disguised as normal function calls though? IIRC only the main node process does anything node, renderers can call "node functions" that really happen in the main process.
Re: Show HN: Electrico – Electron Without Node and Chrome
#65Is it possible to have some kind of electron/tauri/,.. based runtime, but without the actual app? The users would need to install this runtime only once. The apps would need to be installed separately. The apps could be just the plain html/js/css/assets maybe packed within a zip, with a dedicated extension. The runtime would take care of the installation. That way the devs could develop with their FE-stack of their c…
This is a pretty standard type of architecture, it's essentially how anything that runs on a virtual machine works. Back when visual basic was popular, it actually surprised me that Microsoft never ended up bundling the VBDLL files with the OS itself allowing developers to ship significantly smaller installation bundles.
Re: Show HN: Electrico – Electron Without Node and Chrome
#66Looks like a thin wrapper around Tauri. The README doesn't do a good job at explaining why one should use this over Tauri itself. From what I understand, this project attempts to implement a subset of the Electron API so that the library can act as a "drop-in replacement" for simple enough Electron apps. If this understanding is correct, then I think Electrico has the potential to significantly boost adoption of Taur…
an operating system's "native web view" (WRY) Isn’t that just a randomly abandoned version of something of uncertain origin, on average? Why would one want use it? I guess to save distribution space. I don’t have a “top”-deps itch, but using an arbitrary webview sounds compatibility hell even to me.
> I guess to save distribution space.
Personally I'd agree with this. I'd also include saving the RAM of loading an independent version of Chrome for every electron app would be nice. Last, I never understood what version of chrome gets bundled with these electron apps. Is it more or less secure than WRY?
Re: Show HN: Electrico – Electron Without Node and Chrome
#67Earlier quoted context omitted.
an operating system's "native web view" (WRY) Isn’t that just a randomly abandoned version of something of uncertain origin, on average? Why would one want use it? I guess to save distribution space. I don’t have a “top”-deps itch, but using an arbitrary webview sounds compatibility hell even to me.
The target you're thinking of with outdated OS webviews is probably Android. Tauri doesn't even support Android; it's a desktop framework. On both Windows and macOS, the "OS webview" is just a framework binding to the OS-shipped browser (i.e. Edge, Safari); and both Edge and Safari get updated with pretty much every release of the OS (which, in turn, are kept up-to-date in a pretty pushy way these days by Microsoft a…
Tauri is indeed heading to mobile.
Re: Show HN: Electrico – Electron Without Node and Chrome
#68Those projects in general have Alot of problem, AND this is a wrapper on top of them. >Wry also needs WebKitGTK for WebView. WebKit have a lot more security problems and compatibility issues and are not as updated as chromium based, electron. There's nothing wrong about chromium based engines like electron. They are just a little bigger for download a little slow to start but that's it. If your code is well developed…
WebKitGTK has some really bad performance issues. I've written an app using Tauri and it works very well on Mac and Windows, and it does nothing particularly intensive. On Linux the performance is awful. The Tauri devs acknowledge this and seem to have plans to move off it, but moving to another solution (basically packaging chrome like electron does) is obviously a lot of work.
WebkitGTK on Linux is arguably woefully unoptimized. I think people make the mistake of thinking "it's WebKit so it's fast" when it's not that simple.
e.g, it took Igalia getting involved to move more things to the GPU when other platforms more or less had that by default already.
https://blogs.igalia.com/carlosgc/2024/02/19/webkit-switchin...
Re: Show HN: Electrico – Electron Without Node and Chrome
#69Earlier quoted context omitted.
an operating system's "native web view" (WRY) Isn’t that just a randomly abandoned version of something of uncertain origin, on average? Why would one want use it? I guess to save distribution space. I don’t have a “top”-deps itch, but using an arbitrary webview sounds compatibility hell even to me.
The target you're thinking of with outdated OS webviews is probably Android. Tauri doesn't even support Android; it's a desktop framework. On both Windows and macOS, the "OS webview" is just a framework binding to the OS-shipped browser (i.e. Edge, Safari); and both Edge and Safari get updated with pretty much every release of the OS (which, in turn, are kept up-to-date in a pretty pushy way these days by Microsoft a…
On modern mainstream Android devices, the Webview is based on chromium and regularly updated through the play store
Re: Show HN: Electrico – Electron Without Node and Chrome
#70Earlier quoted context omitted.
The target you're thinking of with outdated OS webviews is probably Android. Tauri doesn't even support Android; it's a desktop framework. On both Windows and macOS, the "OS webview" is just a framework binding to the OS-shipped browser (i.e. Edge, Safari); and both Edge and Safari get updated with pretty much every release of the OS (which, in turn, are kept up-to-date in a pretty pushy way these days by Microsoft a…
On modern mainstream Android devices, the Webview is based on chromium and regularly updated through the play store
What do you qualify as a "modern mainstream Android device"?
I think the median Android device out there in the world today — just by sheer volume of them produced — is probably a "Welcome" phone with a MediaTek 6580 chipset and a faked-capacity SD card; i.e. hardware that couldn't possibly run any Android version made in the last six years.
(Such phones could in theory run Android Go... but they often don't, because these devices are often running non-Google-Play-Store AOSP derivatives — and there's no un-Googled version of Android Go.)