Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "legacy browsers"
-
You know what's worse than fixing websites in IE?
Fixing websites in safari for winblows.
FUCKING HORSESHIT3 -
When you only have to support recent browsers/devices, but then a commercial promises more support of legacy browsers/devices for free.
-
Static HTML pages are better than "web apps".
Static HTML pages are more lightweight and destroy "web apps" in performance, and also have superior compatibility. I see pretty much no benefit in a "web app" over a static HTML page. "Web apps" appear like an overhyped trend that is empty inside.
During my web browsing experience, static HTML pages have consistently loaded faster and more reliably, since the browser is immediately served with content useful for consumption, whereas on JavaScript-based web "apps", the useful content comes in **last**, after the browser has worked its way through a pile of script.
For example, an average-sized Wikipedia article (30 KB wikitext) appears on screen in roughly two seconds, since MediaWiki uses static HTML. Everipedia, in comparison, is a ReactJS app. Guess how long that one needs. Upwards of three times as long!
Making a page JavaScript-based also makes it fragile. If an exception occurs in the JavaScript, the user might end up with a blank page or an endless splash screen, whereas static HTML-based pages still show useful content.
The legacy (2014-2020) HTML-based Twitter.com loaded a user profile in under four seconds. The new react-based web app not only takes twice as long, but sometimes fails to load at all, showing the error "Oops something went wrong! But don't fret – it's not your fault." to be displayed. This could not happen on a static HTML page.
The new JavaScript-based "polymer" YouTube front end that is default since August 2017 also loads slower. While the earlier HTML-based one was already playing the video, the new one has just reached its oh-so-fancy skeleton screen.
It would once have been unthinkable to have a website that does not work at all without JavaScript, but now, pretty much all popular social media sites are JavaScript-dependent. The last time one could view Twitter without JavaScript and tweet from devices with non-sophisticated browsers like Nintendo 3DS was December 2020, when they got rid of the lightweight "M2" mobile website.
Sometimes, web developers break a site in older browser versions by using a JavaScript feature that they do not support, or using a dependency (like Plyr.js) that breaks the site. Static HTML is immune against this failure.
Static HTML pages also let users maximize speed and battery life by deactivating JavaScript. This obviously will disable more sophisticated site features, but the core part, the text, is ready for consumption.
Not to mention, single-page sites and fancy animations can be implemented with JavaScript on top of static HTML, as GitHub.com and the 2018 Reddit redesign do, and Twitter's 2014-2020 desktop front end did.
From the beginning, JavaScript was intended as a tool to complement, not to replace HTML and CSS. It appears to me that the sole "benefit" of having a "web app" is that it appears slightly more "modern" and distinguished from classic web sites due to use of splash screens and lack of the browser's loading animation when navigating, while having oh-so-fancy loading animations and skeleton screens inside the website. Sorry, I prefer seeing content quickly over the app-like appearance of fancy loading screens.
Arguably, another supposed benefit of "web apps" is that there is no blank page when navigating between pages, but in pretty much all major browsers of the last five years, the last page observably remains on screen until the next navigated page is rendered sufficiently for viewing. This is also known as "paint holding".
On any site, whenever I am greeted with content, I feel pleased. Whenever I am greeted with a loading animation, splash screen, or skeleton screen, be it ever so fancy (e.g. fading in an out, moving gradient waves), I think "do they really believe they make me like their site more due to their fancy loading screens?! I am not here for the loading screens!".
To make a page dependent on JavaScript and sacrifice lots of performance for a slight visual benefit does not seem worthed it.
Quote:
> "Yeah, but I'm building a webapp, not a website" - I hear this a lot and it isn't an excuse. I challenge you to define the difference between a webapp and a website that isn't just a vague list of best practices that "apps" are for some reason allowed to disregard. Jeremy Keith makes this point brilliantly.
>
> For example, is Wikipedia an app? What about when I edit an article? What about when I search for an article?
>
> Whether you label your web page as a "site", "app", "microsite", whatever, it doesn't make it exempt from accessibility, performance, browser support and so on.
>
> If you need to excuse yourself from progressive enhancement, you need a better excuse.
– Jake Archibald, 20139 -
Wow...lets a minute to appreciate the unsung hero's that revolted and went on to lead and win the battle against IE6.**shiver**
https://blog.chriszacharias.com/a-c...
The majority of you will not understand or be able to appreciate the gravity and extent their actions had on improving quality of life for web developers globally... that is the true gift & legacy of their noble deeds.
and yes it was that bad... no, actually it was even worse - the best words i can use to describe (attempting) development in IE6 is that it felt like we were imprisoned in the software equivalent of a concentration camp where they had perfected the cruellest form of torture, where they allowed us to develop amazing next level experiences in modern browsers just so they could watch all hope drain from our faces as we were forced to destroy them, tearing out the magic in the name of IE6.10 -
While Indian govt. talks about digitizing the country and is pushing ahead with it, their Employee's Provident Fund Org (EPFO) infra is absolutely shit and it's killing small time business that want to help their employees.
You need to add Digital Certs to do just about anything (great security wise) BUT,
The digital sign interface is written in Java Flash, that was dropped by all modern browsers 4 years ago.
The only stable working latest browser for it is Firefox 52 released 3 years ago.
The USB tokens used/supported are all Chinese that don't respect OSS drivers and fork built their own (read Watchdata) with no/shitty and cumbersome linux support (couldn't get it working after 2 nights of trying different versions of drivers).
You still have to run Windows to sign the docs or to interact with EPFO using legacy browsers from 2016
Non Tech problems: EPFO charges 500 Rs/month minimum admin charges, and I pay 1200 Rs PF for my driver. That kind of commission is plain stupid and will make small employers run away from paying PF for their employees.
Any interaction with EPFO is like having to eat thorns. painful, unnecessary bullshit. How useless can someone be building such a system released in 2019?
I just hope they fix it. A simple google search shows there is Web Crypto API for modern browsers. Someone wake these people up. SMH2 -
I'm too retarded to understand how the fuck to get iframes (of other pages on our site) somebody wrote in the past in our code base to not become the page (the original has 2 other pages on our site "embedded") https://cheatsheetseries.owasp.org/...
I don't even fucking understand if I implemented the recommended framekiller code correctly, but it fucks shit up like the not recommended framekiller code so I'll settle for it. I also enjoyed (actually I didn't) reading about how this javascript framekiller stuff is fucking stupid anyway and mainly only applicable for old legacy browsers (in which case go fuck yourself anyway, just use a modern browser which benefits with from the x-header-options whatever the fuck, which was easier to implement and juSt WeRKs)
Guess I have no choice but to write AJAX to do this dumbass shit.
It's a shame I have no fucking clue how to fuckign front end3