[HN Gopher] Webview: Tiny cross-platform webview library for C/C++
___________________________________________________________________
Webview: Tiny cross-platform webview library for C/C++
Author : aragonite
Score : 90 points
Date : 2024-05-29 01:00 UTC (22 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| disqard wrote:
| Does this contain a JS interpreter, or is it a cross-platform
| wrapper around OS-provided browser libraries?
| ammo1662 wrote:
| It seems to be a wrapper.
| mkl wrote:
| It's a wrapper. From the About at the top of the page: "Tiny
| cross-platform webview library for C/C++. Uses WebKit
| (GTK/Cocoa) and Edge WebView2 (Windows)."
| julesrms wrote:
| This is fine, but if you want something that does all this, but
| also:
|
| * is header-only
|
| * supports EDGE on Windows without the need to have the WebView2
| SDK or to bundle a runtime DLL
|
| * supports fetch intercepting and some other customisation
|
| * is modern C++ rather than a sort of mashup of C/C++
|
| then check out the one in the CHOC library here:
| https://github.com/Tracktion/choc/blob/main/gui/choc_WebView...
| bun_terminator wrote:
| Interesting! The header as well as the entire library. Thanks
| wild_pointer wrote:
| From the readme:
|
| > Internally, some absolutely hideous shenanegans are involved
| to make this possible!
|
| Yeah, like literally embedding a dll in the header file.
|
| Pretty cool, but seems kinda fragile.
| leni536 wrote:
| C++ programmers will do anything to avoid using a proper
| package manager. I say this as a C++ programmer.
| actionfromafar wrote:
| Seconded.
| whizzter wrote:
| which one? :P
| julesrms wrote:
| It's totally fair to criticise it for being a horrible, ugly
| technique. But in terms of fragility, it's no worse than
| bundling the same DLL as a file along with your app.
|
| (In fact, it's less fragile than a loose DLL, because you
| don't run the risk of your DLL failing to install/being
| moved/accidentally loading some other random version of the
| same DLL etc)
| rezaprima wrote:
| so, a statically linked Dynamically Linked Library ?
| leni536 wrote:
| Hey, isn't that what docker is for?
| jcelerier wrote:
| Yes, let's add a complete software stack instead of using
| the most basic CS101 linker feature
| kjksf wrote:
| In case you're not just riffing: no, it's not statically
| linked.
|
| The WebViewLoader.dll is embedded in the source code and
| then loaded into memory as if it was loaded via
| LoadLibrary() or by Windows .exe loader which loads
| referenced .dll automatically.
|
| Granted, he re-implemented LoadLibrary() to load from
| memory, which can potentially break if Microsoft changes
| the details of how LoadLibrary() is implemented.
|
| This is one of my pet peeves with Microsoft API design.
| LoadLibrary() only works with files from disk.
|
| It should be implemented as a trivial wrapper around
| LoadLibraryFromMemory() but Microsoft didn't implement
| LoadLibraryFromMemory so we have to resort to re-
| implementing LoadLibrary when we want this very useful
| functionality.
| rovingeye wrote:
| I still don't see a reason to re-implement this
| functionality when you can just.. statically link the
| loader. CHOC is great though!
| julesrms wrote:
| I wrote this a year or two ago and have forgotten the
| details, but there was definitely some reason why you
| couldn't "just statically link" it, otherwise that's
| exactly what I would have done, and saved myself some
| hassle.
|
| IIRC it was either because there wasn't support for it
| back then, or the static version didn't support older
| Windows versions, or somesuch Microsoft nonsense.
|
| But for whatever reason it was, they strongly push people
| to use the DLL, and deploying DLLs in installers is a
| PITA, so...
| rovingeye wrote:
| That's about when they added the capability, yeah.
| They've dropped support for win 7/8, not sure if CHOC
| goes back that far.
|
| I suppose this would break the "Nothing needs adding to
| your build system to use any of this stuff.", but that
| doesn't seem true now that Boost is a dependency for the
| server stuff.
| rovingeye wrote:
| Yeah, it's kind of silly when the WebView2 loader can be
| statically linked. It's just build system avoidance. CHOC is
| great though!
| ninepoints wrote:
| "header only"
|
| Aside from template based code, this is a disadvantage in my
| book usually
| saurik wrote:
| This library is also header-only (look at the source file).
| singularity2001 wrote:
| Together with wasm / js this can give you super lightweight
| 'electron-like' standalone apps in less than 2 MB. Used as such
| in in https://github.com/pannous/wasp/
| iainmerrick wrote:
| Out of interest, why 2MB and not like 20KB, if it's using the
| OS's web view? (Depending on the complexity of the app, of
| course.)
|
| I realise 2MB is really small these days, I just found myself
| thinking "2MB wouldn't even fit on a floppy disk!"
| lf-non wrote:
| Primarily because it bundles a webserver to bridge the host
| code and code running in the browser.
| Jyaif wrote:
| > The goal of the project is to create a common HTML5 UI
| abstraction layer for the most widely used platforms.
|
| It would be great to have this library work on the two most
| popular platforms, ideally with as little Java on Android as
| possible.
| mrbluecoat wrote:
| Cool project, but you may want a more unique name to help with
| SEO and building a community.
|
| https://developer.android.com/reference/android/webkit/WebVi...
| petabyt wrote:
| I consider this the successor to webview:
| https://github.com/webui-dev/webui In general it should use less
| RAM and launch faster.
| cal85 wrote:
| First I've heard of WebUI, thanks. I had been looking at trying
| trying Tauri for an upcoming project - do you know about that
| and have any view on it? Interested in any opinions you have
| about tools in this space.
| novagameco wrote:
| Pet peeve: when people who haven't used Windows in 20 years write
| build instructions on Windows that still use the command prompt
| or just tell you to download MSYS or something
| ranger_danger wrote:
| What would you prefer? I think VS and friends are a whole lot
| more bloated and annoying to use. For reference I have been
| developing on both platforms for 20 years.
| novagameco wrote:
| Cmake is pretty standard so windows users could just generate
| their own project files. But I mean not using .bat files or
| the command prompt like it's 2001. Powershell scripts are
| more common with Windows developers these days and is a far
| better syntax than batch files. But Visual Studio/MSBuild is
| the de facto way to compile code for MSVC (which the
| instructions use anyways, but bizarrely compiling the
| projects via CLI instead of MSBuild). The whole project just
| seems like it was written using 1990s build patterns. It
| doesn't even have a modern build system for linux, let alone
| windows
| saurik wrote:
| > The whole project just seems like it was written using
| 1990s build patterns. It doesn't even have a modern build
| system for linux, let alone windows
|
| This project doesn't have a build system at all, nor should
| it: it is a single source file that you might add to your
| existing project and build using your build system... and
| even that source just includes the header, so presumably
| you wouldn't even do that and would just include the header
| from your existing code. It would be absolutely ridiculous
| for this header to have its own build system.
| badsectoracula wrote:
| I've used Windows many times the last 20 years and i'd rather
| use MSYS2 to build a C/C++ program than MSVC as it allows me to
| use the exact same tools i'd prefer to use on Linux and macOS
| (...i don't really _prefer_ to use macOS, but i can still use
| the same tools there too) than having Windows be its own
| special snowflake. And i find current MSVC incredibly bloated.
|
| I see in other comments you mentioned Powershell and CMake and
| TBH these are two things i avoided whenever i used Windows.
| CMake is used too much to be able to avoid it on Linux (which
| is currently my main OS) but it is not a tool i'd use myself if
| i had the choice.
|
| If i had to use a tool that generates build files, i'd rather
| use premake[0] as it is a self-contained binary with very
| simple Lua-based scripts (by default they look declarative but
| you can extend it as much as you want - i've even used a script
| to generate CMake files since these can be parsed by Qt
| Creator). The only downside is that on Unix systems it doesn't
| know concept of a shared library (can be "taught" with a custom
| script but it isn't something that is available out of the
| box).
|
| [0] https://premake.github.io/
| Night_Thastus wrote:
| Nothing wrong with using MSYS!
|
| Let me tell you as someone who has used virtual machines, done
| native development, and used tools like WSL...MSYS is really
| nice in context.
|
| It's not as fast as bare native, but it's leagues better than a
| virtual machine and plenty fast enough for daily work. It has
| lots of the latest tooling (just recently it updated to GCC14 a
| couple days after GCC14 released). It has all the nice
| toolchains set up with a simple pacman call instead of having
| to compile everything yourself or go to esoteric sources to get
| it installed.
|
| Most importantly, it just _works_ the vast majority of the
| time. I very rarely have to fix something because of an MSYS
| concern. Almost all of my time is spent actually developing.
|
| (Although they are for different work: That is NOT true on WSL,
| where it feels like I spend weeks just trying to get it up and
| working for a few days of productive work)
| captaindiego wrote:
| Is there some simple cross-platform way to have this sort of
| functionality, but rendering to an OpenGL or Vulkan texture?
| pornel wrote:
| There's https://github.com/not-fl3/miniquad
| krapp wrote:
| If "simple" can mean "low level" then maybe SDL2 (or 3 might be
| ready enough.)
___________________________________________________________________
(page generated 2024-05-29 23:03 UTC)