[HN Gopher] LightSpeed: Rewriting Messenger's codebase for a fas...
___________________________________________________________________
LightSpeed: Rewriting Messenger's codebase for a faster, smaller,
simpler app
Author : moneil971
Score : 161 points
Date : 2020-03-02 17:23 UTC (5 hours ago)
(HTM) web link (engineering.fb.com)
(TXT) w3m dump (engineering.fb.com)
| jconley wrote:
| This is an interesting business decision. To rewrite such a large
| app must have cost a fortune. Going full native is probably going
| to increase the cost of future development as well. Aside from
| the costs of writing/maintaining the code, pushing more work to
| the servers is an ongoing cost. Realtime, always-connected, apps
| are costly to run even when you push the majority of the state
| management to the client and just route packets around. They must
| really want eyeballs in their messenger app! There must be some
| future plans for this app that warranted such a major effort.
| Taking on Tik-Tok, perhaps?
| jcelerier wrote:
| > To rewrite such a large app must have cost a fortune. Going
| full native is probably going to increase the cost of future
| development as well.
|
| it's a freakin chat app, and it's freaking facebook ! come on,
| people were doing full rewrites in entirely different languages
| of software insanely more complex than fb messenger back in the
| 90s and with near-zero tooling, eg from cobol to pascal to C or
| similar horrors.
| jconley wrote:
| I've built a few "chat apps". I wouldn't discount the
| complexity. They carry with them a wide array of problem
| spaces. And of course anything at FB scale user counts is
| going to be a challenge.
| Turing_Machine wrote:
| While I have absolutely no doubt there are scalability
| problems, it seems to me that most of those problems are
| going to be (or should be) on the back end, not in the
| client. How is the _client_ 1.7 _million_ lines of code?
| jconley wrote:
| I can see it. It's pretty easy to hit that much code when
| you include your own code for things as trivial as a JSON
| parser rather than leveraging what the native SDK
| provides (which was alluded to in the article). It sounds
| like they had a bit of Not Invented Here syndrome going
| on and this rewrite addressed a lot of that. It also
| sounds like they had a bunch of systems (probably
| different teams even) doing similar tasks like
| synchronizing state. And they also had their own UI
| framework. All that stuff adds up to a lot of code. But,
| all that being said, it still has a ton of features. It's
| not your father's IRC client sending text around and
| failing to transfer files through NAT/firewalls.
| Turing_Machine wrote:
| > But, all that being said, it still has a ton of
| features. It's not your father's IRC client sending text
| around and failing to transfer files through
| NAT/firewalls.
|
| Meh. It displays text, pictures, and videos. That's about
| it. This is just Messenger we're talking about here, not
| the full-blown Facebook app. The only state to keep track
| of is "Have you received message UUID?".
|
| > And they also had their own UI framework.
|
| This is where I suspect the bloat occurred.
|
| Writing your own JSON parser and so on doesn't add up to
| any 1.7 million lines of code.
| ajconway wrote:
| Well, browsers just display pictures and text, yet to
| build Chrome one needs to download gigabytes of code.
| Databases just keep an ordered list of records on disc.
| Compilers just look at the code and produce another code.
| Web servers only need to accept connections and respond
| with some data.
|
| Image editors are the simplest -- they just let you paint
| with colored pixels.
| benbristow wrote:
| Just downloaded the latest update on my iPhone XR. Does seem a
| lot more snappy and I'm loving the recent UI/UX changes too,
| especially the sending photos & GIF changes.
|
| Good work Facebook!
| Priem19 wrote:
| A great way to speed up the pace to their next scandal.
| https://www.quitfacebook.org
| aldanor wrote:
| So, they've reduced 1.7M lines of code to 360K. Let's pause here
| for a moment:
|
| - NumPy is 360K lines mostly C
|
| - Postgres is around 2.1M of C
|
| - Go 1.13 is around 1.5M of Go code
|
| - Rust 1.37 is around 1.2M of Rust code iirc
|
| - core llvm is around 3M of C++ iirc
|
| ...
|
| A chat app is 1.7M. A chat app...
|
| Makes me feel sorry for all the time spent/wasted by all those
| devs, many of whom are unquestionably brilliant and could've
| worked together on something truly awesome, big and useful. But
| we all know that doesn't pay the bills and so here we are.
| lwb wrote:
| Honestly, a chat app that 1 billion+ use per month that
| includes payments, camera effects, extensive social
| integrations, stories, GIFs, reactions, games, polls, voice
| recording, calling, video chat, and works across all mobile
| platforms, with nine years of technical debt, that thousands of
| developers build simultaneously seems WAY more complicated to
| me than any of your examples.
|
| Messenger may not have "HN clout" but the devs who work on it
| are having some of the greatest software impact in the world.
| brundolf wrote:
| > that includes payments, camera effects, extensive social
| integrations, stories, GIFs, reactions, games, polls, voice
| recording, calling, video chat
|
| To be fair, this is part of the problem ^
| derefr wrote:
| It's an inner-platform effect, certainly, but not one FB
| asked for. If they were allowed by the app-stores to factor
| their app into separate "plugins" that were auto-installed
| when a friend used them in a chat, the way iMessage does,
| they'd probably do that. But they're not allowed to have
| their own seamless plugin ecosystem, so into the monolith
| everything goes.
| brundolf wrote:
| No, they specifically used Messenger as a way of pushing
| all of those different things on its massive install-
| base. Anything that distances them from the user in any
| way would compromise on that objective.
| A4ET8a8uTh0 wrote:
| While I understand the sentiment, you are making an assumption
| here that all messenger is a chat app. It seems excessive ( and
| it is ), but you don't know what kind of heavy lifting is being
| done under the hood.
|
| I am not really defending it, but number of code lines alone is
| not a good way to evaluate code.
| greenshackle2 wrote:
| All these programs have textual interfaces only (as far as I
| know).
|
| Having a GUI doesn't justify 1 million+ LOCs, but just for a
| sanity check, pgAdmin 4 has ~260k LOCs, without counting its
| dependencies.
| moron4hire wrote:
| I have a set of code I use for my VR projects that I've been
| iterating on over the last five or so years. It includes a ton
| of not-VR stuff, too, just stuff that I tend to include in my
| projects. (aside: and I'm not trying to make it a "framework".
| It's just my own code and it's only publicly available in the
| sense that I don't charge for it, don't want to waste a private
| Github repo on it, and won't stop anyone from using it, but I'm
| also not going out of my way to teach them how to use it).
|
| THAT code, my "all encompassing, personal repository for every
| VR app I'd ever make", is only 100K lines of code.
|
| I once downloaded all of my dependencies and counted all of
| those lines and still only got to 200K. Well, not counting
| Unity. But at that point, you might as well start counting the
| LoC of the OS.
| notyourday wrote:
| It's a chat app that works _very well_ even on the crappiest
| connections.
|
| If it having 1.7M lines of code indicates anything it is that
| creating a "simple app that provides simple functionality over
| a network well" is _hard_.
|
| Look at the garbage generated by Google - text messages and
| images on Google hangout are not guaranteed to arrive in order
| ( or even be sent in order ) unless you are on a _great_
| network.
| yodsanklai wrote:
| > It's a chat app that works very well even on the crappiest
| connections
|
| Does it? I routinely use Telegram, Line and Messenger.
| Messenger is without contest the one that gives the most
| trouble.
|
| I've been using chat apps at least since ICQ (1996) and
| sometimes I feel the user experience has declined.
|
| That being said, I'm sure that a lot of progress have been
| made and that there's a lot going on behind Messenger in
| terms of security and scalability. I'd be curious to know
| what's hidden between the millions LOC.
| notyourday wrote:
| In my experience in places where connectivity sucks (barely
| able to get data handoffs between stations, sticky wifi,
| etc) messenger kicks ass while the other applications hick-
| up big time.
| derefr wrote:
| > I've been using chat apps at least since ICQ (1996) and
| sometimes I feel the user experience has declined.
|
| You never used ICQ over a spotty 3G connection, though, did
| you?
| pathseeker wrote:
| Ordering messages and providing reliability does not require
| 1.7M lines of code.
| notyourday wrote:
| Code wins arguments. FB messenger beats everything,
| Whatsapp, Wire, Signal, WeChat, Telegram included, in the
| suckiest network connections.
| ringzero wrote:
| Repeating a point without adding proof doesn't make your
| point more valid. When people say "code wins arguments",
| they're referring to _using source code to prove
| something_ , not "it wins because it has more source
| code" (???).
| notyourday wrote:
| People say "Code wins arguments" because written code
| that works demonstrates the winning argument against the
| code that is either not written or does not work.
|
| FB messenger exists and works on crappy connections.
| Google hangout exists and messes up on crappy
| connections. Telegram exists and messes up on crappy
| connections ( see the issues it has in Africa ). Signal
| exists and does not work well even on non-crappy
| connections. Whatsapp exists and sort of works on crappy
| connections. Matrix exists and sucks on crappy
| connections.
|
| What we need is something that exists and works on crappy
| connections that has less LOC than FB messenger to
| demonstrate that it is possible to handle crappy
| connections and modern messaging in much fewer lines of
| code.
| abhia wrote:
| I'm fairly certain that they also included third-party
| libraries in that 1.7M.
| greenshackle2 wrote:
| It seems you are correct:
|
| > We also used quite a few of the OS libraries, including the
| JSON processing library, rather than building and storing our
| own libraries in the codebase.
| bytematic wrote:
| Sometimes making something simple is harder than making
| something complex
| ardit33 wrote:
| it seem you don't have experience on large scale apps... and
| the people that make these type of comments almost never have
| had to work on large applications.....
|
| Spotify had about 500k, lines of code in 2015, (not including
| external libraries).
|
| We did make it in a feature based architecture, where there was
| a main container app (and a major core playback library) and
| for every major feature they had their own sub-project.... and
| there were 10+ teams contributing into it.
|
| There were about 13 features at the beginning, (think,
| playlists, radio, shared ui libraries, etc...).
|
| Each feature was about 10-20k lines of code in total. So, about
| 2-3 features equal a small standalone iOS app.
|
| When I left, there were more than 80 features in the app. Some
| were essential, many were a/b tests, and some were probably
| just legacy/waiting to be removed.
|
| 80 features * 15k lines of code = 1.2mil loc, easily, and they
| are the equivalent of shipping 20 small apps standalone....
|
| What are these features and why is just a stupid music app so
| large? : video, podcasts/shows, genius, etc.. etc.. etc.... To
| users just looks like another tab but almost every one of these
| major features could be its own standalone app for size and
| complexity.
| wodenokoto wrote:
| I would love to read more about why large apps are so big.
|
| I currently work on a project that is much larger than I
| would expect it to be, both in terms of codebase and people,
| and while I don't know who to jank, I also don't understand
| why it has to be so big.
| dlsso wrote:
| They said they reduced code 84% but the numbers they gave are a
| 79% reduction. If they're using different metrics they should
| explain.
| gagabity wrote:
| Keep seeing react native pop up in the comments, there has never
| been any indication that Messenger used any react native from fb
| feom all their presentations I have see . RN is used in the
| Marketplace tab on the Facebook App, the Ad manager app and a few
| other places.
| z3t4 wrote:
| Once you are several years into a software project, everything
| feels like a weekend project, you somehow lost all sense of time-
| cost/benefit...
| AWebOfBrown wrote:
| I thought Messenger was ReasonML's flagship use-case inside
| Facebook. If so, it will be interesting to know what impact this
| has on its development.
| rashkov wrote:
| I think that's just for their web app / browser version
| BooneJS wrote:
| Sounds neat, but I'll continue to use "request desktop website"
| on mobile safari in a vain attempt to prevent running whatever
| else this app does besides chat.
| ckdarby wrote:
| It'll suck for the SEO team at LightSpeed point of sale company.
|
| FB named a open source project the same name as a company.
| pbhjpbhj wrote:
| I don't know if it's clear it will suck? You just advertised
| their company, it's the first time I ever heard of them. It's
| not like LightSpeed is an unheard of name? It's a stock trader,
| web filter, data warehousing company, and probably a million
| other things. Novel names are hard to come by.
| [deleted]
| mcphage wrote:
| It's a common english phrase, as well as a scientific term.
| There are a lot of things named after light speed.
| atrilumen wrote:
| ( It's not an open source project; just a codename for the
| rewrite. )
| throw03172019 wrote:
| Does having 40 contact screen designs seem normal?
| listsfrin wrote:
| Too little and too late. I feel like they lost a whole generation
| of people.
| pbhjpbhj wrote:
| Depends, if they allow WhatsApp and Facebook to
| intercommunicate through it, then they could get 100M people
| using it by next week.
|
| I'm not quite sure why I need two apps on my phone for
| communications through one company when 12 years ago I had one
| app on my desktop for 5 or 6 different company's messaging
| services.
| thehappypm wrote:
| I tried to use FB Messenger for a group thread for a ski trip,
| and I got a resounding "ok boomer".
| jascii wrote:
| Old joke:
|
| Every program can be (memory)optimized by at least one byte and
| has at least one bug in it.
|
| It therefore follows that every program can be reduced to a
| single byte that doesn't work.
| WhyNotHugo wrote:
| I don't know anyone who uses Messenger, yet, I've heard of people
| moving to specific countries where it's the de facto and you
| can't have a social life without it.
|
| I'm also aware of how iMessages and SMS are used in the US, yet
| this is very US-specific, and I don't believe any other country
| uses SMS.
|
| For Chinese people, WeChat is the standard, and what pretty much
| anyone uses.
|
| In Argentina and the Netherlands (and I believe much of the EU),
| WhatsApp is ubiquitous.
|
| Yet, I don't know a single person who uses either SMS or
| Messenger, or iMessages.
|
| So what truly fascinates me, is how different companies put so
| much work into developing such sophisticated messaging apps, but
| they're all reinventing the wheel and each consumed in different
| regions -- I think nobody would have guesses years ago that we'd
| have so many different apps used in different countries, and not
| at all inter-operating with each other.
| pottertheotter wrote:
| I'm in the US. SMS / Apple Messages seems to be the default for
| everyone I interact with. I use Messenger sometimes, but
| usually only when someone else initiates.
|
| My favorite is using Apple Messages since I can send/receive
| from any of my Apple devices. I use macOS for other reasons,
| but being able to send a text from my computer is awesome.
| jianshen wrote:
| Did you ever use AIM, ICQ, MSN, Y! Messenger? I'm quite certain
| that in a decade, there will be another batch of dominant
| messengers "reinventing the wheel" (IG & TikTok I'm looking at
| you). Real-time Communication is just such a crucial part of
| people's lives that people will never stop working on it, even
| if it feels like it's been solved.
| Thorentis wrote:
| I still aren't 100% sure what they're using Sqlite for? Are they
| storing templates as blobs? Are the storing template logic in the
| table? How did that make things faster? Anybody who has more
| detail care to explain?
| NoodleIncident wrote:
| It sounds like the entire client-side state of their app is in
| SQLite
| jandrese wrote:
| This seems like an incredibly low bar to hurdle. FB Messenger on
| iOS is legendarily bloated. In the couple of weeks I had it
| installed it also managed to be the biggest battery drain on my
| phone, even more than some 3D games.
| chundicus wrote:
| Low bar or not, they had to rewrite the entire app to get those
| gains. I think it's still technically impressive.
| beatgammit wrote:
| Is this incompetence or aggressive data mining? I fail to see
| how a texting client is that complicated...
| jandrese wrote:
| Have you seen how much memory and CPU time Signal uses on the
| Desktop? Or Slack? The era of running a chat app for almost
| no resources is gone unless you're an IRC holdout.
| pier25 wrote:
| > Have you seen how much memory and CPU time Signal uses on
| the Desktop? Or Slack?
|
| Aren't those using Electron?
| saagarjha wrote:
| I think that's the point.
| pier25 wrote:
| Right, but if Messenger is not using Electron why is this
| related?
| MikusR wrote:
| All of those are chat apps.
| solarkraft wrote:
| And bloated. And using web technology. Wonder whether
| those are related.
| [deleted]
| MikusR wrote:
| Or Telegram.
| adonese wrote:
| i use telegram web and it is awesome. Messenger web just
| sucks, i don't why actually, maybe it is because of the
| design. I have not checked the others (signal, wechat).
|
| tl;dr web clients are probably more performant than their
| electron counterpart
| MikusR wrote:
| I mentioned Telegram because the desktop version does not
| use electron. It's a QT application and is small and
| fast.
| crocodiletears wrote:
| I think they went through a period (or still are, I honestly
| moved over to messenger lite a couple months into it) where
| they were seemingly intent on making messenger the WeChat of
| the west. It got real chunky real quick. It was around the
| same time everyone was excited about conversational ui and
| Microsoft announced their bot framework.
|
| It may have been slow and bulky before that, but that's when
| I started to notice.
| monocasa wrote:
| They were trying to make it the WeChat of the non china
| east and africa, not the west. And they've been pretty
| successful at that, "messenger" is almost synonymous with
| "Internet" in some parts.
| crocodiletears wrote:
| I wasn't aware, but honestly quite happy they succeeded.
| A lot of the extra features they were adding seemed
| pretty out of place for my local market, but they
| definitely put a lot into it.
| kyawzazaw wrote:
| definitely. Facebook is the internet in my home country.
| But still lots of Messenger features were not used. So
| still bloated. Not that anybody complained or moved away
| from it.
| abraxas wrote:
| Those things literally put up some text and an occasional gif
| and a scrollbar.
|
| It's unreal, our industry has lost its mind.
| [deleted]
| [deleted]
| im3w1l wrote:
| Consider two competing apps. One looks 5% nicer but uses
| 1000% more memory, cpu and battery. That one will be
| preferred by users. And this is why things are how they are.
| TazeTSchnitzel wrote:
| Looking pretty is hardly that expensive.
| im3w1l wrote:
| If you know exactly how you want your app to look
| forever, sure. But you don't. So you want a flexible app
| that can easily be redesigned. And that means
| prioritizing developer comfort very high. Which means
| bloated frameworks.
| djsumdog wrote:
| I wonder if this will break libpurple-facebook or the Matrix-
| facebook-bridge
| buboard wrote:
| how does one manage to make a _chat_ app bloated in 2020?
| ycombonator wrote:
| Abstraction craze. React Native etc etc.
| gigatexal wrote:
| SQLite does it again! I love that they're using it for internal
| state management of the UI
| ronald_dregan wrote:
| Yea, but it's still Facebook Messenger, so it's trash.
|
| If you use Facebook for any reason, you are stupid and I do not
| respect you.
|
| Fuck Facebook, fuck everybody who works for them in any capacity
| (to the HN people who work there - re-evaluate your life choices,
| scumbags), fuck everybody who uses their products and services.
| You are all objectively contributing to the world being a worse
| place.
| [deleted]
| Doctor_Fegg wrote:
| Here's a way in which they can save 100% of the size: Stop
| stubbornly barring mobile clients from using the web interface.
| This is why I don't use Facebook Messenger at all.
| thepangolino wrote:
| For some reason I can access the chat using Firefox Mobile on
| iOS but not through Safari.
| kreetx wrote:
| I used mbasic.facebook.com for a while when it was not
| possible to use it from the regular mobile web. But for like
| a year or something they appear to have turned the web back
| on (at least for firefox, haven't tested anything else).
| wilkystyle wrote:
| If I request the desktop site, I am able to access Messenger
| (iOS, Safari)
| joking wrote:
| That's a workaround for a on purpose decision to cripple the
| mobile website, where the chat and messages worked
| flawlessly. Another decision against users was to use
| messages as notification in some cases.
|
| I didn't pull the trigger on canceling the account as from
| time to time I find news and event from pages that I follow,
| but there's no way I'm installing an app that uses so many
| shady tactics.
| monocasa wrote:
| Yeah, I do that in firefox mobile as well.
| skizm wrote:
| mbasic.facebook.com
| monocasa wrote:
| But then they don't have permissions to slurp up all of your
| contacts, watch all of your SMS, and listen to your
| microphone...
| Scapeghost wrote:
| I really wish iOS would allow you to select which
| contacts/photo album to give an app access to, instead of all
| hundreds/thousands of them.
| DelightOne wrote:
| Maybe group-based, and some apps only get the selected.
| alpaca128 wrote:
| I wish Android/iOS would let the user decide individually
| on every single file/contact/etc access, at least in an
| optional setting.
|
| Would be interesting to see how many seemingly harmless
| apps start to break, I would expect similar results to
| surfing the web with a JS blocker.
| amarshall wrote:
| For photos, I wish iOS would not require a permission at
| all in the case where I just want it to open an OS-
| controlled file picker and then give the app the one photo,
| akin to copy-pasting it. No reason to give access to every
| photo when only N are picked.
| kitsunesoba wrote:
| It's been a while since I worked with the photo library
| APIs in iOS, but as I recall there in fact _is_ an API
| that apps can use to request the user to pick individual
| photos from an OS picker without further permissions.
| Most apps just don't use it because they all want to do
| their own custom photo picker UIs (even privacy focused
| apps fall victim to this).
| MikusR wrote:
| Wait! Somebody found evidence of them listening to your
| microphone?
| pbhjpbhj wrote:
| Well I have messenger lite on Android and they, as the
| parent says, "ask permission to listen to your microphone".
| Presumably they do voice chat, which needs that permission,
| surely.
| lord_braleigh wrote:
| Still no. If an iOS app is using your microphone while
| backgrounded, your phone's taskbar at the top of the screen
| will be red. iOS does not allow apps to use the microphone
| while the screen is off. The microphone thing is a myth
| fueled by paranoia and confirmation bias. FB already has
| plenty of data on you and doesn't need to run NLP on
| everything you say in order to show you relevant ads.
| monocasa wrote:
| > iOS does not allow apps to use the microphone while the
| screen is off.
|
| Isn't the screen off in nearly all of the legitimate uses
| of a microphone, ie. "I'm replicating the ux of a phone
| call in my chat app"?
| moron4hire wrote:
| Do they still block use of the web UI for Messenger in mobile
| browsers, unless I check "show Desktop version" in my browser
| settings?
| dean177 wrote:
| > We extended SQLite with the capability of stored procedures,
| allowing Messenger feature developers to write portable,
| database-oriented business logic
|
| I wish the article was a little more fleshed out, I'd be
| interested in finding out more about how and why they went down
| this path
| kreetx wrote:
| I just listened to the Changelog's (a podcast) episode with
| Richard Hipp, the author of SQLite -- I wonder if he had any
| part on this extension. But in any case, great to see SQLite
| thrive.
| SQLite wrote:
| I did not. This is the first I've heard of it.
| Legogris wrote:
| I have to ask, did they pay the 6k license fee yet?
| jpeeler wrote:
| Wish they had gone into more details about the budgets. Unless a
| project is bug fix only for life, how can one set a binary size
| or lines of code upper limit? I've heard that the best developers
| delete more than they write, but in practice I don't think that
| happens that often.
| butz wrote:
| The loop of app building: 1. Build app with native framework. 2.
| Re-build app with some alternative framework which is slower, but
| let's you deploy single code on all platforms. 3. Re-build app
| with native framework, because it is faster. 4. GOTO 2
| keyle wrote:
| 1. Developers: YEP! 2. Developers: YEP! 3. Developers: YEP!
|
| Munch Munch Code Munch WTF Munch AGILE! $$$ Munch.
|
| Designers: 1. We need a new design system. 2. We need a new
| brand! 3. We need a new font!
|
| Users: -\\_(tsu)_/-
|
| /s <3
| tomaszs wrote:
| Perfect :)
| robofanatic wrote:
| Mainframe -> Native Desktop apps -> Web apps -> Native Mobile
| Apps -> Mobile Web apps
| [deleted]
| beefield wrote:
| Assuming one hates notifications, is there _any_ reason why
| anyone would want to use app over m(basic[1]).facebook.com?
|
| [1] to access messenger because fb stubbornly thinks I want to
| install their crap/spyware on my phone
| ajconway wrote:
| Nice UI and OS integration -- that's precisely why native apps
| exist.
| miloignis wrote:
| I think some things do not show up on the mobile pages -
| reactions and polls, I believe - maybe stickers? I'd also have
| to check if replies show up correctly
| solarkraft wrote:
| To me a lot of the new architecture just seems obvious (don't
| keep the same view 40 times, don't invent your custom app
| specific everything ...) and I really wonder how the original
| project could derail that far. Too many resources? Institutional
| bloat?
|
| That said I find it a bit heart warming that all the major apps
| are now between 1/2 and 1/4 the size of what they were just a few
| years ago. I didn't expect the tech companies to ever realize the
| problem with insane sizes. Is a similar debloating happening to
| Electron apps?
| monocasa wrote:
| Considering that they were shipping 18,000 classes in their iOS
| app back in 2015, a quarter the size of their 2019 app has to be
| still unreasonably massive.
|
| https://gist.github.com/quellish/473f513fbd1310233a8e
| LennyWhiteJr wrote:
| The number of classes isn't necessarily indicative of the size
| or complexity of an app.
| myko wrote:
| That's Facebook proper not the Messenger app
| llovan wrote:
| RIP React Native
| cbhl wrote:
| It looks like polls aren't yet implemented in the rewrite?
| manigandham wrote:
| Facebook's video player experience is absolutely terrible.
| millstone wrote:
| From https://engineering.fb.com/data-infrastructure/messenger/:
|
| _Rather than reinventing the wheel, we used the UI framework
| available on the device's native OS to support a wider variety of
| application feature needs. This reduced not only size, by
| avoiding the need to cache /load large custom-built frameworks,
| but also complexity. The native frameworks don't have to be
| translated into sub-frameworks. We also used quite a few of the
| OS libraries, including the JSON processing library, rather than
| building and storing our own libraries in the codebase._
|
| This is awesome. It shows the benefits of building an app
| leveraging the OS, instead of fighting or abstracting it.
| reaperducer wrote:
| They make it sound like the clouds parted and a ray of sunshine
| struck the programmers at Facebook and they realized that they
| didn't have to ride the framework-go-round to hell.
|
| These are supposed to be the smartest people in SV, but from
| the outside, it strikes me more as a "No shit, Sherlock"
| moment.
| wilg wrote:
| I suppose that makes _you_ the smartest person in SV!
| m0zg wrote:
| >> These are supposed to be the smartest people in SV
|
| They might just be. Everyone else is cargo culting on React
| Native and the like.
| karatestomp wrote:
| Which, for example, gets you more sway with your employer,
| personal "branding" value, and future income / ease of
| switching jobs: "I was instrumental in inventing React"
| versus "I was instrumental in realizing we didn't need to
| invent React"?
| saagarjha wrote:
| "I was instrumental in making Messenger twice as fast?"
| karatestomp wrote:
| Well yeah, but first someone has to get the credit for
| creating some "high-productivity" hog of a framework to
| make it slow, _then_ someone else can come tear all that
| crap out and claim they made it fast.
| bobbylarrybobby wrote:
| Why not be both people? "I made React _and_ I made
| Messenger twice as fast [by ditching it] "
| reaperducer wrote:
| I guess it depends on if you frame it: "I was instrumental
| in adding complexity under the false promise of ease of
| development" versus "I was instrumental in saving the
| company time, money, and improving the product for our
| users."
|
| Things like this are why I'm glad I'm not in the bubble
| anymore.
| brundolf wrote:
| A similar philosophy can often be applied to the web
| 1023bytes wrote:
| So it's basically MVVM with SQLite as the model?
| reggieband wrote:
| From: https://engineering.fb.com/data-infrastructure/messenger/
|
| > We accomplished this by using the native OS wherever possible
|
| Does this mean this application does not use React Native?
| taeric wrote:
| I can't decide if seeing the pendulum swing that drastically
| would be hilarious to see, or not.
| pier25 wrote:
| > _We also embraced platform-dependent UI and associated
| tooling_
|
| It would seem that way.
| esistgut wrote:
| Did the previous application use React Native?
| layoutIfNeeded wrote:
| Wow! So the OS frameworks are there for a reason? Who would
| have thought?!
|
| Mind = blown!
|
| One can only hope that Slack and other Electron apps reach this
| point eventually...
| gigatexal wrote:
| The place that invented it not using it would be huge
| tomduncalf wrote:
| React Native isn't necessarily a great fit for something that
| is intended to be "a simple, lightweight utility" - there is a
| reasonable start up overhead, for example, with RN, and it also
| involves bundling quite a few libraries and dependencies.
|
| That doesn't mean React Native is not a good fit for any kind
| of application - for many kinds of apps, start up time and app
| size are a much smaller issue - but seems Facebook made the
| right decision for an app like Messenger which primarily needs
| to start fast and drain as few resources as possible.
| freepor wrote:
| React Native (or any framework) isn't good when you can
| literally afford billions of dollars of R&D given the
| financial value of the app. Just like the Mars rovers don't
| run Python but it is a great language for a experimental SaaS
| app testing a new market, RN is great for a team of 3
| engineers to get a multi platform app shipped, but not a
| great choice for an app worth ~$100 billion to its parent
| company.
| kreetx wrote:
| Interestingly, there was news on some satellite running
| javascript. But I wonder if the core was running something
| else, and peripherals were run with js -- and simply
| restarted when they died, Erlang style.
| pier25 wrote:
| Exactly. The point of using a cross platform solution is
| because you can't afford to make an app for each platform.
| bmj wrote:
| Yeah, that's how I am reading that.
|
| Given the headaches caused by Apple finally barring UIWebView
| (the basis of frameworks like Cordova) from new App Store
| submissions beginning in April, I'm not surprised FB would do
| this. There is plenty of rumor-mongering that Apple is going to
| make it increasingly difficult for apps based on hybrid
| frameworks through the submission process.
| Klonoar wrote:
| UIWebView was deprecated for years, everyone's had plenty of
| time to move to WKWebView, and it has nothing to do with
| React Native to boot.
|
| Apple legitimately doesn't seem to care about hybrid
| frameworks, they've been there since day one. Any time it's
| seemed like it got difficult Apple has backed down. The lack
| of JIT in WKWebView is probably the only thing that you could
| stretch here.
| Turing_Machine wrote:
| Printing still sucked pretty bad in WKWebView the last time
| I looked into it (which admittedly has been a year or two,
| so maybe that's been fixed).
| saagarjha wrote:
| WKWebView is out-of-process and has a JIT.
| Klonoar wrote:
| Ah, you're correct - not sure why I thought otherwise,
| especially when I touch WKWebView pretty often.
| pier25 wrote:
| React Native doesn't use a webview.
| Turing_Machine wrote:
| > Given the headaches caused by Apple finally barring
| UIWebView (the basis of frameworks like Cordova)
|
| Cordova (and derivatives, such as Ionic) have had WKWebView
| available for a long time now, I think since iOS 9.
|
| The Cordova team added a compile-time flag to force WKWebView
| in 5.1.0 (out since last November), and will be removing
| UIWebView altogether in 6.0.
| ryandvm wrote:
| Man, I hope so. There has beens so much cargo cult built up
| around React Native that suggesting other approaches is almost
| guaranteed to kick off many rounds of contentious design
| meetings.
|
| Fortunately, nothing quite takes the wind out of a platform's
| sails like watching the creator back away from the platform.
| dang wrote:
| (Some of the comments in this thread, like this one, were
| originally posted to
| https://news.ycombinator.com/item?id=22467769, which explains
| e.g. why they mention the URL explicitly.)
| 1023bytes wrote:
| They definitely wouldn't be able to achieve these kinds of
| results with React Native. It obviously adds a lot of
| unnecessary overehad.
| on_and_off wrote:
| -step 1 : write an app with a multiplatform framework.
|
| -step 2 : rewrite it in native so you greatly improve metrics
| while reducing code base size.
|
| Seems like a good way to achieve great improvements in your
| product
| williamdclt wrote:
| If the step 1 allows you to get your product out more quickly
| and that has enough business value, I don't see why not
| brundolf wrote:
| I'm thinking maybe they moved _off_ of React Native. RN makes
| sense for a small org or for an app you 're just getting
| started with, but a megacorp like FB can afford to hand-craft a
| smaller, tighter app for each platform.
| kristianp wrote:
| There's no mention either way. The article talks about a single
| C library and C extensions. And it mentions using native OS
| functionality. Those could be used from javascript or any
| language.
| miki123211 wrote:
| Am I the only one who thinks 86mb for an app is about 86 times
| too much?
|
| Windows Messenger was about 900k. Sure, it only did text, but
| Skype wasn't that big either. I'd accept 20mb for stickers, givs
| and stuff but 80? And 300k lines of code? For a messaging app? It
| just seems... unreasonable to me.
| brundolf wrote:
| Was the previous one React Native? Seeing the talk about UI
| abstraction layers and given that this is Facebook
| ska wrote:
| Not sure how much impact this will have, most of the people I
| know and have discussed this with fall into two camps: people who
| use FB a lot an will put up with a bad mobile client, and people
| who don't want FB on their phone, ever.
|
| I have to go years back to think of someone who told me they just
| couldn't take the bad UX of the clients so they deleted it.
| solarkraft wrote:
| Well hello. I've stopped using Snapchat and started using
| Instagram for stories because the experience, while still not
| great, is about twice as good.
| monocasa wrote:
| It's probably not meant for us, but instead the third world
| phones where they've gotten to the point that it might not even
| install on a large part of their user base.
|
| Like I've heard from peace corps folk about how a large part of
| the third world thinks of messenger as "the internet", which is
| absolutely terrifying.
| solarkraft wrote:
| As someone with a modern smartphone I'm a huge fan of these
| lite apps.
|
| Spotify lite, for example, has all the features, a better (!)
| UI (with material ripples) and everything loads about twice
| as fast.
|
| Every app should be a lite app. Devs, please start giving a
| shit about performance.
| novok wrote:
| I've tried FB lite, and found it to be slower than the real
| app. FB lite seems to act like a fancy web browser, so each
| interaction needs to download it's UI along with content.
| ska wrote:
| Hadn't thought of that - good point.
| brundolf wrote:
| For a while, before it really started to bloat, FB Messenger
| was the slickest, most well-rounded, most enjoyable messaging
| client I could find, and had the advantage that all of your
| friends were already on it. The bloating from Stories and
| everything happened to coincide with my ejection of all things
| Facebook from my life, but Messenger was a genuinely good
| product at one point. Sounds like it may be returning to that
| (though unfortunately that ship has sailed for other reasons).
| machello13 wrote:
| Yep. In my high school and college days (2008-2016) Facebook
| Messenger was _the_ way that you chatted with other people.
| on_and_off wrote:
| I don't think that just because people don't complain about it
| it has no effect.
|
| re app size : Google has already published stats urging apps to
| optimize their size as much as possible since it has direct
| effects on acquisition.
|
| I suspect that long download times lead to more errors + more
| wait time before you can use the app = more likely that the
| user will abandon its current task and
|
| Same with slow app or ui patterns that don't fit with the
| platform = easier to lose users in the first crucial minutes.
| chadlavi wrote:
| tracking you everywhere you go is easier than ever!
| brundolf wrote:
| I'd be curious to see more details on how pub/sub works with
| SQLLite
___________________________________________________________________
(page generated 2020-03-02 23:00 UTC)