8 ms·

The website vs. web app dichotomy doesn't exist

54 points by jakelazaroff 3y ago

kcrwfrd_ 3y ago
This is a pretty nice overview of the current state of affairs. All that I find missing is some exploration of where frameworks like Next.js and Remix fit into the landscape. Next.js's use of React Server Components (RSC) in its new app router reminds me quite a lot of the so-called "islands" architecture. Straddling this spectrum between "website" and "web app" is a continual challenge for us working on our content creator social media platform at Playboy.
ozim 3y ago
My thoughts are that dichotomy exists. There is whole world of difference between sprinkling some effects an making web app. We also have this dichotomy because using frameworks is all or nothing deal. You mostly cannot just drop it in some place and then use it in other part. From the other side one also cannot really start adding some interactivity here and there to end up with web application. You either build an application and use framework or build a website sprinkling interactivity and effects here and there. Requirements are usually clear from the start. So the discussion is really that too many people use frameworks where they should not. Finally Wikipedia and Wordpress are not static site - their output is - but their editing capabilities are fully web apps as every CMS out there is an app and not website or something in between.
- kcrwfrd_ 3y ago
  FWIW I've been tinkering with Astro this week and it's possible to build a website with zero client-side JavaScript. I wonder if it's possible to achieve something similar in Next.js app router if you never have a "use client" component in your tree? In any case it seems like that's the latest trend, allowing us to use full-fledged frameworks (powered by plenty of JavaScript) while minimizing (potentially down to zero) the client-side JavaScript.
  - solardev 3y ago
    This used to be possible with the page router, and was in fact one of the big selling points (graceful degradation down to raw HTML). I'd be surprised if the app router couldn't do something similar, though admittedly I haven't tried to do that yet. Anyone with experience?
    - kcrwfrd_ 3y ago
      I’m pretty sure you can’t achieve zero client-side JavaScript with pages router. You get pre-rendered HTML and it will gracefully degrade without executing JavaScript, yes…but it still comes with a JS bundle that clients will normally execute to hydrate that pre-rendered HTML into react components. RSCs using the app router, on the other hand, don’t have that hydration phase.
- paulddraper 3y ago
  > You mostly cannot just drop it in some place and then use it in other part You mostly can. In fact, I'm not aware of a major web framework that you can't.
  - zdragnar 3y ago
    Ember might be the last of the old guard frameworks where this is somewhere between hard and impossible (last I looked at it anyway). Nowadays, the main libraries are designed to not totally take over the entire page, though add-on frameworks which want to be "batteries included" (i.e. Next for react) certainly will.
  - andirk 3y ago
    Dropping in is the new thing now. Vue and other Javascript frameworks utilize "web components" https://developer.mozilla.org/en-US/docs/Web/API/Web_components https://developer.mozilla.org/en-US/docs/Web/API/Web_compone... which are supported all over now. You have your `<video src="someVideo.mp4">` that is part of spec, and then you have your custom element `<myVideoPlayerThing src="someVideo.mp4" fartButton="true">` that does wtf it wants under the hood but surfaces as a regular HTML DOM element.
  - ozim 3y ago
    You tried doing it with 6+ developers on the team and full backlog of stuff to be implemented and you were able to explain to everyone why "this specific place" has to be different? With business on board and getting web server configuration aligned with ops to have routes and URLs.
