91–100 of 228 posts
I really like the core concepts of React, especially the way it is designed to help you organize your code into reusable components. I think the key to making React take off is building a centralized repository for components that are open source. Then building your webapp would be as easy as importing the components you need: bower install react-navbar bower install react-signup-form bower install react-sso-signin-f…
So I have a word of caution. As someone else in the thread mentioned, React is very intuitive for beginners. There's another framework I've used that was also intuitive for beginners: Backbone. The reason why Backbone is inferior to Angular and Ember is because it optimized for the beginner. Angular and Ember are optimized for the experienced developer on a large code base. Specific to your suggestion, which I think…
Earlier quoted context omitted.
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.
Tester: The UI is wrong right here... Developer: Hmm...I wonder how long it's going to take me to figure out where that HTML was generated in my javascript.
Earlier quoted context omitted.
I just tried it on Firefox 26 on OSX and could not replicate. It has worked for everyone I've had test the page. The only thing that happens when you press back is the animation to load the right demo. There might be something buggy with how the CSS animation is using your graphics driver?
Back button breaking on latest version of Chrome/Win7 here. Scrolling up and down adds history.
This 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…
Thanks for the rational response, Tom. I hope this doesn't get buried (someone is going through and downvoting at least all of my comment to 0). Blog posts are best when they are sensational, and I try not to overdue it. I think React has a lot of good ideas, but "revolutionary" is a strong word. I think "refreshing" is a better word. Regardless, I think both React and Ember are the best 2 solutions out there right n…
That's got a couple of issues.
1. It eats my battery
2. It DoSes my machine (10-20% not available for other things)
So, please don't do that. Set a `dirty` flag, call a `setState` or something that requests just 1 rAF or queues a task to re-render or something and then go back to sleep.
Earlier quoted context omitted.
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.
To quote TFA:
> A set method to change state could trigger a rerender (React has setState), but there's an even easier way to react to changes: continuously call renderComponent with requestAnimationFrame to repaint the UI, and only change the DOM when the component returns different content.
Edit:
I was mistaken about how Om works. I was under the impression that Om scheduled a rAF every 16ms to check for state change. In fact, it only schedules a rAF once the state changes.
However, this relies on being able to listen for state change from the underlying model data. I was under the impression that one of the benefits of Om/React was that you could use its data bindings with any JavaScript library, even if it hadn't been instrumented for property observation. Instead, it seems that with Om, you are limited to consuming data structures that implement its state change notification interface.
Earlier quoted context omitted.
Of course it really is frameworks all the way down. Unless maybe you're building systems by laying out your own transitors. The trick is to understand the strengths and weaknesses of any given framework and match those with the constraints of your project.
I disagree that its frameworks all the way down. There is a distinction between frameworks and libraries. React, Angular, et al are frameworks in the truest sense of the word. Things like jQuery and Underscore on down to stdio.h are libraries. You can pick and choose from what they contain but they're not so tightly coupled that they get in your way. They're a tool belt with tools that do one thing and do it really w…
Earlier quoted context omitted.
Of course it really is frameworks all the way down. Unless maybe you're building systems by laying out your own transitors. The trick is to understand the strengths and weaknesses of any given framework and match those with the constraints of your project.
I disagree that its frameworks all the way down. There is a distinction between frameworks and libraries. React, Angular, et al are frameworks in the truest sense of the word. Things like jQuery and Underscore on down to stdio.h are libraries. You can pick and choose from what they contain but they're not so tightly coupled that they get in your way. They're a tool belt with tools that do one thing and do it really w…
For another example of a post that takes advantage of the dynamic nature of the web page, check out jlongster's sweet.js tutorial[1]. It's a tutorial on writing macros with JS that you can actually interact with (you can make modifications to the example code snippets and see your macros expand on the fly). Very cool.