111–117 of 117 posts
Earlier quoted context omitted.
Are there any helpers/libraries you use when building CRUD forms? I haven't seen one for React yet - or TBH a well functioning one in any language I use - and it's a pain point I would like to solve.
https://github.com/wingspan/wingspan-forms https://github.com/dustingetz/react-cursor http://www.dustingetz.com/2014/02/18/react-dynamic-forms.htm...
Earlier quoted context omitted.
We used Angular at Stampsy and it was a pain to learn and debug. React is awesome because it encourages very modular components, has very small API surface (you can go far with knowing 5 API methods, compare this to Angular insanity) and great out-of-the-box performance (which is possible to boost 5x if you use performance hooks like `shouldComponentUpdate`). React gets you very close to browser limits in terms of pe…
Why do you say AngularJS was hard to debug? Also any insights around modularity - AngularJS directives vs ReactJS components? I hear you about the API surface. Currentlu AngularJS has too many weird/new concepts.
1. Two-way bindings complicate things because there is no single source of truth. (See http://vimeo.com/92687646 at 30:00)
2. Template/directive separation is superficial, in fact these are single concern and should be together.
3. Separation between `props` and `state`, as well as documenting `props` via `propTypes` encourages very natural modularity.
Earlier quoted context omitted.
In all javascript apps the part that is slow is the DOM, not the javascript interface. This benchmark was taken from the webkit source code then forked into http://vuejs.org/perf/ then forked to include mercury then forked again to include elm. Neither elm nor mercury came up with this benchmark and just added themself to it. What this benchmarks shows is that async rendering is really fast. Mercury, vue & elm all us…
There is interaction occurring with the DOM in both benchmarks. The way that the Backbone TodoView is designed does not take into account the possibility of a user adding 100 items using the dom within a tight loop. Probably because such a use case is impossible outside of this type of benchmark. By doing so the Backbone implementation ends up performing a lot of unnecessary renders. Therefore as far as Backbone perf…
edit: I was running the original test instead of your fork.
Anyone know of a Haskell or proper Haskell subset that can do something similar (hopefully batteries included)?
Absolutely not "batteries included" but I've put some work into a React interface for Haste, which is a Haskell->JS compiler. https://github.com/takeoutweight/shade
Anybody have any good reviews on elm?
It is fun to play with and I managed to pick it up very quickly (after having already spent a significant amount of time learning Haskell). I am a bit concerned about the lack of typeclasses and what that could mean if I try and build something bigger using it. Maybe I could use Purescript and Elm together.
There's another advantage to virtual DOM: you can hot-swap code while developing and have React run its diff algorithm without reloading the page. If your component has no (or little) side-effects, it means you get live reload as you edit for free. This is impossible with Backbone/jQuery soup of a view. See my proof of concept video: https://vimeo.com/100010922 And actually runnable example that you can edit without…
Earlier quoted context omitted.
That's the thing I love about React though; you don't have to marshal if you embrace mori wholesale. I can render components based on these data structures and never have to "reify" them into real JS data structures. That said, I'm probably being overly optimistic and I'm just starting to research it. I don't quite like how addons.update feels like a bandaid, but maybe it is good enough. Haven't done enough research…
I've done some research too - check out this implementation of cursors, it enables drop-in O(1) shouldComponentUpdate (like Om) and is compatible with rAF batching (like Om). We explored Mori for a bit too and ended up deciding Mori wasn't worth it. (Our app was big enough that we experienced pretty brutal performance without shouldComponentUpdate. Now our bottleneck is methods like Array.prototype.map over large lis…