The slangc compiler itself in the macOS release is only 96KB so it may be that you’d only need to bundle a tiny subset of those releases. I don’t know for sure - in my CMake I just grab the latest zip for each platform and use the included slangConfig.cmake.
Looks like slangc.exe is 1.2MB so might be worth testing if you actually need more than that to do the transpiling?
I’m sure that slangc compiler app itself needs those dynamically loaded libraries. Some may be optional, but some are definitely needed. Even a bloat of “only” 30 MB would be out of the question for my projects.
Even if you bundled the compiler in the installer, rather than the binary itself?
what you want is being backed by a renderer like Rive and then take advantage of the GPU canvas GPU Canvas — Rive's new GPU layer for 3D, shaders, and custom effects | Rive Community only 25kb, welcome to the future my friends! (well i’m not allowed to talk more or i will be banned 
)
The download would stay the same size. 4x bigger than my current one. All so I can transpile a few shaders.
I assume Yup supports this already?
FWIW most plugins I’ve seen that use iLok licensing are >100MB. Our installers recently went from ~15MB to over 200MB for that reason. So it’s not unheard of for a plugin download to be that large.
Oh, this is not for a plug-in. This is my private hobby project.
To add another perspective here: I think we would be totally fine with compile time constant shaders for all our plugins.
I only did some quick research on Slang, but from what I get, it’s only an abstraction layer for the actual shader code but still requires platform specific code on the C++ side, right? Would JUCE supply some C++ abstraction around the platform specific graphic API calls or would that be something we had to deal with in product code?
We would provide a unified interface to use Slang against.
but slang will bring in the slang-compiler (28mb), gfx module (1.2mb), glslang itself (around 10mb) plus slang-llvm (107mb) dynamic libraries… at this point we directly can ship a browser and do wgsl 
Are you sure?
You will need some of those tools to compile your shaders at build-time, but we would provide a unified interface to use Slang against. With shaders available at build-time why would you need any of those at runtime?
It seems there’s maybe some confusion about what’s actually being proposed with “adding slang support to JUCE” - maybe Tom you could elaborate on exactly what the proposal is, what sort of workflows and functionality adding slang would unlock/replace compared to the current offerings?
A JUCE developer will provide .slang files that expect a specific interface. The build system will run the Slang compiler, and produce platform-specific shaders (Metal, HLSL, …) that use the interface, and these shaders will be built into the shipped binary at build-time.
How would I then use those shaders in my C++ code to style a given component?
If you’re rendering the whole thing then you could set up uniforms, vertices, etc and address your shader by name/ID.
Or we could allow you to just implement a fragment shader interface where we provide things like the position and timing.
The advantage of webgpu is that it’s a cross platform (as in Vulkan, Metal, and DX) API for manipulating the pipeline state object model of each backend. The shaders are a very minor part of this.
The shaders are the important part. The ability to write a shader once and have it work on all the platforms JUCE supports is the hardest problem to solve.
Dawn or wgpu are enormous dependencies. Dawn, in particular, is very difficult to add to the build system.
Slang provides one route to do one-shader-to-multiple-platforms, in a shader language that is relatively popular relative to WebGPU.
Rive might also be the way to go, and we already have people using it in WebViews.
All I was trying to point out is that “write shaders once” is not the only problem that x-platform GPU abstractions need to solve and webgpu is useful because it abstracts the underlying APIs instead of just acting as a shader compiler. I’m wondering if slang-embedded-in-JUCE would wind up basically reimplementing the webgpu API, or a limited subset of it.
It would likely be very similar to a subset of the WebGPU interface, but I think we could cover the vast majority of use cases with that subset.
