3 ms·

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 th

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.

philwelch 3y ago
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.)
- speedgoose 3y ago
  It adds interactivity and dynamic features that would be pretty slow or very challenging to implement in pure HTML/CSS.
  - philwelch 3y ago
    That’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 ago
  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 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
    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.
xk_id 3y ago
Delivering STATIC DOCUMENTS via dynamic javascript apps running on top of http is the quintessential caricature of overengineering.
- speedgoose 3y ago
  I would argue that gitlab.com is a bit more than a collection of static documents that could be delivered over gopher too.
- MasterIQ 3y ago
  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.

philwelch 3y ago

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.)

speedgoose 3y ago
It adds interactivity and dynamic features that would be pretty slow or very challenging to implement in pure HTML/CSS.
- philwelch 3y ago
  That’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 ago
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 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
  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.

xk_id 3y ago

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

speedgoose 3y ago
I would argue that gitlab.com is a bit more than a collection of static documents that could be delivered over gopher too.
MasterIQ 3y ago
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.