Apps Using Web Engines @ WEHF

# Apps Using Web Engines @ WEHF log (correct inline as you see fit) * Intros * Igalia, Tauri, Socket Supply, Bloomberg, Protocol Labs (more i'm sure, add yourself!) * agenda * devtools * polyfilling missing features * styling/theming/os * ipc perf * linux * cross vendor compat * don't want to build everything from scratch * leverage huge amount of work from other projects/vendors * webviews on every os * problem which electron avoids: have to deal w/ multiple engines and api surfacii * tauri has to deal w/ three * many parties involved, many api surfaces * messaging between webviews and native code * different on each * dynamically change function calls * little details and also bigger things * bloomberg has downstream changes * must use fixed version that's validated * how many apps are ok w/ lower quality/reliability of using system default? * trade-off: stability * fixed version not a solution for many projects * if want to embed and don't have stable api, could make a shared api? standard? * that would be great for apps which use older parts of web platform * polyfilling * deno - not polyfilling but has to add platform stuff * interop/compat/baseline projects - perhaps relevant to creating more "stable" web platform to support across multiple "unstable" surface areas (OS, engines, etc) * servo - switching out engine for servo * subset of stuff you have certainty about * webviews ~~wg~~ cg at w3c * https://www.w3.org/community/webview/ * images - tradeoffs - don't want to ship source-sets * need to raise awareness around those trade-offs * pain: integrating w/ OS styles * "is it really native?" if doing webviews * hard to fit into OS styling * maybe system-ui css improving this * some opposite movement too, eg open ui * looks same across all platforms * consistent product experience * hackernews always be mad either way * Mozilla invested in CSS+XUL/(X)HTML OS styling for many years and moved to native controls * WebExtension API for native-or-not styling: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/user_interface/Browser_styles * Tauri looking to port CEF to Linux * for performance * web-rtc * games in kiosk mode * graphics in webkit gtk * electron + chromium * webkit gtk expects abs paths in some places * tauri shares prob w/ servo, lots of dependencies * plans for wpe? webgl game perf * angle, minibufs, gpu -> accel webgl content * no guarantees on perf * then composition (piles more on gpu) * if output view handled well, decent perf * but gtk * limited options in how efficient it can be rn * gpu resource you have to interleave into gtk window * window is just once instance - repaint gets view output and resamples * webgl @ full hd -> * composer (could be optimized tho) -> * gtk does another comp incorporating view output -> * but maybe smart gtk could optimize that better * linux recent gtk much better perf + feature set * but takes ages to go through distros * wpe 2x release annually, every 6mos * deb packager, certain channels get immediately * flatpak * tech preview on epiphany - unstable releases * multiple release channels (but unclear of packaging unstable) * have to compile everything if you want unstable, ideally you use a packaged solution * check your targets - gpu, recent mach, etc * some work to unify pipeline, available at some point, on roadmap * how to inspect - often hidden away * build more tools to make easier to access? * devtools for web, but not for native code * obscure quickly * any tools for this? eg profiling * for wpe, having privilege of being inside web engine * dive into or even under * cpu, mem of specific process * under webgl, map to native api * eg what goes into openshell * partly is implementation and partly debugging technique * often running in embedded envs * but easier to do on desktop * but not for everyone * limitations like closed source gl drivers * try and improve high level tooling * aim for best experience for web app devs * otherwise, bug reports * try and repo * maybe more we could in angle * get more info there, provide it * unclear how that works in chromium * use their runtime dev tools (CDP) * if have conversation on what to improve, what's missing * then happy to close the gap * chrome profiler * hook into lots of events * get profile traces * can figure out why not performing well * chrome tracing, get a few secs of app trace * view in chrome ui * magictrace - not chrome specific * generic gfx tracing tool * generally: as much info as possible * add overlays for dynamic tracing * scripting calls for the dynamic trace points * easier to integrate into your own app * linux: fragmentation * ppftrace, qt have different one (name?) * choose one! stick to it! * what do you want embedded engines future to look like? * Chrome OS as example * browser + OS integrated the best * PWAs working great there * embedding helps focus on web apps * better integration allows web apps to do more * chromeos maybe is opposite, OS integrated into web, not vice versa * eg OS shouldn't have full upgrade cycle of web runtime * maybe browser is api to talk to system * for modern web apps, browser is api to talk to everything * chrome os trying to support all kinds of apps though, not just web apps * pwa apps are opposite of fixed-version web apps in embedded webviews * boundary of web vs browser chrome * maybe in 10yrs if build quality is consistent, could maybe be that way * would be interesting to think about how to get that state * if you draw your box, where does the web platform end * eg window decorations * web apps w/ priv'd apis - chrome apps, fxos, fugu * one sec/perms model, or mode * a think like tauri can provide that extra bit * permissions / privacy / sec models differ in app/webview use-cases * thinking 10yrs out, what's the path to get us there w/ webviews * fugu, chrome-anchored business relationship * concern: piling features on top of web platform * eg servo can keep up? * servo, ladybird doing ok tho * Bloomberg needs even more features actually * different sec lens * eg never let unpermissioned web access to clipboard * whereas install implies it * eg cross origin * awkward * but dbus vs postMessage * feels optimistic * linux permission system connecting web apps to web apps * mobile os does this, but desktop permission expectation is you don't have to * macOS atteempting to address that, at cost of permissioning of your OS * unified permission models? * they reflect different values * and business models? * unclear