Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rebuilding our tech stack for the new facebook.com

engineering.fb.com

Post reply on HN
Print view View original

441–450 of 489 posts

Re: Rebuilding our tech stack for the new facebook.com

#441

Post by asiachick »

mlthoughts2018 wrote: post #430
sgustard wrote: post #419

Earlier quoted context omitted.

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.

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 applicat…

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.

Re: Rebuilding our tech stack for the new facebook.com

#442

Post by sanxiyn »

core-questions wrote: post #392
badfrog wrote: post #217

Earlier quoted context omitted.

> Facebook rendered just fine a decade ago. What changed between now and then It does way more things. In particular, there are a lot more interactive experiences. A decade ago, it just loaded a web page and nothing changed until you refreshed. Now live videos and other content types have streams of comments and reactions pushed to the client in real time.

None of that stuff has improved anyone's life worth a damn.

What? For example, "X is typing..." message in messenger is great for pacing the conversation. It makes online conversation closer to offline conversation. Not all "dynamic HTML" stuffs are good, but some are indeed a big plus.

Re: Rebuilding our tech stack for the new facebook.com

#443

Post by temac »

ulisesrmzroche wrote: post #421
3PS wrote: post #122

I'm actually really surprised by the number of comments in this thread about how the new redesign is slower. I've had it since yesterday and it genuinely feels much faster and more responsive than the old Facebook UI - though, to be fair, that's not a huge accomplishment give that the old UI would take forever to finish painting or respond to input. I'd consider it a success, especially when compared to the disaster…

It’s karma mining. It’s the same people who think frameworks are dumb and that JS is a terrible language and that codes of conduct are controversial and that you can build FB in a weekend with, at most, ten engineers I really have no clue what they do for a living Anyone who was working in the jQuery days knows exactly why the whole industry moved toward SPAs. It’s disingenuous to say it was just a millennial whim an…

people have diverse experiences -> "I really have no clue what they do for a living"

That escalated quickly.

I'm not even sure they were not trolls like you seem to think, but having that line of thoughts by default (because you are also unlikely to have any evidence of your theories) is just sad.

Re: Rebuilding our tech stack for the new facebook.com

#444

Post by zanny »

fouc wrote: post #422
aylmao wrote: post #265

A big point of contention in the comments here lies around the concept of what a website should be. A school of thought in web development believes the web to be the next frontier in application development. For them it makes sense that websites like this feel and act like apps, both as an end-user (animations, transitions without full-page reloading, rich dynamic content, etc) and as a developer (client-side state m…

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.

Re: Rebuilding our tech stack for the new facebook.com

#445

Post by hfourm »

gfodor wrote: post #403
aylmao wrote: post #381

Earlier quoted context omitted.

> 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 rende…

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

Re: Rebuilding our tech stack for the new facebook.com

#446

Post by dzonga »

impressive attack on would be competitors. now new start-ups will look up this doc and say, ahya let's build our interfaces with react + relay. & the new css | js wizardry. when they don't have the manpower and time to do so. end of day can't launch. when they forget this rewrite is implemented 15 years later when fb is already making money. and likewise, as other commentators have said in the thread - we have failed as an industry due to usability regression

Re: Rebuilding our tech stack for the new facebook.com

#447

Post by MattGaiser »

baddox wrote: post #343
3PS wrote: post #122

I'm actually really surprised by the number of comments in this thread about how the new redesign is slower. I've had it since yesterday and it genuinely feels much faster and more responsive than the old Facebook UI - though, to be fair, that's not a huge accomplishment give that the old UI would take forever to finish painting or respond to input. I'd consider it a success, especially when compared to the disaster…

Considering Facebook engineering has gone into detail about how the new site is much faster and transmits much less JS and CSS, I would be a little surprised if the opposite is true. I tend to not implicitly trust HN comments about things being extremely slow, because for whatever reason there are so many of these complaints I’ve never experienced myself. I still haven’t even had performance problems with Electron ap…

> They work fine for me.

They generally work fine. They just annihilate battery life and processing capacity while doing so.

Re: Rebuilding our tech stack for the new facebook.com

#448

Post by [deleted] »

temac wrote: post #443
ulisesrmzroche wrote: post #421

Earlier quoted context omitted.

It’s karma mining. It’s the same people who think frameworks are dumb and that JS is a terrible language and that codes of conduct are controversial and that you can build FB in a weekend with, at most, ten engineers I really have no clue what they do for a living Anyone who was working in the jQuery days knows exactly why the whole industry moved toward SPAs. It’s disingenuous to say it was just a millennial whim an…

people have diverse experiences -> "I really have no clue what they do for a living" That escalated quickly. I'm not even sure they were not trolls like you seem to think, but having that line of thoughts by default (because you are also unlikely to have any evidence of your theories) is just sad.

[deleted]

Re: Rebuilding our tech stack for the new facebook.com

#449

Post by mrmonkeyman »

aerovistae wrote: post #117
Benjammer wrote: post #95

Earlier quoted context omitted.

Humans have been using physical and mental systems to manage complexity for eons, I simply can't understand this argument. React doesn't automatically fix spaghetti code if you don't know how to organize a platform-sized code base efficiently in the first place.

This is like saying "cabinets don't help organize a kitchen if you don't put anything in them" -- I mean, duh, you have to use it right. That's not an argument to have no cabinets. There's a reason nearly ALL major web applications rely on a _framework_....rails, django, laravel, you name it. These exist because it's really hard to organize vanilla code without a framework. React and FE JS are no different. If you're…

It's not that hard to organize vanilla JS. It's just that once you do, you call the end result Angular, React, etc.

Re: Rebuilding our tech stack for the new facebook.com

#450

Post by mrmonkeyman »

cjhopman wrote: post #239
SN76477 wrote: post #111

Earlier quoted context omitted.

I wish they would just give us APIs and let us build our own experience.

I'm curious what your response to the Cambridge Analytica stuff was? Open APIs to build your own experience are like 100 times worse than that, at least the APIs that CA used were limited (such that they didn't provide enough info to actually recreate FB) and required CA to sign a developer agreement with FB to restrict how they could be used.

How are they worse? The API would just produce my timeline, for example. The raw data. And only with my credentials. How is it different from just browsing? Except the ads, the spying, etc.

Browsing fb.com manually is like using an extremely clunky and slow visual API.

Post reply on HN