Does Mithril implement something akin to Redux? Otherwise, I'd argue that those graphs related to size aren't quite correct.
Also, fetch isn't required for either React or Vue.js, could certainly just use the built XHR API to get down even further.
Also, fetch isn't required for either React or Vue.js, could certainly just use the built XHR API to get down even further.
Depends on what you mean by "akin". The core of Redux is just a few lines of code with a set of very opinionated conventions surrounding it, plus a bunch of utilities that people may or may not use. Angular's services serve a similar purpose to redux, but the approach is quite different. Mithril's idiomatic approach is similar to Redux in the sense that it's largely convention-based, but it doesn't actually require any specialized code. We could talk about non-idiomatic options, but from my observations, Redux is the most popular state management convention/library set for React and vuex is to Vue what Redux is to React.
In any case, were talking about a 2kb difference, so it's not like it makes that much of a difference.
Fetch is not required by any library, but a) realistically nobody uses the XHR API directly and b) projects typically do require XHR capabilities. If we're going to be removing things, note that Mithril and Angular are modular and can also be trimmed down if the comparison criteria involves removing things like XHR. Also, if "using the built-in XHR API" means re-inventing basic things like querystring parsing, then a library starts to look a lot more appealing again, and at that point, we're back to the point that Mithril's XHR utilities are smaller than most others that have comparable feature sets (e.g. Axios, superagent).
As for performance, do you have a setup that we could see that shows how those are generated? Just genuinely curious.
The performance numbers are explained in more detailed in the frameworks comparison page (they're dbmonster average render times). There are links to each implementation (they are all naive, using production-mode versions).
I think it's really tough to do comparisons well and what it really comes down to, in my opinion, is how useful the library more so than the size and performance (within reason).
Also, my mistake on missing the links to the implementations in the comparison. Perhaps there needs to be a bit more contrast between the copy and the links?
Anyways, I've used Mithril and I think it's great, just wanted to make sure that the comparisons were fair.
So, I wouldn't consider it a standard for doing performance/size comparisons.
Now, I don't know how old this pattern is, or whether it was already commonplace 15 years ago. I was introduced to these ideas first through Redux, then learned Elm, the found SAM.
SAM fixes three approximations that we have been using in Software Engineering for Decades:
- actions can manipulate application state
- assignments are equivalent to mutation
- there is no need to define precisely what is a programming step (for instance when you write a = b + c, is that a step or is it 3 steps: read b,c, compute b+c, mutate the value of a)
To a certain degree, Redux and Elm are trying to address these three approximations as well, but they do it from a FP point of view, not from a TLA+ point of view.
Their definition of action aligns with the one of event and their approach to mutation is immutability. The main difference between SAM and Redux/Elm is the way side-effects are treated. SAM embraces side-effects (in particular asynch calls) while Redux/Elm don't know how to deal with them. Redux for instance breaks its principle #1 (single state tree) by introducing Sagas.
SAM is a factoring of your code that fits in one line of code: V = State(Model.present(Action(event))).then(nextAction)
No need for a nebula of libraries or inventing a whole new language.
While true, Mithril does have an XHR interface built in, while Vue doesn't and I don't think React does, so it's a fair comparison to include those in the bundle.
https://github.com/lhorie/mithril.js/blob/next/examples/todo...