6 ms·

Yes, it's like with JavaScript itself, it had some issues in the past, all the big issues were resolved but the stigma is still there. I can't see any fundamen

Yes, it's like with JavaScript itself, it had some issues in the past, all the big issues were resolved but the stigma is still there. I can't see any fundamental reason why generating the DOM with React would be faster than generating the DOM with Web Components - They're doing the same thing; it's a matter of time before they even out (if they haven't already). I think that Web Components would end up faster ultimately due to native browser support (more room to optimise).

bigmanwalter 10y ago
The React documentation says it so it has to be true. DOM slow, VDOM fast. Facebook is out there buying developer mindshare.
- danabramov 10y ago
  We don't claim that in React documentation. React can't be faster than the same DOM mutations written by hand because by definition it has to do more work. We do think it helps to create maintainable apps though, and it is fast enough for practical use cases despite its immutable design. That's why we use it at Facebook.
  - bigmanwalter 10y ago
    I just haven't been able to figure out what, exactly, it is about manual DOM mutations that makes an app unmaintainable. As long as your code is organized and modular, it's always been easy enough for me to navigate through and maintain a non-React codebase.
    - jbergens 10y ago
      Probably finding the right place of the dom to change and keeping track of what to change. React basically says "make it like this" and takes care of a lot of things. jQuery code is well known to be hard to maintain when it changes things based on element-types, classes and id's nested in each other.
      - bigmanwalter 10y ago
        It's quite simple to handle that situation with jQuery and modules. If many parts of you code need to make a change to the DOM in the same place, you wrap the DOM changing in a module. var widget = require('./widget'); widget.foo('bar'); And the widget handles the jQuery'ing for you. module.exports = { foo: function(s) { $('.widget').text(s) } }
        dmitriid 10y ago
        Only: - it breaks immediately if there is more than one '.widget' on the page - your app will get out-of-sync DOM updates because different parts will flush changes to the DOM at different times (React is DOM = f(state, time), so if multiple changes happen in f, they all be flushed to DOM in one go)
    - danabramov 10y ago
      I found these things hard: * Inconsistencies or duplicated code between initial render and updates. * Having to write code for N^2 transitions between N valid states instead of N valid states themselves. * Harder to ensure DOM operation order across different parts of the codebase doesn’t produce jank. Sure, this is all possible to solve, but in my experience I just ended up with a crappy version of React.
      - just2n 10y ago
        Seconded on all counts. We also ended up independently implementing a really simplistic and in many ways broken version of React for these reasons and many others.
    - just2n 10y ago
      In my experience it's the needed complexity added by bookkeeping and the coupling that requires to do rendering/updates and data binding using manual DOM manipulations in a performant way, especially in larger scale apps. You can easily write maintainable and simple applications that manipulate the DOM directly if you don't care about performance, or in some cases correctness, and you'll quickly do worse than React would, from what I've seen.
kbenson 10y ago
> Yes, it's like with JavaScript itself, it had some issues in the past, all the big issues were resolved but the stigma is still there. Honest question, because I use Javascript just infrequently enough to have to look this up every time (and it's possible the reported solutions are old), is there a good concise universal way (or two, at most) to determine the type of the variable I may have? It seems it's always a tossup between typeof, instanceof, == null and == undefined, and to my eyes that's way too many.
- comex 10y ago
  A somewhat more succinct option could be to coerce to Object and then use instanceof: 'Object(x) instanceof String'. Or you could use Object.getPrototypeOf, which coerces to Object automatically these days. But null and undefined are special: calling Object on them returns {}, and calling Object.getPrototypeOf on them throws. If the type you're testing for is not one of the builtin literal types, you can just use instanceof.
  - kbenson 10y ago
    "Object(foo) instanceof Class" does seem to be the most definitive, but unfortunately seems to require specific testing against a literal that must exist or it throws, and doesn't work for null/undefined. That at least brings the things I need to know to check the type of something down to three, two of which are singular special cases (if somewhat common ones), so that's better and possibly adequate, if not what I would consider good. Then again, I'm not sure I'm capable of thinking it could achieve good while there exists both an undefined and null in the language. It still boggles my mind that it has both.
    - comex 10y ago
      To clarify, by "literal that must exist or it throws" you mean that you don't know whether the class you're testing for exists? Testing against an invalid class would be an error in most languages… I guess an alternative is foo.constructor and foo.constructor.name, which will give you a string if you want that.
