Hacker News Reader

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.

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.

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

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.

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.

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

The chrome inspector makes it easy to switch between device sizes/user agents.

Rendering with a specific OS/browser combo is not something you can do accurately without actually running that combo. There are services like Browserstack that will do this for you, but I don’t think it’s something that could realistically be built into a browser.

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.

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.

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

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.

> 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

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.