paulrouget/firefox.html — pull request #94 by Gozala (2014-12-18 23:14:17+00:00)
Title: Initial draft of integrating react.

This pull request is not ready to be merged yet, but I wanted to share it sooner to let you know I'm working on this & explain why. For one I believe use of react (or other similar style library) provide enough benefits to justify the switch. I'm going to list pros and cons as I see them below:

## Pros

1. Complex applications like browsers tend to be prone to certain style of issues. In my experience that usually caused by a multidirectional data flow and fragmented state scattered across the runtime. React embraces unidirectional data flow & single app level data storage that makes reasoning about code very trivial.
2. In react synchronization of state with view (html) is taken care of by a library in very performant manner (redraws happen on animation frames) and application code is not constrained with manually updating dom instead it just expresses decleratively how state is mapped to the view. That makes code easier to reason & change as timing issues are really hard to run into as react uses virtual dom and performs complete DOM update in one transaction.
3. Facebook is using react and putting a lot of effort into it, optimizing it for performance etc...
4. React components tend to have a very clear interface and usually prevent you from coupling.
5. Bunch of people know react already and arguably it's easier for ppl to contribute because it's opinionated enough to enforce certain style but not too much.

## Cons

1. React does not very friendly to non-standard html elements or attributes, there for I had to convert hbox, vbox, flex etc... to class names. I don't think that's a huge deal but definitely far from ideal. This limitation is little more annoying with web components, as custom event names aren't supported neither are attributes. That being there are lifecycle methods that let you make your own updates to DOM which is what I've used for `Frame` component. I imagine this limitation will be fixed over time, as I imagine that with a an adoption of web components this problem will be far more relevant.
2. State updates happen should be handled by a root component, there for nested ones need to manually send requests. This is a cost one needs to pay in order to keep app state in one place, which results in little more boilerplate although on flip side having unified view of state has ton of benefits & it does make interface between components strictly defined.
4. Unlike in current prototype different components do need to be wired, meaning that it's not enough to remove required module to enabling / disabling feature, although it's still easy enough to do. With little more effort I imagine it will be possible to reduce coupling even further. I think that can be done via something like an overlay component or alternatively by providing some API to registering components into a root component. I have not actually looked into this yet though.