However React challenges this idea only to the extent of declaring that area’s of concerns have traditionally been for a development team (where there are UI designers, business logic designers and data designers). However their challenge is timely, especially in an Agile development world because most designers don’t even code to the HTML or stylesheet level, but leave that up to developers.
Also, the area’s of concern in Facebook’s view is more around the business functionality. I tend to agree with this. If a component is required to be developed for, let’s say a messaging system, then there would be a clear business owner for this, and therefore, to meet his requirements, the messaging system would have a particular UI, and way of interacting with users, over and above who is employed to build each part of the system. Since developers understand HTML and stylesheets anyways, why separate these concerns between a UI designer (who is more focused on mockups), and the business logic? Further, if business logic is needed just for presentation, why should a UI designer know or care about some programming language to implement the business rules they define? They shouldn’t.
To further this concept, Facebook’s React framework challenges the MVC model because they feel this just isn’t scalable. Again, I tend to agree, simply because the MVC model can become out of hand over time, where more dependencies from one MVC to another increases, causing a chain reaction of support issues.
To address these concerns, Facebook came up with React. This is a great framework that makes development a lot easier by implementing UI components, that maintain state. This is the state of the overall UI, not the state of the data, and hence, mixing html fragments within a React component (done by developers anyways), is not such a bad thing, as a matter of fact, is a great thing because it allows the developer to think in UI components, keeping the UI logic within that component and not mixing it up with actual business logic.
Enter Flux. Flux is yet another thing the Facebook folks have created. It is not a library like React, but rather an architecture that allows developers to separate concerns within a project team. However, unlike traditional MVC style of architecture, they feel that the state of data should flow one way, from the source of the data change, through to the actual presentation, and then to the data layer to persist the change. Hey, not bad at all. This means there is no complexity by rendering up to the second changes in the data. They do so by re-rendering the entire UI component. Oops, yet another “Yiikes”!
But, like other high performance applications, the UI component they re-render is only a delta change rather than an entire rewrite. Enter the React Virtual DOM. Like high performance systems like game engines, only rendering just that part of the screen that actually changes increases performance 10 fold. So the React framework allows this by maintaining a virtual DOM, and when it actually comes to expensive DOM operations, it only does a DIFF to see the areas that are the delta and renders them. This means the state of the data or even presentation state remains intact immediately after a change, and tells the rendering system to re-render those UI changes by way of the delta. This is a developer’s dream, since they don’t have to write complicated logic to keep up with the changes to either the data or presentation of any “Area of concern” (business unit).
Flux is not a library, but rather an architectural style that merely keeps up when state changes. It allows state to change instantaneously and on the fly, without compromising what needs to get rendered as a result. It does this by defining actions that can be performed by UI components, and these actions, when tied to actual presentation data stores, can “react” instantly on a data change. However, the keyword there is “presentation data”, not actual data. Flux does change actual data in a database, but this is not what a Store worries about. It only worries about the state of the data at the time it is rendered, and announces the change to UI components to allow them to re-rerender.
FaWhat does this mean for business owners? A great deal. This means the business owner can focus on their business data, and presentation of that data in a real time manner, and leave the techie stuff up to techies, whether it be a presentation UX designer, architect, developer or tester; each part of the software development lifecycle is handled by the right person allowing the business owner to focus on the features required from their area. Perhaps it is time to see things differently? As Facebook says, give it 5 minutes, and perhaps it might just make sense. After all they deal with Billions of users, why shouldn’t we give what they have to say just 5 minutes?