Matt Strom The thing is do you have to meet accessibility minimums or not? Remember, if core functionality is not provided scripting off you have made an INSTANT WCAG violation, no matter how many ignorant twaddles try to quote the part about the PRESENCE of JavaScript not being a violation out of ignorance. (and possible literacy issues).
Facebook is a STUNNING example of the types of bloated messes that my clients get saddled with thanks to this type of ignorant garbage approaches to site-building. It's not built with progressive enhancement, it has ZERO graceful degradation for ANY of the technologies it uses, AND it's a bloated mess that's probably costing them more to host than it should.
They're just lucky enough to have gotten big enough they can afford to tell 10-15% of the populace to f* off.
Right now if I load up my FB timeline, it is serving me 319k of CSS spanning 59 files when there is NO excuse apart from ineptitude for them to be serving more than 48k in one file -- I'd allow two -- apart from complete ignorance of how to use HTML and CSS properly. (at least if we're talking just screen media). It sends 3.8 MEGABYTES of JavaScript spreading its girth out over 156 separate files when I don't see a DAMNED Thing being done warranting the presence of more than around 128k of scripting (before minification!), again in a SINGLE file, and I'd be SURPRISED if it got that high since I'm "Mr. Scott'ing" that figure . They basically scripttard in ALL the content, SO WHAT IN THE BLUE HUFFING BLAZES ARE THEY WASTING 736K OF MARKUP ON?!?
DEERRRRRP!!!
It's a giant middle finger to usability and accessibility, and the slopped together nature of it must make it a maintenance and development nightmare to work with. It easily wastes nearly 5 megabytes of client-side code vomited up in over 200 separate files doing the JOB of probably less than 256k in 3 to 5 files.
EVEN if you didn't care about the accessibility woes, it's a bloated train wreck of how NOT to build a website, using easily twenty times the code needed to do the job. BUT I bet every single joker who worked on it will defend tooth and nail the various dumbass approaches used to build it as somehow magically being "easier".
Because when I think easier, I think ignoring good practices, slopping together off the shelf code 90%+ of the people working on it can't even explain, pissing away handshakes increasing network overhead for nothing, and writing ten to twenty times the code needed to do the job. Aka what front-end frameworks seem to inherently do!
... and honestly, I could say much the same about Hashnode. I know a number of developers who won't touch this place JUST because of the accessibility failings and lack of scripting off usability.
My "experience" with it was typical of my experiences with most of this recent "paradigm" nonsense -- a bloated mess taking something simple, complicating the piss out of it... and then screwing over a client who I'm brought in to help out of the mess.
In this case some JS junkie had used it for an electric company's payment portal... which was a US EQA violation resulting in a class action suite. The answer to their problem -- JUST like when I deal with React, vue, and all the rest of this scripttard trash was grab it by the nertz and rip it out -- replacing it with letting HTML and conventional website behavior doing the damned job they were designed for.
I GUESS if you were making full stack crapplets it MIGHT serve a purpose, but it seems to me like just another overthinking of the simple and replicating with some dumbass "sequence" rubbish stuff you can do as easily, simpler, or at least more understandably without the excess code and bizzaroland approach to handling things.
That and it seems to also be great for people who can't seem to keep track of scope in event callbacks. I don't have that problem.
... but really, lands sake keep it the HELL away from web-facing front-ends!