5 ms·

Everyone has their preferences but personally I have never used a framework that got everything perfect. I'm not surprised that the author thinks cycle is super

by n0us 11y ago

Everyone has their preferences but personally I have never used a framework that got everything perfect. I'm not surprised that the author thinks cycle is superior since he wrote the library. In other news the forecast calls for more JS frameworks today with a high chance of more JS frameworks later this week continuing with intermittent churn for the rest of the JS season.

pekk 11y ago
As someone who is mostly a spectator lagging months behind the JS framework du jour, it would be helpful if these discussions were a little less personal and a little more objective, even if cooperation isn't in the cards. I really don't have the time or patience to sort through all the WWE-style back and forth, and it is really painful to make a new project using every new thing just to see if it is any good.
- trowawee 11y ago
  I don't know that there's a way for them to be "objective". Like n0us said, no framework's perfect, and anybody who chooses something or builds something is going to tell you the thing they chose or built is the best, or at least better; if they didn't think that, they'd be using a different option. I've used React and Angular. They're both fine. They're just ways of doing the job. You can build stuff in them. The whole "pick a side and engage in a holy war" style of debate in programming is ridiculous, but it gets the clicks and pays the bills.
- n0us 11y ago
  For me the solution has been to pick a relatively popular library, work around the quirks, then just DONT UPGRADE the package. EVER. (Unless there is some real benefit to the end user or a security issue or something) As a solo developer trying to bootstrap a startup I started out 8 months ago with React, I have had a reasonably good experience with React itself. For a pre 1.0 project it's surprisingly stable and once you figure out what you're doing I've been able to move relatively quickly. The big holdup has been the supporting libraries. Some have been an absolute mess but the solution to that is that once I got it working, just don't touch it and don't buy into the promises that it's always going to be the next version that solves the issues. I didn't opt for Redux and went with Fluxxor instead which has worked reasonably well but I kept getting errors and ended up forking it to fix the problem. I'm not going to go back and use Redux for everything because someone told me it's better. I am now on my 3rd build tool over this timeline. I am now on Webpack because people kept promising that the next one would be better. I struggled to finally get React-Hotloader to work and occasionally it works but most of the time I just get Invariant Violation errors and have to do a full reload. I had to jump through hoops to get this to work and enable CORS etc for virtually no benefit. It will almost certainly be my last build tool for a while. The pattern with JS from my viewpoint has been to overhaul entire libraries because it's not quite right. It seems that what these developers don't realize is that when you solve one problem you often introduce another. Once you have a working solution there isn't really much incentive to change things. This guy laments that there is not a good way to do pure JS instead of JSX but you know what? JSX is fine. I already need a build tool to use ES6, and as long as you are consistent you shouldn't run into too many issues using the pure JS solution that comes with React if that's what you really want to do. JSX might be ugly but I would rather just deal with the ugliness and settle for good enough then keep creating extra work for myself in search of perfect. My goal is to build an app. I don't have the time or inclination to try out libraries like cycle or elm every time someone brags about how perfect they are just because they might provide me with a little benefit in terms of ease of development. I am perfectly fine with sitting back and reaping the benefit of other peoples' WWE-style back and forth even if I have to wait a year or more for things to stabilize.
  - sotojuan 11y ago
    I've never used it, but I am surprised you haven't looked into Ember. It's a bigger cognitive load and might not be a good fit for small projects, but I feel like this recent blog post[1] was made for you. [1] https://medium.com/@jonpitch/ember-get-shit-done-36383c2ccc53#.71m1es8id https://medium.com/@jonpitch/ember-get-shit-done-36383c2ccc5...
  - EvanPlaice 11y ago
    I hate to break it to you but WebPack is also riding the peak of a hype cycle right now. It doesn't natively support the future ES6-module standard. Once browsers start providing native module loading support, devs will likely migrate en masse to JSPM. JSPM is the (previously missing) package manager for front-end libraries. It supports transpiling (babel, traceur, typescript) out of the box and also handles bundling.
    - Akkuma 11y ago
      WebPack 2.0 does support ES6 module import statements. In fact, it does tree shaking now too, but only if you use import {x} from foo.
      - EvanPlaice 11y ago
        Oh, cool. I didn't realize webpack 2 was released with ES6 module support. Import {x} from 'foo' Looks like it's going to be the spec for ES6 modules anyway so it's probably a good thing that you have to it for tree shaking.
  - danabramov 11y ago
    >I struggled to finally get React-Hotloader to work and occasionally it works but most of the time I just get Invariant Violation errors and have to do a full reload. Have you considered reporting a bug?
crimsonalucard 11y ago
Although the author is biased, he is presenting valid criticism for fundamental flaws that truly make React inferior from a structural standpoint. Additionally, he presents the framework/language Elm, a library he is not really involved in, as a superior alternative.
- slorber 11y ago
  I agree that some points are actually valid (conceptually). However React permits to do useful compromises on purity for practicity. In Elm you have to hack the system to give the focus to a single input or use an external lib... See https://github.com/evancz/elm-architecture-tutorial/issues/49 https://github.com/evancz/elm-architecture-tutorial/issues/4...
- Scriptor 11y ago
  The author even anticipated your parent comment's argument and used Elm for this very reason. He seems to make it reasonably clear where Elm's approach is different from that of Cycle.js and still both are preferable to React/Reduct.
