I read my contracts. I make a risk assessment. I weigh it against likelihood.
I rarely question clients contracts unless they fuck with the payment terms, or unless they impose unreasonable work guarantees. Almost nothing else matters in a contract.
If the contract is unreasonable I don't hestitate to say "this bit isn't practical". If they don't agree to adjust to fair and reasonable terms I drop the client/contract.
I really hate working for companies who impose exploitative terms because they hold the more powerful position in the relationship. I'd rather tell em to go elsewhere.
Well, that's not really the idea behind React. You could say local storage is more a convenience than anything, React is primarily about rendering your data.
The problem is that, with Redux at least, composing data stores is a major pain. The only pattern supported out-of-the-box is horizontal slicing (have different reducer for separate pieces of data). This may work for separate pages, but it does nothing for you as soon as you need data sharing. I don't think React itself should change, but I haven't found a really satisfactory solution to the problem of sharing stored data.
I agree, and try to write all my react without it, using redux, thunks and reselect heavily.
I think it's easy to say it was a design error with hindsight. I'm happy React came along, and in the future it will either get better or we'll move on to something else, heaving learnt from it's mistakes.
My theory is that any technology that can be simpler will be replaced by one that IS simpler.
New technologies like react either need to fix their problems like lack of integrated state management or be replaced by something that does do it right.
I read your 2nd sentence as "the view library needs to become a framework".
Integrated state mgmt is out of scope for React JS per se. Some ppl feel mobx is a better approach than redux. They're free to mix n match libs to suit their prefs. The React ecosystem is a set of libraries; by definition that entails more choices, more "fatigue", more combinations of approaches, and more innovation, compared to all-inclusive frameworks like Angular. Don't get me wrong; Ng gets some things right, and there are valid reasons to deliberately limit choices and go all-in w/ a framework. But I respectfully disagree thst React "needs" to integrate state management.
That's a symptom of people not understanding the concept of complexity and falling victim to the law of leaky abstractions.
People don't work towards reducing complexity in large applications (which involves trimming dependencies, removing api surface area and minimizing interactions between different people's code, which is all hard), they work towards reducing complexity in simple toy applications (which is about cramming as many tools in until you can do exactly one specific thing in one short line and it looks nice).
That has the effect of reducing complexity at first glance, but increasing it in real world applications.
If you read the article you will see that it entirely failed to predict what just happened in Houston. The article goes on and on about Storm Surges, and building Dikes - neither of which had anything to do with what just happened.
ghshepard, true. The article focused on seawalls and surges, but still managed to get the damage correct: 600,000 residents effected, $100 Billion in damage, 145 mph winds. Regardless, knowing the effects of the storm -shown through the simulation - there could have been a plan for the ensuing catastrophe, e.g. evacuating the city, relief efforts; which seem ad hoc.
What kind of backend work? Scripts? Sure. CRUD app APIs (likely the majority of mainstream app dev out there)? JS is just as well-suited, and has the advantage of tech stack uniformity with the front end.
create-react-app (with redux) is what really made me leve up in JavaScript. It forces you to think in a modern way, about JS. And it's really Easy to get started.
I rarely question clients contracts unless they fuck with the payment terms, or unless they impose unreasonable work guarantees. Almost nothing else matters in a contract.
If the contract is unreasonable I don't hestitate to say "this bit isn't practical". If they don't agree to adjust to fair and reasonable terms I drop the client/contract.
I really hate working for companies who impose exploitative terms because they hold the more powerful position in the relationship. I'd rather tell em to go elsewhere.