91–100 of 105 posts
Earlier quoted context omitted.
How does Om not suffer from the same problems? It's just an Clojurescript interface to React.
Om is not an interface to React but rather React is the backend to Om. I wouldn't use React out of the box, for pretty much the very same reasons outlined in the slides.
Om: A ClojureScript interface to Facebook's React.
Disclaimer: I wrote Mithril (one of the vdom frameworks mentioned in the presentation) I like the idea of reactive programming, but it tends to add a lot of indirection. This is theoretically desirable, but not necessarily pragmatic in reality. A lot of frontend code in the wild is of the throw-away-in-a-few-years nature and it's hard to get mindshare among developers if they're required to learn stuff that feels aca…
If they don't grok filter then they cannot even interact with a relational database at the simplest level (a select, where). I think there is a certain level below which you are not obliged to dumb it down further.
There are also those that understand the concept of filtering at a basic level when reading tutorials about it, but still write for/if loops when it comes to producing actual code and it doesn't occur to them that it's possible to take the anonymous function out of the filter() call and give it a name to start building up a compositional foundation in their codebases.
My point though is that the benefits of FRP are somewhat out of line with the types of problems that people face in the real world.
Disclaimer: I wrote Mithril (one of the vdom frameworks mentioned in the presentation) I like the idea of reactive programming, but it tends to add a lot of indirection. This is theoretically desirable, but not necessarily pragmatic in reality. A lot of frontend code in the wild is of the throw-away-in-a-few-years nature and it's hard to get mindshare among developers if they're required to learn stuff that feels aca…
From yesterday, it's now possible to have stateful custom elements, as if they were Web Components: https://github.com/staltz/cycle/blob/fbae9c6610043ef6e46941a... This brings Cycle a bit closer to React, in that a "component" can handle its own events. The overall approach is still different than React, because in React you are encouraged to use components for anything, while custom elements exist in Cycle only when a pure component (i.e. a function returning a virtual DOM element, in React terms, props-only component) is not enough. Hence TodoMVC could be rewritten to use custom elements.
Using DOM attributes to register IDs is just one technique. Things are evolving fast, and I haven't myself tried to publish/share Cycle just yet, because it's not ready.
PS: I have a lot of respect for Mithril. Unfortunately not reactive as I would appreciate, but Mithril is very fast and very simple to understand.
Earlier quoted context omitted.
If they don't grok filter then they cannot even interact with a relational database at the simplest level (a select, where). I think there is a certain level below which you are not obliged to dumb it down further.
Sure there are those who get by w/ Google/StackOverflow/copy+paste (and hey, everyone has to start somewhere), but also remember that not everyone is a full stack dev. Lots of people make a living programming exclusively on the frontend. There are also those that understand the concept of filtering at a basic level when reading tutorials about it, but still write for/if loops when it comes to producing actual code an…
To me, it's about separation of concerns most of the times, and about handy event operators sometimes (e.g. https://github.com/Reactive-Extensions/RxJS/blob/master/doc/...).
This blog post from the same author gives a bit more detail than the presentation slides: http://futurice.com/blog/reactive-mvc-and-the-virtual-dom
Looking forward to seeing the presentation video
Earlier quoted context omitted.
You mean jQuery I suppose?
Not even the same things. I love React, use it everyday, however from a denotional semantic standpoint it is impure. view m0 = r0 view (m1 = handler e0 m0) = r1 view (m2 = handler e1 m1) = r2 This is the essence of MVC. Mathematically pure and beautiful. React and Flux are so close to this conceptually, but fall far short of it in actuality. View is a function of state. State is an argument to view, and should not be…
He implies that Grunt is dead on the first slide. Well don't I feel stupid since I still use it. I guess it's not cool anymore? I missed the memo. Wait, maybe I'm not cool? What do the cool kids use now instead of Grunt?
He implies that Grunt is dead on the first slide. Well don't I feel stupid since I still use it. I guess it's not cool anymore? I missed the memo. Wait, maybe I'm not cool? What do the cool kids use now instead of Grunt?
Make.
He implies that Grunt is dead on the first slide. Well don't I feel stupid since I still use it. I guess it's not cool anymore? I missed the memo. Wait, maybe I'm not cool? What do the cool kids use now instead of Grunt?
Earlier quoted context omitted.
If you only care about animation, why not just use a constraint solver like a physics engine? Time step is set st run-time, constraints are quite natural (springs to pull something in). Constraint programming provides the declarative data binding feel of FRP behaviors (someone on my committee pointed that out). What you don't get with constraint systems are event streams, but that isn't so useful for UI programming a…
I think that's a really great idea, too. The worrisome bit around constraint solvers is that they're really easy to get into strange "spooky action at a distance" states of constraint interaction which are incredibly tough to escape from. Building good constraints thus feels like something of a black art.
Actually, constraints are quite explicit compared to imperative assignments.