Would the web be better off, if there was zero frontend scripting? There would be HTML5 video/audio, but zero client side JS.

Browsers wouldn't understand script tags, they wouldn't have javascript engines, and they wouldn't have to worry about new standards and deprecations.

Browsers would be MUCH more secure, and use way less memory and CPU resources.

What would we really be missing?

If you build less bloated pages, you would not really need ajax calls, page reloads would be cheap. Animated menus do not add anything functionally, and could be done using css as well. Complicated webapps... well maybe those should just be desktop/mobile apps.

Pages would contain less annoying elements, no tracking or crypto mining scripts, no mouse tracking, no exploitative spam alerts.

Why don't we just deprecate JS in the browser, completely?

I think it would be worth it.

Go deprecate yourself kind sir!

*9 months ago*

We want this feature! Our clients need this feature! It's gonna make their lives so much more convenient, and perhaps even deprecate other features!

* nobody uses it *

* Today *

Someone used the feature and screwed up cause they didn't know how to use it (the feature was working fine). Let's delete it.

Me: I deprecate a react component, because it's bloated and no longer makes sense, and I let everyone on the team know that we're working to get rid of that component

Other Dev: Hmm, if I copy this component for every time that it is used, rename all of my copy's and delete the original, I got rid of the deprecated component...

Me: After hearing that deprecated component was removed... "Good job other Dev"

Me: A couple of weeks later after dev leaves company and I start adding some new features to the app "WTF"

I consider just strangling somebody because iOS14 fucked all legacy Google Cardboard SDK apps overnight.

8 months already, still can't get all my old apps to work, for a thousand reasons.

If I didn't know better, I'd sue somebody. But it's apple, and I'm not Epic, so fuck me.

"Ohh dude why dontya just rewrite your apps to support Unity XR? hurr durr easy peasy lol so cheesy"
I'm tryin, but it's so underdeveloped and featureless, that I need to rewrite and create everything, and in some cases I can't because old apps had many dependencies. I am porting all my prefabs for hundreds of unpaid hours over the last 3 quarters already, and keep getting stuck.

Today I just extended an 8th deadline set by my clients. Each of those are exponentially more explosive and demotivating. It's not just the question of losing money for them - some of their careers depend on these apps I had made. (Long story, but it's exactly like that)

WHAT HAPPENED TO MAINTAINING LEGACY SUPPORT?!?! Nobody asked anyone to deprecate perfectly well working gyro/accel api on all <5 year old iPhones overnight TIM.

You know what?
No you don't!
PHP decided 'in time memorial' to deprecate their 'split' function for another function called 'explode' that splits, oh sorry, that explodes a string.

Now you know something!

DevOps is a huge scam.

Whoever sold companies maintenance-free cloud is God-tier marketer, they would be able to sell fire extinguishers in hell.

First, the platform is constantly moving, keeping up with all the updates for Kubernetes/CNI/Ambassador/Calico/kube-proxy/wtf/foo/bar/etc requires a huge team constantly peddling the boat; and if not updating in time - eventually everything will suddenly break when AWS deprecates old Kubernetes version (1.23 in EKS has just 1 year and 2 months (!!!) of support) or whatever else. At least they don't deprecate services that often.

Second, all other tooling either suck, or expensive as a Boeing. DataDog/Splunk/NewRelic/Grafana? Data centers were built for the monthly prices of these tools not so long time ago. But, capex vs opex, what stupid software engineers knows (though, it's hilarious to be present on a meeting with an agenda "reduce cloud costs").

That's all really.

On the bright side, when the team is solid and really care about the product and build it in a cloud-first manner (with understanding of all the requirements, caveats and limitation) - it can be rock solid, stable and fast platform.

To bad it's incredibly easy to implement some impressively wrong architecture (much more easier than f'up single-server architecture).

Facebook API...

Facebooks "graph" or API's in general fucking stink donkey dick.

Their implementation of oAuth is horrible.. 3 different tokens, which can be either short or long lived, for fetching a facebook page feed (the clients own facebook page)
To that you add a clientID and a ClientSecret.

Great... after painstakingly reading confusing documentation and itching your head... You get it to work.

Then they, without notice, makes a breaking change of deprecate an endpoint you were using.. Jesus..

And all the support you can get comes from a "community group" which may or may not reply with a generic link to their documentation...

status update on the codebox IDE revival project:

