I'm a fan of more frameworks for desktop apps that wrap system webview rather than embedding Chromium.
Chromium is awesome and all, but it's just way overkill for many apps, and doesn't make sense for the download size and the need to support auto-update for security features.
I feel the reason the system web-view is eschewed in these frameworks is because you have no choice but to maintain compatibility with 3-4 browsers: Edge/IE on Windows, Safari on Mac, and Firefox on Linux (usually).
The number 1 request I get from people is to add the ability to optionally bundle chromium.
I personally prefer the system webview because you don’t have to rush update your app for every chromium security update. And on the web making things cross browser is a normal part of the job and instinct imo.
But there are a ton of early startups that only have bandwidth to support chrome/chromium in their complex webapps and want a quick way to port their web app to desktop app. For them taking on the security burden and increasing bundle size is a good tradeoff to getting that consistency.
Luckily electrobun has a custom zig bsdiff implementation that generates update diffs as small as 4KB and self extracting executable that uses zstd so at least the file size is less relevant of a concern compared to electron.
> you don’t have to rush update your app for every chromium security update
I'm interested to hear more about this—if you're using security-sensitive features in a WebView, aren't you then at the mercy of the OS to patch them whenever they see fit? And if you're not using features that have security implications, why do you need the latest version of Chromium at all times?
> But there are a ton of early startups that only have bandwidth to support chrome/chromium in their complex webapps and want a quick way to port their web app to desktop app.
Ugh!
People writing web apps without supporting anything else than Chrome should burn in hell. (And that's a pretty useless decision anyway since “supporting chrome” really means supporting two engines: Chromium and WebKit, because Chrome on iOS uses WebKit internally …)
> Their current approach is what I'd think would be a temporary solution while they reverse engineer the streams (or even get partnerships with the likes of MS and others. MS in particular would likely jump at an opportunity to AI something).
They support 7 meeting platforms. Even if 1 or 2 are open to providing APIs, they're not all going to do that.
Reverse-engineering the protocol would be far more efficient, yes - but it'd also be more brittle. The protocol could change at any time and reverse-engineering it again could days between days and weeks. Would you want a product with that sort of downtime?
Also, does it scale? Reverse-engineering 7+ protocols is a lot of engineering work, and it's very specialized work that not any software engineer could just dive into quickly.
In comparison, writing web scrapers to find the video element for 7 different meeting products is super easy to write, and super easy to fix.
> Here they have a nicely compressed stream of video data
But they don't.
They support 7 different meeting providers (Zoom, Meet, WebEx, ...), none of which have an API that give you access to the compressed video stream.
In theory, you could try to reverse-engineer each protocol...but then your product could break for potentially days or weeks anytime one of those companies decides to change their protocol - vs web scraping, where if it breaks they can probably fix it in 15 minutes.
Their solution is inefficient, but robust. And that's ultimately a more monetizable product.
No, what I'm saying is pipe the video output to an HLS encoder. HLS live will rewrite the m3u8 as more segments come in. In fact, they can render the audio into its own m3u8 and use that as input for their transcriber, saving even more bandwidth/data transfer/etc.
Since it's coming from a headless process, they can just pipe it into ffmpeg, which is probably what they're using on the back-end anyway. Send the output to a file, then copy those to s3 as they're generated. And you can drop the frame rate and bitrate on that while you're at it, saving time and latency.
It's really not rocket science. You just have to understand your problem domain more better.
Shipping uncompressed video around is ridiculous, unless you're doing video editing. And even then you should use low-res copies and just push around EDLs until you need to render (unless you need high-res to see something).
Given that they're doing all that work, they might as well try to get an HLS encoder running in chrome. There just was an mp3 codec in web assembly on HN, so an HLS live encoder may not be too hard. I mean, if they were blowing a million because of their bad design they could blow another million building a browser-based HLS encoder.
With my mindset, you have a gigantic chunk of data. Especially if you're recording multiple streams per machine. The immediate thought is that you want to avoid copying as much as possible. If you really, really have to, you can copy it once. Maybe even twice, though before moving from 1 to 2 copies you should spend some time thinking about whether it's possible to move from 1 to 0, or never materializing the full data at all (i.e., keep it compressed, which could apply here but only as an optimization for certain video applications and so is irrelevant to the bootstrapping phase).
WebSockets take your giant chunk of data and squeeze it through a straw. How many times does each byte get copied in the process? I don't know, but probably more than twice. Even worse, it's going to process it in chunks, so you're going to have per-chunk overhead (maybe including a context switch?) that is O(number of chunks in a giant data set).
But the application fundamentally requires squishing that giant data back down again, which immediately implies moving the computation to the data. I would want to experiment with a wasm-compiled video compressor (remember, we already have the no GPU constraint, so it's ok to light the CPU on fire), and then get compressed video out of the sandbox. WebSockets don't seem unreasonable for that -- they probably cost a factor of 2-4 over the raw data size, but once you've gained an order of magnitude from the compression, that's in the land of engineering tradeoffs. The bigger concern is dropping frames by combining the frame generation and reading with the compression, though I think you could probably use a Web Worker and SharedArrayBuffers to put those on different cores.
But I'm wrong. The data isn't so large that the brute force approach wouldn't work at all. My version would take longer to get up and running, which means they couldn't move on to the rest of the system.
Their business is joining meetings from 7 different platforms (Zoom, Meet, WebEx, etc.) and capturing the video.
They don't have control of the incoming video format.
They don't even have access to the incoming video data, because they're not using an API. They're joining the meeting using a real browser, and capturing the video.
Is it an ugly hack? Maybe. But it's also a pretty robust one, because they're not dependent on an API that might break or reverse-engineering a protocol that might change. They're a bit dependent on the frontend, but that changes rarely and it's super easy to adapt when it does change.
They are in control of the bot server that joins with the headless chrome client. They can use the CDP protocol to use the screencast API to write the recorded video stream to filesystem/disk, and then they can literally just run ffmpeg on that on-disk-on-server file and stream it somewhere else.
But instead they decided to use websockets to send it from that bot client to their own backend API, transmitting the raw pixels as either a raw blob or base64 encoded data, each frame, not encoded anyhow. And that is where the huge waste in bandwidth comes from.
Even in this case it is non-sensical. Dunno about Linux, but on Windows you'd just feed the GPU window surface into a GPU hardware encoder via a shared texture with basically 0 data transmission, and get a compressed stream out.
Chromium is awesome and all, but it's just way overkill for many apps, and doesn't make sense for the download size and the need to support auto-update for security features.
reply