Anyway that’s enough. Cheers to mithril and it’s great devs, if you like mithril check out bss and Wright from porsager and meiosis from Foxdonut.
Every now and then I use software tools where rather than complaining about how x or y should be different, everything seems to be the best possible version of something I'd have come up with myself, and I have zero complaints. Mithril.js is one of those tools.
You're not "in a Mithril project", you're basically just using javascript but the VDOM is expertly and minimally handled by some key functions.
Participating in the project via Gitter was very welcoming as well. Long live Mithril!
Would they not want your solution to conform to existing solutions; which (regardless of being idiomatic to React) would be idiomatic to the codebase?
I have nothing but great things to say about mithril. It has a wonderful and well documented API that maintains simplicity but manages to cover the entire project (no hidden APIs or undocumented features) to the credit of the mithril community the focus in simplicity is grained into the project from the bottom up.
I have to say that it’s been nothing short of amazing and is the reason I took JavaScript much more seriously.
The community is awesome and very welcoming. The gitter chat is always active and people are happy to chat and answer questions. I credit them with being able to move quickly with mithril.
At my job my entire team uses it and everyone so far has loved it. It’s been great!
Last I checked, Mithril hyperscript couldn't handle SVG, which is a non-starter for dataviz work. Anyone know if that's still the case?
SVG works fine with Mithril now, and has for a while. Here's a quick sample: https://flems.io/#0=N4IgZglgNgpgziAXAbVAOwIYFsZJAOgAsAXLKEAG...
Or maybe I'm thinking of a different hyperscript implementation.
[0]: https://discuss.flarum.org/
[1]: https://github.com/flarum/core/blob/master/js/package.json
There's also https://flems.io a snappy web playground with an open source embeddable core[2] ( shameless self promotion :P )
[0]: https://github.com/veloce/lichobile
[1]: http://lichess.org
Good example of using a SPA to improve UX of a "document-based" app.
Another example of this sort of SPA improvement is when clicking on a list-view item brings up an overlaying modal of the item-detail page which is nicer when user is browsing rapidly.
I needed to build a fairly complex tree-table in our legacy ES5 app and I initially turned to Vue to build the first prototype. I'm a big fan of Vue, but for the first time with Vue I found myself really fighting against the framework. In particular Vue's templating system and lack of template fragments make it hard to create complex HTML table elements as they require a strict structure. Another issue is our ES5 app already has its own build system so we'd either be stuck with using Vue without Webpack (which in Vue is a really inferior experience) or attempting to use both build systems which is a bit cumbersome.
While researching Vue template fragments I discovered Mithril has had support for fragments since its inception (React recently also added support for fragments). I had always discounted Mithril. I'm not sure why. Perhaps it's the simple homepage, the seemingly brief documentation, hyperscript, or the lack of HN hype. Wow was I ever so wrong. The documentation is short because the API surface area is tiny and this is a GOOD thing. I never felt like I was writing framework code or trying to figure out the Mithril way of doing things. It pretty much gets out of your way. Hyperscript, which I thought I would hate, turned out to be one of my favorite parts of using Mithril especially when I paired it with Tailwind CSS. Since Hyperscript is pure JavaScript, doesn't require a build step, and is the standard way of writing Mithril components, integrating Mithril into our legacy JS app was absolutely dead simple.
Even with webpack or some other complex bundle, someone without any formation can really quickly set it up and get to code without worrying much about the internals of webpack etc.
<script src="https://unpkg.com/babel-standalone@6/babel.min.js"></script>
<script type="text/jsx">
/** @jsx m */
// your can use jsx here
</script>
No, they're component-oriented. View suggests you're doing MVC or similar. You don't need an M & C with React -- you will likely need to add react-router, but react + react-router (or preact + preact-router) is all the 'framework' you need for most apps.
Well, you (or the author) are comparing it to React in your title, so of course people assume that you're targeting React devs.
Now you're saying that it's something different?
If you include those in preact they may have similar size.
| Be wary of aggressive performance claims, as benchmarks used by some of these projects are known to be out-of-date and flawed (in the sense that they can be - and are - exploited)
on a page full of aggressive performance claims[0] slightly ironic
Guilty as charged. That page hasn't been updated since the v1.0 release, we've been focusing on code improvements.
V2 is around the corner (mostly bug fixes, some of which required subtle breaking changes (i.e. things that most users won't run into but it would not have been honest to make it a minor semver bump). We'll revisit the home page before the release.
And also mentioned on the same page is this :
In the spirit of demonstrating typical performance characteristics, the benchmarks presented in this comparison page are implemented in an apples-to-apples, naive, idiomatic way (i.e. the way you would normally write 99% of your code) and do not employ tricks or advanced optimizations to make one or other framework look artificially better. You are encouraged to contribute a PR if you feel any DbMonster implementation here could be written more idiomatically.
I think React will be the Java of our time. It caters to engineers who want everything to be well defined and typed. And to large corporations which don't care about heavy build processes.
Looking at what happened to Java: It's still used a lot. But not by new and exciting companies or indie developers.
I think we will see the same with React. It will stay around for decades. But the exciting new projects of the next ten, twenty years will not be written in it. They will be written by lighter tech stacks. Just like FB was initially not written in strictly typed Java but in loosely typed PHP.
The reason to use hyperapp IMO is it is far closer to the actual Elm-style FRP model, and as such includes functional state management out of the box, in a far less awkward and boilerplate heavy way than Redux provides.
Usually, what I hear from folks is that you come out of using Mithril with more transferable knowledge than something like React.
One example that comes to mind was when someone realized you could implement an incredibly simple atomic CSS composition framework by basically doing this:
/* some atomic CSS */
.primary-color-700 {color:blue;}
.pad-700 {padding:1em;}
/* a bog standard CSS selector string */
const MyWidget = '.primary-color-700.pad-700';
/* a Mithril element */
m(MyWidget) // <MyWidget /> in JSX
Now compare with what one would do with most frameworks: one would pick some CSS-in-JS library, get things done and over with, but probably learn nothing interesting in the process and have little idea of what sort of code is actually getting shipped to customers.
Advantages over React: Routing built in. Smaller/faster. You don't get numb to the word "dangerously" being used routinely for data that you trust.
Debatable: Mithril does not wrap native browser events. This is an advantage because what you learn about events applies outside the framework. It may also be a disadvantage; debatable.
Disadvantage: React is a more attractive keyword on your resume and in job listings.
EDIT: Forgot my example - https://medium.com/front-end-hacking/how-it-feels-to-learn-j...
When working with libs that use HTML templates such as Vue, it's still possible for designers to be integrated in the development process. But with HyperScript, JSX, or Mithril, anyone contributing to the codebase has to know JavaScript.
Consistency isn't exactly a high point when it comes to industry signaling vs reality.
Beyond that, out of HTML, CSS, and JavaScript, by far I find CSS the most difficult to work with and get to behave the way I want. Are there really a lot of designers who are experts at this language but don't know any JS?
I think you might be able to measure some of this. I wonder if you could look at some popular web apps that have separate HTML/CSS/JS files and look at the proportion of commits where only the UI changes, vs commits where you have to change the UI and the JS. The hypothesis being that in general you need to change your JS, and thus require a full developer anyway.
So your approach might work for simple apps, more ambitious stuff will get overly complicated.
That is imho one of the strength of mithril.js: Simple things are trivial, complicated things are pretty straight forward to solve.
Yet-another-js-framework