4 ms·

Just a reminder: the best part of React isn't about its diffing algorithm or the virtual DOM. Plenty of articles have been written on this (e.g. https://medium.

Just a reminder: the best part of React isn't about its diffing algorithm or the virtual DOM. Plenty of articles have been written on this (e.g. https://medium.com/@dan_abramov/youre-missing-the-point-of-react-a20e34a51e1a https://medium.com/@dan_abramov/youre-missing-the-point-of-r...). The diffing algorithm is a smart way of circumventing the fact that the DOM is so slow; there's nothing to be proud of working with such thing. Ideally your platform isn't so. Web devs will keep reimplementing parts of React elsewhere; but at least, be inspired by some other parts of React please.

moonchrome 12y ago
>we can focus on examining React’s true strengths: composition, unidirectional data flow, freedom from DSLs, explicit mutation and static mental model. So wannabe functional programming in JS ? I always wondered why Facebook didn't just go all-in on clojurescript when they did React, they have the resources to deal with any compiler/technical issues, heck they could reimplement the compiler themselves they already maintain a bunch of PHP VM/language stuff. It does everything react tries to do but better and by default.
- nilliams 12y ago
  There are a huge number of people who don't enjoy programming in lisps and don't buy the tradeoff that homoiconicity is somehow worth sacrificing all syntax for. You can take 'good parts' from functional programming without going 'all in'. Many of us don't agree that the 'all in' is actually better. (See Gary Bernhardt's 'Boundaries' talk [0] for an amazing explanation of what I mean by taking the good parts of FP). React isn't really about functional programming, it's very object-oriented. And where the parent comment refers to 'composition', they mean composition of components/view code, not pure functions as you may have interpreted it as. Personally my dive into the Clojure community has been very frustrating, I find very few answers on how to actually compose large apps, and the answers I do find basically point back to OOP (but implemented in a syntax-less, ad-hoc manner [1]). If I've got this wrong, please tell me, I'm dying for better answers. [0] https://www.destroyallsoftware.com/talks/boundaries https://www.destroyallsoftware.com/talks/boundaries [1] Stuart Sierra - Components Just Enough Structure - https://www.youtube.com/watch?v=13cmHf_kt-Q https://www.youtube.com/watch?v=13cmHf_kt-Q
  - moonchrome 12y ago
    If you've actually seen the React wrappers in clojurescript they all look really nice primarily because homoiconicity allows you to describe DOM as clojure data (and clojure has a nice syntax for vectors/map literals which helps with readability and parsing) for eg. you have stuff like [:div {:style "width: 20px"} [:a {:href "#"} "blah"] "blah"] - that's more concise than HTML and no need to fuse HTML with JS to do it. Also you can keep that representation as datastructures, do operations on it to transform and diff it, no need for custom objects or what not. Updates are also really nice because clojure datastructures are immutable an mutation is already isolated in to special constructs. The OO aspect of React is just a sad consequence of JS - clojure has different ways to deal with polymorphism. My impression is that all the stuff FB guys did (React, persistent data structures, unidirectional dataflow) already exist or are more natural in clojurescript than hacking it in to JS but I'm not the authority on the subject.
    - chenglou 12y ago
      Are you suggesting to throw away a decade of front-end engineering in favour of writing things in Clojure/ClojureScript? What's gonna happen next time a new language comes up in ten years? Rewrite everything? People (at least the ones I talk/work with) do understand the value of lisp. And I myself am a defender of that Hiccup-style syntax (https://github.com/facebook/react/issues/2932 https://github.com/facebook/react/issues/2932) and a huge Cljs fan. But judging from this comment and previous, it seems that you underestimate the value of getting work done in an already established environment.
      - moonchrome 12y ago
        I'm just saying that they reinvented most of the stuff that you get from clojurescript by default, and they did it in a more awkward manner because they tacked it on top of JS. Like they already have a JS preprocessor, have their persistent datastructures, etc. and have to deal with a lot of stuff they wouldn't need to deal with in a functional programming language.
        12y ago
- seanmcdirmid 12y ago
  Immediate mode UI, not functional programming, which aren't very related (most immediate mode UI systems have been done in procedural languages).
  - Gurkenmaster 12y ago
    Immediate mode UI is quite similar to pull based FRP.
Bahamut 12y ago
Just like to add, I was at the Angular 2 todo app talk last night at Google, where the Angular team unleashed a bevy of information about the internal workings and philosophy on application development. Some relevant details are that they too are embracing unidirectional flow, and the concept of immutable data. Frontend development keeps getting refined, it is very promising.
Touche 12y ago
I'm not sure why that article exists given it's content can fit in a single tweet. It's 90% finger wagging "you don't know what I know" and 1 sentence of the point. Anyways, this sentiment has become popular recently for some bizarre reason. All of the things that are the "real strengths" are in fact only possible because of virtual dom. So in my eyes the virtual dom is the important part, as the enabler.
- chenglou 12y ago
  Dan Abramov is a very knowledgeable React person, so it's not just random finger wagging. It's a shared sentiment in the React development team. Virtual DOM didn't enable React's component composition. Unidirectional data flow also has nothing to do with a virtual DOM.
  - Touche 12y ago
    Well, if it's not "random finger wagging" then that makes up for the fact that he spends several paragraphs berating the reader for not being as smart as he is and seeing what he sees and spends exactly 1 sentence explaining what it is that he sees.

