5 ms·

To be honest, this whole thing just seems like a vague rant. It's full of hand-wavy statements like 'Once you learn Elm or Cycle, getting things done will be mo

To be honest, this whole thing just seems like a vague rant. It's full of hand-wavy statements like 'Once you learn Elm or Cycle, getting things done will be more productive' with only vague anecdotes to back them up, with no specific examples of worked problems. The section on JSX & the React.createElement API is a weird diversion, because these aspects are so unrelated to the high level code structure complaints that they belong in a different article. Putting that aside, this section seems unfair at best. Firstly the JSX syntax is disregarded due to verbosity[0]. Okay, not to everyone's taste. However the author then goes on to making a comparison between React's createElement/createFactory APIs and the hyperscript-helpers npm package, which is incredibly uncharitable as the former is a performant, low level API intended for building ergonomic APIs on top of, and the latter is a high level, ergonomics-centric API. Redux is a small library, which needs to be used underneath application-specific abstractions to avoid boilerplate. Not everyone will want to come up with such abstractions themselves. I can certainly see the value for an ergonomic, high-level, Rails-like project on top of React + Redux. Maybe that's the article the author should have written. [0] I would argue many developers actually find the verbosity of JSX helpful when dealing with large trees of components, as compared to nested function calls. The fact that JSX closing tags repeat the tag name is key to this.

vcarl 11y ago
Agreed, opting not to use JSX and then complaining about a lack of ergonomics seems pretty contrived. Yeah, the raw function calls aren't particularly friendly, that's why JSX exists. If more people opted not to use JSX, I'm sure there would be better options for friendly createElement/createFactory. He also doesn't mention the learning curve, and I'd argue that function calls for DOM is less beginner friendly. It's pretty easy to mentally map a render function to its output because they're so syntactically similar.
- Ronsenshi 11y ago
  Not sure how much relevant it is, but author's stance on JSX reminds me of a meme known as "Baton Roue" which depicts person throwing a stick into the wheel of the bicycle he's riding. In other words - sure you don't have to use JSX, but if you really decided to work with React you are highly advised to go with JSX because that's what makes work with it much easier: you get familiar syntax which is easily parseable when somebody else is reading a code. However, if you decided against JSX then you're doing yourself a disservice, because sticking to raw JS does not improve development process at all, probably even opposite.
- mercer 11y ago
  Furthermore, in the situations where I cannot use JSX, I actually like the explicit nature of how you need to specify properties. In fact, as a general comment, the article actually solidifies my choice of using React precisely because it's 'verbose' in the right way: it makes working with something (inherently?) messy explicit, and as a result much easier and pleasant. As I learned how to work with React I've had quite a few moments where I got frustrated trying to get something done, only to realize that I was doing it wrong and that React was 'coaxing' me into doing things right. Very often, without trying, I'd do things in a way that suddenly made things 'click', where in the past my solution would've turned out messy, and where in the future even using other libraries/frameworks and applying what I learned will lead to a better result. I really think the 'pit of success' idea applies (which was mentioned in the initial video presenting React).