jameshart 3y ago
The taxonomy is useful but it’s not exhaustive, and it’s also reductive. Google Maps flits around to all four corners of this map depending on how you’re using it, and it needs intensive JavaScript support no matter where it ends up. Wikipedia is, it claims, a definitively ‘informational’ site, ignoring that it also supports an enormous massively multiplayer community of active editors and authors constantly changing it. What’s YouTube in this breakdown? What’s StackOverflow?
- jameshart 3y ago
  Actually on deeper reading I think the author bundles a lot of this into what they call ‘transactional’ in the top left. As they put it: > Any service that involves literal financial transactions — like Amazon, or your bank’s website — probably lives here But hang on - I need to be able to grab links to Amazon pages and send them to my friends. I don’t need to do the same with my bank statements. What do these sites have in common that this taxonomy usefully identifies? Forms with input fields?
  - csande17 3y ago
    > What do these sites have in common that this taxonomy usefully identifies? Forms with input fields? Yes, that's what the article says, almost verbatim. The idea of the category is to identify sites that need to interact with a server to be useful, but do not need rich dynamic client-side interaction. The editing part of Wikipedia would be "transactional" under this definition, because (last I looked) the way you edit Wikipedia is by typing your changes into a textbox and clicking Submit. It's not a Google Docs kind of situation where all the editors can see each other's cursors move around and type stuff in real time.
- joshmarinacci 3y ago
  Theoretically YouTube would be informational. It's giant lists of videos. Once you find the page for the video it's media embedded in the page and wouldn't actually need JS to function once the video is downloaded. Just like Wikipedia.
  - 3y ago
userbinator 3y ago
IMHO the distinction is simple: It's a web app if turning off JS means you cannot see anything but a blank page.
- simonw 3y ago
  There are plenty of web apps that work just fine with JavaScript disabled though. I describe my project Datasette a web app, and it works fine without JavaScript: https://datasette.io/content/datasette_repos https://datasette.io/content/datasette_repos (Amusingly I do have a version of it that runs as a completely client-side SPA, by executing the server-side Python code entirely in the browser using WebAssembly: https://lite.datasette.io/#/content/datasette_repos https://lite.datasette.io/#/content/datasette_repos )
- DANmode 3y ago
  No True Scotsman argument inbound. As Simon alluded: Those are just one type of webapp. Find the best examples possible to criticize when writing off a major technological trend.
- solardev 3y ago
  All this means is that the logic was shifted client-side. You could move it all to the backend and render the HTML there if you'd rather. (I wouldn't, but it'd still be a web app, IMO). Kinda like old school Mapquest that was server-side, vs Google Maps that used client-side tile fetches. But both are still web apps, no?
isodev 3y ago
It's still surprising to me that, (as reasonable people) we continue to try to make PWAs happen at the expense of re-inventing decades of OS evolution just to replicate it into a browser.
- shawnz 3y ago
  This seems like a sunk cost fallacy to me. The web has evolved for decades, too, so why is it so wrong to allow it to compete as an application platform with the established desktop operating systems of the past?
  - Dalewyn 3y ago
    Because it's not an operating system (for now). We are essentially bolting on more and more management of hardware onto a userland application residing inside an operating system. At what point is it better to just get rid of the operating system and run the browser directly on the hardware?
    - shawnz 3y ago
      What's wrong with slowly building up the hardware management features of the web? Why is that worse than releasing them in one big bang like traditional operating systems have done? And why worry about the nomenclature to begin with? The web is already serving the use cases of an operating system for many people today whether we like it or not. So maybe it's our terminology that should change to reflect reality, rather than the other way around?
    - jameshart 3y ago
      Because the web solves software distribution, installation and, critically, uninstallation. When was the last time you had to uninstall Hacker News? App Stores also solve these problems, but with the problems of gatekeeping and platform openness.
- bandergirl 3y ago
  I think you’re talking about JavaScript apps vs native apps, not specifically PWA vs native. I make that difference because electron apps are still JavaScript but not PWA, and I suppose you’re talking about the lack of good UI components in the browser.
