21–30 of 64 posts
I am definitely an advocate for reactive programming, as I have used React Native to develop a cross-platform mobile application ( https://dedicate.datasilk.io ), but when it comes to web development, I am very much an advocate for using the basic tools that were given to us web developers to build web applications. These tools include mainly HTML & CSS, and when needed, "vanilla" JavaScript (and maybe even a compact…
Cycle is really cool, and I'd love to see reactive programming become more popular, but after trying it out for a project it has a few ergonomics issues that keep me from using it as my primary web framework. - Dynamic lists of components are really annoying to create. In Cycle, the happy path is calling every component function in your app at startup to set up the data flow graph, and then your reactive operators ha…
I totally agree with the two issues you listed! I think both of them are well enough addressed with Cycle State, a new state management library. It has an API makeCollection() specifically meant for dynamic lists, with good DX and great performance. Also I regret imitate(), and gladly using Cycle State I haven't found a single need anymore for imitate(). Not mentioned in the official docs (yet), but Cycle.js has nowa…
I am definitely an advocate for reactive programming, as I have used React Native to develop a cross-platform mobile application ( https://dedicate.datasilk.io ), but when it comes to web development, I am very much an advocate for using the basic tools that were given to us web developers to build web applications. These tools include mainly HTML & CSS, and when needed, "vanilla" JavaScript (and maybe even a compact…
Can anyone comment on how Cycle.js compares to other frontend FRP frameworks like ClojureScript's re-frame[1]? [1]: https://github.com/Day8/re-frame
[NOTE: I have much more experience using re-frame than Cycle.js, but have used both previously] Cycle.js and re-frame, in some ways, are on opposite sides of various spectrums. Cycle.js favors local reasoning and composability through modeling your application as a pure function that takes in streams (sources) and returns streams (sinks). All of your event handling, external data, DOM changes, etc. are explicitly tie…
Events in re-frame (and reagent and React.js in general) are "push"-based. You must be explicit in your UI tree which events we care about and when they are emitted.
I actually wrote a library a long time ago[0] to invert this in React and expose a more pull-based event API, but in practice it wasn't very ergonomic.
Can anyone comment on how Cycle.js compares to other frontend FRP frameworks like ClojureScript's re-frame[1]? [1]: https://github.com/Day8/re-frame
[NOTE: I have much more experience using re-frame than Cycle.js, but have used both previously] Cycle.js and re-frame, in some ways, are on opposite sides of various spectrums. Cycle.js favors local reasoning and composability through modeling your application as a pure function that takes in streams (sources) and returns streams (sinks). All of your event handling, external data, DOM changes, etc. are explicitly tie…
In that case which one would you prefer / why?
Cycle is really cool, and I'd love to see reactive programming become more popular, but after trying it out for a project it has a few ergonomics issues that keep me from using it as my primary web framework. - Dynamic lists of components are really annoying to create. In Cycle, the happy path is calling every component function in your app at startup to set up the data flow graph, and then your reactive operators ha…
I totally agree with the two issues you listed! I think both of them are well enough addressed with Cycle State, a new state management library. It has an API makeCollection() specifically meant for dynamic lists, with good DX and great performance. Also I regret imitate(), and gladly using Cycle State I haven't found a single need anymore for imitate(). Not mentioned in the official docs (yet), but Cycle.js has nowa…
As an aside, thank you for all your work on Cycle! The project I was working on was a visual reactive programming and design tool, inspired by Bret Victor's on direct manipulation and abstraction and by your work on reactive programming and Cycle itself! I remember seeing something like that on the long-term Cycle roadmap as well, but I couldn't find it when writing that comment.
Earlier quoted context omitted.
I totally agree with the two issues you listed! I think both of them are well enough addressed with Cycle State, a new state management library. It has an API makeCollection() specifically meant for dynamic lists, with good DX and great performance. Also I regret imitate(), and gladly using Cycle State I haven't found a single need anymore for imitate(). Not mentioned in the official docs (yet), but Cycle.js has nowa…
Is there JSX support?
If you're just starting out though (or even if you're not) I'd recommend checking out create-cycle-app, the Cycle analogue to create-cycle-app that will set up things like that for you: https://github.com/cyclejs-community/create-cycle-app
To be specific, this reference criticises setState because it does a bunch of implicit updates to subcomponents. I've seen how in practice this does make things hard, but I've also seen the power of it when it works well. Cycle.js looks like it requires me to do a lot more to manage that re-rendering with the benefit of knowing exactly how it is happening.
It is a myth that what I've described above actually saves time and reduces bugs?
I've loved reading Andre Staltz's posts on reactive programming, they are so good. This is an amazing project.
Edit: clarified my comment to add example.
This looks not much different than the usual way of doing event binding and rendering in the event callback.
I am definitely an advocate for reactive programming, as I have used React Native to develop a cross-platform mobile application ( https://dedicate.datasilk.io ), but when it comes to web development, I am very much an advocate for using the basic tools that were given to us web developers to build web applications. These tools include mainly HTML & CSS, and when needed, "vanilla" JavaScript (and maybe even a compact…
Because they're useful! Frontend developers aren't just cargo culting their architecture decisions; they're trying to finding that the benefits outweigh the downsides, particularly with complex apps and large teams.
This article [1] by Tom Dale (one of the authors of Ember) puts it well:
> I have heard from many developers who have told me that they accepted the argument that vanilla JavaScript or microlibraries would let them write leaner, meaner, faster apps. After a year or two, however, what they found themselves with was a slower, bigger, less documented and unmaintained in-house framework with no community. As apps grow, you tend to need the abstractions that a framework offers. Either you or the community write the code.
Do all web apps need JavaScript frameworks? Of course not! But let's not pretend that apps like Trello don't benefit from them.
[1] https://tomdale.net/2015/11/javascript-frameworks-and-mobile...