jblock

I love the fact that we’re starting to think about AI tools being kinder to our brains rather than overwhelming them

TIL that I'd been using items in this list for reference without realizing that I had been working with Josh (OP) at my day-job the whole time!

Hahaha, thank you. I was also trying to be curt and funny, but I guess the HN community takes their Ethereum seriously :D

I have no idea how Etherium or the blockchain works. I'm sure that it's all incredibly important and technically impressive, but these all sound like fake words that your parents would use to describe what happens when they try to update iTunes.

Can't you do both?

You are entitled to your opinions, but why do you see this as forced? The quotes you present show a piece of prose intended to evoke a mood and set a scene. None of it feels forced, or thick, or unnecessary.

I think it really depends on your implementation. For readability, having a `UserStore` and `MessageStore` in one place might get to be troublesome, especially when it comes to separating out business logic. But that said, things like `Om` like to push the idea of a single application state object, so I can forsee an implementation where you have multiple `Store`s that sit atop a single `ApplicationStore`, such that you deal with the keys of `users` and `messages` separately while they are attached to the same parent `ApplicationState` object (which can be immutable and persistent as well).

Absolutely. At first I was excited that there was so much activity. Simultaneously, it intimidates many engineers I talk to because of how much fragmentation there is.

Thankfully, the footprint of each framework is relatively small. I'd try to pick the one that seems to be the least encroaching (e.g. not using tons of custom components, something fairly agnostic about underlying data structure/data fetching methods). That way, if the tide suddenly changes, you're not buried up to your toes in messy, dying code.

You can also get by with React on its own! We've got a few areas in some of our Backbone apps where we've just decided to use raw XHR requests to fetch data (and nothing wrapping around the objects themselves).

So the TLDR is that I don't have a good panacea of a Flux library to recommend, but that shouldn't stop you from investigating React as a view mechanism in your applications.

I wish this was the top comment :(

While your points are reasonably valid, I think it's missing one grander conclusion: the tools are simply that, tools. Above all else, it's what you make with them that matters.

As an engineer, I might be interested in the implementation details of a particular system, but as an end user, I don't give a shit.

And with that, it's up to the engineer to determine the appropriate tool for the job, as has been the duty of engineers since man carved the first wheel.

All I want is a fast, functional Gmail.

Any shine they want to put on it is fine by me.

Watching Veep right afterwards is a nice (and just as brilliant in other ways) contrast.