4 ms·

What I realized a while back is web development has split into two "routes": building websites and building webapps and I think part of the problem is those two

What I realized a while back is web development has split into two "routes": building websites and building webapps and I think part of the problem is those two often get conflated. With a website, the idea is a visitor might only visit a single page. Under this model you want to ship as little JS as possible, and ensure that if the user just tries to read a blog post, the entire site isn't getting downloaded. Contrast that with a webapp. I'm currently building a real estate investment calculator/dashboard and the mental model is diametrically different than building a website. Unlike a site, I want the entire app to be loaded upfront because the user is using the "entire" app, not just viewing a page. The problem I see is when one is trying to design a "site" but uses the "app" model, or vice versa. Attempt to use an SSR framework like NextJS for an "app" and you are going to have a bad time, likewise try setting up a site like you would a webapp and you are going to have some pretty serious limitations.

davidguetta 4y ago
What country are you from ? I've been doing exactly this in the past year so maybe we could compare / chat about our stuff.
clarle 4y ago
This is it. Another thing with a webapp that someone might use regularly is that the JavaScript bundle that's sent down is cached and you likely won't have that same load time every single time. However, if you have a landing page that someone might only visit once, then you want to optimize for as little JavaScript as possible, and in that case, just a pure server-side render might be best for that job.
simonw 4y ago
I don't think this model actually works in practice, because mobile traffic vastly eclipses web traffic for almost every kind of web application. Tricks that work on desktop - where a web application might stay open in a browser tab for weeks at a time - don't apply on mobile. On mobile, I'm much more likely to drop into your app for a few minutes to achieve a single goal, then navigate away and un-load it again. So assuming that I'm going to pay that loading price once and then keep interacting with your application doesn't actually work - most of my interactions with your app will be a cold start, often with an empty cache too since browser caches on mobile devices (especially cheaper Android phones) are much smaller.
- Scarblac 4y ago
  I think that for many real applications, either mobile is relevant and then only mobile is relevant, or mobile is irrelevant. Not many applications are intended to be used on both. In particular I think most applications for professionals assume you are on a normal computer, not a phone. Consumers, OK.
  - jrumbut 4y ago
    > In particular I think most applications for professionals assume you are on a normal computer, not a phone. Consumers, OK. In 2012 sure, but with so much professional work being done asynchronously and mobile phones/browsers being so capable now mobile availability is table stakes. A few features may be disabled, but if I log in and see a messed up layout or a "please log in from your desktop" screen it's a big red flag for quality/execution shortcomings that will bite me on desktop soon enough.
    - geraldwhen 4y ago
      Many corporations make it prohibitively difficult to get a phone or iPad on the VPN to access on prem services or federated authentication to external services. So I only have to build for laptop sizes and up. For what I do, anyway.
  - simonw 4y ago
    I don't think that holds in 2022. There's an entire class of professionals out there these days who don't use laptops. It's possible to run quite a sophisticated business entirely from a phone these days, and a lot of people who are doing exactly that. Sure, there are professions for which this doesn't work - but even as a software engineer I find myself increasingly frustrated when I can't do things like review a simple pull request on my phone if I'm away from my desk rather than pulling out my laptop.
- samstave 4y ago
  I would love a [control]+click combo on opening a link from my desktop into the mobile viewer of my choice... I should be able to go to HN and "View as safari on ios 15. | View as Chrome/brave/ as Device Type [X]" and assign it to ctrl+middle+shift+click... or some such... I should, be able to see the view, on my machine between the three: Desktop, iOS, Android for the same URL view and see the interactions on desktop.... Is there a reason why one cant just cycle through these views on a single tab of a single browser? Click the button and it just cycles through the view
Scarbutt 4y ago
Your example describe two different extremes, in that case is easy to chose, most of us have to work somewhere in the middle and that's were it gets hairy.
debaserab2 4y ago
Even in that model, it's the developer deciding what is an app and what is a site. There's no inherent need for a real estate investment dashboard to act like an app instead of a plain old website. It might serve many of the developers needs, and maybe some of the customers, too - but such a feature could just as easily be served as a plain old webpage as it could a heavy front loaded application.
- yes_man 4y ago
  > There's no inherent need for a real estate investment dashboard to act like an app instead of a plain old website. How so? This assertion might be conflating your idea of what an investment dashboard should be like and how it should behave with what some team or company has concluded a customer wants. It is inherently a product decision. Actually, claiming server side rendered app suffices for any real estate investment dashboard sounds like the ”developer deciding” angle. Unless you truly are claiming that there never is need for anything except server side rendered payloads in the internet. In which case it’s hard to explain why companies don’t do that. It’s almost as if there are product oriented reasons to have webapps. I think the original comment’s logic stands correct
  - debaserab2 4y ago
    The distinction between app and site is one that is done by the business for the business. Customers don't ask for web apps instead of web sites. You can absolutely serve a real estate investment dashboard as a webpage that serves customer needs, depending on what those needs are. Maybe customers truly are served better by an app experience based on their needs, but all the times I've been involved in that discussion the impetus for moving to an SPA has more to do with internal business needs such cleaner division of code, improved click/ad tracking, third party javascript integrations, and often much more hand-wavey ones that never seem to play out as expected like the myth that SPA's are inherently faster than page loads.

