It seems everyone is recommending books/courses/similar. I'll go the other way around. This is difficult for me to say, but I think I am an expert in CSS+JS. I know the inner workings and really advanced things of CSS, and while JS API is quite broader I know some in-depth JS APIs that your average developer doesn't even know exists.
I got to this point first in CSS and then with JS by making side projects and focus each one on a different advanced concept. I will also say it in 1st person as I experienced it as it might sound insulting otherwise:
- Don't get attached to my code. My code is crap. My 6+ months old code is a lot more crap. Always think ways of improving it. Sidenote: try to make it as standard of possible. Initially I did things my way until my open source started to get some traction and it was a mess.
- Once I got past the basics and mid-level, what I did to keep up learning was to try to focus each small side project around a technology I wanted to learn in-depth. Examples: Umbrella JS[1] is about a modular codebase, Superdom [2] is about Proxy, drive-db [3] is about talking with external APIs and DB design, etc.
- Push the limits on the technology on each project. Don't just do the basics and call it a day, try to find what is possible and what is not. Examples: Umbrella JS'[1] performance is similar to jQuery thanks to using the prototype properly, Superdom's [2] Proxies are recursive-ly, drive-db [3] is cached for maximum performance, etc.
- If I don't use it no one will. Publish it for feedback after it is polished from feedback from different projects. Focus on the positive comments to keep going and on the negative ones to keep improving. Because I know my code is crap, when someone says X is quite bad I agree on principle and find a way to fix it or prove to myself that it _was_ the right approach. Examples: Umbrella JS initial code wasn't good for the different ways of importing it, so I added a UMD-ish kind of thing. Superdom was really buggy so I had to write a few tests all around it. drive-db was not good for promises-based code so I converted it to ES7.
There is something I haven't made which I am trying now that it's reading and understanding large, public projects such as Ghost. I have done something similar while contracting, but those closed-source project's code is IMHO generally messier and you are normally trying to go for business requirements, not really focusing on pleasure/learning so much.
I got to this point first in CSS and then with JS by making side projects and focus each one on a different advanced concept. I will also say it in 1st person as I experienced it as it might sound insulting otherwise:
- Don't get attached to my code. My code is crap. My 6+ months old code is a lot more crap. Always think ways of improving it. Sidenote: try to make it as standard of possible. Initially I did things my way until my open source started to get some traction and it was a mess.
- Once I got past the basics and mid-level, what I did to keep up learning was to try to focus each small side project around a technology I wanted to learn in-depth. Examples: Umbrella JS[1] is about a modular codebase, Superdom [2] is about Proxy, drive-db [3] is about talking with external APIs and DB design, etc.
- Push the limits on the technology on each project. Don't just do the basics and call it a day, try to find what is possible and what is not. Examples: Umbrella JS'[1] performance is similar to jQuery thanks to using the prototype properly, Superdom's [2] Proxies are recursive-ly, drive-db [3] is cached for maximum performance, etc.
- If I don't use it no one will. Publish it for feedback after it is polished from feedback from different projects. Focus on the positive comments to keep going and on the negative ones to keep improving. Because I know my code is crap, when someone says X is quite bad I agree on principle and find a way to fix it or prove to myself that it _was_ the right approach. Examples: Umbrella JS initial code wasn't good for the different ways of importing it, so I added a UMD-ish kind of thing. Superdom was really buggy so I had to write a few tests all around it. drive-db was not good for promises-based code so I converted it to ES7.
There is something I haven't made which I am trying now that it's reading and understanding large, public projects such as Ghost. I have done something similar while contracting, but those closed-source project's code is IMHO generally messier and you are normally trying to go for business requirements, not really focusing on pleasure/learning so much.
[1] https://umbrellajs.com/
[2] https://superdom.site/
[3] https://github.com/franciscop/drive-db