WHY THE FUCK DOES PTY.JS REFUSING TO BUILD? YOU IMPREGNATED TWAT, I SWEAR TO GOD IF YOU DON'T BUILD RIGHT NOW IM GONNA FUCKING DEPRECATE YOU AND REPLACE YOU WITH XTERM

He installed? Deprecate it

Waiting for Apple to deprecate their iOS Safari and finally let people install real alternative browsers on their iPhones. Suckfari does not support aspect-ratio either, coincidentally spend hours to find that, now struggling with 100vh and -webkit-fill-available.
Microsoft at least left the choice to install something else besides Internet Explorer before they finally pulled the plug and provided Chromium Edge. Safari isn't the new Internet Explorer, it's worse.

Backend : *breaks feature in prod by changing api*

Me: Feature is broken in prod. Please fix. I was told that the API will not deprecate the old use case.

Backend: ... Fixing it in the backend will take time. Add support for it in the frontend.

Me: I'm not done with the new feature just yet. And it will take some time to have it reviewed and fully tested. Please fix the API.

Backend: .... Well, make a new PR and add support for it first. The new feature can come later.

Me. (-_-) Okay

Sometimes it feels like I'm a code janitor rather than a frontend intern

Why do node.js devs think it's okay to deprecate older functionalities while replacing them with barely-working ones riddled with bugs?

Is this a node.js community thing?

The number of people that pronounce 'deprecate' as 'depreciate' is hilarious. I remember when I was one of them!

Google decided to deprecate the ProgressDialog class in Android O (26). Now I have to deal with all those deprecation messages in Android Studio!

From the docs: "ProgressDialog is a modal dialog, which prevents the user from interacting with the app. Instead of using this class, you should use a progress indicator like ProgressBar, which can be embedded in your app's UI. Alternatively, you can use a notification to inform the user of the task's progress."

They also bugged the Toolbar! Nice.

Every time I see posts about api's changing I wonder if none of those companies uses api versions, or simply deprecate functions before removing them...

When they decided to deprecate the old app that went back to early DOS, they decided to use VB.NET because they'd used some VBA and were familiar with it. Except they had a vague idea that C# was faster and decided to write the OpenGL code in that. Also they had some C++ code and decided to write more of it, accessed by the main program via COM.

I come in and the decision is made to integrate some third-party libs via a C++/CLI layer. On one hand screw COM, but on the other we're now using two non-standard MS C++ extensions. Then we decide we need scripting, so throw in some IronPython.

I'm the build engineer for all this, by the way. No fancy package managers since almost all the third-party dependencies are C++; a few of them are open source with our own hacks layered on top of the regular code, a few are proprietary. When I first started here you couldn't build on a fresh SVN checkout (ugh) without repeatedly building the program, copying DLLs manually, building again, ad nauseum. I finally got sick of being called in to do this process and announced that I was fixing it, which took a solid week of staring at failed compiler output.

Every so often someone wants to update that damn COM library and has to sacrifice a goat to figure out how the hell you get it to accept a new method. Maybe one day I'll do a whole rant just based on COM.

My answer to their survey -->

What, if anything, do you most _dislike_ about Firebase In-App Messaging?

Come on, have you sit a normal dev, completely new to this push notification thing and ask him to make run a simple app like the flutter firebase_messaging plugin example? For sure you did not oh dear brain dead moron that found his college degree in a Linux magazine 'Ruby special edition'.

Every-f**kin thing about that Firebase is loose end. I read all Medium articles, your utterly soporific documentation that never ends, I am actually running the flutter plugin example firebase_messaging. Nothing works or is referenced correctly: nothing. You really go blind eyes in life... you guys; right? Oh, there is a flimsy workaround in the 100th post under the Github issue number 10 thousand... lets close the crash report. If I did not change 50 meaningless lines in gradle-what-not files to make your brick-of-puke to work, I did not changed a single one.

I dream of you, looking at all those nonsense config files, with cross side eyes and some small but constant sweat, sweat that stinks piss btw, leaving your eyes because you see the end, the absolute total fuckup coming. The day where all that thick stinky shit will become beyond salvation; blurred by infinite uncontrolled and skewed complexity; your creation, your pathetic brain exposed for us all.

For sure I am not the first one to complain... your whole thing, from the first to last quark that constitute it, is irrelevant; a never ending pile of non sense. Someone with all the world contained sabotage determination would not have done lower. Thank you for making me loose hours down deep your shit show. So appreciated.

