Skip to content

2023 WebViews and Apps

niu tech edited this page Dec 21, 2023 · 1 revision

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
  • 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
Clone this wiki locally