3 ms·

I haven’t seen anyone talking about how this supports Tauri yet, so I’ll start: that’s pretty great! For anyone who hasn’t heard of it yet, Tauri is a really n

I haven’t seen anyone talking about how this supports Tauri yet, so I’ll start: that’s pretty great! For anyone who hasn’t heard of it yet, Tauri is a really nice Electron-like alternative that uses the system webview instead of shipping an entire copy of Chromium, and it’s written in Rust, so I’d presume there’ll be some way to call out to Rust from PHP. I’m excited to see Tauri get more adoption. I’ve been building/selling a video editor with it for the past couple years and while it’s not always perfect, it suits my needs and I like that native performance is always an option when I need it. I’ve yet to run into a performance problem that is completely out of my control. Not to say my app is perfect, just that where it’s slow, it’s not JavaScript’s fault.

colecut 3y ago
Thanks for this interesting info.. Also, Recut looks very nice. Do you mind if I ask what the full tech stack is for a video-editing app like that?
- dceddia 3y ago
  Thanks! It's Svelte, TypeScript, WebGL (for the timeline) and Tailwind on the UI side, and Rust for the backend that calls out to the libav libraries for the audio/video encoding/decoding. And there's a little Swift in there for some native Mac stuff.
djbusby 3y ago
Where is it slow? I'm assuming libav/libffmpeg stuff - or maybe just in IO cause videos are fat.
- dceddia 3y ago
  That's one place for sure, yeah. Video decoding is just resource intensive, especially if it's being done in software. Switching to hardware decoding is a big thing that's still on my todo list. Beyond that, drawing the timeline efficiently took some work. I spent a bunch of time rewriting it to use WebGL recently, and before that it was some 2D canvas stuff. Plain old DOM elements slow to a crawl when there's 10k+ of them :D Another little wrinkle is that calling between JS and Rust has a fair bit of overhead, so I try to minimize that and avoid sending lots of data back and forth. I think Tauri v2 is supposed to improve that a lot, but right now it's basically serializing everything to JSON and back. There's an alternative where you can send raw binary back and forth, and I'm using that in some spots. (re: the sibling comment about browser compatibility, I've got some fallbacks in place because old Safari didn't support it, heh)
croes 3y ago
Isn't the problem with Tauri and similar solutions that any update of the webview can breake your app? With Electron you know exactly which version of the browser engine you are using.
- dceddia 3y ago
  Sort of! On Windows, it's WebView2, which is more or less Chromium. On Mac it's the system's Safari, which I'm pretty sure is frozen at the OS release (or maybe gets updated with OS updates). So I'm less worried that it'll break with an update, but I've had to fix a few issues when someone is running on macOS 10.13 or something like that, where Safari is just missing some modern JS thing. I've solved that with polyfills and Babel and it's been alright. CSS is the other issue, where old Safari doesn't support grid and some other stuff. So I stick to flexbox and well-supported stuff.
  - AnonC 3y ago
    On macOS, Safari releases are independent of OS releases and show up as separate updates as and when they’re released. They may coincide on the date sometimes. It’s not like iOS where Safari updates never show up as separate updates, and are bundled with iOS updates.
    - dceddia 3y ago
      Do you happen to know if the WKWebView always uses the latest Safari that's been installed? That's been the thing I'm uncertain about, where I think I've run into situations where the installed Safari should support some JS thing, but Recut doesn't actually have access to it, and I've suspected that WKWebView is just frozen at whatever the OS came with.
- notpushkin 3y ago
  I don't really see how is that a problem. Webapps work pretty well despite the fact we have a bunch of different browsers – why the Tauri situation should be any different?

colecut 3y ago

Thanks for this interesting info.. Also, Recut looks very nice. Do you mind if I ask what the full tech stack is for a video-editing app like that?

dceddia 3y ago
Thanks! It's Svelte, TypeScript, WebGL (for the timeline) and Tailwind on the UI side, and Rust for the backend that calls out to the libav libraries for the audio/video encoding/decoding. And there's a little Swift in there for some native Mac stuff.

djbusby 3y ago

Where is it slow? I'm assuming libav/libffmpeg stuff - or maybe just in IO cause videos are fat.

dceddia 3y ago
That's one place for sure, yeah. Video decoding is just resource intensive, especially if it's being done in software. Switching to hardware decoding is a big thing that's still on my todo list. Beyond that, drawing the timeline efficiently took some work. I spent a bunch of time rewriting it to use WebGL recently, and before that it was some 2D canvas stuff. Plain old DOM elements slow to a crawl when there's 10k+ of them :D Another little wrinkle is that calling between JS and Rust has a fair bit of overhead, so I try to minimize that and avoid sending lots of data back and forth. I think Tauri v2 is supposed to improve that a lot, but right now it's basically serializing everything to JSON and back. There's an alternative where you can send raw binary back and forth, and I'm using that in some spots. (re: the sibling comment about browser compatibility, I've got some fallbacks in place because old Safari didn't support it, heh)

croes 3y ago

Isn't the problem with Tauri and similar solutions that any update of the webview can breake your app? With Electron you know exactly which version of the browser engine you are using.

dceddia 3y ago
Sort of! On Windows, it's WebView2, which is more or less Chromium. On Mac it's the system's Safari, which I'm pretty sure is frozen at the OS release (or maybe gets updated with OS updates). So I'm less worried that it'll break with an update, but I've had to fix a few issues when someone is running on macOS 10.13 or something like that, where Safari is just missing some modern JS thing. I've solved that with polyfills and Babel and it's been alright. CSS is the other issue, where old Safari doesn't support grid and some other stuff. So I stick to flexbox and well-supported stuff.
- AnonC 3y ago
  On macOS, Safari releases are independent of OS releases and show up as separate updates as and when they’re released. They may coincide on the date sometimes. It’s not like iOS where Safari updates never show up as separate updates, and are bundled with iOS updates.
  - dceddia 3y ago
    Do you happen to know if the WKWebView always uses the latest Safari that's been installed? That's been the thing I'm uncertain about, where I think I've run into situations where the installed Safari should support some JS thing, but Recut doesn't actually have access to it, and I've suspected that WKWebView is just frozen at whatever the OS came with.
notpushkin 3y ago
I don't really see how is that a problem. Webapps work pretty well despite the fact we have a bunch of different browsers – why the Tauri situation should be any different?