charlysisto 11y ago
Immutability, stateless function (or referential transparency), the ability to reason about state, the edge it gives to concurrency etc these are all valid, and objective arguments. It might not be the end of the discussion but at some point the churn is going to settle down and let a framework/lib/language mature in a rich and reliable ecosystem. I think the churn and js fatigue is a reason to have more of those conversation rather than less because we want to get there faster not later....

by n0us 11y ago

pekk 11y ago

As someone who is mostly a spectator lagging months behind the JS framework du jour, it would be helpful if these discussions were a little less personal and a little more objective, even if cooperation isn't in the cards. I really don't have the time or patience to sort through all the WWE-style back and forth, and it is really painful to make a new project using every new thing just to see if it is any good.

trowawee 11y ago
I don't know that there's a way for them to be "objective". Like n0us said, no framework's perfect, and anybody who chooses something or builds something is going to tell you the thing they chose or built is the best, or at least better; if they didn't think that, they'd be using a different option. I've used React and Angular. They're both fine. They're just ways of doing the job. You can build stuff in them. The whole "pick a side and engage in a holy war" style of debate in programming is ridiculous, but it gets the clicks and pays the bills.
n0us 11y ago
For me the solution has been to pick a relatively popular library, work around the quirks, then just DONT UPGRADE the package. EVER. (Unless there is some real benefit to the end user or a security issue or something) As a solo developer trying to bootstrap a startup I started out 8 months ago with React, I have had a reasonably good experience with React itself. For a pre 1.0 project it's surprisingly stable and once you figure out what you're doing I've been able to move relatively quickly. The big holdup has been the supporting libraries. Some have been an absolute mess but the solution to that is that once I got it working, just don't touch it and don't buy into the promises that it's always going to be the next version that solves the issues. I didn't opt for Redux and went with Fluxxor instead which has worked reasonably well but I kept getting errors and ended up forking it to fix the problem. I'm not going to go back and use Redux for everything because someone told me it's better. I am now on my 3rd build tool over this timeline. I am now on Webpack because people kept promising that the next one would be better. I struggled to finally get React-Hotloader to work and occasionally it works but most of the time I just get Invariant Violation errors and have to do a full reload. I had to jump through hoops to get this to work and enable CORS etc for virtually no benefit. It will almost certainly be my last build tool for a while. The pattern with JS from my viewpoint has been to overhaul entire libraries because it's not quite right. It seems that what these developers don't realize is that when you solve one problem you often introduce another. Once you have a working solution there isn't really much incentive to change things. This guy laments that there is not a good way to do pure JS instead of JSX but you know what? JSX is fine. I already need a build tool to use ES6, and as long as you are consistent you shouldn't run into too many issues using the pure JS solution that comes with React if that's what you really want to do. JSX might be ugly but I would rather just deal with the ugliness and settle for good enough then keep creating extra work for myself in search of perfect. My goal is to build an app. I don't have the time or inclination to try out libraries like cycle or elm every time someone brags about how perfect they are just because they might provide me with a little benefit in terms of ease of development. I am perfectly fine with sitting back and reaping the benefit of other peoples' WWE-style back and forth even if I have to wait a year or more for things to stabilize.
- sotojuan 11y ago
  I've never used it, but I am surprised you haven't looked into Ember. It's a bigger cognitive load and might not be a good fit for small projects, but I feel like this recent blog post[1] was made for you. [1] https://medium.com/@jonpitch/ember-get-shit-done-36383c2ccc53#.71m1es8id https://medium.com/@jonpitch/ember-get-shit-done-36383c2ccc5...
- EvanPlaice 11y ago
  I hate to break it to you but WebPack is also riding the peak of a hype cycle right now. It doesn't natively support the future ES6-module standard. Once browsers start providing native module loading support, devs will likely migrate en masse to JSPM. JSPM is the (previously missing) package manager for front-end libraries. It supports transpiling (babel, traceur, typescript) out of the box and also handles bundling.
  - Akkuma 11y ago
    WebPack 2.0 does support ES6 module import statements. In fact, it does tree shaking now too, but only if you use import {x} from foo.
    - EvanPlaice 11y ago
      Oh, cool. I didn't realize webpack 2 was released with ES6 module support. Import {x} from 'foo' Looks like it's going to be the spec for ES6 modules anyway so it's probably a good thing that you have to it for tree shaking.
- danabramov 11y ago
  >I struggled to finally get React-Hotloader to work and occasionally it works but most of the time I just get Invariant Violation errors and have to do a full reload. Have you considered reporting a bug?

crimsonalucard 11y ago

Although the author is biased, he is presenting valid criticism for fundamental flaws that truly make React inferior from a structural standpoint. Additionally, he presents the framework/language Elm, a library he is not really involved in, as a superior alternative.

slorber 11y ago
I agree that some points are actually valid (conceptually). However React permits to do useful compromises on purity for practicity. In Elm you have to hack the system to give the focus to a single input or use an external lib... See https://github.com/evancz/elm-architecture-tutorial/issues/49 https://github.com/evancz/elm-architecture-tutorial/issues/4...
Scriptor 11y ago
The author even anticipated your parent comment's argument and used Elm for this very reason. He seems to make it reasonably clear where Elm's approach is different from that of Cycle.js and still both are preferable to React/Reduct.

charlysisto 11y ago

Immutability, stateless function (or referential transparency), the ability to reason about state, the edge it gives to concurrency etc these are all valid, and objective arguments. It might not be the end of the discussion but at some point the churn is going to settle down and let a framework/lib/language mature in a rich and reliable ecosystem. I think the churn and js fatigue is a reason to have more of those conversation rather than less because we want to get there faster not later....