Learn More
Resend Email
4
exerceo
55d

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
Favorite
Ranter
Comments
  • 4
    55d
    yes, before (progressive) web apps, there was the cache manifest, the only useful but also dangerous static feature, to allow browsers (again) to deliver cached static content offline, then they introduced the overengineered PWAs, then everyone did React and made SPAs, WTF
  • 0
    55d
    Well I mean how else are you going to create a feature rich dashboard by only delivering static content. All that matters is the performance.
  • 1
    55d
    @shovethisrant As I said, some stuff is not possible without JavaScript. If the JavaScript fails to load, a lightweight non-interactive version needs to be shown.
  • 3
    55d
    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.
  • 0
    54d
    Yes let’s go back to 1999.

    More seriously, let’s say my site has an undetermined amount of photos that are supposed be displayed in boxes with text, please tell me how I can do this using html and css only
  • 0
    54d
    @black-kite Already addressed in the paragraph that starts with "I get it, some things such as…".
  • 0
    54d
    @jestdotty You are referring to homescreen shortcuts. Nothing is preventing an HTML-based site from having a homescreen shortcut.
  • 0
    54d
    @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?
  • 0
    54d
    @black-kite Indeed, and that content can be loaded by JavaScript. However, there is no reason to have the initial page load through JavaScript.
  • 0
    54d
    Because web app can work offline, without any need for a server whatsoever. For example, there are web-based hex editors that work offline right in your browser. You upload a file, edit it and download the modified version
  • 0
    54d
    @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.
  • 0
    54d
    @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
  • 0
    54d
    @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
  • 0
    53d
    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
  • 0
    51d
    @calmyourtities JavaScript can just as well update content on an HTML-based page.

    YouTube did it with real-time live streaming view counts since at least 2016.

    The problem is with pages that are loaded entirely through JavaScript.
  • 0
    51d
    @exerceo but it becomes much more tedious without reusable components
  • 0
    51d
    @calmyourtities Components such as AJAX functions can just as well be re-used across an HTML-based page.
  • 0
    51d
    @exerceo in that case, you’re sending plenty of boilerplate, redundant markup and using up unnecessary bandwidth
  • 0
    50d
    @calmyourtities I don't think so. One can have a function to handle the AJAXing (requesting information from the server), and a function to insert or append the new data on the visible page.

    For loading additional content when scrolling down, the server can either send HTML content that can be inserted at the bottom (archive.org did this before they switched to web app), or send JSON content which is then converted to HTML by a script on the client side.
  • 0
    50d
    @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>`

    }
  • 0
    50d
    @calmyourtities Indeed, however, for a slight improvement of readability in code, one gets much worse loading performance and worse compatibility with older browsers.

    React JS also is at the mercy of Facebook… excuse me, I meant Meta. This means some update might break functionality.

    Also, the feed can be referenced from a variable.

    var feed = document.getElementById('feed');
  • 0
    50d
    @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.
  • 0
    49d
    @calmyourtities

    "that’s a slight improvement in readability that could happen thousands of times in a big project"

    Valid point. Then the worse loading performance on the user side simply is collateral damage.

    However, HTML-based sites depend less on JavaScript to begin with. More stuff is done on the server side.

    "depending on the scenario, the difference between loading without react or with react could be 250ms and 500ms respectively"

    When Twitter switched to React in 2019, it took two to three times as long to load. Similarly, YouTube switching in 2017 from HTML to Polymer, a multi-megabyte JavaScript bomb, tripled the time until anything useful appeared on screen.

    "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."

    Agreed.
  • 0
    49d
    @calmyourtities (part 2)

    "i can’t emphasize how much i miss the <marquee> tag."

    Ah yes, marquee and blink.

    But those are not critical to functionality. A site that used the tags will still render in modern browsers, because HTML and CSS are fail safe.

    Also, blinking text would be an annoyance to me anyway. The functionality of marquee and blink can be replicated using CSS animations. But better shouldn't be.

    However, one unsupported JavaScript function and a blank page or some other kind of error appears. But no useful content.
  • 0
    42d
    Addition: Web apps are also difficult to archive. They require headless browsers that create WARC files that need a "WARC player" to open.

    HTML-based pages can be archived as simple HTML.
  • 0
    37d
    See also:

    https://tantek.com/2015/069/...

    By former Mozilla developer.
  • 0
    37d
    @exerceo go tell that to product owners and stakeholders who want feature rich applications
  • 0
    36d
    @black-kite Then which feature can not be added to an HTML-based website?

    HTML-based means JavaScript can be added on top. Just the initial load should not depend on JavaScript, because it's faster and more reliable that way.

    Also read:

    https://jakearchibald.com/2013/...

    Performance comparison:

    https://jakearchibald.com/2013/...
Related Rants
devRant © 2021 Hexical Labs LLC
Privacy Policy  |  Terms of Service
Add Comment