"Fuck JavaScript, its such a shitty language" seems to be quite a common rant today. It seems as if JS is actually getting more hate than PHP, which is certainly odd, considering the stereotype.

So, as someone who has spent a lot of time in JS and a lot of time elsewhere, here are my views. Please, discuss your opinions with me as well. I am genuinely interested in an intelligent conversation about this topic.

So here's my background: learned HTML/CSS/JS in that order when I was 12 because I liked computers. I was pretty shitty at JS until U was at least 15, but you get the point, Ive had it sploshing about in my brain for a while.

Now, JS certainly has its quirks, no doubt, but theres nothing about the language itself that I would say makes it shitty. Its a very easy leanguage to use, but isn't overdeveloped like VB.net (Or, as I like to call it, TheresAFunctionForThat)

Most of the hate is centered around JS being used for a very broad range of systems. I doubt JS would be in the rant feed so often if it were to stay in its native ecosystem of web browsers. JS can be used in server backend, web frontent, desktop and mobile applications, and even in some system services (Although this isn't very popular as of yet). People seem to be terrified that one very easy to learn language can go so far. And, oh god, its interpreted... How can a system app run off an interpreted language? That's absurd.

My opinion on JSEverything is that it's progress. Thats what we're all about, right? The technologies already in place are unthreatened by JS, it isn't a gamechanger. The only thing JS integration is doing is making tedius and simple tasks easier. Big companies with large systems aren't going to jump ship and migrate to JS. A startup, however, could save a fucking ton of development time by using a JS framework, however. I want to live in a world where startups can become the next Google, because technology will stagnate when youre trying to protect your fortune, (Look at Apple for fucks sake) but innovation is born of small people with big ideas.

I have a feeling the hate for JS is coming from fear of abandoning what you're already doing. You don't have to do that. JS is only another option (And a very good one, which is why it's becoming so popular).

As for my personal opinion from my experiences... I've left this part til the end on purpose. I love programming and learning and creating, so I've never hated a lamguage, really. It all depends on what I want to do. In the times i've played arpund with JS, I've loved it. Very very easy. The idea of having it on both ends of web development makes a lot of sense too, no conversion, just direct communication. I would imagine this really helps with speed, as well. I wouldn't use it in a complicated system, though. Small things, medium size projects: perfect. Running a bank? No.

So what do you think about this JSUniverse?

me: Just to be clear, we're only supporting chrome?
boss: Yes.

* few days later *

QA: I have a lot of bugs to report, the bosses asked me to test the app in all browsers

Fuck in app browsers. They should be fucking banned, honestly.

Instagram, Gmail, Kik, any if you cunts that have browsers in your app... Go fuck yourself.

Proud of my dad today.

He used to be the type of person who installs any application/software without reading what's being displayed on the screen. And my browsers used to be filled with all those toolbars and random search engines.

But yesterday when he was installing an app on his phone, he came to me asking "why does this app need access to contacts. It shouldn't require them in the first place".

I've succeeded in my mission.

Dad: 1
Shady Dev: 0

Am I the only one who hates in app browsers? I fucking hate them. If I want to look at something later, I like to click the link, then close chrome. I'll have the tab to return to it later. But these shitty in app browsers that you can't turn off makes that a pain in the ass.

Wow, the new React app looks so amazing. Lets test is on different browsers.
Chrome ✓
Firefox ✓
Opera ✓
... ✓
IE 11 ...
1. I am on Mac
2. Let's install virtual box
3. Let's install Windows 7 in virtual box
4. Open IE8
5. Open IE11 download page.
6. IE8 crashes
7. Download and install Google chrome using IE
8. Restart Windows
9. Open staging url on IE11
10. **cking blank screen welcomes you.

The brief history of Facebook open source:
- FB releases React under an oppressive licence that tells "woopsie, can't sue FB if you use React"
- a lot of money goes into making React popular to gain leverage from mass adoption
- VMware bans React in their company
- FB releases Flux to bring state management. It flops. Replaced by what some Russian student wrote in several evenings (Redux)
- Preact is released. It's faster than React, and it has MIT licence. Vue beats React in GitHub stars.
- Under mass pressure, FB changes React's licence to MIT. Initial plan to gain leverage fails spectacularly.
- FB releases Flow Types. It flops. Replaced by TypeScript.
- FB releases their own app market for React Native. It flops.
- FB releases Relay. It flops. Replaced by Apollo.
- FB tries to push React.Suspense for the whole JS landscape to obey and comply to how it works. Community says "Fuck You".
- FB releases react-native-web. It flops.
- Web Components are out in all browsers, adopted as a standard. React doesn't support them.
- Google releases Lit, a virtual DOM framework on top of Web Components to fuck with React. It's a massive success.
- React 18 is out. Still no Web Components support.
- (you are here)

In app web browsers are literally cancer.

the internet was so good before corporate interests took everything over and made it garbage

before you found real people, instead of shills
real hobbies, instead of someone wanting to sell you knockoff shit by pretending to have information on your hobby
real information, instead of stupid politics which pretend information doesn't exist and keep changing Wikipedia pages or brigading forums with spam or reporting websites or servers as violating rules to remove innocent people and ruin their shit

before you could find tools and use them
and there were no ads
even when there were ads they were just banner ads where you got free iPods and maybe a virus
but they didn't subscribe you to their service monthly and then play psychological tricks on you so you couldn't cancel
even when the popups came we had popup blockers, and the web browsers were on our side and made the feature widespread and viewed the popups as malicious, and now the world's biggest ad company serves the most popular "open source" browser and is in a war against usability because they have to display their brain malware ads to you or else

and you'd get excited to get an email, instead of annoyed it's more fucking corporate spam you don't want from a random website that required you to give your email address so you could've bought a trinket for your friend Bob's birthday that one time and now their subscriber list keeps "forgetting" you unsubscribed

phones have a billion sensors but the app stores are so infested with bullshit none of it matters
it's all rot
everything is starving and making your life worse

we used to do so much with so little
and now we have so much and leave it all on the table to throw poop at each other

don't forget that brigade science tells you nostalgia is you remembering something to be better than it was. be gaslit. webpages disappear now, too. they get changed. archive.org has the records, and got DDoSed the other day. I knew this day would happen. everyone who lies would love for there to be no archives, no records. to burn the modern books

In-app browsers in mobile apps are so fucking pointless. People have default browsers for a reason. Why the fuck would I want to open external links in your shitty in-app browser?

- Deep-linking wouldn’t work.
- Users might not be authenticated to view the external links so they’ll need to sign the fuck in again - through your app.

Why the fuck do people do this shit?

Me as a mobile app developer trying to add a button to a page of a .Net website:
So, what do i need to do?

Web developer:
Oh that's easy. You need to edit that template which produces html, add an event in there that will call a javascript function, which is in a .js file, which is generated from a typescript file. Than you should give that button a style. Simply by opening up that .less file here and adding a class which will be translated to css later. In that c# file over there you add a bundle reference which contains the css and js files, but before that, they must be minified. In that other c# file, you add a controller that handles your button.
Aaand... take care of new js features and css features. Most browsers don't support them. Those cool C#7 features you love so much... not in this project. Our build servers don't support C#7. Those new features are evil anyway.

😭

Don't you hate it when your testers file an issue under the mobile app project for bugs in the web app, because they happen to be using the web app on their mobile phone browsers and suddenly its the mobile app dev's fault?

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

Pull-to-refresh is useless.

If you are a mobile app developer, please get rid of pull-to-refresh. Your users will thank you.

I have the impression that mobile app developers choose to implement the pull-to-refresh gimmick just in order to make their app comply with a design trend. It seems like a desperate attempt to appear "modern" and "fancy", not because of the actual usefulness of the gesture.

Pull-to-refresh is one of those things that are well-intended but backfire. It appears helpful on first sight, but turns out to be a burden.

It takes effort and cognitive strain to avoid triggering a pull-to-refresh. The user can't use the app relaxed but has to walk on eggshells.

Every unwanted refresh wastes battery power, mobile data (if it is an Internet-connected app), and can lead to the loss of form data.

To avoid pull-to-refresh, the user has to resort to finger gymnastics like a shorter swipe for scrolling up or swiping slightly up before down. Pull-to-refresh could even be triggered while pinch-zooming in or out near the top of a page, if the touchscreen does not recognize one of the two fingers.

Pull-to-refresh also interferes with the double-tap-swipe zoom gesture. If one of the two taps are not recognized, a swipe-down to zoom in can trigger a pull-to-refresh instead.

To argue "if you don't like pull-to-refresh, just don't use it" is like blaming a person who stepped on a mine, since the person moved and the mine was stationary.

A refresh button can be half a second away in the menu bar, URL bar, or a submenu, where it is unlikely to be pressed accidentally. There is no need for a gesture that does more harm than good.

Using a mobile app with pull-to-refresh feels like having Windows StickyKeys forcibly enabled at all times. The refresh circle animation sticks to the finger.

If the user actually wants to refresh, pull-to-refresh is slower than a refresh button in a menu if the page is not at the top, meaning pull-to-refresh is useless as a shortcut anyway if the page is in any other position than the top.

An alternative to pull-to-refresh is pull-for-details. Samsung did it in some of their apps. Pulling down against the top reveals additional information such as the count and total size of selected items.

If you own a website, add this CSS to make browsing your website on the pre-installed Android web browser not a headache:

html,body { overscroll-behavior: none; }

Why is this necessary? In 2019, Google took the ability to deactivate the pull-to-refresh gesture on their Chrome browser for Android OS away from users. On Chrome for Android, pull-to-refresh can only be disabled on the server side, not the user side. The avalanche of complaints? Neglected.

Good thing several third-party browsers let the user turn off this severe headache.

German banks in-app browsers in a nutshell

So you remember the old, not so good days, when your app worked in all the browsers besides stupid Internet Explorer?

So I through those days were long gone, and today ticket that functionality doesn't work in Edge.

Good part of the story? Ticket number is 666.

What are some of your Linux desktop preferences and workflow improvements?

I use Mutate for app launching, DDG searches, and a dozen or so scripts I wrote myself.

I like different URLs to open in specific browsers, so I wrote a script called xhttp that determines which browser to open with URL regexes, and used freedesktop to register it as a browser, and set it as my default.

Anything fun you've done?

In my experience, any BE dev or old architect/lead programmer that says they “can do frontend” does shit like writing Ajax calls in script tags directly in the html. They are the ones who add style attributes directly in html. They are the ones who google how to center a div and they still use float positioning because all of them are old, arrogant BE devs who get caught in a single framework who convince themselves they are an expert. They can’t give any good UX advice. They don’t know how to use a screen reader. They don’t know what WCAG means. They don’t constantly keep up to date on what browsers are supporting and what’s being released in the unstable versions. They don’t know what a web component is. They don’t know what a closure is. They don’t know anything about optimizing web perf metrics. They couldn’t tell you what web crawlers look for. They couldn’t tell you anything about design principles and anti-patterns. They don’t know how to manage a web application that will be seen by millions AND keep it nice, shiny, and refactorable on the code side. What do they really fucking know? how to write an MVC app? How to connect APIs and integrate code that other people wrote? I do full stack all day and writing anything not-client-facing is super easy.

Take that stick out of your ass and get over yourself you asshole. You haven’t written anything close to amazing even though you constantly act like you’re a god-tier programmer and your shit doesn’t stink.

Hit the books like the rest of us you fuck.

The Frontend is anything but fucking easy.

Here some more information to despise Apple.

In the past few weeks I keep having a problem making the iMac connect to whatever website/host, so I had to rerun whatever I had to do: fetching from github, push to github, connecting to a LAN server, pinging to know to IP, accessing a webpage and so on.
Luckily enough, browsers tend to request again if an error occurs.

At my job, I upload app files to servers, like GooglePlay and AppStoreConnect.

For those who don't know, Google makes you upload the app through the browser (among other ways) while Apple requires you to upload your app either through XCode. No other possible ways.

Whenever XCode requires an update, the authentication is required, but the authentication server cannot be reached for at least 5-6 tries.
Then I have to upload the app and just to be ready to hit the "upload button" it takes like 3-4 minutes, which might be completely useless if a network error occurs.

How hard is it to make your fucking app-loader to try again at least a few times?

Getting your web app working on mobile Safari and iOS like the other browsers is the worst nightmare, like in the old days with IE. It has a lot of stupid restrictions and lacks support for browser standards.

Apple is fucking EVERYONE over with Safari 12. They are changing how extensions communicate with the browser, they are calling the new type of extensions Safari App Extensions. It means all current Safari Extensions will not work in Safari 12.

The problem with this is that they require all extensions to have this “backend” written in Swift with a VERY LIMITED API. Maybe you want to close a tab with your extension? “Fuck you, you’re not allowed” are Apple’s response to that. On top of this shit show their documentation is horrendous.

They will kill the extension ecosystem with this new approach, I’m sure of it, because most of the current extensions will not be able to migrate all their features to the new approach. They have built the API around specific extension types, so lots of extensions will simply not work in Safari 12. For distribution they will only allow extensions to be distributed via their new(?) Extension Store where they will review your code, just like an app for App Store. Unless you’re in the Apple Developer Program, which is $99/year.

I do not understand this change and I think it will hurt Apple in the sense that people will use other browsers where extensions are not as strictly controlled. Usually I understand Apple’s changes but this one is just beyond me. 🦆 you 🍎.

I actually want to rant and pitch a product idea here:

So I am furious when i found out Gravit Designer made offline mode premium only, seriously what the fuck. And Figma is getting no progress for the offline mode either - even lacking grids that I need (I might do isomorphic and I also need grids to keep things aligned).

To be honest I liked Figma more now than Gravit (screw you Corel for fucking up a great platform). So that's why I want to do something similar to Gravit Designer, universal and all, works in browsers, without the forced paywall in my face.

I always forsee premium as a way to add features to products when you need it, and as a way to let a developer know they're doing a good job. I want to make this kind of model stick, and it seems with the money-hungry fuckwits of Corel on Gravit, it ain't happening.

So that's why I want to build an designer app that does what Gravit does, except, I want premium to be more ethical, giving all the core features, add more customizabilty to the interface, and actually make the designer workbench yours. Heck, if its possible we can have Google Drive/Nextcloud integration as well for those who want cloud saves.

I badly want to do this because I believe someone out there shares my sympathy. Gravit was a nice product but was ruined by Corel's greedy paywall system. I won't be paying 99 monthly just to get offlline mode. Affinity and Figma's model is better.

Corel you fucking suck

holy shit I swear taxes are like the government trying to tell you you're a peasant to them

my medicare card is about to expire and FOR SOME REASON now the process to renew is a fucking interrogation about various documentation the government has given you. before it was just your damned name, date of birth, and a new photo for the card.

evidently they were supposed to send you snail mail 3 months before expiration. evidently also the only way to renew is get this said snail mail.
and evidently I have to go through this "catchall" change your address with everything in the government process
which is a little ironic
because
to use this service you need to give them something called a notice of assessment, which is when the government accepts your taxes they send you back one of those
well I haven't had access to my tax portal for years. I keep filing them and getting excess money back but I can't actually see any of my returns.
so I tried this time
12 pages of verification and more verification... you do one step, it says wrong info because if you have to write in 2,474 well turns out the , fucks it up and your info doesn't match what's on file and if you fail more than 3 times you'll be locked out. repeat. page after page. how many fucking pages are there? what format are they expecting? nobody fucking knows. you'll get to find out if you pass just this one more!
after about 4 hours of this shit
and they have 2 factor authorization now?! wtf.

then this next step is id verification or we snail mail you a code (WHICH AGAIN IS IRONIC)

I chose id. health card doesn't count, it notifies me later. thankfully I have a passport. bad news, passport expires this September so guess who is gonna be having more fun later
the app of course can't use my camera in the browser I have, so I start downloading fucking other browsers and finally hit one that works
also they lied. they also want a selfie. then it tells me I failed to look like myself. if you fail to look like yourself 3 times you are denied.

ok. so I try snail mail. the page says if I revoke consent to id I can go do the snail mailed code. they lied. if you revoke consent it exits the whole wizard. you enter all the verification steps again.

I try to get them to snail mail me the code. they want some basic info they asked me like 16 times now, and a postal code. ironic. well this is the tax people, so by this point I found all my previous sent in tax returns (though I can't access the government's replies). checked. yep. address all the same. put in the postal code. nope. somehow it's wrong. 3 times I put all this random info in in different ways. 5 times and I'm locked out.

now fucking what.

THE FUCKING IRONY OF
I NEED TO CHANGE WHERE I LIVE SO YOU CAN SNAIL MAIL ME SOMETHING
AND TO CHANGE WHERE I LIVE I HAVE TO CONFIRM WHERE I LIVE SO YOU CAN SNAIL MAIL ME SOMETHING FUCKING ELSE

the government just fucking dunks on you

guess we're all not having fucking medical cards anymore. all we do is pay taxes, and can't even see the paperwork to those taxes we pay.

I am some Kind of angry right now.
Some of you may know the App "Jodel" (for those who don't: it is an app which lets you talk to strangers at in your city/near your location)

I am in an informatics-Channel and I feel a bit annoyed.

There is a groundless hate against JavaScript or Java, it seems because... People feel cool? It remembers me of the PHP-Hate. Clueless people are talking shit, even if the web is not even their programming-field of activity.

Someone just said that in js you can do any shit and it works.
- you can leave out semicolons. wow.

Another one meant that one problem is the unlogical backwards-conpatibility. "You have to look if the script is running on the browsers and on your engine."
- Isn't that part of any programming language? To see if it works?

I don't know what to say right now.
#ilovejs

Uhm btw.: Can someone explain me, what he meant with "engine"? I mean there is an interpreter, but "engine"?!

I really need to appreciate IE in so many ways. It let us to install other browsers, test crap JavaScript code and finally recommending customers to use IE to support their app.

Us users would never accept data lock-in for photos and videos from the camera app on smartphones.

Yet, for some reason, we accepted data lock-in for saved pages on mobile web browsers.

It seems to me that browsers lagging behind is the reason we've seen the JS framework boom both in recent years and ongoing, evident in what they regard as major updates. Most of the functionalities implemented in my time working on the front end are high level problems ubiquitous enough to have been solved at the browser level. Same goes for all the optimizations CSR frameworks are struggling to attain. Every CSR app genuinely feels like recreating a browser, both in UX and dev requirements. These problems exist because current browsers are analog software still accustomed to loading all content at once, no in-app state, just scroll states

The React-Vue-Angular wars of today are a direct hat-tip to the Netscape-Microsoft wars of the early years. If they can form a coalition that sets a standard for syntax, best rendering engine, natural way for user facing devs to control app state, fetch data or connect the back end, somehow render this on the server or find a workaround SEO issues on CSRs, etc, given the shared agreement on expectations for modern web software, it'll be fascinating to see such a possibility

If your SPA doesn't work with the browsers navigation buttons . . . go fuck yourself and fix your application.

At work I have to deal with an application that manages work tickets. There's a login page, an overview console and a page for each individual ticket (and a whole bunch of other pages that I'll ignore for this rant.) If I click on a ticket to view it I go to a new page, right?

What happens if I want to go back to the overview? I hit back on my browser. That should take me back!

WRONG

Nope. Because it's a single page application with no fucking routing programmed, the browser still thinks that the login page is the last page so it takes me there instead.

Like come on, good UX/UI design takes advantage of what the user expects and what the user is used to. The user expects the back button to take him back one page, and therefore it is the responsibility of a SPA developer to mimic that capability in his app. I don't know what framework this web page uses (it has none of the recognizable hallmarks of React or Angular) but for gods sake, implement a freaking router.

Why is there no forward button in any app? Just like browsers

A question.
I understand ads on browsers that use cookies, but I don't understand how I get the same ad on a mobile app say instagram, for a search I did on laptop browser?

Thanks in advance.

It's these individually tiny annoyances in products and software that together form a huge annoyance.

For example, it's 2022 and Chromium-based web browsers still interrupt an upload when hitting CTRL+S. This is why competition is important. If there was no Firefox, the only major web browsers would, without exception, have this annoyance, since they're all based on Chrmoium.

I remember Chromium for mobile formerly locking scrolling and zooming of the currently viewed page while the next page was loading. Thankfully, this annoyance was removed.

In 2016, the Samsung camera software was updated to show a "camera has been opened via quick launch" pop-up window when both front and rear sensors of the smartphone were covered while the camera was launched by pressing the home button twice, on the camera software Samsung bundled with their custom version of Android 6. What's more, if that pointless pop-up was closed by tapping the background instead of the tiny "OK" button or not responded to within five seconds, the camera software would exit itself. Needless to say, this defeats the purpose of a quick launch. It denies quick-launching while the phone is in the pocket, and the time necessary to get the phone out could cause moments to be missed.

Another bad camera behaviour Samsung introduced with the camera software bundled with their customized Android 6 was that if it was launched again shortly after exiting or switching to stand-by mode, it would also exit itself again within a few seconds. It could be that the camera app was initially designed around Android 5.0 in 2015 and then not properly adapted to Android 6.0, and some process management behaviour of Android 6.0 causes this behaviour. But whatever causes it, it is annoying and results in moments to not be captured.

Another such annoyance is that some home screen software for smartphones only allows access to its settings by holding a blank spot not occupied by a shortcut. However, if all home screen pages are full, one either needs to create a new page if allowed by the app, or temporarily remove a shortcut to be able to access the settings.

More examples are: Forced smartphone restart when replacing the SIM card, the minimum window size being far too large in some smartphones with multi-windowing functionality, accidental triggering of burst shot mode that can't be deactivated in the camera software, only showing the estimated number of remaining photos if less than 300 and thus a late warning, transition animations that are too slow, screenshots only being captured when holding a button combination for a second rather than immediately, the terminal emulator being inaccessible for the first three minutes after the smartphone has booted, and the sound from an online advertisement video causing pain from being much louder than the playing video.

Any of these annoyances might appear minor individually, but together, they form a major burden on everyday use. Therefore, developers should eliminate annoyances, no matter how minor they might seem.

The same also applies for missing features. The individual removal of a feature might not seem like a big of a deal, but removing dozens of small features accumulates to a significant lack of functionality, undermining the sense of being able to get work done with that product or software when that feature is unexpectedly needed. Examples for a products that pruned lots of functionality from its predecessor is the Samsung Galaxy S6, and newer laptops featuring very few USB ports. Web browsers have removed lots of features as well. Some features can be retrofitted with extensions, but they rely on a third-party developer maintaining compatibility. If many minor-seeming features are removed, users will repeatedly hit "sorry, this product/software can not do that anymore" moments.

First time would be when I had two teachers working of a bug that resultet in the CSS not loading / updating properly. It took me around 1 hour as well to realize that the text file was encoded with some obscure windows encoding, that doesn't load chrome (and maybe other browsers) can't load properly.

Thanks notepad++, will never use you again for web development.

Second time would be when I presented an app I made too the same teachers in order to boost my mark. Bugs that never appeared before every where and the basic functionality of the app was questionable. I hadn't worked on that app for half a year and had to fix as much as possible in a short amount of time, which might have made it worse.

Don't ask why but thanks to my knowledge about the france language I got a better mark, even though it was spanish