Webview! || Whats going on here??

[Chazrox]

@oskarsh @aaronventure Thank You Im gonna look more into this. Let me ask one thing before I move on, is this function dependent on being connected to the internet or a file in some app data folder?

[dannytaurus]

@Chazrox Unless @aaronventure says otherwise, as far as I know it's all local files. Webview is a bit of a misnomer really. It's just a local HTML file.

[aaronventure]

@Chazrox it's just a frameless browser instance that loads a html file. When you connect to a website with a normal browser app, it loads the same bundle, it's just served by a server. Here it's shipped in your dll. Put the bundle in the Images directory and point the Webview component towards it.

The idea of Webview in general is to leverage the undoubtedly most mature frontend technology on the planet - the web platform technologies - to develop an interface for your desktop app.

The Web tech is so far ahead of the native JUCE UI stuff in terms of what it can do, how well it runs and how easy it is to work with it. As a bonus, you also get skills that directly translate elsewhere outside HISE and even audio.

Once you know this, the only missing thing will be how to point CloudFlare Pages or Github Pages to your github repo (it's like two clicks) and voila, you have a static website. Then if you learn Firebase or Supabase for example, you can ship a whole SSR web app with user accounts, database etc.

[Chazrox]

@dannytaurus def got my wheels turning...Thanks!

[Chazrox]

@aaronventure Mad potential is what Im hearing! Im definitely going to be learning this starting now. Thanks for the great breakdown!

[Christoph Hart]

The Web tech is so far ahead of the native JUCE UI stuff in terms of what it can do

I know my arguments are a bit tainted by the sunken cost fallacy of writing C++ GUIs for 10 years and offering a framework that builds on this tech stack, but this topic is currently creating a rift in the audio developer community and the jury hasn't decided yet. I've heard multiple complaints from developers getting into trouble with multiple instances or bugs that arise when people load in different plugins that all use a webview.

I guess the only way to find out is using it in real world projects and see if it holds up to the expectations.

you also get skills that directly translate elsewhere outside HISE and even audio.

That's maybe the biggest advantage of that approach though - not only you learn web UI development alongside the process, but the pool of people you can hire grows exponentially.

[aaronventure]

@Christoph-Hart said in Webview! || Whats going on here??:

I've heard multiple complaints from developers getting into trouble with multiple instances or bugs that arise when people load in different plugins that all use a webview.

Big if true, but also an issue that should then be fixed by DAW devs or JUCE devs or Webview2/Webkit devs. The potential is too insane to ignore. Though I've never seen two Webview based desktop apps interact with each other negatively, which means this could be a thing because they're within the same process/host, which might then put it into the DAW developers' court.

No doubt in some cases your users will have to be using the latest version of the DAW. That's the price. It's also a question of where HISE's Webview component is with tech, since HISE is still on JUCE 6.

Also, if your plugin has a skeumorphic interface with little or no animations or you're generally just using filmstrips, it's simpler and faster to just use HISE.

If it's not complex and you don't need performant animations, it's also faster and simpler to use HISE, and it's even possible to do a responsive design now with the changeable plugin resolution.

HISE is uniquely positioned here because of hot reloading. Actually developing a complex interface in JUCE is not super fun. Melatonin inspector helps, but man...

[d.healey]

@aaronventure Is there any overheard when the UI is minimized, or does it all go to sleep like the native UI?

[Christoph Hart]

Big if true, but also an issue that should then be fixed by DAW devs or JUCE devs or Webview2/Webkit devs.

That's true and you can expect that DAW or JUCE devs will go out of their way to fix the stuff, but if the issue is within the Webview2 layer you're basically dead in the water as you have to engage with the developer support of Apple and Microsoft and expect them to care about our little fringe use case (compared to where webview tech is used elsewhere).

[aaronventure]

@d-healey it gets destroyed completely, so even the memory gets cleared