Whenever I'm starting to think that my job is hard, I always recall that someone somewhere had to ensure their code compatibility with Nintendo 3DS browser

Looks like Apple is the new Microsoft and Microsoft is the new Apple...

I remember when every release of Windows was a catastrophic mess and you had to wait until at least SP2 to get the OS to work in a stable way. And Internet Exploder was *the* browser that broke everything, every time. And there was the whole embrace/extend thing, where they tried to impose their vision of web standards and compatibility, and *everything* you used *had* to come from Microsoft...

And now, it's Apple who fuck up every single OS release, on mobile and desktop, and whose browsers openly shit on web standards (ever try developing anything for Mobile Safari?). Apple's stuff that only works with Apple stuff (down to things like headphone jacks - OOPS, forgot, they dropped those now).

Microsoft is making interesting, beautiful hardware (Surface machines) while Apple is pushing un-innovative, overpriced garbage year in year out. And they're open-sourcing more and more, while Apple walls itself further and further behind its walled "garden". Bleh.

Be interesting to see in 10 years what will have shifted, because it'll change again by then.

That's so fkcin true...

So I finished my personal website. It works fine on every browser... Except IE. All JS functions pass the compatibility check and I don't get any errors. Great.

Repost from Instagram, IE haters hands up :)

Modern web frontend is giving me a huge headache...

Gazillion frameworks, css preprocessors, transpilers, task runners, webpack, state management, templating, Rxjs, vector graphics,async,promises, es6,es7,babel,uglifying,minifying,beautifying,modules,dependecy injection....

All this for programming apps that happen to run inside browsers on a protocol which was designed to display simple text pages...

This is insanity. It cannot go on like this for long. I pray for webasm and elm to rescue me from this chaos.

I work now as a fullstack dev as my first job but my next job is definitely going to be backend/native stuff for desktop or mobile. It seems those areas are much less crazy.

Waiting for the perfect browser :

1. It's not Safari or IE and without their shitty problems.

2. It's not a RAM gobbler like Chrome. But has its minimal UI.

3. Has Chrome like dev tools or Firebug and nothing less than those.

4. Does not have ads.

5. Cross platform. On both desktop and mobile.

6. Web extensions only

7. Everyone loves it. Even fanboys who swear by Safari

8. Blocks annoying pop ups on some sites.

You're open to contribute more points!

I'm getting so fucking tired of frontend development...

I still like part of it, but I really hate CSS, browser compatibility, stupid users, dumb requests from product owners and fucking weird designs. And to top it all, it's the frontend team that handles all the pressure when the deadline comes up and the project's late, even if it was the product/design/whatever phase that took too much time.

Being a frontend developer is very stressful and has so many annoyances and I'm getting sick of it.

My company's been promising giving me some backend work because there are some backend-heavy projects coming up and they know I have the skills, but they just keep giving me frontend work. Also, one of our frontend developers is on leave, which means more work for the rest of us.

Why did I ever decided to do frontend development?

Google cripples ad and tracking blockers: In January, Chromium will switch to Manifest V3 which removes an essential API in favour of an inferior one. As usually, Google is being deceitful and touts security concerns as pretext.

That hits all Chromium based browser, such as my beloved Vivaldi. The team argues with their own browser internal blocker, but that's far worse than uBlock Origin. One of Vivaldi's core promises was privacy, and that will go out of the window. The team simply doesn't react to people pointing that out. They're fucked, and they know it.

So what now? Well, going back to Firefox because that will include the crippled new API for extension compatibility, but also keep the powerful old one specifically so that ad and tracking blockers will keep working. Google has just handed Mozilla a major unique selling point, and miraculously, Mozilla didn't fuck it up.

