5 ms·

Speaking as someone not intimately involved in the web development community, React looks decent but absolutely not worthy of the obscene amounts of hype it rec

Speaking as someone not intimately involved in the web development community, React looks decent but absolutely not worthy of the obscene amounts of hype it received... unless what web devs had before was really that horrible, because that's the impression I got. Though from what I can tell, jQuery and React are somewhat orthogonal tools, as I have used the former and it goes beyond rendering views. What I cannot figure out is all the harping on about "functional style". The React examples all felt more Smalltalk-ish to me than anything else (I suppose unsurprising given JavaScript's vague influences from Self). The use of closures doesn't really change the conceptual patterns much. Is it because the tutorial can only cover so much ground, or is it that since some of the primary buzz around FP was the management of mutable state, to the point that people now instinctively associate the idea with FP?

xixixao 11y ago
Before React: to make a transition, let's change this, this and then that, mutating state on every step. After React: have one pure function, which takes as input the current state and produces the desired output. This is the main shift. It's very similar to how imperative programming is done in Java vs Haskell.
- vezzy-fnord 11y ago
  Are they pure? I don't think JS has any way to guarantee referential transparency, though of course the use of a virtual DOM can mitigate side effects by having well-defined behavior. Furthermore, the input-process-output model can hardly warrant being called "functional" in of itself, unless you really want to overload the term. The React way of independent handlers that trigger events which incrementally calculate state and update views, is, in fact, quite similar to how Smalltalk UI paradigms work, right down to the installation of an event handler resembling a message send operation. If you don't believe me, check out the Morphic framework that Self uses to implement its environment UI. The similarities are striking: http://handbook.selflanguage.org/current/morphic.html http://handbook.selflanguage.org/current/morphic.html
  - xixixao 11y ago
    If they are not pure, you are literally making an error (as the framework states they are supposed to be pure). input-process-output is how pure functional languages (such as Haskell) deal with imperative coding. You push the imperative part to the top of the call stack and try to keep the rest of the computation pure. JavaScript inherited quite a bit from Smalltalk, so you will find similarities like these in JS in general. Flux supplements the standard React bubbling of events up the chain of components with a simpler, singular flow, making it even more functional.
    - vezzy-fnord 11y ago
      That sounds like a try-hard simplification. Input-process-output is pretty much a generic metaphor for programming in general. I don't think React has anything like monadic encapsulation (not that a language like JS can conveniently accommodate it). You're observing a few high-level properties of a given paradigm and extrapolating an inferred architecture solely from those points. In fact, you're equivocating the entire management and abstraction of mutable state as an inherently "functional" thing, which it is not. OO is just as much capable of factoring state as a virtual resource that you explicitly make transitions to and from and transparently or visibly share increments across object boundaries, as this is exactly what e.g. Self does with Morphic, right down to the same event handler structure. Just because one is a lambda and the other is called a method doesn't make a huge difference. I'm saying that just about all of React's insights were done previously almost verbatim in thoroughly object-oriented environments. That some FP evangelists have a kneejerk hatred for it doesn't mean the mental gymnastics for insisting one over the other is necessary. They can be complementary.
      - peterhunt 11y ago
        I haven't used Morphic in years (and I used it in Squeak). While you're right that Morphic shares some things in common with React, the fundamental difference is that when a composite morph receives an event and needs to change, it has to explicitly pass messages to all of its submorphs to transition them to the next state. With React you simply throw out the old subtree and replace it with a new one. This is similar to how drawOn: works, except that throwing out and re-instantiating your submorphs for every drawOn: is expensive and loses UI state. React gives you this abstraction. Additionally I'm not sure where you're getting this "JS can't be functional" opinion from. Just because it doesn't give you compile-time or runtime guarantees, or because the syntax may be more clunky, doesn't mean you can't get these benefits by convention.
