back button behavior is atrocious ....
But Javascript is awesome! Its the future.
Removing User Interface Complexity, or Why React is Awesome
71–80 of 228 posts
Re: Removing User Interface Complexity, or Why React is Awesome
#72This is a really thoroughly researched post and jlongster has my gratitude for writing it up. I have two concerns with this approach. Take everything I say with a grain of salt as one of the authors of Ember.js. First, as described here and as actually implemented by Om, this eliminates complexity by spamming the component with state change notifications via requestAnimationFrame (rAF). That may be a fair tradeoff in…
To clarify, Om does not "spam" state change notifications via requestAnimationFrame - all rAF calls are batched. For example if a state change occurs we schedule re-render via rAF. If another state change occurs we will not call rAF since one is already queued. In fact no state changes can queue another rAF until all changes in the current cycle have been completely flushed.
I guess this discussion hinges carefully on our relative definitions of "spam." ;) What I mean to say is that, changes or not, the browser will be invoking your diffing algorithm every 16ms.
Re: Removing User Interface Complexity, or Why React is Awesome
#73I hate OP website, why i got to click the back button 10 times to comeback here?
Re: Removing User Interface Complexity, or Why React is Awesome
#74This is a really thoroughly researched post and jlongster has my gratitude for writing it up. I have two concerns with this approach. Take everything I say with a grain of salt as one of the authors of Ember.js. First, as described here and as actually implemented by Om, this eliminates complexity by spamming the component with state change notifications via requestAnimationFrame (rAF). That may be a fair tradeoff in…
I think a lot of people see frameworks like Ember and Angular and get scared by their vastness. You don't "get" them in one evening. I have spent many hours poring over documentation, articles and videos for both Angular and Ember and I still feel that there's more to learn. But things like routing, data persistence and controllers will be a part of your app even if you use React. What I find good about Ember/Angular…
That's a very good point. I've currently settled on Backbone to give my stuff a bit more structure, but I suspect some of the complication of construction might actually disappear when using React. Not all of it, of course, but some of it.
Re: Removing User Interface Complexity, or Why React is Awesome
#75Earlier quoted context omitted.
To clarify, Om does not "spam" state change notifications via requestAnimationFrame - all rAF calls are batched. For example if a state change occurs we schedule re-render via rAF. If another state change occurs we will not call rAF since one is already queued. In fact no state changes can queue another rAF until all changes in the current cycle have been completely flushed.
I guess this discussion hinges carefully on our relative definitions of "spam." ;) What I mean to say is that, changes or not, the browser will be invoking your diffing algorithm every 16ms.
Won't that only happen if a state change has been made? That is, the diffing algorithm will only get invoked once every 16ms if the state changes faster than once every 16ms.
Re: Removing User Interface Complexity, or Why React is Awesome
#76Would you recommend using React instead of Angular for JS heavy areas of a website that is built with a server side framework (like Rails, Django etc.)? I developed a rather complex SPA with Angular recently and I cannot go back to the ghetto that is jQuery when using server side rendering.
Angular solves more than the UI problem,React on its own doesnt solve the architecturing problem , AngularJS does. The big weakness of Angular is server side rendering,which involves heavy solutions like phantomjs,while you can render react components on the server. Angular is not very good at rendering/managing svg either,that's a fact. I would argue maintaining pure html templates is not that hard. But frankly Angu…
> Angular solves more than the UI problem
Hence my question. I feel like for some apps I don't need 60% of what Angular has to offer (routing, controllers, modules etc.) I would be satisfied with just directives. Which are probably the part of Angular I like the least.
For SPAs I see no other alternative to Angular currently. In instances where I need heavy JS only on some pages, I'm not sure.
Re: Removing User Interface Complexity, or Why React is Awesome
#77Earlier quoted context omitted.
To clarify, Om does not "spam" state change notifications via requestAnimationFrame - all rAF calls are batched. For example if a state change occurs we schedule re-render via rAF. If another state change occurs we will not call rAF since one is already queued. In fact no state changes can queue another rAF until all changes in the current cycle have been completely flushed.
I guess this discussion hinges carefully on our relative definitions of "spam." ;) What I mean to say is that, changes or not, the browser will be invoking your diffing algorithm every 16ms.
It will not be invoked every 16ms, my comment above was an attempt to explain that.
Re: Removing User Interface Complexity, or Why React is Awesome
#78Would you recommend using React instead of Angular for JS heavy areas of a website that is built with a server side framework (like Rails, Django etc.)? I developed a rather complex SPA with Angular recently and I cannot go back to the ghetto that is jQuery when using server side rendering.
Based on my initial explorations using React with Rails, I'd say React might even be better when used with an existing server-side framework. With React, you can basically store all you data (state) in the root component (which could be the root of your entire page), and replace that with new state without thinking too much about the DOM updates and view changes that result from this. This is perfect for a server-sid…
I was thinking along those lines as well, thanks for the reply.
Re: Removing User Interface Complexity, or Why React is Awesome
#79Earlier quoted context omitted.
I understand that there are sometimes practical reasons for not being able to use ClojureScript, but have you given it a go? It's really very, very nice (much nicer than JS in pretty much every way). * Immutable data (you can get some of this in JS with Nolen's Mori http://swannodette.github.io/mori/ ) * Better functional programming than Underscore (map :mykey some-objects) * Great syntax: homoiconicity, thrush oper…
it's really unfortunate clojurescript is not written in javascript (or clojurescript, like coffeescript compiler is written in coffeescript ). I wanted to integrate a lisp to a toy jsbin app ( https://mparaiso.github.io/playground/ ), but no way, right now i'm using outlet. See the use case? clojurescript is never going to be big in javascript land if one cant compile it in the browser.
I agree that a self-hosting ClojureScript compiler is desperately needed and highly desirable.
Re: Removing User Interface Complexity, or Why React is Awesome
#80Earlier quoted context omitted.
I understand that there are sometimes practical reasons for not being able to use ClojureScript, but have you given it a go? It's really very, very nice (much nicer than JS in pretty much every way). * Immutable data (you can get some of this in JS with Nolen's Mori http://swannodette.github.io/mori/ ) * Better functional programming than Underscore (map :mykey some-objects) * Great syntax: homoiconicity, thrush oper…
OM and ClojureScript are great - but it is all about choice. Sometimes i prefer/need JS as a language. It would be great to get the AMAZING clojure-community ideas into the JS world.
Yep, camus2 points out environments like jsbin. Bookmarklets are another place you wouldn't use something like ClojureScript.
I'd argue once you go beyond "small" things though switching to ClojureScript is preferable to duplicating large parts of its functionality in separate JS libs.