6 ms·

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

by vjeux 12y ago

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 https://github.com/facebook/react/issues/3226 Tagging ReactElements: https://github.com/facebook/react/issues/3227 https://github.com/facebook/react/issues/3227 Inline ReactElements: https://github.com/facebook/react/issues/3228 https://github.com/facebook/react/issues/3228

ralmidani 12y ago
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.
- rxcfc 12y ago
  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.
  - rxcfc 12y ago
    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.
    - hayksaakian 12y ago
      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
      - poolpool 12y ago
        Or whether you should even be using a web app.
      - rxcfc 12y ago
        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.
        hayksaakian 12y ago
        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"
  - steveklabnik 12y ago
    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.
    - ralmidani 12y ago
      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.
      - rxcfc 12y ago
        Agreed. And I suspect Ember can get closer than that, if not even outdo React in some cases.
      - steveklabnik 12y ago
        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.
  - cordite 12y ago
    It still matters on mobile. Whether it is running out of memory or being too sluggish to be usable.
- teh 12y ago
  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 https://github.com/facebook/react/blob/master/PATENTS
  - ralmidani 12y ago
    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.
    - teh 12y ago
      IANAL so I didn't get that. Thanks for explaining!
    - peterhunt 12y ago
      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 https://news.ycombinator.com/item?id=8985722
      - ralmidani 12y ago
        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?
        peterhunt 12y ago
        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.
- deleted 12y ago
  [deleted]
cromwellian 12y ago
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.

by vjeux 12y ago

ralmidani 12y ago

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.

rxcfc 12y ago
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.
- rxcfc 12y ago
  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.
  - hayksaakian 12y ago
    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
    - poolpool 12y ago
      Or whether you should even be using a web app.
    - rxcfc 12y ago
      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.
      - hayksaakian 12y ago
        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"
- steveklabnik 12y ago
  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.
  - ralmidani 12y ago
    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.
    - rxcfc 12y ago
      Agreed. And I suspect Ember can get closer than that, if not even outdo React in some cases.
    - steveklabnik 12y ago
      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.
- cordite 12y ago
  It still matters on mobile. Whether it is running out of memory or being too sluggish to be usable.
teh 12y ago
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 https://github.com/facebook/react/blob/master/PATENTS
- ralmidani 12y ago
  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.
  - teh 12y ago
    IANAL so I didn't get that. Thanks for explaining!
  - peterhunt 12y ago
    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 https://news.ycombinator.com/item?id=8985722
    - ralmidani 12y ago
      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?
      - peterhunt 12y ago
        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.
deleted 12y ago
[deleted]

cromwellian 12y ago

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.