- shostack 11y ago
  Can you dumb this down slightly for an "early" developer with a real world example by any chance? I'm not grokking the significance of why changing everything and having mutations is bad.
  - orthoganol 11y ago
    It's just nicer to use if you have complex UI. OP's response was poor IMO, just because something follows some abstract principles doesn't necessarily give it value for us. I'll give you examples of things I've worked on where React made sense & where it didn't: -E.g. use React (or Backbone, Angular, etc.): A real-time document editor, with many interacting components, with lots of real time updating of the UI. Definitely needed a framework like that, and it was great. -E.g. don't use React, because in these cases it's a total Rube Goldberg machine (extra steps to achieve the exact same outcome): Basic web app with some ajax submissions, adding results to DOM type of stuff. Maybe small html fragments cloned, inserted by jQuery. No extra fancy client interactivity. ^If people claim you should use React for the latter (undoubtedly some will), they are very likely just people who follow trends to follow trends, or maybe don't have a ton of web experience and it's one of the few things they've learned and are sticking to. It's just so unnecessary (not to mention 100kb+ of overhead, & in my experience comes out to about x3 the amount of code). But yeah, absolutely use React if it's anything like the first use case.
    - hodwik 11y ago
      What technologies would you prefer for the latter case?
      - meestaahjoshee 11y ago
        "Basic web app with some ajax submissions, adding results to DOM type of stuff. Maybe small html fragments cloned, inserted by jQuery." regular old html and jQuery + ajax.
    - xixixao 11y ago
      1) React does not make simple apps overly complex. It might feel like more work if you are more used to jQuery. If you are used to React instead, it really won't have a huge negative impact on a small app. 2) React will scale. It will be a much better vehicle for future development (as you admit, it is more suited for more complex cases than jQuery). I was not making a judgement on the value of the approach, although I personally believe that this paradigm shift has a huge positive impact and is applicable in lots of cases. If I can choose between lots of computation intertwined with state mutation and a declarative approach where the mutation happens on the smallest scale, up the call stack, I will always choose the latter (of course, unless you have to mutate to gain performance).
- barrkel 11y ago
  Before React: to make a transition, let's change this, this and then that, mutating state on every step That's nonsense. There have been data binding frameworks used for well over a decade in JS development - I know I wrote one in the early 2000s. You can't write a decently sized app in JS without developing something like data binding, unless you love busywork and bugs, or have zero prior experience of what came before in GUI frameworks. Data binding is designed exactly to prevent the need to explicitly mutate all the views at every point that the model can change. Instead you write bindings that project the model into the view, and make the model reactive, so that changes to it propagate automatically. It's the same in any decently sized Backbone app - that's why the Collection and Model give you all these events. What's new in React is the idea of cheaply creating a virtual DOM and extracting a set of diffs from it that can then be applied to the real DOM. I did something vaguely similar, again in the early 2000s, but the motive then was to reduce the amount of data on the wire (the server had a data-bound model of what was displayed on screen, but only sent diffs back to the client). It's a neat idea and an excellent implementation, but it's not original or groundbreaking.
aggronn 11y ago
> unless what web devs had before was really that horrible As a big fan of react, I think that this isn't really a fair thing to say. I feel as though this statement implies that front end dev is not complex and therefore it surprises you that there is room for significant improvement. I'm sure that's not what you were thinking, but really, building complex imperative UIs with state can be very difficult, and react does represent a new step in the paradigm shift away from imperative development. Whether React is the future or not, components and composition are here to stay, and I think a increasingly large portion of the community is interested in writing web applications with immutability--all of which suites flux (and react) very well, and does not suite jquery very well. React doesn't enable anything that you simply couldn't do with jquery and backbone, but it does make a lot of it way easier and reduces overall complexity by a ton, especially if you're developing with component structure and immutability in mind.
wrsh07 11y ago
It's considered "functional style" because react is a functional reactive programming framework. This is about more than just managing state. If you're not familiar with FRP, then I think learning more about the theoretical side might help clarify why everyone is describing react as functional.
- vezzy-fnord 11y ago
  I am familiar with FRP. I have never seen React described as FRP, and a Google search for "React FRP" confirms that this is a heterodox belief and in fact it is you who might need to learn more.
  - wrsh07 11y ago
    Oh shoot, you're totally right. I was thinking about react + flux, eg this line from the flux overview [https://facebook.github.io/flux/docs/overview.html https://facebook.github.io/flux/docs/overview.html]: "This structure allows us to reason easily about our application in a way that is reminiscent of functional reactive programming, or more specifically data-flow programming or flow-based programming, where data flows through the application in a single direction — there are no two-way bindings" Anyway, I imagine people refer to react as "functional" because they conflate "declarative programming" with "functional programming."
    - vezzy-fnord 11y ago
      Right. Apologies if I came across as abrasive.
