Live data from Hacker News

Rebuilding our tech stack for the new facebook.com

engineering.fb.com

461–470 of 489 posts

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

#461
post #414

Earlier quoted context omitted.

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"

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

#462

Quite sincerely, it's a total failure. I got the chance to try the new interface, and it's so slow that it's barely usable. It's even slower than the old website, that was already painfully slow. Loading a random profile takes 8 seconds. Opening a messenger discussion takes 6 seconds. It reminds me of the new Reddit website. Facebook was more enjoyable to use 12 years ago. It's really sad that in 2020, 10k+ engineers…

There's always m.facebook.com if you want a retro experience.

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

#463
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…

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.

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

#464
post #381
post #364

Earlier quoted context omitted.

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

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

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

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

#465

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.

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.

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

#466
post #444
post #422

Earlier quoted context omitted.

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

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

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

#468
post #343

Earlier quoted context omitted.

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…

Really? I assume you don't have slack installed on a Mac then eh? What a horrendous piece of shit.

The problem is to install such a distractive application like Slack as an app on your computer. I leave these kind of solutions all in their website so I can control when I want to see messages. So neither accepting desktop notifications. That's nice thing about async messaging solutions, no expectation you respond within in a second.

If they need to talk straight away they can call :)

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

#469
post #452

Earlier quoted context omitted.

Really? I assume you don't have slack installed on a Mac then eh? What a horrendous piece of shit.

I’ve had Slack running on multiple Macs for years. I have plenty of complaints about Slack, but none involve performance. What’s the actual complaint? Do people just look at their memory usage and see Slack taking a lot, and if so, is that actually a problem?

Slack is incredibly slow by any metric.

Startup takes tens of seconds.

Typing messages with formatting is visibly sluggish.

And in common cases it just crash's and restarts.

Memory usage is also an issue if you compare it to the usefulness of Slack.

Just communicating with my team shouldn't take 1/5th of my laptop's resources.

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

#470
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…

Web is reinventing flash, poorly. But as an open standard. Because of Apple.
Post reply on HN