austin-cheney 3y ago
It doesn't matter whether its more content than events or the opposite. The ingredients and compile target remain the same. People are quick to look for a distinction because they are making the technology more complex than it is, typically with frameworks on top of frameworks insanity. Its a forest for the trees scenario.
maelito 3y ago
I've been developping two websites for more than a year, both pure react web apps, one of them having millions of users per year. Both had the particularity to use Netlify's one checkbox prerendering button. They are heavy computing websites, Google was ranking them in red on lightspeed SEO, since it's now detecting that users are served différent HTML than to crawling user agents. Then we switched to Next, with some "use client" / RSC headaches we moved some heavy computing to provide most of content to Google/users with a good performance, 75-100. 5 months later, still no SEO impact. Curious to get your SEO measures if you followed the same path. Then one website was shared on a big media. SEO went x2 with noticeable keyword changes. Content, refering websites >> supposed SPA drawbacks. The only major advantage of Next to me, aside from being a good framework (but composing React + Webpack + ... is good too), is generating good social share metadata, notably Vercel OG images. TLDR : you're developping a blog ? Use Next with RSC. You're developping an interactive Web app ? Use React + prerender and avoid all the server side rendering headaches, or use NextJS with top levels "use client" and "SSR: false" for some components like maps. Just use Next as a PWA with some server side bonus, and worry about perf later, when you have a audience.
wokwokwok 3y ago
So, an app is a thing. It’s not an arbitrary term; it’s a stand alone program that runs on a device. A “thin client” is also a thing, it’s something that runs “just the ui” for some network application. This is the distinction between web-app and website: state. I’ve worked on a lot of these projects, and that’s what it’s always boiled down to. There are only three combinations: - do you have two state models, one on the sever and one on the client? - do you have one state model on the server and just show views of that state on the client? - or (rarely) do you have state only on the client? All of these “modern takes” are basically just trying to reduce complexity by saying “maybe we only need the server state model? Isn’t that easier?” …and yes; it is easier to model state that way, but, unsurprisingly, other things become harder when you do; but this is not a new invention. It’s not even a new idea. Apps (like, actual apps) have done this for a long time too… and it’s ok. It doesn’t solve all your problems… but sure whatever. However. Maybe we don’t need to invent new ways to describe things that already exist…? I don’t think an arbitrary (and it is) four quadrant breakdown like this really does much to help people navigate this space. Bluntly, you can’t have your cake and eat it too. If you want app like behaviour, you need an app. These things like htmx make things easier, and quicker, but they don’t offer all the power of having a rich client state. If you want something that’s great, shortcuts don’t get you there… but, most people don’t need that stuff, it’s just nice… but if you’re not prepared to pay for it, don’t.
- Dalewyn 3y ago
  >So, an app is a thing. It’s not an arbitrary term; it’s a stand alone program that runs on a device. "App" is an arbitrary term, the word you are looking for is application. >Maybe we don’t need to invent new ways to describe things that already exist…? I agree. Can we also stop saying "AI" to refer to algorithms and macros which referred to applications?
  - wokwokwok 3y ago
    https://www.apple.com/au/apps/ https://www.apple.com/au/apps/ There is a common usage for these terms, they are not arbitrarily. Describing websites purely on a “static vs dynamic” or “online vs offline” is arbitrary. That is simply assigning subjective values to the way you interpret a website as behaving and then categorising all websites by that subjective set of metrics. That’s what arbitrary means. How do I measure how “dynamic” a website is? Gut feel? It’s a meaningless metric. How “offline” is my website? Is it a bit offline? Certainty I know when it’s entirely off line… but on a scale of 0-10, how “offline” is a website that runs off an api vs one that fetches static json data files? Wouldn’t you say that categorising websites by these metrics is totally arbitrary? I certainly think it is. This is some classic armchair theorising (look it up); first you invent some labels, then you put everything under those labels in a way that is convenient (rather than data driven) then you talk about it to support some ideas you have.
iambateman 3y ago
The only axis that really matters in terms of web development is WordPress vs anything else. The reason the world believes websites offer crippled functionality compared to everything else essentially boils down to the fact that everyone uses wordpress and it’s incredibly hard to enter meaningful from the front end into a WordPress site.
- solardev 3y ago
  > it’s incredibly hard to enter meaningful from the front end into a WordPress site. Hard to enter meaningful what? Missing a word? (Just trying to understand your comment)
MatthiasPortzel 3y ago
I’ve been thinking along these lines for a while. The web has to support pages all across the spectrum, and it’s reductive to argue that one type of website is what a website “should be.”
deleted 3y ago
[deleted]
deleted 3y ago
[deleted]

