A short exploration of a method for building websites that work without JS, while still enjoying the convenience of modern frontend and backend technologies - with live coding!
![Node Congress 2023](https://gitnation.imgix.net/stichting-frontend-amsterdam/image/upload/v1619376938/eav9rff77rtiyz7qse5v.jpg?auto=format,compress&fit=scale&w=60)
Level: intermediate
A short exploration of a method for building websites that work without JS, while still enjoying the convenience of modern frontend and backend technologies - with live coding!
The main advantage of using Next.js and Redux for no-script web apps is the ability to create applications that function seamlessly both with and without JavaScript enabled in the browser. This approach allows for consistent performance and user experience by ensuring the same HTML is rendered and state management is maintained across both scenarios.
Individuals may choose to disable JavaScript for several reasons including improved performance, faster load times, fewer interruptions like popups, enhanced privacy by avoiding tracking scripts, and increased security by mitigating risks like cross-site scripting and other vulnerabilities associated with ad networks.
Web applications can function without JavaScript by utilizing server-side processing and forms to manage interactions. When JavaScript is disabled, actions like button clicks result in form submissions that are processed server-side, allowing the server to handle state management and rendering of the updated application state.
In the no-script version, instead of using JavaScript event handlers, buttons were wrapped in forms. These forms handle submissions directly, sending the action to the server when JavaScript is disabled. When JavaScript is enabled, the default form submission is prevented, and actions are handled client-side.
Yes, async actions can be handled in a no-script web app by passing the name of an action creator to the server. The server then awaits the dispatch of the action creator, processes the action asynchronously, and updates the state accordingly, ensuring the functionality remains consistent with or without JavaScript.
Potential drawbacks include increased server load due to handling more actions server-side, potential loss of dynamic client-side interactions like animations or immediate feedback, and additional complexity in managing forms and submissions for every user interaction.
Styles in no-script scenarios can still be applied as usual, though some issues may arise in development mode with frameworks like Next.js. In production, styles should render correctly even if JavaScript is disabled, ensuring the visual appearance remains consistent.
This Talk explores developing web applications that work without JavaScript enabled in the browser, while still enjoying the benefits of modern web technologies. The speaker demonstrates converting an existing application to work without JavaScript by wrapping buttons in a form and preventing the default submit event. React helpers are introduced to handle async actions and the speaker shows how to make a counter app work without JavaScript by removing unnecessary callbacks and changing buttons to a button component. The talk also covers adding a form and a surprise feature, and emphasizes that by leveraging forms and an event-based store, applications can seamlessly work with or without JavaScript.
In this talk, I will explore a method to develop applications that work without JavaScript enabled in the browser while still enjoying the benefits of modern web technologies. I will show you a TodoMEC application that works with and without JavaScript. There are several reasons why someone would disable JavaScript, including performance, fewer popups, faster load times, and increased security. I added making my wishlist service work without JavaScript to my task list because it's privacy-friendly and can function without JavaScript. However, I didn't know how to achieve this with Redux and server-side rendering.
Hi, my name is Daniel and I'm a web developer and a privacy enthusiast based in Oslo, Norway. Thank you for tuning in to this talk about using Next.js and Redux for epic no-script web apps, which will be a short exploration of a method that will enable you to develop applications that work without JavaScript enabled in the browser while still enjoying the benefits and convenience of modern web technologies when making them.
Right off the bat, I want to show you this. This is your standard TodoMEC application, where you can add stuff, edit stuff, check stuff off, filter them and clear them. And here it is again. And I want you to pay close attention and see if you can spot any difference. So we can add stuff, we can say whoops, and edit stuff, check off stuff, apply some filters and we can clear them. So, notice anything? Well, this last one was entirely without JavaScript in the browser. And what's so exciting is that this was both the exact same React application, the exact same HTML rendered to the DOM. And I find that pretty cool, that we can have one application that seamlessly works both with and without JavaScript.
But why would anyone disable JavaScript in the first place? Well, there are several reasons, actually. One of them is performance. When there's no JavaScript running in the background, then your computer has more resources to do other stuff. Another one is fewer popups. When you disable JavaScript, you don't have any of the pull screen newsletter signups or slides up from the bottom, scroll hogging or content that are suddenly applied to the website that makes the scrolling jump and stuff like that. You also have faster load times, as obviously you're not loading the JavaScript, so the page will load faster. And a contributing factor to that is that you're not loading the tracking scripts and the ad networks that in themselves aren't really wanted most of the time. Some users will also disable JavaScript because of increased security. There are examples in the past where ad networks have been used as an attack vector for browser vulnerabilities. And by disabling JavaScript, you avoid them and you also avoid stuff like cross-site scripting. I run a wishlist service called Wishigift. And back in 2018, I added this to the task list, make the site work without JavaScript. Because it's a privacy-friendly wishlist service, and I figure that maybe our most privacy-minded users would like to have an experience that works without JavaScript. And also it's nice to be able to post something on Hacker News without the comments saying that this doesn't work without JavaScript. But also because it's the kind of website that can work without JavaScript or perhaps even should, I don't have any WebGL experiences, or I'm not using any web APIs in a heavy way. It's basically a glorified CRUD application, as are many other applications. And I think that those kinds of websites that can work without JavaScript also should. But I had no idea how. I was using Redux for absolutely everything. And I also dabbled a bit in server-side rendering.
To convert an existing application to work without JavaScript, wrap buttons in a form and prevent the default submit event. If JavaScript is enabled, the event is prevented, and the action is dispatched client-side. If JavaScript is disabled, the request hits the server, and the server dispatches the action and re-renders the application server-side. The resulting state and HTML are the same in both scenarios.
So I just started some background processing. Asked myself, what's available when JavaScript is disabled? It's just HTML and CSS. Okay. How can I convert this already existing application to one that works without JavaScript? No idea. And how can I do it in a way that's maintainable? Because I didn't want to have two separate codebases that would need to be maintained.
Well, fast forward to 2020, and I think I wake up one day, and my mind has put some pieces together. I realized that one of the tenets of Redux, which is thou shalt only put serializable values in state or actions, goes very well with, or actually aligns perfectly with a certain type of payload that's also serializable. Well, talking about forms, the solution was there all along. Instead of having standalone buttons, I could simply wrap them in a form and prevent default on the submit so that if there was JavaScript enabled, the event would be prevented. And if there wasn't, well, it just hit the server and we can have our server dispatch whatever action that we want to perform.
So instead of having just a simple click handler on a button, instead we do something like this. We wrap it in a form and set the action to just an empty string so that when you submit this form, it's going to be sent to the same route that we're already at, which means a view route. And we make the assumption that the only reason why anyone would ever do a post request to a view routes is because they are submitting this kind of form that wraps an action that they want to perform. And inside it, we embed the current state or the client state, the app state and also the kind of action that we want to be dispatched. And we will replace our button type button with a submit button. And you can also omit the type attribute here.
Then in our app.js, if you're using Next.js that is, we have this get initial props, and we check for if this is a post request, well, then we want to read the body and the body will look something like this. It'll have an action type, for example, and the state. And we pass that along to a helper function. Now we'll parse the payload. Using the callback that we supplied, getReduxStore, it'll take the parsed state in the payload and create a new ReduxStore with that. And also dispatch the action in the payload to that ReduxStore and return the updated ReduxStore and the updated state. Then we can assign that to our preloaded state and re-render our application with that state.
So when JavaScript is enabled, user clicks the button, the event is prevented and the action is dispatched. State is updated and the React application re-renders client side. And it's quite similar when JavaScript is disabled, except that we can't prevent default. So the request will hit the server and our server will parse the payload and dispatch the action, get the updated state and re-render the React application server-side. And in both scenarios, the end result is the exact same. The state you end up with is exactly the same. And also, the HTML is exactly the same.
We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career
Comments