-
Notifications
You must be signed in to change notification settings - Fork 6
2023 WebViews and Apps
niu tech edited this page Dec 21, 2023
·
1 revision
- Date: 7th June 2023
- Issue: https://github.com/Igalia/webengineshackfest/issues/11
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
wgcg 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
- gtk does another comp incorporating view output ->
- composer (could be optimized tho) ->
- 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