davidguetta 4y ago

What country are you from ? I've been doing exactly this in the past year so maybe we could compare / chat about our stuff.

clarle 4y ago

This is it. Another thing with a webapp that someone might use regularly is that the JavaScript bundle that's sent down is cached and you likely won't have that same load time every single time. However, if you have a landing page that someone might only visit once, then you want to optimize for as little JavaScript as possible, and in that case, just a pure server-side render might be best for that job.

simonw 4y ago

I don't think this model actually works in practice, because mobile traffic vastly eclipses web traffic for almost every kind of web application. Tricks that work on desktop - where a web application might stay open in a browser tab for weeks at a time - don't apply on mobile. On mobile, I'm much more likely to drop into your app for a few minutes to achieve a single goal, then navigate away and un-load it again. So assuming that I'm going to pay that loading price once and then keep interacting with your application doesn't actually work - most of my interactions with your app will be a cold start, often with an empty cache too since browser caches on mobile devices (especially cheaper Android phones) are much smaller.

Scarblac 4y ago
I think that for many real applications, either mobile is relevant and then only mobile is relevant, or mobile is irrelevant. Not many applications are intended to be used on both. In particular I think most applications for professionals assume you are on a normal computer, not a phone. Consumers, OK.
- jrumbut 4y ago
  > In particular I think most applications for professionals assume you are on a normal computer, not a phone. Consumers, OK. In 2012 sure, but with so much professional work being done asynchronously and mobile phones/browsers being so capable now mobile availability is table stakes. A few features may be disabled, but if I log in and see a messed up layout or a "please log in from your desktop" screen it's a big red flag for quality/execution shortcomings that will bite me on desktop soon enough.
  - geraldwhen 4y ago
    Many corporations make it prohibitively difficult to get a phone or iPad on the VPN to access on prem services or federated authentication to external services. So I only have to build for laptop sizes and up. For what I do, anyway.
- simonw 4y ago
  I don't think that holds in 2022. There's an entire class of professionals out there these days who don't use laptops. It's possible to run quite a sophisticated business entirely from a phone these days, and a lot of people who are doing exactly that. Sure, there are professions for which this doesn't work - but even as a software engineer I find myself increasingly frustrated when I can't do things like review a simple pull request on my phone if I'm away from my desk rather than pulling out my laptop.
samstave 4y ago
I would love a [control]+click combo on opening a link from my desktop into the mobile viewer of my choice... I should be able to go to HN and "View as safari on ios 15. | View as Chrome/brave/ as Device Type [X]" and assign it to ctrl+middle+shift+click... or some such... I should, be able to see the view, on my machine between the three: Desktop, iOS, Android for the same URL view and see the interactions on desktop.... Is there a reason why one cant just cycle through these views on a single tab of a single browser? Click the button and it just cycles through the view

Scarbutt 4y ago

Your example describe two different extremes, in that case is easy to chose, most of us have to work somewhere in the middle and that's were it gets hairy.

debaserab2 4y ago

Even in that model, it's the developer deciding what is an app and what is a site. There's no inherent need for a real estate investment dashboard to act like an app instead of a plain old website. It might serve many of the developers needs, and maybe some of the customers, too - but such a feature could just as easily be served as a plain old webpage as it could a heavy front loaded application.

yes_man 4y ago
> There's no inherent need for a real estate investment dashboard to act like an app instead of a plain old website. How so? This assertion might be conflating your idea of what an investment dashboard should be like and how it should behave with what some team or company has concluded a customer wants. It is inherently a product decision. Actually, claiming server side rendered app suffices for any real estate investment dashboard sounds like the ”developer deciding” angle. Unless you truly are claiming that there never is need for anything except server side rendered payloads in the internet. In which case it’s hard to explain why companies don’t do that. It’s almost as if there are product oriented reasons to have webapps. I think the original comment’s logic stands correct
- debaserab2 4y ago
  The distinction between app and site is one that is done by the business for the business. Customers don't ask for web apps instead of web sites. You can absolutely serve a real estate investment dashboard as a webpage that serves customer needs, depending on what those needs are. Maybe customers truly are served better by an app experience based on their needs, but all the times I've been involved in that discussion the impetus for moving to an SPA has more to do with internal business needs such cleaner division of code, improved click/ad tracking, third party javascript integrations, and often much more hand-wavey ones that never seem to play out as expected like the myth that SPA's are inherently faster than page loads.