6 ms·

I do not think this is an issue for one very important reason: There is "Web-Apps" that just need JS and when deactivated it does not make sense at all to use t

• chrismorgan 6y ago
  To be sure, web apps do exist where not requiring JavaScript would be impossible or unreasonably difficult—though even so, most web apps don’t fit into this category. But the very nature of perceiving this dichotomy as acceptable is what leads to people making websites that require JS: people made web apps that rendered completely with React, saying to themselves that they didn’t need to support no-JS operation here, so now they were familiar with React, then when they went to make normal websites they used what they were familiar with, never mind that requiring JS was a bad idea here. Deciding that it was OK to break no-JS users for apps (still worse, normalising this) inevitably led to breaking no-JS users on sites. People talk about the good of web components not tied to any framework, but in practice it doesn’t tend to pan out that way. These things are a framework themselves, so now you probably have a whole extra framework for every such thing you use (though admittedly each will be a lot lighter than React or similar), and it forces you to work in a different way from what you’re used to within your main framework. People routinely end up wanting (or sometimes needing, especially when React is the root framework) tighter integrations between their frameworks, so they go wrapping the web components in a new layer, e.g. to get better types and tooling support, or to route events through their own system rather than the plain DOM events system, or to do something or other involving types that aren’t just strings. That last one is a major limitation and shortcoming of Web Components as a fully-general solution: if you’re passing in attributes, for example, it’s strings all the way, but people often want and sometimes need more complex things. As an example where this causes substantial inefficiency, imagine a chart element that needs an array of data; if it’s straight web components, you’ll be nudged firmly towards turning it into a bunch of elements, or serialising it as JSON and setting it as an attribute, where setting it as a property (something you can only do via JS, so you’ve lost the declarative nature of the element) will be way more efficient.
  • 1337shadow 6y ago
    Some things are just not going to work without JS: - file uploads, the browser fails to indicate that an upload is in progress, the user clicks "submit" again and again because they don't see that the browser is uploading, - file uploads when part of a form with other fields: if some text field doesn't validate, then the form will be shown again and the user will have to upload his file again, unless you go through the length of partially saving the form ... in which case you give up on having a nice transaction that saves the form at once - selects with at least thousands of choices, they will freeze the browser, you need an autocomplete So, as long as your website requires a file upload, or offers to select an option for a foreign key on a table with a lot of data then JS is required. Now, that might only be the case for a page or two, that doesn't prevent the rest of your site from working without JS because webcomponents aren't as invasive as typical JS frameworks that basically want to own all of your page. If you really want to pass JSON to your webcomponent it's pretty easy: <your-component><script type="text/json" slot="your-data">.. dump your json here</script></your-component> But, you could also render your stuff directly and let the webcomponent inspect the DOM and build its own data structure. Anyway, I fail to see the shortcoming here. WebComponents are not tied to any framework once they are built, or, if they were coded without. Shoelace doesn't require loading of any framework, but it's built with the brilliant StencilJS library: required to build, not to use. For me the only shortcoming is with browser based ES modules but they are being fixed with the ImportMap proposal.
    • chrismorgan 6y ago
      We’re kinda getting distracted from the original topic, but I’ll bite anyway. File uploads are just fine without JavaScript. Sure, some users will fail to notice the throbber and status bar text that indicate that the browser is sending the request and hit the submit button again. Unfortunate, but hardly destructive. And then if the form doesn’t validate? Yes, you should partially save the form. You typically have to do something like that when you implement all your validation in JavaScript anyway, because client-side validation is typically imperfect, and there are extra possibilities of failure on the server. The robust way of doing uploads in APIs of this style has always been to upload a blob, and then pass its ID to the form, so that you still have it if something goes wrong. Select with zillions of choices: that’s a terrible case for a select anyway; I’d be inclined to leave it as a text box and enhance from that. Purely out of interest (not because I would recommend it), I just ran an <input list=x><datalist id=x> with 10,000 options and it performed quite tolerably in Firefox. (When I type something that matches all 10,000 options it takes as much as a few hundred milliseconds to start displaying options, but it seems to load the options to present progressively, otherwise it’d have blocked for much longer than just a few hundred milliseconds.) But that means you’ve got to transfer all the options up-front, which might be otherwise unnecessary. Anyway, again you could implement it otherwise and I can even see how a full autocomplete (just, y’know, manual autocomplete) could work without JavaScript, using an iframe and formtarget=_parent. You’ve roused my interest, I’m going to put this on my list of fun technical demonstrations to make just because I can. I have a SSR/CSR hybrid framework in mind to make which will handle these sorts of things properly, using client-side scripting where beneficial and available but working as close to perfectly as possible without it. But I certainly wouldn’t recommend anyone go to the effort of trying to make something like this work without framework support; that’s a recipe for pain. In the short to medium term, this is a case where it’s quite reasonable to require JavaScript, because the framework tooling to handle it otherwise and do it well with both server-side and client-side rendering just doesn’t exist. In my comment I was not saying that JavaScript shouldn’t be used, but that in general you should make things so that they work in the absence of JavaScript, even if imperfectly. My remark on Web Components shortcomings wasn’t about passing JSON—which you can do in an attribute without difficulty, no need for a text/json script in general—it was at the fact that you need to do something like that, because all you have for representing things is DOM nodes. The shortcoming is that you can’t pass data structures and objects by identity to your component like you might with components in systems like React, Vue, Angular or Svelte. Instead, you have to serialise and deserialise constantly, which is wasteful, or else dodge out of its declarative nature and use properties instead of attributes, which is rather contrary to the design and concept of Web Components (and would broadly be anathema to Declarative Shadow DOM, contrasted to the likes of Svelte SSR + rehydration can if necessary relink things where object identity and exact data structures are valuable). I think you understand what I meant by “framework”. React is a framework: it requires that you write your code in such-and-such a way, upon which it offers such-and-such functionality. Web Components is a framework. StencilJS targets the Web Components framework, and by virtue of extra runtime code it provides or must generate, it’s kind of a framework itself.