dominic_cocch

"Orca can capture about 4,000 tons of carbon per year (for scale, that’s equal to the annual emissions of 790 cars).

Now Climeworks is building another facility that makes Orca seem tiny by comparison. The company broke ground on its Mammoth plant this week. With a CO₂ capture capacity of 36,000 tons per year, Mammoth will be almost 10 times larger than Orca."

A lot of negativity in this thread, oddly. This is a 10X improvement over a previous version. Another magnitude or two and this becomes incredible for the environment. Other solutions should also happen, but a problem as big as climate change should have many parallel solutions. We don't have time to put all our eggs in one basket.

Very cool. We do something very similar on Instacart's site. Our main Redux store and header component track window size and scroll position so that all components on the site have that info and can react to if they need. Works wonderfully!

For now we use Rails on the server and a single backbone router for the the client side. This isn't how we want it stay. :)

We do have a couple side apps internally using React Router. We've liked it so far, but it's a pretty basic implementation.

That is definitely one limiting aspect for some places. We actually have a similar issue, since we're a Rails shop first and foremost. Luckily there are a few tools we can use to make it work well with Rails. Maybe a future post!

I also think jQuery and other libraries with large usage are kind of Swiss army knives, so more people have more use for them.

I do believe over time React will become as pervasive as jQuery. Or possibly even the DOM api will eventually allow a similar style of building things natively. This seems to be happening to jQuery now :)

Great point. This has to be the funniest and most confusing bug when you first encounter it!

If your list is totally static, an index will do the job. However, we usually end up appending something like an id from the db since almost nothing on Instacart is static.

We've slowly been growing our React presence on the site for almost a year now. At this point, we're fairly close to the size of the original Backbone app as far as views are concerned.

We're still somewhat tangled in with Backbone, but it's been a great success internally. Performance-wise, development speed-wise and also developer happiness-wise we haven't hit too many snags.

This should really only be an issue when the children of an element are all the same type of element and are at the same depth level. For example, this is very common for li elements in a ul element.

We try to keep the structure of the html so that wrappers generally keep different UI components separate from each other. In other cases, like in the example in the blog post, we just use the index from the .map() loop to add a key to every element we know will need one. React should also warn you when this is an issue.

The backbone model api was made with totally mutable data in mind. React, on the other hand, only works well with immutable props and some mutable state in the top levels of components. That's our first issue, for sure.

Backbone also has a dependency on jQuery, which isn't very useful in React apps since mutatuing the DOM (one of jQuery's main purposes) is a no no. So most of the Backbone library isn't very useful to us anymore. I do still really enjoy the backbone way of fetching and saving models, especially in a Rails context. But I think we can get those features in other ways.

Yes and no, really. We mostly keep our backbone models as props and keep them immutable by pure convention. You really could just call set() on one of them and cause some problems. This isn't great long term, of course. Code reviews and code style guides help here for now.

We've also at times converted backbone models to simple objects at the parent level and passed them down that way. Keeps things simpler, but we lose some of the niceties of the backbone model api. Once the models are objects, you can use componentShouldUpdate pretty defensively if you need.

We've also used throttled and debounced functions for anything which gets hit very heavily.

Yep, it was the actual Flux library. However, we're not totally settled on that choice just yet.

Definitely agree. In our real code we're much more sensitive of performance. This was just a quick way to show a simple way Backbone can be used with React.

I think it'd be interesting for us to do another post in the future about how we measure and improve performance within our React apps. There aren't a ton of articles about this with relation to Bakcbone, it seems.

Thanks for giving it a read!

Whoops! Fixed in the repo now.

I can't seem to edit the title of the HN article anymore. Must be past a certain time or something.

Calling it an MVC may be a misnomer, definitely. I know backbone often refers to itself as MV*, which is sort of funny. :)

Thanks for checking it out! I'll put some thought into the 'C' aspect of this thing.