Personal blog of a developer writing about Ruby, Ember.js, the D language, and design.
Commenters tie its Ruby posts to discussions of dependency quality and health, and the author shares his own design post. One agrees that browsers have no alternative to JavaScript.
> if you want to run your code in a browser, there's no alternative.
^^^^ YES. Although:
1. there was Java in the browser until recently when the Government said not to use it. Eh, it was dead anyway (in the browser at least- very few new projects using it).
2. there are those things called Flash/Flex/Air/etc. that Jobs killed when Apple wouldn't support them- they still live too all over the place though.
3. HTML 5- it's not just for breakfast anymore.
4. Javascript isn't just there because it is the only thing- morons at Google, etc. helped make faster JS compilers/interpreters. How is another scripting language going to erupt if they keep making the bad one faster. It's like PhP all over. Bastards.
Now back to the post to comment on just one thing:
> Just take 10 minutes and read the documentation! 10 minutes!
I was with it and then I read that and thought, "That's bullshit. Total bullshit." So #1 magic JS MVC framework? AngularJS. AngularJS documentation? Yes it has it... but even though I understand it, when something goes wrong, it is not RTFM, it's TFM: Too Fucking Magic. Batarang doesn't help when things aren't wired correctly, and when it does, it is not written for the beginner. EmberJS? EmberJS has only a community of hardcore Rails devs and Sproutcore people that didn't care it got renamed twice (sproutcore->amber.js->EmberJS) and DHH won't embrace it, so it's is F.U.C.K'd- even one of its big time proponents admitted it would be years before it is…
This article feels like a follow up on "On Ruby"[1] and related to "It’s OK for your open source library to be a bit shitty"[2]. The common theme I find in all three is the quality and health of a dependency. I agree with OP that stars and latest commit are not clear indicators of quality.
I think more useful indicators are tests, documentations and pull requests.
* Tests. These are things you can actually run to see if the library actually works. In most cases, you can read them and understand how it is supposed to be used. On some platforms even if the tests passed in the past, they may not pass now, for example using different version of the language or platform. The coverage of the tests would be nice, but it is hard to measure at first sight, therefore using the ratio of tests LOC to library LOC might be an indicator.
* Documentation. The documentation itself does not change how the library behaves but it is a clear indicator whether the author expected someone else to be able to use it or not, and shows a sort of responsibility. Most of weekend hacks would not have one.
* Pull Requests. If there are old and open pull requests, that seem useful, it is a bad sign for the maintainer of the project.
[1] http://hawkins.io/2015/03/on-ruby/
[2] http://www.drmaciver.com/2015/04/its-ok-for-your-open-source-library-to-be-a-bit-shitty/
I humbly submit my own work: http://hawkins.io/2014/01/rediscovering-the-joy-of-design/