-
-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make website accessible without JavaScript #32
Comments
Yes, this is not the way this would be done in production, but it's what I wanted to do. I've long been planning to make the site work without JS as well, but never got to it. We can discuss making the site work much better w/o JS, but I'm not willing to replace Yew for the interactive parts of the site (or doing a full page load for navigation when JS & WASM are available). I don't think there are currently realistic ways of running Yew server-side, otherwise that could be an option too, although you are right that most of the site could be generated statically. |
Right, you can of course use whatever you want. I implemented the frontend I had in mind at https://rust-features.push-f.com/. It works without JavaScript ... if you want to you can link it in your
|
@not-my-profile Worth mentioning that it's done already: https://caniuse.rs/features.json |
Currently https://caniuse.rs/ requires both JavaScript and WebAssembly. If you lack one of those you just get a blank page.
I think we can make the site more accessible as well as greatly simplify its build process:
main.rs
would just generate a bunch of static.html
files along with a single.json
file containing all feature data (which by the way is also what caniuse.com is doing)For the search we could use the same setup that mdBook is using: elasticlunr.js + elasticlunr-rs to have the search index be generated statically. I think the resulting search would be even more performant than the current search (I have a noticable lag when starting to type).
Of course the optional search part could also be implemented in Rust & WASM but I really don't think that there is any good reason for that ... it just significantly increases both the build as well as the runtime dependencies.
The text was updated successfully, but these errors were encountered: