3 ms·
> 1. Why aren’t they saying this in their <noscript> > 2. There’s a lot of content on the page that should be purely static like the FAQs. We can see using a n
by x-complexity 3y ago
> 1. Why aren’t they saying this in their <noscript>
> 2. There’s a lot of content on the page that should be purely static like the FAQs. We can see using a non-Google search like https://search.brave.com/search?q=kzg+ethereum+ceremony https://search.brave.com/search?q=kzg+ethereum+ceremony and see the SEO for all that data is missing because it requires JS without a good reason.
https://github.com/zkparty/trusted-setup-frontend https://github.com/zkparty/trusted-setup-frontend
Occam's razor: Because they didn't think they'd need to put any additional message other than "Please enable JS", since almost everyone enables it.
It's likely they were "build the use case first" when going through with it, and that addressing "no JS" & SEO were not high on that priority list.
- toastal 3y agoHanlon’s razor or ignornace is more likely than that. This message comes with the default framework and someone didn’t know they should check (and we should fault the framework for not throwing a build exception for missing noscript rather than inserting a useless one). You can sum up what the site is and what’s missing in 1–3 sentences and have a massively better noscript experience, but this is the sort of thing that needs to be in project requirements. If you add these to your requirements to a project, you'll ultimately find the path of least resistance was to choose a framework/mindset that didn’t involve at unnecessary virtual DOM no 95% of the time render static (not dynamic) content. Adding a message to enable JS to add to the entropy gives users a simple, actionable message.