Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
red-knot2203222dthanks for the repost
Marl3x2913222d@Crost i need a devRantRant, I want to rant more about the things I read on here then my day to day coding experience, maybe I should just leave this platform
You forgot bananas and pineapples.
Perhaps you are not in the right place here. Best of luck finding a place that suits you.
Midnight-shcode4863218dwebapp - client-side interactive
Midnight-shcode4863218dbut i agree that the current "every page needs to be a pile of shit on top of JS pile of shit" trend is... a pile of shit.
Midnight-shcode4863215d@exerceo yes. that is why i said what i said.
Griddior351dLooking for a cost-effective solution for your app development needs? Hire Ukrainian developers https://devlight.io/blog/... and enjoy their affordable rates, fast turnaround time, and outstanding work quality. With their extensive experience and innovative approach, they are sure to exceed your expectations.
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.
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!
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.
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!".
> "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