51–60 of 60 posts
People who chose AngularJS are looking more and more foolish everyday.
I'm very happy I picked it for my projects and I'm also very excited about React, which I would probably choose today.
Looks like they're using it for the initial profile switcher on desktop, I wonder if it will be making it's way over to the main list soon Pic: http://i.imgur.com/cj9tD1p.png
Which is one thing I absolutely hate about Netflix nowadays! I usually "discover" movies to watch on "instant" directly on my Roku. When I want to use their website, it's because I saw a preview for a movie and want to add it to my (dvd) queue (since I already searched and they didn't have it in "instant"). So I type "netflix.com" in my browser, and wait 5-10 seconds before that screen loads and allows me to choose w…
Looks like they're using it for the initial profile switcher on desktop, I wonder if it will be making it's way over to the main list soon Pic: http://i.imgur.com/cj9tD1p.png
Which is one thing I absolutely hate about Netflix nowadays! I usually "discover" movies to watch on "instant" directly on my Roku. When I want to use their website, it's because I saw a preview for a movie and want to add it to my (dvd) queue (since I already searched and they didn't have it in "instant"). So I type "netflix.com" in my browser, and wait 5-10 seconds before that screen loads and allows me to choose w…
Earlier quoted context omitted.
Because when your code changes DOM, browser does not know whether you are going to stop at it for now, or do something else, so it has to re-render. In React you explicitly request application of virtual DOM changes to real DOM once you are done.
In theory they could add some new methods to the DOM api to allow for this, but it would be non-standard and currently none of the browsers have it. Something like this maybe? batchDomChanges(); ... dom changes here ... flushDomChanges();
My experience says Netflix is spot on! Runtime performance, modularity, headless testing have been absolutely critical as we've thought about how to make a hyper-extendable email client on Atom Shell. Having a consistent component architecture has let us enable 3rd party applications that just seamlessly integrate with the rest of the core email client. Now with React Native, we might be able to do this with mobile s…
Any links on React Native?!
My experience says Netflix is spot on! Runtime performance, modularity, headless testing have been absolutely critical as we've thought about how to make a hyper-extendable email client on Atom Shell. Having a consistent component architecture has let us enable 3rd party applications that just seamlessly integrate with the rest of the core email client. Now with React Native, we might be able to do this with mobile s…
Any links on React Native?!
My experience says Netflix is spot on! Runtime performance, modularity, headless testing have been absolutely critical as we've thought about how to make a hyper-extendable email client on Atom Shell. Having a consistent component architecture has let us enable 3rd party applications that just seamlessly integrate with the rest of the core email client. Now with React Native, we might be able to do this with mobile s…
Any links on React Native?!
Earlier quoted context omitted.
Yes but WHY don't the browser makers optimize for what seems to be this very common use case? Why does a third party library outperform them?
Because when your code changes DOM, browser does not know whether you are going to stop at it for now, or do something else, so it has to re-render. In React you explicitly request application of virtual DOM changes to real DOM once you are done.
Earlier quoted context omitted.
If you think React seems interesting but JSX is a turn-off (or in my team's case a total non-starter), you might want to check out Ractive, http://www.ractivejs.org/ . It uses some of the same ideas like a virtual DOM. Here's a writeup by Ractive's developer where he compares it to React: http://blog.ractivejs.org/posts/whats-the-difference-between...
Curious why JSX is a total non-starter? I've always been intrigued by things that completely invalidate ideas, regardless of how good those ideas appear to be. Is it just aesthetic (xml like)? Is it the precompiler? What is the harm with trying it out?
Now I have to introduce a build step when I'm developing, or do I just say compile it on the client? If I use the new nodejs tools for visual studio, how does it affect debugging? How does it affect completion and highlighting? Does it break node-inspector? Maybe my team uses a bunch of different IDEs and debugging methods, now I have to see which ones break?
For me, it's a non-starter b/c having a framework say, "oh we recommend you write in a different language" seems so completely backwards to me.
I also don't think their justification is very convincing. Basically they say, "markup and code belong together because we think they should and that's why you should use JSX." So basically, they want people to use something that's not javascript because of a design decision they like. Weird.
Earlier quoted context omitted.
Curious why JSX is a total non-starter? I've always been intrigued by things that completely invalidate ideas, regardless of how good those ideas appear to be. Is it just aesthetic (xml like)? Is it the precompiler? What is the harm with trying it out?
So, I want to use a pretty lightweight framework, but then I'm not writing javascript anymore? I have to compile it like coffeescript? But what if I'm already using coffeescript? What if I want to use typescript? Now I have to introduce a build step when I'm developing, or do I just say compile it on the client? If I use the new nodejs tools for visual studio, how does it affect debugging? How does it affect completi…