An article that appeals to my personal stances about Javascript toolkits; I'm always a little hesitant to go too much into my views, because I don't want a potential future employer to think I can't be a team player in terms of adopting a toolkit they're using, or that I'm mired in a "Not Invented Here" (NIH) outlook. Also, my outlook isn't entirely well-researched at this point, I haven't used every one of the major toolkits.
Whenever you add a technology that increases the distance between what you are looking at in the debugger window and what code you wrote yourself, you might be making life more difficult even as it seems "easier" to do other tasks. It's one thing for a toolkit to offer lots of power and save you lots of coding, but if you can't model how it's doing what it's doing, you're not being a good programmer. (Down to a certain level, of course, it's not like I think in assembly language and circuit gates-- but it has to be down to a point of solidity and robustness) The nadir of this style of coding was with Microsoft in the aughts; legions of coders who were writing lots of powerful stuff but had no idea what to do when it went wrong.
For me the way to best leverage what other coders have done is to prefer "do one thing well" tools over frameworks, keeping the core code in as "pure" a language as possible, like raw JavaScript, but then farming out annoying things (like templating or animation/transitions) to a self-contained tool, like jQuery or handlebars.
No comments:
Post a Comment