jamra 11y ago
I think that the reverence of current frameworks is a response to the faults of the previous framework that was revered. We started with JQuery. It was fast and had a simple API. People started to learn JQuery more than they learned Javascript. You even had Stack Overflow answers that nudged people away from Javascript stating the robustness of JQuery's libraries (specifically how it worked the same on every browser). Then, we realized that we did not want to set up our events as one offs. The result was very spaghetti code. Backbone came out of this. It was light and allowed us to modularize our code. However, it didn't really give enough structure so we switched to Angular. Angular was the holy grail. It did everything for us. Events automatically propagated state changes to our objects and automatically redrew our view afterwards. We didn't have to think anymore. It did the thinking for us. Little by little, we started to realize that when you outsource your thinking to your framework, you end up getting stuck in crevices that your framework hasn't anticipated. In Angular, it's difficult to share state between controllers. It's outstandingly slow in that it redraws far too often. The thing that I personally was most sore about was the fact that Angular, similarly to JQuery became the new Javascript. Instead of learning how Javascript works, you needed to learn how to use Angular. This means that you couldn't just port in good Javascript code directly. You needed an Angular directive. Try using a simple charting library such as HighCharts. The examples don't work as is. You need to use the Angular version. It gets messy and all that modularization starts to work against you. It works against you because you don't have control over your javascript. Here comes React. It takes a step back from the hand holding of Angular and just handles the rendering. You can design your Javascript classes and functions as you see fit. If you need to port in Highcharts, go for it. You can use the JQuery plugin if it suits you. All React really does is handle the rendering and re-rendering of your dynamic content on screen. It will also allow you to propagate events that will change the state of your objects, but does not do so in the same way Angular did. It gives you more granular control. I suggest you try it out. The JSX syntax might throw you off at first, but don't give up. It's necessary for how React obtains its amazing speed. If you're just getting started, don't worry about the difference between Shadow and Virtual DOM.
- thoman23 11y ago
  It absolutely is not difficult to share state across Angular controllers. Services work great for this. I also dispute that you are too far removed from "vanilla" Javascript when using Angular. I recently integrated some externally written d3 javascript code and it works as expected without forcing a conversion to "the Angular way". Finally, I certainly dispute that Angular is too slow. Our Investmynd app has a fairly data and interaction heavy front end, and its performance is quite snappy if I do say so myself. :) Now what I do think is true is that Angular is a fairly complicated beast, which when combined with the poor standard documentation, makes it a non-trivial endeavor to learn and use properly.

xixixao 11y ago

Before React: to make a transition, let's change this, this and then that, mutating state on every step. After React: have one pure function, which takes as input the current state and produces the desired output. This is the main shift. It's very similar to how imperative programming is done in Java vs Haskell.

vezzy-fnord 11y ago
Are they pure? I don't think JS has any way to guarantee referential transparency, though of course the use of a virtual DOM can mitigate side effects by having well-defined behavior. Furthermore, the input-process-output model can hardly warrant being called "functional" in of itself, unless you really want to overload the term. The React way of independent handlers that trigger events which incrementally calculate state and update views, is, in fact, quite similar to how Smalltalk UI paradigms work, right down to the installation of an event handler resembling a message send operation. If you don't believe me, check out the Morphic framework that Self uses to implement its environment UI. The similarities are striking: http://handbook.selflanguage.org/current/morphic.html http://handbook.selflanguage.org/current/morphic.html
- xixixao 11y ago
  If they are not pure, you are literally making an error (as the framework states they are supposed to be pure). input-process-output is how pure functional languages (such as Haskell) deal with imperative coding. You push the imperative part to the top of the call stack and try to keep the rest of the computation pure. JavaScript inherited quite a bit from Smalltalk, so you will find similarities like these in JS in general. Flux supplements the standard React bubbling of events up the chain of components with a simpler, singular flow, making it even more functional.
  - vezzy-fnord 11y ago
    That sounds like a try-hard simplification. Input-process-output is pretty much a generic metaphor for programming in general. I don't think React has anything like monadic encapsulation (not that a language like JS can conveniently accommodate it). You're observing a few high-level properties of a given paradigm and extrapolating an inferred architecture solely from those points. In fact, you're equivocating the entire management and abstraction of mutable state as an inherently "functional" thing, which it is not. OO is just as much capable of factoring state as a virtual resource that you explicitly make transitions to and from and transparently or visibly share increments across object boundaries, as this is exactly what e.g. Self does with Morphic, right down to the same event handler structure. Just because one is a lambda and the other is called a method doesn't make a huge difference. I'm saying that just about all of React's insights were done previously almost verbatim in thoroughly object-oriented environments. That some FP evangelists have a kneejerk hatred for it doesn't mean the mental gymnastics for insisting one over the other is necessary. They can be complementary.
    - peterhunt 11y ago
      I haven't used Morphic in years (and I used it in Squeak). While you're right that Morphic shares some things in common with React, the fundamental difference is that when a composite morph receives an event and needs to change, it has to explicitly pass messages to all of its submorphs to transition them to the next state. With React you simply throw out the old subtree and replace it with a new one. This is similar to how drawOn: works, except that throwing out and re-instantiating your submorphs for every drawOn: is expensive and loses UI state. React gives you this abstraction. Additionally I'm not sure where you're getting this "JS can't be functional" opinion from. Just because it doesn't give you compile-time or runtime guarantees, or because the syntax may be more clunky, doesn't mean you can't get these benefits by convention.
