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!
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.
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.
> 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.
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.
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.
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.
// 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); } });
But we see that you've noticed and I think the folks working on HHVM internally will get that corrected soon!