Lazare 11y ago
> However the author then goes on to making a comparison between React's createElement/createFactory APIs and the hyperscript-helpers npm package, which is incredibly uncharitable It's more than uncharitable; it's nonsensical. There is quite good hyperscript support for React. If hyperscript is so great that being able to use it with Cycle is a plus for Cycle, then logically it's also a plus for React.
ernestipark 11y ago
It does feel vague, I'd love to see examples of how the paradigm helps you 'focus on features'. The examples given in the blog seem mostly about syntax/verbosity in nature which is not as interesting as evolving clarity of thought and mental overhead. I haven't explored Cycle.js or Elm, but a few comments on the React/Redux side as I've recently adopted it at work and have found it to be a huge pleasure to work with. There does tend to be a lot of syntactic boilerplate/wiring up of things in Redux which is definitely a bit of a drag, but the most important thing that Redux has done for me is make data flow very clear and easy to trace and understand. Even with Facebook's impls of Flux, and Backbone before that, data flow was very tricky and cloudy at best. As for the criticism that setup has a lot of moving pieces, I sort of agree, but I found myself up and running in a few hours after reading the (incredibly well written) documentation and within a few days I was already more productive than I was previously without Redux. Elm also gets out your way by having immutable types built-in, signals built-in, “dispatcher” (Mailbox) built-in, and ADTs for action types built-in. The experience is great for a developer and the initial setup is quicker. Built-ins are a tradeoff just like anything else. Redux gives you enough to get going, and has a strong ecosystem and community of libs that most people will use (react-redux, thunk middleware). Built-ins might help you get started faster, but maybe that doesn't fly for a company of 100 engineers where use cases vary and customization is important. Lastly, the author claims Cycle.js lets you 'focus on features'. From past experience, this makes it sound like there's just a lot of magic and it's easy to get lost in it all (see Rails). This may or may not be the case with Cycle.js, but that is immediately my gut reaction. I feel Redux gives a pretty powerful philosophy and clear way to handle front-end apps that can scale well to larger apps. If there are some things Cycle.js is doing well over Redux, I want to hear more about those! The arguments against Redux without that context feel pretty weak.
justaaron 11y ago
in keeping with the spirit of extracting sense and meaning where it may be implied rather than enumerated, I grokked: 1) noise is bad. 2) web fashions come and go 3) the trendy is not always right. i happen to agree with these points in many regards, so perhaps I'm a poor reader and merely projecting... but yeah, I'm pretty over the militant "a react in every stack" approach... ditto every other myopic temporary obsession... you realize this after a couple hegelian cycles of thesis, antithesis, synthesis... i mean, when yesterdays baby becomes todays bathwater and it's time to throw it all out, or perhaps consider renaming "common sense" that rare balanced mix of functional object-oriented reactive structured aspect oriented programming as a service platform...in the cloud
- EvanPlaice 11y ago
  I don't think it's as much "a React in every stack" as "observables solve a lot of problems that couldn't previously be solved with promises." Handling async events can be difficult and error probe. Observables finally provide a useful pattern to that can be used to effectively manage async operations on data. React os the poster child because it came first but Angular2 also uses Rxjs (ie Reactive Extensions for JS). The poster goes to the opposite extreme, "if we're doing functional programming in JS, everything should be functional. Here's what I use, everybody who doesn't also use it is dumb." Subjective opinion addressed as fact.
coldtea 11y ago
>To be honest, this whole thing just seems like a vague rant. It's full of hand-wavy statements like 'Once you learn Elm or Cycle, getting things done will be more productive' with only vague anecdotes to back them up, with no specific examples of worked problems. Perhaps missed the whole second part of the article, which gives several concrete examples and concerns.

vcarl 11y ago

Agreed, opting not to use JSX and then complaining about a lack of ergonomics seems pretty contrived. Yeah, the raw function calls aren't particularly friendly, that's why JSX exists. If more people opted not to use JSX, I'm sure there would be better options for friendly createElement/createFactory. He also doesn't mention the learning curve, and I'd argue that function calls for DOM is less beginner friendly. It's pretty easy to mentally map a render function to its output because they're so syntactically similar.

Ronsenshi 11y ago
Not sure how much relevant it is, but author's stance on JSX reminds me of a meme known as "Baton Roue" which depicts person throwing a stick into the wheel of the bicycle he's riding. In other words - sure you don't have to use JSX, but if you really decided to work with React you are highly advised to go with JSX because that's what makes work with it much easier: you get familiar syntax which is easily parseable when somebody else is reading a code. However, if you decided against JSX then you're doing yourself a disservice, because sticking to raw JS does not improve development process at all, probably even opposite.
mercer 11y ago
Furthermore, in the situations where I cannot use JSX, I actually like the explicit nature of how you need to specify properties. In fact, as a general comment, the article actually solidifies my choice of using React precisely because it's 'verbose' in the right way: it makes working with something (inherently?) messy explicit, and as a result much easier and pleasant. As I learned how to work with React I've had quite a few moments where I got frustrated trying to get something done, only to realize that I was doing it wrong and that React was 'coaxing' me into doing things right. Very often, without trying, I'd do things in a way that suddenly made things 'click', where in the past my solution would've turned out messy, and where in the future even using other libraries/frameworks and applying what I learned will lead to a better result. I really think the 'pit of success' idea applies (which was mentioned in the initial video presenting React).

