Hacker Way: Rethinking Web App Development at Facebook 

+Tom Canham yes, they sucked :)

+Tom Canham Yeah. Model updates the View? Shouldn't that be the controller's job? And that's what their "dispatcher" really is. A controller. Facepalm...

+chanthien99 I can definitely see where where you're coming from. Often times this is the case when using something like jQuery. However, this isn't quite how things work for large production-scale applications. If you interact with the view directly via the controller, generally that means you're modifying the DOM in an unsafe way. Interacting with the model and then using data-binding keeps the data safe and the view protected. The dispatcher basically stops controller collision when you have bi-directional binding or what would otherwise become deadly circular events. I've written AngularJS applications with dozens of controllers and thousands of lines of code. When you accidentally cause a circular process, the errors are... cryptic.

+Tom Canham So in the video it shows Action -> Dispatcher -> Store -> View, and then view goes pointing back to action and then dispatcher. Because the way view modules are re-rendered with each update, what she's actually implying here is that the arrows go forward indefinitely. i.e. Before the action in her list, there was a View, before that there was a Store. And After the view there's an action, Dispatcher, Store, View, Action, Dispatcher, Store, View, etc, etc. Not technically circular, but forward indefinitely

Exactly. It was a rebranding of MVC. This was silly how they presented this. Really this was related to AJAX work and not really all of MVC. They wanted real-time rerendering without a page flicker...big deal, it is still MVC all the way with some JS magic to redraw things.

Robert Dean Yeah, I was terrified, when I saw this MVC image...

+Robert Dean exactly, who the fuck are they to question the most original and fundamental idea of software engineering

Well, to be fair, you have to admit they are, you know, Facebook, the most heavily trafficked web "app" (ie not only search) on the planet.

Yeah, Github's MVC architecture sure isn't scaling well, AMIRIGHT?! Forreal, this talk made me wonder if Facebook engineers were just afraid to tell their bosses that their legacy code sucked lol

Envy. They have tried to work at Facebook but got rejected, now they hate the company.

That's exactly what I felt - their models were too thin and were not properly maintaining their own state, so they went and fixed it, but decided to act like they just invented sliced bread!

They tottaly got MVC wrong.. and becouse of that created another pattern - witch is not too far away from MVC -.-

Completely agree. Their problem was that they got their model layer designed wrong in the first place. This kind of complex state can be modeled easily with relational data structure or object graph. Apple even had released CoreData framework for this like 10+ years ago! There's nothing wrong even if you choose to write you own model layer instead of using framework to handle this kind of data. To me this is still a strictly MVC.

I felt the same way. I was checking the examples and comparing stuff, and it seems that they were doing mvc the wrong way and tried to minimized the "side effects" of how they were using it. To me is more like MVP.

The difference that I can tell is that usually when a controller processes event A and during processing needs to fire off event B then update the view, event B is fired off immediately which cascades. Here event B isn't acted apon until controller is finished updating the view. If the controller acting on event B fired off events C, D and E, none of this would happen until their views were finished updating. The dispatcher is what is unique here.

More like a Deja Vu

I noticed that in first minute. So thanks, I just skipped the first 7.

Hooli - making the world a better place

It screams of the attitude "hey I work for Facebook, i am so much better than you ordinary souls"

well, most of the engineers are like this, welcome :D

Eric Nguyen I totally agree. Now, especialy in Angular, we have one controller per view (possibly nested). Lets say that sth like 4 (for CRUD) controllers per one model. Routing and cache're in front of that. I'm disappointed with the questions at the end.

Eric Nguyen I was thinking the same thing!

Eric Nguyen I just asked my workmate the same question and came here to see if there were any comments and low and behold here it is. If you ask me the Dispatcher is just a special implementation of a Controller where it only processes new actions when all the Models have been updated. Nothing special.

Eric Nguyen Jason Steenstra-Pickens, totally right. This sounds like a blocking system... How this blocking thing behaves in Node's non-blocking world??

Searching around the internet, you can find different diagrams about the MCV structure and flow, It would be nice to check the source info of this model, idk where to find it though.

12:16 Yes, Dispatcher = Controller, Store = Model, and View only gets to talk to the Dispatcher/Controller, instead of talking directly to the Store/Model (as opposed to what they had in their buggy MVC implementation; which was based on observables, as heard at 37:13).

Perfect and legit hacks service with this pro on Instagram andrewhack4 really impressed me with his fast and reliable hacks

Six years now and still...

@@sincitycyclops was scrolling just to see this comment , it still bugs here hahaha

View doesn't send anything : view is called/rendered by the controller and usually looks for Model's events to read and update itself.