The setup is: servers, your crap-as-a-service and some mobile devices. For Christ sake, sending 100 bytes as a little [ beep beep + 'hello kitty' ] is not fucking rocket science. Yet you fuckin push it to be a grinding task ... for eternity!!!

You know what, you should invent and require another, new, useless key-value called 'Registration API Key Plugin ID Service' that we have to generate and sync on two machines, everyday, using something obscure shit like a 'Gradle terminal'. Maybe also you could deprecate another key, rename another one to make things worst and I propose to choose a new hash function that we have to compile ourselves. A good candidate would be a C buggy source code from some random Github hacker... who has injected some platform dependent SIMD code (he works on PowerPC and have not test on x64); you know, the guy you admire because he is so much more lowlife that you and has all the Pokemon on his desk. Well that guy just finished a really really rapid hash function... over GPU in a server less fashion... we have an API for it. Every new user will gain 3ms for every new key. WOW, Imagine the gain over millions of users!!! Push that in the official pipe fucktard!.. What are you waiting for? Wait, no, change the whole service name and infrastructure. Move everything to CLSG (cloud lambda service ... by Google); that is it, brilliant!

And Oh, yeah, to secure the whole void, bury the doc for the new hash under 3000 words, lost between v2, v1 and some other deprecated doc that also have 3000 and are still first result on Google. Finally I think about it, let go the doc, fuck it... a tutorial, for 'weak ass' right.
One last thing, rewrite all your tech in the latest new in house language, split everything in 'femto services' => ( one assembly operation by OS process ) and finally cramp all those in containers... Agile, for sure it has to be Agile. Users will really appreciate the improvements of your mandatory service.

I fucking cannot stand CMake. I hate this stupid fucking piece of software. I've been trying for 3 fucking days to get SDL2 to link just once and I cannot. It doesn't work in the slightest.

Every time I look for help I find a Stack Overflow post from 5 years ago about someone having the exact same problem and all of the responses are "This function is deprecated, use this instead"

THAT DOESNT SOLVE MY FUCKING ISSUE
WHY DOES CMAKE DEPRECATE THINGS EVERY 1.5 YEARS

THIS ACTUALLY MAKES ME WANT TO SWITCH TO INTERPRETED LANGUAGES I CANNOT STAND BUILD SYSTEMS

SURELY IT CANT BE THAT HARD

WE HAVE OPERATING SYSTEMS, AERODYNAMIC SIMULATIONS, AND A GLOBAL COMMUNICATIONS NETWORK BUT WE CANT FUCKING PASS COMMANDS TO GCC PROPERLY?????

I know more people thar should be here

Why can we deprecate a regular language like Python 2 (26 months can't come by fast enough) but yet it seems web development is impervious to the idea? If you want to make a website, you must use HTML, CSS, AND JS (or a transpiled language).

I get we use it for backwards compatibility but this combo makes web development so messy and weird, it's hard to understand from a newcomers perspective.

Maybe I'm just too stubborn to understand 🤔

Please support old web browser versions for all eternity.

I hate it when I open a site like SoundCloud one day and am greeted with a "we no longer support your browser" notice. Now I am forced to update my browser to a new version with removed features. On Android, Chrome sometimes crashes due to an apparent memory leak, so I have to go back to Samsung Internet, which does not work with some sites. Also, the Samsung clipboard manager (which can hold up to 20 items) is only available on Samsung Internet, not Chrome or Firefox.
I also have to update the browser on my live USB bootable stick because sites stop supporting it. Any browser starting in 2015 (ECMA script 6) should be supported until at least 2050 so that I never have to fear that a site one day spontaneously stops working on my browser.

I would like to browse the Internet forever without having to ever worry about pages to stop working one day. Browser vendors might also deprecate support for devices and operating systems. Old devices also have replaceable batteries and are easier to repair. I don't want be forced to buy new devices that are difficult and expensive to repair.

Tool question, I can't find any after some googling. But are there any tools out there for dotnet that help you find class, method, and property references outside a solution.

Say I have a bunch of solutions and I need to know where a class is referenced to determine whether or not I can deprecate it. Is there anything out there that would scan other solutions for references to that class?

Before each release of Exoplayer, the developers sit at a round table and randomly pick at least 50 APIs to deprecate.