11 ms·
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.
by xk_id 3y ago
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.
- serial_dev 3y agoI suspect it was a conscious decision, they went for large, paying, enterprise customers instead of fighting for the free, public, and open source projects.
- userbinator 3y agoGitHub 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.)
- apag 3y agoIt’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.
- speedgoose 3y agoWhy 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.
- philwelch 3y agoThis 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.)
- speedgoose 3y agoIt adds interactivity and dynamic features that would be pretty slow or very challenging to implement in pure HTML/CSS.
- philwelch 3y agoThat’s nice I guess, but these should be progressive enhancements and the page should still work without JavaScript enabled.
- deanishe 3y ago> 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.)
- MasterIQ 3y ago[dead]
- Tommy430 3y agoAgreed. 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 https://i.ibb.co/YpmFP91/yt2009-34.png [2] https://i.ibb.co/THK0wk0/yt2009-35.png https://i.ibb.co/THK0wk0/yt2009-35.png [3] https://i.ibb.co/nk7nxZQ/yt2009-36.png https://i.ibb.co/nk7nxZQ/yt2009-36.png
- MasterIQ 3y ago
- xk_id 3y agoDelivering STATIC DOCUMENTS via dynamic javascript apps running on top of http is the quintessential caricature of overengineering.
- speedgoose 3y agoI would argue that gitlab.com is a bit more than a collection of static documents that could be delivered over gopher too.
- MasterIQ 3y agoOver-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.