GitLab is mentioned on the advocacy page https://giveupgithub.org/. GitLab is an open-core business, which means there is a permissively licensed FOSS version and a proprietary version. The gitlab.com website uses the proprietary version. In addition many features of GitLab don't work at all or work much less well if you turn off JavaScript. They have swayed a lot of ostensibly FOSS, copyleft-leaning and privacy/security-centric projects to use it, despite the business model and license.
> In addition many features of GitLab don't work at all or work much less well if you turn off JavaScript.
I feel like the venn diagram of people who complain about JS being required and of people who have never had to code up a web /app/ that users expect rich interactions without a page-reload is just a circle.
I dislike JavaScript being gratuitously required, because it just generally makes things worse—slower to load, and less reliable. I occasionally complain about it, mostly in the places where there’s just no conceivable reason why it should have been done that way, because I do understand pragmatism.
I have also made and worked on multiple web apps where rich reload-free interaction is expected. In some cases, it has not been practical to support JavaScript-free operation at all, but in almost all cases where JavaScript-free operation has been feasible, I have provided at the very least partially-degraded operation—certainly on all green-field development.
A lot of the places where GitLab requires JavaScript are quite unnecessary, and should probably not have been done client-side at all in the first place, though I’d settle for server-side rendering with rehydration.
JS being required for the interactive features would be fine. My personal problem is that I end up on some random gitlab instance to just take a look at the source or issues for some library, and get a blank white page. For the read-only public view there should be no need for any JS.
I understand that thinking but it's ignores reality. To do what you want you want means maintaining 2 codebases (even if just for sub-parts of a site). It's really easy to say "This specific page could be static" and you are right, it could, but it would mean having fallbacks for every JS interaction on the page (or removing them if the user has JS disabled). There simply aren't enough people who die on the no-JS hill to care about, especially since it means ongoing development maintenance, testing, design/UI work, and the list goes on.
GitLab is built on JS and renders a white screen without JS. Enabling JS at all taxes my Core 2 Duo machine, and opening GitLab to a few thousand line file (or worse yet, opening the pull request diff view) taxes my top-of-the-line Ryzen 5 5600X machine running Firefox. GitLab is just badly written.
Or you could server render the pages and hydrate them as needed which is something easy to do with NextJS, NuxtJS, Remix, Fresh, among other modern frameworks for developing with JavaScripts libs.
This is my opinion, too. The JavaScripts should not be required just to read the documents, files, list of files, etc; even if some of the other features do use it.
What about websites that won't even render static text when javascript is disabled. For example, any website that references sinclairstoryline for javascript will not render anything at all until you give permission to run scripts from both the website and that external host.
If I'm just reading static text on a web page, theres'a absolutely no reason why I should need javascript to just read it.
> If I'm just reading static text on a web page, theres'a absolutely no reason why I should need javascript to just read it.
100% true if the site is privately funded. In most other cases JS is required for ad integration and analytics.
I don't like it, but I understand that funding is required and ads are the simplest way to get there without getting into the whole micro-payment and paid subscription mess.
Forcing people to run JavaScript does not guarantee that Analytics or Ads will run as these might get blocked by DNS, Extensions or even the browser itself. I understand the need for them but I don't think it excuses the need to run JavaScript to see text. By the way Hacker News has ads on their main page and the website works perfectly without JavaScript, and even better with it enabled! IMO the job of JavaScript is to enhance the UX, not render the webpage. With modern tooling such as NextJS and Svelte Kit it's possible to code everything in JS (without duplicating logic between backend and frontend) and still have some stuff work without JavaScript, even better when using something like Remix.
> Forcing people to run JavaScript does not guarantee that Analytics or Ads will run as these might get blocked by DNS, Extensions or even the browser itself.
True for power users on PCs, but keep in mind that many users use smartphones [0] and tablets nowadays to access websites. The possibilities to block analytics and ads are severely limited on these devices.
JS is also sometimes used to "protect" content from scraping by bots (I cannot comment on how effective this is is, but I've seen it a lot). Again, I agree that JS shouldn't be used like this, but sadly it is.
You make it sound like it's impossible to build a Web app that supports rich interactions without a page-reload without requiring JavaScript, but this isn't true. You can use progressive enhancement/graceful degradation to build one such that users with JavaScript still get the experience they get now, while users without it will have an experience that's slightly clunkier but still usable.
And as I said in reply to a sibling comment: Then you are effectively maintaining 2 codebases. Also, I'm not aware of any SPA framework (at least the big 3) that even offer an escape hatch to do something like that. Maybe with SSR and some special logic you could but it would be painful and ultimately not worth it.
Remix provides something close to what you are thinking, the application works perfectly without JavaScript but gets enhanced if it's enabled which is pretty nice.
Remix, along with the other frameworks/libraries you've mentioned, are very interesting. I've considered trying out SSR with Quasar (the Vue framework I work most in), though selling it to "business" is hard and I understand why, I can't bring myself to eat the cost (both time and real dollar cost) on my own projects. I do hope SSR continues to advance, though I have some trouble imagining a "free"/"seamless" fallback for no-js users and so other than initial paint I'm not sure how functional some sites will be.
I specifically called out "web apps" in my first comment as I do understand the value SSR brings to things like blogs, news, or other simple sites where JS is not needed, or where it can have a clean fallback. On the other hand, I write "apps" (sometimes deployed on phones via Quasar/Capacitor as well as on the web) and those get much more complicated. I'm not quite sure how modals, WYSIWYG, rich date pickers, etc translate for a no-js user. Simple navigation is easy enough to grasp but my understanding is that things like NextJS/NuxtJS are really just for first render/paint and then React/Vue take it from there. I could be behind the times on what's possible without JS and using SSR through. I just know the PHP codebase I also work in uses plenty of JS to be functional (not above and beyond, literally "table stakes" stuff).
Yeah as of now I think the SSR capabilities of NextJS and NuxtJS will serve mostly for the first paint, it will also allow a user to navigate between pages without running JavaScript (which a SPA wouldn't). I do have to agree though that at a certain point thinking further than this about non-js users becomes too cumbersome and not really worth it if your application is truly a web _app_ meaning very interactive and to the point it could be bundled as a desktop application.
I'd like to note that Remix does handle everything being tied to a single logic as far as my testing went, I love it. The idea is that basically all interaction is done with html forms (like in the old days) and Remix loads a React bundle that makes that run client side after the page has loaded. It's a very simple model that should work for most use cases, although I don't think it's suitable if you're truly developing a web _app_.
As with everything, balance is key. JavaScript is useful and more appropriate is some situations, and it's not in others. I do hope to see more progress with seamless SSR for SPAs though, I think it would make the internet a much better place.
