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 - "loading screens"
-
Grumpy cat was in a lot of our internal products, on loading screens and what not, because why not? PM got pissed and said if he sees that fucking cat again blah blah blah. Grumpy cat is now summoned with a Konami code. Grumpy cat will never die.2
-
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 -
Much obliged if you stop reloading the folder and searching it every five fucking seconds you fucking cunts.
Good god damn this fucking 'feature' of windows 10 grinds my fucking gears. I hit 'x' to stop seeing the visual distraction of the fucking green loading bar when the folders already loaded. Same thing with music. All I want it to do is open and play my fucking song.
Does it do that?
No instead it spends precious cycles updating fucking indexes or sprinkling crack rocks on the corpse of my cpu or whatever cycle fairies at fucking microsoft programmed it to do while wasting my fucking time.
I wish I had a brick and a microsoft programmer within throwing distance, I'd be sorely tempted to nail the motherfucker square in his fucking big fat melon.
Cunts.
fuck count: 86 -
Few years ago as a junior android dev with couple years of self taught experience of working in startups I submitted a simple android app assignment for a junior android dev role. Assignment had only like 8 requirements so I followed them to the letter. That didn't end well.
App was simple just 3 screens. Login screen with username and password input fields, login button.
Had to call a login endpoint after login button was clicked, redirecting to home screen, calling items endpoint, displaying a list of items and when an item was clicked passing item data and redirect to item details screen.
Needless to say big swinging dick senior was not impressed. UI was not perfect, I forgot to display a loading animation when fetching data, didnt handle back button properly.
I agreed with some points but other comments were clearly just nitpicking: his preferred variable naming conventions, his opinions on architecture that was not up to his standard (official google arch at the time was not up to his standard).
He also was mad that app wasn't prepared for release to googleplay (another out of the ass requirement). Like I would prepare a 3 screen app for prod release that he will forget ever existed after 20min of his review.
Lots more of nitpicking, encapsulation this encapsulation that, omg now hes shocked that there are a few warnings after the project is built.
Regardless my self confidence was destroyed at that point and after few more negative experiences I dropped android dev alltogether for a couple years and switched to game dev.
After game dev ran its course I went back to android dev and found a supportive place where I could grow.
Looking back, they were actually hiring atleast a mid level for a junior position but I was grilled as a senior. The guy literally didnt wrote any single positive thing in that review about my code even tho my senior peers said my project was decent back then, its just that I didnt handle a few edge cases and that's all.
I looked up the guy in linkedin, turns out hes a uni dropout who posts all books that he red about software dev in his education section of his linkedin profile. Found a bunch of other narcissistic stuff on his profile. Guy was a fucking idiot. Even if I worked under him it would have probably sucked.
Learned some important lessons I guess. Always get a second, 3rd and 4th opinion and dont take criticism too seriously. Always check what kind of person is providing feedback.4 -
When I just started programming I aways added fake loading screens and hard-coded login screens to my c# applications because it looked cool..
But I also always added an invisible panel to the top right so whenever you click that it would bypass the login screen.
I had to do that because 1. I will forget that password after 2 seconds, 2. I got no time for that login screen.2 -
To all of you:
Nobody enjoys loading screens. Just because the UI reacts on things, doesn't mean that the actual job gets fucking done.
So instead of using some shitty progressbar you copied from a dev who copied it from a 90's textbook, show some cat images.
The fucking internet is full of it and if your shitty Hello World app that is wasting 300MB of my RAM is dieing in the middle of some loading process, you could at least ease my pain.
Please. Show cat images instead of a progressbar. Thank you ❤️8 -
I fucking love Asynchronous Action creators in Redux.
I little more work upfront makes for a well thought out application and makes things like loading screens stupid simple. -
in my previous company , we used to create 4 custom ui states for just 1 screen in android app, and we would have task to create 3-4 new feature screens in 1 sprint (of 14 days) the states would be :
empty state : a state where data is not available. usually consisted of message, a graphic and some action button
data state : the usual state where data is filled on various elements
loading : a shimmer ui showing loading. it was supposed to be pixel perfect to that of the data state. it was basically a different xml, but with grey colored views instead of colorful. the tricky part would usually he to create the dynamic views
error/no connection state : as most of the screens couldbget api error or no internet error, this would be the screen for asking user to retry connection
all of these screens combined with their ui in xmls + kotlin code with barely any stuff being reusable , made the life incredibly difficult. however a lot of our customers would appreciate the interactivity of our app
doing these stuff again nd again , i had become trained to do all those 3-4 (x4) screens and the whole ui stuff in first 4 days of the sprint. but now i am in a company where i am getting passed on to managers after managers and getting tasks to change documentation in 1 week, i find those coding stuff incredibly tough.
gotta get back to shape -
I hate application launchers.
When i start an application, i WANT IT TO START. What i don’t want is your bullshit, custom, logo and splash screen infested piece of shit launcher to start up, with the only option of loading a project or file up, or worse than that, when the only option is to start the fucking application, which should have already happened.
Also, splash screens. Fuck your 5second branded splash screen when your cocksucking application has the fucking loading footprint of MS Notepad.2 -
There have been a few :)
If say it's a videos utter project I initially though was good. Apart from loading a view the controllers didn't do anything - my initial thought was some magic was happening behind the scenes.
However, when I opened up the view things changed.
ALL the business logic happened in the view. Everything. Form processing, consuming an app, file uploads, validation, crud ... You name it, it happened in view. The developer created a raw MySQL connection and build his queries by concatenation g strings, the whole system was wide open to sql injection.
Even more annoying was the "source control" he invented. Every file had several copies. I.e. "User(working).php", "user_v3.php" and even "user(working_no_profile_fields_1.php". It wasn't even like there was any consistency in what file was actually used either. A complete mess. The system had around 69 screens too. No idea how the developer got that gig.2 -
Ubuntu 20.4 is not very cool.
It might look "polished" in some (barely noticeable) areas , which doesn't matter to me as i already used better themes and icon packs. Moreover they tried make ui and icons flwt which looks terrible. It feels like to ubuntu's designers , flat= every icon in a dark gray color. Am not a fan of black topbar either, the old darkish looked much better
The worst thing is that now i have to go through multiple start screens since my laptop is dualboot :/ .
Its now like : black screen > (hp+ubuntu logo) + grub > (hp) > (hp+ubuntu logo + loading icon) > lockscreen > my system
Earlier it was just hp> grub>lockscreen>my system. The fast start up was one of my favourite features of Ubuntu, now its a million loading screens. The lockscreen is cool tho6 -
There was this one time when we've managed to upload a Debug build to Google Play Store.
On the same day we had to create a new build w/ fixes, have the testers perform smoke tests, then switch to some fairly quick overall tests.
If nothing were to come up during those tests, the build was supposed to be passed over to the submission manager for release.
Things weren't going that smoothly in the beginning, w/ the first two builds being broken in one way or another.
Finally, however, we managed to create a properly working build.
QA hadn't had that much time to test it, but no major problems were identified && given the deadline we had to submit it.
The next workday it turned out that the tester responsible for passing the approved build over to the submission manager gave him the Debug build.
The submission manager none the wiser uploaded that build for release.
Result?
The users who managed to update their game got their save data wiped... sort of.
It looked that way given the Debug build was communicating w/ a different server.
In the aftermath of that situation, we had to repair the damage && upload the correct build as quickly as possible.
Also, ever since then a huge text 'DEBUG' was added to the loading screens of Debug builds to make people very aware of which build they were looking at.
As for any repercussions for the tester responsible for the mess, or the submission manager - I have no idea.
They were both still working there, so at the very least none of them got fired because of this.