[HN Gopher] Rebuilding our tech stack for the new facebook.com
___________________________________________________________________
Rebuilding our tech stack for the new facebook.com
Author : alexvoica
Score : 433 points
Date : 2020-05-08 16:04 UTC (6 hours ago)
(HTM) web link (engineering.fb.com)
(TXT) w3m dump (engineering.fb.com)
| bryanmgreen wrote:
| I wonder what the Mobile App versus Mobile Browser versus Desktop
| Browser usage percentages look like.
|
| Generally speaking, how important is it to actually update the
| desktop version other than for the sake of updating tech? I only
| use desktop as part of my marketing work, if I do it use it at
| all.
|
| (Side Note: I can't believe it took this long for Dark Mode to be
| a normal option for all software)
| Groxx wrote:
| > _We addressed this by generating atomic CSS at build time.
| Atomic CSS has a logarithmic growth curve because it's
| proportional to the number of unique style declarations rather
| than to the number of styles and features we write._
|
| I've always wondered... has anyone checked to see if this
| strategy of CSS (which AFAICT is slowly growing in popularity,
| since it's a super simple minification trick) ends up costing
| more in bandwidth?
|
| It seems like it would, because 1) you frequently need multiple
| classes per html element, and 2) those html classes need to be
| sent _on every page load_ , where CSS caches well if used
| "normally". I can see it being smaller on _any individual page_ ,
| especially with class-name minifying, but across many? And
| infinite scrolling loading many more elements?
| axyz wrote:
| we use this approach since more than a year with very good
| results. Regarding the data transfer it is not much of a
| problem because those classes usually get repeated a lot across
| the elements and having lot of repeated string is the best case
| scenario for gzip compression leading to basically no size
| impact.
|
| https://github.com/utilitycss/atomic This is the framework we
| developed to create atomic CSS component libraries if you want
| to have a look (documentation needs some love, but is quite
| stable)
| Groxx wrote:
| Your HTML is still undeniably larger than something with
| dramatically fewer class attributes though, if you minify the
| same way. Hence my "single page" vs "many" difference.
|
| gzip helps for sure, but I doubt `<class="card">...` ends up
| larger than `<class="a b c d e"><class="sub-a sub-b q
| etc"><class="repeat per element">...`.
| axyz wrote:
| there is of course a bit of difference in some use cases,
| my point is that in a real world scenario you often do not
| have
|
| <class="card"> vs <class="a b c d e">
|
| but more something like <class="card"><class="stuff-inside-
| card"><class="other-stuff">
|
| vs <class="a b c d e"><class="b c f"><class="c d e g">
|
| so in the long run you tend to have more repeated strings
| across even completely unrelated elements and that usually
| balances out the possible increase in non gzipped bytes.
| But to be honest we did not had a detailed comparison with
| edge cases and it would be interesting to see when it
| actually may be a bad idea and when it is totally fine
| Groxx wrote:
| when you're less "component-y" with your styles, yeah,
| that happens pretty frequently. careful styling is mostly
| rare (like all careful things)... but atomic styling
| seems to make the savings of careful styling effectively
| _impossible_ , though I absolutely believe it helps the
| less-careful (especially the least-careful) cases.
| scalableUnicon wrote:
| I rarely use Facebook, but when I do I use https://m.facebook.com
| instead of the main site. Similarly i.reddit.com and the HTML
| version of Gmail. Which aren't great looking, but pretty usable.
| I hope these versions will be maintained for a long time.
| Drip33 wrote:
| >Similarly i.reddit.com
|
| Try https://old.reddit.com
|
| It's so bad that people made Browser Extensions for Firefox[0]
| and Chrome[1]
|
| [0] https://addons.mozilla.org/en-US/firefox/addon/old-reddit-
| re...
|
| [1] https://chrome.google.com/webstore/detail/old-reddit-
| redirec...
| benbristow wrote:
| Old Reddit is so damn ugly though apart from the Subreddits
| which have nice custom themes (although does make for a 00's
| Myspace-like inconsistent interface)
|
| The new Reddit definitely seems a lot faster nowadays than it
| did when it first launched.
| SketchySeaBeast wrote:
| > The new Reddit definitely seems a lot faster nowadays
| than it did when it first launched.
|
| For me it's not the speed, it's the number of times the
| page straight up just doesn't refresh, or comes back with
| no data. Very frustrating.
| ccmcarey wrote:
| I don't think old reddit is ugly, though it takes some
| getting used to. Combined with RES for some minor
| enhancements (navigation etc) and it's great.
|
| It's similar to HN. Not fantastic design, but incredible
| information density and usability.
| thelean12 wrote:
| Incredible? HN has horrific usability.
|
| Good luck knowing when people respond to your comments.
| Searching takes you to a completely different website.
| You can't delete comments (which should be a basic
| privacy ask from this crowd). Click targets are
| incredibly small.
|
| It took years of begging for them to even implement
| collapsing comments. And for some reason they put it on
| the right side (not lined up with the tree level), and
| made it a super small click target.
| Supermancho wrote:
| Not to go off on a rant about reddit here, but I still
| use the old reddit (old.reddit.com). The new reddit
| layout is horrid,. Using additional whitespace to improve
| readability, has done the opposite. Counter-productive
| iconography sizing and font styling, it goes on and on.
| Some of this is to make it more mobile-friendly. I get
| it, but as a singular design, it's worse for desktop
| users.
| aerovistae wrote:
| Gmail is a disgrace. I've been using it for so long and I miss
| the version from 2005. It's so slow today I just hate using it.
| It's really sad because it was a great product and that's why
| it took over email.
| pathartl wrote:
| Great write up. Glad to see they're making some changes as the
| current interface still feels like 2005 with the main feed at
| 500px wide. And as always, dark mode is welcome.
|
| I really hope this helps performance on the site. In the past
| year or so I've been noticing that when the page sits in an
| unfocused tab for a while, clicking back usually takes 20+
| seconds to actually load and I'm stuck at a white screen. It
| actually locks up the tab pretty well too, so navigating to other
| addresses and such takes a pretty long time.
| dehrmann wrote:
| > And as always, dark mode is welcome.
|
| I don't get this infatuation with dark mode, beyond it looking
| cool. People claim it helps with eye strain, but a brighter
| background constricts your pupils, improving focus.
| cerved wrote:
| OLED
| olcor wrote:
| Just wanted to point out you might've pasted the wrong
| snippet, which is about eBay's policies.
| dehrmann wrote:
| Oops! Thanks for the catch.
| pathartl wrote:
| In my experience light mode will work fine on things like
| e-paper displays, but when you have an emissive or
| transmissive display the bright light can be straining.
|
| I also feel like dark mode highlights text more, making it
| easier to identify the text. If I use light mode in text
| editors I get completely lost very quickly.
| tgvaughan wrote:
| It never occurred to me that this could be the reason for
| dark mode blurriness, but it makes sense intuitively. (Think
| you mean "constricts" rather than "dilates" though.)
| dehrmann wrote:
| Yup, you're right; they constrict. I found this
| Stackexchange post that goes into far better detail than I
| did: https://graphicdesign.stackexchange.com/a/15152
|
| The only thing I have to add is you can think of
| constricted pupils like a pin-hole camera or a higher
| f-number on a camera aperture. You need brighter light, but
| the depth of field is wider.
| attilakun wrote:
| I think people might have different sensitivities to this
| issue. Before I changed everything to dark mode, I had
| trouble concentrating on a bright screen especially in a
| dimly lit room. Dark mode feels like a total game changer for
| my productivity.
| Amezarak wrote:
| I've been using the new Facebook and the interface is even
| slower than before. It also feels (may not actually be) less
| information-dense, forcing me to interact with the page more to
| see the same information, compounding the problem.
|
| This is on a i7 laptop.
| the_pwner224 wrote:
| > forcing me to interact with the page more to see the same
| information
|
| Product Lead to Zuck: user engagement up 5% after this
| update!
|
| Zuck: great, here's your bonus check
| linuxftw wrote:
| This is the only reasonable explanation. The user density
| is terrible as GP said.
| pathartl wrote:
| Interesting to hear. I haven't gotten the new interface yet,
| so time will tell.
|
| I think we need to shift back to 4:3 displays. Widescreen is
| great for consuming content, but we lose so much vertical
| space.
| neogodless wrote:
| About every 3 minutes I went a little mad with the new
| interface. With the old one, photos open, and you can click
| _almost anywhere_ to close them.
|
| With the new (desktop) interface, you have to find the X to
| close the photo. No, no, not the X you find on the top right of
| every other interface ever. This time it's on the top left!
| pathartl wrote:
| You mean they didn't just use Fancybox like everyone else? /s
|
| But yeah, that's annoying. We've had lightboxes for like 15
| years now and people still can't get it right.
| TheSpiceIsLife wrote:
| > top right of every other interface ever.
|
| That doesn't sound right.
|
| Mac OS and at least _some_ Linux desktop environments have
| buttons at top left.
|
| Still, I agree with your general point: why change away from
| a tradition for little to negative benefit?
| yepthatsreality wrote:
| Facebook folded to the "quit changing the UI" crowd years ago
| when they opened registration up beyond colleges.
| gfodor wrote:
| This is 100% incidental complexity. It's painful to consider that
| this level of sophisticated engineering is needed to render a
| website quickly in 2020. What went wrong?
|
| I'm personally excited about things like turbolinks and phoenix
| liveview, which may provide a path out of this mess.
| janitor61 wrote:
| The frontier of web design is apparently digital Rube Goldberg
| machines, existing probably more for job security rather than
| consideration for the end-user.
| gfodor wrote:
| On the contrary, it does seem like jumping through these
| kinds of hoops has become strictly necessary if you are
| building web apps you would like to be responsive.
| cosmotic wrote:
| Are you sure? Media queries handle layout changes font size
| has been proportional to user agent since the beginning the
| web. A little SCSS preprocessing makes writing complicated
| CSS a lot easier.
| gfodor wrote:
| I didn't mean responsive in the CSS sense, I meant
| responsive as in the "not slow to load" sense, which is
| the point of this article.
| lookdangerous wrote:
| The all-but defacto use of javascript transpilers especially
| invokes the image of 'Rube Goldberg' machines.
| the_other wrote:
| When you don't use transpilers, you _have_ to write ES5
| code. No-one wants that.
| saagarjha wrote:
| Is ES5 really that bad that nobody can stand it?
| goatlover wrote:
| Even in 2020? Isn't ES6 standard now across all supported
| browsers?
| robertoandred wrote:
| No. And "ES6" is itself a vague term. Browser support for
| features and syntax varies considerably and changes
| constantly.
| uryga wrote:
| that might well be, but just recently i got a crash
| report and it turned out the user had some "unsupported"
| version of Safari... and i'd rather transpile/polyfill
| than be _that site_ that asks you to upgrade your browser
| to use it
|
| (funnily enough, it actually parsed ES6 stuff fine, but
| was missing the `Object.fromEntries` method)
| nck4222 wrote:
| >This is 100% incidental complexity.
|
| The article talked a lot about their new dark mode feature, how
| they wouldn't have been able to implement it in their old tech
| stack, and how they were able to reduce their CSS size while
| adding a dark mode.
|
| But is dark mode all that important? Even as a developer I
| don't care at all about FB having a dark mode, did they really
| need to rewrite their entire site to implement features no one
| cares about? Also, for a photo and video sharing site, is CSS
| size really important? I just loaded the page and it loaded
| 13.2mb worth of data while making 249 requests. Thanks for
| cutting down your 400kb CSS file though I guess.
| orpheansodality wrote:
| "I don't care about this feature" !== "nobody cares about
| this feature." I feel like this is a fallacy a lot of
| programmers (myself included) tend to fall into, but it's a
| dangerous trap.
| robertoandred wrote:
| Just because you don't care about a feature doesn't mean no
| one does.
| splintercell wrote:
| Dark mode is very important. Do you use Flux by the way?
| gowld wrote:
| Supporting dark mode == 2 bad UI instead of 1 good one.
|
| f.lux works well with normal UI, replicating natural light.
| dimitrisnl wrote:
| ...but it's not a website. It doesn't list 10 cars, 1 family
| photo and the address on the footer.
| gfodor wrote:
| take a screenshot of facebook - it's a website.
| Groxx wrote:
| I can run Linux in my browser. Is Linux a website?
| https://bellard.org/jslinux/
|
| You have to draw the line somewhere, or it becomes
| meaningless.
| gfodor wrote:
| sure, for me the line is clearly on the side of
| "scrolling through boxes of text and basic commenting" =
| website, since that was the case in 1995. my point was
| that if you took a screenshot of facebook today and when
| it launched, other than some cosmetic improvements, you
| couldn't tell me which version warranted extreme dynamic
| application logic and which was just a dumb server
| generated HTML page. the point being that it shouldn't be
| necessary to do all the stuff in this post to get this
| result, but it is, because our field has failed to build
| better generalized solutions to these problems.
| toohotatopic wrote:
| >What went wrong?
|
| From yesterday:
|
| https://news.ycombinator.com/item?id=23101483 Hello, World -
| Zerodha, India's largest stock broker
|
| Facebook most likely has a different attitude towards software
| development.
| core-questions wrote:
| Facebook rendered just fine a decade ago. What changed between
| now and then, in terms of actual improvement to end user
| experience, to make it so slow this kind of crap is needed?
|
| My guess is:
|
| - Desire to offload more processing to end user machines to
| save compute
|
| - More and more ads and user analytics in order to pick which
| ads to show
|
| - More engineers that irrationally hate the simplicity of PHP
|
| Duct tape on top of abstractions on top of duct tape in order
| to make a document platform behave like an application
| platform. Isn't it time to just replace web browsers with
| something that doesn't suck?
| laggyluke wrote:
| > Duct tape on top of abstractions on top of duct tape in
| order to make a document platform behave like an application
| platform. Isn't it time to just replace web browsers with
| something that doesn't suck?
|
| Be careful what you wish for. You just described native
| mobile apps.
| core-questions wrote:
| I do prefer native apps on mobile in many cases. At least
| the UI is idiomatic.
| badfrog wrote:
| > 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.
| dullgiulio wrote:
| I really don't want a video to autoplay on the side of the
| screen when I'm reading some news article, for example.
|
| It was so much better before when there just were less ways
| of doing what the website wanted and more ways of doing
| what you wanted with your browser and your computing power.
| badfrog wrote:
| Sure, it's totally reasonable for somebody to dislike
| these features. I just object to the claims that it
| doesn't do anything substantially different than what it
| did 10 years ago.
| core-questions wrote:
| None of that stuff has improved anyone's life worth a damn.
| AlexandrB wrote:
| > Now live videos and other content types have streams of
| comments and reactions pushed to the client in real time.
|
| Many of these are anti-features I'd love to be able to turn
| off.
| aeyes wrote:
| A lot more features?
|
| Facebook of 12 years ago didn't have groups, marketplace,
| dating, live videos, stories, ...
| core-questions wrote:
| 99% of that could have been implemented fine using the same
| technology. Live videos etc. are a scourge on the culture
| and I wouldn't miss them.
| lookdangerous wrote:
| 'Desire to offload more processing to end user machines to
| save compute' strikes me as a real possibility
| badfrog wrote:
| I think this is very unlikely. Making the page load one
| second faster pays Facebook more in terms of user retention
| and engagement than it costs them in server usage.
| core-questions wrote:
| Do Facebook users really quit Facebook because the page
| is too slow? Maybe a minute, but one second?
| AgentME wrote:
| I don't think it's any of those. It's about interactivity in
| the webpage. Imagine you have the template for the HTML of
| comments implemented in PHP. Now if the user posts a comment
| and you want to show the comment on their screen before it
| gets to the server and back, then you need the template
| itself on the client. The template being on the server in PHP
| isn't any help. You could imagine the server filling the
| template in with dummy values, and then giving that to the
| client to fill in, but that only works for the simplest of
| templates where a few values need to be substituted in. You
| have to create another template language both the server and
| client understand if you have more complicated logic like
| many conditional or repeated parts. When you have one part of
| the UI the client needs to render on its own, it's easy to
| make a one-off solution for it, but in Facebook's case, I
| imagine they have a ton of UI that they want to be server-
| rendered but also renderable on the client. React is a
| template system that can run on both the server and client,
| and can live-update already rendered elements on the client
| as the user interacts with the page.
| core-questions wrote:
| I don't have to imagine any of that, I used it. In fact,
| it's basically how HN works now, and we seem to be
| commenting fine.
| gfodor wrote:
| I agree with this assessment of the 'why' - and it's why I
| mentioned things like turbolinks and liveview. What you
| mention here seems like a convoluted solution to the
| problem, but I realize it's how it's done, and I've written
| thousands of lines of code doing it.
|
| In fact, the original AJAX stuff in the early 00's
| typically did a primitive version of this since it was the
| most obvious solution during the era of server side
| rendering: just have the server render the new comment and
| slap it in as-is. Instead of extending the reach of that
| concept instead we shifted towards generic data access APIs
| and pushing all the complexity to the client, which has
| resulted in the gigantic mess we see.
|
| I remember writing a basic client-side templating system in
| literally 2002 that naively regenerated the whole page in
| Javascript in response to AJAX API updates - you wouldn't
| notice unless you looked at the CPU being pegged and
| realize your computer was useless for multitasking if that
| site was open. It was clearly a bad idea. Little did I
| realize at the time that the next ~20 years of web software
| development would take that approach and just try to
| optimize it.
| core-questions wrote:
| > Instead of extending the reach of that concept instead
| we shifted towards generic data access APIs and pushing
| all the complexity to the client, which has resulted in
| the gigantic mess we see.
|
| So like, fat clients done badly? I had a Usenet client in
| 1993 that provided just as good of a forum experience as
| we have now, in 16 bits and 4 megs of ram.
| AgentME wrote:
| Asking the server for new HTML means you can't show
| changes until you've done a roundtrip with the server.
| That means no optimistic rendering or immediate feedback
| for local changes, such as a comment being made or an
| option being set in a modal that opens up related
| settings, etc. I think it's extremely useful to have a
| system that allows the client to respond to changes
| locally on its own as the default case rather than
| treating local interactions like a strange one-off
| exception.
|
| React only re-renders the components that have their own
| props or state change. There seems to be a popular
| misunderstanding that React that makes you re-render the
| whole page in response to changes, but that's not how it
| works.
| ahupp wrote:
| I worked on FB site performance a decade ago and I assure you
| it was abysmally slow.
| core-questions wrote:
| I used it a decade ago and it was fine for an end-user, so
| why should I care? Raw advancements in CPU power would have
| been enough to keep the old backend going just fine.
| reaperducer wrote:
| _Duct tape on top of abstractions on top of duct tape in
| order to make a document platform behave like an application
| platform. Isn 't it time to just replace web browsers with
| something that doesn't suck?_
|
| It's not the browsers that suck, it's what companies like
| Facebook do with browsers that sucks. And then all the other
| non-thinking middle managers in other companies who want to
| copy these terrible things because they're incapable of
| leadership.
| core-questions wrote:
| > It's not the browsers that suck,
|
| They're great at rendering documents, yep. Applications
| delivery platform? Not so much, not until you tack a shitty
| language on top of it and then a bunch of crap on top of
| that language to make it remotely useful....
| gorgoiler wrote:
| You have a ten digit user base that you need to engage, so you
| have a four (five?) digit engineering team that somehow needs
| to coordinate their patches in a way that doesn't cause the
| complexity of the site to explode.
|
| It's huge and pretty impressive.
| gfodor wrote:
| I never said it wasn't impressive. I was saying that it's sad
| that this level of incidental complexity is necessary to run,
| what is for all intents and purposes, a website.
| webdood90 wrote:
| I think you're unfairly trivializing it by labeling it a
| "website".
| gfodor wrote:
| I think you're missing the point by assuming I'm making a
| statement about Facebook. I'm talking about the fact that
| this incidental complexity is necessary to do what
| Facebook does. I don't think my description of it as a
| website is relevant, it conveys the point that ultimately
| it's a tragedy that to render obviously simple content to
| users you are stuck building all this crap to make it
| work.
|
| Too many people in this thread seem to be projecting that
| I'm somehow saying this complexity speaks poorly of
| Facebook's product or engineering. On the contrary, my
| point was that it's tragic that brilliant minds at
| Facebook are forced to build all the stuff described in
| the post just to achieve simple goals like "the page
| loads quickly", instead of focusing on other problems.
| motoboi wrote:
| I have been using Facebook for like +10years. Facebook used to be
| reference for speed and usability.
|
| I left it ~4 years ago.
|
| Last day I entered again for curiosity. It's so sad. Strange
| interface, slow, unresponsive. It's sad.
| wallawe wrote:
| Did you try the new UI? It's a lot better but you may have to
| opt in
| reaperducer wrote:
| _Facebook used to be reference for speed and usability_
|
| On web, for a while. Remember when Facebook's iPhone app came
| out, it was a disaster. It was so slow, I could open the app,
| then take the elevator down to the basement of my building,
| drop off some outgoing mail, and return to my apartment before
| it finished updating the news feed. It was legendary in its
| time for its slowness.
|
| At first, nobody complained because there weren't a lot of
| "apps" available. But then all the other apps came out, and
| everyone complained for years that all the other app-building
| companies could build responsive apps, but Facebook couldn't.
|
| Then one day Facebook updated its app and it was a little
| better. Then another update came and it was good enough, and
| everyone stopped complaining and forgot.
|
| _Last day I entered again for curiosity. It 's so sad. Strange
| interface, slow, unresponsive. It's sad._
|
| I only use Facebook once a week, to update the page for a web
| site I manage. It is terribly slow on web. On both of the
| computers I use it on, loading the first page takes upwards of
| 15 seconds. Clicking on the text field to enter a new post
| takes eight to ten seconds for the editor to load.
|
| I don't know how people who are addicted to Facebook manage to
| use it so much without going mad.
| delusional wrote:
| Remember when they had to monkey patch the android runtime
| because their app had too many methods?
| https://www.facebook.com/notes/facebook-engineering/under-
| th...
|
| It's a fun hack, and I enjoy spectacle, but it might be a
| sign that you are complicating your app more than you need.
| saagarjha wrote:
| Remember when reached the limit for __TEXT and had to put
| code in sections that weren't really meant for it:
| https://blog.timac.org/2016/1018-analysis-of-the-facebook-
| ap...?
|
| Remember when they were taking to long to start up that
| they pulled stuff into a separate framework just so they
| could meet launch deadlines:
| https://blog.timac.org/2017/0410-analysis-of-the-facebook-
| ap...?
|
| Remember when the app had 18,000 Objective-C classes:
| https://quellish.tumblr.com/post/126712999812/how-on-
| earth-t...?
|
| Facebook's teams somehow cannot manage their bloat and they
| keep hiring people to hack the platform they're running on
| rather than fixing the actual underlying problem.
| plorkyeran wrote:
| The root cause of the problem is that they have too many
| people working on it, and that's obviously not a problem
| you can hire your way out of.
| saagarjha wrote:
| Perhaps they should hire engineers who have the explicit
| job of ripping out things that should not belong.
| motoboi wrote:
| Your comment made me remember being amazed by BigPipe and how
| damn fast that made the app (still called page back those
| days).
| fossuser wrote:
| Steven Levy talks about this in his new book (which is really
| good).
|
| Zuckerberg's focus on mobile first was a major focus to save
| the company and ultimately a success story (this happened
| right after the IPO).
|
| Their big mistake was non-native applications.
| keymon-o wrote:
| > I don't know how people who are addicted to Facebook manage
| to use it so much without going mad
|
| That's the thing with the addiction. Once you get used to it,
| it doesn't matter how bad it is.
| jtbayly wrote:
| On their phones, perhaps? At least we already know that
| testing it on a computer browser is _not_ testing it for the
| majority user.
| fossuser wrote:
| I miss information density.
|
| HN is great for this and you can change enough settings on reddit
| to get it where it used to be, but FB is really bad for it and
| Twitter is just ok (though with the tweet deck app you can get a
| lot on macOS).
|
| In that FB screenshot you can see half of one post?
| janpot wrote:
| I don't really care about their end result because I don't use
| facebook. But in spite of all the negative comments here, I'm
| actually interested in how their styling solution works.
| kall wrote:
| If I had to guess, I would expect it to be similar to react-
| native-web. They say the api is inspired by RN
| (StyleSheet.create) and the atomic classes look similar to what
| react-native-web produces. Also the author of RNW works at
| facebook.
|
| It's called xstyle and you can see some examples in a talk from
| last year that presented the new tech for new faceook. I will
| update if I find the link (can't right now).
|
| Edit: starts at about 28:00 here, but the rest about
| react+relay data fetching is interesting as well if you care
| about that stuff
| https://developers.facebook.com/videos/2019/building-the-new...
| brailsafe wrote:
| A browser extension that automatically filters out Karen from
| your feed would yield better results, but they wouldn't want to
| alienate their core users
| Chyzwar wrote:
| I like the approach to css with stylex. I hope that now linaria
| and astroturf will get more support.
| chx wrote:
| The most irritating "feature" of Facebook is they insert
| themselves like eight deep in the history when opening their page
| so the back button doesn't work.
| AlexandrB wrote:
| This kind of thing is normally the domain of sites you find
| after searching "office 365 warez". Pretty bad.
| liquid153 wrote:
| Do they still use PHP on backend. If so ick
| innocenat wrote:
| They use Hack if you really needed to know.
| benbristow wrote:
| AFAIK they use 'Hack', a language designed to be very similar
| to PHP.
|
| https://hacklang.org/
|
| PHP is a lot better than it used to be now though! It's got a
| bad rep but newer versions are fast and surprisingly modern-
| feeling.
| kichu37 wrote:
| Faceb OMEGALUL OMEGALUL k.
| thesz wrote:
| It uses scrolling as cookie consent, apparently.
|
| Which is wrong as discussed here:
| https://news.ycombinator.com/item?id=23090393
| polymorph1sm wrote:
| I opt in when Facebook prompted me to test out the new UI in
| Chrome browser, immediately I regretted and frustrated to find
| the button to revert back to the old one.
|
| But then I found out my "old" Safari browser wasn't supported in
| their new fancy UI. Now I only check my Facebook once per day in
| Safari and never sign in again from Chrome.
| trevor-e wrote:
| What I find weird about the article is that they spend so much
| time talking about the performance of the new design, yet fail to
| include any hard numbers comparing the old vs new
| implementations. They do throw out a few numbers like how the new
| page only downloads 20% of the previous 400kb CSS for the
| homepage, etc, but I'm surprised to see no actual browser
| benchmarks for what they claim. How else would they be measuring
| this internally?
| polote wrote:
| Future will tell, but I do think this is a good strategic move by
| FB.
|
| FB is now seen as an app for old people and not fun at all, and
| probably one of the reason is because of how it looks. With the
| new design, things are more shiny, and the product now looks
| cool. How a product is perceived has a big influence on how
| people use it, (for example why people use snap when they can
| send the same videos on insta).
|
| I wouldn't be surprised that this is a beginning of a lot of
| changes on FB
| Panini_Jones wrote:
| What other changes would you forecast?
| [deleted]
| jariel wrote:
| Everything is in the past tense without dates. When was this
| massive re-write? 2010? 2018?
| amelius wrote:
| Looking at the graphical design changes, they haven't rolled
| this out yet.
| rvnx wrote:
| They did roll this new interface on some users (like me), and
| this new experience genuinely sucks.
|
| It's easy to guess what happens under the hood:
|
| "Legacy" programmers implemented working solution.
|
| A newcomer comes into the company, doesn't really give a shit
| about the company because he is #XXXX, follows textbook
| processes, has a very nice pay-check so no pressure, and
| decides to rewrite because "code sucks".
|
| A second newcomer joins, still no pressure, because he knows
| he will get his pay-check. Tells his manager that he cannot
| work without refactoring (it's not true).
|
| 10 programmers later, you refactor code instead of producing
| features. You can do that for all your lifetime.
|
| To their defense, the FB initial codebase from the time of
| Mark Slee or Philip Fung was not a gift but because they had
| pressure to make revenues they were trying to do what was
| right.
|
| When you have 10 years of positive iterations regarding
| product experience and user feedback, revamping everything in
| a big bang boom is a terrible idea from both engineering and
| product perspective.
|
| Sometimes, full revamp are positive because the initial
| product sucked, but when you managed to onboard a billion
| user, it's dangerous to change their habits if you aren't
| 100% sure it's an improvement.
|
| Here, we have PO/PM pushing for change, for whatever reason
| (engineering pressure, or they get a bonus if they deliver
| the product, etc). Same story with all the Google Messengers.
| underwater wrote:
| This is not a big bang rewrite. All the technology here is
| stuff that's been built over the last decade. Haste is a
| decade old, React is 8 years old, GraphQL is around 7
| years, Relay must by 5 years old by this stage. This is
| simply bringing them all together.
| swyx wrote:
| theyve been talking about this since 2019
| https://www.youtube.com/watch?v=WxPtYJRjLL0 i reckon it
| happened over the course of 2018-19
| pmlnr wrote:
| > We knew we wanted Facebook.com to start up fast, respond fast,
|
| You failed.
|
| mbasic.facebook.com on the other hand, is actually fast. Oh.
| Wait. That's no js at all.
| pier25 wrote:
| > _as little as possible_
|
| I just opened FB with the cache disabled and it downloaded 5.85MB
| (19.76MB uncompressed).
|
| Most of it happens after the page has rendered, which is great,
| but that's a lot of stuff. There are 13.74MB of uncompressed
| JavaScript.
| panta wrote:
| Stealing data about the users as accurately as possible
| requires more code than one would think.
| dylkil wrote:
| >Stealing data about the users
|
| its not stealing when the users agreed to it
| infogulch wrote:
| Using a website does not imply informed consent.
| xd1936 wrote:
| No, but signing up for an account and agreeing to the
| Terms of Service does. The not-logged-into homepage is
| 1.3mb. Still not tiny, but definitely not the same as the
| web app.
| AlexandrB wrote:
| No it doesn't. Informed consent is not the same as
| shoving a ToS/EULA in front of someone who may not have
| the legal or technological education to understand it or
| its consequences.
|
| From the Wikipedia definition[1] of informed consent (in
| medicine):
|
| > An informed consent can be said to have been given
| based upon a clear appreciation and understanding of the
| facts, implications, and consequences of an action.
| Adequate informed consent is rooted in respecting a
| person's dignity. To give informed consent, the
| individual concerned must have adequate reasoning
| faculties and be in possession of all relevant facts.
|
| What tech companies do is obtain the minimum _legally
| required_ consent - and sometimes not even that. This may
| be legal, but it's far from ethical.
|
| [1] https://en.m.wikipedia.org/wiki/Informed_consent
| ianmobbs wrote:
| Fortunately, Facebooks ToS[0] is not full of legalese or
| jargon, and I'm sure anybody with enough technological
| education to sign up for Facebook can understand it too.
|
| [0] https://www.facebook.com/terms.php
| bzb3 wrote:
| With a standard 4G/FTTH connection that's less than one second
| of download time.
| sopromo wrote:
| If I have to download 5mb of js for every page I visit on my
| phone I would be out of data in less than 15 days.
| edhelas wrote:
| Everyone have 4G and Fiber, and a Core i7 and 16Gb of RAM :)
| Seriously...
| bzb3 wrote:
| That's not what I've said, and I somewhat agree with the
| original point, but this trend of wanting to cater to the
| lowest denominator rubs me the wrong way.
|
| Some guys think the web should be usable with a 50EUR
| smartphone on GPRS, and I say no, because there's a middle
| ground.
| nromiun wrote:
| How about just caring for the real world instead of the
| numbers provided by the internet provider? Those download
| numbers are for the best case scenario. And unlike
| broadband 4G is not reliable at all.
| pier25 wrote:
| > because there's a middle ground
|
| So where's your middle ground?
| saagarjha wrote:
| Have you read anything about Facebook's emerging markets?
| They want to cater to those people themselves!
| pathseeker wrote:
| >Some guys think the web should be usable with a 50EUR
| smartphone
|
| You went to the other extreme though. Most people in
| high-income countries don't even have FTTH.
| ukyrgf wrote:
| The web should be usable on a 28.8k modem from the mid
| 90s. Why wouldn't it be?
| buboard wrote:
| There is absolutely no excuse. The app is not doing
| protein folding, its merely showing text!
|
| Surprise, many many ppl use facebook in crap laptops, fb
| is popular with everyone.
| bzb3 wrote:
| No, it's not merely showing text. Facebook does a
| thousand things more than show text. You could argue
| those features don't belong in Facebook, but you can't
| argue that features are supposed not to take up any
| space, because that's unrealistic.
| [deleted]
| [deleted]
| throwaway43423 wrote:
| For reference, vscode ships as 13.3MB of uncompressed JS. (Not
| including builtin extensions, but that wouldn't add much)
| schkkd wrote:
| That's pretty much size of a mobile app. But the thing with web
| apps is that they are downloaded every time and hence the
| outcry.
| mgraczyk wrote:
| Not so, refresh the page to see how large the second download
| is (much smaller)
| speedgoose wrote:
| They aren't though. You have a cache.
| the_other wrote:
| Facebook release multiple times a day (or they did), so the
| browser cache is irreLevant.
| victorvation wrote:
| As mentioned in the blogpost, they use code splitting and
| bundle hashing to actually maximize usage of browser
| cache.
| randall wrote:
| There's a bunch of ways FB mitigates this.
| foota wrote:
| I would bet that js bundling and splitting might prevent
| that from being true?
| the_other wrote:
| Thanks siblings, for letting me know about FB's use of
| code splitting and how it helps caching.
| speedgoose wrote:
| Perhaps but thankfully not all webapps are like Facebook.
| pier25 wrote:
| If you have code splitting many chunks will remain the
| same.
| amelius wrote:
| Did they fix the "back" button? (I.e. if you click a link in the
| middle of a feed, then "back", do you get back at the same
| position in the feed?)
| aeyes wrote:
| I think the Facebook feed is completely random on purpose to
| make it feel more up to date.If the app crashes on your phone
| then good luck on finding a post in your feed again.
| beefield wrote:
| My guess is that they have a/b tested that if you remove the
| item from the feed user clicked, users become "more engaged"
| i.e. frustratingly scrolling to find the place where they were.
| [deleted]
| lgl wrote:
| Can we now sanely read comment threads with several hundreds or
| thousands of comments without clicking 200 times on "show
| previous comments" only to then lose all "progress" if we click
| somewhere else? Also looking at you Instagram.
| marcodave wrote:
| One minute of contemplation for those who scroll for 10 minutes
| on mobile, to finally find something interesting to read/click,
| just to click by mistake the back button, and the whole
| timeline completely changed. Youtube recommendation feed also
| terribly guilty of that.
| suyash wrote:
| There is nothing about backend here, that's where the heavy
| lifting is done. Is that all in PHP still and GraphQL ?
| raphaelj wrote:
| 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 can't make a photo,
| video, post and message sharing website that is not a pain to
| use. We collectively failed as a profession. If one needs 2MB of
| CSS for such a website, there is clearly a problem.
| ulfw wrote:
| Agreed. Using this on the i9 8-core 16" MBP and the thing just
| isn't fluid. Has anyone at Facebook even bothered testing this
| on computers people actually use? Like some 2015 Macbook Pro?
| Or a 2014 Macbook Air or whatever.
|
| I wouldn't even want to know how it runs on those.
| lordnacho wrote:
| I've got a 2015 MBP. FB is pretty sluggish, and I wonder why.
| When you send someone a list of notifications, it's probably
| worth getting the data ready in case they click it. And the
| resource usage is pretty big as well.
|
| The mobile app seems to be just fine though, perhaps they
| want to push people to use that.
| ngngngng wrote:
| It really is appalling. I'm on a top of the line laptop with
| Gigabit internet and I can't do anything on Facebook without
| waiting several seconds for loading. Usually I only open it to
| check notifications. I just refreshed and counted and it took 9
| seconds for the page to load and to show my notifications.
| notyourwork wrote:
| Agree whole heartedly, Facebook is a disgrace of a website and
| has been for years. Crazy how slow it is to load.
| lancesells wrote:
| I think you could add Twitter and New Reddit to the list as
| well.
| notyourwork wrote:
| Yes! I use old.reddit.com and am not a twitter user so I
| don't have much exposure there.
| TechBro8615 wrote:
| Mobile twitter website gives me an "oops, something went
| wrong" or "you're doing that too much" error probably about
| 50% of the time I open a link to it.
| edhelas wrote:
| In France we have a Craiglist-like website. They recently
| moved to ReactJS : https://www.leboncoin.fr/
|
| The website features didn't changed in between. It's
| basically a pagination + a search based on radius (so DB
| related) + name (so DB related) + categories (so DB
| related).
|
| The complete website could be build in pure HTML + CSS and
| a bit of JS + Ajax to refresh parts of it.
|
| But no, it's build with ReactJS, and it takes seconds to
| search a simple item on it.
|
| To compare, just try the same search on the Dutch
| equivalent, MarktPlaats, https://www.marktplaats.nl/. The
| experience is way snappier, way lighter, the features are
| the same, and it's just HTML + CSS + a bit of JS.
|
| We made a mistake with React/Vue/Angular. And we should
| really go back and stop using those frameworks.
| julosflb wrote:
| Could not agree more. It is barely usable now. The exact
| opposite of the original spirit. A complete failure.
| amedvednikov wrote:
| It has 96 .js scripts on a single page.
| pyronite wrote:
| This used to be a bigger deal before HTTP/2 increased the
| number of concurrent requests to be virtually unlimited.
|
| Unless I'm missing something, it's "optimal" for a site
| to have many split files. If their JavaScript were 1
| file, a change to a single character would mean the need
| to re-download every bit of JavaScript. Instead, with 96
| files, it would mean 95 of them are still cached client-
| side and only 1 is need of downloading.
| thomaslord wrote:
| It looks to me like these scripts are asynchronously-
| loaded components that load only once they're needed. In
| this case it looks suspiciously like they're nested and
| each script download causes another script to be
| downloaded once the component renders, which would make
| HTTP/2 a moot point. I can even watch the requests pile
| up in the dev tools when they're cached, so my guess is
| if they dumped everything in one file (or even 10 files,
| just not 95) they'd get noticeably improved performance.
| goatlover wrote:
| What's the reason for redoing a website that provides the
| same functionality? Why use an SPA for basic website
| features?
| pier25 wrote:
| > _And we should really go back and stop using those
| frameworks_
|
| I think you are cherry picking.
|
| There are plenty of examples in the modern web of
| terrible React/etc implementations but that doesn't mean
| the approach in itself is bad.
| kolanos wrote:
| > There are plenty of examples in the modern web of
| terrible React/etc implementations but that doesn't mean
| the approach in itself is bad.
|
| If the creators of React can't get it right, then what
| hope is there?
| pier25 wrote:
| React is bloated and slow, but there are dozens of
| frameworks other than React.
|
| https://krausest.github.io/js-framework-
| benchmark/current.ht...
| deanCommie wrote:
| Please name some.
| pier25 wrote:
| Some good React alternatives?
| mhoad wrote:
| I've been plying around with lit-element lately and am
| finding it a much simpler experience overall. Likely a
| lot faster as well https://youtu.be/uCHZJy2n8Qs
| fbnlsr wrote:
| Thank you for this post. I yell at my screen each time I
| have to use leboncoin.
|
| It was super ugly, but it did the job. Now it's super
| ugly, but it steals my focus at every opportunity,
| refreshes parts of the UI I'm about to click, or has
| select inputs that love to play hide and seek with my
| cursor. It's a UX nightmare.
|
| I must say their new payment system is nice. But boy do
| we have to suffer when looking for something to buy now.
| girishso wrote:
| Agreed. SPAs only make sense for few websites like
| Trello, for most other websites plain dynamic HTML with
| dash of ajax here and there are much better.
| pier25 wrote:
| You know it's possible to use any of the modern JS
| frameworks without SPA, right?
| ljm wrote:
| I sort of tolerated New Reddit at first, until I
| experienced first hand their (to the user) cynical reasons
| for doing it. Namely: throwing mobile app prompts in your
| face, blocking some reddits unless you're logged in,
| inserting ads masquerading as proper posts...
|
| Even then, I could cope with some of it, except that they
| just totally broke the experience with shitty infinite
| scrolling. You can't click a damn thing and hope to go back
| to where you left on a post. Sometimes even old.reddit.com
| will redirect you to the new version now.
|
| These redesigns would suck less if they were more about
| being functional and not about scraping every last morsel
| of engagement from unwitting visitors, through whichever
| devious methods they can imagine.
| troughway wrote:
| Twitter and the new Reddit aren't in the same category.
| Twitter is still somewhat usable.
|
| Reddit, on the other hand, is an absolute clusterfuck from
| layout and usability perspective. The choices made were not
| made for monetary gain, they are simply really bad design
| choices that for one reason or another have not been fixed.
| mrweasel wrote:
| Aah, the Reddit redesign. I still can't use it. I check
| up on it once in a while, but my 7 year old MacBook Pro
| still don't like it. It remains slow, regardless of the
| number of times Reddit claims of have improved the speed.
|
| On the phone it's even worse, a large number of subreddit
| now require that you use the app... unless you just go to
| old.reddit.com.
|
| The point of the reddit redesign still alludes me. Sure
| the old design isn't mobile friendly, so I can understand
| that they would want to fix that. Then again they mainly
| use the redesign to push the app. And the new design
| isn't that mobile friendly anyway. Certainly not if you
| value battery life. Comments are now also hidden by
| default, which is just weird. But you have infinite
| scroll, which seems to be the main selling point. I'm not
| sure I needed that though.
| v7p1Qbt1im wrote:
| I like the redesign actually. The default view is
| terrible, though. Once you start using classic or compact
| view it's usable.
|
| Like 80% of my reddit usage is on mobile by now, though.
| So it doesn't matter that much to me.
| pier25 wrote:
| Totally agree.
|
| It's incredible that ugly old.reddit.com with RES still
| provides a better user experience.
| notyourwork wrote:
| Not sure why I'm being downvoted, in what way is Facebook's
| performance not atrocious?
| freediver wrote:
| It is not a failure of the profession. There are engineering
| teams out there that excel at software performance. Granted
| they may not have billions of users. It is a matter of mindset
| and core values and those are hard to change.
| tambourine_man wrote:
| Sorry, I won't take blame for that.
|
| Still haven't found a use case for React/Angular or
| SASS/whatever.
|
| If I'm guilty of something is not recognizing the validity of
| those tools, as I'm sure there are.
|
| But 2MB CSS is simply inconceivable to me.
| tiborsaas wrote:
| That 2MB of CSS is legacy crap most of it they didn't use.
| It's the hallmark of Conway's law.
| seph-reed wrote:
| React, Vue, and Angular all use a virtual DOM, which means
| they're already deprecated 5 years from now. A virtual DOM is
| dumb.
|
| SASS, SCSS, LESS, etc are kind of great though. It sucks you
| have to compile them to css, but you can do this:
| .App { .Topbar { .Logo { color: green }
| } .Content { h2 { color: orange; }
| } }
|
| Saves a lot of time and effort.
| hmcdona1 wrote:
| Angular uses an incremental-dom not a virtual dom:
| https://github.com/google/incremental-dom
| seph-reed wrote:
| https://github.com/google/incremental-dom#usage
|
| Technically correct. The point is, it's not native.
| edhelas wrote:
| Big +1.
|
| I would be really interested to find one, only ONE, website
| where React/Angular was really bringing a better experience
| and better final product than a standard pure JS with simple
| Ajax system.
| taurath wrote:
| I can't help but feel like the people that feel this way
| are people that don't build maintain and modify customer
| focused web products for a living.
| JoshuaDavid wrote:
| I've used react for internal administrative tools for
| configuring UI, and the ability to do a real-time preview
| of what the UI will look like based on how you've
| configured it is pretty useful. Also used it a number of
| times to build form inputs that aren't natively supported
| ("list of objects all with the same properties where you
| can select and make a change to a bunch at once" sort of
| thing).
|
| Basically I've found that if you're doing something useful
| which could be done with jquery but would probably have had
| subtle bugs due to a combinatorial explosion of possible
| states, you can usually use react in that context to make a
| cleaner, faster, and less buggy version of that same UI
| that is faster to develop and easier to reason about (and
| thus better for the end user, since software that works
| consistently is more valuable than software that mostly
| works as long as you don't breathe wrong near it).
|
| If you're looking for examples where a single-page app is
| better than server-side-rendered HTML with some javascript
| sprinkled in to make certain components more interactive,
| though, I can't help you. The successful use cases I've
| seen for react are of the "use it as the way you sprinkle
| additional functionality into your server-side-rendered
| HTML" type.
| komali2 wrote:
| What simple Ajax system?
| __s wrote:
| I updated openEtG to use React instead of PixiJS.
| https://etg.dek.im https://github.com/serprex/openEtG
|
| Fixed some UI bugs, made it straight forward implement
| features like better animations & replays, performance
| improved by removing stuff like a constant timer for UI &
| having a global mousemove handler tracking mouse
| coordinates
| freedomben wrote:
| better experience for who? For the developer it's a _way_
| better experience. For the consumer it often isn 't because
| of inefficient bloat, but if effort is put into packaging
| it sensibly it can be better thanks to build
| pipelines/optimizations. In my experience, there's a lot of
| apps that would have never gotten written in the first
| place without the boost from React/Angular/etc. It simply
| takes way longer (which means also more expensive) to use
| "pure javascript and ajax."
| munchbunny wrote:
| I've been doing FE development on and off since IE5/6,
| starting out with pure JS and Ajax, and in my opinion the
| modern FE developer experience using the major frameworks
| is a generational improvement over the messes we used to
| write. There are still frustrations, but it's a lot
| better than it used to be.
|
| Browser API's and CSS have all improved drastically since
| then, so pure JS and Ajax isn't as bad. I still avoid
| frameworks for small things just to keep pages
| lightweight. But for heavyweight projects, if you don't
| use an established framework, you just end up with a
| shitty home-grown framework anyway, because the
| alternative, teams of developers working on the same site
| with no frameworks, is even worse.
| freedomben wrote:
| Agree completely. I'm amazed at how good pure JS is these
| days. I only use React when I have a non-trivial UI that
| I need to write. It's just not worth it for simple stuff.
| That said I don't do a ton of FE work these days, so my
| opinion is less relevant.
| OkGoDoIt wrote:
| For a certain kind of developer who drinks a certain kind
| of Kool-Aid, sure. Personally I am a lot less productive
| when I'm forced to work on a React codebase. It's kind of
| like using an ORM, it can feel like it makes things
| easier, but really you end up fighting with the
| abstraction more than if you had just learned the
| underlying technology itself.
| jdavis703 wrote:
| The thing is, every place I've worked that was against
| ORMs or frontend frameworks wound up evolving their own
| half-documented, half working framework. I find it's
| easier to spend as much time learning the abstraction as
| the underlying technology, and then that knowledge can be
| ported from system to system.
| freedomben wrote:
| My experience too. The whole "we don't use a framework"
| sounds great but it always turns in to some sort of home
| grown framework that is poorly documented, has bugs, and
| isn't open source so you can't take it with you when you
| leave.
| rhizome wrote:
| Related: "I don't watch or even own a TV" [ _watches
| Netflix /YouTube on a laptop six hours a day_]
| akamia wrote:
| You also miss out on the community aspect of things.
| Working with a framework like React means that there is a
| worldwide community of developers that you can tap into
| when you run into a roadblock.
|
| It is incredibly frustrating to run into an issue with a
| home grown framework and have to ask around only to
| discover that the person who wrote the part you're having
| trouble with left the company 2 years ago and no one else
| understands it.
| aerovistae wrote:
| It sounds to me like you may have never worked in a
| codebase with thousands of JS files. On a major
| application, organizing code in vanilla JS is all but
| impossible. I agree it's better for a very small case, and
| I agree react slows things down, but that's a worthy trade-
| off for having organized, legible code.
| Kaze404 wrote:
| What makes you think React/Angular are products to increase
| user experience? Of course you won't find that, they are
| tools for developers to streamline development and make
| maintenance easier. Have you worked on a _platform_ that
| uses nothing but pure JS and fetch calls? I have, and there
| 's no way to make sense of a project that has to deal with
| so many things.
| revscat wrote:
| https://m.youtube.com/watch?v=F5hA79vKE_E
| BoumTAC wrote:
| why is it downvote ? This link just show you can create a
| basic twitter like application in 10 minutes with the
| right tool. Imagine how many hours/days it would take
| with any JavaScript framework !
| Kaze404 wrote:
| Probably because a Twitter close isn't even close to a
| complex application. You can build one in React/Vue just
| as fast as you would without them.
| tambourine_man wrote:
| >they are tools for developers to streamline development
| and make maintenance easier.
|
| I'm not convinced they are successful at that either.
| datasage wrote:
| Anytime you need to stream data to or from a client, like
| audio/video or data. Single page apps have a much better
| experience.
|
| From an architecture standpoint, it does also allow a
| much simpler separation of concerns.
|
| That said, it does it get used more often that it should
| and can take more time to build than a multi-page app.
| dralley wrote:
| Fucking gmail, for example.
|
| The new SPA version is far, far slower than the old HTML
| version, and uses a truly insane amount of memory. I have
| 2 gmail tabs open, and according to Firefox's
| about:performance page, one is using 140mb of RAM, the
| other is using 95mb, and both are at the very top of the
| list in terms of CPU usage. Above even YouTube in both
| CPU and memory, which is itself fairly bloated.
|
| It is absolutely disgraceful.
| Benjammer wrote:
| 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.
| aerovistae wrote:
| 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 arguing against using a FE framework to
| organize FE code, you're basically saying "We don't need
| frameworks in general! All code should be inherently
| organized!" That's not realistic. It's just not feasible
| when you have a large project.
| Benjammer wrote:
| Yeesh, you've badly misinterpreted my comment. Re-reading
| it, I'm partly to blame here.
|
| >That's not an argument to have no cabinets.
|
| This isn't the point I was trying to make. I didn't mean
| to piggy back on this part of the parent comment: "Have
| you worked on a platform that uses nothing but pure JS
| and fetch calls?"
|
| I meant to respond to this part of the parent: "they are
| tools for developers to streamline development and make
| maintenance easier." I often find that the most ardent
| React fans will see "not React" and jump immediately to
| "spaghetti of vanilla js and fetch calls," with no
| further questions asked.
|
| I'm trying to argue against React dogmatism, I'm not
| arguing in favor of "no framework" dogmatism.
| Kaze404 wrote:
| To be clear I'm not advocating for React on every
| possible use case. In fact I've grown weary of it over
| the years, but not for the reasons the comment I was
| responding to pointed out. My point is that React makes
| the process of organizing frontend code easier, not that
| it's the only way to do so.
| asdkhadsj wrote:
| Well, if we take a step back from React and talk about a
| sort of data-first approach to UIs, I think they are
| _definitely, much_ easier than the old jQuery era.
|
| Mutable state, notably knowing all possible variations of
| said mutable state and how it relates to everything, is
| very difficult imo.
|
| Is React the best implementation of this? Definitely not.
| It will evolve as time goes on. But I don't think I could
| ever manage state in the jQuery mutate-everything model
| again.
| marcodave wrote:
| > 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.
|
| Good counterpoint. Parent comment sound too much like the
| "TRUE programmers don't use data structures" old meme
| tiborsaas wrote:
| These are parallel things. Frontend frameworks let you
| build more predictable and solid apps than vanilla JS.
|
| Indirectly it leads to better UX since the developers can
| spend more time on UI tweaking, than doing it vanilla.
| rhizome wrote:
| Well, one primary benefit seems to be to make loading
| indicators/spinners into first-class components.
| ummonk wrote:
| Come on man, real programmers use assembly and roll their
| own browsers.
| brlewis wrote:
| Assembly is a needless abstraction. Real programmers
| create binaries with xxd.
| krapp wrote:
| Real programmers use a magnetized needle and a steady
| hand.
| TenJack wrote:
| I agree, React/Angular front ends always seem slow and clunky
| to me.
| suyash wrote:
| React is garbage
| yagodragon wrote:
| I can't decide whether I love or hate the UX of this new stack.
| It certainly feels more like an app now than a website. I like
| the new basic layout, "app shell" or tier 1 rendering. It feels
| like the First Contentful Paint is improved and some random
| layout shifts have eliminated. It might take a couple of
| seconds more to load something but it appears where you expect
| it to appear.
|
| On the other hand, navigation and clicking around is still sooo
| slow. My 60-year-old aunt called me and asked if she needs a
| new pc because facebook makes her laptop fans spin like crazy.
| I couldn't explain to her about all this react-redux-graphql
| thing and frankly, she doesn't care. All she cares is that
| facebook is slow and all she does is post photos and talk with
| friends like she did 10 years ago.
| scep12 wrote:
| I don't use Facebook but how do you know it's not BE calls that
| are creating the slow experience? It sounds like they rewrote
| the FE not the entire system.
| BubRoss wrote:
| I still don't understand how the biggest websites get away with
| being so unbelievably bloated. My guess is that most people
| have medium to old phones and PCs that are bogged down with
| nonsense running in the background and facebook, instagram,
| twitter etc. run extra slow, but I guess people just put up
| with it.
| marcodave wrote:
| people just put up with it
| deadbunny wrote:
| The new design is so laughably bad. I was trying to send a
| message to someone on the website, it took 10+ seconds to open
| the chat window then when typing it couldn't keep up with my
| typing (I'm not an especially fast typer either). It was like
| having a 5 second ping over SSH. This is on top of the (pinned)
| tab regularly needing to be closed as it slowly takes up system
| resources.
|
| This is all on my 8core/32gb workstation. I can't even imagine
| how much utterly useless crap they are running in JS to make
| that kind of experience.
|
| On the bright side it does mean I am weaning myself off as
| keeping a pinned tab open is a non starter so I can't just have
| a quick refresh. And I'll be fucked if I'm installing their
| apps on my phone.
|
| So I guess thanks needs to goto the FB engineers for making
| their new website so utterly garbage that the tiny dopamine
| hits driven by the FB algorithms are worth less than the pain
| caused when using the site.
| mister_hn wrote:
| There's too much CSS and JS because of web components and too
| many teams.
|
| * team for web component A => CSS, JS
|
| * Team for web component B => CSS, JS
|
| And so on with 1000+ components,
|
| Ends up to be a big pile of mud and everything maybe
| duplicated, just got a different name and failed to be
| optimised away and removed.
| dewey wrote:
| I guess they probably could build a nice and fast website if it
| was up to them. But there's probably a lot more requirements
| than just that.
|
| Things like
| https://twitter.com/wolfiechristl/status/1071473931784212480...
| are probably not decided on and implemented by the engineering
| team but are coming down as a requirement from the top. This is
| probably the case for a lot of other decisions that slow down
| the page ("We need this A/B test framework", "this needs to be
| hidden to increase retention",...)
| gotofritz wrote:
| > Things like ... are probably not decided on and implemented
| by the engineering team but are coming down as a requirement
| from the top
|
| Yeah, welcome to the real world. We _all_ have to handle
| requirements like that, except maybe when we build our
| portfolio site
| 5cott0 wrote:
| >Things like https://twitter.com/wolfiechristl/status/1071473
| 931784212480.... are probably not decided on and implemented
| by the engineering team but are coming down as a requirement
| from the top.
|
| I've always suspected that the Div-itis plaguing fb's website
| is a result of React's dependence on the overuse misuse of
| higher order components.
| s-km wrote:
| React components aren't a 1:1 mapping to the DOM, so you
| could in theory have 50 HoCs wrapping a single component
| and it still only output one div or whatever.
|
| Also, HoCs have somewhat fallen out of favour over time,
| with hooks and the child as a function/render prop style
| becoming more popular. I think the only HoC I consistently
| use these days is `connect` from `react-redux`.
| lukevp wrote:
| You can use hooks with redux now, so what's the purpose
| of using connect instead of useDispatch or useSelector?
| Octoth0rpe wrote:
| Two big reasons: Values passed via connect can be
| validated by proptypes, and by using connect you can
| mount your component without redux. That may make sense
| for building shared components that may be used with
| redux in one part of your app, but without redux in
| another part. There are a lot of smaller reasons to
| prefer connect, but those are the big ones to me. FWIW I
| use both approaches depending on needs.
| SheinhardtWigCo wrote:
| The extra divs are an obfuscation technique, intended to
| frustrate scrapers and browser extensions.
| tomduncalf wrote:
| Since the <Fragment> component was introduced (React 16?)
| excessive wrapper divs are no longer necesssary
| fortunately!
|
| Edit: not sure they ever were actually, I think you could
| just return props.children in most cases?
| 5cott0 wrote:
| All these things can be true and yet people will still
| frequently misuse them.
| the_other wrote:
| It's not.
|
| HoCs don't add nesting. If they do, you're doing it wrong.
|
| React <15 (2yrs old), did nudge you in the direction of
| div-itis, because all components that rendered something
| had to render a single root element. The more recent
| versions did away with that constraint. HoCs don't even
| need to return markup; they're functions which return
| functions. The general expectation should be that an HoC
| behaves like a factory for the components it wraps.
| 5cott0 wrote:
| So every React app can be effortlessly refactored to use
| whatever shiny new latest and greatest architecture
| abstraction React comes up with?
| the_other wrote:
| No, and FB themselves discourage this in their
| documentation.
|
| Regardless of upgrade paths, React <15 would still let
| you use HoCs w/out adding excess element nesting.
|
| I don't contest that the older React tended towards div-
| itis if you weren't careful with how you used it. But
| this thread was about Higher Order Components (or wrapper
| functions), which don't have any inherent effect on
| nesting.
| BrandonSmith wrote:
| I'm not sure why FB's site has unnecessary DIVs... But to
| defend React, HOC or render prop techniques but don't have
| to output DOM. In other words, every React component does
| not map to a DOM element.
| [deleted]
| tenebrisalietum wrote:
| They already did: https://mbasic.facebook.com.
| andirk wrote:
| 90's versions, like mbasic, of almost every website is
| better. More content, less noise. Mbasic could still use a
| flaming <hr> tag though
| smt88 wrote:
| > _90 's versions, like mbasic, of almost every website
| is better._
|
| I mostly disagree and assume this is slightly hyperbolic,
| but I take your point. The web used to be documents, even
| for things that needed to be apps (like email). Now, the
| web is apps, even for things that should be documents.
|
| Beyond that, the web was not the capitalist/SEO/marketer
| battleground that it is today, where many sites have so
| many costs behind them (devs, videos, etc.) that they
| need a boatload of ads just to try to stay in the black.
|
| In the 90s, you could have a very popular message board
| with millions of pageviews a month for $30/mo.
| stinos wrote:
| For me on FF this is only a tiny bit faster to load the
| main page, but way less readable and pictures are so small
| you have to open them to be able to see what's in there. So
| not a net positive result imo.
| crazygringo wrote:
| For me the performance seems better. It also seems strange that
| if one of their two main publicly stated goals was to increase
| performance (the other goal being ease of maintenance), that it
| would slow down. Maybe you have extensions interfering?
|
| Also, the set and scale of features in the Facebook app makes
| it literally one of the most complex webapps out there. It's
| _far_ more than just multimedia posts+messaging -- it 's a
| marketplace, dating, games, apps, groups, pages, and more.
| Nobody's "failing". And the 2MB of CSS was the "before"
| uncompressed. The "before" compressed was 400 KB, and this
| update appears to reduce it to under 80KB compressed. That's
| _96% less_ than the 2MB you 're complaining about, more than an
| entire order of magnitude.
|
| So Facebook seems to be improving here, no? I fail to see what
| is a "total failure" or "clearly a problem".
| lawn wrote:
| > It's really sad that in 2020, 10k+ engineers can't make a
| photo, video, post and message sharing website that is not a
| pain to use.
|
| Too many cooks spoil the stew.
|
| I might even go so far to say that 10 engineers would have a
| larger chance of success than 10k+ engineers.
| Impossible wrote:
| This was my experience at Facebook. Attempting things with a
| small team (or heaven forbid by yourself) was heavily frowned
| upon because it didn't justify manager and director salaries.
| As a result you ended up with poorly performing over-
| engineered code bases that prefered complex, expensive
| systems that would take multiple teams to build, but for
| whatever reason complexity that would improve performance was
| frowned upon. I'm sure this is common at many big tech
| companies. I didn't work on the mainline FB app but it seemed
| like part of the culture.
| disgruntledphd2 wrote:
| When were you there, if you don't mind me asking?
| dhimes wrote:
| I don't know if I have the new stuff or not, but I agree that
| some parts are currently frustratingly slow to use on desktop.
| I figured it was because so many people are spending much more
| time on it (including, tbh, me). But I was trying to message
| with an old friend and simple gave up a few days ago.
| EGreg wrote:
| Can you please compare the speed of https://yang2020.app/events
| ?
|
| On the mobile web or desktop, either one. (We're running it off
| of one server, it might get the HN effect, we'll see.)
|
| We have been building our own, open source social networking
| platform and we have tried to make a lot of things more
| efficient while doing so. The site I linked to didn't minify
| any files or optimize images. However, it loads things on
| demand as needed, and even lazy-loads entire components.
|
| Is it faster than Facebook? We have our own component system,
| not React.
|
| Here is a site that did minify and combine all files:
| https://intercoin.org
|
| And here is the platform we used:
| https://gitub.com/Qbix/Platform (warning: not all of it is
| documented, but enough, at https://qbix.com/platform/guide).
| discreteevent wrote:
| I've never been on Facebook so I can't compare but your site
| responds pretty quickly for me. Also you left out the h in
| GitHub in your link so it goes to a domain for sale site.
| benbristow wrote:
| Twitter's new design is pretty fast. Sure, it does a lot less
| than Facebook but it's using similar modern SPA tech.
|
| Facebook is still pretty slow even on a Ryzen 3900x with 32GB
| of 3600mhz RAM. It's a lot better than it used to be though.
| snazz wrote:
| Yeah, I think that Twitter did a pretty good job. After the
| initial load, it even works offline, so the actual API calls
| are the only thing that it's fetching over the network.
| thomaslord wrote:
| After the twitter update, I can't seem to get the initial
| load of an individual tweet to work. Ever, on any device,
| on any network. I encounter this issue on my laptop (on
| both Windows and Ubuntu), on my desktop (also both Windows
| and Ubuntu) and on my Android phone. It doesn't matter if
| I'm logged in or not, I always get "something went wrong"
| when I load the page and have to refresh at least once.
| ipython wrote:
| I agree with you; however, the key disconnect is that Facebook
| is _not_ a photo, video, post and message sharing website. It
| 's a marketing platform intended to extract the most value out
| of you, the viewer, and transfer that value to Facebook and its
| advertisers.
|
| If you think of it this way, you can see how you may need 2MB
| of CSS: to battle the bots trying to scrape your information
| and replicate your network, to sidestep the evil developers of
| adblocker software that threaten to destroy the sweet value
| transfer, the JS required to track every single movement you
| make both online and off, the A/B testing framework that allows
| you to determine how to most efficiently extract that extra
| 0.001% of valuable eyeball time, and so forth...
|
| Connecting the world? Well, I guess that could be a nice side-
| effect...
| rhizome wrote:
| That's probably something that can be measured: if the
| profile/wall fills out over several seconds, when do the ads
| appear? First, before everything else? In that case it would
| be cynical, but I agree that they might monetize the delays
| by ensuring ads appear before anything else.
| disgruntledphd2 wrote:
| The ads are only on the side on profile pages.
|
| The actual ads on FB desktop are the newsfeed ads, which
| you see as you scroll.
| karmakaze wrote:
| These views are aligned. A site that's fast and a pleasure to
| use advances both agendas. It's still a failure.
| radicalbyte wrote:
| Only if there's competition. The network effect ensures
| that there is no competition. Leaving us where we currently
| are.
| karmakaze wrote:
| Not even, users can just 'not play' (or play less) if the
| game's no fun.
| beagle3 wrote:
| There are many users for which it is not fun, but an
| addiction. I have spoken to lots of people who say about
| once a month something like "Yeah, facebook is really bad
| for me, I just waste time and get upset", but they can't
| stop checking it every hour, and responding to posts that
| touch them emotionally, in either a good or bad way.
|
| That's by design, of course - it benefits Facebook
| greatly that its herd is addicted, and unlike people
| addicted to alcohol, nicotine or other substances -
| there's not even another supplier they can turn to: It's
| either feed your addiction or suffer withdrawal symptoms.
|
| And I think the success rate of quitters (as a percentage
| of those who actually want to quit) is also comparable,
| at single digit percent.
| jawns wrote:
| Imagine this:
|
| A "free" ad-driven social networking site that brings in
| gigantic revenue, but that has to pay thousands of high-
| priced engineers to implement all of the cruft you just
| described.
|
| versus ...
|
| A subscription-based, non-ad-driven social networking site
| (perhaps operating as a member-owned cooperative?) that
| brings in much more modest revenue but that also can operate
| with many fewer engineers because it can be largely cruft-
| free.
|
| I know there have been a gazillion attempts at the latter and
| none has succeeded in any way comparable to the "free" sites.
| It's too bad, because if any of them were to ever achieve
| Facebook scale, the subscription price would probably be
| quite modest.
| zdragnar wrote:
| Food for thought- the value of each user is radically
| different when accounting for geographic (i.e. income)
| markets.
|
| For subscription to work, you either:
|
| 1- undercharge users from wealthier countries
|
| 2- price poorer users out of you platform
|
| 3- give up on the idea of worldwide adoption (Facebook
| scale, as you say) entirely
|
| 4- attempt to charge different amounts by country of
| origin, and watch your users cheat the system mercilessly
|
| 5- go freemium, and suffer the same fate that news
| organizations do- find that far too few are willing to pay
| to go ad-free, stick ads back into the free version, and
| end up leaking data anyway
|
| I suppose 4 might be the most feasible option, but once it
| is obvious that some people pay more for the exact same
| value, they are likely to assume that the product has less
| value than it actually does, feeling that they are being
| ripped off.
|
| In short, there is probably a good reason that paid
| services will never reach Facebook scale.
| mtsr wrote:
| What you argue here could probably be said about half the
| companies admitted to any YC batch, and still there are
| successes. Maybe the glass can be half full too?
| zdragnar wrote:
| I think the catch is focusing on "Facebook scale" in
| terms of users on a social network. I am not aware of any
| YC companies at close to their scale (or potential to get
| there) without being ad driven, freemium or running on
| borrowed money.
|
| Small social networks are fine for what they are and, I
| think, have much more flexible options for getting the
| bills paid.
| PaulDavisThe1st wrote:
| 6. Option 4, but just relax about the outcome.
|
| At ardour.org, we offer 3 tiers of subscriptions ($1, $4
| and $10 per month) named to target different economic
| conditions. We also offer a single fixed payment with a
| suggested but editable cost based on OECD data about the
| cost of dining out.
|
| We're not trying to maximise revenue, which is perhaps an
| important difference between us and, oh, Facebook :)
| brlewis wrote:
| > the subscription price would probably be quite modest
|
| Yes. It would be set to the minimum required to dissuade
| banned users (e.g. spammers) from continuing to create new
| accounts. This amount would still likely be well above
| cost.
| hbosch wrote:
| > A subscription-based, non-ad-driven social networking
| site (perhaps operating as a member-owned cooperative?)
| that brings in much more modest revenue but that also can
| operate with many fewer engineers because it can be largely
| cruft-free.
|
| I, too, loved App.net. Alas, seems that people won't even
| pay a couple bucks a month to see what their friends are
| eating for lunch.
| asdkhadsj wrote:
| People instinctively know the value of something when
| asked to part with their money. :D
|
| Yet they still spend their time on it. Huh.
| jimbokun wrote:
| People know their friends are not on App.net, but are on
| Facebook.
|
| Or in other words:
|
| https://en.wikipedia.org/wiki/Metcalfe%27s_law
| ianmobbs wrote:
| I think the biggest assumption you're making here is that
| most people care about ads - and they don't. Fundamentally,
| when I'm scrolling through Facebook or Instagram or Reddit
| or whatever, I just don't care that I see ads while I'm
| scrolling. I'm not going to pay $1/2/3/4/5 a month to avoid
| something I don't care about, and that's really only the
| value add of a subscription-based service. I'd also say
| most folks don't find Facebook's data policies as egregious
| as the tech community does.
| freediver wrote:
| I'd really like to understand how does one not care about
| ads. To me it's like potholes on road. It would require
| terrific willpower to ignore them.
| TwelveNights wrote:
| Although it's getting harder and harder since many
| platforms try to blend their ads in with the actual site
| content, I can avoid them reliably well by checking
| metadata such as the poster, some indication that it's an
| ad, or if the content is clearly different from what I
| was expecting.
|
| I wouldn't say it's as bad as potholes on the road, since
| ads are more predictable.
| BurningFrog wrote:
| I'm not interested in the ads, so I don't notice them if
| they're not shoved in front of what I _am_ interested in.
|
| I can see that if you consider ads to be inherently
| offensive, you _would_ notice them wherever they appear,
| and be annoyed.
|
| But that's not where most people are.
| cameronbrown wrote:
| People do. My dad doesn't install an adblocker because he
| simply doesn't care. I wouldn't either if it wasn't for
| the serious performance impact.
| Dotnaught wrote:
| Being unwilling to pay for the service suggests to me
| that the entire experience has no meaningful value.
| smadge wrote:
| Economists have done studies where they tried to
| determine how much someone would need to be paid to stop
| using Facebook for a year. Maybe people are not willing
| to pay for the service, but they would rather have the
| service than $X.
| [deleted]
| maccam94 wrote:
| Facebook's problem is that a subscription fee would
| drastically limit adoption and prevent them from
| monopolizing the social graph. They see more potential to
| make money without charging users directly.
| hckr_news wrote:
| People just don't want to pay for social networking
| platforms. We've been conditioned to think that these
| things should be free.
| dbspin wrote:
| Perhaps it's just a figure of speech, but I feel you
| should be challenged on the use of 'been conditioned to'.
| I see conditioning misused as an explanation all the time
| in tech discussions. This isn't an example of
| conditioning, but of anchoring, which if you want to view
| it through the lens of learning theory is an example of
| modelling rather than conditioning. But really it's
| better understood through the lens of behavioural
| economics. A value has been established and normalised,
| and other values are judged against it.
|
| The reason I bring it up is that in changing user norms,
| it's much less helpful to think about them in stimulus
| response terms, than in terms of modelling other users
| behavior - which itself is guided by limitations on our
| capacity to process information, and heuristics which
| though adaptive are poorly adjusted to the modern media
| landscape. So people didn't flock to facebook initially
| because they were conditioned to prefer it - they used it
| because (in addition to offering a peek into the lives of
| others, it was cool). Conditioning is an important part
| of why people become addicted to the reward loops of
| social networking sites, but it's an insufficient
| explanation for their appeal and often misapplied.
| BurningFrog wrote:
| Well, they _are_ free, so that probably contributes to
| that perception.
| huijzer wrote:
| I think social media is as social as sitting in a bar
| where everyone tries to get you to listen to their
| stories and look at their photos. To respond to someone
| in the bar you can send a text, which they might respond
| to somewhere in the future. Therefore, I am not planning
| to pay for it, since it is not adding (much) value to my
| life.
| eitland wrote:
| > I know there have been a gazillion attempts at the latter
| and none has succeeded in any way comparable to the "free"
| sites. It's too bad, because if any of them were to ever
| achieve Facebook scale, the subscription price would
| probably be quite modest.
|
| MeWe is freemium (paid extra stickers and storage) and is
| actually nice, at least the parts I've seen, a lot like
| Google+ - a friendly neighborhood full of photographers,
| chili enthusiasts etc.
|
| Of course most people are going to go with twitter, but if
| you'd like something more like Google+ or what Facebook
| could have been you might want to try MeWe.
| rosstex wrote:
| Unfortunately, you're right.
| js2 wrote:
| I wonder if they fixed the bug where if you visit the site with
| Safari on an iPad, when you try to type a comment, every space
| becomes two spaces. Also, I wonder if paste (command-v) is also
| randomly blocked at times.
|
| I use mbasic.facebook.com as much as possible. Occasionally
| I'll use m.facebook.com. I've had the mobile apps uninstalled
| for ages.
| x3blah wrote:
| Does the compensation of those "engineers" reflect that they
| have "failed"? Perhaps there is another way to evaluate the
| work, not from the perspective of the user waiting in front of
| a screen. Do not forget that the money to pay the salaries of
| those who do this work does not come from users.
| smhinsey wrote:
| All this and the chronological sort mode is still totally
| broken. Third post in my feed is 3 days old followed by one 2
| hours. Total joke.
| jaywalk wrote:
| They really don't want you sorting chronologically. That
| negates The Algorithm(tm).
| strictnein wrote:
| Remember when working at a FAANG company was supposed to be
| some mark of pride?
| asumandiras wrote:
| > If one needs 2MB of CSS for such a website
|
| The 2MB was for the old site. The new site loads 20% or 400KB.
| tarsinge wrote:
| I haven't tested but I doubt the problem is with the CSS, is
| it?
| gkoberger wrote:
| I'm not a Facebook (the company) apologist by any means, and
| only use it because there's a few groups on it relevant to a
| company I own.
|
| That being said, I find the new FB to be insanely fast. I don't
| even block ads on it.
|
| I do agree Facebook was way better 12 years ago (I saw real
| updates and photos about friends, rather than companies and
| ads). But speed right now hasn't been the problem.
| todd3834 wrote:
| At a company I used to work for, we worked so hard to make sure
| our web app would load extremely fast... just to end up losing
| the battle with the data and analytics team for analytics
| scripts. They used a tag manager (tealium) which by itself can
| be used for good but it ultimately gave the other team the
| ability to overload our site with 3rd party scripts.
| virvar wrote:
| Really? I really like it. I almost solely use Facebook to
| organise blood bowl matches, so it's a lot of group chats and
| events, and it's so much better than the old design.
|
| I haven't noticed it being slower either, it's certainly not
| fast, but it's not really something I notice either.
| hindsightbias wrote:
| Looking at the internet today, I think we need to lower our
| expectations and be realistic. At least in the US.
|
| We are still driving 60mph on freeways and what trains we have
| do not travel at 300kph.
|
| Perhaps many of us flipped out when we only had 9600 baud
| modems, but you could get up, brew some tea, walk the dog, or
| read a book while waiting for a page to load. We all had so
| much more patience back then.
|
| Why do we need instant gratification with FB and other social
| media? Maybe, or maybe not /s.
| goatlover wrote:
| Because the underlying computing technology has gotten so
| much faster, unlike the case with cars and roads.
| saagarjha wrote:
| And computing technology is not beholden to oil/car
| interests and NIMBYs.
| SN76477 wrote:
| I wish they would just give us APIs and let us build our own
| experience.
| cjhopman wrote:
| 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.
| OkGoDoIt wrote:
| But then how would they force us to look at ads? How would
| they keep all their valuable data locked in their walled
| garden? Sadly I don't think we're ever going back to the
| glory days of open APIs.
| sktrdie wrote:
| You're missing their main goal: having an easier-to-change
| codebase.
|
| Apparently this is way more economically rewarding than
| performance for Facebook.
|
| With that in mind, who cares if the site is slow (btw this is
| the only complaint of your rant). If the software requires a
| few devs to change and a few eyes to maintain, they can
| literally scale as much as they want. And actually now they're
| probably in a way better position than they would if they had
| developed a super performant but unmaintainable site.
|
| The quote, premature optimization is the root of all evil, is
| still very much valid imho.
| taway555 wrote:
| I'm not sure what your setup is, but 8 seconds to load a
| profile is not my experience. It takes less than a second here.
|
| This is an anecdotal datapoint that is insanely useless in the
| real world, but the fact that it is the top comment is typical
| of this site.
| jseliger wrote:
| _Facebook was more enjoyable to use 12 years ago_
|
| We'll see what the data show. I have been reading comments
| about Facebook's supposed decline for as long as I've been
| aware of Facebook and yet their published numbers continually
| show greater engagement. https://jakeseliger.com/2018/11/14/is-
| there-an-actual-facebo...
| detaro wrote:
| Engagement isn't just driven by "enjoyability", so that's not
| a particular convincing counter-argument.
| mnd999 wrote:
| There's a lot of fake profiles though and I think a lot more
| than they're prepared to admit. Even brazen binary options
| trading scam profiles don't get removed - it appears that
| they're happy as long as the number are going up.
| ben_w wrote:
| They're trying to police 2.5 billion accounts with 45
| thousand employees (including HR, developers). I'm not
| surprised they stuck. Don't get me wrong, it's not OK for
| them to suck, but I'm not surprised given the 55,555:1
| accounts:staff ratio.
| aguyfromnb wrote:
| > _and yet their published numbers continually show greater
| engagement._
|
| Do you think this might have anything to do with the fact
| that, as an advertising company, it's crucial that they are
| able to tell companies that engagement is increasing?
| slipheen wrote:
| I've seen people in the past make the mistake of correlating
| "Enjoyment" with "Higher Engagement", but you want to be
| really careful there.
|
| For example - Flame wars increase engagement, even if people
| feel drained and frustrated afterward.
|
| I understand why it's a useful metric - It's particularly
| valuable if your business model depends on time-on-site to
| sell ads.
|
| But I wouldn't recommend them as a proxy for enjoyment by any
| means.
| [deleted]
| duckfruit wrote:
| The unquestioning supplication at the alter of 'engagement'
| (a sterile marketing term if there ever was one) is what lead
| to where we are now in the first place. This is an affliction
| that pervades the entire consumer internet sector, but the
| folks at facebook seem to have refined it to its fullest
| potential.
|
| The other day I got a facebook notification on my phone,
| which said something along the lines of "You have 4 new
| messages". Of course, thinking it was from my friends I
| opened the app to look at them. 3 of my 4 "messages" were
| notifications for friend requests from people I had never
| met. The last one was a photo someone had posted of cake
| she'd baked (not to me specifically, just in her feed). To
| someone sitting at her desk at facebook, looking at an
| engagement metrics chart, the notification would seem to have
| served its purpose - another data point, another person
| enticed to open the app in response, engagement maximized.
| But of course, this was deception. I found this experience
| distasteful enough to disable notifications entirely -
| probably another data point for their metrics team - and
| annoyed enough to complain about in an HN comment.
| strictnein wrote:
| The new "Person X has posted a photo" notifications are the
| worst. Their abuse of the notification icon is getting
| ridiculous. It used to be focused on when someone
| interacted with something you had done, now it's just used
| to drive "engagement".
| muglug wrote:
| I would be very surprised if engagement wasn't down among
| Americans under 50 - it may well be counteracted by growth in
| other markets and in other apps (especially Instagram), but
| there's _much_ less activity on Facebook.com from my peers
| than there were five years ago.
| SheinhardtWigCo wrote:
| The 2MB of CSS is needed to justify that headcount.
| robertoandred wrote:
| Where are you getting 2MB from?
| agluszak wrote:
| "On our old site, we were loading more than 400 KB of
| compressed CSS (2 MB uncompressed) when loading the
| homepage, but only 10 percent of that was actually used for
| the initial render. We didn't start out with that much CSS;
| it just grew over time and rarely decreased. This happened
| in part because every new feature meant adding new CSS."
| robertoandred wrote:
| Read the first four words.
| suyash wrote:
| Let's not even get started with thir mobile apps, horribly
| large in size, poorly engineered (performance) and privacy
| loopholes are everywhere (perhaps by design).
| freepor wrote:
| Facebook isn't trying to maximize your enjoyment, they're
| trying to maximize their profits. By that measure they are
| doing vastly better than 12 years ago.
| robertoandred wrote:
| Where did you get 2MB from?
| kick wrote:
| The _problem_ there is that '10k+' "engineers" are _trying_ to
| make _the same_ 'photo, video, post and message-sharing
| website'.
|
| It's a structural problem and little more: the website (and
| app) is their main money-maker, so they're going to give it a
| disproportionate amount of resources.
|
| Imagine you hire ten thousand people to lay one railroad track.
| [note; see end of post] If any single one of them doesn't
| contribute directly in some way, you'll fire them. This seems
| kind of strange, doesn't it? Sure, it probably requires more
| than a single person to lay a track. But _ten thousand_ people
| to lay one? How is that supposed to work, mechanically? This
| would be enough to warrant shareholder revolt.
|
| Now, the railroad track gets broken a few hundred times, maybe
| they hammer it enough to make it twice as long, whatever. It
| now no longer resembles a railroad track. Certainly no train
| could go across it. Send a few hundred people to go ask the
| managers of this project for a replacement track. Okay, we're
| now at...maybe a tenth of people having contributed? Repeat
| this process until everyone's contributed. Maybe the manager
| gives different groups different materials for the track to
| fuck with them, whatever. But somehow, every single person
| manages to not get fired.
|
| What's the outcome look like? You have a single railroad track,
| probably not even well-fit for the job (sparks fly whenever
| trains run on it; maybe it causes them to tilt, so on), but
| it's laid! And ten thousand people are employed!
|
| It's the same thing with a website. You can't put a terabyte
| onto a user's device every single time they load your website;
| you just can't. So you have a window of performance you have to
| hit. Between _ten thousand_ people trying to have things thrown
| onto user devices? Good luck making anything resembling
| 'decent'.
|
| It's the same problem that Dave Zarzycki noted in his talk
| about launchd[1], but _worse_. Instead of 512 megabytes shared
| between some random abstract parties you can basically ignore,
| it 's <10MB shared between ten thousand coders, translators,
| graphic designers, users, managers, etc. Does something seem
| strange about this?
|
| [note]: This is the appropriate comparison here; at the scale
| of 'Over ten thousand people working on one program', it's
| grunt work, not art, science, or even _programming._ There 's a
| word for implementation-grunts that's fallen out of favor in
| the past few decades: coders. This was seen as distinct until
| recently.
|
| [1] https://youtu.be/SjrtySM9Dns?t=255
| soedirgo wrote:
| I don't know how many people FB actually allocates for their
| main app, but this reminds me of a chapter in The Mythical
| Man-Month. It is said over 1000 people and 5000 man-years
| went into OS/360. I don't see it anywhere today.
|
| Instead, the book proposes The Surgical Team, i.e. about 10
| people taking specialized roles, with the system being the
| product of the mind of a few key people. I wonder how well
| this aged.
| kick wrote:
| Fred Brooks was accurate about most things, yeah. It's hard
| not to envy him; he got to work with (and write a book
| with) _Ken Iverson_. Can you imagine? People back then
| really had all the luck!
|
| ...at least as far as computers go, anyway.
| HumblyTossed wrote:
| > 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.
|
| Were you using a machine with a gigabit connection, 32GB RAM,
| and 10th gen intel cpu like the devs?
| starpilot wrote:
| Comments like these remind of an old post on Slashdot, "What
| makes a good website?" Ask "geeks" what they prefer, it's
| usually minimalism, no images, consistent text styling. In the
| end, the ideal format becomes a text file without markup. I
| think we need to accept the opinions of techies are
| increasingly irrelevant in tech. It's like being fine artist
| getting paid to design flyers or a chef making burgers.
| raphaelj wrote:
| Wrong. The average user does not give a shit if the page is
| rendered server-side, or of it's a SPA.
|
| Geeks prefer speed, like everyone. There are plenty of papers
| that show that a reduction in latency improves the conversion
| rate. And it's does not have to be ugly to be fast.
| umvi wrote:
| Geeks prefer function over form
|
| Consumers (apparently) prefer form over function (or at
| least, they are more easily fooled into thinking the more
| form, the more function)
| mellow2020 wrote:
| I prefer form to _follow_ function. Make it as pretty as
| you can, but not at the expense of the function.
| notyourwork wrote:
| Performance need not be coupled to idea of minimalist design.
| A performant website can still look like Facebook and not
| take 5000 ms to load.
| _jal wrote:
| First, that's just wrong.
|
| "Geeks", as a class, will tend to focus on technical issues
| before aesthetic ones. Looking at that fact and immediately
| equating it to an absurd extreme is a fun game, if you don't
| care about describing reality. I know some accomplished
| engineers who are also good designers, and vice-versa.
|
| Second, if my professional opinions are not being taken
| seriously, that usually means one of two things: I'm too far
| out over my skis, or am in the wrong place with the wrong
| people. Especially so if you feel like a chef making burgers.
|
| Of course, if "in total control" and "irrelevant" are the
| only two states of being one sees, I suppose I see how you
| get there.
| function_seven wrote:
| Everyone hates slow webpages. Not just geeks. We can all
| argue over whether minimalism or eye-candy is preferred. But
| if your site feels like running in mud, it's frustrating
| regardless of the design.
|
| And all these SPA, client-side rendered, sites seems guilty
| of this. You navigate to a page, and it loads up "instantly",
| except you see nothing but gray placeholder images. Then
| content starts loading in, but haphazardly. You see a link
| you want to click, and you go to click it, when BAM! it jumps
| down 37 pixels because some stupid widget just loaded above
| it on the page.
|
| I really hate the modern web. Not the look of it, or the
| styling. The mechanics and slowness.
| ravenstine wrote:
| I hope we someday enter a period of reform where our field
| begins to apply more rigor to our process. We have the
| tools to make a fast, sleek web. The process is very, very
| broken from an engineering perspective. The money seems to
| never stop, which is why businesses can burn through
| developers without too much regard to whether they are
| doing the right things. Maybe that can't be fixed, because
| the people in charge are going to keep the status quo going
| if the money is coming in and they're made to look good.
| Optimization is a risk that companies of even modest size
| find to be too great.
|
| Or perhaps people involved in a revamp/redesign/unification
| should be well compensated to the point where they are
| unlikely to leave in the middle of a multi-year project. I
| have a feeling based on my experience that a lot of these
| bad rebuilds are a result of too many engineers and
| designers coming and going.
| hn_throwaway_99 wrote:
| But, perhaps ironically, Slashdot was killed because its
| design updates made it more "designer-y" but much less
| usable. I remember one update in particular that added a ton
| of whitespace, gave it a "cleaner" look I guess, but it meant
| there were like 1/4 of the posts on the screen so it just
| took longer to peruse the comments. They also f'd up how they
| showed voting so it became much harder to just scan for
| popular comments and valuable discussion. I remember going to
| Slashdot pretty much daily and after that update just said
| screw this, will have to find something else.
|
| Design updates can be useful, but just like for engineers,
| "beware lots of highly paid people looking for something to
| do".
| jhhh wrote:
| It's Facebook's own standard: "We knew we wanted Facebook.com
| to start up fast, respond fast, and provide a highly
| interactive experience.". The person you're responding to is
| saying they haven't met their own metrics for success based
| on their experience. You can't really attribute this
| "preference" solely to them.
| suyash wrote:
| Atomic CSS is a bad idea, read more here
| https://www.browserlondon.com/blog/2019/06/10/functional-css...
| axyz wrote:
| nowadays is quite rare to write classes in pure html, using any
| framework like react, vue and similar we are used to pass
| classes in a JS environment. Obscure and minified class names
| can be imported from a package using a perfectly meaningful
| name, also the same set of classes can be exported with many
| different names to even better usage specificity with no cost
| in size.
|
| We overcome most of those issues using a mix of postcss compose
| and css modules with a custom hashing solution based on the
| actual css rule content, this allowed us to have virtually
| infinite semantically named components with a css bundle size
| that tend to stabilize around 20/25kb gzipped for a very big
| e-commerce use case and I doubt any other use case would go
| much higher than that size.
|
| https://github.com/utilitycss/atomic If you want to have a look
| (documentation needs some love, but the samples generated by
| the init do give a good idea of the concept)
| jedberg wrote:
| I can't remember the last time I loaded FB on a computer. At this
| point it's clear that they care far more about the mobile
| experience than the desktop. Even if I'm sitting at my computer
| I'll still use my phone for FB.
| 29athrowaway wrote:
| I don't like it.
|
| Round borders with misplaced text, cannot go to a specific time
| on my timeline anymore, does not feel very responsive.
|
| Overall, the UI does not look very appealing and feels like a
| downgrade.
| crocodiletears wrote:
| Reminds me of the new Chrome UI. Not a fan of this soft,
| rounded-off aesthetic that seems to be spreading about.
| whalesalad wrote:
| The use of Monokai is so off-brand for FB.
| [deleted]
| polote wrote:
| > We knew we wanted Facebook.com to start up fast, respond fast,
| and provide a highly interactive experience.
|
| And we forgot about it while developing it, this is just common
| mistake in product management, when projects are not iterative,
| things are so long, that you even forget why you are doing them
| vosper wrote:
| I saw no mention of Reason or ReasonReact. I thought they rewrote
| Messenger in Reason, and so I figured facebook.com would be next.
| Did Reason fall out of favor or something?
| dgellow wrote:
| Was Reason ever more than an experiment?
| vosper wrote:
| ReactReact just had a release (0.8) a few days ago, so it's
| apparently not dead
|
| https://github.com/reasonml/reason-
| react/blob/master/HISTORY...
| frou_dh wrote:
| The repos have some activity, but it looks bad that the most
| recent post on the official blog was in August 2018.
| swyx wrote:
| lol no, "Did Reason fall out of favor" does not logically
| follow from "I figured facebook.com would be next". you were
| simply too optimistic on Reason.
| rickyvetter wrote:
| Hey - maintainer of ReasonReact here. We don't believe in
| mandating the tools that people use and there are plenty of
| good reasons to use TS, Flow, PureScript, Rust, etc. Folks on
| the Messenger Web team in Facebook like Reason as their
| language of choice. Reason is used heavily on Messaging code in
| the old facebook.com and in this rebuilt version.
|
| The rebuilding of facebook.com was done quickly and involves
| almost every web team at Facebook. Almost all of these folks
| are familiar with Flow and only some are familiar with Reason.
| Asking every engineer at FB to learn Reason at the same time in
| addition to the already massive number of new things would have
| been adding unnecessary risk to this already incredibly risky
| project.
| longlho wrote:
| There doesn't seem to be any mention of actual KPIs/metrics
| changes in the relaunch?
| 3PS wrote:
| 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 that was and continues
| to be Reddit's redesign.
| kylemh wrote:
| I even used network throttling to do Fast 3G and it's still
| taking like ~3 seconds at _most_ for everything.
| elboru wrote:
| I guess it's optimized for some computers/networks but not for
| others. Right now I'm in an area without optical fiber so I
| have to use a 4g modem (12 MBps), I have an old 2013 MacBook
| Pro and even though my setup is far from being fast, I have no
| problems with most web pages, some few load kinda slow, but
| Facebook is in a different category, it's totally unusable,
| some stuff never even get to load. If I want to check Facebook
| I have to use Safari (the new theme is not supported in Safari
| yet).
| otabdeveloper4 wrote:
| Try it with a normal computer for normal people, not with your
| monstrous 'developer machine'.
| vbezhenar wrote:
| Do you mean 2007 year CPU constantly throttling because of
| kilograms of dust on Windows 7 full of malware swapping on
| HDD?
| Udik wrote:
| Just tried it on my 2012 $1k laptop. 2s for full page load;
| about 1s to load up a chat, about 1s to open a friend's
| profile.
| runawaybottle wrote:
| Let's go on this tangent, why _is_ Reddit's frontend so
| sluggish and lacking quality of life improvements that should
| be in place by now?
|
| Surely they are hiring world-class devs, so what's holding them
| back?
| fbthrowaway42 wrote:
| > Surely they are hiring world-class devs, so what's holding
| them back?
|
| Facebook Engineering has a notorious "not invented by me"
| culture, it's not unique there but a lot of our "world-class"
| engineers are just acting economically rationally and hole-
| digging on some new bespoke framework or tool to cement their
| position in the company. You end up with a massive amount of
| churn and over-engineered vanity projects, and it's
| manifesting downstream in basically every product we've
| turned out for the last five years. That's why the
| applications bloated and terrible.
|
| The joke inside the company is that it used to be "move fast
| and break things" but now it's "breakfast, vest and move
| things around". It's really an engineering culture of
| decadence and waste these days.
| dpau wrote:
| It's by design. Reddit doesn't want you using the website.
| They want you to download the app. As numerous annoying
| popups and notifications will tell you when visiting the
| website (especially on mobile).
| rrdharan wrote:
| > surely they are hiring world-class devs
|
| What makes you think that?
|
| Reddit seems like a place where the kind of experienced and
| talented people needed to turn it around could make a lot
| more money (via stock grants in addition to salary) and
| frankly have a lot more impact, at any of FAANG.
|
| I've not seen anything to indicate that Reddit is hiring, or
| trying to hire, "world-class devs".
| d23 wrote:
| Well first, don't just blame the engineers. The company has
| to actually prioritize making a functional product.
|
| Ultimately, reddit made no attempt to lean into the the
| thing that might attract world-class people to come there:
| a passion for the product. Or, at most, any attempts made
| were surface level. Some of the best engineers I've worked
| with are at reddit. They just happen to be outnumbered, and
| some have golden handcuffs on.
| basch wrote:
| Across mobile messenger, messenger.com and the messenger
| desktop app, the website was the only place left where you
| could have multiple chats open at once. Now that moves to one
| at a time as well. That is a huge usability regression (unless
| its been fixed since last time I tried the prerelease. Edit:
| Just switched back, it does look like they maintained chat
| windows at the bottom instead of just chatheads on desktop,
| although I can still only have two chats open at once.) Friend
| lists also got left with the legacy interface, which cant bode
| well for them in the long run. They are still facebooks most
| squandered opportunity.
|
| The neverending quest to reduce information density is a
| usability disaster, despite the misheld belief that cleanliness
| = usable. Zooming out on the new fb interface, to restore some
| information density, leaves a comical amount of whitespace.
| Wells Fargo has turned its desktop interface into a giant
| stretched mobile app. Nothing is hyperlinks that support right
| click or new tab anymore.
|
| https://medium.com/signal-v-noise/why-i-love-ugly-messy-inte...
|
| The cluster f of the old old facebook interface was beautiful.
| dhimes wrote:
| Are you using desktop of phone? I've found the desktop quite
| slow lately- I thought it was probably due to high usage.
| willio58 wrote:
| I may be the only one here that thinks Reddit's new design is
| fine now. At first, it was buggy and sluggish. Now it is fine.
| vbezhenar wrote:
| Yep, works fast for me too. Random profile opens in 2-3 seconds
| max for me. But for some people websites are slow for some
| reason. I've heard complains about Gmail loading 30 seconds,
| while it takes 2-3 seconds cold start for me.
| hetspookjee wrote:
| I don't understand how you think a 2-3 second load time is
| "fast" for such an enormous platform and the actual content
| the user sees. I sure get that Facebook is way more than
| that, but to think a page loading in 2-3 seconds is fast is
| something you could've gotten away with in 2000, but in
| 2020..? I genuinely don't understand why you find it quick.
| vbezhenar wrote:
| Almost every fast website works with that speed for me. I'd
| like microsecond speed, but when there are websites which
| truly take 10+ seconds to fully load, 2 seconds is fine. I
| think that for me 5 seconds is when I'm getting a little
| bit worried about loading speed, less than 5 seconds is
| acceptable. Hacker news works only a little bit faster.
|
| That said, I live in Kazakhstan and my typical ping to EU
| is 100 ms, so that might make my experience a little bit
| worse (it's 100 Mbps in theory). May be those who connect
| to those resources with 1 ms latency are getting much
| better typical experience, I don't know about that.
| Kinrany wrote:
| My guess is that Facebook is popular enough that they are
| not optimizing for first impression.
| disgruntledphd2 wrote:
| That's true, but they (apparently) _used_ to care deeply
| about how long it took you to post something.
|
| They've probably just accepted that consuming is more
| popular than producing, though.
| baddox wrote:
| 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 apps, and
| those seem to be widely panned on HN as having abysmal
| performance. They work fine for me.
| tincholio wrote:
| For me, it is decidedly slower and clunkier
| atlgator wrote:
| Advancing technology doesn't make up for destroying humanity,
| IMO. Fuck Facebook.
| aboringusername wrote:
| For me, I consider the real test for a website's performance to
| be how it reacts under JS disabled conditions. Using NoScript has
| completely changed the way I use the internet. Combine that with
| DoH and filtering and you can remove a large part of the jank
| that fills browsers needlessly.
|
| It's a delicate balancing act, but it puts _you_ in control.
| Sometimes it 's just not worth the hassle, and I suspect it's why
| you see many comments like "just read the f* article", except
| sites are so slow and cause so much rendering and CPU cycles it's
| just an abuse of the platform.
|
| Websites are capable of serving text without JS being required.
| Drip33 wrote:
| With increasing adoption of reCaptcha v3 which won't let you
| browse on any page without Javascript, it will become harder
| and harder to use the internet with NoScript enabled.
| encom wrote:
| I've tried several times to get used to NoScript, but there's
| just too much friction in day-to-day usage. I already get
| regular breakage due to agressive uBlock configuration.
| dopamean wrote:
| I don't think there's a single piece of software (if you can call
| facebook's website a piece of software) that I've used longer
| than facebook.com. I was one of the earliest users in 2004 and
| have had an account the entire time. It's really interesting, in
| sort of a morbid way, to see how it really has become a shittier
| experience every year. I'm sure it's hard to get right and I
| wouldn't claim to know better than them but it is quite amazing
| that they have so many engineers being paid so much money and the
| product from a usability standpoint manages to get worse. I
| really think that will be their ultimate downfall one day.
| aylmao wrote:
| 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
| management, frontend/backend separation, with an API in between,
| modular application structure, etc).
|
| Apps don't load in 10ms, but they also can support some offline
| functionality given their independence from the server.
| Overriding browser behaviour and managing your own loading
| behaviour makes sense, because the default browser behaviour is
| not the experience you're striving for; it's not the app
| experience. These people are usually those who have worked on
| large web projects too-- the developer experience that web
| developers have built for themselves in "userland" (JavaScript)
| is pretty good, and has evolved a lot to have features that makes
| developing the exact behaviour you want easier, and correctly
| iterating on a codebase, quicker.
|
| A separate school of thought wish websites stayed true to their
| origins as enriched documents, and think trying to evolve them in
| the direction of applications is counter-productive to their true
| purpose as interactive surfaces to get and send information. If I
| am just going to scroll and see a few pictures, why do I need to
| download anything other than the structure of the page and the
| pictures themselves? If all the building blocks are already
| there, in the browser, why do people need to re-invent them and
| ship them as yet more JavaScript?
|
| What should a website be though? The fact there isn't consensus
| about this is indication that there really doesn't seem to be a
| clear answer.
|
| Per the document-like school of thought, facebook.com just keeps
| straying further and further away from the ideal, but as far as
| as the app-like school of thought goes, the new facebook.com is a
| pretty remarkable achievement.
| saagarjha wrote:
| You can make a single-page app that isn't bloated.
| gfodor wrote:
| 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.
| aylmao wrote:
| > 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 receiving information with friends and the world,
| yeah, it hasn't changed much.
|
| Facebook today offers a richer experience 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.
| tarsinge wrote:
| 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.
| kungato wrote:
| 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
| toast0 wrote:
| > 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.
| ng12 wrote:
| 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.
| nickbauman wrote:
| Tech stack? This is only stuff they put in the browser.
| suyash wrote:
| exactly it's missing all the backend information which is most
| critical.
| didibus wrote:
| I understand the new stack is React + Relay, but what was the old
| stack?
| ajayyy wrote:
| It looks a lot like the new Twitter. I guess the new trend is
| just to show multiple tabs from the mobile app at once as the
| desktop site.
| shp0ngle wrote:
| I don't get the hate for the new Twitter, to be honest. It
| loads fast, is simple, it's to the point.
| garaetjjte wrote:
| It's slow, requires JS, and fails around.. 50% of loads, I
| think?
| dbbk wrote:
| It obviously does not fail on half of loads.
| shp0ngle wrote:
| ok I guess YMMV. It doesn't fail for me, so I guessed it's
| like that for everyone.
|
| everything requires javascript nowadays, that's just a
| default
| f1refly wrote:
| "Oh there's radioactive material in every food now, why
| would you complain about that? That's just a default."
| buboard wrote:
| it is yahoo from the 90s
|
| https://cdn.searchenginejournal.com/wp-content/uploads/2006/...
|
| Nothing new under the sun
| npongratz wrote:
| The Yahoo I knew and loved from the 90s manifested as a web
| directory:
|
| https://www.ttcs.tt/wp-content/uploads/2014/09/screenshot-
| of...
| ViViDboarder wrote:
| Wow. That made me way more nostalgic than I was expecting.
| atestu wrote:
| That's their redesign from 2006
|
| https://techcrunch.com/2006/07/17/new-yahoo-home-page-
| goes-l...
| cat199 wrote:
| interesting to see these kinds of details, but this is hardly
| 'rebuilding the the stack' - just UI<->API layer
| swyx wrote:
| there is such a thing as a frontend stack
___________________________________________________________________
(page generated 2020-05-08 23:00 UTC)