You're more than welcome to use XHR however you see fit. We don't dictate that choice. For many that will mean `$.ajax` - React plays nicely with jQuery (so long as you don't modify the DOM out from under us). For others that might mean a thin library that does that the same thing.
What this actually returns is a lightweight DOM-like structure. The framework then uses that to make modifications to the real DOM. In the case of the first render that's going to mean setting innerHTML of something. After that though, if you re-render this component with a different value for props.name, React won't re-render the <div> in the DOM, but will instead just modify it's contents.
From the article:
> The data returned from render is neither a string nor a DOM node -- it's a lightweight description of what the DOM should look like.
Like @thezilch said, the syntax is JSX, which is pre-processed into runnable JS.
Thanks for taking the time to follow this conversation through :) We've spent a lot of time getting the docs to where they are today, but there's always more to do. We have more planned but think we got a pretty good point for our initial public release.
When we've showed the site internally at FB & Instagram we got a lot of the same feedback you're giving now, that we need more examples. We have some more in the repo and more we'd like to write. Coming soon!
> This breaks code editors, static analysis tools like jshint etc.
You're right. One of our goals in the coming months is to try to make some language files for editors. Vim actually does a pretty good job of this already thanks to the similarity to E4X.
JSHint is another thing we'd like to improve upon. At Facebook & Instagram, we actually lint against the transformed code. Right now the transforms don't modify line numbers so it's been easy to match up. We'd like to build some tooling around this for people who make use of React and JSX.
> I think Web Components is landing soon, and this seems like it could leverage that.
I like the way you think! We've started thinking about that already.
Any chance of having CoffeeScript integration? Instead of inlining straight XML, can we wrap it in a function call (like gettext style) so it does not break existing languages/editors?
The trick is that it's not using JS to animate (not setting position manually or even depending on requestAnimationFrame). It's using CSS transitions to let the rendering engine optimize the animation.
It's not really a matter of neglect, it's a matter of finding people who actually want to do this. OS integration is pretty difficult with Firefox's codebase, partially because it's not really a native app. Parts are real (like the titlebar) but most isn't (including scrollbars). It's hard & dirty work being done by a very small team.
(I'm a former Mozilla employee who added Lion Full Screen support and did some other OS X integration work. If you know somebody who cares about Firefox and wants to work on OS X related work let me know and I'll git in touch with the right people to make that happen.)
They don't allow that. My wife tried to add her checking account to a business-related paypal account, but it was already on her personal account so they didn't let her connect it.
I'm curious what you find "hideous". 3.6 -> 4 was a pretty big overhaul, but I think it looks pretty good. I customize a bit (small buttons, get rid of the search box & home button) and I may be baised.
I'll say that Firefox isn't perfect and there are quirks & oddities with bits of the interface. I'm sure there are bugs for most of them though.
(note: I work at Mozilla on Firefox, so while I'd normally be curious, I'm invested in fixing problems!)
