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 them. Look at apps like [Prezi](https://prezi.com/) as an example.
I concur that normal content like news articles should still be accessible without activating any JS at all.
The idea of real web components not bound to any of these fancy JS frameworks that die and get replaced so quickly nowadays is amazing in my opinion.
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.
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.
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.
There's also no reason to expect browsers to become anything more than poor man's window decorations for webkit/etc, cause it didn't happen for three decades. We're on our own here and that ain't gonna change.
He's describing only SOME ways to solve those use-cases. No way I'm trading extensibility and programmability of a browser for something some guy thought up to be 'ideal' solution to those cases.
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.
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.
> I’m not saying that JavaScript shouldn’t be used, but that the absence of JavaScript should be supported in general, even if it isn’t perfect.
Aside from an SEO perspective, I don't understand why this is still such a popular perspective. JavaScript is so ubiquitous that turning it off is akin to removing the wheels from a car and expecting it to drive. Perhaps some cars will, but would you really want to take a trip in it?
To your point, I tried disabling JS on Amazon recently and I was able to make a purchase, but the website felt broken, the product preview carousel didn't work, and I definitely didn't want to use it like that again. IMO, you can't disable JavaScript in 2020 and have a good web experience.
I have js disabled by default for years now, mainly because for the type of content I randomly access, the percieved speed is a whole lot faster. E.g. I can start reading an article immediatly instead of waiting for content to stop jumping around or watching a spinner while a couple 100 kloc worth of js load an convert a bunch text in json to a bunch of text in html.
As an additional bonus I can get trough reading an entire article without newsletter signup modals being shoven down my throat.
For sites I use regularly and I as a user benefit from more interactivity not just the advertisers, I hit the toggle switch to activate js.
But I dont think this is a particularly popular or that common a perspectice. If it werent for fear of a SEO penalty the web would be much less usable without js activated.
> I can start reading an article immediatly instead of waiting for content to stop jumping around or watching a spinner while a couple 100 kloc worth of js load an convert a bunch text in json to a bunch of text in html.
I absolutely understand this point. It's the most frustrating thing about this decade of the web or, really, ever since browsers disabled popups.
However, I don't think this is a case against JavaScript as much as it is about poor web design practices. This is what happens when websites force feed visitors garbage to get clicks and when developers add things without regard to performance.
I'm not against JavaScript (or any other languages running in the browser for that matter). Ironically, when I started doing this I was a full time frontend dev.
For me this was just a "hack" to significantly improve my browsing experience. While I'm not advocating people doing the same, I disagree with the sentiment that absolutely everything is an app and static documents being an archaic concept.
One of my gripe is with people claiming that the absolute priority is the user and their experience, while all they really care about is conversion numbers and how quickly the devs can churn out new features.
And the other aspect is the same why I don't like this image so popular with product managers
While I do get and agree with the main point they are making, the image also implies that the more complex a product is, the better. But a car is not inherently better, more useful than a bicycle. The latter will outperform it in many use cases.
I see it the same with websites/apps. If you are building an browser based photoshop alternative, by all means throw all the shiny tools and frameworks at it, I'm willing to let it load a little and I'm not expecting it to work blazingly fast on a 50$ phone and a spotty 3G connection. But for a textual content based website, maybe consider letting the user just hop on and get going.
And I do think framework independent web components are the way to go for this btw.
Well maybe one could argue that you can have a decent browsing experience, I like to be able to view content without JS enabled (I'm a uMatrix user myself).
But as you say, as soon as you want to do something like a form that's a bit complicated then of course some browser side interactivity is going to be very helpful.
But your point makes a lot of sense, really what we all hate is when a page slows down your computer because it loads a gazillion of ad scripts and all. Some scripts is ok, if the site works after I enable the first scripts that seem legit to me then I'll save the config and move on with my life.
Thanks to you for sharing your code ! We're lucky to have Shoelace and you ;)
Agreed, but this is also due to the population that hn targets ...
Also, as soon as you want to do something that's a bit more complicated than displaying a textarea and a handful of inputs or selects in a profile page, then JS is going to help a improving UX a lot ...
TBH it feels to me that webcomponent pages load faster than Vue/React/Angular sites, so at least that's an interesting compromise.
I agree in theory, but really HN is lacking some features which would make it more enjoyable all which would likely need minimal JS, e.g. sorting, notifications, and some better way to read multi-page discussions. You will likely never read this comment since HN has no notification concept!
Neither sorting nor notifications require any JavaScript whatsoever. As an example, old Reddit has sorting and notifications and handles them all server-side with no JavaScript required. “A better way to read multi-page discussions” is too vague for me to comment on.
And it doesn't cut it for a foreign key: it can't even have a separate option value and label like the basic select ... Well, it sort of can, but then the user sees the value of the option (the related row id in the context of a CRUD) and not the label ...
Does that mean that when I choose "something" and go back to my form again i will see "123" because "123" is the id of "something" on the remote row ?
I must be doing it wrong ... otherwise, it's far from acceptable UX.
You seem almost to be deliberately fabricating problems. In this case the solution seems rather obvious: you would put the label as the value, and resolve the label back to an ID on the backend. Just as you’d be checking the ID on the backend anyway, to make sure it’s valid.
Yes, this could be a problem if the label is not unique. But if that could happen you already had problems, because how was the user supposed to tell which “ACME Inc.” they were supposed to click on?
I'm sorry to make you feel this way, I'm fine ignoring the typical customer that will not accept such an UX for the shake of the discussion, I'm fine with having unique labels even though that means that I would either have to store them in the DB, either rebuild them, for example, in the case of "<firstname> <lastname> (<email>)", I'm afraid a user could do a typo in-between selection and form submission, for example while opening the form on an existing object to modify another field (users do mis-click, and give me a call), in this case, should I be showing the input with the data that contains the typo so that the user can see it and delete the value and start over ?
Also I know users would be happier if I could display some kind of image along with the labels like an avatar, to make a form (boring by definition?) more lively. Do you really believe it was a mistake to make select fields accept a different label and value ? If not, then why don't the input+datalist do the same ?
And even then, what's the equivalent of a select multiple based on an input+datalist ? Please, forgive my ignorance, but I don't understand how to allow multiple selection with a datalist and an input and no JS, without having the user submit the form for each choice they want to add.
I to filter the datalist choices based on another field value without JS ? for example, a country field that would filter users.
How can I have a datalist of countries and a datalist of cities, so that you get to choose your city based on the country ? Do I have to omit the Country field and show 300k cities ? Do you realize how many cities are named "Springfield" ? The datalist would have to propose like 50 results at the time and the user would have to search through them (assuming their browser could load the 300k cities without crashing), wouldn't it be much better to first have a country and then state or region selector to make it easier for them ?
I'm not trying to create problems, I'm trying to find solution for problems that users actually have ... And I have a repo that does /just/ that with a very specific backend framework and has 1400+ stars so the problem seems pretty real to me ...
I was never proposing datalist as a solution, far less a general one (it’s definitely not!), just pointing out its existence and potential suitability for some cases, and as a point of interest.
You can typically get a really long way with just plain text boxes, and then if they produce an invalid or probably-incorrect value, prompt them “did you mean such-and-such?” (and either force them to select a correct value or allow them to say “no, I really meant what I typed”). In fact this would sometimes be better than the types of combo boxes or autocompleting dropdowns people often use, which often have poorly-implemented failure flows (e.g. if you have to choose a valid value and it’s fetching valid values from the backend, and it makes you wait a second until the response comes back, ever time, or else it’ll forget you typed anything). And it can combine with live JS-powered validation if desired, or not.
Especially for addresses, I find the approach of allowing almost freeform text entry and then proposing ways of massaging it into shape to be excellent. Either one totally freeform field, or a series of text boxes depending on the country—and isn’t it an issue that we often put the country field last even when it can affect the understanding of earlier fields! But it’s technically more difficult to do this and requires extra functionality probably on the backend or via some external API to do well (to say nothing of countries with, shall we say, massage-resistant addresses), so software developers tend to do things the technically-trivial way rather than the more adventurous way that, if done well, will be better for users. (And perhaps it’s just as well, because if done badly it would be much worse.)
But really, most of what I’m talking about is just thinking about the no-JS behaviour, particularly when designing things from scratch. When you have an existing system that already doesn’t want to work that way you’re kinda stuck, but greenfield developments are a good time to lay down the right foundations.
I concur that normal content like news articles should still be accessible without activating any JS at all.
The idea of real web components not bound to any of these fancy JS frameworks that die and get replaced so quickly nowadays is amazing in my opinion.