31h 10y ago
> JavaScript itself, it had some issues in the past, all the big issues were resolved What about automatic semicolon insertion (ASI)? This makes it impossible to internalize how the JS implementation will interpret your code without memorizing a bunch of special cases, and makes "newline" semantically significant even if you only intend it for formatting your code. It's never going to be fixed because of backwards compatibility. I can put up with a lot of language peculiarities, but I don't like wondering if some random "return" statement in my code is going to misbehave because of extra whitespace. This is enough reason for me to keep looking for an ideal language.
- Roboprog 10y ago
  Possibly embrace the fact that semicolons are noise, and treat JS like you would Ruby or other line oriented languages??? (ignoring the fact that JS will "look ahead" past an otherwise complete line - e.g. - return [nothing] followed by open curly brace - but Ruby for example won't) Remember the bad old days of BASIC? You only needed that extra delimiter (colon, rather than semi) when you were going to put multiple statements on one line :-) Yeah, minifiers are often too dumb to accept valid input text :-(
  - 31h 10y ago
    > Possibly embrace the fact that semicolons are noise, and treat JS like you would Ruby or other line oriented languages??? I'd be happy to treat JS as "statements end with a newline, not semicolon", if that were consistently true. The paradox of Javascript: Do statements end in a semicolon, or newline? If you answer either way, you're sometimes wrong. As far as I can tell this is the only misfeature of JS that is really unfixable.
skocznymroczny 10y ago
except it still doesn't have support for modules in 2017.

bigmanwalter 10y ago

The React documentation says it so it has to be true. DOM slow, VDOM fast. Facebook is out there buying developer mindshare.

danabramov 10y ago
We don't claim that in React documentation. React can't be faster than the same DOM mutations written by hand because by definition it has to do more work. We do think it helps to create maintainable apps though, and it is fast enough for practical use cases despite its immutable design. That's why we use it at Facebook.
- bigmanwalter 10y ago
  I just haven't been able to figure out what, exactly, it is about manual DOM mutations that makes an app unmaintainable. As long as your code is organized and modular, it's always been easy enough for me to navigate through and maintain a non-React codebase.
  - jbergens 10y ago
    Probably finding the right place of the dom to change and keeping track of what to change. React basically says "make it like this" and takes care of a lot of things. jQuery code is well known to be hard to maintain when it changes things based on element-types, classes and id's nested in each other.
    - bigmanwalter 10y ago
      It's quite simple to handle that situation with jQuery and modules. If many parts of you code need to make a change to the DOM in the same place, you wrap the DOM changing in a module. var widget = require('./widget'); widget.foo('bar'); And the widget handles the jQuery'ing for you. module.exports = { foo: function(s) { $('.widget').text(s) } }
      - dmitriid 10y ago
        Only: - it breaks immediately if there is more than one '.widget' on the page - your app will get out-of-sync DOM updates because different parts will flush changes to the DOM at different times (React is DOM = f(state, time), so if multiple changes happen in f, they all be flushed to DOM in one go)
  - danabramov 10y ago
    I found these things hard: * Inconsistencies or duplicated code between initial render and updates. * Having to write code for N^2 transitions between N valid states instead of N valid states themselves. * Harder to ensure DOM operation order across different parts of the codebase doesn’t produce jank. Sure, this is all possible to solve, but in my experience I just ended up with a crappy version of React.
    - just2n 10y ago
      Seconded on all counts. We also ended up independently implementing a really simplistic and in many ways broken version of React for these reasons and many others.
  - just2n 10y ago
    In my experience it's the needed complexity added by bookkeeping and the coupling that requires to do rendering/updates and data binding using manual DOM manipulations in a performant way, especially in larger scale apps. You can easily write maintainable and simple applications that manipulate the DOM directly if you don't care about performance, or in some cases correctness, and you'll quickly do worse than React would, from what I've seen.

kbenson 10y ago

> Yes, it's like with JavaScript itself, it had some issues in the past, all the big issues were resolved but the stigma is still there. Honest question, because I use Javascript just infrequently enough to have to look this up every time (and it's possible the reported solutions are old), is there a good concise universal way (or two, at most) to determine the type of the variable I may have? It seems it's always a tossup between typeof, instanceof, == null and == undefined, and to my eyes that's way too many.

comex 10y ago
A somewhat more succinct option could be to coerce to Object and then use instanceof: 'Object(x) instanceof String'. Or you could use Object.getPrototypeOf, which coerces to Object automatically these days. But null and undefined are special: calling Object on them returns {}, and calling Object.getPrototypeOf on them throws. If the type you're testing for is not one of the builtin literal types, you can just use instanceof.
- kbenson 10y ago
  "Object(foo) instanceof Class" does seem to be the most definitive, but unfortunately seems to require specific testing against a literal that must exist or it throws, and doesn't work for null/undefined. That at least brings the things I need to know to check the type of something down to three, two of which are singular special cases (if somewhat common ones), so that's better and possibly adequate, if not what I would consider good. Then again, I'm not sure I'm capable of thinking it could achieve good while there exists both an undefined and null in the language. It still boggles my mind that it has both.
  - comex 10y ago
    To clarify, by "literal that must exist or it throws" you mean that you don't know whether the class you're testing for exists? Testing against an invalid class would be an error in most languages… I guess an alternative is foo.constructor and foo.constructor.name, which will give you a string if you want that.

31h 10y ago

> JavaScript itself, it had some issues in the past, all the big issues were resolved What about automatic semicolon insertion (ASI)? This makes it impossible to internalize how the JS implementation will interpret your code without memorizing a bunch of special cases, and makes "newline" semantically significant even if you only intend it for formatting your code. It's never going to be fixed because of backwards compatibility. I can put up with a lot of language peculiarities, but I don't like wondering if some random "return" statement in my code is going to misbehave because of extra whitespace. This is enough reason for me to keep looking for an ideal language.

Roboprog 10y ago
Possibly embrace the fact that semicolons are noise, and treat JS like you would Ruby or other line oriented languages??? (ignoring the fact that JS will "look ahead" past an otherwise complete line - e.g. - return [nothing] followed by open curly brace - but Ruby for example won't) Remember the bad old days of BASIC? You only needed that extra delimiter (colon, rather than semi) when you were going to put multiple statements on one line :-) Yeah, minifiers are often too dumb to accept valid input text :-(
- 31h 10y ago
  > Possibly embrace the fact that semicolons are noise, and treat JS like you would Ruby or other line oriented languages??? I'd be happy to treat JS as "statements end with a newline, not semicolon", if that were consistently true. The paradox of Javascript: Do statements end in a semicolon, or newline? If you answer either way, you're sometimes wrong. As far as I can tell this is the only misfeature of JS that is really unfixable.

skocznymroczny 10y ago

except it still doesn't have support for modules in 2017.