This really pisses me off. As a front end developer (ember.js, HTML and Css) colleagues and boss and pm are always making jokes how I just need to change a button or a color and whenever there is a bug in the UI there's always big fun and jokes around it. But when there's a bug in the API, they never joke around, it's just : oh yeah we're getting the wrong data or an exception. But they always like to undervalue UI work even when it involves complex layouts, multi browser compatibility, responsive design, mobile browsers etc.. While they just code their API to connect to a database and everything works they don't really need to worry about what the user is using as a browser. They just get requests and send replies. I don't really think people value the work in front end as much as backend and that pisses me off as I believe there's a lot more going on in the front end.. I know they mean well and they are all cool people but sometimes it pisses me off as they don't value my work..

After 3 months and around 5 projects at my new job, I've finally come to the realisation that the developer in charge and I disagree on everything, all tech stack/browser compatibility decisions are made completely blindly and no matter what, the lead (full stack) dev refuses to take any of my frontend expertise/knowledge on board.

how did a startup become this rigid and terrible?

I already want to quit.

<rant>The state of front end web development in 2016</rant>.

Cross-browser compatibility.

Introducing No.js! A revolutionary new framework. Just build your templates and then... Stop. No worrying about browser compatibility. Web dev has never been so simple.

Had a blast from the past the other day. Testing an issue with an AngularJS app in IE11 on a project managers Surface.

Nothing works. Just a blank screen. I open the JavaScript console to hundreds, maybe thousands of errors. They all seem eerily familiar, but I can't place them. It's like something from a past life.

Then I see one that brings the issue into sharp focus.

"{{variable_name}} is a reserved word"

No it isn't, I think. That hasn't been a reserved word in JavaScript since...

Me: "Is your browser in Compatibility Mode?"

PM: "Yeah, it's for one of our legacy programs"

Me: "You need to turn that off to test this app. It thinks you're using IE6, so it's having a 2 decade old shit-fit. I haven't seen those errors since I was a teenager making crap on Geocities"

I never thought an error message could make me feel so old 😩

This fcktard client that insist on using an iframe and demands support for browsers like IE7. You are costing me years of my life.

Fucking fuck of a Microsoft trying to protect people against tracking from 3d parties in an iframe in random ways in some versions of IE7. Or IE11 in IE7 compatibility mode.

If you are going to refuse sessions just do it! I got a fucking check and fix for that. Because these fuck faces friendly people at Apple like to refuse sessions on iPads and iPhone too. But we worked that out, because they are at least consistent. So a few dirty little hacks made it all Okay.

But no, Boo Hoo I'm Microsoft and I will throw a tantrum. I like my browsers to be like an magican, instead of an usefull piece of software. If you look in this page, or look here we got them. I got your sessions​, safe and secure.

But when you need me, to verify that the user is allowed to access data we do a little hocus pocus and now they are gone. Nowhere to be seen or found again. Fun times free fucking magic shows all day long.

It's morning but maybe its time for a bottle of scotch. Maybe if I'm in the state as this browser. Where I don't know what I'm doing because I'm shitfaced drunk it will start working.

When in Rome do as the romans do.

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, 2013

Why fix browser compatibility issues when you can just block what versions users can log in with?

Friend: why do you hate react so much ?
Me: Because web development should be all about browser compatibility ( yeah even for that shitty ie8 ) and usability not spa and shitty made animation that breaks when you switch from landscape to portrait .
Friend: then why do you use it ?
Me: money.

Yup this seems about right... 😂

Fuck Homestead.

For the fortune of you not to know, Homestead is a sad attempt at a Wix-like build your own website platform.

However, Homestead is the most unusable piece of shit platform that humans have ever had the misery of interacting with

Lets start off with the login page. The login page is small, unresponsive and half the time just deletes your input whenever you press submit.

It's important to note that unless you're running MacOS or Windows, Homestead will send to an error page on which there's a link to contact support, but pressing that link requires MacOS or Windows.

Fine, I'll fiddle around with my user-agent, and we'll be in soon enough. But now we come to the joy that is the website editor itself.