shostack 11y ago
Can you dumb this down slightly for an "early" developer with a real world example by any chance? I'm not grokking the significance of why changing everything and having mutations is bad.
- orthoganol 11y ago
  It's just nicer to use if you have complex UI. OP's response was poor IMO, just because something follows some abstract principles doesn't necessarily give it value for us. I'll give you examples of things I've worked on where React made sense & where it didn't: -E.g. use React (or Backbone, Angular, etc.): A real-time document editor, with many interacting components, with lots of real time updating of the UI. Definitely needed a framework like that, and it was great. -E.g. don't use React, because in these cases it's a total Rube Goldberg machine (extra steps to achieve the exact same outcome): Basic web app with some ajax submissions, adding results to DOM type of stuff. Maybe small html fragments cloned, inserted by jQuery. No extra fancy client interactivity. ^If people claim you should use React for the latter (undoubtedly some will), they are very likely just people who follow trends to follow trends, or maybe don't have a ton of web experience and it's one of the few things they've learned and are sticking to. It's just so unnecessary (not to mention 100kb+ of overhead, & in my experience comes out to about x3 the amount of code). But yeah, absolutely use React if it's anything like the first use case.
  - hodwik 11y ago
    What technologies would you prefer for the latter case?
    - meestaahjoshee 11y ago
      "Basic web app with some ajax submissions, adding results to DOM type of stuff. Maybe small html fragments cloned, inserted by jQuery." regular old html and jQuery + ajax.
  - xixixao 11y ago
    1) React does not make simple apps overly complex. It might feel like more work if you are more used to jQuery. If you are used to React instead, it really won't have a huge negative impact on a small app. 2) React will scale. It will be a much better vehicle for future development (as you admit, it is more suited for more complex cases than jQuery). I was not making a judgement on the value of the approach, although I personally believe that this paradigm shift has a huge positive impact and is applicable in lots of cases. If I can choose between lots of computation intertwined with state mutation and a declarative approach where the mutation happens on the smallest scale, up the call stack, I will always choose the latter (of course, unless you have to mutate to gain performance).
barrkel 11y ago
Before React: to make a transition, let's change this, this and then that, mutating state on every step That's nonsense. There have been data binding frameworks used for well over a decade in JS development - I know I wrote one in the early 2000s. You can't write a decently sized app in JS without developing something like data binding, unless you love busywork and bugs, or have zero prior experience of what came before in GUI frameworks. Data binding is designed exactly to prevent the need to explicitly mutate all the views at every point that the model can change. Instead you write bindings that project the model into the view, and make the model reactive, so that changes to it propagate automatically. It's the same in any decently sized Backbone app - that's why the Collection and Model give you all these events. What's new in React is the idea of cheaply creating a virtual DOM and extracting a set of diffs from it that can then be applied to the real DOM. I did something vaguely similar, again in the early 2000s, but the motive then was to reduce the amount of data on the wire (the server had a data-bound model of what was displayed on screen, but only sent diffs back to the client). It's a neat idea and an excellent implementation, but it's not original or groundbreaking.

