From 30 years of dev experience I couldn't agree more, David.
And yes, I have to deliver quality web apps (and underlying APIs) at pace.
I baulk at the argument that frameworks speed up development. I find that writing Plain Old JavaScript gives me so much control over what to do with the results, so I can 'fiddle with the minutiae' of coding to make a great web app as I have that deep-down control in the first place.
Sure, there are repeated 'patterns' in development which I'm quite sure jQuery has reduced to a $ call, but when I want performance and have it under my control? I just write the pure JavaScript myself.
My take? It's better to remember the JavaScript patterns for a particular task, always.
Sure, if you want performance then it is good to be 'close to the metal'. High performance is a non-functional requirement that not all of us need, and it is better to focus on the domain than reinventing Knockout, Vue, react, angular, or whatever buzzword framework you want.
I find it hard to believe that writing your own frameworks for large Enterprise projects does not lead to slower development times than using a tested off the shelf solution.
What we should be teaching developers is how to understand when to use the tools available to them, not the equivalent of constructing a table saw every time they want build some furniture.
I worked most of my career as a server side guy and this hostility to frameworks is completely alien to me.
From 30 years of dev experience I couldn't agree more, David.
And yes, I have to deliver quality web apps (and underlying APIs) at pace.
I baulk at the argument that frameworks speed up development. I find that writing Plain Old JavaScript gives me so much control over what to do with the results, so I can 'fiddle with the minutiae' of coding to make a great web app as I have that deep-down control in the first place.
Sure, there are repeated 'patterns' in development which I'm quite sure jQuery has reduced to a $ call, but when I want performance and have it under my control? I just write the pure JavaScript myself.
My take? It's better to remember the JavaScript patterns for a particular task, always.
Sure, if you want performance then it is good to be 'close to the metal'. High performance is a non-functional requirement that not all of us need, and it is better to focus on the domain than reinventing Knockout, Vue, react, angular, or whatever buzzword framework you want.
I find it hard to believe that writing your own frameworks for large Enterprise projects does not lead to slower development times than using a tested off the shelf solution.
What we should be teaching developers is how to understand when to use the tools available to them, not the equivalent of constructing a table saw every time they want build some furniture.
I worked most of my career as a server side guy and this hostility to frameworks is completely alien to me.
Thank you Nick - you put it better than I could. Or in fact did.