The website editor is clunky, hard to use, and has enough menus and submenus and sidebars to make the Jira UI shake with fear. Each interface option label is either ridiculously ambiguous or just straight up wrong. The built-in HTML editor doesn't support HTML5, in the name of "browser compatibility".

CSS? Pah! Who needs it! Our psuedo-90s skeuomorphic ugly-as-shit prebuilt styles will work just fine. Responsive design? Bullshit! Nobody uses a smartphone to browse the web, so why do we need to handle it?

Uploading a file? Good fucking luck buddy. There's a complicated dance among the minefield of pop-ups that ask you to confirm some shit or modify some shit and you gotta click the right option each time or else the file won't upload.

Wanna use https like 86% of the entire web and all modern websites? That's a premium feature. Fork over an extra $10 a month

Ok ok, I made it through all that. Dig through the thousands of menus to find the 'publish changes' button, and sigh with relief.

Open up a private browser tab to check my work, and nope. The site looks like shit, even by Homestead's standards. That's because Homestead claims to be a WYSIWYG editor, but it's a damn lie. The site looks like shit, so it's time do dive back into the hellhole that is this damn site editor.

And rinse and repeat. Deal with the shitty editor, publish, and pray it doesn't look like garbage. Be too scared to test on other devices because this flaming pile of dog shit pretending to be a website is bad enough on my device.

Two more months, then I'm done with this client. Someone get me a drink

I despise it when software developers remove features because "too few people use them".

Is this what those shady telemetry features are for? So they can pick which useful features to get rid of because some computer rookies whined that it is "feature creep" rather than just ignoring it?

Now I have to fear losing useful (or at least occasionally convenient) features each time I upgrade, such as Firefox ditching RSS, FTP, and the ability to view individual cookies. The third can be done with an extension, but compatibility for it might be broken at some point, so we have to wait for someone to come up with a replacement.
Also, the performance analysis tool in the developer tools has been moved to an online service ("Firefox profiler"). I hope I don't need to explain the problems with that.

But perhaps the biggest plunge in functionality in web browser history was Opera version 15. That was when they ditched their native "Presto" browsing engine for Chromium/Blink, and in the process removed many features including the integrated session manager and page element counter.

The same applies to products such as smartphones. In the early 2010s, it was a given that a new smartphone should cover all the capabilities of its predecessors in its series, so users can upgrade without worrying a second that anything will be missing. But that blissful image was completely destroyed with the Galaxy S6. (There have been some minor feature removals before that, such as the radio and the three-level video recording bitrate adjustment on the S4, but that's nothing compared to what was removed with the S6.).

Whenever I update software to a new version or upgrade my smartphone, I would like it to become MORE capable, not LESS (and to hell with that "less is more" nonsense).

Web development is the worst!
I still cannot understand why it is not possible for browsers to correctly support all official specs... Exceptions here and there, dirty fix for this one, add a little margin here, hide this...
The daily struggle never stops.
Don't even get me startet with PHP!
Next round is on me ;)

Internet explorer, the plague of internet browsers...

Why should I make my fucking code messier and write some bullshit workaround just because you’re a stubborn idiot who refuses to upgrade your fucking operating system and browser. ARGHGHGGH

In a universe where JavaScript was never invented, the world of programming might look vastly different. Perhaps another programming language would have taken its place, or multiple languages would have coexisted in a more harmonious ecosystem.

Without the challenges posed by JavaScript, web development may have been smoother and more streamlined. Websites could have been faster and more responsive, without the need for complex optimization techniques. There might have been fewer security vulnerabilities to worry about, and the web could have been a safer place for users.

In this utopian world, developers would have had more time to focus on building great user experiences and innovative features, rather than battling with cross-browser compatibility issues and JavaScript quirks. The internet would have been a more accessible and inclusive place, with fewer barriers to entry for those who want to build and create.

Overall, a world without the horrors of JavaScript would have been a world with less frustration and more possibilities.