aggronn 11y ago

> unless what web devs had before was really that horrible As a big fan of react, I think that this isn't really a fair thing to say. I feel as though this statement implies that front end dev is not complex and therefore it surprises you that there is room for significant improvement. I'm sure that's not what you were thinking, but really, building complex imperative UIs with state can be very difficult, and react does represent a new step in the paradigm shift away from imperative development. Whether React is the future or not, components and composition are here to stay, and I think a increasingly large portion of the community is interested in writing web applications with immutability--all of which suites flux (and react) very well, and does not suite jquery very well. React doesn't enable anything that you simply couldn't do with jquery and backbone, but it does make a lot of it way easier and reduces overall complexity by a ton, especially if you're developing with component structure and immutability in mind.

wrsh07 11y ago

It's considered "functional style" because react is a functional reactive programming framework. This is about more than just managing state. If you're not familiar with FRP, then I think learning more about the theoretical side might help clarify why everyone is describing react as functional.

vezzy-fnord 11y ago
I am familiar with FRP. I have never seen React described as FRP, and a Google search for "React FRP" confirms that this is a heterodox belief and in fact it is you who might need to learn more.
- wrsh07 11y ago
  Oh shoot, you're totally right. I was thinking about react + flux, eg this line from the flux overview [https://facebook.github.io/flux/docs/overview.html https://facebook.github.io/flux/docs/overview.html]: "This structure allows us to reason easily about our application in a way that is reminiscent of functional reactive programming, or more specifically data-flow programming or flow-based programming, where data flows through the application in a single direction — there are no two-way bindings" Anyway, I imagine people refer to react as "functional" because they conflate "declarative programming" with "functional programming."
  - vezzy-fnord 11y ago
    Right. Apologies if I came across as abrasive.

jamra 11y ago

I think that the reverence of current frameworks is a response to the faults of the previous framework that was revered. We started with JQuery. It was fast and had a simple API. People started to learn JQuery more than they learned Javascript. You even had Stack Overflow answers that nudged people away from Javascript stating the robustness of JQuery's libraries (specifically how it worked the same on every browser). Then, we realized that we did not want to set up our events as one offs. The result was very spaghetti code. Backbone came out of this. It was light and allowed us to modularize our code. However, it didn't really give enough structure so we switched to Angular. Angular was the holy grail. It did everything for us. Events automatically propagated state changes to our objects and automatically redrew our view afterwards. We didn't have to think anymore. It did the thinking for us. Little by little, we started to realize that when you outsource your thinking to your framework, you end up getting stuck in crevices that your framework hasn't anticipated. In Angular, it's difficult to share state between controllers. It's outstandingly slow in that it redraws far too often. The thing that I personally was most sore about was the fact that Angular, similarly to JQuery became the new Javascript. Instead of learning how Javascript works, you needed to learn how to use Angular. This means that you couldn't just port in good Javascript code directly. You needed an Angular directive. Try using a simple charting library such as HighCharts. The examples don't work as is. You need to use the Angular version. It gets messy and all that modularization starts to work against you. It works against you because you don't have control over your javascript. Here comes React. It takes a step back from the hand holding of Angular and just handles the rendering. You can design your Javascript classes and functions as you see fit. If you need to port in Highcharts, go for it. You can use the JQuery plugin if it suits you. All React really does is handle the rendering and re-rendering of your dynamic content on screen. It will also allow you to propagate events that will change the state of your objects, but does not do so in the same way Angular did. It gives you more granular control. I suggest you try it out. The JSX syntax might throw you off at first, but don't give up. It's necessary for how React obtains its amazing speed. If you're just getting started, don't worry about the difference between Shadow and Virtual DOM.

thoman23 11y ago
It absolutely is not difficult to share state across Angular controllers. Services work great for this. I also dispute that you are too far removed from "vanilla" Javascript when using Angular. I recently integrated some externally written d3 javascript code and it works as expected without forcing a conversion to "the Angular way". Finally, I certainly dispute that Angular is too slow. Our Investmynd app has a fairly data and interaction heavy front end, and its performance is quite snappy if I do say so myself. :) Now what I do think is true is that Angular is a fairly complicated beast, which when combined with the poor standard documentation, makes it a non-trivial endeavor to learn and use properly.