I think it's fair to say that StreamField has been one of the most successful and popular things we've built within Wagtail - it's a design that's stood the test of time. Nothing in software is ever really complete, though... as developers become more confident using it, it's being used in ever more complex and demanding applications that stretch StreamField's performance and UI usability to the limit. It's not unknown for page content to run to tens or even hundreds of blocks - and in the classic Django form paradigm, that adds up to a lot of HTML being rendered server-side.
Faced with this problem, it's natural to look at shifting this work to the browser side, building on client-side frameworks such as React to turn StreamField's JSON data into a rich editing interface. The react-streamfield project born out of NoriPyt's Wagtail's First Hatch crowdfunder has led the way on this, and many of the UI improvements introduced there have already been adopted into Wagtail itself as part of the 2.7 release.
However, up to now one thing has stood in the way of Wagtail embracing the react-streamfield model in full: backwards compatibility. Wagtail site creators have invested much effort into building custom StreamField blocks from Django form widgets, and we don't intend to turn our backs on that and make everyone rewrite them all in React. This means that any rich client-side implementation of StreamField that creates and populates FieldBlocks on-the-fly will need to interoperate with widgets written in the classic Django way. react-streamfield handles this by making some reasonable assumptions about the client-side behaviour of form widgets - for example, there will be an HTML input element matching the widget's name, and writing to its '.value' property will update it.