Hacker News Reader

Well I certainly want Google Maps to act like an app (which it does): panning, zooming and so on. And I'm happy for Hacker News to act like a traditional website. At that point it's a false dichotomy: different solutions for different problems, yes?

As an analogy: some pop-up books are amazing works of art. But reading would be frustrating if every book was a pop-up book.

On one hand I appreciate how elaborately the parent comment made their point. On another, I appreciate how succinctly you made your point. A conundrum within a conundrum, indeed.

Sometimes the medium is the message; sometimes a cigar is just a cigar.

HN in a nutshell

Things that act like apps also can’t be adequately prevented from compromising the general data privacy of the population. What this means is that it doesn’t matter very much whether your or I have mere preferences for something to have rich app-like functionality or not. Our wanting of it does not play a role unless it can be made verifiably secure and not abusive of user privacy rights. So far, general web applications cannot be made verifiably non-abusive of users’ data privacy, so we must only focus on websites as purely structured documents with no app-like capability.

I sure wish companies wouldn’t abuse data privacy so we could instead care about user preferences for app-like functionality, but we don’t yet live in a world like that.

How is this any different than native apps that offer the same functionality? The article is about facebook, not emacs. A native facebook apps is a much bigger privacy concern. The native app still stores your data in the cloud so you don't control it. It still can be using 3rd party libraries that are doing more than their stated function. It can still be communicating with servers from all over the world. On top of all that it has raw packet access to your WiFi for scanning your entire network on all ports (web apps can't do that). It can scan for SSIDs to find your location (a web app can't do that). It can scan bluetooth to find out your location and/or proximity to others (a web app can't do that). On most OSes it can read most of your files (like say your private ssh keys) web apps can't do that. If you give it access to your photos to select one photo it can read all of them, web apps can't do that. On a web app you can easily add all kinds of mods via extensions to add or remove features because the web apps are based on a known structure (HTML). that's rarely true for native apps. For app in question, Facebook, see FBPurity as an example.

I am not sure that's what he or she was trying to say. Agree with everything you said about native apps. The question for me is if it's necessary for every page to run javascript, even if it doesn't have any app-like features, even if it's just a document. I would love to be able to turn off javascript and be able to browse the document-web without everything being broken. In the specific cases where I need dynamic or app-like behavior, then I can use javascript, or maybe even a separate app browser. https://www.wired.com/2015/11/i-turned-off-javascript-for-a-...

I don't think you articulate this quite right: it's possible to both think that websites and web applications are worthy uses of the web, but also that many web applications would have been best engineered using 'classical' techniques from early websites. There's a strong argument to be made in Facebook's case, since the core value proposition of Facebook hasn't changed much since it's inception, and it began its life as a server-side rendered 'website.'

In any case, this argument is operating at the wrong level of abstraction, the issue here isn't the distinction between these two things conceptually, but if there would be less incidental complexity overall if what are typically called web applications took a different approach to implementing their features, while still maintaining the same user experience.

It's hard to look at all of the crap you need to do to get a functioning web app working to not think there must be a better approach.

> it's possible to both think that websites and web applications are worthy uses of the web, but also that many web applications would have been best engineered using 'classical' techniques from early websites.

I agree with this.

> There's a strong argument to be made in Facebook's case, since the core value proposition of Facebook hasn't changed much since it's inception, and it began its life as a server-side rendered 'website.'

Yes, but I assume that's from the perspective of the value the site brings to you, not in general and not to everyone. If someone solely gets value from facebook.com as a site to send and receive information to/from friends and the world, then yeah, it hasn't changed much.

Facebook today offers a richer experience and that might be part of its value for other people. On facebook.com you can IM a friend, while watching a video in a PIP window and engaging in a real-time conversation on the the comment thread of an event post. You can then switch back and forth between an online marketplace and a streaming service without losing the state of your chat window. The ability to do these things are part of the value proposition for many users that facebook.com now offers today, and delivering that value can be harder with a solely SSR'd website.

> there would be less incidental complexity overall if what are typically called web applications took a different approach to implementing their features, while still maintaining the same user experience.

If you've figured a way that's better do share! I'm sure there's instances in the wild, but I don't think an experienced engineer would ship their own client-side networking in JavaScript if there was a better way to achieve what they want without shipping any more JS.

> It's hard to look at all of the crap you need to do to get a functioning web app working to not think there must be a better approach.

To be clear, you can get a functional "hello world" web app with a single line a code (specifically, thanks to the fact html is very permissive with improperly formatted documents). Everything afterwards depends on the decisions you make, for the experience you want. Is getting rid of that 200ms flicker between page full page loads worth the 500ms it might take takes to load and initialize your client-side routing library? Is making your site available offline worth the effort of setting up all the extra PWA business? Some will think so, some will not.

In any case, this argument is operating at the wrong level of abstraction, the issue here isn't the distinction between these two things conceptually, but if there would be less incidental complexity overall if what are typically called web applications took a different approach to implementing their features, while still maintaining the same user experience.

It's hard to look at all of the crap you need to do to get a functioning web app working to not think there must be a better approach.

> You can then switch back and forth between an online marketplace and a streaming service without losing the state of your chat window.

On the other hand, if you built these things with lighter-weight techniques, these separate parts of the application could be opened in separate browser tabs or windows (without your computer grinding to a halt from loading multiple instances of a gigantic SPA.)

