4 ms·

Plug and Play All Your Observable Streams With Cycle.js

24 points by staltz 11y ago

cmdv 11y ago
I've been playing with Cycle.js and was struggling a little even though I have previous experience in RxJS but after going through this article it really cleared up some fundamental aspects to Cycle.js :)
- RobertKerans 11y ago
  The PragProg book they just released uses RXJS && Cycle.JS: I'm about halfway though at the minute, it's been really good so far, and I'd recommend it if you're wanting a bit more detail.
Maarten88 11y ago
> This embedded content is from a site that does not comply with the Do Not Track (DNT) setting now enabled on your browser. Never seen that before; +1 for medium.com
- omphalos 11y ago
  Now if only they would stop requiring JavaScript to see images :)
bryanrasmussen 11y ago
Cycle.js http://cycle.js.org/ http://cycle.js.org/ says that it allows "thisless JavaScript: The use of functions and RxJS Observables allow for a JavaScript programming style without the this keyword. Cycle.js encourages you to create apps with functional practices. Without this, you can write more reusable code and define logic without tightly coupling it to data. See it for yourself, this cannot be found in Cycle.js TodoMVC." this, uh, doesn't seem to match my normal understanding of JS. Normally the method to reuse code is to change what 'this' refers to, but the statement above implies the existence of 'this' is a failure of JavaScript's design. I would like some elaboration.
- tobr 11y ago
  If you want to adopt a functional style, then there is little benefit to using `this` instead of regular arguments or closures, which are more versatile and follow more straightforward rules. I think most JS developers have been confused over the value of `this` more than once.
  - bryanrasmussen 11y ago
    I would think call and apply would be useful for a functional style, but no?
    - tobr 11y ago
      For sure, but probably more as a way to handle arguments than to set the context. Or to work in a more FP-ish way with an OO-ish API.
    - RobertKerans 11y ago
      YMMV, but I thought I would use them more regularly the more I wrote my JS in a functional style, but the use cases started to steadily dry up; it's gets much easier to write code that simply doesn't need to hold the reference in that way. Arrow functions help a great deal (there is no concept of `this` within them). Still very useful, but in very specific cases, or abstracted off into helpers. I've found `bind()` is much more useful (and will become moreso if the bind operator is okayed and optimised).
- Lazare 11y ago
  If you look at this jsbin, you might get a better feel for what's being discussed: https://jsbin.com/cejuyijahu/1/edit?js,console https://jsbin.com/cejuyijahu/1/edit?js,console If you use an OOP style (with classes and inheritance), then you end up needing to use the 'this' keyword. If you use a functional style, you don't. Is the functional style better? Does it let you write more reusable code, and avoid tightly coupling it to date? Eh...maybe. If you like that style, you'll probably be more productive that way (and be intrigued by Cycle.js). If you don't like that style, you won't be. Also: > the statement above implies the existence of 'this' is a failure of JavaScript's design It's certainly been a pain point, and there's a lot of confusion and debate over classes, prototypes, constructors, the this keyword, figuring out what 'this` even refers to at any given point, the 'new' keyword, etc. I'm not sure I'd agree that the existence of the 'this' keyword is a mistake (and I doubt the people behind Cycle.js would either), but I don't think it's controversial to note that you can avoid a lot of confusion and sidestep the whole thing, if you are of a mind, by just using plain functions returning objects as needed.
noelwelsh 11y ago
Holy hyperbole, Batman! That article took a long time to get to the point, and I'm a touch hesitant to use the same breathless tone as the author. As I understand it, the model is the same as Elm. Separating specifying the computation (in this case, defining the event processing graph) from running the computation is an old trick in FP circles[1]. It's great to see JS libraries moving forward, but it would sure be an easier read if the author dropped the embellishment. [1] Blog post about this: http://underscore.io/blog/posts/2015/04/28/monadic-io-laziness-makes-you-free.html http://underscore.io/blog/posts/2015/04/28/monadic-io-lazine...

