Increasingly, I see posts on twitter mentioning one way or another — “What framework should I learn?” and complaints about there being too many frameworks or libraries to every possibly keep up with. Tired of keeping up with the frameworks? Learn JavaScript.

JavaScript has always been a very interesting language to me. I think it stems from my experience in an agency where I didn’t have a lot of control over what was coming back from the server that I’d almost have to re-construct a whole page’s worth of elements and data in order to complete the design. This was both an awful and awesome experience to have, because it taught me a lot about what’s possible with JavaScript as a language. Mind you, back then it was mostly hacks upon hacks with jQuery — totally proud of it!

Today, I’m constantly pushing myself to write code that is both creative and resembles something maintainable. One of the things that helps me do that is React. The library that has certainly made the most noise in the web community over the last few years, pushed the envelope with how we structure web applications. It wasn’t what it does, but how React does things under the hood that I found most impressive. There’s a misconception that JavaScript is slow — actually, it’s really fast (see NodeJS) and it’s accessing the DOM mutating it and applying changes that’s slow. React abstracts some of these steps away (via use of a VirtualDOM) to make rendering faster.

As someone who is passionate about the language, I’m glad React takes a proactive approach to teaching developers about JavaScript, rather than hiding it being a curtain as some frameworks and libraries do. When React loses community support, I think we’ll be better off as the next tools come in and change the web. React encourages developers to write their own code, and not rely on a framework to think about and structure their own application. This is a feature I now look for in a framework, as I find you almost never want a tool that gives you the everything and kitchen sink, but rather takes you into the kitchen, hands you a spanner and tells you to get to work. Typically, when people think of JavaScript, who are not front-end developers, they will often think of jQuery. The library that did it all — entire apps built with jQuery. The greatest thing about jQuery is the abstraction it gave us to some less than perfect browser API’s and it implemented features that were not easily written in JavaScript. You can learn so much from reading the jQuery source code. Fortunately, we now have a lot of good ideas that came from jQuery that are now just part of the language and with many packages doing one thing and doing it very well, we can include separate packages or roll our own for certain things. Did you know that React now has more stars on GitHub than jQuery?

Separation of concerns is a term that’s often thrown around as a reason for choosing one architecture or framework over another. React has basically flipped this on it’s head, and while some people find it uncomfortable (JSX syntax in particular), this shift in thinking has prevented context switching when it’s unnecessary state you need to maintain in your head. The idea is that a component’s markup, styles and behaviour are all interdependent. If one is out of sync with the other, we end up with a broken UI. The way to solve this is to directly tie markup to the behaviour, and while JSX is not enforced, it’s definitely recommended and incredibly convenient. Without React or jQuery, however, there is still JavaScript. Libraries and frameworks will always aim to make things easier by abstracting away the bad parts. Thankfully, there’s a great committee pushing the language forward, learning from the community and with tools like Babel, we can use these features today.

Want to learn JavaScript? I recommend reading useful articles by Eric Elliott.