54 points by jakelazaroff 3y ago

This is a pretty nice overview of the current state of affairs. All that I find missing is some exploration of where frameworks like Next.js and Remix fit into the landscape. Next.js's use of React Server Components (RSC) in its new app router reminds me quite a lot of the so-called "islands" architecture. Straddling this spectrum between "website" and "web app" is a continual challenge for us working on our content creator social media platform at Playboy.

ozim 3y ago

My thoughts are that dichotomy exists. There is whole world of difference between sprinkling some effects an making web app. We also have this dichotomy because using frameworks is all or nothing deal. You mostly cannot just drop it in some place and then use it in other part. From the other side one also cannot really start adding some interactivity here and there to end up with web application. You either build an application and use framework or build a website sprinkling interactivity and effects here and there. Requirements are usually clear from the start. So the discussion is really that too many people use frameworks where they should not. Finally Wikipedia and Wordpress are not static site - their output is - but their editing capabilities are fully web apps as every CMS out there is an app and not website or something in between.

kcrwfrd_ 3y ago
FWIW I've been tinkering with Astro this week and it's possible to build a website with zero client-side JavaScript. I wonder if it's possible to achieve something similar in Next.js app router if you never have a "use client" component in your tree? In any case it seems like that's the latest trend, allowing us to use full-fledged frameworks (powered by plenty of JavaScript) while minimizing (potentially down to zero) the client-side JavaScript.
- solardev 3y ago
  This used to be possible with the page router, and was in fact one of the big selling points (graceful degradation down to raw HTML). I'd be surprised if the app router couldn't do something similar, though admittedly I haven't tried to do that yet. Anyone with experience?
  - kcrwfrd_ 3y ago
    I’m pretty sure you can’t achieve zero client-side JavaScript with pages router. You get pre-rendered HTML and it will gracefully degrade without executing JavaScript, yes…but it still comes with a JS bundle that clients will normally execute to hydrate that pre-rendered HTML into react components. RSCs using the app router, on the other hand, don’t have that hydration phase.
paulddraper 3y ago
> You mostly cannot just drop it in some place and then use it in other part You mostly can. In fact, I'm not aware of a major web framework that you can't.
- zdragnar 3y ago
  Ember might be the last of the old guard frameworks where this is somewhere between hard and impossible (last I looked at it anyway). Nowadays, the main libraries are designed to not totally take over the entire page, though add-on frameworks which want to be "batteries included" (i.e. Next for react) certainly will.
- andirk 3y ago
  Dropping in is the new thing now. Vue and other Javascript frameworks utilize "web components" https://developer.mozilla.org/en-US/docs/Web/API/Web_components https://developer.mozilla.org/en-US/docs/Web/API/Web_compone... which are supported all over now. You have your `<video src="someVideo.mp4">` that is part of spec, and then you have your custom element `<myVideoPlayerThing src="someVideo.mp4" fartButton="true">` that does wtf it wants under the hood but surfaces as a regular HTML DOM element.
- ozim 3y ago
  You tried doing it with 6+ developers on the team and full backlog of stuff to be implemented and you were able to explain to everyone why "this specific place" has to be different? With business on board and getting web server configuration aligned with ops to have routes and URLs.

jameshart 3y ago

The taxonomy is useful but it’s not exhaustive, and it’s also reductive. Google Maps flits around to all four corners of this map depending on how you’re using it, and it needs intensive JavaScript support no matter where it ends up. Wikipedia is, it claims, a definitively ‘informational’ site, ignoring that it also supports an enormous massively multiplayer community of active editors and authors constantly changing it. What’s YouTube in this breakdown? What’s StackOverflow?

