[lhorie]

I recall reading about this idea of "exponential creativity". I don't remember if that was the actual term used in the article, but it was basically this idea that given a problem, you can incrementally come up with better solutions (e.g. add 9's to the end of a number to make it bigger), or you can take a leap out of that box and come up with a new class of solutions that completely outdo the old way of doing things (e.g. Knuth's arrow notation, busy beaver).

One could argue that the arms race between Prototype, Dojo, YUI etc from the last decade was a race of incremental solutions and one-upmanship, and jQuery largely stood out from the crowd by having extremely well thought out developer ergonomics.

I think that the ideas behind React/Mithril/Mercury (composability, unidirectionality, etc) are, as jQuery UX was at the time, a "leap out of the box" in the frameworks' arms race, but I feel that frameworks like tuxedo are again settling into the territory of being merely stabs at incremental improvements.

The main problem I see here is that it's not particularly obvious what kind of problem this framework solves. Virtual DOM frameworks are hot because they help solve problems. In contrast, it's hard to sell features.

[mattgreenrocks]

The big problem is that OSS market rewards bloated frameworks/high commit rate/hype over careful, minimal design. Devs are unable to separate hype from technical excellence. I'm not sure many developers even skim the code of their favorite frameworks. Essentially, they're selecting OSS based on the exact same criteria used by the enterprise companies:

* "I'll go with Angular since it's supported by Google"

* "When I'm not sure which library to use, I just choose the one with the most commits"

* "I'll just choose something with the most features in case I need them"

The upshot is that incremental, monolithic solutions get selected over and over because they're easiest to digest and usually supported by a well-known entity with lots of capital (lol meritocracy).

Ultimately, OSS is a poor vehicle for R&D because the market is every bit as dysfunctional and short-term-gain-seeking as the real market. Very strange.

[sanderjd]

It's not strange, it's the natural state of a market with limited and ever-changing information. At each iteration, people ask themselves two questions: "Am I convinced this will alleviate one or more pain points I have?" and "Am I convinced this will be active, well-documented, maintained, and improved for the forseeable future?". Note the questions are "am I convinced this will" rather than "will this", because information is limited.

It is very difficult to know a priori whether something will really alleviate a pain point, or whether it just seems like it will. The ability to do that successfully most of the time is one of the great advantages of experience.

Even worse, it's basically impossible to predict the future evolution of community support for a given project, but support from a company that can pay salaries and is not itself going anywhere is one of the best positive indicators of longevity and maintenance (though it says little of quality).

[untog]

When I'm not sure which library to use, I just choose the one with the most commits

I have never seen anyone use that logic.

[vog]

Me neither. Nevertheless, the commit rate plays a role.

If the last commit is months old, you should be careful. If it is years old, you should stay away from it. (Example: The original Qmail mailserver was rock solid and djb's masterpiece of security. But you had to add custom patches for even basic features such as SMTP Auth. Why? Because at the time Qmail was written, SMTP Auth wasn't common yet.)

If the author then says that this is not due to lack of time, but because the software is "ready" / "done", this is an even worse sign. (Yes, I'm looking at you, Tilecache.)

[laichzeit0]

> Ultimately, OSS is a poor vehicle for R&D because the market is every bit as dysfunctional and short-term-gain-seeking as the real market.

My biggest problem is I don't want to invest time anymore keeping up with the latest technology fad. I still write Perl code for this very reason, I invested the time, and it's "good enough" for most problems.

The second biggest problem is the maintenance of software developed using a fad technology. As often happens when I've used something cool it ends up biting me in the ass when a year or two down the line I have to go back and make code changes and the framework/library is no longer maintained, breaks in newer browsers, etc. because people have moved on to something newer and better.

I seriously question the long-term return on investment using new web technologies these days and am very apprehensive about willy-nilly investing time learning and using them until they've gained a significant amount of traction.