5 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.
    • DaiPlusPlus 6y ago
      What you’re describing are all inadequacies in current browsers to deliver a good user-experience for native HTML features. There’s no reason why browsers can’t show upload progress/status for non-AJAX uploads, and there’s no reason for browsers to keep on having poor <select> UX. etc. JavaScript itself is a workaround - it shouldn’t be the solution.
      • 1337shadow 6y ago
        If some field of the form doesn't validate then upload has to start over, unless you store the file in some tempdir and add it to the session and go through that kind of length. What exactly do you suggest to fix select ? Even if it was parsing a JSON blob, you still have thousands of results, an autocompletion endpoint seems much more efficient.