jameshart 3y ago
Actually on deeper reading I think the author bundles a lot of this into what they call ‘transactional’ in the top left. As they put it: > Any service that involves literal financial transactions — like Amazon, or your bank’s website — probably lives here But hang on - I need to be able to grab links to Amazon pages and send them to my friends. I don’t need to do the same with my bank statements. What do these sites have in common that this taxonomy usefully identifies? Forms with input fields?
- csande17 3y ago
  > What do these sites have in common that this taxonomy usefully identifies? Forms with input fields? Yes, that's what the article says, almost verbatim. The idea of the category is to identify sites that need to interact with a server to be useful, but do not need rich dynamic client-side interaction. The editing part of Wikipedia would be "transactional" under this definition, because (last I looked) the way you edit Wikipedia is by typing your changes into a textbox and clicking Submit. It's not a Google Docs kind of situation where all the editors can see each other's cursors move around and type stuff in real time.
joshmarinacci 3y ago
Theoretically YouTube would be informational. It's giant lists of videos. Once you find the page for the video it's media embedded in the page and wouldn't actually need JS to function once the video is downloaded. Just like Wikipedia.
- 3y ago

userbinator 3y ago

IMHO the distinction is simple: It's a web app if turning off JS means you cannot see anything but a blank page.

simonw 3y ago
There are plenty of web apps that work just fine with JavaScript disabled though. I describe my project Datasette a web app, and it works fine without JavaScript: https://datasette.io/content/datasette_repos https://datasette.io/content/datasette_repos (Amusingly I do have a version of it that runs as a completely client-side SPA, by executing the server-side Python code entirely in the browser using WebAssembly: https://lite.datasette.io/#/content/datasette_repos https://lite.datasette.io/#/content/datasette_repos )
DANmode 3y ago
No True Scotsman argument inbound. As Simon alluded: Those are just one type of webapp. Find the best examples possible to criticize when writing off a major technological trend.
solardev 3y ago
All this means is that the logic was shifted client-side. You could move it all to the backend and render the HTML there if you'd rather. (I wouldn't, but it'd still be a web app, IMO). Kinda like old school Mapquest that was server-side, vs Google Maps that used client-side tile fetches. But both are still web apps, no?

isodev 3y ago

It's still surprising to me that, (as reasonable people) we continue to try to make PWAs happen at the expense of re-inventing decades of OS evolution just to replicate it into a browser.

shawnz 3y ago
This seems like a sunk cost fallacy to me. The web has evolved for decades, too, so why is it so wrong to allow it to compete as an application platform with the established desktop operating systems of the past?
- Dalewyn 3y ago
  Because it's not an operating system (for now). We are essentially bolting on more and more management of hardware onto a userland application residing inside an operating system. At what point is it better to just get rid of the operating system and run the browser directly on the hardware?
  - shawnz 3y ago
    What's wrong with slowly building up the hardware management features of the web? Why is that worse than releasing them in one big bang like traditional operating systems have done? And why worry about the nomenclature to begin with? The web is already serving the use cases of an operating system for many people today whether we like it or not. So maybe it's our terminology that should change to reflect reality, rather than the other way around?
  - jameshart 3y ago
    Because the web solves software distribution, installation and, critically, uninstallation. When was the last time you had to uninstall Hacker News? App Stores also solve these problems, but with the problems of gatekeeping and platform openness.
bandergirl 3y ago
I think you’re talking about JavaScript apps vs native apps, not specifically PWA vs native. I make that difference because electron apps are still JavaScript but not PWA, and I suppose you’re talking about the lack of good UI components in the browser.

austin-cheney 3y ago

It doesn't matter whether its more content than events or the opposite. The ingredients and compile target remain the same. People are quick to look for a distinction because they are making the technology more complex than it is, typically with frameworks on top of frameworks insanity. Its a forest for the trees scenario.

maelito 3y ago

