Hi, I'm one of the devs on this team. Let me know if you have any questions.

It's a super awesome feeling to have open sourced this after working on it for months, and I think we've done some interesting things. So I want to share our ideas and opinions. I'm hoping to publish more about them in the coming weeks.

I couldn't figure out from the blog post why you switched from backbone to react. Could you talk a bit about the reasons?

I left them out because many others have blogged about the same reasons. But this is the biggest reason:

We have a lot of complexity in our view/component layer where we trying to bring simple workflows to very complicated technical features. Backbone (even with Marionette) doesn't have a strong view composition story, essentially avoiding setting up any patterns.

React's composition pattern is so strong that its hard not to abstract things. The complexity is still there but its easy to follow and extremely simple to test (especially with redux).

There are more reasons, but I have to go now. Hopefully that suffices

With regard to adopting React, coming from Backbone in the past. I've found that it simplifies the view layer, particularly when it comes to extracting shared functionality. It's not to say that you can't do this in a Backbone application, far from it. However, it's less work in a React application because of how React enables composition.

There were two primary drivers the led me to adopt Redux.

1) When working with multiple services to build a single view, Backbone models are the wrong abstraction. Redux allows you to work with arbitrary data structures without the need to deal with hooking up events between nested models/collections. It also prevents overfetching or having to resort to nested models when a single endpoint serves multiple views.

2) Managing complex asynchronous flows becomes easier when there's a single source of truth.

The backends for frontends pattern that Netflix and Thoughtworks have written about is another approach to dealing with the multiple services issue, but in reality, it's not an option for every project.

Thanks for open sourcing this. I know that can be hard to get through legal and can be something that is hard for people. Great to see this!

CloudFlare was actually very encouraging. I emailed our internal open source legal mailing list and had responses from our CEO and Head of Product Strategy within 5 mins that were really excited about it. There was a brief concern about phishing, but that was quickly resolved. It was more difficult writing the blog post than getting legal's approval :P

Now, I'm hurt, James. I replied

    From: John Graham-Cumming
    Subject: Re: open sourcing cf-ui
    Date: Fri, 11 Mar 2016 07:15:56 +0000

    This is fantastic! I am really happy to see open source 
    stuff from www and would love to see this open sourced soon 
    with a nice blog post describing why we wrote this, what 
    the transition was like, what the components do. 

    We've done a tremendous amount of blogging and open 
    sourcing of systems level stuff and it's great that we can   
    do the same here. Super to showcase all our technology. 

    Really nice. 

But, oh, those guys reply and that's what you remember?

:-)

You weren't in that 5 min cutoff. And no excuses about being on the other side of the world

Wow, I'm jealous. Every time I've tried to get stuff open sourced at the company I'm with I get blocked by legal usually they just don't get what the technology is, like kernel bypass PF_RING network processor :( one day. Glad to hear you had a good experience though

It may be that our legal counsel is too busy making dad jokes to care about me open sourcing some JavaScript.

+1 can confirm

I'm amazed that you even have an open source legal mailing list.

I was shocked too, honestly. But we are always looking for projects we can open source, so it's very useful.

It's dead easy to open source stuff at CloudFlare. We have an internal mailing list. Email was sent on March 11, 2016 requesting this. Everyone signed off (including legal) that day.

Thats about how long it takes me to write a blog post :P

Also I was trying to get a number of things in a good place, like https://lernajs.io/

We were busy doing other stuff.

Heh, yeaah boss. OBVIOUSLY I do TONS of things. Where would I even begin to talk about all the things I do? There's just so many! No time to open source something with all the things I definitely do...

closes 30 browser tabs

The demo page causes a crash and reload loop on Safari iPhone iOS 9.3.2

Related blog post that explains what this is and why we open sourced it: https://blog.cloudflare.com/cf-ui/

OK, we'll change the URL from https://cloudflare.github.io/cf-ui/ to that, which gives more background.

nope. This is the new javascript <3

Lerna [1] is very cool. I was firmly against monorepos, but the ability to easily manage and coordinate between individually versioned packages in a single repo is awesome. You get the benefits of a monorepo but also the benefits of small modules so it's the best of both worlds.

[1]: https://github.com/lerna/lerna

After seeing the Lerna reference in the post I think I'm more interested in that than the UI framework (although that seems cool too :)

James is also on the Lerna team as well! He and I can answer questions about that too. (We also have a slack https://slack.lernajs.io/)

I noticed there are components for all the standard HTML typography like <kbd> is <Kbd> and such. Is there a perf hit in wrapping everything in a react component? Any particular reason to do this?

Not sure about the perf difference between DOM elements and component elements, but the primary reason would be: let's say later on you decide each <kbd> should have a className, or a little tooltip helper, or a title attribute, or some ARIA role or something. Since you can't modify the built-in DOM elements, you'd have to find each instance where you used <kbd> throughout the codebase. If they're wrapped, you can just modify the <Kbd> wrapper in one place and the new output is rendered everywhere.

This is exactly it. Also if we ever choose to use React Native (cough), it would be good not to have hard coded DOM elements.

I haven't tested the performance heavily but I'm not really concerned about it.

Is this really how to do tables in React?

          <Table striped>
            <TableBody>
              <TableRow>
                <TableCell>One</TableCell>
                <TableCell>Two</TableCell>
              </TableRow>
              <TableRow>
                <TableCell>Three</TableCell>
                <TableCell>Four</TableCell>
              </TableRow>
            </TableBody>
          </Table>

It might seem a bit strange, but there is a good amount of value in wrapping native DOM elements. The easiest way to describe it would be when using bootstrap.

    <Input />

could return

    <input class="form-control" />

Now, you don't have to type `class="form-control"` on every single input, and if you want to move away from bootstrap, you can remove it all in one place.

That is just an abstraction over regular tables allowing them additional functionality not present in regular HTML. Of course you can use the standard table markup.

Is that TypeScript in the examples? Haven't done JS in a while(angular), so it seems like TypeScript has become the de facto standard now.

TypeScript is quite popular but I wouldn't say it's anything like the de facto standard for frontend development. If anything, writing ES6 (and transpiling with Babel) is the standard.

I think it's just ES2015 with JSX.

In the React world it seems that ES6 or ESNext transpiled has the most mindshare. That's what this is.

Between what they're doing and the example text in their image, I like these guys :)

Looks useful and interesting - thanks!

To start, I love Elm. I'm super interested in compilers and I've looked a lot into theirs.

However, Elm is still making breaking changes on the language level [1]. To bet on a language like that right now is tough for a larger company.

Also, we're not dropping everything and rewriting it all from the ground up. I'm not sure that Elm has a good story for incremental migrations yet, where React has an excellent one.

[1]: http://elm-lang.org/blog/farewell-to-frp