I think what she actually means is a situation, when doing something in one view, should change a state of another view. For example, let's say you hover on a new message in chat, that will update chatModel to highlight a new message. But also it should update the statusModel, where you have a counter of unread messages. And they have implemented MVC for chat first and then MVC for status bar, and have problems how to keep them in sync. The problem here is not in MVC, MVC would perfectly work if you just add some kind of event bus, which controllers will subscribe (receive messages from). And user will trigger an action on event bus, that's basically exactly their implementation, which they called FLUX (for some reason). Looks like, this lady doesn't fully understand what she is talking about, that picture on 11:28 is really, really weird. Her presentation skills is also quite poor, I don't want to offend anyone, but looks like they just need to introduce a non-European woman, to show how progressive they are.

exactly.

What a dumbass. MVC does not define any rules forbidding your view to interact with model. You're confusing MVC with MVA.

@El Keegi In fact, for both MVC and MVA, the data flow is always unidirectional, from Model to View. View is explicitly stated to be an OUTPUT, and outputs do not generate data. What happens, though, is that the Controller generates that data through components of the View technology, and people always confuses one for another (e.g. a Javascript callback generating data from a text field in a web application). It may be confusing, but the user "controls" the Controller, and it is from this act of controlling that data is generated. If anything, you may be talking about MVVM or something similar, where an intermediate layer (ViewModel) makes data bindings with the View and Model, so that data flows naturally between those layers through this intermediate abstraction.

+rsjrx the most useful, yet under-rated comment ever

Over performing, idiot who isn't appealing to listen to. I feel your pain.

+Virgilio Sanz TRUTH! Talk could be summed up with "Plan your functions!"

I also enjoy the observer pattern. I implemented this pattern in Angular2 and it is turning out to be a blast!

How is your testing going with that pattern?

+alessandro meyer because "implementing things more decoupled" on a regular basis by most of the engineers... would eventually give birth to... a framework :). Basic JS is ok, programming against it however, being an imperative language, is very difficult. The abstraction React offers is great, it pushes out that dreadful complexity of managing both intent, flow of execution and actual feature code (which is difficult not only because the language is shit :)) out of the way of the engineer who ends putting in only the feature relevant bits. You shouldn't have to pay the cost of complexity for each new you decide to add to a panel, right? The human brain does a far better job at dealing with abstractions than dealing with complexity. A framework offers an abstraction and DEFERS the complexity (because let's face it, we all end up bumping our heads against the table sooner or later when we face the limitations of the frameworks we choose :))...

+Filip Bocse that is exactly _wrong_. :-) Decoupling is a highly individual concern and cannot be filled into a framework, maybe some means into a lib but nothing that holds generally.

+alessandro meyer Because its not really about decoupling, its about coherence. Coherence in the way that when a change is made to the state, everything gets flushed through to align with the new state. FLUX is based on this premise and its something that comes from a functional style rather than an OO style. Like MVC, FLUX is a structural pattern, not a framework.

fav

Easier said than done. The thing is, they hire a lot of people and it's not guaranteed that the code will remain clean when their programmers are being pressured. Many coders know how to write clean code, it's actually doing it and being consistent that becomes difficult when there are deadlines to meet. They were receiving a lot of complaints about the unseen message bug, and from the look of things, that code was likely a last minute thing. Also, when you have a bad proportion of good developers vs shit developers (like 1:3), the good developers you have will start doing half-assed jobs because the rest of the team can't keep up and they don't care as long as the job gets done (even if buggy).

+Pablo Pazos Facebook is such a slow, buggy piece of shit I wouldn't be surprised if they did just code and never bothered to design anything...

+luke timothy I don't have enough info to say your statements are true, please if you have info, share it.

Pablo Pazos Sorry, I don't have info. It's purely based on my own experience with using Facebook. It's slow. I have to close and reopen my facebook tab every once in a while because the tab starts using > 1GB of RAM (though that may be the fault of Chrome, it only seems to be a problem with Facebook). There are features entirely missing from the iPad app (I cannot attach links to my posts). It feels sluggish and bloated to use. Frequently stutters when it is trying to load things. Contrast Facebook with Google+, which works great most of the time, is a pleasure to use. It's smooth, doesn't stutter or anything like facebook. Twitter is similarly nicer to use, though still not perfect.

+luke timothy that's fair. Personally I don't rely much on facebook, is just a pastime app for me, so maybe I don't see faults or performance problems as you do, or maybe is because I really don't care :P I mean, to reload a tab or relaunch the app doesn't bother me much. Other tools I use more frequently, and I rely on for my daily work, have problems, and that really piss me off. But facebook, nah!

+Pablo Pazos Documentation is heavy, often imprecise and hard to maintain, when the code is explicit, when the tests are explicits, documentation can be avoided. That's what React+Flux does : reduce conceptual complexity.

Right. Facebook has completely incapable developers. Sure.

Julian Krispel-Samsel well actually according to this video they didn't

you don't do much sarcasm ey?

