Hacker News Reader

I just use Knockout.js unless there is a really compelling reason not to, I just chose one and learnt it decently well.

It supports IE (back to 6 believe it or not), is backwards compatible with itself, is relatively mature, very stable, performs fine, supports modern stuff like component orientated architectures and custom tags (if you want them), interops brilliant with lo-dash/jquery and grows with you, it's also way more of a library rather than a framework so there is very little koolaid, the devs answer on github and are active (if not a huge community).

I also rather like it's <button data-bind="click: someFunction">Do The Thing</button> binding syntax (not least because with phpstorm and pycharm you can create custom language injections on XML attributes meaning I can do jump to definition near perfectly).

Yeah, Knockout has also served us well: has been flexible as our architecture has shifted, and has progressed steadily without forcing us to pay a "framework churn" tax. It's become a mature, stable, pragmatic option, IMO.

> But my god the cognitive load involved in swimming through all of the "this library literally saves THE WORLD" marketing fluff is intense.

The problem with javascript libraries and frameworks is that, since the language itself has so many warts and quirks, it's easy to make a lot of "progress" patching over them with your unique library. So you come out on the other side, having won all these tiny victories, making things more sane, and I imagine most authors will believe their library literally "saves the day", when in reality, it just makes the language suck less.

> But my god the cognitive load involved in swimming through all of the "this library literally saves THE WORLD" marketing fluff is intense.

As far as I can tell, this isn't a JavaScript problem -- it's a general problem, and it comes from the fact that creating specific & modest solutions to day-to-day problems often seems to be a worse way to advance your career than creating a tool or library that becomes part of How We Do Things Now™.

I don't think the "javascripters" (whoever they are) are behind all the fragmentation. What we're seeing is caused by a low barrier to entry combined with a larger number of people who want to profit from a lucrative business pattern. That pattern is to create a technology that addresses a grievance (real or imagined), create a community around that technology to help promote it, then sell consulting fees once companies adopt it. This has worked brilliantly in the past (Enterprise Java in the 90s, Scrum, Ruby on Rails) and continues to make the companies behind it a lot of money in consulting fees.

I don't think this is a good enough business model to explain so many tools popping up. Firstly, it's hard and expensive to make a tool good enough to become popular. But more importantly (and increasingly), it's extremely hard and very risky to build a community to a critical mass where it can sustain itself, precisely because there are so many tools competing for attention. I think tools pop up despite this difficulty and risk, because people have real itches they're scratching.

Introspectively, despite having many frustrations with my tools, and periodically coming up with ideas for tools that seem at the time like they might improve upon things, I know that my gut sense is not, "wow, I could just code this up, get a community going, and make tons of consulting cash!", but rather, "ugh that seems super hard and likely to result in many hours of unpaid labor, I'll just work around these issues and get back to work".

I think there's a misunderstanding; I'm not saying people profit from the tools. They profit from consulting for companies who have adopted the technology, which is a very, very lucrative field. Just look at the Rails consulting shops.

edit: I just re-read my previous statement and you're absolutely correct in your analysis of what I actually said vs what I meant. I've since changed the post to read "technology" instead of "tool." What I meant to imply was that technologies like React and AngularJS were lucrative, not the supporting tools like gulp, grunt or npm.

> "ugh that seems super hard and likely to result in many hours of unpaid labor, I'll just work around these issues and get back to work".

I agree with you on that score. Unfortunately, unpaid labor on the side is an expectation of startup web development these days. Companies do not want you learning new technologies on the clock. They expect you to do that on your own. They expect you to contribute to and/or run your own open source projects. Just last week, my boss told me straight up that I was expected to make something that the company owns and profits from on my own unpaid free time to further my understanding of one of their core technologies. The "or else" was implied, of course.

> Just last week, my boss told me straight up that I was expected to make something that the company owns and profits from on my own unpaid free time to further my understanding of one of their core technologies. The "or else" was implied, of course.

Personally that would be a sign to start sending out my resume. Don't tolerate that kind of approach.

I use Javascript every day. The cognitive load you're talking about doesn't exist with me.

On the browser, all I need is a library that handles DOM manipulation easily and has good browser support. When I find one, I stick with it for a long time and only change when something really exceptional comes along. Exceptional doesn't mean "literally saves THE WORLD", it means either comes up with better ways of accomplishing what my current library does, or does the same thing but with a huge decrease in file size.

I'm not interested in the flood of people trying to become the next John Resig. I'm just interested in getting stuff done.

Exactly. You articulate my thoughts regarding JavaScript excellently

> People come into the language, and there are what seems like an infinite number of "the only right" ways to do something, all of vary degrees of complexity/usefulness, and all claiming that they are god's gift to computer science.

Maybe we need to start proselytizing and make all the incoming Javascripters repeat: "There is no god but Crockford, and JSLint is his prophet."