[HN Gopher] Tauri: An Electron alternative written in Rust
___________________________________________________________________
Tauri: An Electron alternative written in Rust
Author : metalwhale
Score : 1068 points
Date : 2021-02-19 16:49 UTC (1 days 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
| [deleted]
| galaxyLogic wrote:
| Reading all these comments about WebView compatibility issues
| makes me wonder why not just do Progressive Web Apps"? For the
| server the OS doesn't matter, and for the browser compatibility
| issues just deal with them like any web-app would.
|
| What is wrong with separate client and server?
| niels_bom wrote:
| Isn't there a lot more work to do around local IO and
| permissions with PWAs?
| JanSt wrote:
| does it support the bluetooth web api?
| Chyzwar wrote:
| I just tried and integrating with create-react-app was an breeze.
| I would consider that as an alternative for electron.
| 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.
| jjjeii3 wrote:
| Blazor can now also be used to write cross-platform desktop
| applications with C# similar to Electron:
|
| https://visualstudiomagazine.com/articles/2021/02/17/net-6-p...
|
| C# will then be compiled to WebAssembly.
| 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?
| gigel82 wrote:
| Have you tried developing relatively complex UI with QT? You
| need to hire a team of engineers and spend man-years of effort
| to build custom UX that in the web / Electron can be replicated
| with an npm install fancy-library.
|
| Yes, I hate Electron, but the alternative is not QT; it's
| something like Sciter.JS with real Web API compatibility (or
| perhaps a stripped down WebKit2 which is much less resource-
| heavy).
| GirkovArpa wrote:
| I am convinced that the sort of Web API compatibility so many
| people demand is only a few native libraries away. I would
| like to start experimenting in this area but I can only get
| rust-sciter DLLs working with "vanilla" Sciter and not
| Sciter.js, and I don't want to use other languages.
| jcelerier wrote:
| I worked in a job where people developed very similar Qt and
| Electron apps, in both cases it was a one person effort and
| the development took about the same time.
| GirkovArpa wrote:
| Would you be able to mention these apps? I would like to
| take a look.
| 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.
| hannofcart wrote:
| Their licensing is written horribly, to just FUD companies
| into buying their commercial license.
|
| However, the library components offered under LGPL3 are all
| you need to ship a perfectly good desktop app. The GPL3
| licensed stuff listed in the comparison chart on the page you
| linked are typically the utility applications like Qt
| Designer which you won't need to ship with your application
| anyway.
|
| It's unfortunate how the company backing Qt is going about
| this. But it's a great framework overall.
|
| (At my last firm, we shipped several apps via Qt and it's
| always been a joy to use.)
| 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.
| bscphil wrote:
| Is the M1 really not competitive with the latest XPS?
| jlokier wrote:
| Unfortunately, The XPS would be useless for that part of
| my workstation class problems that target the Apple
| ecosystem.
|
| Like almost everyone, I'm financially constrained as well
| as space constrained. so buying multiple expensive
| machines, or a high end Mac Pro or something is not on
| the table as an option.
|
| So it's a compromise.
|
| My compromise at the moment is to use a MBP for Apple
| things, do smaller Linux and Windows things in a VM on
| it, and do big Linux and Windows things on cost-optimised
| rented servers much more powerful than the XPS from Dell.
| That seems to be a better use of the resources I have for
| the workstation class problems I'm choosing to solve.
|
| An additional target of my interests is the M1-class
| processor with it's ARM plus extensions architecture.
|
| So I will wait and see what the next high end, ARM-based
| MBP from Apple is like. By all accounts the M1 is an
| excellent and powerful processor, competitive with other
| Intel-based laptops, so its successor may be a good match
| for my needs. It might not be, in which case I will need
| to revisit my strategy, but until it's announced we don't
| know, and it doesn't make sense to buy an XPS at the
| moment for what might be just a few months of only
| marginal discomfort. I have my servers after all.
| 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.
| bscphil wrote:
| I suppose this depends on your point of view. QT has
| achieved broad acceptance as "the" cross platform
| solution among open source Linux-first applications, as
| well as much of the open source ecosystem more generally.
| (Open source being what it is means that there are _many_
| exceptions, obviously.)
|
| For example, on my computer right now I have 55
| applications that depend _directly_ on qt5-base, _not_
| including libraries and parts of QT. This is _also_ not
| including a ton of applications that depend indirectly on
| QT, including most every KDE desktop application, which
| depends through KDE 's frameworks.
|
| So while QT may not have caught on in commercial software
| development, I'd say calling it a failure depends very
| much on what software ecosystem you're in. You might
| argue that HTML has achieved "universal usage" for
| desktop apps in a way that QT has not, but I would have
| to disagree. I don't have a single HTML UI or Electron
| app on my computer, and I don't feel as though I've given
| anything up. In fact I simply haven't come across any of
| these apps that I felt like I needed.
|
| So I might say that HTML has failed to gain mass usage on
| the platforms that matter to me. :-)
| jcelerier wrote:
| > were all super capable and promising but failed to gain
| mass usage
|
| Depends where you look. Plenty of hardware devices use Qt
| as their UI. Modern Mercedes-Benz and Ford cars, LG TVs
| UI, stuff like the Remarkable tablet or th Telegram chat
| app... The nice thing being that you can test the UI on
| whatever OS you're running. Also, i18n on the web ? Come
| on. It's terrible when compared to Qt tooling
| simias wrote:
| I think you're right, but I'm not sure about "easy to
| use". It's only easy to use because everybody uses it, so
| as you point out there's a massive talent pool and
| massive resources.
|
| As somebody who only started developing for the web a few
| years ago after a long time working with Qt, winforms,
| GTK and other "old school" native toolkits, I really
| don't find the web superior in terms of simplicity
| outside maybe of a few niches. You end up having to
| resort to dozens of external libraries to emulate the
| base functionality of something like Qt. And unless you
| want to go the transpiler way (which, admittedly, is
| incredibly common these days) you have to do it all is
| Javascript which is easy to pick up but a pretty huge
| liability in the long run IMO. It's just not a very good
| language, even if you stick to "the good parts".
| 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.
| simias wrote:
| Honestly I could try to ignore the memory consumption if at
| least it was snappy. The few electron apps I use have
| visible lag when I do something that forces a large redraw.
|
| That's a problem that didn't have with GTK app running on a
| computer with one order of magnitude less computing power
| and RAM two decades ago. VS code on the first computer I
| used to program would probably be unusable (if it even
| launched), yet we had full fledged IDEs back then. I'm not
| talking about advanced language server plugins here, just
| basic usage.
|
| The great side effect of this is that if you avoid all this
| wasteful crap and keep using old school technology,
| computers are snappier than ever. My terminal always pops
| up instantly, nvim fires up faster than I can press return,
| rg lets me search a huge codebase with barely noticeable
| latency. My IMAP mail client is faster, more configurable
| and more ergonomic than any webmail I've seen.
|
| Life is good when you avoid the www.
| 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.
| eivarv wrote:
| That's not my experience, at least. I haven't had any major
| issues I wasn't able to solve with either.
|
| Even if I were more comfortable with web tech when I first
| started experimenting with this stuff (some time around
| 2012-2015) I still found the end result much better.
| Neputys wrote:
| If you don't go beyond standard interactions and look
| it's probably fine but let's say I want system chrome to
| look like the one in photoshop and some custom dropdowns
| for starters...
| ianlevesque wrote:
| Why would your desktop users want your weird drop downs?
| UI consistency used to be a thing.
| kaszanka wrote:
| Some companies/people take branding too seriously.
| jcelerier wrote:
| ... it'd be doable ? E.g. look at telegram which is a Qt
| app and even more foreign-looking than Photoshop:
| https://images.app.goo.gl/JVNR4Jetmh7frvwo6 . Or
| allegorithmic substance, also made in Qt:
| https://images.app.goo.gl/CbJaGhRvSswymAjQ7
| Razengan wrote:
| SwiftUI is pretty good, if you don't care about
| Android/Linux/Windows.
| ori_b wrote:
| I feel like this is a monkey's paw wish. I've wanted to see QT
| and GTK replaced with something better for a long time.
|
| We got Electron, and other browser based toolkits.
| 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.
| ianlevesque wrote:
| React Native is fantastic as a user on macOS and Windows.
| Personally I think if there's any hope of winning the
| Electron crowd over that's it. I like to develop with
| stronger typed languages than JS, but there's clearly demand
| given electron's popularity.
| calibas wrote:
| I started getting in the habit of using Typescript with JS.
| It's annoying at first, but worth it for any decent sized
| codebase. All the bugs from JavaScript's unexpected type
| conversions just disappear.
| 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.
| areille wrote:
| It would be fun that Dart finally takes over Javascript this
| way (Flutter is written in Dart, which was originally written
| to be the new Javascript)
| pictur wrote:
| I wish the dart language was more common than typescript.
| but this is very hard.
| y2bd wrote:
| What do you like about Dartlang? Every time I've looked
| at it it's seemed like a rather uninspired language,
| almost like a slightly more dynamic Java (and an older
| Java too). I've never used it for anything production
| though.
| 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!
| jokoon wrote:
| I can't help to remind everyone to watch The Birth and Death of
| Javascript:
|
| https://www.destroyallsoftware.com/talks/the-birth-and-death...
|
| Cousins of electrons and their RAM requirements are a steep
| reminder that the DOM is cancerous and will have to evolve and
| suffer from deprecation.
|
| Or maybe introduce metrics and good performance practices?
| 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.
| [deleted]
| [deleted]
| 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.
| jcelerier wrote:
| Slack definitely does not look good when your definition of
| "looks good" is "integrated with the rest of the OS"
| stevenhuang wrote:
| Same here for Windows. Feels like using a video game UI.
| Probably is the basic styling, but I'm really liking the file
| size (2.6MB) and mem usage (app.exe using 2.7MB with the
| "Desktop App Web Viewer" instance using 22MB) otherwise.
| 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.
| davej wrote:
| I've been following this project for a while, it's super
| exciting. Unfortunately, progress seems to have slowed somewhat
| in the last 6 months.
|
| Loading Node in the renderer is a broken pattern that is full of
| compatibility issues and security vulnerabilities. Electron have
| come to realise this too and seem to be pushing towards
| ContextIsolation and explicitly defined bridges between the
| "backend" node process and the renderer.
| 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/
| c-smile wrote:
| In what sense it is an alternative to ElectronJS?
|
| If size than not that much as Tauri is based on Node.JS that is
| 56 Mb executable by itself.
|
| Yet Node.JS is pure C/C++ code. It is not clear what does
| "written in Rust" mean at all and what benefits Rust provides in
| that setup.
|
| For the comparison: my scapp.js.exe (
| https://github.com/c-smile/sciter-js-sdk#demos ) that is
| Sciter.JS packaged as standalone exe without dependencies is of
| size 5.3mb - at least 10 times less than Node.JS, Tauri and
| ElectronJS.
|
| That exe includes HTML/CSS, QuickJS (ES2020) engines and
| essential portions of Node.JS runtime:
| https://github.com/c-smile/sciter-js-sdk/blob/main/docs/md/m...
|
| So is the question above, alternative in what sense?
| datagram wrote:
| Tauri apps don't use the NodeJS runtime. You have to write your
| app's backend in Rust. Like you said, the NodeJS runtime is
| tens of MB; if you look at their demo app you'll see that it
| doesn't even break 3MB.
| hojjat12000 wrote:
| If you look at the website you will see that it is not bundling
| Node.js, apps can be as small as less than 1mb. It is written
| in rust (because the backend is, also it will integrate with
| Deno in future which in Rust). It is still in development, but
| if you look at the website you will see the features that it
| provides or will provide (such as system integration) and the
| value that it adds.
| 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."
| pjmlp wrote:
| Thanks, I stand corrected.
| dmix wrote:
| Definitely needs a better homepage, one better targeted at
| developers, which so many fail to do.
| 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.
| antihero wrote:
| Wouldn't a better solution to be use something like
| https://github.com/microsoft/react-native-macos ?
| 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...).
| baxrob wrote:
| No offense: https://www.youtube.com/watch?v=RJv2-_--EY4
| 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.
| lucideer 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._
|
| Which is why many many people tried this approach long before
| Electron came along. Electron has been successful largely
| because it deviated from this: it swallowed the bitter pill of
| bundling the heavy duplicated webview in order to ensure a
| consistent development target.
| 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?
| ksec wrote:
| The problem is not all current Web Standards are supported
| across all System Browsers. So the Subset is meant as
| lowest common factor. How do get anything to work when you
| have customers using IE?
| tssva wrote:
| It seems every couple of months there is an alternative to
| Electron posted here which uses system webviews. A quick search
| turns up a wide variety of them.
| 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.
| willwinger wrote:
| I agree, however last time I checked Servo was not that
| stable.
| lcnmrn wrote:
| Yes, it doesn't yet render pages as good as other
| browsers, but we can tweak our code for it. 10x better
| performance and 100x less memory usage is a win.
| hawk_ wrote:
| any idea when windows webview will switch over to Chromium?
| veidr wrote:
| One approach that you can take to deal with this is to
| mentally back way the fuck off the 1990s on what your UI
| expectations are.
|
| Give up pixel-accuracy and fine-grained control of your app's
| UI layer, and just treat it how people like Peter Norvig and
| Chris Lattner treat their home pages.
|
| There isn't any browser with even 0.1% share that can't
| render those things.
|
| You also don't really have to go as far as those guys do,
| leaving the font 14-point Times New Roman and using HTML 1
| tables. You can add some style, fonts, etc... just don't add
| anything that would make it _not work_ if somebody opened it
| in Netscape Navigator 4.
|
| There is definitely a big downside, in that your app won't
| look all dope and modern. For many apps that is a deal
| breaker. Also, some UIs really do require a higher fidelity
| UI. Not all UIs are just like, buttons and menus (although a
| lot are).
|
| But there is also a big upside: durability, in the sense that
| your app's UI will work on most 10-year old computers, and
| most computers 10 years from now.
| 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.
| Klonoar wrote:
| WebView2 does not use that Chromium, however.
|
| It's slightly absurd, and you should direct the "WTF?" to
| Microsoft for this.
| oldmanhorton wrote:
| Edge is pushed to the vast majority of PCs, and on those
| machines, I believe it provides a system-level webview2
| component. You can choose to package your own webview2
| into your app if you want the extra compatability that
| offers at expense of app size and ram usage
| 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.
| pitay wrote:
| At least with writing uncomplicated web applications it
| was still quite easy to have it compatible with the major
| browsers, you just had to test the web application with
| them as you wrote it to make sure. Compatibility problems
| didn't even come up very much while building it if you
| stayed reasonably within the boundaries of standards that
| were well entrenched. The biggest issue was how little
| CSS IE6 supported, if you did anything fancy with CSS and
| it didn't work with IE6 you had to include an IE6
| specific hack, fortunately that was easy and worked
| completely fine with other browsers.
|
| There were problems with internal off the shelf
| applications whose user interface was built for IE6 only.
| The funny thing is those applications still worked well
| with the Firefox of the time, but IE9 broke compatibility
| with them and the applications didn't work on IE9, but
| IE10 got released and was compatible with them again.
| 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.
| ahepp wrote:
| I also hate electron apps, I refuse to install them on my
| personal machine, and use a(n independent) web browser.
|
| Efficient software is great, the cool parts of the
| projects I work on are efficient. In my case, the GUI
| doesn't need to scale in the same way, and I'm pretty
| confident the customer would rather have better cross
| platform support (at a lower cost than if we had to test
| a bunch of OS web views) than 100MB of their disk back.
|
| But yeah, there are plenty of examples of software I use
| where I disagree. Although this is often based on my
| aesthetic dislike for an inelegant system, than on any
| kind of resource constraint.
| 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.
| ahepp wrote:
| Actually it's the opposite. I know my users care more
| about cross platform support, or any other feature I
| could whip up, rather than 100MB HDD space.
| mst wrote:
| I cordially dislike Electron apps, _but_ once one factors
| in opportunity cost given limited developer manpower, the
| trade-off you 're choosing to make here is quite likely
| entirely rational.
|
| I would prefer to live in a world where I didn't believe
| the last sentence to be true, but in the current world I
| still think it is :)
| [deleted]
| 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.)
| 3np wrote:
| Did you try Brave? I'm yet to encounter anything that
| works in Chrome but not in Brave (save for the occasional
| site that breaks because of ad/trackblocking, which can
| easily be disabled)
| kaba0 wrote:
| Well, because Brave is pretty much a renamed chrome with
| preinstalled adblock
| 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.
| ruined wrote:
| but, conversely, browsers tend to have access to a lot of
| ident/auth goods that a standalone electron wouldn't,
| even if you're using containers. also it's perhaps harder
| to phish someone running an electron app because outside
| webpages open a real browser.
| dcow wrote:
| Running tabs in a separate process has been a boon IMO.
| It's better security and a crashed tab doesn't bring the
| browser down and an unresponsive tab can be killed
| independently.
| jlokier wrote:
| I agree, however that is part of the argument for why
| Electron RAM usage should be compared against browser
| tabs, instead of assuming that Electron must be using a
| lot more ust on principle because it's separate.
| 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.
| simonh wrote:
| Or at all, how many Electron apps would bother with
| native Linux clients for example. Some maybe but
| certainly not all and probably not most either.
| krzyk wrote:
| Electron app is not a native Linux client, it is just a
| browser app. If you ran that app in a tab it gives you
| much better performance and less memory used.
| krzyk wrote:
| > 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.
|
| Exactly, one can look at Telegram app, it is clean,
| polished and open source client written as a native app
| that works across many platforms (and one of few that has
| Linux client).
| cdmoyer wrote:
| Honestly, this site is the only place I really hear about
| the supposed horror of electron. The resource issue
| doesn't seem to effect me or people in the 7 slacks I'm
| in all day.
|
| My 6 year old MacBook runs slack, Xcode, android studio,
| safari, chrome, messages, vs code, vim, iterm2, preview,
| battle.net and hearthstone all the time without issue,
| really.
|
| I think for the average user, they'd rather have more
| features across platforms more quickly than a smaller
| resident memory footprint and install size.
| wutbrodo wrote:
| For a counter-anecdote, I've seen the Slack app freeze up
| colleagues' workstations many times, and these are
| monster machines designed to run an autonomous vehicle
| stack on raw sensor data.
| nicoburns wrote:
| > Instead of writing platform specific apps
|
| You've answered your own question as to why people write
| then.
|
| > What value does electron add to the user?
|
| It adds a lot of value to Linux and to a lesser extent
| Mac users: before a electron a lot of apps didn't have a
| version for these platform at all.
| wutbrodo wrote:
| I've been an exclusive Linux user since college so I'm
| aware of the disadvantages of app/service unavailability
| (I remember the dark days of running Netflix in a windows
| VM that I barely had enough RAM to run...).
|
| But what's the advantage of using the Slack app over a
| browser tab? This is a sincere question, since enough
| people reference the benefit of faux-native wrapped
| webapps that I assume there's some value.
|
| I seem to be the only one in my company who doesn't use
| Slack's app, and I'm always shocked when I see a
| colleague's computer freeze and have them say "ugh it's
| almost definitely the Slack app". I work in autonomous
| vehicle engineering, so these are _monster_ machines I'm
| talking about, capable of running the entire car's stack
| locally. The only advantage I can think of are desktop
| notifications, but 1) I'm pretty sure browsers support
| those and 2) is that really worth using an app that's
| amateurish enough that it freezes your computer
| regularly?
| JoshTriplett wrote:
| For an app with no source available publicly, I would
| much rather have a web app in a sandbox than a "native"
| app (whether native or electron-style) that I would have
| to trust.
| krzyk wrote:
| > It adds a lot of value to Linux and to a lesser extent
| Mac users: before a electron a lot of apps didn't have a
| version for these platform at all.
|
| I prefer web versions of those apps on Linux than
| electron. Sorry, I want to run just one browser and it is
| not Chrome based one.
|
| And for sure Electron apps don't allow that ease of cross
| platform development as one thinks, I would argue that it
| is on the same level as a native app with good
| abstraction library (see Telegram client source on
| github).
|
| It is more that they don't want to hire desktop
| developers (or just ones that want to learn something
| else than JS).
| 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/
| dmitrybrant wrote:
| My god... a 200+ MB install footprint, 200+ MB of RAM
| usage, requires a beefy GPU just to render its window.
| How did we get here?
| brodock wrote:
| I think we got there also by desperation of lacking good
| cross-platform GUI toolkits.
|
| The current state is, you either use something that looks
| like Windows 95 in all platforms, or web app.
|
| What the web made possible is to anyone to create a
| decent custom UI with little effort. I still remember how
| messed up was to create a custom component for Java
| Swing, which I believe is still one of the easiest to do.
| How would you do that for QT? GTK? WxWidgets? etc
| krzyk wrote:
| Take a look at Telegram client, looks great on Linux, not
| sure how it looks on macos or Windows.
| dleslie wrote:
| I'll take Win95 in a heartbeat; consistent, accessible,
| responsive and clear. Vastly superior to the majority of
| web interfaces.
| kilburn wrote:
| Also totally inflexible, you better have the right-sized
| screen/resolution: too small and you can't see that "ok"
| button; too large and you'll have a ridiculously small
| and crammed winform to fill/see your information.
| pjmlp wrote:
| Most cross platform toolkits support layout managers,
| since Motif days.
|
| Actually even WinForms supports them, even though too
| many are happily doing fixed canvas positioning without
| using them.
| dleslie wrote:
| Windows has shipped an accessibility magnifier since the
| 90s, before hidpi was a thing.
| smt1 wrote:
| Qt is (still) very good at being cross platform and
| native looking. Actually, I think qml is easier than the
| webstack for newbies, perhaps not C++ though.
| mekkkkkk wrote:
| I might be crazy, but for me it's faster and more
| convenient to download and run Etcher than to read up on
| dd command arguments and device paths. Storage space is
| plentiful for me. RAM isn't an issue as it's only run
| once in a blue moon.
|
| Is it crazy bloated and resource hungry for what it does?
| Undeniably! Does it matter? Not for me.
|
| Electron resource use can be painful for apps that are
| running constantly, like Discord, VSCode and Slack. For
| utilities like Etcher, who cares.
| eitland wrote:
| In fairness, for some reason Etcher works sometimes when
| other things don't.
|
| It might be because it is slower and doesn't overheat my
| usb sticks, I don't know, but if nothing else works you
| can try etcher.
|
| (Not sure how I found out, can have been something I read
| or a recommendation by a colleague 3 a 7 years ago or
| something.)
| morpheuskafka wrote:
| The actual duplication is done in the Node.js runtime,
| not the V8 runtime inside of the Chromium GUI layer.
|
| I do wish they had a command-line version that just ran
| node without Chromium, but there is a use-case to have a
| simple foolproof application like this; these days there
| are a lot of people who need to image drives like this
| and would be best not to mess with dd on their first
| time.
|
| And dd doesn't exist for Windows so you've got to use
| some tool or another like this.
| 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
| ajxs wrote:
| I see a lot of people in the tech industry deeply
| concerned with human impact on the environment and our
| diminishing prospects of repairing it without drastically
| altering our lifestyles. At the same time the general
| consensus in the tech industry towards the steady
| increase in power requirements for everyday computing
| seems to be indifference.
|
| These two viewpoints cannot be reconciled.
|
| Every month when this Electron discussion comes up there
| are so many who dismiss the egregious resource usage
| outright on the basis that it's trivial for modern
| computers. I'm one of those people who use Thinkpads in
| 2021 for my personal computing and have no problems with
| it. I will never buy a Mac, and I don't want to
| unnecessarily spend hundreds of dollars on a modern
| system when refurbished ones from a decade ago work so
| well. I avoid Electron apps on the basis that they
| flatten my battery quickly. I switched from using vscode
| to vim on my x200 and my battery life tripled, I'm not
| even exaggerating here either.
| slaymaker1907 wrote:
| No, they are completely reconcilable. The amount of power
| it takes to run a powerful consumer CPU is trivial
| compared to the amount of power used in many other common
| applications like heating, vehicles, etc. This effect is
| particularly pronounced when you consider that laptops
| use way less energy than desktops (on average) and mobile
| computing as a whole is displacing desktops outside of
| niches like PC gaming.
|
| The environmental issue doesn't make sense IMO, but
| increasing hardware requirements does have real impact on
| accessibility.
| ajxs wrote:
| These effects scale. If every single laptop uses a small
| amount more power than is necessary, the relatively minor
| increase in energy use for one computer totals up to a
| significant increase in overall energy usage. Not to
| mention the unnecessary obsolescence of hardware. The
| externalities of manufacturing new hardware - and
| disposing of old hardware - are extremely significant.
| Just so what? So my perfectly good 10 year old laptop has
| enough RAM to run 6 Electron apps at once?
|
| Sure, your ceiling lights use less energy than your
| fridge. That's not a justification for everyone to
| completely ignore turning them off when not needed.
| FooBarWidget wrote:
| Even if they add up, they still pale in comparison to the
| amount of energy you can offset with a couple of
| windmills.
| doctorbuttes wrote:
| Let's ban anything not written in assembly.
| yuanchenxi95 wrote:
| Second that
| GuB-42 wrote:
| Maybe not banned but they could do a carbon tax like they
| do with motor vehicles. Or maybe like with appliances
| where you have an energy rating, with stickers telling
| you how much electricity it will use per year, possibly
| with tax incentives to pick the most efficient.
|
| Problem is: how to test that? Even with the most
| straightforward tests, there are cheaters. Appliances
| have a special "eco" mode to meet the specs that most
| people won't use because it barely does the job. And for
| cars, well, VW have shown us how far companies are ready
| to go.
| magnio wrote:
| > it's inefficient computation to energy ratio
|
| Probably true.
|
| > affects the global climate in a negative way
|
| If electricity consumption of all computers in the world
| doubled because of Electron apps, the total annual
| electricity consumption would increase by 0.01%. So
| probably false.
| jcelerier wrote:
| In 2012 PCs (only PCs, not network appliances, not data
| centers, not phones...) were estimated at 1.5% of global
| electricity use, so you're off by a good margin. And that
| is deeefinitely not negligible, nor is the need (and eco
| impact) to buy newer computers because a 2016 MacBook Pro
| is unusable when your work requires 4/5 electron apps
| side by side.
| magnio wrote:
| I stand corrected. Turns out I forgot to multiply by 365
| days/year. The real figure is indeed in the ballpark of
| 2%.
| 3np wrote:
| No joke, if it weren't for the resource usage of vscode
| and the couple of other Electron apps I rely on, I
| wouldn't consider upgrading my workstation (which is
| already new enough to be energy efficient enough but
| maxes out at 24GB RAM) but here we are.
| 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.
| fn1 wrote:
| That same reasoning is why Google is having a YouTube app
| on AppleTV which does not use native widgets, so
| bluetooth keyboards don't work, scrolling is off etc.
|
| It's not that they cannot afford building 10 native
| AppleTV apps in parallel and pick the best one.
| Klonoar wrote:
| Nobody ever said that Slack couldn't be implemented in
| Cocoa, and it's really not remarkable that someone did
| it. ;P
|
| You and I both know that one person can write UI in a
| vacuum, but there's a litany of other challenges that
| come up when positioning an application across platforms
| - sharing code, resources, etc. If all you look at it on
| is a technical level, you're doing the problem a
| disservice.
| 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
| sodality2 wrote:
| https://news.ycombinator.com/item?id=18763449
|
| "This is literally what Slack moved from years ago,
| because it was very problematic, let me tell you why
| since I'm the one who did it.
|
| * Adding new APIs was a huge pain in the ass, you had to
| write all of this ugly bridge code in Objective C, and
| the APIs ended up being super unnatural on the JS side.
| As a result, desktop integration wasn't done much since
| it felt like a "Black Magic" type thing. Writing new APIs
| in Electron is Just JavaScript, so you can make something
| much more natural.
|
| * We could literally do fuck-all for people running old
| versions of macOS - you can't upgrade Safari on old
| machines, you just Get What You Get. For awhile, every
| YouTube video on older macOS versions had a pink shade to
| it. Users write in, "This is clearly wrong!" "Yep, but we
| can't fix it. Sorry."
|
| * And big spoiler - WKWebView uses _basically_ the same
| amount of memory give-or-take a few MBs as Chromium. It's
| the content that sets the memory usage bar, not the host.
| "
| [deleted]
| [deleted]
| jedbrown wrote:
| How does one get the Slack sidebar inside a browser tab?
| I loathe the Electron app, but don't have a different
| viable way to manage 30-odd workspaces.
| Wowfunhappy wrote:
| > 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.
|
| Coincidentally, Slack _doesn 't_ fully work in Safari or
| traditional Edge. Video calls only work in Chromium-based
| browsers, and in the Electron app which is of course also
| Chromium.
|
| This is actually the thing that finally got me to switch
| back to Chromium last week, after using Safari and
| Firefox for the better part of a decade. The Electron app
| sucks, I don't like switching between browsers for
| usability reasons, and I need to make Slack calls for
| work.
| Tijdreiziger wrote:
| Anecdotally I wrote some JavaScript just today (I'm not a
| frontend dev but I write some simple stuff for fun
| sometimes). It seemed to me that every modern feature you'd
| care about is now widely supported. I used the JS fetch API
| and template strings and these things just work in modern
| browsers. I even encoded my web fonts in WOFF2 only,
| because it's so widely supported that I didn't see the
| point in bothering with WOFF1 too.
| Xevi wrote:
| Tauri also uses MSHTML (Internet Explorer) on Windows. And
| there's no way I'm going back to developing for that.
| nicklarsennz wrote:
| Isn't IE just using Chrome now? Or do you mean support
| for old IE?
| Xevi wrote:
| No, IE is still the same. But Edge has moved to Chromium.
| nicoburns wrote:
| Their browser is. But Windows' webview is still the IE11
| engine.
| 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.
| toastal wrote:
| An entire generation is being raised on Chromebooks. I
| wish Boot2Gecko and Firefox OS weren't a bit ahead of
| themselves and had better _ugh_ marketing.
| brokenkebab wrote:
| Entire generation where? Let's say I saw exatly 1 guy
| with a chromebook through my life, and likely chromebooks
| weren't even officially sold in my country. And still
| Chrome is the most popular browser here.
| 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.
| oxymoron wrote:
| In 2008, when IE7 came out, I cried of joy. I turned 22
| that year, so the 7 years with only IE6 and Firefox was a
| significant chunk of my life. Firefox showed us that the
| web wasn't finished and could still be improved, and then
| came Firebug which made Firefox first web dev the obvious
| choice. But the vast majority still used IE6, so there was
| always a miserable step in the project of fixing all the IE
| bugs. After doing it for years and knowing your foe, it was
| by then a relatively quick and manageable experience. The
| real pain was in knowing all the CSS2 features and other
| goodies that could never be used. Seeing Microsoft
| recognizing that, yes indeed, the web wasn't finished in
| 2001 was actually an emotional moment at that point.
|
| So yeah, the situation is without doubt much better now. I
| think people tend to forget (or aren't aware) that
| Microsoft actively said "there's no more work to be done
| here" and stopped all progress for 7 years. There's been
| some progress on the web since 2014, as a point of
| comparison.
| mattmanser wrote:
| I've had to say this a fair few times here, but I'll keep
| saying it.
|
| IEDevToolbar, which Firebug was pretty much a clone of,
| came out a year before Firebug. And it took Firebug years
| to catch up in feature parity, as far as I remember.
|
| So, firebug didn't make it the dev tool of choice. We all
| just hated microsoft. And tabbed browsing was great.
| Klonoar wrote:
| What?
|
| I used that IE toolbar setup for years, and it _never_
| worked as well as Firebug did.
| oxymoron wrote:
| I was young and dogmatic, so I did admittedly despise
| Microsoft back then. I can't recall I ever heard of
| IEDevToolbar, though. Did it really feature the DOM tree
| view where you could do CSS manipulation? I always had
| the impression that it was a Firebug invention, but I
| could be wrong about that.
| treve wrote:
| The DOM inspector view in Firefox predates Firebug by
| years. My memory might be a bit shaky, but it may even
| have existed in Mozilla Web Browser?
|
| It really looked like a 'DOM tree/tree of Javascript
| classes' though, not really like the inspector we have
| today.
| smt1 wrote:
| There is also servo, which may not be as complete as
| Chromium, but is definitely interesting architecture wise,
| especially with the number of virtual machines and
| compilers written in Rust these days.
| 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.
| userbinator wrote:
| "standards" - in practice, it's "what Google wants".
| 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.
| innocenat wrote:
| Especially on MacOS where Webkit usually behave
| differently? Like, why would webkit still require webkit
| prefix for Web Audio API, which is like 8 years old at
| this point.
|
| To me, develop for Electron is more fun than normal web
| because I don't have to check whether the new web feature
| I am using is available everywhere (especially Safari)
| yet.
| 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.
| cozzyd wrote:
| 100 MB / app is significant, especially on laptops.
|
| Slack used to use so much memory on Linux that I couldn't
| afford to run the desktop app and ran it inside a Firefox
| tab for years... seems to have gotten better somehow.
| kaba0 wrote:
| I doubt there would be many GUI apps that eat less than
| 100 MB -- if only that would be the maximum.
| 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.
| CommonGuy wrote:
| The Apple Silicon (M1) issue is because .NET (which we
| use for our "backend") doesn't support it yet.
|
| Linux does not have a core WebView out of the box, so
| libwebkit2gtk is the closest alternative. Not optimal,
| but it works. Looks like Tauri uses libwebkit2gtk too.
| dmix wrote:
| Fortunately MacOS users upgrade very quickly. High Serria
| which is slowly waning at 7% came out in 2017. Compared to
| windows where twice as many (16%) at still using Windows 7
| and won't be able to download the Webview2 update which
| Microsoft kindly provides.
|
| https://gs.statcounter.com/windows-version-market-
| share/desk...
|
| https://gs.statcounter.com/os-version-market-
| share/macos/des...
|
| Really depends on your market I guess and how much legacy
| webview browser support you need.
|
| Or really how much you'd need to add polyfills like
| `@babel/preset-env` to keep the JS equal.
| ac29 wrote:
| Webview2 supports Windows 7 according to the link in the
| comment you're responding to.
| [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.
| whywhywhywhy 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.
|
| The current generation of web developers who grew up within the
| Chrome ecosystem has zero interest in spending time on cross
| browser support.
|
| Even if the user had to install 4GB of chrome runtime they'd
| still argue it's better than them making it work in Chrome,
| Edge-Chrome and Safari WebKit.
|
| Not saying everyone, maybe my companies hiring process is
| screwed but every developerbar 1 that I've worked with over the
| past 4 years has been the same and even getting them to test in
| one other browser than Chrome is honestly like pulling teeth.
|
| Infuriates me as someone who's first job was CSS+HTML
| supporting IE 5.5-7.0, Firefox, Opera and Safari.
|
| The amount of times I've heard "Can't we just tell them to use
| Chrome?" when talking about users is getting absurd.
|
| The lack of understanding that a few hours of their job being
| slightly more difficult can add up to saving literal lifetimes
| of time saved or entire data centres of disk space when you
| extrapolate the savings across your user count. I know its
| maybe cheap to roll out a Steve Jobs quote but this one still
| resonates with me.
|
| "Well, let's say you can shave 10 seconds off of the boot time.
| Multiply that by five million users and thats 50 million
| seconds, every single day. Over a year, that's probably dozens
| of lifetimes. So if you make it boot ten seconds faster, you've
| saved a dozen lives. That's really worth it, don't you think?"
|
| https://www.folklore.org/StoryView.py?story=Saving_Lives.txt
| userbinator wrote:
| _The current generation of web developers who grew up within
| the Chrome ecosystem has zero interest in spending time on
| cross browser support._
|
| The scary power of Google.
| trustdragon wrote:
| It is a good idea but it is not a new idea
|
| the interesting history of these sorts of frameworks is that
| Google actually created a framework that did this and stopped
| development on it. the code is still on GitHub. And there's a
| bunch of other frameworks that use a variety of different
| languages not just rust as the application language that also
| have this idea of not bundling chromium but instead using the
| system webview for rendering HTML and JavaScript.
|
| You can find a bunch of different approaches in lists like
| "alternatives to electron." There's some on GitHub.
|
| I took a slightly different approach where instead of using the
| system web view which I thought you know is going to be
| inconsistent across systems and it's not going to support the
| latest HTML JavaScript and security features I used the
| assumption that the user already has chrome installed which
| works in a high number of cases or can download and install it
| if that's not the case. predictably I suppose some people
| express to satisfaction that it was not using Firefox. using
| Firefox becomes more possible and more likely I suppose as
| firefox's support for the dev tools protocol achieves parity
| with chrome support for that.
|
| https://github.com/c9fe/graderjs
| 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.
| elonvolo wrote:
| The dirty little secret is that a software project with two
| different native codebases is often cheaper, with a faster
| time-to-market, than a cross platform browser-tech based
| solution that had just one codebase.
|
| The BS of the browser tech world compounded over time and a
| million edge cases eventually eats up all the one-codebase,
| cross-platform savings.
| 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.
| saagarjha wrote:
| If you cared about performance, would you really be using
| Electron?
| innocenat wrote:
| Yes. Why not? HTML/CSS great (from the development POV) for
| UI, and I can always write the performance critical code in
| C and linked them to the electron HTML/CSS frontend.
| saagarjha wrote:
| Presumably, if copying some data between JavaScript and
| native code in a slightly roundabout way was an issue,
| you wouldn't run things through web technology in the
| first place...
| [deleted]
| 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.
| c-smile wrote:
| "is this impossible?"
|
| Possible, see Sciter.JS : https://github.com/c-smile/sciter-js-
| sdk
|
| 10 times more compact than Tauri, 20 times less than
| Electron.JS
|
| Yet it has Rust API ( https://github.com/sciter-sdk/rust-sciter
| ), that if someone need "Made with Rust" label :)
|
| And it works even on Windows 2000, do you remember that thing?
| See: https://sciter.com/necromancing-sciter-on-windows-2000/
| LockAndLol wrote:
| From what I understand the internals (aka the engine). That
| is a problem IMO. I understand it's to create a dependency on
| the maintainer in order to make money, but yeah... it's the
| reason I've stayed away thus far.
| gigel82 wrote:
| I like Sciter for the possibilities, but it needs better
| compatibility with web standards. Being able to port an
| existing application that uses React -for example- and have
| it just run would be the cat's meow.
|
| Needing to rewrite with other UI/JS frameworks to account for
| quirks gives me pause.
| c-smile wrote:
| It depends on what application you have in mind.
|
| React needs web browser compatibility layer to work in
| Sciter.JS as React was designed strictly for browsers.
|
| For that matter: PReact ( https://preactjs.com/ ) works out
| of the box already, see :
| https://github.com/c-smile/sciter-js-
| sdk/tree/main/samples/p... ;
|
| MithrilJS ( https://mithril.js.org/ ) works as it is also.
|
| SvelteJS works as it is with Sciter.JS too.
|
| Also Sciter.JS has its own native implementation of JSX (
| it's built in JS core of Sciter.JS) and also DOM extended
| by native element.patch(vdom) that makes "reactivity" to
| work in Sciter.JS with native speed.
|
| Yet quite a lot of UI components are natively built-in. For
| example:
|
| https://sciter.com/behaviorvirtual-list-for-sciter-and-
| scite... and https://sciter.com/sciter-js-themes/
| gigel82 wrote:
| I think the project is great and I admire your work, but
| I'm confused about how you position it.
|
| Being "almost" web compatible is not a recipe for
| success, as it's bound to cause confusion and frustration
| among folks that want it to be an Electron alternative.
|
| Either embrace Web APIs entirely (perhaps a smaller
| compatible subset), or just position it as something else
| entirely, like Flutter.
| c-smile wrote:
| "how you position it"
|
| Hmm... and how do I do that? What's your impression?
|
| Sciter.JS is "an embeddable HTML/CSS/JS UI engine" and
| that's it.
|
| Yes, it is possible to use it without touching native
| side like ElectronJS, see: https://quark.sciter.com/ ,
| but that's not the primary use case. So far it has around
| 400 mln installations in embedded form as part of other
| products, see: https://sciter.com/#customers
|
| If you want you can treat it as Flutter that uses time
| proven and familiar HTML/CSS/JS resource definitions
| instead of Dart. Dart is close to JS but not JS, Flutter
| has some DOM but not HTML DOM, it has some style system
| but quite rudimental one.
| gigel82 wrote:
| I think your description is technically correct, it is an
| UI engine that uses the HTML, CSS and JS languages.
|
| But to most folks, that sounds like a "web browser/view
| engine", which it is not. Does it pass the Acid2 / Acid3
| test?
|
| The power of ElectronJS is not its use of HTML, CSS and
| JS, but the fact that it is a web browser engine and one
| can share the millions of frameworks, libraries and
| muscle memory built for the web in their desktop
| applications.
| c-smile wrote:
| Modern browsers do fail on ACID tests anyway.
| display:flex broke old box model.
|
| > one can share the millions of frameworks ...
|
| For your *desktop* application you need just one, not
| millions of them.
|
| > libraries and muscle memory
|
| Not a problem, here I am using Remarkable [1] as it is:
| https://github.com/c-smile/sciter-js-
| sdk/tree/main/samples/m..., in other places I may use
| LeafletJS for showing maps, etc. Essentially all
| libraries for JS/NodeJS should work out of box.
|
| Problem is that desktop UI has different UI model from a
| web page. Web page / Web app is usually "endless paper
| tape" opened full screen - has defined width but no
| height - no need for vertical alignment for example.
|
| And desktop UI is usually different - small or vertically
| and horizontally space limited windows, etc.
|
| In Sciter you can show element as popup one - in separate
| window that can be rendered outside of your [small] app
| window, consider this popup: https://sciter.com/wp-
| content/uploads/2021/02/select-table.p... , good luck
| with recreating this in browser. By the way that <select>
| element is defined as: <select>
| <tr role=option value="1"> <td>Option
| 1</td> <td>*Short*</td>
| <td>123456</td> </tr> <tr
| role=option value="2"> <td>Option 2</td>
| <td>******* LOONG ********</td>
| <td>123456</td> </tr> <tr
| role=option value="3"> <td>Option 3</td>
| <td>*Short*</td> <td>123456</td>
| </tr> </select>
|
| Sciter supports arbitrary markup in selects, popups, etc.
| No one of "millions of frameworks" will help you with
| that.
|
| Also this <frameset cols="200px,*">
| <section>A</section> <section>B</section>
| </frameset>
|
| will give you split-view out-of-the-box. But web dev's
| will start looking for frameworks in order to achieve
| this simple component that browser have internally.
|
| TL;DR: Web and desktop UIs use inherently different
| models. You can share parts between these two different
| platforms but only parts, really.
|
| [1] Remarkable JS:
| https://github.com/jonschlinkert/remarkable
| croes wrote:
| Too bad it's kickstarter campaign to make it open source
| failed.
| jokoon wrote:
| Can it play videos?
| c-smile wrote:
| Yes. Check https://github.com/c-smile/sciter-
| sdk/tree/master/samples/vi...
|
| But Sciter do not have codecs embedded. Instead
|
| a. it [re-]uses streaming services of underlying OS;
|
| b. has interface for the hosting application to supply its
| own video streams.
|
| This way some applications use WebRTC as video sources,
| some use ffmpeg library to provide video streams. Video
| playback architecture is app dependent usually. Sciter
| provides to them "video rendering site".
|
| That's idea of Sciter - to reuse underlying OS services as
| much as possible.
|
| For example Sciter has spellchecking but only if OS
| provides spellchecking API (and usually they do).
| tambourine_man wrote:
| That's awesome, I'm gonna play with it over the weekend.
| Thanks!
| [deleted]
| _jordan wrote:
| sciter is a really wonderful piece of software. it's
| performance has been really impressive when I was benching it
| against qt
| 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.
| tambourine_man wrote:
| Safari is huge. Doing Chrome only is suicide. Thankfully,
| cross browser compatibility is much easier these days,
| specially if you don't use flex or grid.
| 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.
| GirkovArpa wrote:
| I've performed a couple experiments remaking Electron apps
| using Sciter.
|
| My first target was
| https://github.com/AkashRajpurohit/clipper, a neat little
| clipboard manager. The owner was gratious enough to
| officially list my project under the "Clones" section of his
| readme =D The result was a 6mb file, compared to the original
| 165mb Electron app.
|
| The second attempt was https://github.com/girkovarpa/temps-
| lite, an aesthetically-pleasing weather app which was
| motivated largely by the fact that the original was broken
| and abandoned yet still had people who wanted to use it.
| According to the open issues and forks trying to resurrect
| it, anyway. The file size savings were similar to the former,
| and they start virtually instantly. Unlike the Electron apps
| which have a bit of delay and then a blank window before they
| finish starting up.
| 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.
| ianlevesque wrote:
| It goes deeper than that. Frickin' Spotify has a manual toggle
| for whether or not I want Hardware Acceleration turned on or
| not. It's not the only one. I don't have any way to know which
| setting doesn't spin up my laptop fans and burn me. How about
| just building your app in such a way that I don't have to
| manually configure that. We've had music players since the
| 90's, I don't see why this is so hard.
| 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.
| SeriousM wrote:
| Every developer needs to have a certain understanding of
| the environment he tries to build something. Just like
| printing 3d models - you need to know the characteristics
| of the material and limitations of them and the machine
| you're using. Blaming one of these later on just because
| you didn't want to read the manual is unprofessional.
| 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.
| notatoad wrote:
| "it's weird to want nice things" is the sort of attitude
| that means you might have been a web developer for too
| long :)
| Kaze404 wrote:
| Not at all. Being a web developer I'm all for working
| towards fixing these problems. I could have communicated
| that better :p
| imbnwa wrote:
| What browser incompatibilities do exist are case-by-case
| basis, not all at once, depending on business domain and
| solution design, and even if, like you point out, you can
| just carpet bomb the issue with a poly/ponyfill.
|
| The infantilization in frontend is accelerated by its
| veneer of supporting Product's sole mission in life to ship
| products ASAP, and I fucking hate it, and I've been some
| frontend engineer somehwere unimportant for 5 years now.
|
| I wager, generalizing from my quite limitde experience,
| that a concerning amount of frontend devs just know how to
| schlep bags of data around and eventually get a desirable
| outcome with a framework keeping things narrowly from
| getting out of control when they are obvious re-factors,
| massive simplifications, that would get just as much
| expressiveness with less code. You will have bossess who
| only understand technical discussion in the form of "what
| framework or library should we use for this new epic?",
| like, bro, let's model the problem and see what we need
| from there maybe before we start thinking about writing
| code? You can almost just ask a frontend dev, "How would
| you refactor this or that code? to find out if they're just
| a baggage handler trying to minimize any concerted thought
| on their part. It's like frontend is corporate's proving
| ground on how to flatten all thinking and passion out of
| software engineering
|
| Sorry, end of rant. I came to frontend from academia
| naively thinking people wanted to think about problems and
| put effort into solutions
| 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-20 23:02 UTC)