Leo Horie, creator of the Mithril JavaScript framework, writes about the framework and front-end design choices.
Commenters recommend Mithril as small, fast, and close to plain JavaScript, and say the Mithril blog is worth reading even if you never use it.
There's some truth to that.
My own experience was in writing a lot of vanilla JS, being pretty happy with it, and then wanting to grow bigger I investigated some of the frameworks. At the time, Angular 1.x was considered the thing, so I implemented a project in that (multiple drag and drop lists, items from lists into other lists, and so on), and tried to follow best practices as far as I could tell. DRY, decoupling, etc. It was pretty horrendous. I ended up with so many different services, service providers, components, dependency injectors, and all kinds of (to me) really quite complex abstract boilerplate that had nothing to do with the actual business problems.
I eventually got it all working, and thought I was doing pretty good. I then took a break from that project and came back to it 2 months later, and couldn't make head nor tail of it. So many angular-specific concepts and terminologies.
I've since come across mithril.js, and found it (for me) perfect. It's designed to let you build stuff really fast, and modularise things around your business logic, rather than have the whole of you application design enforced from the framework. Leo's blog posts https://lhorie.github.io/mithril-blog/ are fantastic, and I think made me understand a lot more of javascript itself, and how to design applications in much more 'well designed, but not framework specific' ways.
I "failed" a job interview recently to the reason that they didn't have faith in my jQuery (any by extension Javascript) skills.
I managed to write a multi-page response explaining how the modern frameworks were moving away from jquery in favour of data bindings, virtual dom, etc... while I acknowledge that there is still a place for jQuery, it has a very much diminished role in modern web development.
In the end, I never sent the email in response. While it was cathartic to write, I really didn't want to come across as "sour grapes". (and truth be told, I respected their decision... I'd feel a better fit in a more technology forward environment, their reliance on "old faithful" technologies can still make money)
I feel like even angular has come-and-gone as a framework the 1.x just isn't performant on busy pages. Anything with a log of ng-repeats gets out of hand. Though I suppose that could also mean that I'm writing bad pages too.
My most recent favorite is Leo Horie's https://lhorie.github.io/mithril/ We've got some of that running in production and it really is beautiful to work with.
I'd like to try REACT, but haven't found the right project for it yet.
I've sortof started rambling here... my point was I share your experience with employers looking for "old" tech.
This looks really fun way to develop React apps.
I just developed a React app, and managed to trip over state related problems at every stage. First with full state outside components, then within a top component, then I tried with a simple store type concept. Whenever I had to deal with async issues, I made a mistake with communicating ongoing state or getting React to notice changed state. I was waiting for Redux to go 1.0 (which it apparently did yesterday!).
I wonder how async updates, like network requests, to the model should work? Perhaps two channels, one for events from the components to what ever is handling requests for you (I just used D3, since I have some other uses for it), and then it can message the results via channel to what actually updates the model.
OP's example reminded me strongly of Mithril [1]. Though with addition of CSP channels to communicate changes, and explicit external render call, which Mithril allows also, but I don't remember having to use. It's clean and simple looking, and I like it. Now I got one more way to mess with my app state. And should I decide to use Mithril again on other projects, CSP seems like a worthy addition if it can be applied this easy.
[1] https://lhorie.github.io/mithril/
I experimented with React a bit but I was a bit bugged by how large it was. The basic idea of rendering to a virtual DOM and having unidirectional data flow is really simple but I had trouble actually diving in to React's source code and seeing things under the hood (for example, I had to find a blog to see how the diffing algorithm worked).
What are the other libraries out there that we can use for this virtual DOM pattern right now? I only found mithril[1] that similarly does the template rendering with Javascript but I still don't know how different to React it is in the end? Is the diffing algorithm similar? Do they handle corner cases the same (many attributes need to be treated specially when writing them to DOM)?
Simplifying it a bit: other than the virtual DOM, is the rest of React also the best way to structure apps? What would the ideal "barebones" virtual DOM library look like?
[1] http://lhorie.github.io/mithril/
I like Mithril which is similar to React/Ractive.
https://lhorie.github.io/mithril/
It doesn't abstract away too much from JavaScript and provides good methodologies as outlined in the Learn/Guide section of the site.
As per your points:
1. A good couple of hours to about 6 depending on expertise just to test the workflow, get comfortable with MSX and to read the docs.
2. I've not used it in production as for current as I am still in an experimentation speed, but the whole premise is that it acts as a UI layer amongst the business logic that you may already have. It is fairly transportable.
3. This would be on a medium scale level depending how you couple your code and how modular you keep it.
4. Because it is fairly straight forward to get up and running. The blog posts alone provide great insight into application structure. Also the benchmark claims are quite appealing.
A couple of other things I do w/ Mithril.js ( http://lhorie.github.io/mithril/ )
- write documentation for the API methods (and arguments, return values, and arguments to callbacks and their return values, if applicable) and show examples of usage
- follow semantic versioning (x.x.X for bug fixes, x.X.x for backwards-compatible changes, X.x.x for breaking changes)
- consider versioning documentation in addition to releases if your project can be used as mission critical software (e.g. if it's a framework). This can be as simple as creating a task that copies a snapshot of the docs to an archive
- maintain a change log
- make sure your release is on the master branch (not gh-pages) if you're publishing to component.github.io
- setup channels of communication for discussion and support (gitter.im, IRC, mailing list, etc)
- create a tag in StackOverflow.com