24 points by staltz 11y ago

cmdv 11y ago

I've been playing with Cycle.js and was struggling a little even though I have previous experience in RxJS but after going through this article it really cleared up some fundamental aspects to Cycle.js :)

RobertKerans 11y ago
The PragProg book they just released uses RXJS && Cycle.JS: I'm about halfway though at the minute, it's been really good so far, and I'd recommend it if you're wanting a bit more detail.

Maarten88 11y ago

> This embedded content is from a site that does not comply with the Do Not Track (DNT) setting now enabled on your browser. Never seen that before; +1 for medium.com

omphalos 11y ago
Now if only they would stop requiring JavaScript to see images :)

bryanrasmussen 11y ago

Cycle.js http://cycle.js.org/ http://cycle.js.org/ says that it allows "thisless JavaScript: The use of functions and RxJS Observables allow for a JavaScript programming style without the this keyword. Cycle.js encourages you to create apps with functional practices. Without this, you can write more reusable code and define logic without tightly coupling it to data. See it for yourself, this cannot be found in Cycle.js TodoMVC." this, uh, doesn't seem to match my normal understanding of JS. Normally the method to reuse code is to change what 'this' refers to, but the statement above implies the existence of 'this' is a failure of JavaScript's design. I would like some elaboration.

tobr 11y ago
If you want to adopt a functional style, then there is little benefit to using `this` instead of regular arguments or closures, which are more versatile and follow more straightforward rules. I think most JS developers have been confused over the value of `this` more than once.
- bryanrasmussen 11y ago
  I would think call and apply would be useful for a functional style, but no?
  - tobr 11y ago
    For sure, but probably more as a way to handle arguments than to set the context. Or to work in a more FP-ish way with an OO-ish API.
  - RobertKerans 11y ago
    YMMV, but I thought I would use them more regularly the more I wrote my JS in a functional style, but the use cases started to steadily dry up; it's gets much easier to write code that simply doesn't need to hold the reference in that way. Arrow functions help a great deal (there is no concept of `this` within them). Still very useful, but in very specific cases, or abstracted off into helpers. I've found `bind()` is much more useful (and will become moreso if the bind operator is okayed and optimised).
Lazare 11y ago
If you look at this jsbin, you might get a better feel for what's being discussed: https://jsbin.com/cejuyijahu/1/edit?js,console https://jsbin.com/cejuyijahu/1/edit?js,console If you use an OOP style (with classes and inheritance), then you end up needing to use the 'this' keyword. If you use a functional style, you don't. Is the functional style better? Does it let you write more reusable code, and avoid tightly coupling it to date? Eh...maybe. If you like that style, you'll probably be more productive that way (and be intrigued by Cycle.js). If you don't like that style, you won't be. Also: > the statement above implies the existence of 'this' is a failure of JavaScript's design It's certainly been a pain point, and there's a lot of confusion and debate over classes, prototypes, constructors, the this keyword, figuring out what 'this` even refers to at any given point, the 'new' keyword, etc. I'm not sure I'd agree that the existence of the 'this' keyword is a mistake (and I doubt the people behind Cycle.js would either), but I don't think it's controversial to note that you can avoid a lot of confusion and sidestep the whole thing, if you are of a mind, by just using plain functions returning objects as needed.

noelwelsh 11y ago

Holy hyperbole, Batman! That article took a long time to get to the point, and I'm a touch hesitant to use the same breathless tone as the author. As I understand it, the model is the same as Elm. Separating specifying the computation (in this case, defining the event processing graph) from running the computation is an old trick in FP circles[1]. It's great to see JS libraries moving forward, but it would sure be an easier read if the author dropped the embellishment. [1] Blog post about this: http://underscore.io/blog/posts/2015/04/28/monadic-io-laziness-makes-you-free.html http://underscore.io/blog/posts/2015/04/28/monadic-io-lazine...