I'm a Software Engineer for SmartProcure.
Nothing here yet.
No blogs yet.
React and GraphQL are awesome tools! But I'm not so sure about Node (and by extension, Meteor) for creating entire application backends with and expecting better-than-most performance. Node acting just as an API entrypoint makes sense and is a good choice, but the instant when you need to do concurrent operations, Node and Meteor will not scale (by design of JavaScript). I'd stick something like Elixir or Go as your business-logic application, and if you really want Node, make it your API layer (but both Elixir and Go have great API layers for them as well). Just for clarification : I'm a full-stack JavaScript developer (Node (Sails.js and MongoDB) on the backend and React on the frontend) for my day job.
I sold my first website (a static brochure site) at the age of 15. I'm 23 now and didn't graduate from college, but I write full apps (I'm front-end oriented, but I also manage all Git/CI stuff at my work) for a living. I came into the job with just a few years of intern experience. We probably have a tiny bit in common in terms of where we were when I was your age. I'm fairly naive since I'm still pretty young by industry standards, but I will suggest what I did to get where I am today: If you don't know best practices for whatever task you're trying to accomplish, just make it work Strive to learn best practices Understand the best way for you to learn and use it Want to learn every day Apply newly gained understanding of best practices into your work Go to step 1. That's the gist of it. Don't learn stacks or frameworks--Learn the primitives. I was fortunate to have my father growing up. We were extremely poor, but he was an electronics technician in the Navy, so I always had electronics/gadgets/tech when I grew up. My dad taught me HTML when I was 5 or so as he was learning it, but when he stopped caring about HTML and I had questions, he told me he didn't know and I had to find the answers on my own. The family computer was a custom-built linux box (Knoppix), so I had an understand of it pretty well at a young age. The point is, I had the great fortune of understanding installing operating systems (Even linux :p), understand computer components (RAM, CPU, etc) and what they mean for programming. I recommend understanding these things because one day you'll be on a team with a devops person who's going to complain about your high RAM-consuming apps and you have to understand the implications of perf and how to learn to fix them. I also urge you to learn how to learn the best way you can. Unfortunately, this is extremely subjective and unique--only you learn the way you do. The only advice I can give on this is study your own behavior when you get stuck on problems and examine your initial habits to gain knowledge. For me, my dad telling he didn't have the answers I was asking for was a blessing in disguise. I learn best when I'm by myself and dissecting working things and breaking them down. I "view-sourced" every site I could to get insight on how it worked, and tweaked things locally. Also understand that programming languages are tools. JavaScript is a great tool for the front-end because... well... it's the only one. But on the backend the field is so diverse and you have to understand how to make choices on tools. Since every tool was invented to solve a problem, when considering learning a new language, try to understand what problem it solved and see if it fits with the problem you're trying to solve. Hammer and nail and all that good jazz. For example, I've been getting into Erlang/Elixir recently and I immediately tried to understand how this 30+ year old tech is relevant today. Apparently Erlang was made for telecomm systems and that in of itself had problems it needed to solve--problems that are still relevant today and can be utilized to fix them because Erlang did it way back then. Learning things like that will give you a great perception of languages--instead of viewing them as skills, you view them as tools and your skill is your ability to understand when to use them. Or you can just learn a stack every year and earn a paycheck and never go deeper than that--the choice is up to you :p
For accessibility purposes, my advice is to never overwrite native components, if possible (ie. Only extend them). They come out-of-the-box with keyboard support, screen-reader support, etc. You will have to re-implement all of that if you make a new <select /> component with <div> s or what-have-you. Tons of work for not much gain, in my opinion.