Lazare 11y ago

> However the author then goes on to making a comparison between React's createElement/createFactory APIs and the hyperscript-helpers npm package, which is incredibly uncharitable It's more than uncharitable; it's nonsensical. There is quite good hyperscript support for React. If hyperscript is so great that being able to use it with Cycle is a plus for Cycle, then logically it's also a plus for React.

ernestipark 11y ago

It does feel vague, I'd love to see examples of how the paradigm helps you 'focus on features'. The examples given in the blog seem mostly about syntax/verbosity in nature which is not as interesting as evolving clarity of thought and mental overhead. I haven't explored Cycle.js or Elm, but a few comments on the React/Redux side as I've recently adopted it at work and have found it to be a huge pleasure to work with. There does tend to be a lot of syntactic boilerplate/wiring up of things in Redux which is definitely a bit of a drag, but the most important thing that Redux has done for me is make data flow very clear and easy to trace and understand. Even with Facebook's impls of Flux, and Backbone before that, data flow was very tricky and cloudy at best. As for the criticism that setup has a lot of moving pieces, I sort of agree, but I found myself up and running in a few hours after reading the (incredibly well written) documentation and within a few days I was already more productive than I was previously without Redux. Elm also gets out your way by having immutable types built-in, signals built-in, “dispatcher” (Mailbox) built-in, and ADTs for action types built-in. The experience is great for a developer and the initial setup is quicker. Built-ins are a tradeoff just like anything else. Redux gives you enough to get going, and has a strong ecosystem and community of libs that most people will use (react-redux, thunk middleware). Built-ins might help you get started faster, but maybe that doesn't fly for a company of 100 engineers where use cases vary and customization is important. Lastly, the author claims Cycle.js lets you 'focus on features'. From past experience, this makes it sound like there's just a lot of magic and it's easy to get lost in it all (see Rails). This may or may not be the case with Cycle.js, but that is immediately my gut reaction. I feel Redux gives a pretty powerful philosophy and clear way to handle front-end apps that can scale well to larger apps. If there are some things Cycle.js is doing well over Redux, I want to hear more about those! The arguments against Redux without that context feel pretty weak.

justaaron 11y ago

in keeping with the spirit of extracting sense and meaning where it may be implied rather than enumerated, I grokked: 1) noise is bad. 2) web fashions come and go 3) the trendy is not always right. i happen to agree with these points in many regards, so perhaps I'm a poor reader and merely projecting... but yeah, I'm pretty over the militant "a react in every stack" approach... ditto every other myopic temporary obsession... you realize this after a couple hegelian cycles of thesis, antithesis, synthesis... i mean, when yesterdays baby becomes todays bathwater and it's time to throw it all out, or perhaps consider renaming "common sense" that rare balanced mix of functional object-oriented reactive structured aspect oriented programming as a service platform...in the cloud

EvanPlaice 11y ago
I don't think it's as much "a React in every stack" as "observables solve a lot of problems that couldn't previously be solved with promises." Handling async events can be difficult and error probe. Observables finally provide a useful pattern to that can be used to effectively manage async operations on data. React os the poster child because it came first but Angular2 also uses Rxjs (ie Reactive Extensions for JS). The poster goes to the opposite extreme, "if we're doing functional programming in JS, everything should be functional. Here's what I use, everybody who doesn't also use it is dumb." Subjective opinion addressed as fact.

coldtea 11y ago

>To be honest, this whole thing just seems like a vague rant. It's full of hand-wavy statements like 'Once you learn Elm or Cycle, getting things done will be more productive' with only vague anecdotes to back them up, with no specific examples of worked problems. Perhaps missed the whole second part of the article, which gives several concrete examples and concerns.