1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
|
---
title: "It's Near Impossible to Use NoScript but the Future Is Bright"
categories:
- blog
abstract: My fight against the overuse of JS may not be futile
date: 2023-03-12T06:03:22+01:00
year: 2023
draft: false
tags:
- javascript
- privacy
- Hot-Wire
- React
- Next-js
- Hugo
- Internet
- software-engineering
- SSR
- server-side-rendering
---
{{<img-pull-right "js-old-logo.png" "javascript">}}
Speaking of [Javascript](/tags/javascript), I have tried to use NoScript for the last couple of weeks. My goal was to reduce my internet trail even more, as [PrivacyBadger](https://privacybadger.org/) and a few other extensions still leave a considerable chance to spy on me. In addition, I have a huge issue with allowing my computer to run random code without my consent. It's a security nightmare!
Turns out, that JS has taken over the internet more than I anticipated. React became the primary building block of most of the internet. It doesn't matter if you see a single paragraph of text - you most like see what JS has rendered. This site uses JS for statistics, but it works based on HTML alone. This was always my goal—JS as a bonus, not a hard requirement.
JS is great for web applications - I can't disagree with it. It's the language for SASS companies - like the [one](https://zendesk.com) I work in. It has evolved a lot, and it's nice to use now. But it's so overused!
There are webpages where disabled JS breaks some functionality - mostly search (why are we waging war against ctrl+f?) or menu. It's terrible, but it gets much worse.
There are now a lot (and I mean A LOT) of web pages where without JS, all you are able to see is a white background. Everything is rendered dynamically. Single Page Applications - very complex systems are used where a static HTML would be sufficient.
But not all is lost. A few years ago, [Hot Wire](https://hotwired.dev/) came borrowing ideas from older frameworks, and it proposed a solution where you get a full HTML webpage from the backend, and then progressively on subsequent pages, your browser can fetch just the changed parts. It was not a novel idea; we've seen it all before. But it came from Basecamp, so it made a buzz on the interwebs. And the response was tragic. Younger developers raised on React thought of rendering webpages on the backend as something only graybeards would like. The backend is just to return JSON! And for all the dull business logic, of course.
A few years have passed, and [Next.js](https://nextjs.org/) has a crazy idea of rendering React apps on the backend. And suddenly, it's all the rave. Who could have thought that showing just HTML may be faster than fetching megabytes of Javascript code? It even has a name for it now - Server Side Rendering. So we came full circle, just with the extra layer of complexity needed to make it work seamlessly. The added benefit is that since every subpage can be downloaded in any order, disabled JS doesn't break the entire webpage!
This site is 80% there, as I use [Hugo](https://gohugo.ihttps://pagespeed.web.dev/report?url=https%3A%2F%2Fd-s.sh%2Fo/) to generate static HTML files. All that's missing is a mechanism to not re-render the entire DOM on each subpage. But who needs it? It's a simple blog. The simpler, the better. Hugo + rsync, that's all. I still get perfect scores on [Google Speed Index](https://pagespeed.web.dev/report?url=https%3A%2F%2Fd-s.sh%2F).
The future is bright, but today is not. To actually browse the web, I need to constantly allow domains or even temporarily disable blocking in a given tab. And it's hell.
|
