zpao

Hi, Paul from the Open Source Team here at Meta. HHVM is still in use and there are no changes to the level of maintenance the open source project gets. There's no conspiracy, no quiet quitting. The reality is that we just had some issues that affected our automatic syncing a little while back and HHVM got stuck. Since use outside of Meta is relatively low, unsticking it was just lower priority.

But we see that you've noticed and I think the folks working on HHVM internally will get that corrected soon!

Rome is a completely separate project that Meta no longer owns. You can check https://rome.tools/ for the project status.

Hi, Paul from the React team here. There have been lots of questions about the license+patents combo we use. Recently our legal team answered some of those questions.

https://code.facebook.com/license-faq

It was the right decision at the time - it made React much more familiar for people at FB who were writing PHP/Hack (Dan called this familiarity out in the post). It also enabled some great things that are still awkward with other patterns - https://github.com/reactjs/react-timer-mixin/issues/4 is an interesting case. That functionality is nice and elegant with mixins but not so with classes.

I think if we had to do it again (and get to keep the knowledge of the last few years), we'd probably skip mixins. We'd surely do some other things differently too though :)

No we've known and said it for a long time but not very loudly. People haven't used them sparingly and they tend to infect a codebase. Now we're just making a more concerted effort to communicate more broadly that they can be bad.

Another way, which we actually supported in 0.13, was to turn on "pause on caught exceptions" in your debugger. We throw and catch a warning so that you could catch warnings live. We continue to do that now, just with the added benefit of having the stack trace showing up without needing to pause.

They're only needed if you don't start your JSX expression on the same line as the return.

FWIW, https://github.com/facebook/react/blob/master/package.json is not actually the package.json we ship to npm. This is just for building. https://github.com/facebook/react/blob/master/packages/react... is the package.json we ship to npm.

> Might lead to a SpiderMonkey version of Node.js at some point, too.

I worked on that 4 years ago :) <http://zpao.com/posts/about-that-hybrid-v8monkey-engine/>. The Node community at the time wasn't a huge fan, though it's effectively the same thing that MS just did (build a minimal V8 API shim on top of another JS engine). I guess everybody is ok with a little fragmentation now. Our intention was also to try to get this upstreamed, however with low interest and other things to do, we didn't follow through.

I'm excited to see this, and especially to have the MS folks involved with the TC. I'd love to see an engine-agnostic API but realistically I don't think it'll happen, at least not anytime soon. Right now Node itself definitely relies pretty heavily on the V8 APIs. Those APIs can be abstracted for the most part (even if each engine is just shimming those parts of the V8 API) but the other problem is the longer tail of binary npm modules. Right now they have the full V8 API to work with. If they do a shim layer then it will come at cost for every vendor except V8. And then maintaining that layer as V8 changes APIs. If you go the engine-agnostic API route, then you will need coordination between engine vendors. That opens the doors to a multitude of problems.

No sample code yet and yes it will be open sourced.

iOS and android right now. And yes, native components can be rendered directly with JSX. And you won't need to mix with DOM. <h2> For example doesn't mean anything on iOS.

No, it skips the DOM entirely and works with native elements (iOS views) directly.

It is worth considering, but it's often worth finding out what the cure is before writing it off. You have to make the right tradeoffs (eg, when working on a tight deadline, it's probably not the right call to go off into the weeds finding out if you can make 3 lines of code into 1).

Maybe. We're still working on the details about what that will look like. Chances are we'll have some basic support if you're doing a limited set of things. Stay tuned.

Mostly what @BinaryBullet said. fb.me is a urlshortener and then it hits real CDNed files. I (as maintainer of React) suggest not actually using fb.me urls in production. Use cdnjs or jsdelivr. Or host it yourself. We've been meaning to put together a proper CDN hosting setup for JS libraries but just haven't gotten around to it.

So long as you know the colors in [0] are all just the hardcoded CSS "standard" colors, then great :) There are some "awesome" ones there (papayawhip, lightgoldenrodyellow) and the history of how they came to be (via X11) is pretty interesting too.

AFAIK You're taxed on receiving stock as if it were income. This is regardless of if you sell it today, tomorrow, or never.

After that you're only taxed on gains. If you sold on the day of reception, then your gains/losses are likely minimal. Eg, receive at 50 sell at 50 = 0 gains/losses. Sell at 51 and you have $1*N gains. Those gains are taxed at a higher rate until a year after the stock appeared in your account. I think the difference is ~10% (35 vs 25 or so).

So there are definite tradeoffs between holding for the year vs selling immediately. This part is no different than buying/selling on the stock market.

tldr; yes, but not exactly

You could actually do this without a single change to the JSX transform, and instead just make a simple object that calls m() with the right params. Then you just change the @jsx pragma to point at that object. With a complete array of elements this should mostly work.

```js / @jsx m.dom */

function m(type, props, children) { // assuming m() looks something like this. return { type: type, props: props, children: children}; } m.render = function(lwDOM){ console.log(lwDOM)}; m.dom = {};

// React hard codes this array so we can do something like this to build the mapping ['a', 'span'].forEach((el) => { m.dom[el] = function(props, ...args) { return m.call(null, el, props, args); } });

m.render( <a href={"google.com"}> <span>hello</span> <span>world</span> </a> ); ```

Sorry to get your hopes up! I'll try to remember to make it a bit more obvious next time.

No, they aren't. Taking a look at the first one on the list... the latest version was published in 2011.

The trick is to use rawgithub.com (where you would otherwise see raw.github.com) - http://rawgithub.com/pinterest/cloudgrid/master/example/inde...

I tried that once, very shortly after open on a Wednesday. The wait was 2-3 hours. It's a popular place.

You're more than welcome to use XHR however you see fit. We don't dictate that choice. For many that will mean `$.ajax` - React plays nicely with jQuery (so long as you don't modify the DOM out from under us). For others that might mean a thin library that does that the same thing.

If you're interested in using jQuery with React, we have an example: https://github.com/facebook/react/tree/master/examples/jquer.... It doesn't use XHR but it should give you some idea of how the 2 can play nicely together.

What this actually returns is a lightweight DOM-like structure. The framework then uses that to make modifications to the real DOM. In the case of the first render that's going to mean setting innerHTML of something. After that though, if you re-render this component with a different value for props.name, React won't re-render the <div> in the DOM, but will instead just modify it's contents.

From the article: > The data returned from render is neither a string nor a DOM node -- it's a lightweight description of what the DOM should look like.

Like @thezilch said, the syntax is JSX, which is pre-processed into runnable JS.

Thanks for taking the time to follow this conversation through :) We've spent a lot of time getting the docs to where they are today, but there's always more to do. We have more planned but think we got a pretty good point for our initial public release.

When we've showed the site internally at FB & Instagram we got a lot of the same feedback you're giving now, that we need more examples. We have some more in the repo and more we'd like to write. Coming soon!

> This breaks code editors, static analysis tools like jshint etc.

You're right. One of our goals in the coming months is to try to make some language files for editors. Vim actually does a pretty good job of this already thanks to the similarity to E4X.

JSHint is another thing we'd like to improve upon. At Facebook & Instagram, we actually lint against the transformed code. Right now the transforms don't modify line numbers so it's been easy to match up. We'd like to build some tooling around this for people who make use of React and JSX.

> I think Web Components is landing soon, and this seems like it could leverage that.

I like the way you think! We've started thinking about that already.