Especially in ruby world, it's amazing how big impact marketing has on open source projects.
It's nothing new that when you prepare a nice webpage with some pictures and logo your project is more likely to gain some traction. But mentioned element of social media and virality makes sometimes seemingly random projects to become popular.
It would seem that when releasing an open source project, your webdesign and marketing skills are way more important than your programming skills.
It gets fixed a bit later because when project becomes popular some good programmers join in and get rid of some silly bugs and so on. But the original design and assumptions stay. API often stays. And since I consider programming nowadays being a lot of like building from lego blocks, API has a huge influence on programmers productivity.
"Better presentation is more effective at attracting attention" would, I think, be the only reasonable conclusion here (and then only because it seems axiomatic).
In that context, it would be interest to talk to someone like kalzumeus about testing developer response to various methods of presentation for open source projects, not only to see what works in that regard, but to see whether contributors and adopters respond to the same sort of cues you'd expect to encourage consumer behavior.
Marketing shows that a project has some money behind it, which is a good sign it's going to be supported for a while, which allays the biggest fear most people and organizations have when selecting an open source tool: "is it abandonware?"
I guess actually evaluating the project itself is completely out of the question? Or you could, you know, adopt it and continue it?
The idea that the technical excellence of open source is secondary to it's marketing/influence is toxic at it's core, and reflects yet another way that developer culture has been infected by Business.
Developers focus more on amassing influence than raw skills. We're told to work on 'important' open source projects (remember when everyone fell over themselves to say they contributed to Rails?) and to jump on bandwagons. We're exhorted to take Github stars and activity streaks seriously (lol). And we're told that we can never do enough marketing for our open source projects, that we should buy domain names, blog about it, write more documentation, do bugfixes in a speedy fashion, speak, and maintain social media handles.
This will only get worse over time, because we're all convinced we have to amass influence. We're literally working ourselves to death for a few values stored in a database.
This is the case in every industry right now, and has been since the beginning of time. Marketing is the ability to influence people. It seems obvious to say this, but people who can influence people are usually the people with the most successful products (see: politicians, Apple, pg, etc.).
> _I was there_ ... In 2007, at the beginning of my journey
> I started this blog. I remember my first JavaScript
> tutorial which gained a lot of readers, even though I
> wasn’t the expert in the field ... So when I recommended
> jQuery, some people followed me in this opinion and tried
> it.
This post was a fun read simply because my own career path is not unlike the author's. I spent this time in comp.lang.javascript (;^)) and ##javscript, where I learned pretty quickly that I was decidedly not hot shit and that even frontend JavaScript development already had a significant history. Today I wouldn't entertain the idea that I was present at the start of some turning point, it was just the start of another career.
Being a neophyte coming from the land of HTML, CSS, and A List Apart, I took to jQuery like a fish to water, but more experienced folks correctly slapped my hand when I championed it (like David Mark, the Voldemort of c.l.j.). I wasn't quite sure why it was so reviled in these circles, but given that I had arrived at these communities to learn and not teach, I went with it and just listened (and didn't write blog posts).
Over time I saw jQuery for the abomination it is. A very usable, imprecise API that has "fluent interface" and a selector engine as its chief selling points, where a single prototype is the God object to end all God objects. Given that all of the other libraries implemented a comparable selector engine, I never felt deprived when working with Prototype, or MooTools, or Ext.js, or ultimately Google Closure. I could see that designs written with these other libraries were far more comprehensible and cohesive than what was coming out of the jQuery world, but to oppose the jQuery tidal wave was a fool's errand, so I just kept writing lots of software for my employers, and didn't write blog posts.
Maybe some day the history of how jQuery "made it" will be written. It seems like a shining example of "Worse is Better." Recommendations like the one from the author were just the blind leading the blind. Now we're stuck with it. Maybe more of us who felt this way should have written blog posts, but as the author hints, that's the paradox! You can spend so much time writing software, or spreading ideas, but seldom is there time to do both prolifically. I still don't feel qualified to write blog posts like this one...
jQuery is beautiful and meticulously engineered (and also modularized) to a level far beyond other DOM manipulation/cross-browser compatibility/animation/promise/wart abstraction/whatever else libraries. It may not be the best at everything, and it's certainly not minimalist (though its components are now designed to be independent and customizable) but it is the meeting of many good practices and informed design across its many capabilities. It's the everything-and-the-kitchen-sink philosophy (with a focus on performance).
> Given that all of the other libraries implemented a comparable selector engine
This is not true; other libraries implement their own selector engines which, while (sometimes) smaller in size, are also less feature-rich. Sizzle (jQuery's independently developed selector engine) provides many additional selectors not currently available in the browser (such as nested pseudo-selectors: `:not(:has(div:first-child))`).
If none of this appeals to you, you are welcome to use a different library. There are lots of other strong options. But just because jQuery doesn't fit your needs doesn't make it 'an abomination'
You're right that Sizzle was the class of selector engines, and if the story ended there (with jQuery as a DOM library) then jQuery wouldn't be listed on many resumes. By publishing `jQuery.prototype' to `$.fn', pushing the idea of "plugins", and by encouraging DOM operations as the main extension point in application design, jQuery made itself into something more. The brittleness of this approach is proven by how calling jQuery UI component methods requires an additional level of dispatch. This way of doing things has no legacy. It's considered an antipattern now, and a "mess of jQuery" is a known form of code debt. I don't think it's a matter of whether this style "fits your needs" anymore.
A "mess of" anything is a known form of code debt. Just because jQuery doesn't force you to use it properly doesn't make it unusable. jQuery, or parts of it, are still used by default in almost every SPA application framework, and some of the resulting applications are even well structured.
Just a very common use case for jQuery selectors is the :even and :odd extension, used to apply classes to table rows in order to alternate shading to make them easier to read.
There are many capabilities sizzle.js provides that go beyond CSS specifications (and also in some cases that are in the specification, but not yet implemented by browsers). Selectors can get pretty nasty, and having more flexibility available can help to make them more manageable. A lot of times you wouldn't want to use the more complex selectors, but it's certainly nice to have them.
You're forgetting one of the driving forces behind jQuery: browser incompatibilities. Now, with IE on board with HTML5 (whatever the hell that is) and most browsers at least trying to be standards-compliant, it's easy to forget that without a compatibility layer, building a cross-browser Javascript application was literally impossible.
Furthermore, jQuery offered a pretty nicely-engineered codebase and a very friendly and predictable API at a time when client-side JS was very unpredictable.
I don't use jQuery much anymore, since it's often just as easy to use plain JS. Plus, I'm often compiling so I can use a ES6 compiler to make it even nicer.
But I definitely leaned heavily on jQuery in the days prior to IE8-IE9 and client-side builds.
And even disregarding all my arguments above, I don't think it's fair to call such a carefully-designed and maintained project an "abomination", even if you do disagree with some of its technical decisions.
jQuery was far from the only popular cross-browser DOM library. We had a choice of jQuery, MooTools, YUI, Prototype, Dojo, Mochikit, and quite a few others, along with good presentation of standalone cross-browser techniques from sources like QuirksMode. jQuery mostly succeeded through its marketing to web designers which formed a critical mass of well-written extensions and hireable know-how, and a zeitgeist of jQuery as a baseline.
This is a slight diversion, but if you're interested in the topic of popularity-driven ethics (diction?) you may be interested in the novel by Cory Doctorow called "Down and Out in the Magic Kingdom" http://craphound.com/down/
I only read it recently, and in addition to recommending it as an enjoyable sci-fi read, one of the themes is the use of system called 'Whuffie', which is a reputation-based metric that permeates all of society, including politics and economics.
If you make living out of your OS project, popularity and huge number of users might not be necessary good thing. It all comes down to conversion rate, community maintenance cost etc...
Indeed, popularity does not directly correlate with quality (which is not to say that popular libraries and tools are never high quality.) That said, the reasons most projects fail have less to do with the imperfections of the tools used than with the approach taken to the project as a whole. And especially if you're running a business there are good reasons to choose tools that are reasonably well known and widely used, regardless of whether they're the absolute best available on the market. The biggest reason being that it's a lot easier to find developers who know or are interested in learning a popular tool than an obscure one.
I agree entirely. Long ago, I got some amazing advice, which has helped me to this day.
"When you have n choices, and you aren't positive which to choose, choose the more popular one".
I used to think this advice was about "the more popular is better". Now I don't think that's true. But the more popular is (in the case of software for example) more likely to be tested on more OSes, or have questions with good answers on stackexchange, have people you can employ to work on it, and still be functioning in 5 years time.
The same arguments apply to hardware too -- much easier to convince Android developers to fix their app if there is a bug on the Galaxy Note (for example), than some obscure handset.
be careful with it tho. it also depends on the reasons why project is popular. for example, wordpress is popular is because it is so easy to setup and bring to life for person with little to no technical knowledge. but other side of the medal is that code you see contributed by community often will be of very low quality. Same applies to javascript frameworks, and I bet, to hardware too (although I don't have example for hardware of top of my head)
Something that is sometimes seen as a "marketing" type thing is documentation. However, good documentation is a clear indicator of a better project, if only because it makes it qualitatively easier to implement. I'm going to choose the project with the clear, attractive, well written guide and api docs over the project where I have to dig through pull requests to find method names.
Worse are the projects that actually expect you to look at the tests as the only form of docs. This indicates that the author does not care about whether you have an easy time using the project, and that it was only written for their own amusement.
A well done project website shows that the author wants you to have an easy time working with the code, and is "putting out a welcome mat".
mercury is likely the "better" framework, with it's reactive approach, but in vue, there is attention to detail and documentation through and through. So vue is inevitably what I recommend to backend developers or others who just want to get something done.
I don't use Vue.js (I use React), but I agree that the project is extremely well-documented and beginner-friendly.
The project also has 3400 stars on Github, so the lead dev is gaining some significant popularity. Furthermore, a number of for-profit businesses are almost certainly using the framework in production, as a key part of their websites (Optimizely is cited on their web site as using it in production, but I'm positive there are others).
And yet, for all his efforts, the developer is given $5.00 a month on his prominently displayed Gratispay account: https://gratipay.com/yyx990803/
$5.00. A single Starbucks cappuccino. A month.
When I see things like this, it makes me despair of ever making a decent living doing open source software (I have some semi-popular projects, but nowhere near the level of Vue.js).
In the end, it also makes me wonder if open source development isn't devaluing the software profession in terms of compensation and prestige. If seems like if people don't pay for something, they just don't respect it, regardless of how useful, well-documented, and well-designed it may be.
I love open source, but every time I see a super popular project with only a few dollars of total donations, or hear the lead dev of a open source project used by massive companies around the world tell me he's barely making a living, part of me dies inside.
This isn't unique to software; the lowered barriers to creation has meant that the value of almost everything has dropped to the point of worthlessness. While you may not be able to make a living from your open source software through donations, you can certainly make a living by providing support to businesses or assisting with integrations/migrations. We are seeing a shift towards a service-oriented industry, rather than a product-oriented industry, and I expect the rate at which this transformation is taking place to drastically increase in the near future.
if you're running a business there are good reasons to choose tools that are reasonably well known and widely used, regardless of whether they're the absolute best available on the market. The biggest reason being that it's a lot easier to find developers who know or are interested in learning a popular tool than an obscure one.
Recently, I've been questioning the exact value of using popular tools because it's easier to find developers (vs other reasons). So much of what a business is building and providing is bespoke. Even if you use a popular framework that makes your job posting buzzword compliant, that can end up being a relatively small portion of the knowledge required to actually be effective writing software for your business's industry. This goes doubly for organically created internal business processes, which are, nearly by definition, bespoke and won't be found in exact form anywhere else. Now, if you've got good, strong project managers who know your business's industry (rare, IME), then maybe the primary knowledge/experience the programmers need is only on specific frameworks.
Obviously there's a lot of wiggle room here. Both early stage and established companies and code bases could make use of people who are either wide breadth or deep depth, there is no one guiding principle. Are you really going to turn down the candidate who knows 15 languages and frameworks but doesn't know the one you use? Or is this just your bias because you don't feel you'd be able to effectively interview them because you don't know as much as they do?
It's not just about screening people for already knowing the tools. It's also about finding people interested in learning or using them. For instance, I'd imagine it's really difficult to recruit developers willing to work on software built in Cold Fusion if it's not already their preferred language. The same goes for anything new and sufficiently obscure. That limits your hiring pool significantly. And for the newer ones means you're unlikely to be able to find anyone with a deep understanding of your language or framework (or DBMS)'s internals.
Popularity might not be the best indicator of quality, but it's a pretty good indicator of longevity of the project - and this is, I think, more important, in the long term at least.
All the technical superiority of an unpopular library will amount to nothing if couple of months down the road the author will not be interested in fixing some obscure, but important bug, nor there will be anyone to take on the maintenance from him/her.
Importantly, like you said, it's also the measure of some level of quality. It's incredibly, incredibly rare that a tech project becomes popular without any level of quality. A lot of people could do much worse than that combination (some quality + longevity)
Nothing exists without some (possibly very low) level of quality, but by any measure of quality other than popularity itself, popular things may fall anywhere in the quality spectrum.
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.
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.
35 comments
[ 2.4 ms ] story [ 72.5 ms ] threadIt's nothing new that when you prepare a nice webpage with some pictures and logo your project is more likely to gain some traction. But mentioned element of social media and virality makes sometimes seemingly random projects to become popular.
It would seem that when releasing an open source project, your webdesign and marketing skills are way more important than your programming skills.
It gets fixed a bit later because when project becomes popular some good programmers join in and get rid of some silly bugs and so on. But the original design and assumptions stay. API often stays. And since I consider programming nowadays being a lot of like building from lego blocks, API has a huge influence on programmers productivity.
In that context, it would be interest to talk to someone like kalzumeus about testing developer response to various methods of presentation for open source projects, not only to see what works in that regard, but to see whether contributors and adopters respond to the same sort of cues you'd expect to encourage consumer behavior.
The idea that the technical excellence of open source is secondary to it's marketing/influence is toxic at it's core, and reflects yet another way that developer culture has been infected by Business.
Developers focus more on amassing influence than raw skills. We're told to work on 'important' open source projects (remember when everyone fell over themselves to say they contributed to Rails?) and to jump on bandwagons. We're exhorted to take Github stars and activity streaks seriously (lol). And we're told that we can never do enough marketing for our open source projects, that we should buy domain names, blog about it, write more documentation, do bugfixes in a speedy fashion, speak, and maintain social media handles.
This will only get worse over time, because we're all convinced we have to amass influence. We're literally working ourselves to death for a few values stored in a database.
Being a neophyte coming from the land of HTML, CSS, and A List Apart, I took to jQuery like a fish to water, but more experienced folks correctly slapped my hand when I championed it (like David Mark, the Voldemort of c.l.j.). I wasn't quite sure why it was so reviled in these circles, but given that I had arrived at these communities to learn and not teach, I went with it and just listened (and didn't write blog posts).
Over time I saw jQuery for the abomination it is. A very usable, imprecise API that has "fluent interface" and a selector engine as its chief selling points, where a single prototype is the God object to end all God objects. Given that all of the other libraries implemented a comparable selector engine, I never felt deprived when working with Prototype, or MooTools, or Ext.js, or ultimately Google Closure. I could see that designs written with these other libraries were far more comprehensible and cohesive than what was coming out of the jQuery world, but to oppose the jQuery tidal wave was a fool's errand, so I just kept writing lots of software for my employers, and didn't write blog posts.
Maybe some day the history of how jQuery "made it" will be written. It seems like a shining example of "Worse is Better." Recommendations like the one from the author were just the blind leading the blind. Now we're stuck with it. Maybe more of us who felt this way should have written blog posts, but as the author hints, that's the paradox! You can spend so much time writing software, or spreading ideas, but seldom is there time to do both prolifically. I still don't feel qualified to write blog posts like this one...
> Given that all of the other libraries implemented a comparable selector engine
This is not true; other libraries implement their own selector engines which, while (sometimes) smaller in size, are also less feature-rich. Sizzle (jQuery's independently developed selector engine) provides many additional selectors not currently available in the browser (such as nested pseudo-selectors: `:not(:has(div:first-child))`).
If none of this appeals to you, you are welcome to use a different library. There are lots of other strong options. But just because jQuery doesn't fit your needs doesn't make it 'an abomination'
Furthermore, jQuery offered a pretty nicely-engineered codebase and a very friendly and predictable API at a time when client-side JS was very unpredictable.
I don't use jQuery much anymore, since it's often just as easy to use plain JS. Plus, I'm often compiling so I can use a ES6 compiler to make it even nicer.
But I definitely leaned heavily on jQuery in the days prior to IE8-IE9 and client-side builds.
And even disregarding all my arguments above, I don't think it's fair to call such a carefully-designed and maintained project an "abomination", even if you do disagree with some of its technical decisions.
I only read it recently, and in addition to recommending it as an enjoyable sci-fi read, one of the themes is the use of system called 'Whuffie', which is a reputation-based metric that permeates all of society, including politics and economics.
"When you have n choices, and you aren't positive which to choose, choose the more popular one".
I used to think this advice was about "the more popular is better". Now I don't think that's true. But the more popular is (in the case of software for example) more likely to be tested on more OSes, or have questions with good answers on stackexchange, have people you can employ to work on it, and still be functioning in 5 years time.
The same arguments apply to hardware too -- much easier to convince Android developers to fix their app if there is a bug on the Galaxy Note (for example), than some obscure handset.
Worse are the projects that actually expect you to look at the tests as the only form of docs. This indicates that the author does not care about whether you have an easy time using the project, and that it was only written for their own amusement.
A well done project website shows that the author wants you to have an easy time working with the code, and is "putting out a welcome mat".
Compare mercury: https://github.com/Raynos/mercury with vue: http://vuejs.org/.
mercury is likely the "better" framework, with it's reactive approach, but in vue, there is attention to detail and documentation through and through. So vue is inevitably what I recommend to backend developers or others who just want to get something done.
The project also has 3400 stars on Github, so the lead dev is gaining some significant popularity. Furthermore, a number of for-profit businesses are almost certainly using the framework in production, as a key part of their websites (Optimizely is cited on their web site as using it in production, but I'm positive there are others).
And yet, for all his efforts, the developer is given $5.00 a month on his prominently displayed Gratispay account: https://gratipay.com/yyx990803/
$5.00. A single Starbucks cappuccino. A month.
When I see things like this, it makes me despair of ever making a decent living doing open source software (I have some semi-popular projects, but nowhere near the level of Vue.js).
In the end, it also makes me wonder if open source development isn't devaluing the software profession in terms of compensation and prestige. If seems like if people don't pay for something, they just don't respect it, regardless of how useful, well-documented, and well-designed it may be.
I love open source, but every time I see a super popular project with only a few dollars of total donations, or hear the lead dev of a open source project used by massive companies around the world tell me he's barely making a living, part of me dies inside.
Recently, I've been questioning the exact value of using popular tools because it's easier to find developers (vs other reasons). So much of what a business is building and providing is bespoke. Even if you use a popular framework that makes your job posting buzzword compliant, that can end up being a relatively small portion of the knowledge required to actually be effective writing software for your business's industry. This goes doubly for organically created internal business processes, which are, nearly by definition, bespoke and won't be found in exact form anywhere else. Now, if you've got good, strong project managers who know your business's industry (rare, IME), then maybe the primary knowledge/experience the programmers need is only on specific frameworks.
Obviously there's a lot of wiggle room here. Both early stage and established companies and code bases could make use of people who are either wide breadth or deep depth, there is no one guiding principle. Are you really going to turn down the candidate who knows 15 languages and frameworks but doesn't know the one you use? Or is this just your bias because you don't feel you'd be able to effectively interview them because you don't know as much as they do?
All the technical superiority of an unpopular library will amount to nothing if couple of months down the road the author will not be interested in fixing some obscure, but important bug, nor there will be anyone to take on the maintenance from him/her.
Certain projects have either a niche audience, are less known, less easily groked by users, etc.
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.
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.
https://news.ycombinator.com/item?id=8973867