I see no advantage over Svelte stores. Did I missed something?
Overmind.js – Frictionless State Management
11–20 of 48 posts
Re: Overmind.js – Frictionless State Management
#12Hi there and thanks for the feedback on "Why even choose this". Will update the front page!
But to answer your question.
The main reason Overmind and its predecessor Cerebral (https://cerebraljs.com/) was developed is application insight. The complexity of what we build on the web these days is way beyond the scope of what our brains are able to comprehend. What effects are triggered and what state changes are made is difficult to infer reading code and using low level debugging tools. Basically understanding what actually happens when you open the browser and interact with the application. So the main reason Overmind should catch your interest is its debugger. It is not there just to debug errors, it is there to constantly give you a mental image of the whole application at the abstraction level of the application itself.
The second reason Overmind was developed is to reduce the amount of concepts of APIs required to get going with an application. Most developers, arguably, think about code imperatively. "I have this thing I want to do, let me just do it". That is why Overmind has a base concept of an "action", where you can access any state, effects and other actions you have defined in your application... and just do it. This, arguably, lowers the threshold of understanding and scaling up your app. When you get into concepts related to time complexity Overmind provides operators. When you get into concepts related to state complexity Overmind provides statemachines and statecharts. It is important to understand that Overmind does not let you just free wield state changes. You can only run state changes in actions and unlike Mobx you can use async code as normal. The state changes are bound to the action execution itself, again creating a more straight experience with less concepts to learn.
The third reason is TypeScript. We have all felt the pain of Redux boilerplate and with TypeScript it does not become better. Overmind has the goal for you to spend as little effort as possible telling TypeScript about your application, it should just understand it. Basically help developers move to TypeScript by gaining as much benefit as possible with as little typing as possible.
Now, Overmind was not built to send a message that mobx-state-tree and redux are bad solutions. It is intended to be a healthy alternative in the ecosystem showing that controlled mutability is a valid approach and hopefully be an inspiration that we can push visual tooling way beyond what we are doing currently.
To get more details on controlled mutation VS value comparison (immutability) I wrote an article here: https://itnext.io/updating-uis-value-comparison-vs-mutation-...
Re: Overmind.js – Frictionless State Management
#13Seems like every new JS framework comes with new ways to over engineer a simple list / todo app.
Joking aside, im sure this is useful for state management, where it matters.
Re: Overmind.js – Frictionless State Management
#14Hi there and thanks for the feedback on "Why even choose this". Will update the front page! But to answer your question. The main reason Overmind and its predecessor Cerebral ( https://cerebraljs.com/ ) was developed is application insight. The complexity of what we build on the web these days is way beyond the scope of what our brains are able to comprehend. What effects are triggered and what state changes are made…
I like the look of Overmind, the website is great as are your videos. I hope it gets more traction because the values you describe are important and underappreciated.
I'm a big fan of Mobx State Tree but have begun to hit a wall.
I'm currently dealing with TypeScript compilation time issues due to the complexity of the types MobxStateTree employs and thus have to face the fact that I can't rely on it to express my application without tiptoeing over circular type performance holes.
Re: Overmind.js – Frictionless State Management
#15Read through the overview and the introduction and literally could not tell what Overmind was supposed to be helping with. Everything shown looks like just basic examples of using state normally in JavaScript. What does it actually do ?
Lib like this or Redux seems like to try to better help people who don't have CS back ground to develop. Anyone who had CS training should be able to state management in plain JS or other general purpose programming language.
The main boon of Redux et al in my experience is that they impose some rules as to where and how state changers are handled, meaning less weird inconsistencies when working in a team (especielly if the team members change over time).
Re: Overmind.js – Frictionless State Management
#16Read through the overview and the introduction and literally could not tell what Overmind was supposed to be helping with. Everything shown looks like just basic examples of using state normally in JavaScript. What does it actually do ?
Lib like this or Redux seems like to try to better help people who don't have CS back ground to develop. Anyone who had CS training should be able to state management in plain JS or other general purpose programming language.
Just because you can doesn't mean you should. A CS degree doesn't mean you won't reinvent the wheel poorly.
Re: Overmind.js – Frictionless State Management
#17Hi there and thanks for the feedback on "Why even choose this". Will update the front page! But to answer your question. The main reason Overmind and its predecessor Cerebral ( https://cerebraljs.com/ ) was developed is application insight. The complexity of what we build on the web these days is way beyond the scope of what our brains are able to comprehend. What effects are triggered and what state changes are made…
> The third reason is TypeScript. We have all felt the pain of Redux boilerplate and with TypeScript it does not become better.
Redux btw, is redundant now; and offers very little value over useContext + useState. And they work wonderfully with TypeScript.
Re: Overmind.js – Frictionless State Management
#18Seems like every new JS framework comes with new ways to over engineer a simple list / todo app. Joking aside, im sure this is useful for state management, where it matters.
Exactly! :)
It is very difficult to convey "When does this solution pay back its cost". If you can get by with only React as state management, great. There are so many factors that ties into friction. Everything from the experience of the team, preferences, size of project, how clear the domains of the project is, ability to separate and isolate, typescript or not etc.
Re: Overmind.js – Frictionless State Management
#19Read through the overview and the introduction and literally could not tell what Overmind was supposed to be helping with. Everything shown looks like just basic examples of using state normally in JavaScript. What does it actually do ?
Lib like this or Redux seems like to try to better help people who don't have CS back ground to develop. Anyone who had CS training should be able to state management in plain JS or other general purpose programming language.
I don't recall my cs program actually dealing much with state management as a standalone concept.
I feel like you could take this stance on almost any framework or library.
Re: Overmind.js – Frictionless State Management
#20Earlier quoted context omitted.
Lib like this or Redux seems like to try to better help people who don't have CS back ground to develop. Anyone who had CS training should be able to state management in plain JS or other general purpose programming language.
I don't recall my cs program actually dealing much with state management as a standalone concept. I feel like you could take this stance on almost any framework or library.
Probably because JavaScript as it is used in browsers and especially React is asynchronous and in CS you traditionally study classic programming languages which are mostly synchronous code, even if it is multi-threaded you still command where and how access to shared data happens most of the time. In JavaScript and React asynchronous aspect is mostly hidden from you hence need for things like Reudx.