Hacker News new | comments | show | ask | jobs | submit login

React 0.14 is going to have similar optimizations. Check those three posts if you are interested in the details :)

Reuse Constant Value Types like ReactElement: https://github.com/facebook/react/issues/3226

Tagging ReactElements: https://github.com/facebook/react/issues/3227

Inline ReactElements: https://github.com/facebook/react/issues/3228

React's unfair and one-sided patent grant aside (personally, I will never build a real app with React unless that situation changes), it is not a complete MVC framework, and to my knowledge there is nothing that fills in the gaps to make something close to Ember feature-wise. So while React may end up faster, Ember will hopefully be quick enough that its programming model wins out.

Edit: grammar.

What makes the patent grant unfair? I think saying "you can use our pretty powerful technology until you sue us" is a great way to defang the patent system.

[1] https://github.com/facebook/react/blob/master/PATENTS

It's unfair and one-sided because you cannot sue Facebook for infringing an unrelated patent, but if Facebook sues you for an unrelated patent, you will lose your rights if you try to assert (defensively) that their patent is invalid. In other words, you can never sue or even defend yourself against a Facebook lawsuit.

For a more balanced approach to patents, see the GPL, Mozilla Public License, or Apache 2.0 License.

This is a common misinterpretation of this clause. There's been a lot of discussion at length here: https://news.ycombinator.com/item?id=8985722

A discussion started by an actual lawyer about the same license used for an other project is here: https://news.ycombinator.com/item?id=8901357

He doesn't agree with your interpretation. The license is very clear in that everything a company would typically do to /defend/ against a patent suit brought by Facebook will terminate its patent rights on React.

Let me quote the second paragraph (added line formating for readability), the (b) part is the broadest I think:

    The license granted hereunder will terminate, automatically and without notice,
    for anyone that makes any claim (including by filing any lawsuit, assertion or
    other action) alleging

    (a) direct, indirect, or contributory infringement or
    inducement to infringe any patent: (i) by Facebook or any of its subsidiaries or
    affiliates, whether or not such claim is related to the Software, (ii) by any
    party if such claim arises in whole or in part from any software, product or
    service of Facebook or any of its subsidiaries or affiliates, whether or not
    such claim is related to the Software, or (iii) by any party relating to the

    or (b) that any right in any patent claim of Facebook is invalid or
So why word it like users cannot defend against Facebook while Facebook doesn't intend to be a claimant?

I read that discussion. The patent grant is very asymmetrical. Why should an entity using React be vulnerable to being sued by Facebook for unrelated patents and be unable to challenge those patents?

IANAL and I have nothing else to add to the discussion here other than adding the context that Facebook hates patent trolls and doesn't really compete on technology, so even if your interpretation is correct (which I don't believe it is) it'd be purely defensive anyway.

IANAL so I didn't get that. Thanks for explaining!

That's not just what it says. If it just said that, that would be fine.

It says making "any claim" against a Facebook patent will terminate your right to use the software. Facebook gets to protect its own software patents: "that any right in any patent claim of Facebook is invalid or unenforceable."

The other lines are okay, it seems.

I am not an IP law expert or lawyer though, but the writing seems pretty simple.

I'm not a lawyer either, but isn't the word "claim" a term of art in law. Doesn't it have a specific meaning distinct from the common usage?

"Claim" has a specific meaning in the sense of the invention "claimed" by a patent. But Facebook's patent grant is clearly not using it in that context: "any claim (including by filing any lawsuit, assertion or other action)".

And a good reason for someone to claim a patent is invalid is being sued for violating that patent.

It's also worth noting that we're getting to the point where fastest doesn't really matter. Both Ember and React will be fast enough. Performance shouldn't be a deciding factor.

One of the motivations for this change was that a real-world application was too slow. As the original presentation says, choosing a technology and then finding out that it's limiting you is really rough when it happens to you.

Performance _does_ enable certain kinds of applications, and it does absolutely matter, even on the desktop.

Performance matters, but if Ember can have 50-60% of the speed of a performance-optimized React app without the associated cognitive overhead, I suspect many will see the trade-off as worth it.

Agreed. And I suspect Ember can get closer than that, if not even outdo React in some cases.

Agreed, for sure. I wasn't trying to make a framework-specific statement, just disagreeing with the notion that performance doesn't matter at all. It may only be for certain kinds of applications, but having more options is always good.

I should have added the caveat that there will always be a handful of cases where you do need absolute top performance. However, I do think that for the vast majority of apps we'll end up at a point where performance isn't the deciding factor. It doesn't mean that we shouldn't keep improving performance, just that being the fastest doesn't matter so much if all the options are very fast.

it seems like if you're concerned with performance, react vs ember is not the conversation you're having.

your concern would be whether to use a framework at all

Performance is a relative term. One could just as well argue that if you're really concerned with performance you should just write machine code.

i suppose i presumed a difference of 2x either way (worse/better) to justify picking one over the other -- given that frameworkless is ultimately the most optimize-able.

do you need something to be "at least X(ms) fast" or "faster than what company Y is doing" or "as fast as possible, no exceptions"

Or whether you should even be using a web app.

It still matters on mobile. Whether it is running out of memory or being too sluggish to be usable.

Basically, if you treat render functions as "pure functional" functions, you can employ memoization and avoid recalculation. I hope this isn't the subject of patents, because it seems pretty basic.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact