16 ms·

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 guarant

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 https://github.com/tauri-apps/tauri

pjmlp 5y ago
Yes, the lazy devs path, helping Google to spread Chrome everywhere.
- YPPH 5y ago
  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 5y ago
    > 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 5y ago
      Without this kind of thing happening at times, we might still be using Flash.
      - fabianhjr 5y ago
        Yeah, it had nothing to do with work on open standards like HTML5 and CSS3. (And WebGL for more advanced rendering needs) /s
      - kbelder 5y ago
        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 5y ago
  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 5y ago
    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.
dmitryminkovsky 5y ago
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.
- fabiospampinato 5y ago
  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.
  - nine_k 5y ago
    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 5y ago
      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.
      - nine_k 5y ago
        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 5y ago
        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.
silon42 5y ago
It would be better to use Rust+Servo (no JS, or at least optional) IMO
- simion314 5y ago
  >(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.
  - sanxiyn 5y ago
    People are doing that too. https://sixtyfps.io/ https://sixtyfps.io/ is basically a Qt clone in Rust, actually developed by previous Qt developers.
    - detaro 5y ago
      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 5y ago
    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.html https://raphlinus.github.io/rust/druid/2020/09/28/rust-2021....
  - jackosdev 5y ago
    egui is a really fantastic Rust GUI toolkit, best I've used in any language
  - MathCodeLove 5y ago
    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.
krapp 5y ago
"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.
- kitsunesoba 5y ago
  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.
- awestroke 5y ago
  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
  - ben-schaaf 5y ago
    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 5y ago
      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.
brnt 5y ago
> WebKitGTK Is there something like WebkitQt? Guess it would use WebEngine.
- fabianhjr 5y ago
  Webkit not WebEngine. ( https://webkitgtk.org/ https://webkitgtk.org/ )
dmingod666 5y ago
Saw a comparison, Electron app size of 138MB Vs Tauri in single digit MB is a big difference though.
- fastball 5y ago
  Sure, but Neutralino[1] already does this, it's just not Written in Rust™ [1] https://neutralino.js.org/ https://neutralino.js.org/
  - cozzyd 5y ago
    Does neutralino run on platforms other than a minimal SUSE? </obligatory physics joke>
gr__or 5y ago
I'd argue Babel-ing and polyfill-ing the webcompat delta is wiser than shipping chromium
favorited 5y ago
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.
ummonk 5y ago
And here I was hoping it would use Servo.
- fault1 5y ago
  Servo is kind of dead, no? I'm not sure anyone is working on it for their day job, at least.

pjmlp 5y ago

Yes, the lazy devs path, helping Google to spread Chrome everywhere.

YPPH 5y ago
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 5y ago
  > 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 5y ago
    Without this kind of thing happening at times, we might still be using Flash.
    - fabianhjr 5y ago
      Yeah, it had nothing to do with work on open standards like HTML5 and CSS3. (And WebGL for more advanced rendering needs) /s
    - kbelder 5y ago
      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 5y ago
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 5y ago
  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.

dmitryminkovsky 5y ago

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.

fabiospampinato 5y ago
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.
- nine_k 5y ago
  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 5y ago
    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.
    - nine_k 5y ago
      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 5y ago
        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.

silon42 5y ago

It would be better to use Rust+Servo (no JS, or at least optional) IMO

simion314 5y ago
>(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.
- sanxiyn 5y ago
  People are doing that too. https://sixtyfps.io/ https://sixtyfps.io/ is basically a Qt clone in Rust, actually developed by previous Qt developers.
  - detaro 5y ago
    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 5y ago
  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.html https://raphlinus.github.io/rust/druid/2020/09/28/rust-2021....
- jackosdev 5y ago
  egui is a really fantastic Rust GUI toolkit, best I've used in any language
- MathCodeLove 5y ago
  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.

krapp 5y ago

"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.

kitsunesoba 5y ago
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.
awestroke 5y ago
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
- ben-schaaf 5y ago
  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 5y ago
    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.

brnt 5y ago

> WebKitGTK Is there something like WebkitQt? Guess it would use WebEngine.

fabianhjr 5y ago
Webkit not WebEngine. ( https://webkitgtk.org/ https://webkitgtk.org/ )

dmingod666 5y ago

Saw a comparison, Electron app size of 138MB Vs Tauri in single digit MB is a big difference though.

fastball 5y ago
Sure, but Neutralino[1] already does this, it's just not Written in Rust™ [1] https://neutralino.js.org/ https://neutralino.js.org/
- cozzyd 5y ago
  Does neutralino run on platforms other than a minimal SUSE? </obligatory physics joke>

gr__or 5y ago

I'd argue Babel-ing and polyfill-ing the webcompat delta is wiser than shipping chromium

favorited 5y ago

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.

ummonk 5y ago

And here I was hoping it would use Servo.

fault1 5y ago
Servo is kind of dead, no? I'm not sure anyone is working on it for their day job, at least.