I only started to really feel I was moving to another level with React when I was given a large UI project to tackle and told we had to use React & Redux and bring as much of the code under unit tests as possible. After getting through that and producing something I could feel I truly understood, that's when I felt I could call myself a "React graduate". Based on this, my advice would be: develop an idea for a product you'd love to create, ensuring it's complex enough to keep you busy, but within a reasonable scope (i.e. doable within a month or two) perhaps your workplace can assist your learning: ask about sizeable projects coming up that you might take on with React (or consider your options if your workplace isn't willing to help you on your learning journey) keep up to date with brainy folks who write about their React findings & advice, Medium is great for this! Find a few articles about React that you like and start following those authors and their publications; you'll start getting pretty regular, relevant articles in your inbox daily after following a few of these Above all, put your learnings to work and build things, solve problems, and have fun! :)

I've seen you say similar things when any JavaScript library/framework is mentioned, Jason. Can you be a bit more specific about how using these frameworks degrades accessibility? Examples would be nice to see.

My opinion is that Hype-Driven Development, as you aptly put it, belongs in the realm of leisurely personal projects, not in serious/client/enterprise ones. My reasons are: less support when things go awry generally messier, less maintainable code (since hype usually surrounds new toys that you're not experienced with) harder to pass to another developer, unless they're skilled and adaptable to exotic codebases As well as other challenges that come with learning anything new, Hype-Driven or otherwise, like needing more time invested to adapt your thinking to the new tech. As for what its impact is, seeing how JavaScript has been ramping up hype like nobody's business in the last decade, it's meant a huge, huge influx of newly shared open source software modules. It's been great to see the interesting libraries and frameworks that have popped up and changed the way we develop for the web. And on the other hand, it's given many a sane developer an insane number of choices to make, AKA: JavaScript Fatigue. So, pros and cons.

Learning leave: that is, leave that I can take for use as time off to learn something of my choice that's related to my profession. (Separate from annual leave)

Usually I'd wake up normal time, go to work normal time, leave normal time. I then tell myself to get to bed early when I reach home. However one thing I can't be without in the morning for that workday is a nice strong brewed coffee from the local coffee shop. Without that, I'm a zombie at my keyboard...

Personally I'd stick with React and Redux for your view rendering and state management libraries. You're at a bump in the road right now regarding state management by the sounds of it, not your rendering library. If you stick at learning and applying Redux in real applications you'll learn soooo much from the experience. Granted, the same could be said of any state management library, but given that most libraries these days solving a similar problem to Redux were inspired by Redux, I'd strongly advise investing the effort and time into learning that. You'll come out on the other side with a real appreciation of how to structure your app for growth and how to manage application state that you can apply to other libraries and implementations. You'll also have first-hand knowledge of the most popular front-end state management library currently around— something very potent to include in your toolbox of knowledge! Perhaps you could share the part(s) of applying Redux that you're struggling with to help you overcome your current sticking points?

I can see where your colleague is coming from, but I think their viewpoint is on the extreme side of the scale. To me it sounds like they're thinking along the lines of: "this person wrote a comment, therefore they probably have a misunderstanding about the code that follows, so they might have written error-prone code". Equally, they might have completely understood the code and simply want to help other developers get a quick summary of what follows. It may or may not be of any actual help to themselves or others, but this is simply what some folks like to do. There's other common uses for comments too, such as for automated documention tools and to simply help break up blocks of code with clear divisions.

Reduction in size is always a welcome feature, I'm glad that they were able to shave off a fair few KBs!

Sounds like a plan, that's what my thinking would be too in your shoes. Good luck! :)

I'd choose Python out of those 2, based on what I see in industry demand nowadays. PHP I'm seeing much less demand for now than before, and Python is gaining in popularity given its usage in current trendy tech like machine learning. Though it's fair to say Laravel for PHP is a strong competitor and it would be my reason for choosing PHP if I did. I don't think Codeigniter is nearly as popular a framework. (Not to suggest popularity is everything by the way, just that it helps to guarantee that the language/framework will continue to thrive and receive updates and community support; as well as better prospects for industry jobs)