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
-
A web app can and shall do things a website cannot. A website is about delivering content, a web app is about behaviour. Devrant is a website, Discord (the browser client) is not. A non-interactive version of Discord wouldn't even make any sense.
So the question is misformed, or maybe only meaningful in that there are nuts who shell out a web app to deliver what's actually a website.
The classic "load 5MB of JS trash just to show 1k of text" crap. -
@exerceo MOST sites now have an undetermined amount of content. Even brochure websites have an undetermined amount of content because who wants to go add an additional block in an html file anytime they want to add a paragraph or an image?
-
@black-kite
I mean. showing an undetermined amount of content as a website is not a problem without javascript either. You can still server dynamic content with server side rendering e.g. PHP, Jinja2, Thymeleaf... Except instead of infinite scrolling you are given pagination.
It's not like people back in the day kept editing the HTML manually to add every photo. Once you know you gonna need to serve a lot of content you would go with server side rendering and ideally make or include a CMS to manage it.
I feel like many people dislike websites because every time you click a button the whole thing blinks for some reason, as if browsers never figured out how to keep the first displayed html on screen until the second one is rendered in the background and showed over it. I remember a lot of people heralding SPAs because of this. -
@Hazarth i wasn’t going to mention PHP or the use of CMS tools. You had the guts to do so.
Come on now…
OP specifically points the finger at JS (popular skapegoat on devRant these days) but what he regrets especially is not having content readily available instantly.
I don’t really understand the fuss because most brochures sites are Wordpress based (yes I know, PHP), and don’t take much time to load. Maybe @exerceo is extremely impatient and can’t put up with waiting 200ms -
@black-kite I'm not a big fan of PHP tbh, actually I hate it (I've done it professionally for about a year and wanted to kill myself pretty much daily lol) I much more prefer other templating engines for ssr.
And I don't really agree with OP 100% either, but I agree that much like we have the well known meme of "it should've been an email" we should also have a meme for "it should've been a website". Because really not every scroll page full of banners, or a simple review site for movies, games or news needs to run on Angular/React, download a "minimized" 2MB javascript and then pretty much just show me text (oh, and a huge accept-cookies banner ofc)
It's clear that Web Apps are extremely useful and comfortable way to use the web, but there's a limit and the speed is impacted in a real way. For example when a webpage loads all those pseudo-line graphics to show "there will be text here in a moment" That's the time where a static website would've already had the text served -
these other comments are missing two big points in my opinion.
1. if you have data that frequently needs to be changed, a web app is better. initially it may take more time to load and use up more bandwidth, but if your app frequently changes a small amount of data (eg. telling the server to save a boolean value in a user’s settings) it would be much less efficient to reload the whole page to do so, as you would using ssr instead of client side javascript
2. i forgot oops -
@exerceo but it becomes much more tedious without reusable components
-
@exerceo in that case, you’re sending plenty of boilerplate, redundant markup and using up unnecessary bandwidth
-
@exerceo let’s take devrant for example. if you download the data for a feed, you have to render the html for it within the function.
i think most people would agree, this react code:
{…posts.map(post =>
<div>
<p>{post.content}</p>
<span>{post.tags}</span>
</div>
}
is more readable than this:
for(let post of posts) {
document.getElementById('feed').innerHTML += `<div>
<p>{post.content}</p>
<span>{post.tags}</span>
</div>`
} -
@exerceo
1) that’s a slight improvement in readability that could happen thousands of times in a big project. not to mention that there can be independent state if you define a <Post> component
2) depending on the scenario, the difference between loading without react or with react could be 250ms and 500ms respectively. is that really a difference that matters to your user, especially when you can deliver features much quicker and more reliably?
3) loading performance and old browser compatibility are constraints. you’re looking at it backwards. if your project requires old browser support, then you plain and simply can’t use react. don’t argue that the framework can’t do what it doesn’t claim to do.
4) updates won’t break functionality if you stay on older versions. and breaking updates is part of all software, even plain html. i can’t emphasize how much i miss the <marquee> tag. -
@exerceo go tell that to product owners and stakeholders who want feature rich applications
What only relying on JavaScript for HTML form input validation looks like
How is a "web app" any better than a "web site"?
All a "web app" does is adding a JavaScript program as a middle-man between the browser and the server.
Where as "web sites" instantly deliver content, "web apps" deliver JavaScript code that then loads the content and puts it on the page.
A "web site" serves the browser useful content on a silver plate (metaphorically speaking), where as "web apps" serve some JavaScript code and the browser has to do the heavy lifting.
It appears that the only benefit of "web apps" is the fancier name. "App" sounds fancy while "site" sounds mundane. But technically, a "web app" is worse than a "web site". It's both slower and vulnerable to scripting errors.
Why would anyone in their right mind choose to create a web "app" over a web "site" to load text and a bunch of pictures?
I get it, some things such as posting comments without reloading the page and loading new search results when scrolling down are not possible without JavaScript, but why use JavaScript for everything, even where it wouldn't be necessary?
JavaScript should never be required to show a bunch of boxes containing pictures and some text. JavaScript is intended to enhance web sites, not to load entire websites.
As web developer Jake Archibald said, "[100% of] your users are non-JS while they're downloading your JS" ( https://twitter.com/jaffathecake/... ).
See also: I miss the good times when the web was lightweight. ( https://devrant.com/rants/9987051/... )
"App" is not an excuse: https://jakearchibald.com/2013/...
I am sad Archive.org switched to being a web app. But I applaud them for resisting that trend longer than most other large sites.
question
web development
progressive enhancement