31–40 of 159 posts
Earlier quoted context omitted.
The problem is that JavaScript is used for tons of garbage purposes too. I wish for more control in my browser over what is running
Faulting a technology for its malicious uses is a common fallacy, but a fallacy nonetheless. Not saying you're wrong (you're not), but it's not a valid argument against JavaScript.
I guess it depends if your website does something valuable or substantial. If it's just your hobby site... great, develop it without JS. But if it's a site people pay to access (or requires ads) and they expect some functionality - like Youtube or Netflix say - I don't think this is possible.
As far as I understand it, YouTube and Netflix are a nicer UX with JS but there’s no particular feature that would kill it completely.
Like, for example, I thought that you can play HLS* manifests from plain HTML5 video tags.
EDIT: I was thinking of HLS and not DASH
Quoted post unavailable.
I’ve found that the best browsing for me has been a result of disabling HTML and CSS as well. No errors, 0 load time, accessible to anyone even if they don’t have a computer or internet connection. Websites built without JS is cute but if you’re serious about fast, accessible, error-free browsing then using HTML and CSS is really just bloat.
[1] - https://ip.ohblog.org/
Earlier quoted context omitted.
The problem is that JavaScript is used for tons of garbage purposes too. I wish for more control in my browser over what is running
Faulting a technology for its malicious uses is a common fallacy, but a fallacy nonetheless. Not saying you're wrong (you're not), but it's not a valid argument against JavaScript.
This is why things being generally available that have the potential to be harmful causes such a debate, because on the one hand it’s useful, on the other it’s harmful.
The reason people blame the tool is because the tool enabled people to be able to maximise their harm, and people will maximise harm when given the opportunity.
In this case: JavaScript enables people to externalise their processing cost into people’s own computers, which is a huge potential for harm as it’s a really asymmetric power dynamic.
Quoted post unavailable.
Does Next SSR like this also submit traditional web forms and handle them server side? Or would that count as the 20% that's unsupported?
A form is just an bunch of input fields and a submit handler.
If you write your fields as real HTML input fields (instead of, say, weird bespoke divs that happen to have key handlers, yuck), you can still add JS to them for autocomplete and validation and such. But they'll still work without JS.
The other part is the submit handler. If you capture the submit button onclick to do something (like submit it using AJAX) then that won't work. But it's easy to add a HTTP POST fallback, and honestly that should be a best practice with or without Next. It's been like that since the jQuery days and before.
Beyond that, I can't think of anything specifically involved in SSR that would affect forms. Have an example?
Edit 1: If you're using a third-party module/framework/service to create a form, whether it will work with JS depends on its specific implementation. The MUI framework, for example, has higher-order form input abstractions (like the component here https://mui.com/base/react-input/#introduction) that depend on React and JS, but are really just wrappers around the HTML element. It will still accept text without JS, just lose some of its secondary features. On the other hand, with something like Typeform... I couldn't even get the actual form to load without JS enabled: https://www.typeform.com/templates/t/demo-feedback-form-temp...
Edit 2: I thought of another way to interpret your question. In addition to the frontend parts of Next, which the above addresses, Next also has API endpoints and edge functions that can act as form handlers if you want them to. That only works if you're hosting on a live Node server (like Vercel), not if you're baking to static clientside HTML for CDN distribution. (The difference between `next start` and `next build`)
But that's kinda a tortured way to deal with form submissions. Usually the webforms would POST to someplace that's a preexisting business requirement (a Salesforce or Hubspot endpoint, for example, or even an email address), so you don't really have to use the Next middleware to handle submissions. You COULD do that in Next if you really wanted to, but I wouldn't myself... it would just be reinventing the wheel for no good reason.
Quoted post unavailable.
All I mean to convey is that the likes of Next.js aren’t a panacea: you do still need to be aware of what’s going on and sometimes adapt your code to work with Next.js. 80%, as you said.
And as an example of another sort of unnecessary brokenness, there’s a “Show more” later in that page that should have been serialised as a element, but it’s done as a . Here the lesson is: lean on what HTML offers, where possible.
If it's really that hard for you to prerender a page on the server, then just send the text by itself. Can you do that? I don't need you to prerender your header, your footer, your menus, or any of that junk. Give me the text body. Place it in an element your JavaScript code can replace when it boots, if I choose to let it run at all, which I won't if I can avoid it.