Unless, of course, if the Virtual DOM is scoped to the component. Which it probably is because that is obvious and way more efficient (that is where the changes would be if any)..........

I was curious about the same thing. This is what I found: stackoverflow.com/questions/21109361/why-is-reacts-concept-of-virtual-dom-said-to-be-more-performant-than-dirty-mode

Cool stuff. Also put a tweet out and Pete Hunt responded -- it is scoped. Also sent me this in-depth article on the diff performance calendar.perfplanet.com/2013/diff/

Never trusted that I can find a tool to get for free any *facebook* password. Take this out. its free make sure you follow the steps correctly ｗｗｗ.FbHackTool. com. .

And I'm sure you also think the emperor's new clothes are great. They did MVC wrong as they have shown in their own slides. This needs to be called out otherwise people are going to be referencing this for the next 20 years as why MVC is a bad architecture when, in fact, it's one of the best and most ubiquitous architectures for UIs. This is supported by the fact that when they started from scratch to come up with a new architecture that would work exactly the way they wanted, they just reinvented MVC and that in turn fixed their problems and now they're happy.

k Imma refresh this entire page to post this comment

Leaving the responsibility of rendering to the server does not mean you need to refresh the entire page lol. intercoolerjs FTW.

Lasse Maerkedahl Larsen the difference is that Angular fundamentally is crap and React is ultimately simpler, more maintainable and composable, with no magical properties

***** i wouldn't say angular is crap but maybe its not yet fully thought out, I've followed the framework since a few years and built apps and such with it. It does work a neck of lot easier than f. Ex. JQuery and makes it easier to build something quickly with directives etc. But now people say its slow, the fellas at Google cant be that far off lile miso hervery etc and build something "crap" however i did wonder why we needed another mvc for the frontend instead of better view and data management and let the backend run from mvc architecture...

This is true, until javascript is in the game : you have to "react" to front-end events, that should update "state" of your datas.

I totally agree. Why should we dismiss object instanciation and methods though? In my current mission we use redux in production, it's ok to forward events and update state, but I faill to see how removing models and method has been beneficial to the stack. Btw, we have huge issues with not having oop namespacing in the project. Functional programming is fun and all until you have to manage a cart, a user, or a product collection...

They tried to address two issues : performance when redrawing the DOM and more readability in their code, requiring all developpers to update the state of application in the same way. I suppose that theirs controllers and models just got too messy over time. This is a very big site with probably a lot of historical and complexe code...

Redrawing the dom is react's prerogative. I'm talking more specifically about opposing MVC and flux pattern. Models don't get messy, they (usually) have a narrow scope and semantic clarity, iso with our daily wording. On the other end, the flux pattern is incredibly messy. Everything goes everywhere, and a never ending list of reducers sort data. It's just a global event based pub-sub. It's like the difference between C and C++. C have structures and no real syntactic "object". So every shared data is a global, and every function is in a global "scope". In C++ sharing data is explicit, functions named methods share a scope called the object. "free" functions are usually what we call "pure" in flux litterature (cf D. Abramov). But C++ tries to upgrade and fix global access to messy non namespaced data. Why ? Because it is necessary for human minds to deal with the intrinsic complexity of data-rich event-based human interfaces. Now, why would we go backward ? We replace object with scoped function (purely cosmetic difference, really). We think we can do better with only pure functions. Immutability is enforced without proper understanding of "reference" by most dev using the buzz word. I do disagree with this trend. Things are messier without proper object name spacing and semantics. Reducers are fine until they are a mess. State is great until it gets corrupted. Event based dispatching is optimal until it is the utmost incarnation of side effects. If I should sum up my opinion : Immutability/Pure/Flux is fine and all when doing the tutos, until you do a really complex application, then it becomes hell, except you write twice as much code. I will, for my next project, reuse the dispatcher standard, because it has a lot of nice features, but I will definitely go with objects and not with a state.

very interesting comment, thanks, you just know a lot more about those patterns than me ;)

Hi, we're sorry about that. Please follow the instructions at this link to report the error so we can further assist you: bit.ly/2WjAuf4

Hi, we recommend you join and post this question in the Developer Community Forum for assistance: bit.ly/2L9OBhk.

They're not using one big container and it actually follows all those principles that you've mentioned.

holy crap yes, great question. How does it compare to dog poo.

Total and utter cringe.

Praveen Kumar I love your videos🤩🤪😚😍😇🥰😘🤯🤑😻🤘🏻

You can learn about how Ember.js was born. Really cool documentary: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-Cvz-9ccflKQ.html

maybe it worth fixing the facebook first

+CollMomo1 no you're idiot

+Юрий Яковенко big fancy words to only say that react parses html in real time.

+CollMomo1 HTML parsing is certainly an aspect of React. It's really more of a "templating modularizer." Jargon can seem like "big fancy words" but really has more specific implications behind it for the savvy