
Open-Sourcing CloudFlare’s UI Framework - luisrudge
https://blog.cloudflare.com/cf-ui/
======
thejameskyle
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.

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

~~~
thejameskyle
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

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

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

------
rtsao
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](https://github.com/lerna/lerna)

~~~
michaelmior
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 :)

------
netghost
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?

~~~
exogen
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.

~~~
thejameskyle
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.

------
pbreit
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>

~~~
badthingfactory
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.

------
_RPM
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.

~~~
savanaly
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.

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

------
misiti3780
Looks useful and interesting - thanks!

------
Ruud-v-A
A shame they didn’t rewrite it in Elm while they had the opportunity.

~~~
thejameskyle
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](http://elm-
lang.org/blog/farewell-to-frp)

