> JavaScript is an integral part of the platform that is the web, just like HTML and CSS
I always think it's interesting when people bring CSS into this, because it's actually a very strong counter to the general argument.
By design a user agent is well within its rights to completely ignore any stylesheets attached to a page, and the idea was always that this should be completely OK, partly because you have no idea what the UA's capabilities are, up to and including whether or not it's doing any kind of visual rendering at all.
This isn't a news flash to everyone, but even those already aware of this seem to think the main reason you'd do this is ADA accommodations and those are some kind of minority afterthought. My experience is that this is misguided -- accommodations for unusual visitors is important, but I think the biggest benefit might be that the simpler you make things for the client, the less complicated the engineering tends be, even if you can't import your Java-imitation-of-smalltalk-inspired application paradigm of choice.
And "too bad if you didn't have JS!" position seems to basically boil down to the idea that serving a custom client that consumes JSON instead of HTML as the media type for a given URI is Real Progress™.
Keep things as simple as possible. Don't require JS unless what the application needs to do can't be done without it.
The problem is that arguments from both sides are often generalized and it's not necessarily wrong. If you have a wide audience e-commerce enterprise you should probably keep JS use as limited as possible. If you build tools for programmers or highly dynamic projects, JS everywhere is probably fine.
If you build tools for programmers, give me some way of interacting with it other than running your JS in my browser. Otherwise, I'm likely to find it horribly awkward to integrate with my preferred workflows, and I'm unlikely to use your project.
> By design a user agent is well within its rights to completely ignore any stylesheets attached to a page, and the idea was always that this should be completely OK, partly because you have no idea what the UA's capabilities are, up to and including whether or not it's doing any kind of visual rendering at all.
I think that is just an outdated idea that does not apply to highly interactive, long-lived web applications. The user agent is well within its rights to ignore anything it wants, of course, but the user agent is not owed anything by the server. With CSS, or JavaScript, the app may just not work.
> With CSS, or JavaScript, the app may just not work.
When it comes to CSS, generally most apps will continue to work even if the CSS is simply ignored.
Because that was one big point of CSS. Separation of presentation from content and function.
It's funny. That kind of separation of concerns is something developers talk about valuing, but the SPA/webapp craze erodes the user-facing aspect of it, even while developers are very proud to demonstrate they're thinking hard about which specific kind of separated-concern architecture they're working with well away from the boundary where an outside user or UA would care.
I always think it's interesting when people bring CSS into this, because it's actually a very strong counter to the general argument.
By design a user agent is well within its rights to completely ignore any stylesheets attached to a page, and the idea was always that this should be completely OK, partly because you have no idea what the UA's capabilities are, up to and including whether or not it's doing any kind of visual rendering at all.
This isn't a news flash to everyone, but even those already aware of this seem to think the main reason you'd do this is ADA accommodations and those are some kind of minority afterthought. My experience is that this is misguided -- accommodations for unusual visitors is important, but I think the biggest benefit might be that the simpler you make things for the client, the less complicated the engineering tends be, even if you can't import your Java-imitation-of-smalltalk-inspired application paradigm of choice.
And "too bad if you didn't have JS!" position seems to basically boil down to the idea that serving a custom client that consumes JSON instead of HTML as the media type for a given URI is Real Progress™.
Keep things as simple as possible. Don't require JS unless what the application needs to do can't be done without it.