[HN Gopher] Tauri: An Electron alternative written in Rust
___________________________________________________________________
Tauri: An Electron alternative written in Rust
Author : metalwhale
Score : 607 points
Date : 2021-02-19 16:49 UTC (6 hours ago)
(HTM) web link (tauri.studio)
(TXT) w3m dump (tauri.studio)
| jmaygarden wrote:
| I started to build some internal tools (that utilize Rust
| libraries to interface with hardware) using Tauri last year. That
| effort ended after trying to cross-compile to aarch64 and hitting
| a ton of roadblocks. It looks like it is still an open issue. So,
| Raspberry Pi, for example, is not supported.
|
| https://github.com/tauri-apps/tauri/issues/941
| pwdisswordfish0 wrote:
| What part does node.js play in this?
| Sephr wrote:
| I'd rather have development resumed on Carlo. You can re-use the
| existing Chrome install on a user's device without having to rely
| on a system-provided WebView.
| CivBase wrote:
| What if I don't have Chrome installed?
| Sephr wrote:
| Then Carlo could auto-install it, and it wouldn't have to be
| a unique installation just for one app.
| soheil wrote:
| Why can't there be a docker-like Electron running a base version
| of Chromium with additional layers for other versions support for
| different apps on top of it? This would both save more resources
| and lower each app's bundle size significantly.
| keskadale wrote:
| Question: Why do we need Electron alternatives? Why do we need to
| develop applications that need a bundled browser to run? Why
| can't we just use GTK/Qt?
| ketzo wrote:
| There is a lot of effort currently being put into creating web
| applications. It would be nice if we could use the fruits of
| that labor on desktop and mobile applications.
|
| That's how I understand it, anyway.
| eivarv wrote:
| It would also be nice if people understood and really
| appreciated the trade-offs of doing so - i.e. hogging
| resources, killing batteries, potentially wrecking the end
| users' experience and ability to multitask efficiently, etc.
| y2bd wrote:
| The two main reasons I've always heard against QT in particular
| are
|
| 1. Non C++ devs don't want to write C++/participate in the C++
| ecosystem at all. While there are plenty of QT binding
| libraries for other languages, they seem to be of varying and
| unpredictable quality.
|
| 2. QT has potentially difficult licensing:
| https://www.qt.io/licensing/
|
| Disclaimer: I've never used QT.
| azangru wrote:
| Will PWAs make Electron obsolete?
| yannoninator wrote:
| Do PWA's support notifications?
|
| If not, then no.
| Ashanmaril wrote:
| Web notifications do exist, they're horrible though
| Solid_Applaud wrote:
| Unlikely, because Electron is very useful in exposing system
| and hardware APIs.
| alooPotato wrote:
| For most apps - wouldn't PWA's be sufficient as implemented
| today. Presumably, they'll expose more and more hardware APIs
| over time?
| qbasic_forever wrote:
| Even basic things like reading and writing files from the
| filesystem are obnoxiously difficult in a pure browser or
| PWA environment. Storing state in general is full of
| enormous pitfalls and eccentricities, like 50mb limits for
| some browsers or just completely random total deletion of
| all app state at the browser's whim.
| alooPotato wrote:
| Seems like they are making a lot of progress on that
| front: https://web.dev/file-system-access/
| Solid_Applaud wrote:
| Fine, but these are proposals. We want something we can
| work with today, something that we have the power to hack
| on that will expose new systems we come up with to
| HTML/JS, and that is the niche that Electron-like systems
| fill really well.
| alooPotato wrote:
| Supported in Chrome and Edge today.
| themihai wrote:
| PWA is useless if you need to bypass CORS(i.e you can't develop
| a general rss reader for example). In practice PWAs are just a
| shortcut to a website. On electron you get
| closer to native apps in terms of network and OS access so I
| believe the PWA are and Electron are quite different platforms.
| qbasic_forever wrote:
| Electron gives you far, far more access to native libraries and
| hardware than PWAs will ever dream about. People are still
| arguing about how to expose USB devices, bluetooth, etc. in the
| browser for example. With an electron app you can just npm
| install a few native wrapper libs and go to town. It's great
| for moving clunky old native GUI apps (IDEs, etc.) to a more
| modern cross-platform codebase.
| pachico wrote:
| Each Electron application seems to think it's the only one
| running in a computer. It's the only way, I imagine, they think
| it's acceptable the amount of resources they need to run.
| hctaw wrote:
| As a developer shipping executables to MacOS, Windows, and
| Linux today this is the only assumption I can make. I cannot
| assume that dependencies exist or are the correct version, I
| can't assume the user knows that package managers exist or that
| the dependencies shipped by the package managers are correct, I
| can't assume anything exists on PATH or LD_LIBRARY_PATH, and I
| can't even assume that libc or libc++ on a system will work
| with the executable I compiled on mine.
|
| Meanwhile 16GB of memory is becoming common and 1TB SSDs cost
| less than $100. So taking up a little bit more space saves me
| time and money and reduces the cost to ship to my customers. Oh
| well.
| ymbeld wrote:
| 16GBs of memory isn't enough for me anymore.[1] Although that
| is mostly due to Intellij and the Web at large (my browser).
|
| [1]https://news.ycombinator.com/item?id=26120743
| dylan604 wrote:
| Bill Gates, is that you? This was Bill's excuse on why
| Microsoft does not try to optimize the code for their
| software. Just make the users buy new hardware for each of
| our sofware updates. Makes perfect sense. /s
| hctaw wrote:
| I've never had a customer report performance issues
| relating to memory usage or a market analysis that
| suggested we should improve memory size or disk space used
| in the binaries we ship.
|
| What I have gotten are expensive bills for network
| bandwidth and cloud platforms when backends are too chunky
| or download sizes too large.
|
| Which of the two do you suggest we optimize for, the one
| that costs money and gets complaints, or the thing people
| argue about on HN and Reddit but mysteriously never
| materialized in reports?
| imhoguy wrote:
| I think it has changed since Moore's law pretty much
| stalled on single core. Windows 10 runs fine on old Core 2
| Duo with 4GB RAM and SSD.
| jlokier wrote:
| > Meanwhile 16GB of memory
|
| Oh if only that was enough. My Safari is currently using
| 25.33GB1 and and it regularly goes over 30.
|
| > 1TB SSDs cost less than $100
|
| Ah, if only it was that easy.
|
| 1 (According to iStat Menus; it's harder to see in Activity
| Monitor due to the separate processes.)
| hctaw wrote:
| you can't buy an M1 mac with more than 16GB of memory so it
| seems like you have bigger problems
| jlokier wrote:
| My Mac isn't an M1, but it does only have 16GB of RAM.
| Yes, it goes into swap when Safari grows like that. It's
| mostly ok even with several GB of swap used, but can slow
| down.
|
| My solution is to restart Safari when it gets too bad, as
| it's obviously leaky.
|
| For a long time I used Firefox, was annoyed at how slow
| it would get on a busy browsing day, and didn't realise
| the memory consumption of Safari (also open) was
| overloading the poor machine. One day I saw the stats and
| realised what was happening. Now I open only one browser
| at a time, and everything is much nicer.
|
| If I decide to get another Mac (undecided), I'm holding
| out for an M1X or whatever with more RAM. 16GB isn't
| comfortable for my work any more. I'm not the kind of
| person who casually buys new expensive machines, so won't
| be getting the x86 32GB as an intermediate knowing I
| don't really need it, as I think it would be better to
| end up with both an x86 (which I already have) and an ARM
| going forward. I'm into code generation and portability,
| so that's better for me. And I like the idea of less fan
| noise!
| hctaw wrote:
| I was going to comment this elsewhere, but workstation
| class problems require workstation class solutions. If
| 16GB isn't sufficient for your work you should upgrade.
| Unfortunately Apple has stopped making competitive
| workstation laptops.
|
| As an example, the new MacBooks are not very competitive
| (for performance) with the latest XPS series from Dell.
| gameswithgo wrote:
| It isn't your fault that you have to do this, it is that our
| industry hasn't created enough quality, easy to use, cross
| platform gui libraries for popular languages, such that the
| only viable place to turn is to use a whole web browser.
| eivarv wrote:
| I don't think this is entirely true. Have you tried
| wxWidgets or even Qt?
|
| In my experience, this is more about resources and
| economics ("reuse existing code" vs. having to learn
| something new).
| qbasic_forever wrote:
| We've had about 60 years and multiple huge attempts at it,
| and IMHO HTML & CSS _are_ the easy to use cross-platform
| GUI platform. Nothing else stuck--flash, java swing, qt,
| etc. were all super capable and promising but failed to
| gain mass usage. HTML & CSS is the way. Nothing in
| existence has as much capability, developer usage and
| talent pool, accessibility and internationalization
| features, etc. A good GUI system is much more than just
| getting boxes and text on the screen.
| gameswithgo wrote:
| I don't think HTML+CSS is the way because of innate
| goodness of them, but because the web led to so many
| people being expert at it, and so many tools being built
| around it, including a cross platform browser or too that
| are top notch to render it all.
|
| At the very least a proper gui library could precompile
| all of that stuff so you aren't literally parsing HTML
| and CSS to render things, and HTML And CSS parsers don't
| need to be part of your running code. Nor a Javascript
| JIT, and runtime, etc.
| qbasic_forever wrote:
| I don't disagree either to be honest, but the reality is
| we live in a world where almost every business is
| dependent on a presence that shows up in web browsers.
| This puts enormous pressure and real dollars spent on
| making web browsers and the HTML & CSS ecosystem super
| fast, accessible, etc. Thousands of developers are
| trained every day how to make basic HTML & CSS
| experiences. Any UI system that throws all that away and
| tries to build up a similar ecosystem from scratch is
| going to be churning and churning for years.
|
| Don't forget browsers are pretty spectacular runtimes. V8
| and its JIT compiler is arguably one of the best runtimes
| of any language in the world. Sure the very first view of
| a page is going to do some parsing, etc. but as it runs
| it gets faster and faster with core functions and
| components compiled on the fly into platform machine
| code. The sandbox and security and encryption support in
| browsers is top notch and supremely battle-tested and
| hardened. With WASM now pretty mainstream we're starting
| to see entirely new frontend UIs coded in languages like
| C++, Go, Rust, etc. that are incredibly fast too. If you
| squint hard enough the browser is really no different
| than the JVM or .NET CLR these days--it just has 20 more
| years or so and an order of magnitude more developers
| working on improving it.
| hctaw wrote:
| I didn't say I was shipping GUI software ;)
| pachico wrote:
| I understand your point, however I still think it's
| unacceptable to have 1-1.5 GB of RAM consumed by simply two
| Electron applications running idle.
| [deleted]
| fabiospampinato wrote:
| That's not the baseline though, the baseline RAM
| consumption for an Electron app is about 100MB. If you have
| garbage code as input it doesn't matter which stack
| executes it, you'll have garbage performance output.
| alcover wrote:
| Even 100MB is crazy. I know RAM is cheap but the
| absurdity of that amount is beyond me.
| CivBase wrote:
| How many Electron applications do you honestly have
| running on your computer at any given time such that
| 100MB each is so concerning?
|
| Right now I'm running VS Code and PyCharm, each with an
| one open project and one open editor. PyCharm is eating
| 1.8 GB while VS Code is only eating 130 MB. Funny enough,
| I see people complain about VS Code being a resource-
| hungry Electron app all the time but I've never seen
| anyone gripe about the resource usage of JetBrainz IDEs.
|
| This isn't an excuse to Electron all the things, but
| browser-based GUIs do have their place.
| fabiospampinato wrote:
| It's a lot for sure, but it's not quite that simple:
|
| - First of all the amount of RAM consumed actually
| depends on how much free RAM you have, Electron thinking
| it's a browser boggles up some extra RAM "just in case",
| which is a tread-off that probably works better for
| actual browsers than the average Electron app.
|
| - Secondly while displaying "hello world" costs you
| ~100MB of RAM the RAM required as the app scales in
| complexity doesn't scale quite that fast, you may very
| well work on your app for a year and still need about
| ~100MB or RAM for it, you'll have to write very
| inefficient code (or keep a lot of data in memory) for it
| to require 1GB for JS' heap or something crazy like that.
|
| Still ~100MB is a lot for sure, I think a lot of it could
| be trimmed away if the developers really tried to lower
| memory usage significantly, like maybe a much more
| efficient "Electron Mini" could be made with some effort.
| Klonoar wrote:
| It's not crazy - go run a blank Cocoa app in Xcode and
| see how much memory it takes.
|
| People have unrealistic expectations on this.
| pupdogg wrote:
| Whenever I'm reminded of Electron, I'm thankful to have
| experienced WinAmp!
| sterlind wrote:
| ironic, because Electron apps should be easily skinnable. just
| put new CSS and images, maybe some new html, especially if
| there's some way of exposing e.g. the UI components so you can
| alter the layout and such.
| Ashanmaril wrote:
| I used to use an Electron wrapper for Google Play Music (may
| it rest in peace) and the developer of that did this. The
| default colour scheme for that product was a harsh orange,
| but the Electron client allowed you to override the CSS to
| change that base color, as well as switch between light/dark
| mode.
| yannoninator wrote:
| I think the desktop seriously needs a production, RAM and
| developer friendly breakthrough that isn't Electron.
|
| Tauri may be it, but the desktop SO needs this moment, I don't
| want to see 50 years on and Electron is still being used.
| eivarv wrote:
| For the GUI-parts (and more) there's always wxWidgets and Qt,
| at least.
| Neputys wrote:
| No there isn't (with resigned sobbing tone) there isn't.
| Everything GUI related on desktop is depressing prehistoric
| garbage that still takes ages to make and if god forbid you
| want something nice you might as well shoot your self.
| calibas wrote:
| There's React Native for Windows/macOS, though if you don't
| like Electron I doubt that's very appealing either.
|
| I've had some nice experiences using PyInstaller to create
| desktop apps.
| ZeroCool2u wrote:
| I'm really hoping Flutter or Kotlin Desktop have a breakthrough
| here soon. Personally, I'm rooting for Flutter, but I'll take
| what I can get.
| sam0x17 wrote:
| This is huge. I've been waiting for the equivalent of this to
| emerge in the crystal lang ecosystem for years (gotta get them to
| finish windows support first). I might dust off Rust again just
| because this exists.
| pookeh wrote:
| Why doesn't Electron debundle itself into the Runtime vs
| Application? Much like .Net Runtime. Electron can then be
| installed in a single spot in the system and all Electron apps
| pick it up from that spot. You can install bundle the Electron
| Runtime in the installer (200mb installer is no biggie for a
| desktop app) but you get all the benefits of consolidating RAM
| usage across.
| spijdar wrote:
| Well, the .Net runtime isn't exactly the most successful story
| from an end user perspective, where you occasionally run into
| weird problems with mismatched runtimes or missing runtimes or
| similar.
|
| Granted, it's not that often, but it feels like a lot of apps
| relying on it just ship their own copies of the runtime. Still
| saves resources if multiple apps use the same runtime version,
| but...
| neeleshs wrote:
| If the installer could do this instead..
|
| Check if the app is supported by an existing runtime, if not
| download it and make it available globally, otherwise use the
| current runtime and download only the app
| rtkwe wrote:
| It's a simpler experience to just dl the app and install it
| when it's bundled and less chance of something odd breaking
| your app for your users. Unbundled you wind up with either a
| Java situation where you have to get your users to install a
| particular runtime because you built with a particular one or a
| MS runtime where every app comes bundled with it's own copy to
| make sure you have the right one so there's not that big of a
| savings.
| edflsafoiewq wrote:
| It already is. For example, on Arch Linux, Electron is packaged
| as a separate binary and the eg. VS Code binary is just a shell
| script that points electron to the right entrypoint
| #!/bin/bash ELECTRON_RUN_AS_NODE=1 exec electron9
| /usr/lib/code/out/cli.js /usr/lib/code/code.js "$@"
|
| But most Electron apps prefer to bundle the whole runtime with
| their app.
| ziftface wrote:
| That's an interesting point, especially since V8 is already
| used for running multiple applications that need to be
| sandboxed from each other. It would probably be a big effort
| though, and to get any real benefit from it, applications would
| actually have to start switching to a different fork of
| electron. But I often have multiple electron applications
| running at once so this would be pretty nice.
| mhaberl wrote:
| Argument against debundling is that runtime update could break
| your app in some way.
|
| Sure, there are apps that get updated regularly, but not of all
| of them are like that, for example some company could implement
| some internal tool that doesnt have to get updated for years
| and runtime updates would present a risk with no benefit.
| hundchenkatze wrote:
| previous discussion from 7 months ago:
| https://news.ycombinator.com/item?id=23769424
|
| Looks like they're making good progress!
| twarge wrote:
| Downloaded the demo app for macOS; feels like an alien UI even
| though effort was clearly made to use system widgets. On the
| positive side, the app is only 4 MB and consumes 50 MB at
| runtime, so at least they've succeeded in that important aspect.
| kall wrote:
| I think most companies that already decided on the electron UX
| vs dev effort tradeoff will happily trade user resources for a
| guaranteed, uniform browser version target. It makes a big
| difference in development and testing.
| ryandrake wrote:
| Yea, but as a user, it's disappointing, and kind of
| impossible for me to push back on this trend. I can avoid
| using these apps, but it's an impotent show of protest. It
| won't make a difference. User experience, native look and
| feel, and the user's RAM are all being sacrificed on the
| altar of More Comfortable Developer Experience.
| gameswithgo wrote:
| Its consuming more than that at runtime I believe, you just
| don't see it because its using webkit in another process? I
| recall some discussion along those lines.
| kumarkeshav wrote:
| hey twarge, can you please test our app and provide feedback.
| it would be really awesome if you provide some feedback. here
| is our app https://getorionapp.com
| vulcan01 wrote:
| If I'm not mistaken, this is just because the CSS styling isn't
| that good, right? Take Slack (which uses Electron) as an
| example: it looks almost the same on Windows and Mac, but it
| looks good -- because the styling (through CSS) is good.
| millstone wrote:
| You're talking about how the app looks, but GP was talking
| about how the app feels.
|
| Slack looks nice but feels quite broken. For example, its non
| native context menus are beautiful, but do not dismiss
| properly, do not support single-click selection, do not
| support spacebar to pick, do not support type-select...
|
| When I use Slack I am constantly frustrated that things don't
| work the way my other Mac apps work.
| MaxBarraclough wrote:
| Is CSS really the major factor in the memory usage of an
| Electron app?
| vulcan01 wrote:
| I wasn't responding to the memory usage portion of the GP's
| message, but rather to the alien feel.
| nklayman wrote:
| The demo app has very basic styling, it isn't designed to be
| pretty. Since a Webview with HTML/CSS/JS is used for the GUI,
| you can style your app however you want.
| Const-me wrote:
| If someone paid me to do something similar, I would probably be
| building on top of this: https://github.com/Const-me/Vrmac
|
| There're two hard problems there.
|
| One is how to render vector graphics and fonts. So far, only web
| browsers do that in a cross-platform way. Windows has it's
| Direct2D and DirectWrite, while Linux has nothing comparable,
| unfortunately.
|
| Another higher level one is how to build easy to use GUI library
| on top of that. Have not approached that one. I have a few ideas
| but did nothing so far to address them, lately I'm too busy with
| other projects.
| eivarv wrote:
| Why not just wrap/abstract the native platform APIs (like what
| wxWidgets does)?
| Const-me wrote:
| These native platform APIs don't use GPU much, or at all.
| That's true even on Windows where GPU support is better than
| anywhere else. wxWidgets wraps Win32 stuff, it does not use
| WPF (backed by DirectX 9.0c) nor UWP (backed by Direct3D 11+,
| Direct2D, and DirectWrite).
|
| Count of pixels in displays was improving way faster than RAM
| bandwidth or CPU performance. Currently, this does not matter
| much on desktops, matters somewhat on laptops, and critically
| important for many mobile and embedded platforms.
|
| When you want to render anything at all at native display
| resolution and refresh rate, GPU stuff is the only option
| that works well enough.
| netghost wrote:
| The "patterns" documentation seems like a good place to get
| oriented around the ways they suggest people use this Tauri:
|
| https://tauri.studio/en/docs/usage/patterns/about-patterns
| math0ne wrote:
| I love this feature roadmap!
| filereaper wrote:
| Will this at some point make Electron apps like Slack/VSCode less
| hungry and more resource efficient?
|
| My cpu fans spin up everytime Slack is open.
| qudat wrote:
| This never happens to me. I run slack in my browser as just
| another tab.
| Thaxll wrote:
| It's writen in Rust it must be good.
| happytoexplain wrote:
| I supposed you're being sarcastic. The realistic version of
| this is that we have experience and evidence that tells us that
| it has the _potential_ to be more performant.
| postalrat wrote:
| So does the assembly version I just started work on.
| neysofu wrote:
| Oh shoot! If only the industry realized sooner that
| everything ultimately compiles to Assembly and thus decades
| of PL research were utterly useless! We were wrong about
| this the whole time. How could we not realize? We better
| off rewrite everything in Assembly to squeeze out every
| clock cycle!
| ibraheemdev wrote:
| Are you disagreeing that Rust makes it easier to write
| performant software?
| IceWreck wrote:
| On the go side, there is Wails (https://wails.app/) which is
| pretty popular
| jszymborski wrote:
| I just love that they have different "patterns", which truly
| makes this a flexible platform.
|
| I'm personally a big fan of the "Lockdown" [0] pattern, which
| avoids spinning up a local server and has a far more conservative
| security model.
|
| [0] https://tauri.studio/en/docs/usage/patterns/lockdown
| grishka wrote:
| I only have one question. Was the name inspired by Stargate?
| nklayman wrote:
| It's actually inspired by the star system
| (https://en.wikipedia.org/wiki/T_Tauri_star).
| BrianOnHN wrote:
| I scrolled just for this.
| pspeter3 wrote:
| This was my first thought as well.
| soylentcola wrote:
| That's what I was wondering. I've watched a decent amount of it
| but my GF is the biggest fan I've ever met (so, naturally,
| that's what stuck out when I saw the article).
| maxk42 wrote:
| It's either that or a reference to the Tauri civilization that
| dwindled some 3,000 years ago in the Crimean peninsula. I'm
| leaning toward the former.
| f-word wrote:
| Does this let me bundle signed snapshots so random miscreants
| can't tamper with my app? I couldn't find it, and it's the one
| thing I'm desperately looking for in this kind of platforms
| hit8run wrote:
| I shipped a Mac app to the App Store using native web views via
| macgap in 2013 :) Idea is not new but still better than electron
| up until today.
| pi_el_59 wrote:
| i've also heard of this alternative
| https://www.outrunlabs.com/revery/
| pjmlp wrote:
| Without wanting to attack Tauri's author work in any way, for me,
| the only sensible alternative to Electron are native webviews and
| daemons/services talking to the user's installed browsers.
| dmix wrote:
| Isn't that what this is basically?
| tedunangst wrote:
| So if I install a Tauri app I can access it with Firefox?
| pjmlp wrote:
| Is it? I couldn't find it.
| tene wrote:
| https://tauri.studio/en/docs/getting-started/technical-
| detai...
|
| "The first generation user interface in Tauri apps
| leverages Cocoa/WebKit on macOS, gtk-webkit2 on Linux and
| Webkit via EdgeHTML / Chakra on Windows. Tauri leverages
| the MIT licensed work known as webview that has been
| incorporated into the officiall webview_rust bindings."
| CivBase wrote:
| From the roadmap:
|
| > Go, Nim, Python, C++ and other bindings are possible with the
| stable API.
|
| I think something like this might actually have a lot of
| potential, specifically because it's much easier to create
| bindings for other languages with Rust than with JavaScript.
|
| You're stuck with a NodeJS runtime to run an Electron app, even
| if you "compile" it. You could theoretically make bindings to
| another language, but you'd still be dependent on that NodeJS
| runtime. But this could theoretically be compiled to a relatively
| lightweight DLL and interfaced with using practically any
| language you want.
|
| The page logic would still need to be JavaScript, of course, but
| that's just the nature of webviews for now.
| OJFord wrote:
| Huh, funny seeing this here, started using it just a week or so
| ago, really like it so far.
|
| I'm writing my frontend in JavaScript with Svelte, and able to
| make impressively smooth RPCs to the Rust backend with Tauri's
| API. Really nice work.
|
| Edit: actually that's something quite important to add perhaps
| that the headline doesn't make completely clear - it's not merely
| 'written in' Rust, but like Electron gives you Rust (resp. Node)
| to use.
| mch82 wrote:
| > Today, Tauri uses Rust for the backend - but in the not too
| distant future, other backends like Go, Nim, Python, Csharp etc.
| will be possible. This is because we are maintaining the official
| Rust bindings to the webview organisation and plan to let you
| switch out the backend for your needs. Since our API can be
| implemented in any language with C interop, full compliance is
| only a PR away.
|
| Sounds promising. I'd love a web view front end for Python as an
| alternative to tkinter.
| cdata wrote:
| This project is cool, and it is cool to have alternatives to
| Electron for cases that call for something like Electron.
|
| Something that is also cool is that Rust runs really well on the
| web (via WASM), which opens the door to building projects
| primarily with Rust and deploying them to the web with a web
| front-end. It will not suit every case, but in some cases it
| might save you from asking users to download a separate app that
| bundles a web browser engine.
| brundolf wrote:
| Looks like it uses system webviews instead of bundling a copy of
| Chromium? This to me seems like the real headlining feature, but
| strangely I had to dig pretty deep to find it:
| https://tauri.studio/en/docs/getting-started/technical-detai...
|
| I kind of wonder why it took this long for someone to try this
| approach. It just makes a whole lot more sense on the surface.
|
| Interesting thing I just thought about: since users _don 't_ get
| to choose their system webview, I wonder if this has the
| potential to broaden browser diversity a little bit?
| mike_ivanov wrote:
| > why it took this long for someone to try this approach
|
| it didn't - there is already a few projects like that, with
| Neutralino being the most notable.
| hu3 wrote:
| > I kind of wonder why it took this long for someone to try
| this approach.
|
| Perhaps a similar approach to
| https://github.com/webview/webview ?
|
| "Tiny cross-platform webview library for C/C++/Golang. Uses
| WebKit (Gtk/Cocoa) and Edge (Windows)"
| flixic wrote:
| Yes, Tauri's documentation explicitly states that it uses
| this Webview project.
| hu3 wrote:
| That's great in the sense that the more solutions using
| that library, the more mature it gets.
| baxrob wrote:
| Tauri has effectively controlled the Webview project for
| the past year. See
| https://github.com/webview/webview/issues/305
| abeltensor wrote:
| tauri does use webview but its moving away from it in favor
| of a rust native solution called WRY.
| hu3 wrote:
| Interesting. So according to @baxrob, Tauri took over
| control of https://github.com/webview/webview project for
| the past year. And now I'm told they are moving away from
| it.
|
| I'm left wondering why take over a project if they're going
| to ditch it. For lack of a better term.
| nklayman wrote:
| We didn't take over control, rather we helped setup an
| independent org around webview and other related repos.
| At the time, the original author of webview expressed
| plans to work on it a lot. However, this didn't really
| happen. Webview is stuck with some nasty bugs and missing
| features, and none of the members of the Tauri team had
| enough C experience to fix it efficiently. Instead, we
| created our own pure Rust solution
| (https://github.com/tauri-apps/wry). We've already given
| it way more features than the original webview project,
| and it doesn't carry the bugs that plagued webview
| either. The next release of Tauri (about a month or so
| out) will use Wry, and will have features such as multi-
| window and fancy window styling (frameless, fullscreen,
| custom controls, etc...).
| dsizzle wrote:
| Revery is another similar project that is trying to be a
| lightweight alternative to Electron https://github.com/revery-
| ui/revery
| abeltensor wrote:
| No revery is native. It doesn't use a webview at all; just
| uses the skia engine; basically a flutter competitor.
| vlovich123 wrote:
| Well Windows is basically Chrome so your diversity will
| basically be Chrome & WebKit which is what you have anyway. And
| having all the fun of web development against multiple browsers
| with all the headaches of desktop distribution is kind of the
| worst of all worlds. It'll be interesting to see if this
| approach finds success (since it may cut down on the size of
| your binary) but it could easily get abandoned if any
| significant projects start using this as frontend devs create
| pressure to simplify the stack across platforms.
|
| On Linux it's going to pull in GTK which means a not great
| experience on KDE (even though KDE does have WebKit hooks like
| GTK does).
| brundolf wrote:
| > so your diversity will basically be Chrome & WebKit which
| is what you have anyway
|
| Right now many web apps can brush off doing QA in Safari (and
| Firefox for that matter). Most regular websites don't have
| issues, but most of those don't need any vendor-specific
| fixes in the first place. I've used multiple complex web apps
| that just break unceremoniously unless you're using Chrome.
|
| If web apps that are complex enough to warrant a desktop app
| are forced to support Safari, that lifts awareness for the
| entire web/JS ecosystem. That's a win, if it plays out that
| way.
|
| > having all the fun of web development against multiple
| browsers
|
| The difficulty here has gone sharply down since all major
| browsers are evergreen now (and IE is all-but-gone). Not to
| mention the availability of tooling like Babel.
| vlovich123 wrote:
| > Right now many web apps can brush off doing QA in Safari
| (and Firefox for that matter). Most regular websites don't
| have issues, but most of those don't need any vendor-
| specific fixes in the first place. I've used multiple
| complex web apps that just break unceremoniously unless
| you're using Chrome.
|
| There's billions of active iPhones out there & they ALL use
| WebKit for webviews as no other browser engine is allowed
| for iOS apps. MacOS desktop apps are a fraction of that
| number of users & web view apps are a fraction of that. I
| just I don't follow this reasoning unless you're saying
| that this might gain traction across developers who might
| go & fix the bugs. That might help WebKit (although
| questionable). It's never going to help Firefox which is
| the sole remaining engine that doesn't have a strategic
| play to try to encourage compatibility.
|
| > The difficulty here has gone sharply down since all major
| browsers are evergreen now (and IE is all-but-gone). Not to
| mention the availability of tooling like Babel.
|
| If that were actually true, would you be concerning
| yourself with getting devs to do more QA on Safari or
| Firefox?
|
| The truth is that it's still hard to write web apps cross-
| browser and will likely remain hard indefinitely as long as
| there are > 1 web engines. The point of the web was to make
| you OS agnostic (ironically recreating the same pattern in
| desktop development of 2 or 3 major engines as with 2 or 3
| major OSes) but with this tech you're combining both
| dealing with the browser-specific issues & OS-specific
| issues. Additionally, you're now not only having to
| maintain compatibility across 3 engines, but all the
| various versions popular versions of the OS distribution
| will have shipped. I really struggle to see the value of
| this approach if I'm concerned with shipping the app &
| lowering my development costs & increasing velocity to
| shipping useful features.
| the_duke wrote:
| > Well Windows is basically Chrome
|
| As far as I know that's not accurate and the default webview
| on Windows is still the old Edge based one, not Chromium.
|
| The plans here are somewhat unknown I think, but right now
| you have to force the user to download and install (or bundle
| an installer) for WebView2 or Edge beta channel if you don't
| want to support old Edge.
|
| Gtk-webkit is also quite different from Safari, you can't
| assume they are just the same.
| FuriouslyAdrift wrote:
| The latest WebView2 is based on Edge Chromium AFAIK.
| https://developer.microsoft.com/en-us/microsoft-
| edge/webview...
| unnouinceput wrote:
| Starting from 20h2 version Edge is based on Chromium. And I
| remember when that rolled out plenty of people were irked
| by Microsoft simply automatically installing it (the new
| Edge Canary) without asking for permission.
| ksec wrote:
| What we need is a subset of HTML features that are known to
| work across all major browser. From Firefox, Safari /WebKit on
| other MacOS, and Chrome.
|
| Or something that compiles to the compatible HTML code for
| those platform with 100% accuracy.
|
| Unless that happens, you are dealing with godzillion number of
| edge cases in hundreds of different System Browser.
|
| But even _if_ such language or subset of feature exist, it will
| still not be as good or as be limited compared what is possible
| on top of current Electron. Which means from a user
| perspective, the Dev is optimising for something they rarely
| cares about; download size. Given memory CPU and Memory usage
| to electron.
| eivarv wrote:
| What we need is a subset of HTML features that are known to
| work across all major browser. From Firefox, Safari /WebKit
| on other MacOS, and Chrome.
|
| What, you mean like standards? Web standards?
| the_duke wrote:
| A major benefit of Electron is that you can develop against a
| single browser and runtime version and don't have to deal with
| all the small but time consuming compatibility quirks.
|
| On Windows the default webview engine is still not the new
| Chromium but old Edge (WebView2 has to be installed
| separately), Safari has a fair amount of issues and gtk-webkit
| can be very quirky as well.
|
| This is not so significant if your app has a web version and
| you have to deal with it anyway , but thereare a fair amount of
| Electron only apps. Or even with a web version, the desktop app
| often has special features not present on the web.
|
| But webviews are as much a moving target as browsers and often
| behave differently from the regular browser version in a myriad
| of ways, so you need an even bigger testing matrix.
|
| Webviews are also hard to properly secure and don't provide the
| extensive APIs of Electron, which you often have to bake
| yourself in a wrapper written in, eg, Rust or C++.
|
| I say all this as someone who hates how resource hungry
| Electron apps are and groans each time about yet another one on
| my machine, but I understand why it is so popular.
| e_y_ wrote:
| I wonder if it would make sense for Tauri to support shipping
| a bundled webview engine for platforms where the native
| webview is outdated or otherwise problematic for your
| application? With the idea that you could eventually migrate
| to system webviews.
|
| That way, you're building with cross-platform in mind but
| still have the option to pick a stable target if you need it,
| compared to solutions like Electron where you don't have that
| choice.
| themihai wrote:
| >> I wonder if it would make sense for Tauri to support
| shipping a bundled webview engine for platforms where the
| native webview is outdated
|
| I guess you can ship an electron version for these
| platforms where native webview sucks. Chances are that once
| you do the electron app you start doubting the benefits of
| shipping a webview based app.
| lcnmrn wrote:
| An alternative to Electron should be built using Servo and
| Deno, both written in Rust.
| hawk_ wrote:
| any idea when windows webview will switch over to Chromium?
| 908B64B197 wrote:
| I have to post it here because it's on top: On Windows the
| new WebView is Chromium.
|
| https://developer.microsoft.com/en-us/microsoft-
| edge/webview...
|
| Old one is, of course, kept for compatibility reasons.
| the_duke wrote:
| Yes, but it is not installed by default. You have to
| install it separately, at least for now,which makes things
| a lot more complicated if you want your app to rely on it.
| encom wrote:
| I'm moderately certain that Chromium is installed by
| default on new installs of Windows now.
| pjmlp wrote:
| A major benefit of Electron to Google is the amount of FOSS
| developers helping to turn what is left of the Web into
| ChromeOS.
| ASalazarMX wrote:
| > A major benefit of Electron is that you can develop against
| a single browser version and don't have to deal with all the
| small but time consuming compatibility quirks.
|
| Somehow I doubt the ideal solution is to bundle a web browser
| with every app. Electron feels like a prototype that went out
| of control.
| brundolf wrote:
| Nearly every successful technology is a prototype that went
| out of control :)
|
| That doesn't mean we shouldn't try and improve on things
| given the opportunity, but it's not an indictment either
| babypuncher wrote:
| I think they're overstating the browser compatibility
| problem too. It was really bad 15 years ago, but today it
| is almost a non-issue. Between significantly improved
| standardization of web technologies, and new tricks like
| polyfills, I think it has become pretty uncommon for apps
| to not just work on multiple browsers without any
| tinkering.
| ahepp wrote:
| "almost a non-issue" doesn't sound very convincing to me.
|
| As someone who doesn't write GUIs often, I just don't
| want to have to worry about it at all. What's the cost of
| electron over webviews? 100mb hdd space? On the other
| side of the trade, never having to worry about cross
| platform concerns again? Not having to support or test on
| multiple platforms?
|
| Seems like a no brainer to me. But it's entirely
| possible, even _likely_ , that I'm putting too much faith
| in electron, or that there are better options I just
| don't know about.
| norman784 wrote:
| I really don't share your point of view, but I understand
| it, for me feels like we as developers are getting worse
| and worse with the time, we get every year more powerful
| machines but our software is getting worse every year,
| who cares about performance if is cheap to develop, maybe
| if our apps uses less resources it would have less impact
| in the environment (less energy consumption is better for
| everyone, except for the lazy developers).
|
| I really hate electron apps, for example you have teams,
| that is written in electron, in linux is somehow better
| than the web version but is just way worse than the
| windows/mac versions, in web you can view 2 cams, linux 4
| but in mac and windows you have more cams at the same
| time and also a lot of features that are missing in
| linux, so I don't see too much the benefits of electron
| here, just pure laziness of microsoft not willing to
| invest in a better cross platform app.
| saagarjha wrote:
| > I just don't want to have to worry about it at all
|
| And in doing so you're prioritizing your needs over all
| of your users'. I think it's fair to claim that a minor
| convenience to you, at the cost of inconvenience to all
| your users, might be something you may want to deal with.
| jlokier wrote:
| I use Chrome, Safari and Firefox on a Mac.
|
| In my experience, unfortunately it isn't true that apps
| work with very high reliability. This is why I use
| multiple browsers. I don't want to use Chrome, and I
| encounter new websites with functionality that don't work
| properly in Safari or Firefox quite regularly. Some of
| this is even quite basic functionality.
|
| From things like shopping carts where the final payment
| button doesn't work in Firefox (nothing happens), to
| video conferencing that sort-of works in Safari but then
| the audio breaks while it is reliable in Chrome.
|
| Even GitHub doesn't render properly in Safari
| occasionally (the page is full of weird size text and
| giant rectangles). But that's almost certainly a Safari
| bug.
| babypuncher wrote:
| I think this is more a problem with developers working in
| Chrome and using Blink-specific features. I stopped
| having compatibility issues with my apps when I moved to
| Firefox years ago.
| jlokier wrote:
| Some of it is Blink-specific, but some of it is silly
| Javascript stuff. How else do you explain a shopping cart
| final payment button not working.
|
| I like development in Firefox too. When I was doing it
| intensively (just ~2 years ago), I found some of the CSS
| I was using behaved differently between Gecko, WebKit and
| Blink, though (and differently again in Android's pre-
| chrome browser), so I reconfirmed that I do need to test
| some things across all browsers. By differently, I don't
| mean prefixed browser-specific CSS (although there is
| that), I mean standardish things like table row height
| calculations showed up significantly differently, certain
| border highlights, and a number of WebKit rendering bugs
| that Gecko did not have. Key-event based text editing and
| wheel events are also significantly different, even more
| so when you include the common mobile browsers.
| saagarjha wrote:
| > How else do you explain a shopping cart final payment
| button not working.
|
| Given the megabytes of JavaScript on many websites, the
| chances that some of it depends on some random VM
| internal quirk is quite high.
| brundolf wrote:
| This is exactly the problem I was suggesting might be
| improved by an increase in browser diversity. 9/10 times,
| the issue isn't the browser itself, the issue is that the
| dev didn't bother to test and find the (handful of often
| small and easy to fix) bugs in other browsers. If they
| were forced to do QA - and ideally, had to adhere better
| to the actual standards to make their own jobs easier -
| you might have an easier time using those apps (and the
| libraries they depend on) in other browsers.
| brundolf wrote:
| > don't have to deal with all the small but time consuming
| compatibility quirks
|
| > Webviews are also a moving target so you need a big testing
| matrix
|
| I say this as a front-end web app dev who would most likely
| be affected by this kind of shift: it might be slightly less
| convenient, but I wholeheartedly think it's worth doing, on
| several levels.
|
| People built web apps 15 years ago in the dumpster-fire that
| was web standards at the time (and frankly, web tooling too).
| Browsers, even the good ones, didn't update themselves
| automatically. Most of the world was still on IE which was
| actively hostile to web standards for the sake of lock-in
| (and users weren't even on the same version of IE!). There
| was nothing like Babel to smooth over the rough edges, there
| were no polyfills. And even the standards that existed, when
| you got the opportunity to use them, mostly sucked.
|
| I think, given all that, we can deal with supporting recent-
| ish Chromium and the latest Safari, if it means bolstering
| web diversity and saving an order of magnitude in RAM and
| storage.
| jlokier wrote:
| I run three browsers on my desktop, because the number of
| things that don't work properly in anything except recent
| Chrome is enough that I keep encountering issues, I don't
| want to use Chrome for my regular browsing, and both Safari
| and Firefox have issues on some sites.
|
| On my tablet, a number of current websites don't run even
| on Chrome, because the tablet isn't particularly new, so it
| doesn't have current Chrome. It's still great hardware in
| perfect condition though, everything that does run on it is
| perfectly smooth and so on, and I still use it. Youtube in
| particular is fine. Literally the only reason to buy a new
| one would be to satisfy the software treadmill.
|
| My old phone didn't run Chrome (or Safari). It had Firefox.
| The only reason I switched to a newer phone, using Android,
| was because of sites that gradually didn't run well on
| Firefox any more. That was annoying, having to ditch a
| perfectly great phone and replace it with something better
| for the web but worse for other things.
|
| I have a Macbook Pro at home. I'm pretty happy with it,
| it's still a fine machine, I use it for work every day. It
| runs the latest Safari that's safe to run on it, but that's
| not the latest Safari, because it would have problems
| running the most recent OS.
|
| This brave new world of "I'm sure we'll be fine supporting
| recentish Chrome and latest Safari" is a world of
| exclusion. I don't like the memory usage of Electron, but I
| prefer it to applications that are a bit broken!
|
| Also, to be honest, I've been looking at memory usage.
| Electron uses much less than any of the three big browsers.
| You may know that Chrome famously starts a new process for
| each tab, and Safari does too. Firefox isn't far behind. As
| a result, the memory saved by running a new page in an
| already running browser compared with Electron isn't as
| much as it was long ago, back in the days when tabs shared
| memory. This is visible with Safari, as the website name
| shows up in the system utility for viewing process memory.
|
| I know, that feels wrong somehow, but it's true.
|
| Finally, when using a system WebView, will that save memory
| if it's opening a separate instance of the system's
| browser? It must be separate in some ways, if opening an
| application that uses a WebView doesn't open all your saved
| tabs from last time the browser was open. (And it's a
| horrible experience if opening an application does open all
| the other tabs.)
| encom wrote:
| One major benefit of running webapps in an actual browser
| like Firefox, instead of Electron, is that I can have
| uBlock and a handful of other defensive plugins, to
| prevent shady things happening behind my back.
| datalus wrote:
| Make no mistake, it's still a dumpster fire. Just maybe
| less raging.
| brundolf wrote:
| I worked on a highly complex web app for ~3 years, and we
| made a point to support Firefox, so whenever somebody had
| a Firefox-specific bug we wouldn't tell them to just use
| Chrome, we'd fix it. We only had 2-3 Firefox-specific
| issues in that entire time.
|
| I have heard that mobile safari can be a bit more unruly
| than the rest, though it isn't really relevant to the
| question at hand
| mrec wrote:
| Similar. Built a very complex app officially aimed at
| oldIE but made a point of ensuring it worked on other
| browsers too, largely on a skunkworks basis. A few years
| later (when we're no longer actively working on the app)
| everyone switched to Chrome and it Just Worked. Someone
| tried it on an iPad and it Just Worked (modulo some fat-
| finger challenges with small UI affordances).
|
| At the time, jQuery was a big help in this, especially in
| hiding the event model mess. Things are a lot better now.
| Although I do wish we had a strict compatibility-checking
| layer that'd warn you if you used any feature of the web
| platform that wasn't supported by everything you wanted
| to support.
| morpheuskafka wrote:
| That's fine for someone who already keeps current with
| front-end stuff, but someone who is a desktop app developer
| is more likely to just go native than try to make a desktop
| app that tracks 3+ browser engines of wildly varying
| versions (luckily 7 is out of support now, but it still
| might be desired to support for some desktop apps in which
| case now you have IE to deal with). Electron gives the
| promise of total code re-use across platforms which is what
| makes web technologies more suitable for desktop apps.
| briandear wrote:
| > Electron gives the promise of total code re-use across
| platforms which is what makes web technologies more
| suitable for desktop apps.
|
| I am not sure what the point is of Electron: a shitty-
| resource hungry app that literally is a wrapped web-app.
| Instead of writing platform specific apps that leverage
| the power and capabilities of those platforms, we get a
| jack of all trades and master of none. Electron is a
| business decision, not an enlightened technical one.
|
| What value does electron add to the user? I would argue
| none. That Slack can't find the resources to write actual
| Swift for a Mac App is just amazing to me. Instead we are
| essentially interacting with a lowest-common-denominator
| web app. Is a chat app that hard to write natively? We'd
| get better performance, a smaller footprint, and a more
| polished, platform-specific product.
| ZephyrBlu wrote:
| > I am not sure what the point is of Electron: a shitty-
| resource hungry app that literally is a wrapped web-app
|
| The point is that its effectively a web app.
|
| > What value does electron add to the user?
|
| They have a desktop app faster than if it was being built
| natively.
| encom wrote:
| Electron exists because there's a horde of developers
| whose only tool is a JavaScript hammer, so every problem
| looks like a nail. That's how you end up rewriting `dd`
| for Chrome[p].
|
| p: https://www.balena.io/etcher/
| cjohansson wrote:
| Electron should be banned for the environments sake if
| the other reasons doesn't persuade, it's inefficient
| computation to energy ratio using Electron apps, when
| there is a lot of users like with VSCode or Slack it
| probably affects the global climate in a negative way
| danudey wrote:
| Also: a lot of our "Electron" apps are essentially Electron
| frontends to the existing web frontend.
|
| For example, Slack-the-Electron-app and Slack-the-web-app
| are fundamentally identical, aside from likely some
| platform integration features and so on. That means that,
| likely, a lot of these Electron apps would already work in,
| for example, a Safari or Edge webview, since the web
| version has to anyway. I sincerely doubt that they're
| taking the time to strip out that compatibility, since the
| only reason to do so would be efficiency and if you're
| using Electron that's not a priority.
|
| IOW, for many applications, there's a near-100% chance that
| everything would function with little to no extra work, and
| for most of the rest it would likely take very little.
| Klonoar wrote:
| Slack originally _was_ platform specific webviews, and
| migrated to avoid issues like what is mentioned in this
| thread. One of the engineers who did it has even
| commented on HN to explain this.
| saagarjha wrote:
| This is probably the comment you're talking about:
| https://news.ycombinator.com/item?id=18763449. I was
| unconvinced then, and I am even more unconvinced now as I
| run a fully native Cocoa Slack client on my Mac that was
| written by one person reverse engineering APIs.
| macrael wrote:
| what's that client?
| saagarjha wrote:
| https://shrugs.app/.
| brundolf wrote:
| It also launched 8 years ago; the web has changed a lot
| since then. Edge wasn't even around until 2015, much less
| being used for webviews.
| Klonoar wrote:
| This sounds like you didn't look up and read the comment
| in question. Problems with cross-platform webviews
| stopped being the HTML/CSS/JS layer long ago; it's
| integration, availability, and rate-of-updates that are
| common blockers.
|
| Call me when Microsoft actually ships WebView2 with the
| OS.
| efwfwef wrote:
| if you would link to that comment it would be helpful
| [deleted]
| [deleted]
| 908B64B197 wrote:
| > Most of the world was still on IE which was actively
| hostile to web standards for the sake of lock-in (and users
| weren't even on the same version of IE!)
|
| More like: A lot of corporate users mandated a specific
| version of IE and wouldn't allow anything else to be
| installed.
| brundolf wrote:
| Chrome didn't even exist until 2008. Firefox existed and
| had a foothold, but it was very much a minority. IE was
| >50% until 2010 and remained the single most popular
| browser until 2012: https://en.wikipedia.org/wiki/Usage_s
| hare_of_web_browsers#/m...
| ahepp wrote:
| what happened in 2018-07?
| mumblemumble wrote:
| _Some_ corporations did that. Most didn 't. The main
| reason IE dominated was that most people didn't care, and
| stuck with the default. The main reason old versions of
| browsers were more common than new ones was that self-
| updating browsers hadn't become a thing yet, and most
| people didn't care, and just stuck with the default. The
| reason most browsers stay up-to-date now is that modern
| browsers are all configured to self-update by default,
| and most people don't care, and stick with the default.
|
| I have never bought a prebuilt Windows PC, so this is
| pure speculation, but I am wildly guessing that the
| dominance of Chrome is because computers are now coming
| with Chrome preinstalled and configured as the default,
| and most people don't care, and just stick with the
| default.
| 908B64B197 wrote:
| > I have never bought a prebuilt Windows PC, so this is
| pure speculation, but I am wildly guessing that the
| dominance of Chrome is because computers are now coming
| with Chrome preinstalled and configured as the default
|
| I'm not aware of any Windows machines shipping with
| Chrome pre-installed. But as soon as you use any website
| that's owned by Google you get spammed with install links
| for Chrome.
| encom wrote:
| I remember there was a long period where everything would
| bundle Chrome. One wrong checkbox and your computer would
| be infested. Adobe Reader was one prominent example.
| brundolf wrote:
| My experience was that IE finally got bad enough (around
| version 8), and Chrome got good enough, that even
| "grandmothers" started having everyone telling them to
| use Chrome, and it was so incredibly superior that you
| didn't have to be technical to appreciate it.
|
| _Now_ the reason everyone uses it is because it 's
| psychologically the new "default", whether it is on the
| actual system or not. Everybody knows that's just what
| you do when you get a new computer: you go install
| Chrome. And the irony is that even now, with Edge being
| basically the same thing, most people don't bother to re-
| evaluate that default assumption that "the windows
| browser is bad". They just use Chrome.
| laggyluke wrote:
| > most people don't bother to re-evaluate that default
| assumption that "the windows browser is bad"
|
| That's one way to look at it.
|
| Another way is to say that Microsoft has lost customer's
| trust and now has to work extra hard to earn it back.
|
| IMO they've learned their lesson, at least for now, but
| it would also be great if others could learn from
| Microsoft's mistake too.
| nix0n wrote:
| > WebView2 has to be installed separately
|
| Many Windows installers package one or more Visual Studio
| Redistributable packages into the installer. Is that not
| possible for these installers?
| runarberg wrote:
| > don't have to deal with all the small but time consuming
| compatibility quirks.
|
| Good, then developers might start to develop against
| _standards_ instead of handpicked browsers. Or if they use a
| future (unstable) standard that is their own headache (as
| opposed to user's; which are subsequently in practice forced
| to use chromium derived browser).
|
| An app developed against a single browser (as opposed to the
| web standard) should be considered what it is, an ugly hack,
| and developers that do it should only do it for their own
| private apps never to be published until it is standard
| compliant.
| hobofan wrote:
| This is about desktop and not web development though. I
| agree that pages available on the web should be standard
| compliant and work with all browsers.
|
| On the desktop you are developing against a runtime that
| the developer of the app gets to choose, so why not choose
| one that has less potential for quirks?
| danudey wrote:
| Because then you'll get a more efficient app that people
| don't constantly complain about?
|
| Especially on macOS, where Chrome/Chromium have
| historically been extremely inefficient, swapping the
| Chromium engine for WebKit2 WebViews would mean battery,
| memory, and CPU savings which would absolutely be worth
| the effort IMHO.
| hobofan wrote:
| Apart from the install size which is still not optimal,
| it is very much possible to write an efficient Electron
| app, as evidenced by Discord and Element.
|
| That Slack, the poster child of bad Electron apps
| performs so badly must therefore have different reasons.
| Exactly the same way you can write websites in a way that
| is more or less efficient you can write Electron apps of
| varying degrees of efficiency.
| plorkyeran wrote:
| Discord is efficient now? I have to restart it on a
| regular basis because it starts using 5+ GB of ram.
| [deleted]
| modeless wrote:
| I question how major that benefit is. I think strict
| Electron-only apps are not really that common. All the ones I
| use have a web version.
| munificent wrote:
| _> Webviews are also a moving target so you need a big
| testing matrix._
|
| Even worse, an OS update _after_ you ship your app can
| spontaneously break it on end user 's machines without you
| knowing or being able to do anything about it.
|
| At least with the web, when new browser versions come out,
| you can fix your site since users essentially "install" it
| every time they refresh the page. But an installed app that
| runs on top of a spontaneously updated framework is the worst
| of both worlds.
| [deleted]
| snemvalts wrote:
| Need a docker for electron
| brundolf wrote:
| It's not hard to silently auto-update an Electron app's
| internals; I assume the same is true for Tauri
| timerol wrote:
| The issue would occur if the auto-updater itself broke as
| a result of an OS upgrade
| brundolf wrote:
| Seeing as the auto-updater wouldn't have anything to do
| with the webview, I don't see how that's any more likely
| to happen in this case than it would be in Electron, or
| any other desktop application for that matter
| albertzeyer wrote:
| But why would the system webview be less resource hungry? If
| it runs in an own process instance, the only memory you safe
| is (maybe) the executable code (i.e. maybe 100MB max).
|
| Or you would need some common runtime which is shared across
| the OS, and somehow use IPC to it. Then you can potentially
| save some more memory. But I don't think this exists. And I'm
| also not sure how much you really would save.
|
| The advantage of using the system webview is that you can
| update this component, in case there are any vulnerabilities
| or so.
| OskarS wrote:
| Dynamically loaded system libraries use shared memory. You
| can load it once for the entire system.
| albertzeyer wrote:
| That's what I mean by executable code. But that is only
| really minor (<100MB or so) compared to the remaining
| resource usage.
| OskarS wrote:
| Ah, sorry, I missed that in your comment.
| sophiebits wrote:
| They're not inherently more efficient (other than the
| reduced application size), but Safari and Edge are both
| more resource-efficient than Chrome.
| [deleted]
| jiofih wrote:
| It didn't take long, this approach was around years before
| Electron came in. But the reason Electron picked up is
| precisely the stable APIs with cross-platform compatibility
| that comes from bundling chromium. You won't get that here.
| morpheuskafka wrote:
| It will, but browser diversity is not what you want for an
| electron-style app. The whole point of Electron is that it's a
| browser you control--you set the site permissions, you control
| the version and updates, you know exactly what it supports.
| That's what makes longer-lasting, more native experiences
| possible with a low development cost.
| dfabulich wrote:
| People have been trying the WebView approach for years.
| (Projects include: Quark, Electrino, DeskGap, Revery, and
| Neutralino.)
|
| Historically, it worked terribly on Windows.
|
| On Windows, if you used the OS WebView, your Windows 7 users
| would be forced to use IE11 to run your app, even if they had a
| newer/better browser installed locally. On Windows 10, you'd
| get whatever random version of Edge was installed, or the new
| Chromium-based Edge.
|
| In 2021, we're in a new era for Windows WebViews, thanks to
| Microsoft shipping WebView2 at the end of 2020, which ensures
| that the OS-provided WebView will be a modern version of
| Chromium. https://docs.microsoft.com/en-us/microsoft-
| edge/webview2/ Tauri supports WebView2 and I bet it will work a
| lot better than historical approaches.
|
| Support is still pretty dicey on other platforms, though. macOS
| doesn't have anything like WebView2, so if you want to support
| a five-year-old version of macOS (which isn't _that_ old in
| desktop terms), you 'll be forced to support and test your app
| on a five-year-old version of Safari. (The user _might_ have
| upgraded to a two-year-old version of Safari, but they might
| not, if they prefer Firefox or Chrome, and that 's now _your_
| problem.)
|
| The easiest and best way to improve the user's experience on
| old OS versions is to provide your own copy of Chromium, like
| Electron does.
|
| At that point, if you've shipped an Electron app for macOS and
| Linux, maybe you just wanna ship an Electron app for Windows
| and call it a day?
|
| Having said that, if you can keep your OS-version support
| matrix tight, Tauri might work OK for you.
| CommonGuy wrote:
| We use the WebView approach for Kreya[1], though not with
| Tauri. We had some occassional issues with Chromium/Safari
| differences, but otherwise it works fine.
|
| We use WebView2 on Windows, Safari on macOS and WebKit2GTK on
| Linux. Not shipping a whole Chromium installation on each
| install and update reduces the installer and on-disk size a
| lot!
|
| [1] https://kreya.app
| dfabulich wrote:
| https://kreya.app/docs/getting-started
|
| I see issues here!
|
| > _Apple Silicon (M1) is not yet supported._
|
| And on Linux,
|
| > _you may install Kreya by downloading the tarball. Note
| that both libgtk-3 and libwebkit2gtk-4.0 dependencies are
| required. Install them manually if they aren 't present on
| your system._
|
| libwebkit2gtk is, itself, _an embedded browser_, 44MB
| installed size, plus dependencies.
|
| It's convenient that you can make Snapcraft install it for
| you, but that's not really different from making Snapcraft
| install Electron and running that.
| [deleted]
| lenkite wrote:
| People have already tried this approach.
| https://github.com/webview/webview https://github.com/yue/muban
| ..and several others too.
| mikewhy wrote:
| > I kind of wonder why it took this long for someone to try
| this approach. It just makes a whole lot more sense on the
| surface.
|
| As others have mentioned, this is not the first time someone
| has tried. As for why people might not go for it:
|
| - Electron is Chrome. Webview is: Cocoa/WebKit, gtk-webkit2,
| and Edge (or is that Edge and Edge/Chrome). Yes standards have
| progressed a ton but there's still inconsistencies and it's
| nice not having to worry about them.
|
| - Electron is JS, so your app is 100% in a single language. In
| Webview. With these alternatives you now have to use 2
| languages. Not the end of the world, but again, nice not having
| to deal with.
| pjmlp wrote:
| Which is exactly why everyone pushing for Electron apps has
| nothing worthy to say about Chrome market share.
| Brakenshire wrote:
| Pity they can't use Servo as the rendering engine, even if it
| only deals with a small subset of style/layout properties. That
| kind of parallel layout engine should make building fluid 60fps
| interfaces a lot easier.
| Maledictus wrote:
| Why can't they?
| afavour wrote:
| AFAIK there are no V8 <-> Servo bindings. So in theory (I
| don't know Servo well at all) you could render a static
| HTML document but you'd have no DOM JS APIs to work with.
| fabrice_d wrote:
| Servo uses SpiderMonkey as its JS engine, and supports
| some DOM apis.
| silon42 wrote:
| you probably wouldn't want it anyway. Using Servo only
| for rendering and using Rust for everything else would be
| preferable.
| nklayman wrote:
| Servo is quite large and extremely difficult to build from
| source. We've tried to make it work with Tauri but decided
| it's not worth it, at least for now.
| mdaniel wrote:
| Do you have more specifics, and/or have you advised them
| of the difficulties? It seems to use the same "mach"
| build process as does firefox, and I build FF developer
| edition regularly (not every day, but damn near):
| https://github.com/servo/servo#normal-build
|
| While investigating this, I have deep sympathies for
| whoever has to work with that taskcluster silliness
| because yikes that is some A++ grade obfuscation as
| compared to a .gitlab-ci.yml or .circleci or even the
| .travis.yml they migrated off of
| NetOpWibby wrote:
| This makes me feel better about abandoning my own plans
| to do the same.
| flanbiscuit wrote:
| > I kind of wonder why it took this long for someone to try
| this approach. It just makes a whole lot more sense on the
| surface.
|
| Like other replies have mentioned, it's not a new idea
|
| DeskGap uses the native OS Webviews.
| https://github.com/patr0nus/DeskGap/
|
| Electrino (4 years old) was an experiment where they forked
| Electron and removed Chromium to replace it with the native OS
| Web views. https://github.com/pojala/electrino
|
| Quark is a fork of Electrino:
| https://github.com/jscherer92/Quark
|
| There's also a way of building desktop GUIs using Deno, which
| uses Deno Webview, which is a binding for the same webview
| library that Tauri uses.
|
| https://denotutorials.net/making-desktop-gui-applications-us...
| https://github.com/webview/webview
| baxrob wrote:
| Also wxWidgets/wxWebView and pywebview
|
| https://docs.wxwidgets.org/trunk/classwx_web_view.html
|
| https://github.com/r0x0r/pywebview
| flohofwoe wrote:
| It's not a new idea, for instance
|
| https://github.com/webview/webview
|
| ...has a fairly long history. It's great for extremely small
| application packages (when I tinkered around with it on macOS a
| few years ago I brought it down to 26 kilobytes).
|
| The usual argument against the idea is that Electron gives you
| a fixed Chromium version to work against, while the system
| webviews are a moving target with different underlying browser
| engines.
| hinkley wrote:
| I think my best-case scenario would be an Electron replacement
| that is not so bloated and also keeps parts of Firefox well-
| funded and people looking at compatibility.
|
| Elevating a new stack is a good consolation prize.
| andai wrote:
| I heard about a similar project a few months ago but I can't
| recall the name. I think the downside is that each OS has its
| own idiosyncratic webview.
| dsizzle wrote:
| Revery? https://github.com/revery-ui/revery
| lilactown wrote:
| AFAIK Revery doesn't use webviews, it is based on Skia
| alpaca128 wrote:
| I recently discovered NeutralinoJS, but I haven't tried it
| yet.
| genezeta wrote:
| Neutralino, maybe?
|
| One significant difference regarding webviews is Neutralino
| on Windows is using an outdated WebControl (MSHTML/Trident
| based) and this one seems to be using at least WebView
| (EdgeHTML based) or even WebView2 (Edge-Chromium) if
| available, both of which are a major improvement.
| themihai wrote:
| >> I kind of wonder why it took this long for someone to try
| this approach. It just makes a whole lot more sense on the
| surface.
|
| I believe there are dozens of projects using Webview and market
| themselves as a lightweight "Electron". The development for
| these apps takes longer (as you need to test for different
| webview versions/vendors) and the end product is worse as some
| features are shimmed or you just choose to not support them due
| the effort required. Of course this depends by project.
| I've developed a media player and considered webview. Soon
| enough I've found the limitations of safari, ie webview and
| even firefox webview on audio/video codecs is a blocker. Next
| was indexeddb and some random performance issues. It didn't
| took long to realise that it's hard to compete with native apps
| using Electron but its even harder using different webview
| versions.
|
| I will consider webView again when WASM gets native DOM access
| and audio/video decoding becomes available (performance wise)
| in WASM.
| devwastaken wrote:
| Webviews don't work because they solve very different problems.
|
| System webviews will always have different features, break
| things, and are entirely uncontrollable by the software
| distributor. This means your software will not be resilient to
| the future.
|
| You cannot access the JS engine the same as you can V8 in most
| webviews. This means you can't interop with C libraries without
| some performance destroying hack like copying everything into
| the JS space through sockets.
|
| This also means something as simple as reading a file has to,
| again, cross the sandbox in an inefficient way. You'd have the
| browser, it's javascript engine, _and_ your own runtime in node
| or python or however too.
|
| Electron develops patches that make chromium more performant
| and feature ready for desktop.
|
| Electron conjoins the chromium and node v8 event loop to take
| advantage of libuv - again a performance improvement.
|
| The decision of webviews and electron is based on what you're
| trying to do. If it's simple html/JS that's pretty much self
| contained then sure.
| andrew_ wrote:
| It's been a minute since I attempted it on Windows, but
| transparency of borders and borderless windows with the
| webview on Windows was next to impossible. It's one of the
| reasons we used Electron. I'm curious to know if they've
| solved that, but can't find my mention of it.
| taejavu wrote:
| Is it easier to test than electron? Cypress doesn't support
| electron and that makes me sad
| exacube wrote:
| Does using the underlying platform's webview make things faster?
| What are the benefits to end users?
| dguaraglia wrote:
| It'll make applications smaller by not having to bundle a full
| copy of Chromium for each application. It _may_ make
| applications slightly faster if the webview is already loaded
| in memory, and it 'll probably save some RAM because
| applications would share some memory.
| swagonomixxx wrote:
| This kind of makes me think... is there room for a much more
| stripped down version of Chromium that is suitable for lower
| memory footprint? Or is this impossible?
|
| It looks like Tauri uses system webviews, which use a lot less
| memory, but the burden is then on the developer to make sure that
| they build essentially 3 (maybe more) UI's on platforms that
| might change under their feet. That's why the Electron approach
| is simpler - it trades of performance for uniformity of
| experience across the major platforms.
|
| But I'm wondering if it really has to be this way. Do modern
| browsers really need 2G of RAM in order to send and receive
| messages in a chat box (looking at you, Slack).
| slater wrote:
| Electrino, but looks abandoned:
|
| https://github.com/pojala/electrino
| swagonomixxx wrote:
| Wow, at least from the screenshot in the README, the binary
| size is much smaller. However I think that's just from the
| fact that they don't bundle the JavaScript engine and the
| rendering engine into their binary. You're right though,
| seems abandoned.
| munificent wrote:
| _> is there room for a much more stripped down version of
| Chromium that is suitable for lower memory footprint?_
|
| That's basically the history of Flutter. The initial goal was
| something like "Web: The Good Parts" and the results of that
| experiment led them to where they are now.
| ducktective wrote:
| I mean, where are they now? Promising or DoA? I fear touching
| it because of it being a Google project (killedbygoogle.com)
| chgibb wrote:
| We're pretty bought into Flutter. No cross platform toolkit
| is perfect but Flutter is miles ahead of everything else.
| For a not very scientific analysis: https://trends.google.c
| om/trends/explore?date=today%205-y&q=...
| nwienert wrote:
| It's definitely not miles ahead of just about anything.
|
| It has significant tradeoffs and fits some projects
| better than others.
|
| React Native has quite a few benefits over Flutter.
| Especially if building for the web, I'd actually say
| Flutter is _only_ usable now if you don't build your web
| app with it. Which in my cost benefit analysis makes it
| miles behind RN, but of course, that's why it depends.
| jonathanaird wrote:
| They're putting a lot of resources behind and it actually
| is thriving. They have a real financial interest as there's
| pretty thorough firebase support. It's also reviving their
| Dart language.
|
| As someone that's using it, it is improving very quickly.
| Web support is getting quite good.
| unnouinceput wrote:
| I wish Mozilla would do the same move as well. I remember in
| 2000's I had a Mozilla ActiveX that I could bundle in my
| applications and instant web browser without IE crap (back then
| was Mozilla vs IE only, Chrome was still in its infancy).
|
| Nowadays Mozilla it seems they don't even export the old
| ActiveX, let alone to have their own webview equivalent.
| vulcan01 wrote:
| > the burden is then on the developer to make sure that they
| build essentially 3 (maybe more) UI's on platforms that might
| change under their feet
|
| Is this really different from the current state of web
| development? Front-end developers have to test against Chrome,
| Firefox, and Safari, at a minimum. For apps that are basically
| installable websites (like Slack, which has a perfectly
| functional webapp) this doesn't seem like that far of a
| stretch.
| MattGaiser wrote:
| > Front-end developers have to test against Chrome, Firefox,
| and Safari, at a minimum.
|
| Do many companies actually do this though? I've only ever
| been with companies that test against Chrome. The one time at
| FF bug was found, that company told that client to switch to
| Chrome.
|
| I know there was a kerfuffle about Airbnb and Groupon only
| doing Chrome as well.
|
| https://www.reddit.com/r/AirBnB/comments/dv7v6n/customer_sup.
| ..
|
| https://thenextweb.com/dd/2017/11/28/please-build-
| websites-w...
|
| Maybe in theory all platforms are considered, but in practice
| many companies just do one and the others mostly just work.
| joshuacc wrote:
| Yes, absolutely. Every company that I've ever worked at had
| a list of officially supported browsers that included
| Chrome, FireFox, Safari and Edge/IE. QA engineers would
| make sure to rotate through various browsers while testing,
| and for crucial features would run through every scenario
| in every supported browser's oldest and newest supported
| versions.
| hinkley wrote:
| Pretty much the only reason to use Saucelabs is browser
| compatibility testing.
|
| We don't run everything through it, but we run karma to
| make sure the code runs and the right events fire. It is
| still possible to write code that runs everywhere but IE.
| calibas wrote:
| Most companies today use frameworks that have good cross-
| compatibility so it tends to just work. In my opinion
| though, a responsible web developer is going to test on
| multiple browsers at the very least.
| swagonomixxx wrote:
| In a previous company we had to do FF and Chrome. Not IE
| though, which was a big time saver. QA ran all their test
| cases on the latest stable of both FF and Chrome, and
| features would not be deployed to prod if they didn't work
| on both browsers.
| livre wrote:
| Not much different but enough to be dangerous. Older Windows
| use Trident, 10 still uses EdgeHTML, many people are stuck
| with old Androids that don't have up to date engines (not
| sure if Android is a target, wasn't easy to find in their
| website), and webviews have access to the system in ways a
| website doesn't (like reading files or using the camera
| without having to ask for permission or being allowed to
| issue requests to arbitrary domains).
| moron4hire wrote:
| But we know from web statistics that these are very few
| people and shrinking every year.
| Klonoar wrote:
| That is not how it works on Windows, as you have to ship
| either the Webview2 runtime or installer with your app -
| otherwise you're stuck with the old rendering engines.
|
| At which point, it's just easier to ship Electron.
| moron4hire wrote:
| Shipping Electron and bundling the WebView2 runtime are
| practically the same level of difficulty.
|
| Making an installer is not that hard, and you should have
| enough respect for your users' compute resources to go
| through the modicum of effort it takes.
| Klonoar wrote:
| >Making an installer is not that hard, and you should
| have enough respect for your users' compute resources to
| go through the modicum of effort it takes.
|
| No. As shown by the slew of other comments in this
| thread, it's not _just_ about getting the runtime to
| load. You still have other issues involved.
|
| You should have enough respect for your own time and
| money to ship the product and not open yourself up to a
| litany of cross-platform issues. Your job is not to fix
| OS vendors failing to get a common UI framework in place.
|
| Signed, someone who has literally dealt with cross-
| platform-webviews in a shipping product in the past six
| months, and who builds native Mac apps.
| nklayman wrote:
| Tauri's Bundler will automatically take care of shipping
| the Webview2 runtime, so there won't be any extra work
| required of you.
| dmix wrote:
| And in recent years this has gotten much easier. Cross
| browser support used to be a pain in the ass.
|
| Now most of the time changes aren't even needed. Besides
| maybe the odd Firefox or Safari thing.
| Kaze404 wrote:
| Funnily enough in my experience it's usually Chrome and
| Safari that do weird things, which as a Firefox user always
| gets me dinged on PR reviews :p
| kybernetikos wrote:
| Have you seen how Sciter.JS has been developing
| https://github.com/c-smile/sciter-js-sdk
|
| There are a few working examples, and they have dramatically
| lower memory footprint and are quicker to start than full fat
| browsers.
| hobofan wrote:
| It seems like Electron is decently optimizable for a lowish
| memory footprint. Both the Element and Discord desktop client
| run with consistently ~50MB RAM each.
| scambier wrote:
| Are you sure about that? Most of the time, Electron apps are
| split into multiple processes, and the task manager (by
| default) only shows the main one. Order your processes by
| name and I'd be surprised to see the total under 150MB.
| scaladev wrote:
| >~50MB RAM each
|
| You _are_ measuring the total RAM usage, right? Something
| like `free -m` right before starting the application, and
| then after it warms up?
|
| Every time I see these "electron is not heavy, it only uses X
| MBs of RAM", it turns out that the author looked at a single
| electron process (out of typically 5-10), and then only
| measured RSS, completely ignoring shared memory.
| kaslai wrote:
| Doesn't RSS include shared mappings? That's why metrics
| like PSS and USS were introduced.
|
| But that aside, yeah Discord is pretty heavy. My current
| instance which is only connected to a single server is
| eating 555 MB PSS, or 846MB RSS. Definitely not a
| lightweight at all.
| glen-ellen wrote:
| This is similar to what Plotly did with their Kaleido
| project[1] that generates static images of plotly.js
| visualizations. Instead of using Electron or Selenium, they
| recompiled Chromium, stripping away a bunch of the parts they
| didn't need. This resulted in a cross-platform build that is
| much lighter weight.
|
| > The goal of the Kaleido project is to make static image
| export of web-based visualization libraries as universally
| available and reliable as it is in matplotlib and ggplot2.
|
| > To accomplish this goal, Kaleido introduces a new approach.
| The core of Kaleido is a standalone C++ application that embeds
| the open-source Chromium browser as a library. This
| architecture allows Kaleido to communicate with the Chromium
| browser engine using the C++ API rather than requiring a local
| network connection. A thin Python wrapper runs the Kaleido C++
| application as a subprocess and communicates with it by writing
| image export requests to standard-in and retrieving results by
| reading from standard-out.
|
| > By compiling Chromium as a library, we have a degree of
| control over what is included in the Chromium build. In
| particular, on Linux we can build Chromium in headless mode
| which eliminates a large number of runtime dependencies,
| including the audio, video, GUI toolkit, screensaver, and X11
| dependencies mentioned above. The remaining dependencies can
| then be bundled with the library, making it possible to run
| Kaleido in minimal Linux environments with no additional
| dependencies required. In this way, Kaleido can be distributed
| as a self-contained library that plays a similar role to a
| matplotlib backend.
|
| 1. https://medium.com/plotly/introducing-kaleido-b03c4b7b1d81
| crazypython wrote:
| > 3 (maybe more) UI's on platforms
|
| Not really. Targeting the web platform and not aiming for
| perfect compatibility or looking the same isn't that hard.
| oscargrouch wrote:
| Not just that, it allows to ship with much more api's available
| to the user.
|
| That's why is not always the best approach to appeal to whats
| people are saying.
|
| Here on HN this was the #1 thing that people used to ask or
| complain for when the topic was electron.
|
| "They should just integrate with the system browser" was the
| common saying. But the the burden would be on the developer,who
| would not only be back to the hellish scenario of multiple
| browsers implementations but also having to deal with a very
| skinny SDK to work with.
|
| In the end of the day, the applications deployed on Electron
| will win, because they will allow developers to do much more
| and without the application breaking here and there because of
| the gimmicks of each platform.
|
| When hearing what people say, you must have in mind the kind of
| the crowd you are listening to. Here on HN for instance is
| mostly Apple users, mostly developer types, and that's the
| reason why they ask for the platform browser, after asking for
| the platform UI, because that's how apple platform users will
| tend to think.. and the memory thing is the fact that most here
| are developers.
|
| But that's far from being representative of the whole world of
| users. So, you might appeal to the particular crowd here on HN,
| but once you are out there "in the world" you will have a hard
| time facing contenders that are more resourceful than you, and
| the worse of all, is that it is by design. You cornered
| yourself into it because you forgot you are in a bubble..
| k__ wrote:
| Doesn't seem like a big improvement when they still use web tech.
|
| I'm all for web tech, but that's what makes Electron no better
| than a browser.
|
| Revery seems like a much better solution.
| themihai wrote:
| I think a better electron would be an Electron that you can build
| only with the features you use(i.e I don't use websql, I don't
| need CORS, web notifications, nfc, bluetooth, hundreds of legacy
| js and css features, no pdf/print support etc). I'm pretty sure
| that if you can drop all the stuff you don't use you get better
| performance/efficiency.
| hobofan wrote:
| The Electron alternative that possibly isn't one.
|
| Electron apps are usually quite heavy because they bundle Chrome.
| Tauri doesn't and instead relies on webview, which uses a
| different browser engine dependent on your platform, with all the
| incompatibilities that come with it.
| Tuna-Fish wrote:
| > Tauri doesn't and instead relies on webview, which uses a
| different browser engine dependent on your platform, with all
| the incompatibilities that come with it.
|
| Isn't windows system webview now a chromium fork? This should
| make incompatibility on the major platforms now much less of an
| issue.
| smasher164 wrote:
| People act as if they haven't dealt browser incompatibilities
| in the past. Just feature-detect/polyfill and move on.
| notatoad wrote:
| Some people _haven 't_ dealt with browser incompatibilities
| in the past. Not every developer comes from a webapp
| background, and electron is a platform to develop desktop
| apps. desktop app developers don't want to deal with
| polyfills and feature-detection in their platform.
| Kaze404 wrote:
| It's weird to want all the benefits of web development
| without it's unfortunate quirks in my opinion. If desktop
| developers don't want to deal with them, which I think is
| reasonable, they have loads of other tools they can use
| to build desktop apps (and give the users a better
| experience most likely).
| judge2020 wrote:
| It's not weird - every developer wants to 'just code'
| their features/business logic without having to deal with
| the pain points of the tech. They choose web tech for
| their app because the opportunity cost of learning a
| desktop-native language is the time that could be spent
| bootstrapping an electron app and getting the product out
| the door earlier.
| seph-reed wrote:
| It seems like it would be pretty easy to get rolling a
| feature request for automatic polyfills. I'm not sure if
| Tauri pre-compiles the js it's handed, but if it does it
| can very easily check for what needs to be polyfilled.
| chrismorgan wrote:
| That works for many _scripting_ capabilities, but there's
| plenty you can't polyfill. If you're stuck with the old
| MSHTML-based web view (which you will be on all but very
| recent Windows 10 and even sometimes there), there are
| various CSS Grid features that you can't polyfill, and
| you'll have a number of weird and annoying SVG sizing and
| styling issues quite apart from any potential missing
| features, and a bunch of other things like that-- _even if_
| you polyfill everything in reach (which, even where
| possible, may perform terribly).
| Klonoar wrote:
| That updated Webview is, still, not the default on Windows.
| You have to ship it yourself.
| flowerlad wrote:
| On their web site I don't see a quick answer to the most obvious
| question: How's it better than Electron? Does it require less
| resources than Electron and if so how does it accomplish it?
| dmix wrote:
| Just a note to the marketing site developer I wasn't familiar
| with the "Brownfield" term and that was the first one listed.
|
| For others
| https://en.wikipedia.org/wiki/Brownfield_(software_developme...
|
| Also the first comment by brunsolf might be worth considering as
| the first description.
| worik wrote:
| "The core is built with Rust and the CLI leverages Node.js"
|
| Sublime to the gorblimy in one sentence!
| hashedout wrote:
| Hmm, there doesn't seem to be any real applications made with it
| yet. Though, the roadmap looks good.
| yannoninator wrote:
| Not sure why this is downvoted, this is a good point.
|
| Before people are getting hyped around this, this is alpha
| software and not production ready.
| thereddaikon wrote:
| Can we just stop using browsers as a framework for desktop
| applications? That's not what they are meant for. Electron and
| everything like it is the ultimate expression of developer
| laziness.
| qudat wrote:
| There's a reason why no one wants to build a desktop app using
| Qt and it's not laziness.
| Nagyman wrote:
| Can we stop attributing technology choices to laziness? Sounds
| like a _lazy_ evaluation and presumption of someone else's
| motivations.
|
| More seriously, there are far more folks familiar with browser
| frontend technologies than the myriad of desktop frameworks,
| rife with their own challenges.
| shomyo wrote:
| 'Written in Rust' is a new 'I use Arch, btw'.
___________________________________________________________________
(page generated 2021-02-19 23:00 UTC)