If JS is disabled the client still gets the initial HTML render (no white screen of death) but no live updating as the channel/LV process won’t be subsequently instantiated.
I can’t find it now but I thought he mentioned in this podcast if you were just doing a form you could write a fallback where it POSTs to a controller without needing form state held in the LV process. Of course then you’d need extra code to render the validation error messages server-side after the POST. I doubt any use-case more complex than a standard form is possible with JS disabled.
Although my last job (very much big corporate) had some terminals super locked down like that too though.
Not uncommon in my experiences… ^.^;
On my own devices I use uMatrix though, I like fine-grained whitelisting. Can’t recommend it enough! ^.^
Depends on who it’s being made for. And it definitely doesn’t hurt to keep ADA compliance in mind anymore as it’s been hitting some places hard lately!
That is why should always ‘start’ with the basics so you know they work, then just ‘enhance’ after that with whatever pretty things or special features or so. Like I use GraphQL, but not on the client-page side. ^.^
Honestly such messages are amazingly rude to people that use screen readers. I saw one here go off on a rant once… >.>
Eh, you really aren’t that demographic though, that doesn’t make the demographic that you are in the entire world though. Working at a college really shows me how very important it is to have proper fallbacks (I didn’t really care either before here to be honest…).
Eh, it’s not an “old” thing (although I am stuck on GUI-less consoles quite often) for most, but rather a compliance thing so it is actually useful. People with visual and/or motor disabilities are far far more common than one would think.
Yes I thought I recalled the comment on the client getting an initial HTML render, which would be wonderful as far as I’m concerned. I wasn’t sure if I had heard that correctly though, like if it was in Chris’ video or in that Elixir Mix episode or elsewhere.
Either way I’m pretty stoked to mess around with this thing. It’s great how much focus there has generally been lately in the community around creating interfaces (scenic etc).
The initial request is just a plain old HTTP request and HTML response, so screen readers and crawlers will see the LiveView’s static HTML. After render, the browser reconnects and the LiveView process is spawned on the server.
A company (or just an individual developer that values their time) building apps needs to consider whether a) that 0.2 - 0.7% represents their target demographic, and b) whether the have the time/resources/interest in creating (often large-scale, and sometimes unfeasible) workarounds for JS-only functionality to serve that traffic.
GraphQL on the client-side is one of its major selling points.
In ReactQL, the out-the-box demo component I provide pulls stories from HackerNews via SSR and delivers the result in React-rendered HTML:
Subsequent requests to a GraphQL API server (or routing) are performed on the client, cutting out the need to round-trip to a server to rebuild HTML.
This leverages the capabilities of 99%+ of browsers in exactly what they were designed to do.
^^^ Server rendered initial HTML answers that concern.
Well, yeah. If your demographic isn’t ‘the world’, then design accordingly. That goes without saying.
None of the apps I’ve built the past decade, for myself or for clients, have been for government departments with locked-down JS.
Right, but it’s still exceedingly uncommon to consume a website - as an individual user - outside of Chrome/Safari/Edge, even with a screen reader. And if you’re surfing without a GUI, you can’t expect a site to accommodate this slim use-case beyond basic HTML.
Fewer sites/apps these days even make sense in a HTTP verb-only context. There wouldn’t even be ‘static’ ways to represent functionality of most of the things I typically build now beyond the initial HTML render.
That’s from a UK-centric survey, worldwide the value seems to average 1.1% with some countries averaging well over 2% and TOR users averaging over 10%, so it all depends on your focus as well.
Yep, that’s the useful thing of using it everywhere, you know it works and is well tested, and its trivial for a client to progressively enhance to use it while working without JS.
Not at the college here (well not any JS above some ancient standard, not even react works with it).
Those sound like ones that are browser addons, the ones we are required to use are not because they reach a required level of ADA compliance for the college.
That’s been my life for the past… wow its been over 10 years of work now… >.>