(Fooling around with ChatGPT)

Browser compatibility

Oh, gather 'round fellow wizards of the code realm! 🧙✨ Let me regale you with the epic tale of software sorcery and the comical misadventures that come with it! 🤪🎉

So there we are, facing the dreaded Internet Explorer dragon 🐉 - an ancient, stubborn beast from the era of dial-up connections and clipart-laden websites. It breathes fire on our carefully crafted layouts, turning them into a pixelated disaster! 🔥😱

And then, the grand quest of cross-browser testing begins! 🚀🌍 One moment, your website is a shining knight in Chrome's armor, and the next, it's a jester in Safari's court. A circus of compatibility struggles! 🎪🤹

CSS, the arcane art of cascading style sheets, is our magic wand. But oh, the incantations can be treacherous! A slight misstep and your buttons start disco dancing, and your text transforms into a microscopic mystery! 🕺👀

But fear not, brave developers! We wield the enchanted sword of Stack Overflow and the shield of Git version control. We shall slay bugs and refactor with valor! ⚔️🐞

In this enchanted land, documentation is the mystical parchment, often written in the cryptic dialect of ancient monks. "This function doeth stuff, thou knoweth what I meaneth." 📜😅

And meetings, oh the meetings! 🗣️🤯 It's like a conference of babbling brooks in the forest of Jargon. "Let us discuss the velocity of the backlog!" 🌿🐇

But amidst the chaos, we code on! Armed with our emojis and a bubbling cauldron of coffee, we persist. For we are the wizards and witches of the digital age, conjuring spells in Python and brewing potions in Java. 🐍☕

Onward, magical beings of code! 🚀 May your bugs be few, and your merges conflict-free! 🙌🎩

Apparently some smart shithead decided to override ctrl+f browser behavior when you edit files directly on github.

Edit renders only part of file and displays search under edit file label that disappears every time you find something. ( what if there is more then one occurrence smartass )

Default ctrl+f can’t find text on page unless it’s displayed.

Thanks morons.

I swear on the Almighty nature, I fucking hate Browser compatibility.

Passing php data via JSON encode. Works superfine on Firefox and Android mobile browser doesn't on Chrome. Fucking shit. Been sitting for 13 hours and gave up. FFuuuuuuck !!!!

Form submission via ajax and it again works on Firefox but doesn't on Chrome. I just can't understand, my mind is fucked by all the angels in heaven. Data gets submitted, the form is reset but the function called to refresh the JSON data doesn't work.

Someone please kill me or I swear I will fucking kill everybody.

Debugging WebRTC is pure hell.

For starters, it's JavaScript, so you know this isn't gonna end well. Second, it's still in kinda beta phase for some browsers so you gotta add polyfills. Let's talk compatibility now. During normal days, yeah, I could ask for a couple of computers in the office, each using a different browser. But, covid. One browser mishbehaves and doesn't wanna share the camera with the other browser, so I can't really test a connection with the only 1 computer I have. I can't take my partner's computer all day to debug.

Solution: ask the marketing department or even the execs to video chat with you to test it on a staging server. So I push my changes to the server, wait for them to build, call my lab rat, check all the bugs, clean the code, push the changes back up. No fancy breakpoints. I'm doing the old style like my great uncle did. Oh wait no, he was pretty intelligent, but my lab rat isn't. They probably don't know what a console is. So no baby I'm not only talking about console logging the problems, I'm talking `alert` the heck out of the bugs - okay no, I'll just display the objects in the middle of the screen. The screen is my console.

The sad realisation that today you have to use browser stack and you remember how slow it is and it crashes for no reason... repeatedly.

I have a nightmare project that I will probably be ranting about quite a lot in the coming weeks, but I don't want SEO to pick up the specifics on the off chance my peers Google the issues we're facing and my profile comes up.

Let me set up the scene by describing the predicament, and then I'll get to the most outrageous thing I've heard while working at this job. It gives you a CLEAR idea of why we're in this situation in the first place.

