Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Thanks to the Streisand Effect, I've installed this. Seems to work pretty well on the few sites I've tried. Hopefully the maintainer can find a new home and let people know on Twitter.

https://twitter.com/Magnolia1234B



Wow, Gitlab has gotten ridiculous. They're making me sign up for an account, verify email, go through two captchas, and fill out a survey before they'll let me view the repository.

. . . and now that I've done all that the repository is 404ing.


They really had an opportunity to capture significant market share and they ruined it. Their interface also doesn’t work without javascript. What a shame.


GitHub isn't usable without JS either anymore.

(A long time ago, I clearly remember it did. There's nothing about browsing files or participating in the effective forum that's called "Issues" which fundamentally requires JS.)


It’s now usable without JS once again. It was not long ago that repositories stopped being viewable without JS enabled, but they are now again.

I hadn’t tried interacting in Issues without JS enabled in years, but I just tried to out of curiosity and successfully replied to an issue that way.

I must admit to finding myself quietly impressed that any place would be capable of reversing itself on a decision like that.


Why would they have to make their interface work without JavaScript? The few people who block JavaScript for sure know how to enable JavaScript again. And if they block JavaScript for security and trust reasons, well, they are going to download software from gitlab and run it anyway.


Delivering STATIC DOCUMENTS via dynamic javascript apps running on top of http is the quintessential caricature of overengineering.


I would argue that gitlab.com is a bit more than a collection of static documents that could be delivered over gopher too.


    Over-engineering indeed, but it does address actual problems.
    Primarily: Addressing what most browsers haven't well managed to handle: interaction with big files.
    E.g. huge database-like Plain Text: browsers typically fail with OOM (Out of Memory).

    I'll write a review of GitHub's delivery infrastructure when I have the time.


This is the attitude that has ruined the entire web. The real question should be: why is JavaScript necessary and what does it add? (In the majority of applications, absolutely nothing.)


Agreed. Sadly it's due to the constant churn of tech these days. Developers should just take notes from the books on the shelf: don't change without consent unless you explicitly some change.

Slightly off-topic: I've been viewing YouTube on a old YouTube frontend that works back to (at least iirc) IE6 and Win98 for some time now [1] [2] [3]. The frontend feels mad snappy as hell and it loads fast compared to YouTube today since the frontend is not heavily JavaScript reliant, it just uses it to enhance the site.

[1] https://i.ibb.co/YpmFP91/yt2009-34.png [2] https://i.ibb.co/THK0wk0/yt2009-35.png [3] https://i.ibb.co/nk7nxZQ/yt2009-36.png


    Abuse of animation and skip of best-effort loading:
    This is probably more relevant to the sluggishness and bad interoperability, rather than JavaScript.
    [ Those abusing JavaScript for nefarious purposes: probably not the JavaScript to blame. ]

    Standards established don't necessarily imply being well-designed:
    Blindly following without thinking shall regardless trap.

    Many current infrastructures are fundamentally flawed and difficult to fix:
    1 step wrong, all steps wrong.


It adds interactivity and dynamic features that would be pretty slow or very challenging to implement in pure HTML/CSS.


> pretty slow or very challenging to implement in pure HTML/CSS

That's the heart of it, isn't it? It's challenging.

At the core of modern web development is the attitude that developer convenience trumps all.

The software is free after all. (The thousands you pay in bandwidth and hardware upgrade costs to keep running their bloatware doesn't count because none of that goes to the web developer, and is therefore irrelevant in their it's-all-about-me worldview.)


That’s nice I guess, but these should be progressive enhancements and the page should still work without JavaScript enabled.


I suspect it was a conscious decision, they went for large, paying, enterprise customers instead of fighting for the free, public, and open source projects.


Phone number verification also fails for Google Voice.


Loads of services have that issue, not just GitLab. Some are even blocking Twilio numbers.


Twilio is registered on the PSTN as an IPES, if your making the effort to block non-wireless OCNs, then your gonna block Twilio.



Ur


I think the sign up page is because the repo is blocked. It probably redirects to that for non-logged-in users.


Thanks for the twitter link, the author has now posted a wetransfer link and is thinking about another home.


Streisand Effect indeed... I wasn't aware this existed but now I've saved a copy.


Another extension that deserves some fame is "Behind the overlay". it allows you to kill any unskipable full page overlay informing you about the benefits of a subscription and the excellent quality of the article beneath it.

Coupled with the Archive.ph button they make up my holy trinity of paywall bypass.


curious, what's the 3rd part of the trinity now that Bypass Paywalls is gone ?


It's not going anywhere, it just needs to find a more reliable home.


warning: gitlab link is taken down too, dont waste time


Uhm... maybe codeberg.org? Or self-hosted forgejo/gitea?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: