Worrying about somebody using „Chrome data saver mode“ before your startup gets 100k hits per month means to me that your focus is completely off.
Instead, perhaps improve your core product and talk to actual users today?
See where the problem is?
No, I don't. In part because I don't tick boxes, I just (try to) build good shit. Also because I don't expect every UX "best practice" from [random internet authority] from a site with JS disabled. I just expect the text on the site to render somewhere readable.
Usually, the argument from the "js is bad" crowd, isn't that the site should be as functional with JS disabled... only... that the basic content... should still render...
If my current frontend framework of choice happens to not render any HTML without JS, I am sorry, my site will be inaccessible to you.
Because that frontend framework allows me to iterate much faster and improve my product for the vast majority of users.
It’s never been worth worrying about non JavaScript clients (except search engines)
That's probably the difference in experience then. I've been a software engineer for almost as long, but I'd never consider describing my work as just "web tech", and the engineers are all willing to make a reasonable minimum effort to at least render "something" without JS. The difference is probably between web developers, and software engineers generally.
My javascript user metric collecting service says all my users have JS...
Imagine that :P
> any rational business will refuse to invest resources to serve your unique needs.
I'm not convinced that's rational, but all the same. Any rational engineer would rather do the job correctly, rather than what's easy. Which is what the argument comes down to. One the minimum always works, the other way is easier (for you).
> If my current frontend framework of choice happens to not render any HTML without JS, I am sorry, my site will be inaccessible to you.
Don't be sorry in this case, if this is the tradeoff you've decided to make. That's totally fine. It's your project, and your code. You absolutely should make the decisions you think are best. I'm just some random idiot on the internet who thinks your decisions are bad, and your framework is a dumpster fire waiting to implode. I like to write code that works, and I think code that works in every case is objectively better than code that works in most cases, and is easier to write. But I suspect the code we write and projects we care about are very different.
The difference seems to be that I care more about the code than I do about the cash. You frame all decisions from the context of a business trying to make money. You're right when you say:
> Because that frontend framework allows me to iterate much faster and improve my product for the vast majority of users.
That is probably the best way to make the most money with the smallest expense. But I have a different set of standards for the work I do. And just to be clear, please note I didn't say my standards for my work are better than yours, only that they're different.
But your code does not work in every case:
Image a user that would like to access your website using an even older setup than simply no JS, let's say he's using lynx on a 50 by 20 character ssh session on an old Android phone with a broken keyboard.
Your website will look like shit, it will be absolutely unusable and the user will have a mental breakdown.
If you counter that your website is only one line of text that says "Hello world!", and that would work on my imaginary lynx setup, let me counter as well:
I am now a user that has no computer at all. I would like to access your content by calling. Where is the phone number I can call to talk to a human in my language, at 03:30am in the morning?
Remember, not everyone is using the latest technology! A company should be accessible even if the user doesn't have WASM/React/JS/CSS/HTML/HTTP/TCP/a computer/a Chomsky universal-grammar based spoken language/...
I think we all have edge cases we simply cannot serve. I agree that there might be different thresholds, though. :-)
I had enabled 'Do Not Track' in the browser, which broke the widget.
I'm sure the 3rd party provider regrets listening to the privacy nerd who insisted on supporting this header.
"Everyone has JavaScript, right?"
After reading the page...
...basically, yeah.