Svader is a library for rendering 2D shaders on Svelte websites, using either WebGL or WebGPU.
It's streamlined for the specific use case of rendering 2D graphics using fragment shaders as an alternative to SVG or the JS canvas API, so it's not meant for doing 3D objects like three.js, for example.
This started as something I needed for my own project, but I eventually decided to split it into a separate library. I've since found that this use case fits really well into the Svelte compiler-based approach and its fine-grained reactivity system.
In general, I think using shaders like these has some really positive upsides compared to traditional ways of doing graphics on the web — not just for games and stuff, but also for something like data visualizations and aesthetic details. My dream is that one day, you'll see web developers using small, isolated shader components ubiquitously across web applications, just as naturally as something like SVGs are used today.
This is very cool. However, I do wonder about your use case for making things like sliders.
CSS and HTML already have several decades of work on accessibility and cross platform support. It's far from trivial to recreate this.
For things like hero pages, I can see the benefit. But for basic UI like sliders, are you reinventing the wheel here?
Talking about the slider specifically, I'm of course not advocating for going out and rewriting all sliders using shaders.
This is just an example of a place where you can use a shader to create a cool, interactive visual effect.
On the example site I've implemented the slider as a regular HTML slider element, and using a canvas to replace its visual appearance. Doing something like this, I don't believe there's anything in the way of getting all the accessibility benefits of a regular slider element, though I could be wrong, I'm no expert by any means.
Maybe you could do some research, since you're introducing a technology that could easily make accessibility worse or impossible.
However, from what I can see, it probably is accessible, as it is still usable without a mouse, which is an easy first test.
(Though, in Safari, neither slider test has any kind of slider, so there are other big problems.)
It's not more of his responsibility to research that, as it is yours.
Any plans to integrate this with an animation engine? I've found Svelte animations little bit buggy however. Also are the limitations of 3D just a design choice? Thanks for the HN post.
I haven't thought about it, but I'm open to the idea. What kind of animation engines do you have in mind?
Yes, the absence of 3D is very much a choice. I believe this need is already covered pretty well by existing libraries like three.js and threlte etc. These are relatively large and complex to use, because you essentially have to adopt the mental model of having a whole 3D scene or something like that. With Svader, the mental model is just that you have a canvas with an attached fragment shader, which paints the canvas with respect to some input parameters.
I don't have a lot of experience but https://animejs.com/ comes to mind. I'm not sure how the rendering works in WebGPU with changing inputs either. For example, does Svader cap at 60fps or the browser refresh rate? Do you use requestAnimationFrame? Thanks again.
If the animation engine is capable of smoothly changing a value in JS, I think it would already integrate very well with Svader.
The way the reactive rerendering works, is that every time a change in the input parameters is detected it queues a requestAnimationFrame, so yes, it follows the browser refresh rate.
Since Svelte 5 is automatically able to track changes in values, both by reassignment as well as object mutation, anything that changes a value -- no matter if it's designed for Svelte or not -- should be able to integrate smoothly.
This is awesome, thanks for sharing!
None off he examples work on Safari iOS 18.1.1
Same here. All examples are white or black pages. All are empty except the slider, which has a non-interactive text that says ”Slide me”. iPhone 15 Pro, iOS 18.1.1.
Even the the example at svader.vercel.app/hello-world/webgl/? Testing on the Safari browsers is currently a TODO, and the library is in general still experimental when it comes to wider browser support, but I would have expected at least the standard WebGL examples to work. Does it at least display the "WebGL not supported" message?
WebGL works very well on iOS.
If in doubt try https://luduxia.com/whichwayround/ ;P
Just a white page.
Strange. I'll have to look into this.
Thanks for letting me know!
If you don’t have access to Apple devices, I find Epiphany/GNOME Web to be a pretty good proxy—it uses WebKit, unlike most things these days that use Blink. Most times, Safari issues appear in Epiphany as well. This seems to hit a TypeError in https://svader.vercel.app/_app/immutable/chunks/entry.B0k4a9... line 1, column 9932 (Xe(ht,e)), and I have no time to investigate further.
How good are the developer tools in Epiphany browser?
(I would try but I killed my laptop recently!)
They're identical to Safari, macOS theme and all.
I strangely can’t get any of the examples to work on iOS - even on chrome.
Chrome on iOS also uses WebKit as backend, as iOS restrictions don’t allow other engines. Same goes for Firefox, Brave, etc…
Edit: Actually not fully true anymore, as of iOS 17.4, you _could_ bring your own engine (https://developer.apple.com/support/alternative-browser-engi...) - with restrictions, of course.
On mobile, none of the examples work.
One makes my phone extremely sluggish.
It also breaks the browser history.
The page with the list of examples sometimes doesn't render at all. Which is weird bc. <ul> is a solved problem since like 1999.
"Sick stuff, bro!"
That's weird since this very much is a completely plain <ul>. What OS and browser are you using? Which example is slow?
I go to examples, click on #3 "Oversized Canvas", then WebGL, then I get a blank screen.
I go back, still a blank screen.
I go back again and for a faint moment I can see the examples list and then it goes blank and the viewport becones very large because I can now scroll a lot but everything is blank.
Mobile Safari, latest iOS.
Yeah, I've been made aware that the examples don't work on iOS. I'm guessing there's a single underlying error that's messing with the navigation etc. since I believe SvelteKit does some JS-based optimizations around navigation. I'll have to look into this. Thanks for reporting!
This reminds me a little of the <shader-doodle> web component, which also works in any framework or plain HTML:
Really cool idea with doing it as a web component.
There's also Pocket Shader which is pure JS: https://github.com/braebo/pocket-shader
My question, from using ThreeJs and @react-three{fiber, drei} and seeing this site, is why I do I continue to use CSS & HTML? The question is what is important, not the answer.
In my experience there are times when building HTML CSS components is an anti-user pattern. I know HTML-CSS well, but is it the best experience for users? In some cases my answer is no.
In particular, with complex websites I believe that using graphic navigation is superior to other alternatives. When we want to navigate using {Google,Apple,Etc} maps we do not have a list of hierarchical menus. One does not navigate to the continents menu, then countries, then states, then cities, etc. You zoom out, you zoom in or you type a location. A user can quickly and easily go from a street view in NYC to a street view in Osaka.
I suspect that direct 3D graphics could be used in other situations, but have not had a chance to explore them. Low hanging fruit first.
(And yes, this is not a bug free system. Getting things to work across platforms, browsers, etc can be tedious. On the other hand most {iPhones, Android phones } seem to have strong graphics capabilities that make them able to handle a modicum of graphics. :-) )
You're using HTML when you go from a street view from NYC to Osaka. You exit NYC street view, use the HTML <input> tag to enter Osaka, maybe you even click the man in the bottom-right to enter street view again. You should be considering the maps canvas as an interactive element in an HTML-CSS page.
In a three.js-only webpage, will ads be embedded properly? Will the user be able to select the paragraph he is currently reading? Why reinvent the wheel when so much effort has been put into creating HTML/CSS/JS. Much of the page is rendered on the GPU anyway.
Also, in my case, just looking at the demo [1] makes my GPU work at 10%+15% vs 1%+0% of a normal static page (iGPU+dGPU, Intel UHD 630+NVIDIA Quadro P620). Though the linked page does apparently use a rendering loop, while the other examples are just as inexpensive as normal HTML+CSS pages.
> You should be considering the maps canvas as an interactive element in an HTML-CSS page.
this breaks down if my 2D/3D scene _is_ the page and has its own interactive elements and rendering tree which need to be managed with their own state and lifecycles. the killer app in google maps is the interactive map, not the inputs - the types of experiences possible on the web today go far beyond text/image content and forms.
>why I do I continue to use CSS & HTML?
Because you don't know how to write GLSL/WGSL, that things like font rendering end up requiring you to learn at best texture atlases, at worst SDF font rendering, and because you're quadrupling the time it takes you to do _anything_ because you're pixel bashing.
Oh and it's not accessible, which means you're going to get clapped by any audit, which means you're already eliminated from most places. Shaders have their place, for interactive, high speed components that you _explicitly_ don't want to make accessible by default.
Just fyi, Dark Reader (Firefox extension) completely broke the more interesting experiments and I had to disable it to see them. Only the 'square color gradient' experiments survived, for some reason.
The appropriate place to report this is dark reader's issue tracker.
What is a website maker to do with this info? An extension made to deface sites defaced my site? Expected behaviour.
Usually, the Dark Reader failure mode is that things look a bit off and you can tell that something is not working, which tells you as a user that you might have to disable it.
In this case, there simply was nothing shown for the affected experiments, which is somewhat unusual, and it took me a second to even realize it might be Dark Reader. I thought that could be useful feedback for the developer.
It is a widely used plugin. By me as well. And usually allmost all sites work.
So technically the developer of dark reader is the place to go. But if I would use svader - then I would have to be prepared to loose all that audience. (or at least use a sign to warn)
So giving that feedback is still valuable.
People don't care who is to blame. They care if it is working or not. (maybe there is something simple the dev of svader can do)
It works wonderfully until it fails miserably. At least, a couple years back that was the case. Someday, my local vision model will prefecth, take screenshots to check for my desired contrast, and iterate. Then the 3-5% of sites (perceived) that ruin rule based tools like DarkReader can finally perform reliably and not ruin our sleep or give us headaches.
> widely
Bullshit.
Your overall comment might apply to a consumer facing website, but your feedback is rubbish for some developer providing a proof-of-concept. mckirk made a perfectly good "fyi" comment because it didn't pressure the dev, while giving the dev a heads up _if_ they are interested and happen to read HN.
Firefox on a laptop is now a niche browser (3.35%) and is trending to be less popular than Opera (2.86%) and Samsung Internet (2.6%). Obviously HN selects for abnormal users: I actually like mckirk's comment because it is a beautiful reminder that there are niche users with interesting configurations and maybe I should have a look at that plugin. Nobody wants to be an entitled open source user.
>> widely
>
> Bullshit.
Dark Reader has >9 million total users across browsers as reported by the Chrome, Edge, Firefox, and Mac app stores [1][2][3][4]. That is definitely a very small percentage of total web browser users - with some estimates putting chrome users at 3.2 billion(!)[5], but 9 million users isn't something to scoff at either.
FWIW - I completely agree that mckirk's comment was a great passing "fyi" that doesn't put pressure on the dev. I also think it relevant to the original post (not some tangential common complaint, nor against the HN guidelines).
[1]: https://chromewebstore.google.com/detail/dark-reader/eimadpb...
[2]: https://microsoftedge.microsoft.com/addons/detail/dark-reade...
[3]: https://addons.mozilla.org/en-US/firefox/addon/darkreader/
[4]: https://apps.apple.com/us/app/dark-reader-for-safari/id14382...
[5]: https://www.statista.com/statistics/543218/worldwide-interne...
"Your overall comment might apply to a consumer facing website"
Svader is for making consumer facing websites. At least potentially.
"mckirk made a perfectly good "fyi" comment"
And was still downvoted for it. Hence my reaction.
"Firefox on a laptop is now a niche browser"
And I use dark reader on firefox as well as on chrome.
> downvoted
Correctly downvoted: 1. guidelines "Please don't complain about tangential annoyances", 2. HN site norms are enforced by downvotes - downvoting is correct by definition
Plus another important guideline is "Please don't comment about the voting on comments". I'm trying to help you moderate yourself - of course the next escalation is for this inane subthread (including my comments) to be flagged.
https://news.ycombinator.com/newsguidelines.html (edited: added more details)
You might as well quote the rule in full, if you are going to throw the guidelines around.
> Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
I think this makes it pretty clear that this guideline wasn't talking about people trying to provide helpful feedback for a developer, letting them know about a strange edge-case (i.e., why should an extension injecting CSS even mess with WebGL content?) that they might want to look into.
"Correctly downvoted: 1. guidelines "Please don't complain about tangential annoyances""
We disagree on "tangential annoyances". And that's it from my side.