[HN Gopher] Show HN: Electrico - Electron Without Node and Chrome
___________________________________________________________________
Show HN: Electrico - Electron Without Node and Chrome
Author : thomastsch
Score : 183 points
Date : 2024-09-14 11:18 UTC (3 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| koito17 wrote:
| Looks 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 Tauri.
|
| For those who don't know: Tauri is a collection of Rust libraries
| that allow using an operating system's "native web view" (WRY)
| and a Rust backend for the process backing a web view (there is
| an IPC layer between JS and Rust). The overall result is that, on
| Mac OS and Windows, one can distribute native executables without
| needing to bundle either Node.js or Chromium. There is no startup
| cost of loading Node.js, since a native Rust binary is used. As
| for the web view itself, startup tends to be faster than
| Chromium, since the libraries for e.g. WebKit are usually pre-
| loaded by the OS itself. Tauri apps have near-instant startup
| time, and I've found it to be a joy to use. The only downside is
| that the backend must be written in Rust. Electrico seems to help
| soften the learning curve by providing JavaScript APIs mirroring
| that of Electron.
|
| Overall, nice project.
| DanielHB wrote:
| From my understanding the main difference between electron and
| other WebView Containers (besides built-in APIs) is that
| electron runs your nodejs code in the same process as your
| browser code.
|
| So there is no cross-process communication, true synchronous
| communication between browser and nodejs code, ability to
| communicate without copying memory and without serialization,
| etc. All these capabilities are essential if you do a lot of
| processing between the two sides. It is also why electron must
| bundle a browser (and its v8 engine) and can't rely on the OS
| browser like other solutions do (which might not be v8 or might
| be the wrong version of v8).
|
| From my understanding this is not the case of any other WebView
| wrappers tech (Tauri, Wails). Which makes them unsuitable for
| some kinds of applications (invoking a function cross-process
| is extremely slow).
|
| I am not sure how correct I am with these claims as I never did
| a lot of electron. If you have a deeper insight I am quite
| curious about the topic.
| koito17 wrote:
| 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
| renderer has no direct access to require or other Node.js
| APIs
|
| https://www.electronjs.org/docs/latest/tutorial/process-
| mode...
| notpushkin wrote:
| > Renderer processes can be spawned with a full Node.js
| environment for ease of development. Historically, this
| used to be the default, but this feature was disabled for
| security reasons.
|
| Makes sense.
| killcoder wrote:
| Renderers can access Node APIs via the 'node integration'
| setting or via a preload script.
| themoonisachees wrote:
| 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.
| baumschubser wrote:
| In a recent podcast, Daniel Thompson from Tauri talks about
| the perspective of having shared memory between the Webview
| and the backend in Tauri as well. However, it is pretty
| vague.
|
| See here, search for "Topic 12":
| https://syntax.fm/show/821/is-tauri-the-electron-
| killer/tran...
| cyanydeez wrote:
| You can used shared buffers in chrome so one could use
| webworkers for a lot of processing. However, we are still
| waiting for many Apis to be available in webworkers.
| DanielHB wrote:
| What you really want is to get a reference to those
| SharedArrayBuffers in the native code like you can do
| with WASM
| __jonas wrote:
| >From my understanding the main difference between electron
| and other WebView Containers (besides built-in APIs) is that
| electron runs your nodejs code in the same process as your
| browser code.
|
| That is not correct:
| https://www.electronjs.org/docs/latest/tutorial/process-
| mode...
|
| > So there is no cross-process communication, true
| synchronous communication between browser and nodejs code,
| ability to communicate without copying memory and without
| serialization, etc
|
| From the Electrton docs:
|
| > Arguments will be serialized with the Structured Clone
| Algorithm, just like window.postMessage, so prototype chains
| will not be included. Sending Functions, Promises, Symbols,
| WeakMaps, or WeakSets will throw an exception.
|
| (https://www.electronjs.org/docs/latest/api/ipc-
| renderer#ipcr...)
|
| But yes they do build pretty heavily on Chromium, so swapping
| it out for a system WebView would probably not be possible.
| killcoder wrote:
| Within a renderer you can access NodeJS APIs directly. The
| main process shouldn't be used for any significant
| computation, as it will block GPU paints and cross-process
| synchronisation.
|
| The other main difference is Electron bundles a known set
| of APIs, given the known Chromium version. There's such a
| huge variance of supported features across the embedded web
| views.
| cyanydeez wrote:
| Yes, this is the best benefit of elecrron: you dont have
| to trouble shoot 10s of OS webview versions and their
| ixremental suppory, especially with MacOS.
|
| But it is right that the ui for elwctron has to use a IPC
| layer to get a node backend running. However, chrome is
| moving a lot of things like FilesystemAPI into browsers
| so there may be a day were nodejs is dropped in favor of
| a sandboxed chromium.
| killcoder wrote:
| You don't need IPC, you can either use a preload script
| to expose particular Node APIs in a secure manner or set
| 'nodeIntegration' to 'true' to expose everything.
|
| Source: https://www.electronjs.org/docs/latest/api/struct
| ures/web-pr...
| DanielHB wrote:
| oh wow, I was very wrong, I don't know why I got this
| notion that electron shared the runtime environment between
| non-browser and browser code. Thanks for the clarification.
|
| I am pretty disappointed about this, it severely limits the
| usability of native code from inside the UI code and makes
| Electron much less attractive compared to Tauri, Wails or
| similar alternatives.
|
| Do you know if at least moving objects between the electron
| processes uses direct memory-copying and not some heavy-
| handed serialization (Wails for example serializes to
| JSON). The links you pointed out don't mention that.
| killcoder wrote:
| You were correct. Electron lets you expose specific
| NodeJS APIs via the preload script or everything via the
| 'nodeIntegration' setting:
|
| https://www.electronjs.org/docs/latest/api/structures/web
| -pr...
|
| Separately the IPC lets you do zero copy in some
| circumstances via Transferable objects such as
| ArrayBuffers. Structured cloning is efficient but not
| zero copy, and json serialisation shouldn't be used
| (since structured cloning is easily available).
| __jonas wrote:
| Thanks for adding this context! Guess I was mislead by
| the Electron documentation talking about multiple
| processes and IPC, appreciate the clarification!
| cyanydeez wrote:
| Isnt another downside that the javascript in the OS web view
| could be different and lead to having to support a significant
| number of different webview versions. If you ship chrome with
| your app, you get to choose the conformance.
|
| This seems very overlooked in your evaluation.
| pipe01 wrote:
| Yes, but imo it's not a huge deal as we are used to this with
| regular websites
| Sammi wrote:
| It most certainly is a huge deal to handle all the browser
| differences with regular websites.
|
| A big reason people choose Electron is so they don't have
| to deal with all these differences.
| wruza wrote:
| _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.
| Retr0id wrote:
| It might be a minor compatibility pain, but I don't think
| it'd be any worse than developing for the web in general.
| Sammi wrote:
| 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.
| creshal wrote:
| > they are on a specific modern version of Chrome.
|
| For some value of "modern", usually "horrifyingly
| outdated".
| afavour wrote:
| Not really. MacOS's webview is kept relatively up to date
| with whatever version of Safari is current when the OS is
| released. Webview2 on Windows receives regular updates via
| Windows Update.
|
| You encounter the exact same compatibility issues you would
| on the web, with a somewhat slower uptake to new versions.
| Not ideal but entirely manageable.
|
| > why would one want to use it
|
| Primarily because (last I checked, anyway) any app using
| Electron has to bundle its own version of Chromium, which is
| massive. It also means each Electron-powered app is totally
| ignorant of the other, resulting in a lot of duplication and
| unnecessary memory usage. When you use the system webview you
| have minimal bulk and resources can be shared, as if they're
| multiple tabs in one browser rather than each one being its
| own browser.
| wruza wrote:
| Took note, thanks!
| WorldMaker wrote:
| At this point most operating systems are ahead of Electron on
| average, not behind it. Electron takes longer to bundle a new
| Chrome version than it should. Then it takes a while for
| applications to actually upgrade Electron versions because
| that includes the compatibility headaches of keeping up with
| all of Chrome changes, Node changes, and Electron API changes
| at the same time. Some apps are years behind on Electron
| today simply because they don't want the headache of
| rebuilding Node native dependencies or fixing Electron API
| breaks and think being on an old build of Chrome and the
| subsequent risk of unpatched security problems is an okay
| risk to take.
|
| There is still a long tail of versions you might encounter
| when using a (security supported OS), but for most Linux
| distros, macOS, and Windows the worst case in the long tail
| is now just 6 months behind. (You lose security support if
| you don't keep up with semiannual OS releases.) If you have
| reason such as a corporate overlord to also support LTS OSes
| the worst case is closer to 2 years depending on Unix distro.
| (Windows WebView2 remembers IE and still requires regular
| update cadence even on LTS Windows, so WebView2 on today's
| LTS Windows should still be closer to the 6 month mark than
| the 2 year mark if following Microsoft's LTS policies,
| staying within support, and not paying for more complicated
| LTS contracts.)
|
| It should be very easy with caniuse/MDN statistics to write
| web apps for any browser of the last six months. If you plan
| to support macOS you still need to support two (related like
| siblings) renderers as macOS wants you to use WebKit/Safari
| and everything else is Chromium in one way or another today,
| but testing on two browsers shouldn't be a showstopper for
| many (most?) apps. There are definitely Chrome-only APIs that
| might appeal to you in building an app, but at that point
| many of them you can polyfill with a native dependency (a
| Rust dependency in the Tauri world).
| derefr wrote:
| 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.
| ttfkam wrote:
| Tauri is indeed heading to mobile.
|
| https://v2.tauri.app/blog/tauri-mobile-alpha/
| NoahKAndrews wrote:
| On modern mainstream Android devices, the Webview is based
| on chromium and regularly updated through the play store
| troyvit wrote:
| > 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?
| ijidak wrote:
| Missed a great opportunity to call it Electron Neutrino (Neutrino
| for short)
| mirzap wrote:
| It's never too late to pivot.
| sgc wrote:
| Or in this case, it's never too late to spin.
| throwitaway1123 wrote:
| It might have been confusing since there's another project
| operating in this space called Neutralinojs.
| mkl wrote:
| > cross platform for linux, macos, linux, ios and android
|
| I like how Linux is so important it gets two mentions, but
| Windows is left out. Presumably that's a typo though?
| fredoliveira wrote:
| Should be, yes. Tauri supports windows, and this wraps it.
| v3ss0n wrote:
| Those 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 they are fast and
| snappy. Discord is one good example also vscode
| jemmyw wrote:
| 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.
| v3ss0n wrote:
| I used WebKit in both gtk and qt . QT team did good job by
| building qtwebengine that update regularly outside of toolkit
| release process.
| Klonoar wrote:
| 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...
| Deukhoofd wrote:
| Yeah, I tried Tauri for a bit, and this was the primary issue I
| quickly found as well. Generally you use these kinds of tools
| to be able to easily do cross-platform UI. With Tauri every
| single OS you target will use a different underlying web
| browser engine, which means you'll still be running into many
| platform specific issues.
|
| Especially webkitGTK is just a drama, it's barely able to do
| layout for basic tables in a performant manner.
|
| In my experience in the current implementation Tauri is not
| ready for production. I've seen some preliminary work by the
| Tauri devs to investigate if they could use some standardized
| webview engine, but that's still very far away.
| v3ss0n wrote:
| Only way to compete electron is by building a webtech
| compatible UI engine that is lighter weight, more secure,
| higher performance, and renders well.
|
| That is big engineering task and not something a small group
| of devs can do.
|
| Only thing that could comes close is building electron and
| chromium compatible api on top of Zed team's UI engine.
| abhinavk wrote:
| Zed team also being the creators of Electron should have
| been the best people for this. They themselves opted to
| write a new immediate mode UI library.
| v3ss0n wrote:
| Yeah,atom too back in atom, they tried really hard to
| improve speed of atom by rendering in GPU as texture but
| before that properly implemented MS took over.
| timeon wrote:
| > Discord is one good example also vscode
|
| Discord constantly downloads huge updates and vscode uses too
| much memory (not counting LSP) for text editor.
| v3ss0n wrote:
| Well as a user I appreciate a software that make improvements
| all the time. Discord add good features, why should I
| complain about a lot of updates?
|
| VSCode use as much memory as you add extensions. I agree it
| uses up memory but Jetbrain and Fleet performance is also as
| bad if not worse then vscode and they use alot more mem.
|
| If u want vscode as just text editor Just disable all the
| included default extensions.
| AbuAssar wrote:
| This should be merged into tauri, like how bun also supports
| nodejs api
| briandear wrote:
| I still don't understand why we're using any of these Electron-
| style "apps."
|
| Ship a web application, or write actual native apps. Electron and
| that flavor of "app" development is the worst of all worlds.
|
| Just like the JavaScript web frameworks have turned what should
| be small web applications into huge monsters -- Electron has made
| what should be relatively small, high performance applications
| into these bloated resource hogs.
|
| I get it, JavaScript developers want to be part of the fun and
| there is definitely a use case for tiny resource-constrained
| startups still changing product-market fit. But companies like
| Slack for instance -- worth billions of dollars and can't find a
| way to write a high performance desktop app in Swift for MacOS
| instead opting for Electron.
|
| Think of the climate! All that extra power required to run these
| resource hog Electron apps on tens of millions of computers isn't
| trivial, not to mention a neutered user experience that results
| from not taking advantage of actual native applications.
|
| JavaScript isn't the panacea people want it to be.
|
| Electron makes it easy for companies but it makes it rougher for
| the victims.
|
| And Tauri and all the others are simply different flavors of the
| same shit sandwich.
| adhamsalama wrote:
| The only thing I like about Electron apps is that they just
| work on Linux, otherwise not many companies would bother
| porting their apps to Linux.
|
| I think web apps/Electron apps may be a factor in reaching the
| year of the Linux desktop.
| squarefoot wrote:
| If Lazarus supported other languages beside Object Pascal,
| that would be the truly native multiplatform integrated
| development system the world is looking for.
| conradludgate wrote:
| For me, writing JS is not great, but using HTML and CSS is what
| just resonates for me when it comes to building front end
| applications. If I need some device privileges that a browser
| cannot grant me, then I will use a HTML/CSS based renderer for
| that app.
|
| Now, I have grand visions for an embedded servo renderer that
| can be driven using native compiles rust, not JS. But who knows
| if we will get that one day
| nicoburns wrote:
| As it happens, we are building pretty much that over at
| https://github.com/DioxusLabs/blitz
|
| There was also a recent HN discussion
| https://news.ycombinator.com/item?id=41221252
| lost_womble wrote:
| It's great that you mention the climate impact of Electron
| apps, because those bloated monsters truly are a huge problem;
| though I think you underestimate how much the Tauri team's
| focus has been on shrinking app size to alleviate the
| environmental impact made by the download of said huge Electron
| apps.
|
| One of the things that actually made me interested in Tauri in
| the first place was their 1.0 Release[0] which included
| information on just how much CO2 output would be saved by
| switching from Electron to a similar Tauri app (600Mb vs 3MB)
|
| Of course you're right that if, instead of using Web UI in the
| first place, companies went straight to native apps then
| there'd be even more savings to be made -- but there's trade
| offs to be made with regards to aligning OSs and reusing
| components and onboarding engineers and writing good cross-
| platform tests when working in native that just aren't there
| when working with a WebUI, and something like Tauri which has
| many of the upsides with fewer of the externalities of Electron
| should be applauded at least as a step in the right direction.
|
| [0]: https://tauri.app/blog/2022/06/19/tauri-1-0/#environment
| rmdashrfv wrote:
| I understand where this guy was coming from with the comment
| about Tauri being the same type of thing, but when you
| _really_ take a look at Tauri, it seems to really hold up.
| There are some Tauri apps that have performance that is
| easily on par with native.
|
| The only thing is that Tauri apps seem to be quite easy for
| the developer to botch and end up with performance problems.
| One of the worst performing apps I ever used in my life was a
| Tauri app.
| pzo wrote:
| Go to app store on your iPhone, swipe refresh and see how heavy
| all those native SwfitUI apps are and we are talking only about
| app updates. You will barely find app less than 100MB and few
| that are even 300MB+. Didn't check if they are also as heavy on
| desktop. So that's at least regarding app size on environment
| impact native apps at least using SwiftUI not making it better
| - I would say they make it even worse since javascript apps can
| just autoupdate non native part without downloading whole
| bundle (and I think this is what slack and discord doing for
| some updates). SwiftUI apps are also not as fast as UIKit apps
| not sure about memory performance.
|
| In practise I will take any JetBrains IDE or VSCode over native
| XCode IDE anytime - XCode is such a big heavy hog.
| danenania wrote:
| This does make sense from a "crafting great software"
| perspective.
|
| But building three separate codebases in comparatively niche
| GUI frameworks full of platform-specific quirks when you could
| achieve 95% of the quality with a single JS/TS codebase comes
| across pretty terribly as a business decision. It's hard to
| justify what is likely a 10x-ish cost multiplier with "it uses
| less RAM" or "the scrolling feels more natural". While large
| companies can afford it, the cost-benefit still doesn't look
| good to them.
| 5kyn3t wrote:
| Is 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 choice
| and ship just the small packages. Does this make sense?
| explodingcamera wrote:
| I guess that sounds like the normal web/progressive web
| apps/web archives (especially with the push to more platform
| APIs in browsers)? Also, Tauri uses the system's
| WebView2/Webkit runtime, so it essentially works like this
| already.
| wruza wrote:
| This doesn't work. Developers move on to a next version for
| reasons out of their control. Now a user has a version hell,
| just like c:\python{all, sorts, of, versions}, and probably a
| versioned file extension. Bundling tens of megabytes is not a
| problem for the last ten years. Having everything you need
| right in your backpack is a good thing for everyone.
|
| It could be feasible if software communities didn't tend to
| underimplement features and then solve them by intertwining all
| sorts of dependencies and their maintenance policies. For
| example, for as controlled thing as typescript, there are at
| least four popular ways to "just run" projects, all with
| different quirks and issues (tsc & node, ts-node, swc-node,
| tsx). Although it was obvious that people would want to run and
| watch .ts files based on tsconfig.json, without an explicit
| compilation step.
| danenania wrote:
| Sounds like Adobe Air. It was pretty nice as a development
| platform. Something similar for Electron is an interesting
| idea!
| wavemode wrote:
| That's genius! I propose we call this system of apps "the World
| Wide Web" and call the runtime you install, a "Web browser".
| WorldMaker wrote:
| It does sound a lot like what Progressive Web Apps (PWAs) are
| supposed to be. It's very close to how the original
| Manifest.json worked when given an html/js/css/assets list.
|
| Only a couple of browsers supported that version of
| Manifest.json. Chrome developers thought it was too much of an
| 80/20 solution and decided to get deep in the weeds of the 20%
| instead of delivering the 80% solution while they worked.
| That's what got us the way too low level and hard to reason
| with Service Worker APIs for PWAs. It's over-engineered for the
| 20% of use cases in a way that makes "easy" 80% so much harder
| than it ever should have been. Chrome developers still randomly
| promise the web that the "easy high level API" will arrive any
| day now, but looking at the mess that is Workbox (their team's
| supposed-to-be high level building block library for Service
| Worker PWA APIs) it still doesn't look like it will happen any
| time soon.
|
| It's more the shame because we briefly had a simple JSON
| manifest format for assets. That JSON format should have been
| easy to emulate in the Service Worker APIs if those APIs truly
| were meant to solve the problem, not just solving more
| interesting problems in a related space that a minority of use
| cases needed. Google doesn't currently have enough incentive to
| make PWAs easy to build, and as long as Chrome is the majority
| browser, Google is the major obstacle.
| vunderba wrote:
| 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.
| lucasyvas wrote:
| I'm honestly just waiting for someone to add Rust bindings for
| Electron (instead of gluing Node to C++ in the main process, and
| using WASM for the renderer process instead).
|
| Someone may ask why - simply to have options. Tauri is great but
| there are many users complaining (with justification) that
| relying on the platform webview sucks, especially on Linux.
|
| In general, there's no reason Electron can only have a Node API.
| fs0c13ty00 wrote:
| I like this, as the author of LRCGET (which is made with Tauri),
| I hate debugging something that works on Windows (Microsoft Edge
| WebView2) but doesn't work well or doesn't work at all on Linux
| (Webkit2gtk) or macOS.
|
| One of the example is audio playback. Chromium and in turn Edge
| WebView2 have great support, but make it work in Webkit2gtk is a
| big pain in the *s. I then decided to switch the audio playback
| feature to Rust side (using Kira and Symphonia) instead.
|
| Having Chromium bundled eliminates all the pain about
| inconsistency between webview engines, and using Rust means we
| don't have to pay for the NodeJS size in our app bundle (plus
| better performance).
|
| For Tauri, I think something like Servo will fit well as bundled
| browser engine. Hopefully some day it will happen.
| fithisux wrote:
| Is it compatible with Deno? Nice project.
___________________________________________________________________
(page generated 2024-09-17 23:01 UTC)