moonchrome 12y ago

>we can focus on examining React’s true strengths: composition, unidirectional data flow, freedom from DSLs, explicit mutation and static mental model. So wannabe functional programming in JS ? I always wondered why Facebook didn't just go all-in on clojurescript when they did React, they have the resources to deal with any compiler/technical issues, heck they could reimplement the compiler themselves they already maintain a bunch of PHP VM/language stuff. It does everything react tries to do but better and by default.

nilliams 12y ago
There are a huge number of people who don't enjoy programming in lisps and don't buy the tradeoff that homoiconicity is somehow worth sacrificing all syntax for. You can take 'good parts' from functional programming without going 'all in'. Many of us don't agree that the 'all in' is actually better. (See Gary Bernhardt's 'Boundaries' talk [0] for an amazing explanation of what I mean by taking the good parts of FP). React isn't really about functional programming, it's very object-oriented. And where the parent comment refers to 'composition', they mean composition of components/view code, not pure functions as you may have interpreted it as. Personally my dive into the Clojure community has been very frustrating, I find very few answers on how to actually compose large apps, and the answers I do find basically point back to OOP (but implemented in a syntax-less, ad-hoc manner [1]). If I've got this wrong, please tell me, I'm dying for better answers. [0] https://www.destroyallsoftware.com/talks/boundaries https://www.destroyallsoftware.com/talks/boundaries [1] Stuart Sierra - Components Just Enough Structure - https://www.youtube.com/watch?v=13cmHf_kt-Q https://www.youtube.com/watch?v=13cmHf_kt-Q
- moonchrome 12y ago
  If you've actually seen the React wrappers in clojurescript they all look really nice primarily because homoiconicity allows you to describe DOM as clojure data (and clojure has a nice syntax for vectors/map literals which helps with readability and parsing) for eg. you have stuff like [:div {:style "width: 20px"} [:a {:href "#"} "blah"] "blah"] - that's more concise than HTML and no need to fuse HTML with JS to do it. Also you can keep that representation as datastructures, do operations on it to transform and diff it, no need for custom objects or what not. Updates are also really nice because clojure datastructures are immutable an mutation is already isolated in to special constructs. The OO aspect of React is just a sad consequence of JS - clojure has different ways to deal with polymorphism. My impression is that all the stuff FB guys did (React, persistent data structures, unidirectional dataflow) already exist or are more natural in clojurescript than hacking it in to JS but I'm not the authority on the subject.
  - chenglou 12y ago
    Are you suggesting to throw away a decade of front-end engineering in favour of writing things in Clojure/ClojureScript? What's gonna happen next time a new language comes up in ten years? Rewrite everything? People (at least the ones I talk/work with) do understand the value of lisp. And I myself am a defender of that Hiccup-style syntax (https://github.com/facebook/react/issues/2932 https://github.com/facebook/react/issues/2932) and a huge Cljs fan. But judging from this comment and previous, it seems that you underestimate the value of getting work done in an already established environment.
    - moonchrome 12y ago
      I'm just saying that they reinvented most of the stuff that you get from clojurescript by default, and they did it in a more awkward manner because they tacked it on top of JS. Like they already have a JS preprocessor, have their persistent datastructures, etc. and have to deal with a lot of stuff they wouldn't need to deal with in a functional programming language.
      - 12y ago
seanmcdirmid 12y ago
Immediate mode UI, not functional programming, which aren't very related (most immediate mode UI systems have been done in procedural languages).
- Gurkenmaster 12y ago
  Immediate mode UI is quite similar to pull based FRP.

Bahamut 12y ago

Just like to add, I was at the Angular 2 todo app talk last night at Google, where the Angular team unleashed a bevy of information about the internal workings and philosophy on application development. Some relevant details are that they too are embracing unidirectional flow, and the concept of immutable data. Frontend development keeps getting refined, it is very promising.

Touche 12y ago

I'm not sure why that article exists given it's content can fit in a single tweet. It's 90% finger wagging "you don't know what I know" and 1 sentence of the point. Anyways, this sentiment has become popular recently for some bizarre reason. All of the things that are the "real strengths" are in fact only possible because of virtual dom. So in my eyes the virtual dom is the important part, as the enabler.

chenglou 12y ago
Dan Abramov is a very knowledgeable React person, so it's not just random finger wagging. It's a shared sentiment in the React development team. Virtual DOM didn't enable React's component composition. Unidirectional data flow also has nothing to do with a virtual DOM.
- Touche 12y ago
  Well, if it's not "random finger wagging" then that makes up for the fact that he spends several paragraphs berating the reader for not being as smart as he is and seeing what he sees and spends exactly 1 sentence explaining what it is that he sees.