DEV Community

Vani Shivanand
Vani Shivanand

Posted on

If one knows, "how to use a framework" - it doesn't mean one knows the framework

In simple words this post is about, From the excitement of learning a syntax to diving deeper into the internals of frameworks and to make the right decision for each application.

Yes, there are jobs out there that pay if one knows how to use a framework. They are good to start with. But in parallel, if the effort is not put in learning the basics of the language, the engine that runs and the interactivity - it may get hard to build a career by switching to learn the usage of frameworks.

Let's take an instance of jquery vs core-javascript concepts. In my personal observation, jquery experts had more knowledge about jquery than a few javascript developers about javascript. And of course, javascript developers had to leave out a few job options. But in the long run, it is worth it as they get to learn any new framework with much ease and also they feel a lighter loss than a framework expert.

If we take two-way binding or virtual-dom, we should put the effort into learning why they are needed and when. If we get to read, "use redux only when needed", it's good to take the next step in knowing why is it said so.

If we don't do this, frameworks over frameworks will keep the developers rolling from one knowledge base to another.

When enough developers do this, the companies can form a team of core-language developers and not use any frameworks in a lot many scenarios. Many companies take a decision to use a framework because it gives them stability due to the availability of framework-developers.

In the long run, if we create framework developers, it would be an inefficient usage of developer base' learning-time as someone who might have put 4-5 years in a framework might see another framework gaining more attention.

This is not against any frameworks, they are needed because we lack in teams that can build the same with the base knowledge of a language alone. In the past, companies have seen instability with the same. Also, they are very much needed in a few scenarios where the requirements match the need.

It was to remind us(especially myself) to learn any core language in depth.

I am a frontend developer. This may not apply for a few backend scenarios which I might not be aware of. Thanks for reading!

Top comments (4)

Collapse
 
aleksikauppila profile image
Aleksi Kauppila

I’ve enjoyed a division from knows how to use a technology to understanding and utilizing the underlying concepts that the tech is built upon. Where the latter knows what features to avoid and what to make use of to the maximum benefit of the software.

Collapse
 
jessekphillips profile image
Jesse Phillips

I'm not sure jquery is a good example. I started with doing folding lists and fancy elements in pure Javascript, my excuse for not using jquery was to better learn the language. 10 years later and jquery phasing out, jquery would have been the correct focus.

See what I didn't realize all those years ago was all the caviots with browser support which jquery figured out. And I still don't want to know all those differences (which are disappearing with newer browsers and polyfill).

I view jquery as a library rather than a framework, so I agree with your position.

Collapse
 
sebbdk profile image
Sebastian Vargr • Edited

Totally agree.

I see way to many developers pick tools based on popularity rather than the underlaying architecture of the tool.

I’m sad to say that in 10 years I can count on one hand the amount of people I’ve talked too in person about the internals of the tools we use on a equal level of comprehension.

For the record, I did not care much either up until 5 years ago.

Maybe that picture would look different if I went to some more talks/meetups tho. :)

Collapse
 
jwp profile image
John Peters

So true, we (fellow developers who've been around a bit) believe nobody becomes a subject matter expert until 1.5 years of the daily grind. Then, one knows a thing or two.