I sometime wish iframes were more useful.

Yeah I mentioned in another thread but the Rails and Phoenix communities both reject the approach of thick clients driven by data access APIs, in both theory and increasingly in practice.

Not really at all, there are some posts about things like stimulus and DHH is obviously against SPA apps. However, go look at any Rails job posting board... Like 60-70% of them are looking for Rails + React (which is a great combo btw)

Even rails 6 ships with webpacker by default and they have included an API mode for a while...

Phoenix live view on the other hand is totally awesome and goes along with your point

> ... as far as the app-like school of thought goes, the new facebook.com is a pretty remarkable achievement.

I agree, they’ve done a fantastic job. Not only that, but as far as corporate engineering blogs go, this article is one of the best I’ve ever read.

Usually I either know the subject too well to learn anything, or I don’t know the subject well enough to understand what they’re saying in the amount of time it takes to read an article.

In this case, they found the perfect depth, they had great judgment on when and how to use visuals, and what they’re conveying is so clearly valuable.

If you usually skip the article and just go straight to comments, consider actually reading this one!

Thank you. This is one of the first things I tell people in my web-dev workshop. They're probably not going to be building websites, they most likely will be building web applications.

There is something between 10ms and 10s, especially when it's after the initial load. The point of contention is not the website vs webapp debate, it's more that a webapp doesn't have to be that bloated.

The whole point of SPA initially was better use experience, notably through faster response time and loading.

If you are not building for the first time experience I do not understand why you would have a problem with initial load of a web app taking seconds. It's like an install just way faster. No one uses facebook only once and so shouldn't care. Android apps are so shit the "slow" webapps are still miles ahead. I do not understand why android google drive app takes 5 seconds to load

> I do not understand why android google drive app takes 5 seconds to load.

The Android UI framework is simply amazingly slow. Instanciating widgets takes forever, and you have to do it in the UI thread.

Under the document-like school of thought, less "engineers" would need to be employed. Also, less computing resources would be required on both the client side. Money, not to mention time, could be saved.

Perhaps application-like school of thought probably allows for more user manipulation. metrics and tracking.

Not sure about the resources part. One key point in having app like interactions Is that you forego the complete page request/render cycle a document oriented implementation requires.

Perhaps we should split the web into two worlds. Create dedicated browsers for just enriched document etc. Add some sort of constraints on what the browser can do, and how much control is removed from the user.

They tried that in the 90s, its called Java. Didn't really work out for that purpose.

In practice things like Twitter and Facebook, interactive programs, should really be just that - programs you run. If the interface is nigh static and the purpose is content interaction rather than primarily consumption you should be opening the Facebook program that gives you this interface and uses its client / server communication to feed messages to and from the interface, not provide the whole thing over the wire spread across document addresses.

And they are that on mobile. Who uses Facebooks mobile website? Everyone uses the app. The contention only exists on "desktop" OSes because Windows and OSX don't provide a UX workflow to push an app at user (at least they didn't when it mattered) the way a mobile site can. And that the app environments on both were way worse than the Android or iOS SDKs for making a dumb GUI for something like Facebook.

> Who uses Facebooks mobile website? Everyone uses the app.

I do, just like I do with every app that might feel too comfy reaching out to my contacts. Not to mention how resource hungry it is.

If you think MFC, VCL, .NET are worse experiences than Android SDK you really never coded for Android.

We have Lynx already.

But seriously, where do you draw the line between enriched documents and apps?

CSS? JS used for styling? d3 for visualizations? WebGL?

Websites have gotten so bloated that the only sane future I see is serving people unix + x in wasm.

The problem here is that the average end user would not know which one to use and when to use it.

And then all those non techy people will say why this website doesn't open... And they need to download another browser to have web apps. I hope you can see how bad this can go

I'm pretty sure it's because the Documents style isn't viable for Facebook as a business, their money comes from all the interactive JS crap they insist on shoving into their product

Tech has this global problem of technology products never being what they say they are on the tin. It's like those front-end/back-end iceberg memes -- what the user wants and what the business wants are just barely in alignment. This needs to end.

I'm currently reading "The Dream Machine", and it makes me instantly go back in time and imagine reading the same comment on discussions around "batch mode" vs "time-sharing" and the development of CTSS [1].

[1]: https://amturing.acm.org/award_winners/corbato_1009471.cfm

No, the problem isn't that the new FB acts like an app, the problem is that it's clunky as hell.

It's like a bad copy of "the new Twitter" and even Twitter isn't really good.

The only end-user software from FB is Messenger Lite. It's quick and does what I expect it to do.

Even the voice chat is good and I didn't expect a lite version of a messenger to have it.

Is the new FB even live yet?

You can toggle between the old and new - click the little triangle at the right end of the header bar and then "Switch to new Facebook"

It's selectively opt-in I think.

I got it-and I did not opt in, it just appeared

You can make a single-page app that isn't bloated.

I mean almost by definition a single app page is a mini browser inside a browser. So you can make it as fast and clever as you want, you still added another layer to render boxes, text and probably the most important: ads.

Maybe they should rename it to Faceapp? It certainly has nothing to do with pages or a book anymore.

And Apple doesn't sell fruit... what's your point?

Web is reinventing flash, poorly. But as an open standard. Because of Apple.