Anyways, the nightmare project only runs in IE with compatibility mode set to version 6. So it only runs in IE 6 at the latest.

And it is massive. I'm talking real, real enormous.

The most recent roadblock I ran into while Chrome-ifying it is the extensive use of a browser API that was removed 8 years ago.

It involves synchronous data input and I know for a relatively certain fact there's no way to fix it without combing through every single reference to this API and converting the ones that need sync data (not all of them do) to callbacks. How big of an issue is that?

Well, just one of that 15-ish modules has over 900 references to it. Even just creating a spreadsheet of "commented out / doesn't need a fix / needs fix" for each reference in 1/15th of this project would take days of manual labor.

Here's the rant.

So after discussing this issue in the meeting (we ended on "they don't believe me that we can't just replace it with jQuery") I brought up the next issue. One of our 3rd party libraries is so old it doesn't work anymore and we can't modify that code (it's compiled).

They said that even if it was backwards compatible (no fucking way. This version is like, at least 10 years old, I guarantee it) they can't simply replace it because we don't have a subscription to this product anymore (suggesting we find an alternative).

And I fucking kid you not, this is what happened next.

They then began discussing how this is why you shouldn't use 3rd party code. Because it becomes obsolete and you can't even fix it yourself because it's not yours to edit.

Yes. They said this DIRECTLY after we discussed our 900+ references to a browser API >>REMOVED<< 8 years ago. Yes, they said this about a 3rd party library that receives regular support but is totally FUCKED because we NEVER updated it after adding it and we never even renewed the LICENSE.

What the FUCK

var manual = '.... use chrome...';

User: "Hey this thing is broken, can you fix it?"
Me: "Works just fine for me, what browser are you using?"
User: "Edge, why?"

..... god I hate browsers.... rtfm bitch.. make my life easier please?...
Sometimes I wish I only did back end work...

I thought I had a decent handle on CSS. I can use flexbox and grid to make some decent and responsive webpages, and I'm at least familiar with most of CSS's more common gotchas

But no.

Even in 2021, with years of improvement in the language and browser compatibility, CSS can still fuck you over

I was adding some margin to a div element, and I noticed that the div element's margin seemed to force it's parent to move down too, as if the margin was applied to the parent as well

It took far too many nearly nonsensical google searches to discover that CSS has a nasty little trick called 'margin collapse'

And in true CSS fashion, the way to fix it is a hacky workaround. In this case, if you add a padding of 1px to the parent, the margin collapse doesn't apply.

Fuck CSS. From its weird implementation to its hundreds of gotchas to its hacky workarounds to said gotchas.

Fuck CSS

The Odyssey of the Tenacious Tester:

Once upon a time in the digital kingdom of Binaryburg, there lived a diligent software tester named Alice. Alice was on a mission to ensure the flawless functionality of the kingdom's latest creation – the Grand Software Citadel.

The Grand Software Citadel was a marvel, built by the brilliant developers of Binaryburg to serve as the backbone of all digital endeavors. However, with great complexity came an even greater need for meticulous testing.

Alice, armed with her trusty testing toolkit, embarked on a journey through the intricate corridors of the Citadel. Her first challenge was the Maze of Edge Cases, where unexpected scenarios lurked at every turn. With a keen eye and a knack for uncovering hidden bugs, Alice navigated the maze, leaving no corner untested.

As she progressed, Alice encountered the Chamber of Compatibility, a place where the Citadel's code had to dance harmoniously with various browsers and devices. With each compatibility test, she waltzed through the intricacies of cross-browser compatibility, ensuring that the Citadel would shine on every screen.

But the true test awaited Alice in the Abyss of Load and Performance. Here, the Citadel's resilience was put to the test under the weight of simulated user hordes. Alice, undeterred by the mounting pressure, unleashed her army of virtual users upon the software, monitoring performance metrics like a hawk.

In the end, after days and nights of relentless testing, Alice emerged victorious. The Grand Software Citadel stood strong, its code fortified against the perils of bugs and glitches.

To honor her dedication, the software gods bestowed upon Alice the coveted title of Bug Slayer and a badge of distinction for her testing prowess. The testing community of Binaryburg celebrated her success, and her story became a legend shared around digital campfires.

And so, dear software testers, let the tale of Alice inspire you in your testing quests. May your test cases be thorough, your bug reports clear, and your software resilient against the challenges of the digital realm.

In the world of software testing, every diligent tester is a hero in their own right, ensuring that the digital kingdoms stand tall and bug-free.

I just thought. The next generation of coders are going to curse the software we praise. Well be using JavaScript to drive cars and ATMs (if we aren't already). We're gonna talk shit to dev youngsters about compilers, shims and fucking cross browser compatibility and how good they have it. Some of us will be stuck in the past keeping bullshit legacy code alive. Besides that, the world is gonna be a fucking awesome place (rip Mahammad Ali)

The secret to cross-browser compatibility is just wrapping every single element in an extra div, just for good measure.

for me, the most interesting project I''ve worked on was 4 years ago for a beer company.
it was a facebook app developed in HTML (not html5), jQuery & jQuery hi, php, imagick, ffmpeg, & YouTube library.
for the Euro Cup, users had elements to drag and drop on a stage, add frames, dialog boxes, and create a 15 second animated story board. all positions of these elements along with the frames where sent server side to create images of each frame (rendering fronts and positioning), then combining them using ffmpeg to generate a video.
these videos were later uploaded on the client's YouTube channel.

this project was awesome, knowing css3 and html5 were prohibited to use due to cross browser compatibility. it was ban exercise on all levels :)

Developers celebrate new Safari browser features. Nice! Good work! But when will Apple ship the new Safari to older macOS and iOS versions?
That would increase compatibility and reduce planned obsolescence, Apple! 🍏🍎👿

F*ck u IE, f*ck u. You are the worst browser.

Chrome doesn't support something, something Firefox doesn't.
When you plan to take a risk, they give F*** you later on.

IE do you even exist?

Dear web developers, please think of the boot disk users.

Users might have to boot their computer from external bootable media such as a live USB stick, SSD, or live CD/DVD, after their operating system caught a problem that prevents it from booting.

Emergency boot media usually has earlier versions of web browsers because they are not frequently used, much less updated. Sadly, the developers of many websites have a habit of breaking compatibility for older web browsers. For example, the new audio player used by the Internet Archive (Archive.org) does not even support Firefox 57, a version that was released as recently as November 2017!

Therefore, websites should retain support for old web browsers. If not all features can be made to work, at least the essential features should work on older browser versions. Websites should not let down people who are stuck due to a computer problem. Those users should still be able to browse the Internet for help, and perhaps enjoy basic entertainment such as watching videos (YouTube, Dailymotion) and listenening to music or audio books (SoundCloud, Internet Archive) while at it.

The attached screenshot shows something no internet user wants to be "greeted" with.

Keep the Internet accessible.

Any recommendations for decent 13 inch laptop under 1400$ USD
- Atleast 8 gigs of RAM and option to upgrade
- resolution >= full HD
- storage >= 256 GB SSD
- battery >= 6 hrs heavy chrome usage
- Linux compatibility
- Cpu- nothing heavy - browser and docker containers, no building or compiling

Can a React.JS expert help me to understand something?

In short, I would like to know what are the main differences between react version 15.6 and 17, in terms of browser issues, and component compatibility?

We have a legacy code base that is in version 15.6 and the team wants to upgrade it and I am attempting to argue with my dumb CTO to upgrade to version 17. However, I’m not versed in react, I'm just a PO and the CTO doesn't know anything but for some odd reason is adamant about staying on an older version. The developers gave me their opinion but I'm interested in an outside opinion.