3 ms·

"According to the consensus, I should have gone with Backbone.js in 2011 (then Knockout, Ember, Meteor, Angular…)" The best investment that I ever did was real

"According to the consensus, I should have gone with Backbone.js in 2011 (then Knockout, Ember, Meteor, Angular…)" The best investment that I ever did was really learning JavaScript and all it shortcomings. The problem with a longer younger colleague's at work is that they seem to learn frameworks instead. They can make cool stuff but from the moment they are in situations where for example "this" does weird stuff, they don't know why or how. There is nothing wrong with using frameworks - I use a lot of React these days, before a lot of Backbone - but if you know enough JavaScript changing between them should not be a big deal.

greenshackle2 10y ago
That's the problem with all abstractions. The abstraction gives you hope that you won't have to worry about the low level details, it will be so easy. But almost invariably, the abstraction breaks down or acts weird, or some low level error or limitation bubbles up, or the abstraction has horrible performance for some edge cases. So now, where you had 1 problem - the low level thing - you have 2 problems - the low level thing, and the abstraction. You don't have to be a uber-expert in the low level thing but it's really helpful to be comfortable with it. I see it with ORMs - 'wow this is magic, I never have to do SQL again' - 'oh crap, a weird edge case, I have to do SQL' - 'oh crap, why is this so slow, guess I have to look at the generated SQL, and maybe hand-roll my own'. (Not saying you shouldn't use abstractions, they can save a lot of work for the central cases where they work right.)