I've been developping two websites for more than a year, both pure react web apps, one of them having millions of users per year. Both had the particularity to use Netlify's one checkbox prerendering button. They are heavy computing websites, Google was ranking them in red on lightspeed SEO, since it's now detecting that users are served différent HTML than to crawling user agents. Then we switched to Next, with some "use client" / RSC headaches we moved some heavy computing to provide most of content to Google/users with a good performance, 75-100. 5 months later, still no SEO impact. Curious to get your SEO measures if you followed the same path. Then one website was shared on a big media. SEO went x2 with noticeable keyword changes. Content, refering websites >> supposed SPA drawbacks. The only major advantage of Next to me, aside from being a good framework (but composing React + Webpack + ... is good too), is generating good social share metadata, notably Vercel OG images. TLDR : you're developping a blog ? Use Next with RSC. You're developping an interactive Web app ? Use React + prerender and avoid all the server side rendering headaches, or use NextJS with top levels "use client" and "SSR: false" for some components like maps. Just use Next as a PWA with some server side bonus, and worry about perf later, when you have a audience.

wokwokwok 3y ago

So, an app is a thing. It’s not an arbitrary term; it’s a stand alone program that runs on a device. A “thin client” is also a thing, it’s something that runs “just the ui” for some network application. This is the distinction between web-app and website: state. I’ve worked on a lot of these projects, and that’s what it’s always boiled down to. There are only three combinations: - do you have two state models, one on the sever and one on the client? - do you have one state model on the server and just show views of that state on the client? - or (rarely) do you have state only on the client? All of these “modern takes” are basically just trying to reduce complexity by saying “maybe we only need the server state model? Isn’t that easier?” …and yes; it is easier to model state that way, but, unsurprisingly, other things become harder when you do; but this is not a new invention. It’s not even a new idea. Apps (like, actual apps) have done this for a long time too… and it’s ok. It doesn’t solve all your problems… but sure whatever. However. Maybe we don’t need to invent new ways to describe things that already exist…? I don’t think an arbitrary (and it is) four quadrant breakdown like this really does much to help people navigate this space. Bluntly, you can’t have your cake and eat it too. If you want app like behaviour, you need an app. These things like htmx make things easier, and quicker, but they don’t offer all the power of having a rich client state. If you want something that’s great, shortcuts don’t get you there… but, most people don’t need that stuff, it’s just nice… but if you’re not prepared to pay for it, don’t.

Dalewyn 3y ago
>So, an app is a thing. It’s not an arbitrary term; it’s a stand alone program that runs on a device. "App" is an arbitrary term, the word you are looking for is application. >Maybe we don’t need to invent new ways to describe things that already exist…? I agree. Can we also stop saying "AI" to refer to algorithms and macros which referred to applications?
- wokwokwok 3y ago
  https://www.apple.com/au/apps/ https://www.apple.com/au/apps/ There is a common usage for these terms, they are not arbitrarily. Describing websites purely on a “static vs dynamic” or “online vs offline” is arbitrary. That is simply assigning subjective values to the way you interpret a website as behaving and then categorising all websites by that subjective set of metrics. That’s what arbitrary means. How do I measure how “dynamic” a website is? Gut feel? It’s a meaningless metric. How “offline” is my website? Is it a bit offline? Certainty I know when it’s entirely off line… but on a scale of 0-10, how “offline” is a website that runs off an api vs one that fetches static json data files? Wouldn’t you say that categorising websites by these metrics is totally arbitrary? I certainly think it is. This is some classic armchair theorising (look it up); first you invent some labels, then you put everything under those labels in a way that is convenient (rather than data driven) then you talk about it to support some ideas you have.

iambateman 3y ago

The only axis that really matters in terms of web development is WordPress vs anything else. The reason the world believes websites offer crippled functionality compared to everything else essentially boils down to the fact that everyone uses wordpress and it’s incredibly hard to enter meaningful from the front end into a WordPress site.

solardev 3y ago
> it’s incredibly hard to enter meaningful from the front end into a WordPress site. Hard to enter meaningful what? Missing a word? (Just trying to understand your comment)

MatthiasPortzel 3y ago

I’ve been thinking along these lines for a while. The web has to support pages all across the spectrum, and it’s reductive to argue that one type of website is what a website “should be.”

deleted 3y ago

[deleted]

deleted 3y ago

[deleted]