With the checkin of #10362, the code to render to a stream now looks like:

```
import { renderToStream } from 'react-dom/server'

renderToStream(<div>some text</div>).pipe(response);
```

This is great! I am, however, a little concerned about taking the word "node" out of the mix, because I'm thinking that we may eventually want to render to [**browser** streams](https://www.w3.org/TR/streams-api/), which are a really neat feature that can be used in concert with "service-worker-side rendering". I would propose renaming `renderToStream` to `renderToNodeStream` and `renderToStaticStream` to `renderToStaticNodeStream`.  This would give room for `renderToBrowserStream` in the future.

If I make a PR on this, would it have a chance of being accepted? 

cc @gaearon & @sebmarkbage 
const e = await render(<math />);
        expect(e.childNodes.length).toBe(0);
        expect(e.tagName).toBe('math');
        expect(e.namespaceURI).toBe('http:www.w3.org/1998/Math/MathML');
      });
    });
    
    
    itRenders('an img', async render => {
      const e = await render(<img />);
      expect(e.childNodes.length).toBe(0);
      expect(e.nextSibling).toBe(null);
      expect(e.tagName).toBe('IMG');
    });
    itRenders('a button', async render => {
      const e = await render(<button />);
      expect(e.childNodes.length).toBe(0);
      expect(e.nextSibling).toBe(null);
      expect(e.tagName).toBe('BUTTON');
    });
    itRenders('a div with dangerouslySetInnerHTML', async render => {
      const e = await render(
        <div dangerouslySetInnerHTML={{__html: "<span id='child'/>"}} />,
      );
      expect(e.childNodes.length).toBe(1);
      expect(e.firstChild.tagName).toBe('SPAN');
      expect(e.firstChild.getAttribute('id')).toBe('child');
      expect(e.firstChild.childNodes.length).toBe(0);
    });
    describe('newline-eating elements', function() {