3 ms·

Here's my experience, being an author of an "underdog" js framework. My project (Mithril.js) has ~2600 stars on github, a relatively lively mailing list, and i

by lhorie 12y ago

Here's my experience, being an author of an "underdog" js framework. My project (Mithril.js) has ~2600 stars on github, a relatively lively mailing list, and it's on the front page of todomvc, so it's definitely more popular than many "competitor" projects, although not nearly as popular as Angular or Ember. My general impression of the landscape is that affiliation w/ a famous brand helps a lot in driving adoption. Being a guy in the outskirts of Toronto, working on the project on my spare time (with two small kids), it's pretty hard to compete w/ teams that get paid full time and get opportunities to talk at big conferences in San Francisco. I'm skeptical that this kind of gap can be made narrower with hard/good technical work alone. This reality weaves deep even into the design philosophy of Mithril: one reason the project is small is that I don't have the resources to tech-support a huge complex one. Lack of time is obviously not a selling point, so the design of the framework itself needs to account for it - I put a lot of thought into reducing learning curve and framework complexity because that is something that both reduces my workload as a support person, and is itself a selling point (especially considering all the recent Angular criticisms). I think the only reasons my project enjoys any popularity at all is the efforts I put into non-coding tasks: writing docs (took me like 2 months of writing docs nearly exclusively to get to what I consider a decent level of documentation, even despite having a tiny API), writing articles, talking to the community, getting on twitter, adding shameless plugs on HN :) etc. In a way, this is similar to being a startup founder: there's a lot of peripheral stuff to do. It's not uncommon to be spending more time on non-coding aspects of the project than actually coding.

thunderbong 12y ago
http://lhorie.github.io/mithril/ http://lhorie.github.io/mithril/
pelonpelon 12y ago
Why I'm coding with Mithril... I have experience creating a very complex React app to organize a conference. It included registration, authentication, personalized schedules and calendars, news articles, up-to-the-minute updates, a store, physical pass(ID) verification, and a few dashboards for use by clients of my client. Honestly, it was a lovely experience. Once in the React rhythm, the coding became an exercise in pattern application. This was before Flux came along. Presently, 58% of users of my current client's site arrive via mobile and minified React tops 145kb, which takes a lot of time to deliver and unpack. I serve 1000 new users per week who can't rely on finding React in their browser cache. This is too much overhead. I am a little obsessed with under-one-second loading and 3 second attention spans. Non-minified React is 642kb and that's too much code for me to grok if I want to understand what my application is doing. I did some work converting Bootstrap to React and ramping up took too much of my time. Then I found Mithril. It's faster than anything. It's tiny. It does only what it needs to do, no bloat. And it does most of the good stuff that React does. It's also FRP friendly, another current obsession of mine. It's in the early stages, but it is so small and focused that it can be used anywhere. TODAY. Consider it code you would have written on your own if you'd had the time (and were a VERY talented js coder). mithril.js is small enough to understand in detail. It's so well designed that even an intermediate dev like me can grasp it. Beyond the basic documentation is a blog and API docs written as precisely and as focused as the code. The API is so small you can master it in an hour or two. It's a testament to its quality that the earliest blog entries are applicable today. I recommend reading them from oldest to newest. They read more like a tutorial than a blog. Post a question to the Google Group and Leo will likely refer you back to a blog post because he's already covered your question. Another sign that Mithril is of great quality: most public discussion about Mithril revolves around the philosophy and logic of app design, not code errors. When errors are discovered, Leo patches them within hours if not minutes. Leo got so much right. Most things right. More than any other framework I know.
pelonpelon 12y ago
Oops. My comment [below] grew into a post, although shorter due to character limits. https://news.ycombinator.com/item?id=8973867 https://news.ycombinator.com/item?id=8973867

by lhorie 12y ago

thunderbong 12y ago

http://lhorie.github.io/mithril/ http://lhorie.github.io/mithril/

pelonpelon 12y ago

Why I'm coding with Mithril... I have experience creating a very complex React app to organize a conference. It included registration, authentication, personalized schedules and calendars, news articles, up-to-the-minute updates, a store, physical pass(ID) verification, and a few dashboards for use by clients of my client. Honestly, it was a lovely experience. Once in the React rhythm, the coding became an exercise in pattern application. This was before Flux came along. Presently, 58% of users of my current client's site arrive via mobile and minified React tops 145kb, which takes a lot of time to deliver and unpack. I serve 1000 new users per week who can't rely on finding React in their browser cache. This is too much overhead. I am a little obsessed with under-one-second loading and 3 second attention spans. Non-minified React is 642kb and that's too much code for me to grok if I want to understand what my application is doing. I did some work converting Bootstrap to React and ramping up took too much of my time. Then I found Mithril. It's faster than anything. It's tiny. It does only what it needs to do, no bloat. And it does most of the good stuff that React does. It's also FRP friendly, another current obsession of mine. It's in the early stages, but it is so small and focused that it can be used anywhere. TODAY. Consider it code you would have written on your own if you'd had the time (and were a VERY talented js coder). mithril.js is small enough to understand in detail. It's so well designed that even an intermediate dev like me can grasp it. Beyond the basic documentation is a blog and API docs written as precisely and as focused as the code. The API is so small you can master it in an hour or two. It's a testament to its quality that the earliest blog entries are applicable today. I recommend reading them from oldest to newest. They read more like a tutorial than a blog. Post a question to the Google Group and Leo will likely refer you back to a blog post because he's already covered your question. Another sign that Mithril is of great quality: most public discussion about Mithril revolves around the philosophy and logic of app design, not code errors. When errors are discovered, Leo patches them within hours if not minutes. Leo got so much right. Most things right. More than any other framework I know.

pelonpelon 12y ago

Oops. My comment [below] grew into a post, although shorter due to character limits. https://news.ycombinator.com/item?id=8973867 https://news.ycombinator.com/item?id=8973867