There's something to be said for being in close proximity with a lot of other people working in the same profession. I came from working in tech for 8 years before moving to Silicon Valley and it's a world of difference.
In other words, Country Music will always exist outside of Nashville, but if you make Country music, Nashville is the place to be.
More on that point. The reason you cannot use if/else within JSX is because the statement needs to evaluate to an expression. If you really need to use if/else logic embedded, a ternary operator would work just fine.
I haven't had to pull in jQuery for other things with usage of react-bootstrap, as react-bootstrap handles all of the interactions that bootstrap provides. Also, if file size is getting you down, and you don't need all of react-bootstrap, you can simply require the individual components you need.
I strongly feel that React Native is going to come out right around F8, but cannot prove it other than that the React team seems to be speaking there and this comment on twitter https://twitter.com/reactjs/status/573872611853123584
I'm getting pretty excited to start working with React Native either way.
Ran both through the Timeline in Chrome. It seems like there is a lot of time spent on scripting for Ember's version. In the underscore version you're consistently hitting render, but at least it's much closer to 30fps than Ember is in this scenario.
The next sentence in your quote has some importance too, "Remember that the key only has to be unique among its siblings, not globally unique."
I agree there could be a little more clarity in that block of text, but I think the trade-offs section describes it well. Additionally, if there are any nodes in the tree that have a chance of being the same item between renders, you're going to benefit immensely from implementing a `shouldComponentUpdate` in your `SearchResultsItem.jsx` file.
React certainly doesn't win on every performance level, and if you try to compete on performance you're eventually going to lose. A careful developer could implement this list with no framework at all and have performance that beats both.
In the end, it's more about the mental model that best fits you and your team. I find the composite UI of React where I am building every component of other components in Javascript without a templating language to get in my way to be best suited to me.
If Marko works well for your team and you find it easy to get new developers on board and contributing code then that's awesome, keep up the good work.
It's as intended. If the ID in a list of 100 changes, and that ID is the key, React is going to assume the tree is different during reconciliation. If you were to use an index, like 0, on pagination the key is still 0 and as such the DOM nodes will be reused. http://facebook.github.io/react/docs/reconciliation.html See #2 in the Trade-offs section.
Not necessarily addressing the speed portion, but if you're going to give a key to a repeated item in React, it is best to use the index instead of a unique identifier(if the overall DOM structure does not change much between renders) so that React does not destroy and recreate each item on tree change.
I think the Front-End community just happens to collaborate a lot more than other communities and so the ideas get shared at a faster pace. Yes, it leads to framework churn, but it's mostly because we're learning from each other's ideas. If the other side of the coin is stagnation where people learn the dogma of a framework and not the reason behind it, I'm all for framework churn.
Find something that works for your team and stick with it. No one is making you use the latest framework or library out there.
Charleston resident here, our politics are so backwards in this regard. We're also considering making new bars close at midnight to make downtown 'more attractive to tech companies'.
At least local lawyers have stated that they're willing to take the case of any uber driver caught by this for free.
Angular Bootstrap's Typeahead directive does this job pretty well, although we've had to do some template overriding and funky directives to get the functionality we needed (e.g. switching the results to a different set by clicking an item in the dropdown). Glad to see more alternatives being made out there. Nice job!
We've got some particularly complicated html RegEx for Email parsing at our company. We manually write new ones for new email layouts as we get them. I'd be interested in any information on how you're solving the issue, as I love how you've tackled it at least on the UI end.