When you begin to use most modern languages it is often very tempting to start with the "easy to use" framework. What the word framework refers too sometimes varies, but most often it is a group of libraries or modules. In other words, a set of code written to reduce as much of the repetitive coding possible which will speed up development. This is accomplished by removing the need to write things like http protocol functions, procedures, or objects. How much time you save depends on a lot of different factors. How mature is the framework? How well is it documented? How well do you understand what your end goal is?
When you are first learning a language you don't have a wide enough knowledgebase to use a framework. If it is mature with great documentation it may help you mask your limited knowledge and speed you up. However, as soon as you start encountering problems it will be hard to diagnose. Is the problem in your code? Is it in the framework code? How are you using/calling the framework? What starts out as a great productivity tool can rob you of days of work with something as simple as a missed parameter.
Before you hitch your star to a framework try writing a simple one of your own. Take something you see yourself doing a lot and put it into your language's format for external code. Source the code in from your location and call the central code in a program or two. Since you have written everything you will understand it better. While you are working through the problems of using external code, you will build up a basic knowledge of how it works. This is also a great way to start building your own portfolio of code snippets. You can then share these with others and prospective employers in the future. In general most modern languages encourage you to write your programs in this way.
Why are frameworks and modules/libraries a better way to code? It allows you to break the problem down into small parts. When you learn a better way to do something you only need to update that part. You can then test that one part and not need to test everything. So when someone finds a huge bug in OpenSSL you only need to run your tests that connect and use OpenSSL. The code that writes to the local log file isn't affected, so why test it? If it's all in the same file then you should test it because your change could, even if the chances are small, effect it. Typos happen and small files are easier to debug also.
Once you are comfortable with this then start looking to take advantage of frameworks. You will understand how they should work enough to troubleshoot them. You will also then understand enough to start reading them and learn from others. Even better you can start pushing back enhancements and bug fixes but that's a topic for another post.
So don't rush into playing with frameworks. They will likely confuse you and slow your learning process. Write a simple one of your own first. Then take your time and research the one that fits your needs best. Nothing will ever be perfect but good enough will often be enough.