[HN Gopher] Tauri - Electron alternative written in Rust
___________________________________________________________________
Tauri - Electron alternative written in Rust
Author : WolfOliver
Score : 493 points
Date : 2022-01-05 09:42 UTC (13 hours ago)
(HTM) web link (tauri.studio)
(TXT) w3m dump (tauri.studio)
| torginus wrote:
| What's the advantage of this? There are tons of projects other
| than Electron, that wrap a browser renderer, like CEF, NW.js etc.
|
| As I understand, the heavy resource use of these apps is due to
| Chrome, replacing the thin OS shim with something, hardly curbs
| the resource usage.
| mtsr wrote:
| The big difference is this doesn't run it's own instance of
| Chrome, but runs on the OS native browser.
| forgotmyoldacc wrote:
| If anyone wants to know how it works:
|
| > [leverages] WebKit on macOS, WebView2 on Windows and WebKitGTK
| on Linux.
|
| So cross-platform compatibility isn't guaranteed, unlike
| Electron.
|
| https://github.com/tauri-apps/tauri
| pjmlp wrote:
| Yes, the lazy devs path, helping Google to spread Chrome
| everywhere.
| YPPH wrote:
| Does the Chrome engine, embedded within Electron, contain any
| Chrome features which one could legitimately call into
| question (such as sync)?
|
| If not, what's wrong with it "spread[ing]" everywhere?
|
| It's hardly lazy dev work. It's a pragmatic approach to
| developing cross platform apps quickly. Apps that, it might
| be added, don't have a horrendous UI, which is common with
| other frameworks.
| niyaven wrote:
| > If not, what's wrong with it "spread[ing]" everywhere?
|
| Because then it's a monopoly. I'm taking shortcuts but
| having a single browser engine controlled by a single
| company means that you rely on that company to define what
| is tomorrow's web like.
| bredren wrote:
| Without this kind of thing happening at times, we might
| still be using Flash.
| fabianhjr wrote:
| Yeah, it had nothing to do with work on open standards
| like HTML5 and CSS3. (And WebGL for more advanced
| rendering needs) /s
| kbelder wrote:
| Electron feels to me a lot like stand-alone flash apps
| used to feel.
|
| I get that same feeling when I open an program using it;
| kind of a 'oh...' slight disappointment. I get that it
| makes sense sometimes for a developer to sacrifice
| performance and size for ease of development... but as a
| user, it feels like a loss, a sign the developer will be
| taking too many shortcuts, or that I just won't like
| their general design philosophy.
| fabiospampinato wrote:
| Arguably that's like observing that the same feature works
| differently in 2+ browsers and blaming web devs for it. It's
| the job of the browser people to make correct, or at least
| consistent, platforms.
|
| While part of being a web dev unfortunately is also dealing
| with this you can't necessarily blame web devs when Safari
| breaks IndexedDB for the nth time, or when after using ES2018
| features like regex lookarounds you discover that Safari
| still hasn't implemented them (which year are we in now,
| 2022?).
|
| You may also discover that mobile and desktop browsers work
| differently in some aspects, not everybody even has the
| resources to test every single thing in 3+ desktop browsers
| (which may require at least 1 VM already if you are not
| developing on macOS, which I think might even be illegal to
| run in a non-mac hardware, bizarrely) and 3+ mobile browsers
| (which may require at least one physical device or a macOS VM
| for the iPhone, and another physical device or another VM for
| Android, and all these VMs aren't exactly lightweight).
|
| Besides an Electron app doesn't necessarily have to run
| anywhere else, there's no point in checking compatibility
| with Gecko when your app never has to run there.
| pjmlp wrote:
| Arguably that's like observing that the same feature works
| differently in 2+ POSIX OSes and blaming devs for it. It's
| the job of the OS people to make correct, or at least
| consistent, platforms.
| silon42 wrote:
| It would be better to use Rust+Servo (no JS, or at least
| optional) IMO
| simion314 wrote:
| >(no JS, or at least optional) IMO reply
|
| At this point why not focus on some actual GUI toolokit, like
| write a Qt clone in Rust, for real world apps we don't need
| all the CSS and HTML crap, you need simple layout, GUI
| components and an option WebView you can embed in the app if
| needed. Probably there is no commercial interest to pay
| professional developers with real experience to implement
| this.
| MathCodeLove wrote:
| HTML and CSS, while not perfect, are still the best tools
| I've found to create a pleasant UI. Other libraries like Qt
| do _work_ , but it's more difficult to get things looking
| exactly how you want them to look.
| scoutt wrote:
| Qt allows the use of (sort-of) CSS for customizing
| controls.
|
| https://doc.qt.io/qt-5/stylesheet.html
| megaman821 wrote:
| HTML and CSS are probably the best tools for styling,
| layout and accessibility. Compared to other UI platforms
| though, their built-in controls are missing, limited, and
| inconsistent between browsers. See https://open-ui.org/
| for an example of what controls could be improved and
| added.
| kaba0 wrote:
| It is definitely slightly subjective, but come on. God
| damn winforms were more productive than HTML+CSS hooks
| you have to go through. In sane frameworks you have
| proper layouting (not some third party css library with
| ton of boilerplate to do something like vbox/hbox) and
| easy customizability through inheritance (eg. try to
| create a datepicker in HTML.)
| com2kid wrote:
| Hell even Swing had good layouts decades before CSS
| caught up with things.
|
| WPF has amazing layouts.
|
| CSS is irritating as hell. Even modern CSS, justify-
| content, justify-items, seriously?
|
| Flex has so many weird edge cases it is overwhelming. I
| have used flex type systems in other frameworks that
| worked 10x better, while Flexbox is way better than what
| existed before on the web, it is still and endless source
| of frustration.
|
| And yes, Winforms is 100x more productive than HTML.
| Awhile back I designed a fully functioning UI in Winforms
| to get an idea what I wanted my website to look like. I
| hadn't used Winforms in years. Took me less than a day to
| get a UI up and running with data binding to my backend
| and all the features implemented.
|
| TWO MONTHS of web dev later I had the same thing working
| in a browser.
|
| Now the browser was styled, and responsive, sure. But 2
| months vs 6 hours. The loss of productivity there is
| insane.
| simion314 wrote:
| CSS has too much old crap, how many ways you can center a
| thing? How many ways you can horizontal align some stuff?
| There should be only 1 way and that way should not have
| hacks like use negative margins.
|
| What a Qt or other similar frameworks gives you is
| consistency, all components in all apps will look and
| work the same (with the exception of customized ones).
| This means you can focus on UX and not on bad design. My
| experience is that some bad designer will force his
| opinion on the users, will force his preferred fonts,
| font sizes and font colors on the users(making text hard
| to read), will disabgle text selection for some weird
| reason, will fuck with the scrollbars because the native
| ones are ugly etc.
|
| For a working app that is not a music player you don't
| need the "power" of css, say you seen video games have a
| small Launcher/config window that hase buttons,drop
| downs, checkboxes , I noticed those use Qt or Windows
| Forms. I am also noticing that modding tools , open
| source tools (that are not GNOME) also focus on
| functionality and you will not see buttons with round
| corners, fancy fonts and animated borders.
|
| IMO Electron advantage is not his the "powerfull"css and
| html and it is that you can reuse the existing node
| ecosystem and existing web developers and the
| alternatives are also lacking for higher level languages
| (GTK is shit IMO)
| paavohtl wrote:
| > There should be only 1 way and that way should not have
| hacks like use negative margins.
|
| There is: flexbox and grid. All kinds of alignment can be
| done with basically a one-liner in both layout systems,
| without any hacks.
| simion314 wrote:
| >There is: flexbox and grid. All kinds of alignment can
| be done with basically a one-liner in both layout
| systems, without any hacks.
|
| You missed the part with "there should be ONLY 1 way". I
| know about flex and grid, this are new and thanks the
| gods we finally we have something decent (not good).
|
| Flexbox is great I wish to magically remove or magically
| fix all the code that does not use it and instead uses
| "float" or other shit.
|
| You would say "don't use the other old shit" but my point
| was that we need a GUI framework that does not have 1
| million lines of code for supporting this old stuff. If
| we really want to use HTMl a language for documents to
| write GUIs then we should make a new version that is the
| modern subset of html and css, where you ONLy have 1 way
| to do a thing (remove or limit the use of float, don't
| support all boxing models, simplify the layout rules so I
| don't have to google and find that to make something to
| work I have to set min=width=0 so the css engine follows
| a different path and does the correct thing)
| projct wrote:
| I'm curious if you've found any GUI frameworks for any
| OS, in any language, that have ripped out all their
| legacy code and/or the design tradeoffs and hacks their
| legacy code required.
| carlhjerpe wrote:
| This is obviously a different camps kind of thing, but I
| don't think you're supposed to make everything look
| exactly pixel perfect to how you want it, you're supposed
| to follow the look and feel of the OS with native
| controls and such.
|
| I understand both, I don't agree with either more than
| the other.
| austincheney wrote:
| I have written a full OS like GUI in JS proving that it can
| be tiny and memory efficient. The GUI part of the
| application is about 2k loc across two JS files plus CSS
| and includes full file system display and navigation. It's
| all vanilla JS and static DOM methods so it's as fast and
| memory efficient as the browser allows.
|
| It's amazing how fast the browser can be for this (and
| tiny) when you aren't using querySelectors, vDOM, or event
| listeners.
| oceankid wrote:
| Curious, what do you write that is 'OS like GUI' that
| doesn't require querySelectors, DOM and event handlers?
|
| How do you handle the nuances of GUI and input handling?
| austincheney wrote:
| Content is dynamically generated in response to user
| interactions. For example a user clicks a button to
| navigate to a parent directory the new directory contents
| are fetched and populated into DOM artifacts using a
| function which recognizes the returned object as a
| microservice instance.
|
| Instead of querySelectors I use things like
| getElementById, getElementsByClassName,
| getElementsByTagName, and some custom DOM navigation
| utilities I wrote for this application like getAncestor,
| getModalsByModalType, getNodesByNodeType, and so forth.
|
| You don't need any kind of framework or fancy wiring to
| work with events. You always know what you are working
| with from within the event handler, because event
| handlers receive an implicit _event_ object as their
| first argument. From that there is event.target which
| returns the element the handler is assigned to or
| event.currentTarget which returns the element the user
| interacted with that fired the event after bubbling.
|
| State management is also just as easy.
| sanxiyn wrote:
| People are doing that too. https://sixtyfps.io/ is
| basically a Qt clone in Rust, actually developed by
| previous Qt developers.
| detaro wrote:
| I don't think "basically a Qt clone" is a fair framing,
| in both directions. (sixtyfps aims to cover things Qt
| doesn't, Qt does things sixtyfps doesn't and won't for a
| long time if at all)
| seumars wrote:
| I believe the interest is there, it's just not as easy as
| it seems: https://raphlinus.github.io/rust/druid/2020/09/28
| /rust-2021....
| duped wrote:
| Because layout, rendering, and accessibility are not easy
| problems to solve and already handled by browser engines
| that come with your OS.
|
| It's more work to reinvent those wheels than bind to them.
| jackosdev wrote:
| egui is a really fantastic Rust GUI toolkit, best I've used
| in any language
| Blahah wrote:
| Tauri allows you to build apps that are pure rust - the js is
| optional and has multiple configurable integration models
| called 'patterns' that allow defining and constraining the
| engines includsd, the interfaces between them, and the
| tradeoff between binary size and distribution
| simplicity/robustness.
|
| https://tauri.studio/en/docs/usage/patterns/about-patterns
| brnt wrote:
| > WebKitGTK
|
| Is there something like WebkitQt? Guess it would use WebEngine.
| fabianhjr wrote:
| Webkit not WebEngine. ( https://webkitgtk.org/ )
| favorited wrote:
| This is a feature. It means every process doesn't have its own
| copy of Chrome.
|
| It might mean more testing for developers, but it's a benefit
| for users.
| krapp wrote:
| "cross-platform compatibility" isn't guaranteed on the web
| either, yet somehow "cross-platform compatible" websites exist.
|
| It isn't a problem that's so difficult it requires wrapping a
| 60Mb runtime around every individual app instance.
| awestroke wrote:
| Everyone is basically using Chrome or Safari nowadays - so
| WebKit. Very little incompatibilities to consider compared to
| writing something that works on different WebView
| implementations
| Semaphor wrote:
| Luckily, that is not the case. In Germany, FF still has 20%
| on Desktop and 10% total (and I wonder if those numbers are
| maybe too low, as FF blocks those trackers by default).
| gefhfffh wrote:
| That means that there are about 8 million people using
| Firefox in Germany.
|
| The world has more than 3 billion internet users
| jcelerier wrote:
| I don't understand why this relative metric matters. Past
| the size of a small city it just shouldn't matter how
| many more users the competition have. There are more
| firefox users _today_ (~200M) than there were total
| internet users in 1998 (~150M), and surely you would
| agree that it does not make sense to discard that, any
| more than it makes sense to discard, say, UK or France
| from diplomatic relationships because they have ~70M
| inhabitants while India and China account for almost 3
| billion.
| gefhfffh wrote:
| Hmm it matters because when everyone basically uses
| competition, it doesn't matter if a few people use
| something else
| roblabla wrote:
| WebKit, WebKitGTK and WebView2 are all webkit-based too
| currently. WebView2 was always chromium-based afaict, I
| think the old trident-based edge had a separate control.
|
| Also, on the web, firefox still exists.
| sanxiyn wrote:
| Sorry, I am using Firefox.
| ben-schaaf wrote:
| WebKit and Blink have many significant differences,
| especially when it comes to supporting newer features. In
| terms of incompatibilities they're about as different as
| Gecko is from Blink, if not more so.
| capableweb wrote:
| Not sure how familiar you are with the history of browser
| engines, but Blink and WebKit are definitely more similar
| than Gecko and Blink.
|
| Gecko comes from the heritage of Netscape. Blink comes
| from the chain of KHTML > WebKit WebCore. They don't
| share any points, while Blink probably wouldn't have
| existed without WebKit.
|
| But yes, today there are differences between WebKit and
| Blink.
| carlhjerpe wrote:
| "In terms of incompatibilities they're about as different
| as Gecko is from Blink, if not more so."
|
| > Not sure how familiar you are with the history of
| browser engines, but Blink and WebKit are definitely more
| similar than Gecko and Blink.
|
| I see we interpreted parent poster differently, he wasn't
| talking about the history of rendering engines, but
| rather compability with the various web specs. Since
| Chrome forked WebKit quite a long time ago now and Blink
| has been reworked quite a bit they have deviated from
| eachothers implementations. Since everyone is trying to
| follow an open spec it might be that in certain areas FF
| and Chrome implement more of the same API's than Safari,
| which doesn't have anything to do with codebase history.
|
| You might and probably will feel more comfortable in the
| WebKit codebase if you're a Blink developer or vice versa
| in comparision to Gecko, but that is if you're writing
| the engine itself and not pressing the pedals (targeting
| it).
| elpescado wrote:
| > as different as Gecko is from Blink
|
| As someone who has been playing with some web dev in
| early 2000s, that sounds funny. Gecko, WebKit and Blink
| seem very consistent to me. I remember dealing
| incompatibilities between IE6 and "standards-compliant"
| browsers (mainly Firefox/Mozilla Suite back then). And
| don't get me started on dealing with "classic" Netscape!
|
| `<layer>` tag anyone?
| FooBarWidget wrote:
| I'm not sure why downvoting is needed. What's said is true:
| on the web we already have to deal with different browsers
| and versions. It should be a fact of life for web developers.
| And things today are still infinitely better than back in the
| IE 6 days: many modern features work on all major targets.
| Why do people insist so much on engine consistency for
| "desktop web apps"?
| kitsunesoba wrote:
| I've always felt that engine inconsistencies in electron-
| alikes are a bit overblown, particularly now with the old IE-
| based webview out of the picture (modern Windows uses a
| Blink-based webview). They're all capable of the basics, and
| the greatest inconsistencies will be found in newer features.
| Stick to a slightly older well supported set of features and
| you'll be fine.
|
| There are some significant differences between engines when
| it comes to things like local file access, but that's what
| the native component of electron/tauri/etc is there for.
| schwartzworld wrote:
| Most cross compatibility issues have been resolved in
| browsers. Firefox and Chrome are pretty much at parity, Edge
| is chrome and Safari is the exception.
|
| Web views are less standardized though and require more
| finesse.
| tekknik wrote:
| In my experience it's Chrome that does weird things. I
| write for Safari and it works great in FF. Chrome and Edge
| will require some tweaking of CSS to make it look correct.
| dmitriid wrote:
| > Firefox and Chrome are pretty much at parity, Edge is
| chrome and Safari is the exception.
|
| Firefox and Safari are very much at parity. Chrome ships
| ~40-70 new "standard" APIs every month or so: https://web-
| confluence.appspot.com/#!/confluence
| fragmede wrote:
| Chrome is the new IE6, and guarantees cross platform
| compatibility everywhere it uses its own renderer though.
| (Basically !iOS.) It's a strong reason for choosing to
| Electron for your "native" app.
| pjmlp wrote:
| Nice IE reference, helping Google to spread ChromeOS is
| exactly one reason not to package Electron everywhere,
| besides the bloat to have multiple copies.
| wokwokwok wrote:
| I mean... fair, but is the 60MB runtime the issue?
|
| I really don't care if my hello world UI is 60MB _to
| download_ , I care that it consumes 1 GB of my precious ram
| to run.
|
| How is running js with a rust backend any better than running
| js with a C++ backend?
|
| I guess your "backend" is rust here, which is nice (because I
| <3 rust), but tell me this won't sit there guzzling all the
| memory it can get it's hands on for the UI?
|
| Ie. really, do you get meaningful benefits from using this
| over say, _literally_ just using
| https://github.com/webview/webview?
| hkalbasi wrote:
| Per https://github.com/Fournux/tauri-vs-electron it uses
| just 20 MB of ram on linux.
|
| Why? I guess because webkit-gtk is less ram hungry than
| blink.
| tuananh wrote:
| any idea why the memory usage difference on windows are
| very close but significantly different on linux?
| hkalbasi wrote:
| WebView2 is chromium edge. This was the reason that I
| guessed webkit-gtk uses less ram than chromium.
| tuananh wrote:
| ah, that makes sense. thanks
| WolfOliver wrote:
| To download the zipped version of
| https://www.monsterwriter.app/ it needs 100MB. If I build
| an universal file (Intel and M1) it doubles in size.
|
| I assume this to be a conversion killer. If you have to
| wait 10 min do download you loose interest in trying it
| out.
| jmondi wrote:
| 100MB in 10m is 166.7KB/s. I'm gonna go ahead and guess
| that most people have internet faster than that.
| dmingod666 wrote:
| It's got better memory stats than electron on the tests I
| saw..
| dotancohen wrote:
| > I really don't care if my hello world UI is 60MB to
| download,
|
| If you're writing Hello World for fun, then sure. But _I_
| won't be using any of your software if it's that bloated.
| I'm not going to even complain to you about my internet
| connection or hard drive space or personal preferences. If
| you are not going to respect my resources as a dev, I will
| not use your software. Just like I won't ride with a cabbie
| who curses and cuts off other drivers.
| bastardoperator wrote:
| How do you feel about video games that range hundreds of
| gigabytes?
| tekknik wrote:
| Games with hundreds of GB are using high poly models and
| high res textures. The actual code segment of the game is
| much much less. This isn't really the same.
| bannable wrote:
| Games at that size are not clocking in because of their
| models and textures. It's from use of lossless,
| uncompressed audio files, and shipping multiple language
| files.
|
| The issue is most common on games that release on
| consoles, but also for ones that want to support older
| hardware: the audio formats they use are designed to
| minimize the amount of decompression necessary for play,
| and so reduce resource requirements in exchange for
| storage space.
| dotancohen wrote:
| I don't play video games, so I have no opinion of them. I
| actually do play Kerbal Space Program, though I think
| that it is a few hundred megabytes, certainly not even a
| single gigabyte.
| bastardoperator wrote:
| 1.9 GB on disk not including expansions.
|
| https://www.gog.com/game/kerbal_space_program
| dotancohen wrote:
| In that case, I feel that I'm getting a decent experience
| for the size.
|
| Would you argue the same for a 60 MB Hello, World
| application?
| jraph wrote:
| One can hope that the code of the engine will be shared
| across apps in memory, thanks to shared libraries, and that
| the engine itself will use shared things too, by virtue of
| being distributed with the OS.
|
| ... if you happen to run other browsers and apps using this
| WebKit / libwebkitgtk / webview.
|
| and that embedded apps won't be obese frontend code with
| bazillion npm dependencies and a heavy, all too widespread
| framework, of course.
|
| Hopefully, developers turning to Tauri will have some
| sensibility to lightness.
| nine_k wrote:
| The code size is usually epsilon compared to the amounts
| that the JS heap, DOM, and JIT consume. These are not
| shareable.
| rebolek wrote:
| > I really don't care if my hello world UI is 60MB to
| download
|
| lot of people cares, they may have a slow connection, must
| pay per MB and so on.
|
| There is no reason why hello world UI should be 60MB.
| heurisko wrote:
| I can remember using 56k dialup and downloading ISOs
| around 650MB.
|
| A 60MB download would have been fine.
|
| Indeed, with the annoying habit of proprietary software
| to install "Download managers" that download the actual
| software, I would be happy for just a 60MB runtime for
| the actual program itself.
| int_19h wrote:
| I also remember using 56k dialup, and we paid per
| _minute_. A 60 Mb download would take several hours.
| pjerem wrote:
| I'm not sure you really remember. With 56k dialup,
| downloading 650MB could easily take days. Downloading 1MB
| could have taken 3 to 4 minutes.
|
| 60MB, even today, is really big when you have to download
| it while boarding a train or with poor connectivity (even
| in rich countries, just being in a metallic building is
| enough for 60MB to be painful to download.
| heurisko wrote:
| I remember leaving the computer on to download 650MB
| overnight, which used to be an ISO for an operating
| system. It was usually finished sometime the next day.
|
| And 60MB would have been a couple of hours, not bad to
| wait for some software.
|
| It wasn't prohibitive to do this.
|
| Indeed, I seem to be back at square one, as downloading a
| AAA game for me once again takes about a day.
| projct wrote:
| Add a little line noise for the average 30-70y/o house
| wiring and you get 43 hours for 33.6 or 50 hours for
| 28.8. It took running a brand new line in order for me to
| get 56k. So, the parent comment is accurate.
|
| It was absolutely prohibitive for the average person with
| a shared line, and the direct comparison to shared line
| today is a metered connection. Even in the US it can be
| as much as $30 per gigabyte which would make that 60MB
| download cost $1.80.
| liketochill wrote:
| 650,000 kb / 5 kb/s = 36 hours
| HatchedLake721 wrote:
| You download desktop apps while boarding a train?
| wokwokwok wrote:
| Yes, but this is my point.
|
| https://github.com/tauri-apps/tauri/discussions/3162
|
| > FabianLars, 3 hours ago, Collaborator
|
| > ...for example my somewhat simple app uses ~120MB
|
| > But only ~5MB is the actual tauri/rust process, the
| rest is WebView2.
|
| So, if 60MB is a large download, surely a simple app
| using _120MB of ram_ is pretty outrageous too?
|
| > There is no reason why hello world UI should be 60MB.
|
| Absolutely, but you can't have everything. Fast. Small.
| Doesn't use any memory. Easy to develop for. Free.
| Consistent cross platform behaviour.
|
| You can't have them all.
|
| So... the question isn't "is 60MB ok?"
|
| The question is: What do you care about the most? Is it
| really the download size?
|
| It's not the download size for me.
| jen20 wrote:
| I'd encourage you to rethink whether the "all" you
| describe is desirable. I couldn't care less whether an
| app is consistent across platforms - in fact I consider
| that a strict negative since apps should be consistent
| with the platform on which they are running not with
| themselves on other platforms.
| phil294 wrote:
| I don't think that "consistent" always necessarily refers
| to pixel-perfect equality. When using this term in web
| dev, most would refer to browser standards as in spacing,
| layout, JS apis, availability of native elements etc. In
| this context, consistency is rather the opposite of
| negative. I don't think anyone really cares about how
| date picker looks on Firefox vs. on Chrome.
|
| Maybe you are referring to Gtk/Qt vs. win32 etc. with
| their integrations in the operating system. I agree that
| they look and feel the best for their respective OS, but
| eventually require you maintain multiple unrelated
| codebases. It is understandable and necessary for this
| approach to die. A middle ground would be best, say, Qt
| support on all existing platforms. Or more likely,
| prettier browser defaults for standard elements like
| lists and tables, with browsers themselves respecting the
| underlying OS theme. Probably never gonna happen...
| nine_k wrote:
| While true, you pay the price to download a program once,
| but the price to run the program, every day.
| tekknik wrote:
| But you don't pay RAM usage fees.
| cozzyd wrote:
| Don't give them any ideas.
| wolframhempel wrote:
| Arguably both Slack and Spotify (and Visual Studio?) have
| reached significant scale with Electron apps - so at the
| end of the day it seems to be less of an issue for end
| consumers.
| AlexAndScripts wrote:
| VSCode is Electron, not VS.
|
| I would add Discord to that list.
| msbarnett wrote:
| Spotify is built on Chromium Embedded Framework, not
| Electron. Common misunderstanding.
| hendersoon wrote:
| Lots of things are popular, but that doesn't imply
| quality. McDonald's does not make the best hamburger in
| the world.
| usrusr wrote:
| Yeah, and large fraction of the dev appeal of Electron is
| that a concern that has haunted web development for a quarter
| of a century is completely out of the picture when you do
| Electron. You're not even concerned with possible differences
| between past, present and future versions of the engine
| because your code runs with exactly the version you bundled.
|
| Sure, if your app is just a faux-native variant of something
| that is developed for the browser anyways nothing is lost,
| but if it's an offline first application that just happens to
| use web tech for UI the difference is huge.
| dmitryminkovsky wrote:
| I guess but compatibility issues on the web, while they existe,
| are pretty discrete these days. Browser monoculture is
| exceedingly worse, both practically and from a business
| perspective, in my opinion.
| cpuguy83 wrote:
| As someone who uses Safari on Mac, I can say that
| compatibility issues are a big deal. Granted many of the
| issues are simply from sites checking for Chrome and telling
| everything else to f--- off. I've even seen a site fail to
| run on (chromium) Edge because it _really_ wanted Chrome.
| However, real compatibility issues are a thing as well.
|
| That said, I hate electron. I hate that I have to run 4-5
| instances of chrome on my machine all day long for various
| different apps instead of the developer checking that their
| stuff works across the 3 main rendering engines.
| stcredzero wrote:
| _Granted many of the issues are simply from sites checking
| for Chrome and telling everything else to f--- off._
|
| The world has circled back to the bad practices around IE
| 6! History doesn't repeat, but it sure does rhyme!
| jchw wrote:
| To be fair, I hate Safari with a passion. It took until iOS
| 15 for support for WebAssembly.initiateStreaming and
| there's still no support for WebM or Opus on iPhones.
| Curiously, on platforms where Apple doesn't mandate a
| browser engine, Safari is magically able to support codecs
| that aren't patent-encumbered...
| hlbjhblbljib wrote:
| Nobody tests on a Mac. If Apple wanted the platform to be
| supported they could make it much cheaper to test on, but
| instead they've made developer hostile moves for the last
| ten years.
| cpuguy83 wrote:
| Github actions has Mac runners at the same rate as Linux
| runners, including the free tier (though the free minutes
| burn faster, as I understand it).
| mhitza wrote:
| It's a 10x multiplier to run mac on GitHub actions
| https://docs.github.com/en/billing/managing-billing-for-
| gith...
| Hasu wrote:
| You are correct that Safari has major compatibility issues,
| but incorrect that the problem is simply that developers
| target Chrome (it happens sometimes, sure). Most things
| that work in Chrome also work in Firefox, but WebKit is ~10
| years behind both Firefox and Chrome because Apple hasn't
| invested in keeping up to date with web APIs where their
| competitors have. Hell, even Edge (before it adopted
| Chromium) was more compatible than Safari.
|
| Personally, I view Safari in 2022 the same way I viewed IE
| in 2012 - as a backwards browser holding back web
| development because the company developing it just doesn't
| care about the web. The compatibility issues aren't as bad,
| but I have to care about Safari because iOS still won't let
| any browser use anything other than WebKit, where there was
| a point where saying "Anyone choosing to use IE11 deserves
| a bad experience" made a certain amount of sense. No one
| gets a choice on their iPhone, so Apple makes things harder
| for web developers, probably because they want them all to
| be iOS app developers instead.
| kyriakos wrote:
| Safari is missing features and has its own quirks so I
| wouldn't say that.
| fabiospampinato wrote:
| I don't know about that, one data point: an ES2018 feature,
| regex lookarounds, is still not implemented in Safari. And
| the JS engine is the thing that's the most compatible across
| browsers, nowhere near the level of incompatibility of the
| rendering engine for example.
| dmitryminkovsky wrote:
| For language issues I assume using Babel, which in my
| opinion is not a big deal if you're already making an app.
|
| Render-wise, browsers are pretty uniform these days. I
| experience very few problems in this regard, and my app
| Pony runs out of the same web codebase on all platforms
| (iOS, Android, web). The worst offender is Safari, but it's
| not that bad. The potential gains from something like Tauri
| (and I plan to try Tauri for Pony desktop) far exceed the
| compatibility concerns for me (which I've already had to
| address due to web).
| nine_k wrote:
| Ignore stuff that was added to HTML, CSS, and JS for last
| 4-5 years. You'll still have a pretty solid? GUI platform,
| likely more capable and accessible than Qt or GTK or AWT.
|
| With the usual compiler / transpiler stack, you'll have a
| nice, fast-to-market, non-esoteric development environment.
| All without the need to ship 100MB binaries.
| fabiospampinato wrote:
| Sorry but requiring web devs to ignore the last 4~5 years
| of progress is just unacceptable.
|
| Not that that would fix the situation, there are still
| rendering inconsistencies between browsers when using
| stuff like margins floats and tables.
| fsloth wrote:
| "requiring web devs to ignore the last 4~5 years of
| progress is just unacceptable."
|
| But this it not for "web devs", but for general UI
| development on desktops. Given some conventions there are
| decades old 4-5 years does not sound very ancient in
| comparison. And for desktop you probably want to trade
| bleeding edge hotness for tested and tried methods
| anyway. 4-5 years on desktop is a very brief span of
| time.
| skinkestek wrote:
| Then do as I: develop in Firefox and if it works there
| (and isn't a PWA where maybe you get in trouble with
| Safari?) then it works everywhere.
|
| Less testing, less bugs. Whats not to like?
|
| Contrast to Chrome first developers who often get caught
| by cross browsers incompatibilities just like they did
| back in the days when they were IE first developers : )
| pineconewarrior wrote:
| I do this too, but still run into issues with Safari.
| Luckily, later Safari 14 versions and Safari 15 are not
| too bad.
| fabiospampinato wrote:
| Unless I'm missing something that doesn't fixes the
| issue, the problem is symmetrical, browser A is different
| than browser B, so browser B is different than browser A,
| testing in either of them doesn't guarantee a correct
| output in both of them.
| skinkestek wrote:
| Chrome - like IE before it - has a number of "features"
| that only work/ed in Chrome/IE.
|
| Writing for a standards compliant browser like Firefox
| makes your code more well defined today just as it did
| back then because you won't get away with the same
| sloppyness. (This also makes you catch and fix problems
| in early iterations over the problem instead of after QA
| calls to complain so it saves you time and context
| switching too and if you are good you might look like a
| cross browser superhero almost for free ;-)
|
| Earlier on not every basic thing was supported
| everywhere, many people here will remember the ACID
| tests. Younger devs won't remember them as we stopped
| talking about them after every browser became compliant.
| Today every mainstream browser has comprehensive test
| suites to cover everything we need from CSS I think.
| fabiospampinato wrote:
| Testing on ~~Chrome~~ Firefox would save you from
| accidentally using Chrome-only features, but that's only
| part of the problem, caniuse.com kinda works better for
| that as you get data about other browsers too.
| skinkestek wrote:
| >Testing on Chrome would save you from accidentally using
| Chrome-only features, but that's only part of the
| problem,
|
| How?
|
| > caniuse.com kinda works better for that as you get data
| about other browsers too.
|
| caniuse.com is nice but unlike using a standards
| compliant browser it requires you to be mentally alert
| and aware of it.
|
| Using a standards compliant browser means you'll see the
| result of sloppy css immediately on the screen.
| fabiospampinato wrote:
| >>Testing on Chrome would save you from accidentally
| using Chrome-only features, but that's only part of the
| problem, >How?
|
| Sorry I meant "Firefox" and "Chrome-only" there.
|
| In general though it's not like Firefox is spec compliant
| and others aren't, pretty much every browser works a
| little different in some areas. Just for the sake of
| saying something verifiable: no browser is spec compliant
| because the spec mandates a precise maximum length for
| strings and each main browser has a different, arbitrary
| (= I have the RAM, they just won't let me use it), lower
| limit on that.
| spoiler wrote:
| > Contrast to Chrome first developers who often get
| caught by cross browsers incompatibilities just like they
| did back in the days when they were IE first developers :
| )
|
| I'm not entirely sure how I feel about this statement
| (and comparison to IE). If anything, Safari is "the new
| IE" rather than Chrome.
|
| MOST (hopefully the nitpickers pick up the caps lock)
| stuff in Chrome are drafts or standards.
|
| Sure, Google pioneered/championed some of them, but
| that's kinda irrelevant if developers voted for those
| features. There's very little Chrome-specific stuff.
|
| Also, other browsers have vendor specific stuff in them
| too, yet people rarely fling shit in their direction?
|
| FWIW I also mostly use Firefox for dev because I prefer
| how some devtool features are designed/implemented.
|
| Most of my cross browser issues in FF were "brief" in the
| senses that they were bugs that got fixed eventual.
| skinkestek wrote:
| > I'm not entirely sure how I feel about this statement
| (and comparison to IE). If anything, Safari is "the new
| IE" rather than Chrome.
|
| Some people who either don't know history or willfully
| ignores it keeps claiming that Safari is the new IE, at
| one point one even made a webside out of it.
|
| Don't fall for it.
|
| Chrome is the new IE:
|
| - technologically advanced? Check!
|
| - implement a number of things without asking or waiting
| for consensus? Check!
|
| - will be abandoned as soon as they have crushed every
| competitor? Well, it is produced by the worlds most
| famous company when it comes to killing its own software.
| bananabreakfast wrote:
| I can't believe you seriously just suggested Google is
| going to abandon Chrome.
|
| Next up, Microsoft is going to abandon Word. Also,
| Facebook is going to abandon Facebook. This is why no one
| takes these conversations seriously. All vitriol, no
| substance.
| danielheath wrote:
| IE still had released, but it stopped moving forward
| after 6 because there was no longer a good reason for ms
| to invest.
|
| I doubt google would spend much on chrome if no other
| browser were popular.
| jitl wrote:
| There's plenty of weird cruft in Firefox's ~30 year old
| codebase that causes bugs and unspecified behavior. For
| example, Firefox's ContentEditable code deletes things
| "backwards" compared to all other browsers and operating
| systems (bugzilla:
| https://bugzilla.mozilla.org/show_bug.cgi?id=1735608) -
| this behavior isn't standardized in any spec, and Firefox
| is different from other browsers.
|
| There are plenty of gotchas in layout/rendering as well,
| where either the standard is under specified, or Firefox
| has some small bugs. Maybe Chrome has many-chrome only
| APIs, but the developer will always need to test in
| Chrome and iOS Safari 13 (or whatever your oldest
| supported iOS version is).
|
| Chrome and iOS are where the users are, and a good
| website or app should be usable and beautiful for
| everyone.
| nightpool wrote:
| This is absolutely not true. I wrote a simple flexbox
| layout in Firefox last year and it was _majorly_ broken
| when I tried to test it on Chrome, since Firefox and
| Chrome disagreed on how to compute "min-width" for
| inline images and other replaced content. In this case,
| my layout worked in Firefox, but Chrome was the browser
| that was following the CSS standard correctly, and my
| code was broken.
| [deleted]
| hlbjhblbljib wrote:
| The last 4-5 years of "progress" have been pretty
| unacceptable.
| nine_k wrote:
| But you won't be developing a web app, you'd be
| developing a _desktop_ app, much like with React Native.
|
| Having web developers learn C++ and Qt instead would be
| much more unacceptable.
| fabiospampinato wrote:
| By this logic requiring web devs to write ES3 code should
| be acceptable too.
|
| The platform changed significantly, improved
| significantly, in the past few years, some of these major
| advancements can't be ignored just because a browser
| doesn't implement them.
| shukantpal wrote:
| Nope, you can compile code back to whatever ECMAScript
| version you like with tools like Babel or TypeScript. So
| the devs don't even notice that they're compiling to 4-5
| year old ES.
| fabiospampinato wrote:
| That's actually not true in general, tell me how to
| compile Proxy and regex lookarounds to ES5 or whatever
| version that doesn't support these features. In fact tell
| me how to polyfill these features in any way at all.
| projct wrote:
| There's a proxy polyfill. And if you really wanted
| there's at least one pcre2 wasm build you could wrap to
| make a polyfill, lol. Barely anyone uses
| lookahead/lookbehind even in pcre, though.
| fabiospampinato wrote:
| Proxy polyfill: assuming you are referring to this [0],
| since I haven't seen anything else like this, then I'll
| paste here what the readme says:
|
| > The polyfill supports just a limited number of proxy
| 'traps'. It also works by calling seal on the object
| passed to Proxy. This means that the properties you want
| to proxy must be known at creation time.
|
| i.e. that's not a polyfill for Proxy. It's a polyfill for
| a subset of the thing, maybe that's useful for somebody,
| but it's useless for the use cases I had for Proxy so
| far.
|
| Shipping an entire regex engine with your app: right,
| that's the only way to do something like that. Not that
| that's actually the same thing though, I can't just load
| this and use lookarounds as normal, i.e. it's not a
| polyfill.
|
| For all practical purposes these features are not
| polyfillable. If your idea of a polyfill includes not
| actually polyfilling the entire thing or shipping an
| entire engine with your app then sure, anything is
| polyfillable, you could even run Java in the browser.
|
| [0]: https://github.com/GoogleChrome/proxy-polyfill
| mrtesthah wrote:
| > _Shipping an entire regex engine with your app: right,
| that 's the only way to do something like that._
|
| You mean like shipping an entire 100+ MB browser and
| rendering engine with your app?
| fabiospampinato wrote:
| Electron does not weigh 300+ MB for starter, and one
| means basically statically linking your app so that it
| ships with its own dependencies and works more
| consistently, while the other means shipping a language
| because the one you have to use is not implemented
| properly by the platform, pretty different things when
| you look at them. I'll give you though that in both cases
| you are shipping a big engine with your app, so it kinda
| sounds like the same thing.
| edflsafoiewq wrote:
| What advancements do you have in mind?
| fabiospampinato wrote:
| A lot got released in the past 4/5 years. I don't have a
| list of favorites off the top of my mind. Many useful
| things got shipped though.
| folkhack wrote:
| > Sorry but requiring web devs to ignore the last 4~5
| years of progress is just unacceptable.
|
| No it's not. "Web dev" is one of the things in my toolbox
| and I still clicked on this well-knowing it was likely
| not truly cross-platform and keeping up with bleeding-
| edge features.
|
| Truth is all development is about tradeoffs and Electron
| is one heck of a blob to ship to users... in a lot of
| applications a lighter weight artifact may be desirable
| where the trade off of the last 4-5 years of browser
| advancements may be perfectly OK.
|
| Is it unacceptable? Sure - if your application needs
| features out of the last 4-5 years of browser
| advancements... but that's not most applications. If you
| need a bleeding-edge solution that's truly cross-platform
| then Electron clearly still is your choice as you're just
| shipping around a fancied up Chromium.
| duped wrote:
| Couldn't you just package your favorite regex library and
| expose it through a JS function binding in your app?
| fabiospampinato wrote:
| That's a big "just", but yes in theory that's doable,
| however:
|
| - The performance you are going to get will be terrible
| compared to the native implementation.
|
| - Oniguruma, which I think is Ruby's engine, weighs half
| a megabyte on its own, that's comparable to the core
| bundle of the app I'm working on. That's a lot to my
| eyes.
|
| - If you need to use this engine in dependencies that
| just assume that lookarounds are available then you are
| going to need to fork every single dependency just to
| wire it with the regex engine you compiled, super messy.
| kjleitz wrote:
| Safari not supporting lookbehinds is a bigger PitA than I
| ever imagined it would be.
| fabiospampinato wrote:
| Right? And that's not the kind of feature that you can
| just polyfill back in. I don't understand how it's
| possible that that's not implemented yet.
| wolframhempel wrote:
| As a guy who started web development when IE6 was the
| dominant platform I cannot cherish "browser monoculture"
| enough.
|
| .clearfix
| runarberg wrote:
| And now we have display of "flow-root" instead of clearfix.
|
| However the only reason I ever used the clearfix hack was
| when using float to do layout. I haven't done that for ages
| (i.e. since CSS grew to include flexbox and grid). And I
| only ever use float to--well--float images inside text
| where the inside display is always inline. So I haven't
| ever seen a need for display flow-root in the wild...
| Although I'm sure it exists.
| ummonk wrote:
| And here I was hoping it would use Servo.
| dmingod666 wrote:
| Saw a comparison, Electron app size of 138MB Vs Tauri in single
| digit MB is a big difference though.
| fastball wrote:
| Sure, but Neutralino[1] already does this, it's just not
| Written in Rust(tm)
|
| [1] https://neutralino.js.org/
| cozzyd wrote:
| Does neutralino run on platforms other than a minimal SUSE?
|
| </obligatory physics joke>
| gr__or wrote:
| I'd argue Babel-ing and polyfill-ing the webcompat delta is
| wiser than shipping chromium
| fabiospampinato wrote:
| One very important thing I'd like to highlight: using one shared
| browser instance rather than N is not gonna make your apps that
| consume 1GB+ of memory suddenly consume much less than that, the
| problem for those apps is the code they run, it's not the
| language, it's not the platform, it's the badly written code, and
| Tauri doesn't change that.
| torginus wrote:
| I don't think that the Js devs are entirely to blame for this -
| Chrome literally eats memory for websites even with little to
| no Js. That's not to say that some sites are not guilty of this
| - Reddit is a travesty for example. The problem is that Chrome
| does things that make sense for a browser - like hanging on to
| a lot of cached stuff in the page history, or starting a
| separate renderer process for an iframe, but are horrible ideas
| when you are running a desktop app.
|
| Additionally, I'm pretty sure stuff like React is also horrible
| for memory usage - if you create a reference to a HTML element
| from Js, that means all the native resources that that element
| uses are subject to GC lifetime, and React, with it's shadow
| DOM does exactly that.
| parhamn wrote:
| This is a great point. I think last I measured a basic electron
| browser/webview is about ~20-36mb which is not far from an
| about:blank chrome tab. The 300mb+ memory usage you see is
| mostly the javascript from the apps themselves.
|
| Either way, I'm glad more people are in the space!
| c-smile wrote:
| According to Tauri's documentation (https://github.com/tauri-
| apps/tauri) minimal app:
| Tauri Electron Memory Consumption Linux
| 180 MB 462 MB
|
| Note Tauri is full fledged Client/Server with WebView
| (client) running in separate process with RPC between UI
| process and Rust code (Server).
|
| For the comparison:
|
| Standalone Sciter (scapp.exe,
| https://github.com/c-smile/sciter-js-sdk/tree/main/bin) takes
| ~8 MB of RAM (with minimal Cairo and GDI backends).
|
| That's 20 times less than even Tauri.
|
| WebView based solutions are not suitable for applets - small
| portable desktop applications.
| [deleted]
| mysterydip wrote:
| Back in the day people coded lightweight because it wouldn't
| run otherwise, and speed mattered in single core sub-GHz CPUs.
| We don't have that same constraint today, how do we get people
| to write more efficient code?
| burlesona wrote:
| You can't. Humans are lazy and working within constraints
| requires discipline and effort. Waste expands to fill the
| available space. The only thing that made old software
| efficient is that it wouldn't run if it wasn't efficient
| enough. And BTW there was crappy old software that made your
| computer chug back then too, it just looks better now because
| computers have gotten so much faster that apps can be a lot
| sloppier before users notice.
| rattlesnakedave wrote:
| People still write efficient code where it counts. There is a
| trade off between development velocity vs efficiency &
| reliability. In most consumer software the advantages of
| building and shipping more frequently largely outweigh saving
| on compute, memory, or disk, which is historically cheap.
| lkxijlewlf wrote:
| Get them to stop pushing developer productivity above
| everything else.
| mehdix wrote:
| Environment should be the new constraint. Inefficient apps
| collectively consume energy that otherwise would have been
| saved and therefore contribute to global warming.
| vidarh wrote:
| You look for places where a potential customer base is
| unhappy about the slowness, and see if provides an
| opportunity to compete.
|
| There's little else until/unless people see enough well
| performing applications that they start complaining or move
| away from the slow ones.
| alcover wrote:
| I think eventually energy price may sort this out.
| kitsunesoba wrote:
| Operating systems should being pointing fingers at
| egregiously heavy apps.
|
| It's not perfect but the battery menu on macOS pointing out
| apps consuming a lot of energy has inspired a good amount of
| efficiency work for macOS ports of things because users see
| it and gripe at developers about it.
|
| I would like to see that taken a step further. Something like
| the system showing a notification banner saying something to
| the effect of, "BadApp is consuming excessive amounts of
| energy. Quitting it will increase your battery life by
| approximately 3 hours and 15 minutes." I believe quantifying
| the loss that the user is suffering as a result of the
| developer's laziness will go a long way to inspire
| displeasure in users, who will then apply pressure on
| developers to fix it and opens up space for competitors who
| sell themselves with better efficiency.
| kvark wrote:
| Power optimization doesn't improve memory footprint. In
| fact, it can do the opposite and increase memory
| allocation. Think tradeoffs between memory and processing,
| e.g. caching of intermediate results.
| goodpoint wrote:
| That's a corner case. 99% of bloated software is just
| bloated.
| kitsunesoba wrote:
| Sure, but that's just a single facet of optimization, and
| I think it could be argued that just requiring developers
| to take a closer look at their usage could in many cases
| free up enough memory to cancel out intentional increases
| memory usage, meaning in many cases memory usage is
| nearly unchanged while other facets of performance are
| improved. It's still an overall win.
| fabiospampinato wrote:
| I think this is a great point. The delta in performance
| must be visible for people to even care about, and that's
| not obvious even for technical people (if something takes
| 15ms or 0.15ms to render the difference is massive, but
| probably you can't even perceive it with your eyes). Energy
| usage is a proxy for that that anybody can understand, and
| care about on a portable machine.
| staticassertion wrote:
| Who says using a ton of RAM isn't efficient? Unless your
| system OOMs what's the downside of having a bunch of
| allocated memory? Especially if it isn't even paged in.
| throw10920 wrote:
| In general, you're correct - RAM does literally nothing if
| it's not being used.
|
| Several reasons why this principle doesn't apply in this
| specific (Electron) situation:
|
| (1) Every single Electron/webtech application I've used
| hasn't _just_ consumed tons of RAM, but _also_ had a
| noticeable CPU (- > battery & performance) impact.
|
| (2) Most webtech apps I've seen have had memory consumption
| in the 200-400 MB range - which isn't a problem on my 16 GB
| desktop, but _is_ a problem on my 4 GB RAM laptop. People
| have less RAM than you think, and want to run more
| applications than just yours. Which is better: to be able
| to run Spotify, Discord, Slack, Matrix, Obsidian, your web
| browser _and_ a video game all at once, or to have to
| manually open and close applications when you OOM?
|
| That is - wasting 200 MB of RAM isn't bad if your available
| RAM is far in excess of 200 MB. For most people, it isn't.
| If Electron apps each used only 5 MB more than necessary,
| you would see virtually no complaints at all.
|
| (3) Inefficiency is making bad use of available resources.
| Not only are chat applications like Slack and Discord not
| intrinsically difficult problems, but the very existence of
| third-party clients like Ripcord[1] show that these
| applications are making _extremely_ poor use of the
| resources given.
|
| [1] https://cancel.fm/ripcord/
| Karunamon wrote:
| I do, because _your program isn 't the only thing running
| on my system_. Low free RAM means paging, and generalized
| slowdowns when something else RAM-hungry, like a game or a
| web browser, is invoked.
|
| Memory is a limited resource to be used judiciously, not an
| all-you-can-eat buffet.
| staticassertion wrote:
| Unless you're seeing other processes crash because of a
| lack of RAM this isn't an issue, your OS will page things
| in/ out, including in Chrome, based on memory pressure.
| Karunamon wrote:
| _Yes it is an issue._ Under high memory pressure, we
| start digging into swap, and at that point, the UI is
| starting to significantly chug.
|
| Worse, this often happens when there's plenty of cache to
| evict. I can and have restored a nigh-unusable desktop to
| normal operation many times with a painfully entered
| `echo 3 > /proc/sys/vm/drop_caches` from a new TTY,
| instantly resolving the pressure and giving me time to
| find and terminate the presumptuous program who thinks
| its entitled to 3/4 of system memory (usually some flavor
| of web browser or electron bloatware).
|
| Why's the kernel so jealously guarding its cache
| allocation and making the UX suck harder? Not a clue.
| Whatever performance penalty I take from nuking caches is
| far, _far_ less than from allowing free memory to fill up
| and dealing with the pathological behavior surrounding
| that.
| staticassertion wrote:
| > Under high memory pressure
|
| Just to again note that just because a program says it's
| using N MB of RAM doesn't mean that all of that RAM is
| actually paged in. Every thread you execute has an 8+MB
| stack but most of it won't get allocated for the majority
| of programs.
|
| > we start digging into swap, and at that point, the UI
| is starting to significantly chug.
|
| Only if you're constantly swapping in _and out_ of swap.
| Just putting something into swap and never retrieving it
| won 't case issues.
|
| I'd generally recommend disabling swap altogether though
| and just letting OOM take out misbehaving processes.
|
| This isn't all to say that using less memory is 'bad',
| but when people say 'oh that program is such a memory
| hog' I wonder if they might be measuring incorrectly, or
| not realizing what it's doing with that memory.
| Karunamon wrote:
| >Only if you're constantly swapping in and out of swap.
|
| Which, in the experience I just gave, is what's
| happening. System memory at some high 90s percent
| utilization, swap usage creeping up, kswapd with a ton of
| CPU usage, and worst of all, _UI chugging_. If it wasn 't
| 'actual' memory usage, why does dropping caches,
| instantly freeing up some amount of memory, restore
| responsiveness?
|
| I've tried operating swapless before, but that just means
| OOM killer kicks in even when there's cache to evict.
| That seems like a priority inversion to me - of anything
| paged in, shouldn't cache have the absolute lowest
| priority, and be the first thing to go when memory's
| needed for other things?
| staticassertion wrote:
| I agree that caches should get evicted more consistently.
| thawkins wrote:
| what's the point of having a bunch of ram sitting around
| doing nothing, I would rather have a system that had zero
| free ram but managed its address space well, so that
| changing ram usage was painless. why pay good money to
| have hardware sitting idle?.
| Karunamon wrote:
| The same reason I refill my car's gas tank _long_ before
| it hits zero; low /no resource problems range from
| irritating to catastrophic. Unused RAM isn't wasted, it's
| headroom.
| mysterydip wrote:
| The things you pointed out are the problem. On RAM-heavy
| machines you're right, it's not noticeable and can even be
| a performance boost. The problem is that same app is run on
| machines with all kinds of capacities and system loads.
| staticassertion wrote:
| Phones have gigabytes of RAM. It's a relatively niche
| situation where someone is running Chrome on < 1GB of
| RAM, which is less than what modern OS's require to begin
| with.
|
| Besides, memory usage is hard to measure. Lots of memory
| may never get paged in.
| jstummbillig wrote:
| People around here seem to really struggle with the miracle
| that is getting into soft dev from nothing and then actually
| being employable in the capitalist sense after 6 or so month.
|
| Of course it's a trade off! We enabled this miracle by
| training people that have a very focused, narrow
| understanding of not even a field but a particular tech.
| Electron is basically the perfect fit for this type of
| education. It enables someone to build something where
| previously they could build nothing. It makes getting from 0
| to 1 that much easier.
|
| From a business standpoint, it's simply smart to be wasteful
| with resources that are abundant (average computing power on
| personal devices), when it helps you save on resources that
| are not (dev time). But of course, there is much not to like
| about the side effects.
| FpUser wrote:
| >"It enables someone to build something where previously
| they could build nothing. It makes getting from 0 to 1 that
| much easier."
|
| Making GUI apps using Electron tech for front end is no
| less time consuming than doing GUI in Lazarus for example.
| But the end result is way more frugal in the latter case.
| [deleted]
| l30n4da5 wrote:
| > Making GUI apps using Electron tech for front end is no
| less time consuming than doing GUI in Lazarus for example
|
| It is a lot faster if you already know web tech stack,
| and you would have to learn Lazarus/pascal
| Spivak wrote:
| And since you have to know the web stack to exist at all
| on browsers that box is checked for basically everyone.
| Break the dominance on the DOM and JS in browsers and you
| open the door to better cross-platform toolkits.
| FpUser wrote:
| The original statement assumes that someone does not know
| nothing and has to start from scratch.
|
| In any way I am all in for the type of developers that
| know how to screw size 8 bolt into size 8 nut and the
| rest be damned. It keeps some healthy niche and
| remuneration for little more versatile types.
| goodpoint wrote:
| > employable in the capitalist sense after 6 or so month
|
| Bad developers, bloated software and technical debt go hand
| in hand and eventually bite back.
|
| The world needs more good developers, not just more
| developers.
| oscargrouch wrote:
| i've forked chrome to create something like this (meant for
| native apps in a multi-process environment) and can confirm.
|
| The multi-process architecture and the chrome platform is
| already a overkill just for a browser (in my opinion), its much
| more if for each application you have a browser process + gpu
| process + several renderers.
|
| If you have only one main process, + 1 gpu and a process for
| each application running you solve that problem, even more if
| those process are not running javascript as in my case.
| dgudkov wrote:
| Tauri looks like an alternative to WebView2 + .NET Core.
| [deleted]
| jokoon wrote:
| I have a hard time understanding why platforms like electron are
| so popular.
|
| The predictions from Gary Bernhardt seem to really be true, in
| the future everything will be javascript.
|
| I wonder if somebody actually tried to make an OS that only has a
| browser, that's what Chrome OS actually is, after all.
| didip wrote:
| It is not hard for me to understand that even though I am not a
| client-side engineer.
|
| Web tech (HTML, JS & CSS) are widely understood with millions
| of tutorial reference. On top of that, you get a cross OS build
| that looks the same everywhere.
|
| If all you are paying are just CPU and RAM, then that is a
| great tradeoff.
| pornel wrote:
| Right-click, Inspect Element.
|
| Web development tools have become fantastic UI debugging tools.
| You can inspect live running UI and tweak it in real time
| without a rebuild.
|
| CSS is very powerful, and it's relatively easy to build complex
| layouts with animations. People joke how it's impossible to
| center things, but CSS has matured beyond that (IE is dead).
| int_19h wrote:
| WPF had the equivalent of "inspect element" 10 years ago. You
| don't need HTML for that, you just need good tooling.
| SavantIdiot wrote:
| Because it saves my company 66% in development costs.
| throw10920 wrote:
| It takes 3x as much effort to write an application in Qt than
| using web technologies?
| Ostrogodsky wrote:
| Who is doing the writing?
| SavantIdiot wrote:
| I wasn't even talking about the penalty of writing a Qt
| application in C++.
|
| That's a different penalty. Qt doesn't really compare with
| what can be done with a good UX/UI dev on the team, and in
| much less time. And there are _far_ more front-end devs
| than Qt experts.
| throw10920 wrote:
| > Qt doesn't really compare with what can be done with a
| good UX/UI dev on the team
|
| Those are orthogonal. UI/UX is platform-agnostic - if
| you're only developing Electron UIs, you're not actually
| good at UI/UX.
|
| > in much less time
|
| Are you telling me that an Electron developer will be
| able to implement a system significantly faster than an
| equally-experienced Qt developer?
|
| > there are far more front-end devs than Qt experts
|
| You don't need to be an "expert" to use Qt - it has a
| relatively simple API for simple use-cases - it's not
| rocket science or distributed computing.
| SavantIdiot wrote:
| > Are you telling me that an Electron developer will be
| able to implement a system significantly faster than an
| equally-experienced Qt developer?
|
| Yes. Hands down.
|
| I'm actually saying two things: there are _far_ fewer Qt
| developers, and the learning curve is much steeper. This
| has huge impact on maintaining and improving the code. We
| started with Qt and abandoned it because it is way easier
| to bring someone new in and get them started than having
| someone climb the curve to learn Qt and C++. Plus
| spinning up new features in Qt is laughably slow compared
| to how quickly a frontend dev can do the same in
| Electron: the former takes days, the latter is
| practically interactive.
|
| It was such a clear choice to abandon Qt.
|
| I was primarily worried Electron wouldn't last long, but
| we wrote our first app with it 6 years ago and it has
| remained completely stable. The biggest dev hits have
| been in Node peripheral support as they get better, like
| BLE and serial port interfaces.
| dboreham wrote:
| Probably much more than 3x
| throw10920 wrote:
| "Probably"? On the contrary, the _incredible_ complexity
| of the JS ecosystem makes it likely _easier_ to write in
| Qt.
|
| I've had direct experience with this myself - with no
| prior Qt or webdev experience (although knowledge of how
| JS the language works), it took me only around an hour to
| figure out how to write a Qt application - but after 5
| hours (and counting) of struggling with Angular, I wasn't
| able to figure out how to use it.
| strokirk wrote:
| Can you share how you learned? I've spent a lot of time
| trying to learn how to use Qt but it's very complex and
| hard to experiment with.
| throw10920 wrote:
| Here are the reasons, bad as they might be:
|
| (1) Branding. Businesses want their app to be thoroughly
| branded, so they'd rather have a canvas where they can invent
| their own buttons than use something cross-platform native like
| Qt.
|
| (2) Hiring. Existing developer base trained on webtech. Qt is a
| C++ thing - there's a far greater hiring pool for webdevs than
| C++ devs.
|
| (3) Ignorance. Some developers don't _really_ know that Qt
| exists, or want to go through the trouble of learning it.
|
| None of these reasons benefit the user - but Electron isn't
| chosen by those who want to benefit the user in the first
| place.
| OJFord wrote:
| > I wonder if somebody actually tried to make an OS that only
| has a browser, that's what Chrome OS actually is, after all.
|
| What do you mean then, how does the hypothetical OS differ from
| ChromeOS?
| fastball wrote:
| We built our product for the web. People wanted our product as
| a desktop app. So we wrapped it in Electron and now we have 3
| desktop apps. People wanted our product as a mobile app. So we
| wrapped it in Capacitor and now we have two mobile apps.
|
| There are just two of us building this product.
| throw10920 wrote:
| What prevents you from using Qt to do almost exactly the same
| thing?
| kristiandupont wrote:
| They built their product for the web.
| iterati wrote:
| 2 developers. Also, "almost exactly" is a funny oxymoron.
| throw10920 wrote:
| Qt is just as easy for 2 devs are webtech is? (that's a
| rhetorical question - it is.)
| AtlasBarfed wrote:
| So efficient for you, but 1000x more resources everywhere it
| runs.
|
| I wonder if someone can quantify the carbon impact of
| Electron just from Slack.
| adwn wrote:
| > _So efficient for you, but 1000x more resources
| everywhere it runs._
|
| And yet, to the people who _do_ use their app on the
| desktop, this is obviously a preferable situation to _not_
| using the app - which would probably be the case had the
| developers decided against Electron.
| danieldk wrote:
| And yet, we have single indie developers writing
| multiplatform Qt [1] and macOS native [2] Slack apps.
| Last time I checked, Ripcord used 30-40MiB RAM, a small
| fraction of the official Slack client.
|
| Writing native apps (or a Qt app) would well be in reach
| of Slack. In fact, they already have native apps. E.g.
| Slack for iOS/iPadOS is native [3], just allowing M1 Mac
| users to use the iPadOS version would most likely be a
| large net improvement in resource use for those who'd
| choose to install the iPadOS version. Unfortunately, they
| disallow iPadOS installs on macOS to force people to use
| the terrible Electron version.
|
| [1] https://cancel.fm/ripcord/
|
| [2] https://shrugs.app
|
| [3] https://twitter.com/slackhq/status/931599784137363459
| ?lang=e...
| surajs wrote:
| yboris wrote:
| I chose Electron for the app I was building because it would
| make sure the app I create (1 code base with Angular) would
| perform exactly the same way on Mac, Windows, and Linux. It
| required virtually _no_ learning of anything new (just look up
| some Electron API like "minimize window") and I was done.
|
| https://videohubapp.com/ & https://github.com/whyboris/Video-
| Hub-App
|
| As a single developer, I was able to get an app out in a few
| months and have been improving it for 4 years now. I love it
| (enough to create a Renamer app too:
| https://yboris.dev/renamer/ ).
| fn-mote wrote:
| > I have a hard time understanding why platforms like electron
| are so popular.
|
| To what extent is Electron's popularity due to getting cross-
| platform availability without writing your code 3x?
|
| The advantages of a native app have to be worth the costs...
| and I'm seeing plenty of Electron apps so there's a lot of
| people making that cost-benefit tradeoff.
|
| I share the dislike for bloated apps... but every time my stuff
| takes 10 seconds to start up I think more about keeping it
| running the whole day than submitting a PR to remove cruft.
| sbarre wrote:
| Aside from the improvements to project timelines, Electron and
| similar products are popular because they improve the developer
| experience, and in 2022 the developer experience is what
| matters the most to many software companies (yes, in many cases
| ahead of the customer experience).
|
| DX directly drives engagement and retention, and good
| developers are hard to find (and keep!).
|
| And like it or not, there are more and more developers entering
| the industry with web-only training, so we have products that
| reflect the stack and tooling those developers are most
| proficient with.
| vp8989 wrote:
| It's not just the developer experience, in fact that is
| probably lower on the priority than you would think. The
| entire business IME struggles to reason about a product, in
| the details, that is logically 1 product but physically N
| products by virtue of all the different target platforms and
| codebases required.
| gitgrump wrote:
| > ... and in 2022 the developer experience is what matters
| the most to many software companies...
|
| This is what happens when you keep lowering the bar, and more
| and more developers can do less and less.
| berkes wrote:
| No, this is what happens when supply and demand are way out
| of balance.
|
| There simply aren't enough developers over the entire
| range, and certainly not enough with decades of experience,
| for all the work that can be done.
|
| Renting additional servers, etc is cheap and easy compared
| to hiring additional developers. So we all optimize for
| that.
| formerly_proven wrote:
| JS DX always seemed really quite bad whenever I looked. A
| constantly shifting landscape of frameworks and packages
| where nothing will stand for long before being eroded away.
| yayr wrote:
| let's see
|
| - language: ES / Typescript are quite established
|
| - CSS: also quite established
|
| - Frameworks: there is still a lot of innovation here, but
| also React / Vue / Angular are quite established.
|
| on that latter part I prefer the innovation. Let's just
| imagine for a while what UI would look like if we only had
| Swing (Java) or QT (C++)
| jcelerier wrote:
| > Let's just imagine for a while what UI would look like
| if we only had Swing (Java) or QT (C++)
|
| yes, Telegram looks so bad right ?
| yayr wrote:
| if you like the pricing and licensing, functionally QT
| may be for you. The web frameworks mentioned on the other
| hand are free to use for everybody and anything.
| jcelerier wrote:
| Qt is LGPL. You know what else requires you to respect
| the LGPL ? Electron becauses it is built mainly on LGPL
| components (Blink, FFMPEG to name the biggest ones). If
| you are ok with the license of Electron you are ok with
| the license of Qt.
| int_19h wrote:
| > Let's just imagine for a while what UI would look like
| if we only had Swing (Java) or QT (C++)
|
| I can easily imagine that, because that's more or less
| what we had before Electron. And it was much better,
| because apps (mostly) looked consistent across the OS,
| rather than each and every one coming up with its own
| custom UI theme.
| blub wrote:
| At least for Qt, the answer's quite simple: you'd have
| KDE and the associated apps.
|
| As for the stability of the front-end ecosystem, it
| doesn't exist. The many articles that were posted on HN
| over the years complaining about the endless quagmire of
| front-end frameworks, libraries and technologies explain
| this better than I could.
| worik wrote:
| > in 2022 the developer experience is what matters the most
| to many software companies (yes, in many cases ahead of the
| customer experience).
|
| Not working on iOS
| Chris2048 wrote:
| > Electron and similar products are popular because they
| improve the developer experience
|
| > more and more developers entering the industry with web-
| only training
|
| aren't these very different things? Is Electron popular
| because web-skill are so common, or because the dev
| experience is better - I sceptical of the latter, as I find
| JS very dependant on framework/ecosystems for compatibility.
| sbarre wrote:
| Sorry if I implied those were tightly coupled. I do think
| they are related but more loosely than perhaps I meant, and
| not exclusively.
|
| Electron improves DX for all the usually stated reasons
| (build once for many platforms, etc) but I do think there
| is a connection to the fact that a lot of developers out
| there are learning web tooling, and if a company wants to
| put out a desktop app in 2022, it's an easier (and
| therefore better for DX) path to use something like
| Electron or Tauri - where devs can use the skills they
| already have - than try to either upskill or hire a team
| that can build native apps on all your desired platforms.
| rk06 wrote:
| would you rather have three teams developing one app on three
| platforms (windows, mac, linux) or one team developing one app
| for all platforms?
|
| It makes perfect business sense to use electron. It opens paths
| which otherwise would be very costly and hence infeasible.
| azangru wrote:
| > It makes perfect business sense to use electron.
|
| In many cases, it should also make perfect business sense to
| use PWAs. I've heard Adobe has brought a significant part of
| the Photoshop and Illustrator functionality into their web
| apps.
| MontagFTB wrote:
| > I've heard Adobe has brought a significant part of the
| Photoshop and Illustrator functionality into their web
| apps.
|
| This is true. We managed to wrap a very large portion of
| the desktop code base into a "portable" library (with some
| customization at the point the library hits the OS, e.g.,
| file IO.) This library is compiled specifically for the OS
| it's going to run on (iOS, Web) to give us the best
| performance we can muster.
|
| The UI for each implementation is bespoke. This lets us
| build native interactions on the platforms we ship to,
| giving the end user the best look-and-feel for the platform
| they're on. The flip side to this is development cost and
| time. In the long run, we believe it is worth it.
|
| Rewriting Photoshop in Electron would have been infeasible
| and the performance hit a non-starter. The path we've taken
| has some trade offs to it, but is the right one given the
| legacy tech we have and what we want to do with it.
| maxerickson wrote:
| There's a terrible performance regression in Illustrator
| 26 when working with files with many objects. Works fine
| in 25, UI freezes for several seconds in 26.
|
| Windows 10, pulling in part of an engineering drawing
| from a PDF (so many thousands of objects).
| MontagFTB wrote:
| I'm on the Photoshop team, so cannot speak to AI issues.
| Have you tried filing a report here?
| https://community.adobe.com/t5/illustrator/ct-p/ct-
| illustrat...
| thomascgalvin wrote:
| > would you rather have three teams developing one app on
| three platforms (windows, mac, linux) or one team developing
| one app for all platforms?
|
| I would rather have one team developing a cross-platform
| application in a language that isn't Javascript.
| pitaj wrote:
| We'd love to. What do you suggest we use? Java swing? C
| Gtk? C++ Qt? All of those often look ugly and are harder to
| use.
| purplerabbit wrote:
| Given that there's no other language that works cross-
| platform with as little jank as JS, I don't think that
| distaste is adequate reason to avoid using it
| worik wrote:
| HTML/CSS/WASM??
|
| Would that work?
|
| I am not a front end kind of developer, I am a "plumber".
| So it is a genuine question.
| ReleaseCandidat wrote:
| > I would rather have one team developing a cross-platform
| application in a language that isn't Javascript.
|
| So, use one of the many languages that compile to JS.
| Starting with TypeScript. Or (alphabetically)
| ClojureScript, Elm, PureScript, or Rescript.
| egeozcan wrote:
| Why do you care which language software is developed in?
|
| Should I not use anything that uses ML if I dislike python?
| berkes wrote:
| While I agree that maintaining one codebase is preferable,
| the 'teams' part is a bit off.
|
| No-one wants 'three teams building one product' which is why
| it almost always is far better to have one team with android,
| iOS, web and desktop mixed. Obviously if their mixed
| erpertises are around one codebase, that is even better.
| lijogdfljk wrote:
| > I have a hard time understanding why platforms like electron
| are so popular.
|
| For an example. I'm writing a FOSS app mainly for myself, but i
| am publishing it for everyone of course. I want to support
| Browsers, but also "Apps" in OSs. I'm on Linux, MacOS, Windows
| and iOS every day.
|
| I do not, by a large margin, have the time to write my
| application in 3 or 4 different native UI toolkits.
| Furthermore, my application has a lot of text editing and
| rendering functionality, one i'd have to then reinvent in
| various UI toolkits, unless i used something that crossed all
| OSs above perfectly. Finally, my app has WASM plugins, similar
| to Obsidian.md, to allow the user to easily extend the
| application.
|
| All together i will not, by a large margin, use anything
| Native. I barely have enough time _(don't, honestly lol)_ to
| write the app once - let alone supporting all the above
| platforms.
|
| I'm targeting the web.
|
| As an aside, i'm writing this in 100% Rust lol. No JS, because
| i prefer Rust.
| scottwitcher83 wrote:
| fiatjaf wrote:
| When are we going to get back truly native apps?
|
| Flutter Desktop works great, and there are a bunch of nice GUI
| libraries for Rust, also some new developments for the JRE.
| krapp wrote:
| Probably never. The web is becoming, if it hasn't already
| become, the universal platform for application development and
| distribution, and javascript the One True programming language.
| Every holdout will eventually and inevitably be assimilated,
| either transpiled into javascript or compiled into WebAssembly.
|
| And it's partly the fault of the native programming community.
| It should be as easy to write a native, cross-platform
| application as it is to write html, css and javascript. Native
| developers should recognize what works about the web paradigm
| and adapt to it. There should be forks of these technologies
| specifically designed for native application development rather
| than documents. But that never happened, GUI development is
| still basically programming and it still sucks and now the
| train has left the station. The only relevant innovation likely
| to happen now will be iterating on the web-app model.
|
| I mean, I'm looking at the layout tutorial for Flutter now[0].
| It's nesting function calls and you have to update a yaml file
| to include an image, whereas with HTML it's a simple table or
| maybe grid and the img tag. This example for Rust[1] is
| ridiculously verbose and noisy compared to the web stack. All
| GUI programming is. Meanwhile I can write a fully functioning
| website with nothing but a text editor. No need to install a
| language runtime, package manager or IDE, no need to learn a
| company specific workflow or follow a style guide. No need to
| memorize a new set of quirky verbs for a CLI.
|
| I don't even _like_ the web-app paradigm, but I can totally
| understand why it won.
|
| [0]https://docs.flutter.dev/development/ui/layout/tutorial
|
| [1]https://github.com/gabdube/native-windows-gui
| fiatjaf wrote:
| Has the web won on mobile? No. In fact there was a time in
| which Cordova-like apps were getting very popular, but react-
| native and then Flutter, Kotlin and Swift have ended that. Or
| at least that's my impression. react-native is almost like
| the web still though, but the fact that people are doing
| react-native and not Cordova must mean something.
|
| Meanwhile, 10 years ago the only ways to do desktop native
| apps were the old -- very good, but old, with that old feel
| -- technologies like GTK and so on. Now there are these other
| things I cited above, and more! It's a renaissance.
| asimpletune wrote:
| Can you explain more the part about native apps being hard to
| make? I mean, I can open Xcode, start a new project, hit run,
| and there's an app ready to go, with a simulator and
| everything. It has API's that allow safe access to OS-level
| resources. It has powerful multi-threading, built-in views
| that I can reuse (like collections), stack based browsing is
| native, etc... Also, the client is not broken by default
| (I.e. client apps in the browser are by default spyware, at a
| technical level).
|
| All the weird tooling that exists around actually getting
| html + js + css to work like an app is an indication to the
| contrary. The constantly evolving ecosystems is an indication
| of reaching stability, not having yet achieved it.
|
| I will say though that targeting different platforms is an
| issue, which is not the same thing as your claim. Yes,
| targeting all platforms is hard, but I don't think any one
| native app ecosystem is really any harder than web.
|
| I do think there's a lot of survivor bias from people whose
| job it is to build apps with web technologies.
|
| And to your point that "it won". I don't think anyone, even
| lay-people, like electron-based apps. It's just what they
| have to use because there is an infinite amount of web
| developers. However, I feel that it's a bit premature to call
| call something that's ubiquitous that everyone hates as
| "winning".
|
| Also, the most used software as a matter of time on task
| would probably be excel, email clients, and web browsers. All
| of these are built natively. So with the exception of slack,
| and taking a broad view of the road that lies ahead, most of
| the stuff that's built on electron is sort of vapor in the
| grand scheme of things.
|
| I think we can actually expect to see more and more native
| apps, due to power consumption requirements. I stopped using
| Chrome years ago due to its aggressive power/memory
| consumption and never actually really looked back.
|
| Any way, sorry for the unnecessarily long response, but
| seriously what you're saying is very hyperbolic. We are
| literally just at the beginning of the absolute beginning in
| terms of what technology is going to look like. Things will
| be very different in 5 years and super different in 10-20
| years.
| shaolinspirit wrote:
| from my experience the struggle with making native apps is
| in implementing all of the services that are in browser
| environment out-of-box manually. image caching, websocket
| handling etc.
|
| which enables more fine tuning for the end product, where
| in html you can put img tag and that little thing will
| fetch the image for you, store it somewhere and render in
| accordance with some layout structure.
|
| in mobile dev you need to do more so to say, low level
| stuff in comparison with browser.
| asimpletune wrote:
| Well they're definitely very different technologies too,
| and the things that you mention, in that specific
| context, are what the web was actually designed to do
| well. Basically, the web is purpose built for digital
| publishing. This is really good for content, as it allows
| the publishers to update the content and leave the client
| relatively the same.
|
| Your example of an <img> is a perfect one. Yes, if all
| the images are going to be loaded remotely, I would say
| this is a client/server messaging paradigm, and one that
| excels in digital publishing.
|
| However, if you're going to build an app (which is what
| we're talking about), then you are probably going to want
| to store the app's images in one giant executable...
| which means all the caching and everything you want is
| going to be extremely fast, probably much faster than
| what the browser will do for the same task.
|
| If you really want to understand what I mean, just ask
| yourself "what is the life-cycle of a web app", e.g. what
| is the "main" method? Are there clearly defined
| transitions between views? What is the execution/memory
| model?
|
| When you answer those questions you realize that the
| browser was built to display pages of text and images,
| loaded by a server. From there it should be clear why
| people don't think there's any comparison when it comes
| to building apps, because one was designed for it and the
| other inherited that responsibility.
|
| I'm not saying web development as a paradigm isn't
| popular, but I'm arguing against it being easier than
| native because it's not really. However, if you wanted to
| add like a digital publishing component to an app, I'd
| just embed it into a web view, which is the best
| technical choice.
| fiatjaf wrote:
| I agree.
|
| Writing native apps is very easy once you get mildly used
| to any framework for writing native apps.
|
| The "web" is just another framework, a very popular one,
| but also one that is very bloated and hard-to-use.
| thehappypm wrote:
| For one, you need Xcode, which means you need specific
| hardware.
| fiatjaf wrote:
| You need specific hardware to be able to publish Electron
| apps for Mac too.
| aniforprez wrote:
| With electron I can actually just build the apps for the
| other platforms and then do specific platform level
| changes (if required) for Mac. For native apps, I
| literally cannot even begin to code anything unless I
| have access to hardware
| fiatjaf wrote:
| This is not true, most languages are multiplatform. And
| there are dozen of multiplatform native GUI frameworks
| out there. Flutter is one of them, the other ones I cited
| too.
| kaba0 wrote:
| With all due respect, I think the web's layouting (or lack
| of) is the most complicated out of any framework I have ever
| used (including qt, swing, javafx, winforms, wpf). I think
| the great majority of web devs would have trouble recreating
| something like bulma (regarding layouting) even without
| responsiveness -- I definitely would have quite a bit of
| trouble doing that.
|
| So if anything, we are just accustomed to the web's way and
| other (saner) approaches look stranger for some reason (even
| though with some insane complexity js frameworks come back
| and mimic the two decade old frameworks here and there)
| fiatjaf wrote:
| I agree with that. Doing layouts with HTML and CSS is too
| open, flexible, which means you have to do everything
| yourself from scratch every single time.
|
| Another thing you have to do from scratch is the eye candy
| aspect of every webapp. I guess the web is more flexible in
| the sense that you can do anything you want UI-wise, but
| honestly, how much time and work and money is spent on
| making pretty webapps? How much more productive our society
| would be if the useful tools were just tools and not
| masterpieces of design?
| kaba0 wrote:
| And my biggest gripe is that the product you would get
| out of the aforementioned frameworks without _any_ design
| would look.. ok, usable. But even if you just want a
| website that is not just a bunch of text (though even
| _that_ require some css to make it readable smh) you have
| to get quite invested into CSS, or at least bring in a
| css lib that provides you with some basic design.
| Otherwise it will look like it is the remains of some
| website from ARPANET.
| lvass wrote:
| I've done pure markup + classless CSS a few times. It's
| nice, readable and really the way I think the web should
| look like. But then you realize you don't get paid for
| doing good things on the web. I couldn't handle this
| feeling and just quit front-end work entirely except for
| pages I own.
| Chris2048 wrote:
| But isn't this the danger of evaluating something via simple
| example?
|
| You can make fine websites with just a text editor (although
| I'd argue how easy CSS is to use) but as soon as it needs to
| be an _app_ you need JS code, and suddenly the difference isn
| 't so great. Infact, I'd probably find a traditional prog-
| lang easier to use in that case.
|
| I think the _real_ advantage of JS is the robustness of its
| sandbox & permission system, that's what really needs
| reproducing.
| thejosh wrote:
| It's always going to be a pain.
|
| The best thing about electron is that it brings apps that
| otherwise would be locked to Windows (and probably Mac) to
| Linux.
| ReleaseCandidat wrote:
| > When are we going to get back truly native apps?
|
| When the browser is the OS - or the other way around.
| The_rationalist wrote:
| the fact it use Apple internet explorer make it a dead on
| arrival. One does not needs more than three braincells to
| understand the the true electron successor will simply have an
| api that enable a range of allowed chromium versions installed
| natively. If not found then it will transparently auto install
| the desired version, at the same time making this version
| available for other apps.
| razetime wrote:
| is this what the new Zed editor is planning on using?
| polycaster wrote:
| Is "written in Rust" a registered trademark already?
| anhanhanh wrote:
| It's the hottest feature nowadays
| Shadonototra wrote:
| they promote "written in Rust" more than the product
|
| that is the only thing i remember of the countless of projects
| advertised on hackernews, "written in Rust", they still haven't
| got it, the language is the least important piece of a product
| [deleted]
| Emanation wrote:
| They call it rust, because everything written in it becomes
| derelict after 180days of its first 3 'written in rust' posts
| devoutsalsa wrote:
| That's mostly because the get sick of waiting for it to
| finish compiling.
| maxbond wrote:
| Let's put this meme to bed. Tauri has been developed for two
| years now. People don't just write Rust because it's trendy.
| If you want to throw stones at Rust, there are many more
| substantial criticisms to make.
|
| Our compilation times are long.
|
| Those sweet, ergonomic macro interfaces are only possible
| because of proc-macro dark magic that tends to be very
| verbose and special case-y.
|
| There's no spec.
|
| Unsafe is overused.
|
| Et cetera.
| Fiahil wrote:
| And where are GATs ?
|
| (See also: https://blog.rust-lang.org/2021/08/03/GATs-
| stabilization-pus...)
| StevePerkins wrote:
| I don't think the criticism is of Tauri. As far as I can
| tell from their website, THEY aren't promoting THEMSELVES
| on the basis of their implementation language being the #1
| feature.
|
| I think the criticism/meme is directed more at overly
| enthusiastic fans of Rust. Even if a project doesn't
| promote itself as _" Written in Rust!"_, that's how it gets
| promoted online by the fanboys. It IS a substantial
| criticism, as generally they are not doing the credibility
| of these projects any favors.
| kybernetyk wrote:
| >People don't just write Rust because it's trendy.
|
| [Citation needed]. Because when your unique selling point
| is "it's like $otherproduct but written in $language" then
| well ...
| bocytron wrote:
| Here's your citation:
| https://insights.stackoverflow.com/survey/2020#most-
| loved-dr...
|
| Rust is #1 loved language, almost 20 points above the
| second one.
| goodpoint wrote:
| I can't imagine a better definition of trendy and hyped
| up than "loved on stack overflow".
| saghm wrote:
| Six years in a row is more than just a fleeting thing;
| obviously we have no way to know for sure what will
| happen in the next few years, but it seems likely that
| Rust isn't going anywhere anytime soon.
| Lendal wrote:
| I don't do anything because it's trendy and I don't use
| Stack Overflow, but I have used Rust in a project. Its
| popularity with me is 100% merit-based. In fact, the
| project failed only because of management not
| understanding its value and me being unable to
| communicate to them why Rust is superior.
|
| The language ultimately chosen for the project ended up
| being 100% a political contest, and that language was not
| Rust.
| rileyphone wrote:
| Or maybe people just like working with it? Trend and hype
| bring people to it, sure, but that doesn't take away from
| the fact that it's an incredibly economic language that's
| also fast.
| kybernetyk wrote:
| Reminds me kinda of the Haskell hype a few years back.
| maxbond wrote:
| Tauri's pitch is something like, "Electron, but lighter
| weight and more secure," not "written in Rust." If you're
| skeptical of the value in that, hey, so am I.
|
| I'll cite my own experience:
|
| I learned Rust because I needed a modern systems language
| in my toolbox. I specifically wanted something that could
| be used to write firmware. So I chose Rust over
| alternatives like Go or D, because I couldn't tolerate a
| garbage collector with those requirements. Trendiness had
| nothing to do with it; in fact, I was hesitant to pick it
| up because I was worried it wouldn't have staying power.
| (Having taken the plunge, I have no regrets.)
| mikkelam wrote:
| How do you know if software is written in Rust? Don't worry,
| the developer will tell you
| [deleted]
| sanjayio wrote:
| Maybe I'm reading between words in this thread too much but
| sounds like there's a bit of hating. I welcome our Rust
| (hybrid) apps, sounds like a net positive for software.
| yedf wrote:
| good question
| badrabbit wrote:
| Is this similar to wails for golang? Whatever happened to Servo,
| I was hoping for it to compete with webview
| rileyphone wrote:
| For some practical examples: https://tauri.studio/en/showcase/ In
| particular I'm looking at https://github.com/kimlimjustin/xplorer
| WolfOliver wrote:
| I'm using electron for https://www.monsterwriter.app/ and i'm
| looking for a lightweight alternative since a while.
|
| This seems to be a good fit. I guess when you can reduce the api
| calls to bindings (accessing filesystem, network, etc.) cross
| platform compatibility should not be a problem.
| jhgb wrote:
| Have you tried Sciter?
| WolfOliver wrote:
| I do not really understand the lisence of this. In the repo
| it says its open source but on the website they ask for
| money?
| jhgb wrote:
| Sciter currently isn't FLOSS, but you're free to use its
| dynamically loaded binary distributions.
| c-smile wrote:
| Sciter SDK (https://github.com/c-smile/sciter-js-sdk) is
| OpenSource/BSD
|
| But Sciter Engine itself (https://sciter.com) is not OS -
| its sources are available to customers only. I tried to
| make it Open Source (
| https://www.kickstarter.com/projects/c-smile/open-source-
| sci... ) but not too much interest for that.
| nisegami wrote:
| As I understand, stuff like this is typically called
| "source available" rather than "open source".
| WolfOliver wrote:
| no, but looks like it natively builds for m1 :)
| c-smile wrote:
| That's correct.
|
| Sciter supports ARM and M1 targets natively: Windows, MacOS
| and Linux.
|
| As also H/W rendering with backends: DirectX, OpenGL,
| Vulkan(coming) and Metal (coming).
| WolfOliver wrote:
| I would be curious if anybody onboarded an Tauri application
| into the Mac App Store and if it builds for M1?
| twarge wrote:
| It cheerfully builds and runs on M1.
| EugeneOZ wrote:
| No: https://github.com/tauri-apps/tauri/issues/2421
|
| https://github.com/tauri-apps/tauri/issues/3088
| Narretz wrote:
| I wonder if the processing / size overhead of Chromium / Node
| could be reduced by making both more modular? I.e. compiling only
| the features you need. But I guess Chromium isn't built for that.
| AndrewDucker wrote:
| Lots of their roadmap for 2021 is still undone. Something be to
| worry about?
| capableweb wrote:
| Is there any company/project that made and published their 2021
| in the beginning of the year, and successfully completed all
| the tasks verbatim in the end of the year? My guess is that the
| number of companies/project who completed everything is close
| to 0.
| mkl wrote:
| Most organisations would have updated the roadmap when
| obstacles arose, so it does seem a bit strange.
| dagurp wrote:
| The repository seems very active so I wouldn't worry too much
| Hamuko wrote:
| Probably not worth worrying, but I also wouldn't expect to
| download Tauri-powered apps anytime soon.
| OJFord wrote:
| They had a feature-freeze for a security audit, I'd _guess_
| that 's a big contributor, and also that possibly there's a
| bunch of unmerged progress as a result.
| flohofwoe wrote:
| Here's a similar, older and slightly less hipster project for Go,
| C, C++ (and more languages via C-API bindings):
|
| https://github.com/webview/webview
|
| ...I wouldn't go as far as calling a simple WebView widget
| wrapper an "Electron alternative" though.
| Per_Bothner wrote:
| For DomTerm (https://bothner.org) I've used both
| webview/webview and wry (on Linux only) - and both are usable.
| The main problem with webview is that it is semi-abandoned
| (last checkin was in March) and the features set is pretty
| minimal. Wry is actively developed and has more features.
| However, the wry-based executable is quite a bit bigger than
| the webview-based one. And of course leaning to use Rust is an
| issue.
| dolmen wrote:
| According to the About page of Tauri, the Tauri team is
| maintaining the Rust bindings of Webview.
|
| Source: https://tauri.studio/en/docs/about/intro#polyglots-not-
| silos
| hackerlytest wrote:
| gspr wrote:
| Aaand still bundling what amounts to an entire web browser just
| to do what one has always been able do in Qt/GTK/whateverTK. Sad.
| roblabla wrote:
| It doesn't bundle it though, it uses the one that comes by
| default on the OS. Which is already a huge improvement, because
| it should, in theory, be able to share resources across
| different apps (e.g. the DLL should only be loaded once in
| physical memory, etc...).
| gspr wrote:
| Ah, good point! Thanks for the clarification.
| danuker wrote:
| Why do people use such a tool? I did not enjoy Electron due to
| its sluggishness, and I believe that it is a strictly Pareto-
| inferior solution:
|
| * Creating a web app has the same UI performance, but does not
| require you to download and update.
|
| * Creating a native app has the same installation and update
| requirements, but allows much better UI performance.
| pygy_ wrote:
| Because sometimes you want a desktop app right now and are most
| productive with Web technologies.
| Icathian wrote:
| I feel you've answered your own question. If you want to make a
| single app that can be web or offline, and cross-platform,
| Electron and friends allow you to do that. It's a trade-off of
| dev effort for user experience, and as much as many devs hate
| that philosophy it allows many things to exist that otherwise
| would not be worth the effort.
| jaggirs wrote:
| Because you can use the same code for both interfaces.
| sdeframond wrote:
| I believe it is because it is easier to find developpers
| familiar with the Web than with any other cross platform
| toolkit.
|
| Put another way, it is easier for a web developer to get
| started with electron than to learn a new language.
| ss108 wrote:
| Because some of us have to build things which, for biz/customer
| reasons, have to be desktop apps, but we, as devs, are more
| familiar with web technologies/there are more web libs out
| there.
| AnIdiotOnTheNet wrote:
| There is a moderate demand for local desktop applications, but
| there is a very large supply of Web developers. Solution: by
| bundling an entire web browser with your application you can
| have web developers making 'desktop' interfaces.
| munro wrote:
| I used this a bit, it was really great. Writing a Rust backend &
| exposing it to TypeScript was really slick!
|
| There was one issue I ran into that made me think about jumping
| to Electron mid project, but I can't remember what it was now,
| but I think it was something like making my app bleed the entire
| MacOS window while still being moveable.
|
| The other downside is you're going to be tempted to go down the
| rabbit hole and do everything in Rust. [1]
|
| [1] https://github.com/Submersible/sycamore-mac
| outworlder wrote:
| > The other downside is you're going to be tempted to go down
| the rabbit hole and do everything in Rust.
|
| Downside? :)
| rileyphone wrote:
| Thanks, I came to this thread to find personal anecdotes about
| using it but of course it's just hacker news hackernewsing
| about electron and what have you. I think I'm going to start my
| project with Tauri+Svelte and see how that feels.
| Simplicitas wrote:
| Rust and Electron haters can do all the hating within this one
| post here.
| SavantIdiot wrote:
| Drake turning away: ElectronJS 0.06GB app
|
| Drake approving: Any modern game requiring 100GB of content
| mysterydip wrote:
| I'd love to see some electron apps that use 60MB of RAM. Can
| you share some examples?
| steveklabnik wrote:
| Right now, the various Electron apps I have running:
|
| 1Password, 155mb
|
| Discord, 441mb
|
| Element: 38.7mb
|
| Signal: 91mb
|
| Slack: 46.2mb
|
| A few higher but a couple that are lower...
| danieldk wrote:
| How are you measuring this? Slack on my Mac is 325 MiB on
| disk (probably because it is a universal binary). A
| freshly-started Slack uses 461MiB RAM for all it's
| processes (usually getting worse when it has been running
| for a while).
| xanaxagoras wrote:
| Same, 473.4mb right now for 4 processes. Also slack is
| the only passably "good" electron app I've ever used.
| throw10920 wrote:
| Have you tried Obisdian(.md)? It seems relatively speedy
| and low-RAM for an Electron app ("only" ~150 MB without
| plugins).
| xanaxagoras wrote:
| I haven't, I've actually been curious about this app
| though. I wasn't sure how easy it would be to use it
| while retaining all ownership of my data. I'm not
| interested in third parties hanging onto that, nor in
| software subscriptions (their "Sync" offering). I'd be
| happy to pay for the Catalyst tier if it's something I
| end up using, I'll check it out and see how much effort
| it is to integrate with Nextcloud. I use Joplin now, it's
| OK, hard to complain for the price but not my favorite.
| mtrpcic wrote:
| You retain total ownership of your data with Obsidian.
| It's basically a tool to view a directory of markdown
| files and their connections between one another. I just
| track mine via git and push it to my remote whenever I
| want to back things up.
| strokirk wrote:
| Obsidian is pretty sluggish on my computer, especially
| when scrolling even short documents. But that's probably
| possible to improve in the future and no fault of
| Electron. As a comparison, VS Code is super snappy even
| on very large documents.
| dylan604 wrote:
| Does it improve things to have animGIFs disabled?
| steveklabnik wrote:
| I'm on Windows, this is what Task Manager is showing.
| IIRC that means this is the physical memory being used.
|
| Some time later, some of these numbers have changed a
| bunch. I'm on a desktop so it's always on. Element has
| climbed up to 800mb of usage. Signal's dropped to 44mb. I
| closed Slack after posting that comment. Discord's about
| the same. I now have VS: Code open, it's taking up 626
| mb.
| dylan604 wrote:
| The meme is bad, but seeing it as text is even worse.
| AnIdiotOnTheNet wrote:
| Modern games have a shit-ton of assets in high quality. That
| takes up significant space no matter how you deal with it.
|
| Electron generally isn't doing anything more interesting than
| what we did on Win98 with 8MB of ram for the entire system.
| sanjayio wrote:
| What a great idea. I don't understand the hate for either at
| all. They're tools for a job.
| ReleaseCandidat wrote:
| Is there a comparison somewhere (not the one in the GitHub
| README) which features of Electron are missing in Tauri?
| [deleted]
| yayr wrote:
| Is there still an easy way to use node.js with Tauri? I'd
| appreciate an easy to use cross-platform tool on the backend. Or
| is it better to build the backend features needed (e.g. file
| access, config management, network etc.) fully in rust?
| Aeolun wrote:
| If you do that, wouldn't it be NW.js?
| yayr wrote:
| that seems to use Chromium on the frontend and not the native
| webviews
| diimdeep wrote:
| Imagine trying to use app built with this in five to ten years
| that not recently updated or maintained, very scary.
| Xevi wrote:
| Care to elaborate why that would be more problematic than any
| other app that hasn't been updated or maintained in that period
| of time?
| oscargrouch wrote:
| Not the op but, giving this rely in whatever is on the host
| OS, the DLL's on the host OS will evolve changing its
| interface or even not ship anymore while with applications
| that rely the bare minimum like electron this is not a issue.
| msie wrote:
| I really miss the days where many things were made from scratch
| like operating systems and compilers. Nowadays it's something
| built on Linux, Android or Chrome.
| rattlesnakedave wrote:
| nkrisc wrote:
| The project is horrible because one of the devs said something
| that wasn't nice? Are you saying the project is horrible on its
| technical merits, or you just don't like the developer's
| response to someone?
| [deleted]
| [deleted]
| rattlesnakedave wrote:
| Yeah, you're right. I just edited before I saw this. Likely
| not horrible, just doesn't work, and not friendly to new
| users.
| tomrod wrote:
| Sounds like a frustrated open source maintainer who has had to
| handhold users and perhaps isn't terribly good at it.
|
| Does that speak to technical competence of the project? Not
| sure. This seems pretty mild compared to Linus Torvalds'
| infamous excoriations.
|
| That said, I would hope the maintainers and devs would spend
| time reviewing issues to become familiar with the feedback, at
| a minimum.
|
| I for one want a faster Electron, and Rust sounds like a great
| way to get there.
| rattlesnakedave wrote:
| Re: Linus, at least the linux kernel works.
|
| More seriously, you're correct. See the new edit. Likely a
| good project, just doesn't work well on M1 AFAIK, and doesn't
| seem super friendly.
| tomrod wrote:
| We can all use more compassion and empathy. Be at peace,
| and hopefully the developer(s) can correct course on their
| principles of engagement.
| zozbot234 wrote:
| _> This is a really horrible project and should be avoided
| IMO._
|
| I'm glad to see that you've retracted this, but note per HN
| Commenting Guidelines: "Please don't post shallow dismissals,
| especially of other people's work. A good critical comment
| teaches us something."
| roflc0ptic wrote:
| "Sorry if I was rude but it was intentional... if you fcking
| people would read..."
|
| I don't know if this is a reason to embargo a project in its
| entire (is this person in charge? What do the other devs think
| of this behavior?), but jeez, that is unpleasant.
| rattlesnakedave wrote:
| I agree the one interaction is not enough to embargo the
| whole project. If it works for you, great! I even find the
| work they're doing with rust technically interesting.
| However, the damn thing just not working AND that interaction
| (not me in screenshot) really put me over the edge after a
| night of trying and failing to get my app to build + run.
| egeozcan wrote:
| For starters, I'd never introduce a project with such people
| exposed to the community in my company. We always get paid
| support when available but humans sometimes don't read and
| they do ask stupid questions, and such answers can get some
| people responsible with the choice in big trouble, or at the
| very least, it forces us to drop it for an alternative.
|
| I'd expect them to have some sort of code of conduct and
| remain compliant to it.
| schickling wrote:
| Hi folks, I'm the user from the screenshot above (thanks for
| sharing this btw).
|
| I have to say, this was a quite unpleasant and unwelcoming
| interaction as my question was genuine and I indeed did do some
| extensive research before asking this question in Discord.
|
| As a devtools founder myself (co-founded www.prisma.io) I
| highly value welcoming and helpful communities and offered my
| help to the people behind the Tauri project to turn it into a
| more welcoming community. I hope they are open to it since I
| actually really enjoy using Tauri as a project.
| WolfOliver wrote:
| Are you still using tauri?
| schickling wrote:
| Yes and besides this mentioned M1 problem, it's been really
| great to use. I think Tauri has a lot of potential!
| [deleted]
| nim2020 wrote:
| Hi Schickling.
|
| Denjell here from the founding team of Tauri. Thanks for
| reaching out directly, and I just wanted to state for the HN
| record, that we are going to be having a board discussion
| surrounding the unpleasant event raised here, and will make a
| public statement very soon.
|
| That said, on a personal note, I am quite sorry this
| happened. We do support and uphold our Code of Conduct, and
| this is not an appropriate response and the community tone we
| want to nurture.
| schickling wrote:
| I'm excited to hear you're looking into this and take it
| serious. I think this is a great opportunity to for the
| Tauri community to become a more welcoming and inclusive
| place. Happy to help!
| marcosdumay wrote:
| That is certainly rude.
|
| But the contents aren't very problematic. This is one person
| tired of repeating himself in a chat.
|
| The issues up there have a much more reasonable discussion.
|
| I wouldn't embargo the project due to it, but it's worth
| looking if they have a better channel than the discord one.
| Anyway, the Mac isn't a good environment for webviewers (notice
| that there are other projects with this same known bug).
| burlesona wrote:
| This is a reason why discord is not good as a "project
| discussion hub." Make most of your knowledge sharing ephemeral
| and it means you have to repeat yourself over and over.
| throwaddzuzxd wrote:
| You can still create a FAQ. Discord is a great way to know
| what are the frequently asked questions.
| tomrod wrote:
| IRC has loads less overhead with equivalent ephemerality!
| :)
|
| I'll not bemoan folks choice of comms channels, just would
| be nice to have a consistent place to do it. Between
| Gitter, slack, IRC, Discord, and others, fragmentation of
| chat clients is annoying. Pidgin solved this all a long
| time ago but then XMPP got dumped.
| zaik wrote:
| > but then XMPP got dumped
|
| by Google and Facebook.
| tomrod wrote:
| And virtually everyone else, right?
|
| What is open standard used today?
| zaik wrote:
| XMPP is still alive (= there is a community maintaining
| protocol, clients and servers). I am using XMPP
| exclusively for chat since about one year, pulling in
| most of my friends. It seems that if users do not demand
| the usage of Internet Standards like XMPP we will be
| stuck with corporate walled gardens forever. See also:
| https://blog.samwhited.com/2019/02/whats-wrong-with-xmpp/
| IceWreck wrote:
| If someone is looking for the Go alternative, there is Wails.
|
| https://wails.io/
| mfollert wrote:
| > Wails automatically makes your Go methods available to
| Javascript, so you can call them by name from your frontend! It
| even generates Typescript versions of the structs used by your
| Go methods, so you can pass the same data structures between Go
| and Javascript.
|
| That sounds really great!
| OJFord wrote:
| That does sound really nice - would love that with Tauri.
|
| I've never used Typescript, so at the moment I just have the
| pain of untyped structures in JS-land (and making sure I get
| it right passing back in to Rust-land) - but, at least as far
| as I know, if I did use TS I'd just suffer from manually
| duplicating data structures instead.
|
| (I suppose ultimately I intend to do that, it's just so
| imperfect anyway that I haven't bothered yet.)
| makapuf wrote:
| Nice (linux is coming soon though)
| IceWreck wrote:
| Wails works on Linux, has been for years but they decided to
| delay the Linux version for the latest release for some
| reason.
| giorgioz wrote:
| At https://www.waiterio.com we use plain webviews for Android,
| iOS and macOS without any framework and Electron for Windows and
| Linux. The problem with frameworks is that once a year Apple make
| a change to their signature and it can break the framework for
| several weeks/months before a fix/hack around is found. By using
| native webviews you can quickly implement the change needed and
| get back online in days.
| dangoor wrote:
| Projects like Tauri use libraries like Wry[1], though. Getting
| Wry fixed to use the new API shouldn't be any more difficult
| than the work you need to do, right? And that work is then
| shared by everyone using the project.
|
| [1]: https://github.com/tauri-apps/wry
|
| Edit to correct that Tauri uses Wry and not Webview.
| WolfOliver wrote:
| would this work for Windows and Linux too?
| WolfOliver wrote:
| I mean MacOS, not Windows
| giorgioz wrote:
| yes we already had a macOS published on the App Store for 2
| years written as a thin Swift app with WKWebView:
| https://apps.apple.com/us/app/waiterio-restaurant-pos-
| system...
|
| https://developer.apple.com/documentation/webkit/wkwebview
|
| The app store reviewers will allow apps with only webview
| only if you are offering some feature that would not be
| possible to implement in the browser alone.
| giorgioz wrote:
| Vanilla webviews is definitely possible on Windows with
| Webview2 https://docs.microsoft.com/en-us/microsoft-
| edge/webview2/ The problem though was compatibility since
| that webview might be based on old versions of Edge which
| used to be a much more outdated browser than Safari/Chrome.
| So far in 5 years of using Electron Windows never broke
| Electron except on a minor instance. Our Windows Electron app
| doesn't work on Windows 10 S. The problem might have became
| fixable by now but Windows S had so little marketshare that
| we never found time to fix that issue.
| mmargerum wrote:
| What do you get from this you cannot get from building your app
| in QT, Flutter, or Lazarus?
| hiccuphippo wrote:
| Probably the "written in rust" label.
| zem wrote:
| having a gui toolkit that works with your language, rather than
| having to change your language to the one the gui toolkit uses.
| [deleted]
| synergy20 wrote:
| Last time I checked it's using libwebkit to render html/js/css,
| which means, on top of my chrome typical daily browser, Tauri
| brings another browser(memory and CPU) into the system, which
| nearly doubled my 'browser resource' consumed on the computer,
| not good.
| dangoor wrote:
| Tauri uses Wry[1], so it should actually be using the webview
| that comes with your OS. FWIW, every Electron app includes its
| own copy of Chromium, so that's even worse from this
| perspective.
|
| [1] https://github.com/tauri-apps/wry
|
| (edited to fix that Tauri uses Wry and not Webview)
| synergy20 wrote:
| I just ran vscode on ubuntu and checked its memory usage,
| you're correct that vscode brings its own chromium instead of
| sharing any libraries with my running chrome.
|
| Wry said to use 'default web engine', which under Gnome is
| libwebkitgtk(i.e. webkit engine), that is different from its
| default browser firefox which uses Gecko as the engine.
|
| so Electron and Tauri both will bring their own
| demanding/heavy cpu/memory needs from their built-in web-
| engine that shares nothing with your already running heavy
| browsers. Neither is a light-weight solution.
| dangoor wrote:
| Neither is as lightweight as native, but if you've got a
| collection of apps running against OS webviews vs a
| collection of apps running against their own Chromiums, it
| seems like the webview ones would share at least some
| memory. (It could just be that all you gain is disk space
| and smaller downloads, which I agree isn't that much of a
| win)
| synergy20 wrote:
| When I was playing with Tauri I had to install
| libwebkitgtk etc for it, since neither firefox nor chrome
| brings in that dependency. Unless you're using some gtk
| browser that disk space was not saved by Tauri at all.
|
| Anyways other than Tauri is a Rust-flavor, on the
| resource usage side, it shall not have much difference
| from using Electron, which uses Nodejs.
___________________________________________________________________
(page generated 2022-01-05 23:00 UTC)