This is the editorial from my latest newsletter, subscribe here.
I come bearing good news! For those of you who didn’t hear yet (where’ve you been?) SitePoint recently launched a new podcast: The Versioning Show. It’s headed by regular SitePoint contributors M. David Green and Tim Evko, who every week sit down to discuss the industry of the web, from development to design, with some of the people making it happen today.
Personally, I’m loving the show. I was an avid listener of the previous SitePoint podcast (anyone remember that?) and I think that podcasts in general are an excellent way of keeping up with an increasingly fast-paced and ever-changing industry. Tim and David have already spoken to a number of distinguished guests, one of whom was Chris Coyier. They asked Chris (who has also written for the JavaScript channel) what types of technologies he would use if he had to build a new website tomorrow. I found his answer interesting (in so far as it gave me food for thought) and that’s what I’d like to look at today.
Chris’ position is that basically “It depends”. For a small(ish) website he’d start off simple with HTML and CSS, sprinkle on jQuery for interactivity and (if needed) use WordPress by way of a backend. For an app which required more interactivity and state, he’d probably reach for a React and Redux solution. In other words, he’d go straight for familiar tools that make him productive quickly.
Now, living in JavaScript land, where there’s a new and fancy framework coming along every few days, I’m kinda the opposite. Whenever I get a new problem to solve I immediately think “Which one of those two dozen frameworks or libraries I’ve been wanting to try out would be best suited to the job?” There’s only so much you can learn about a technology by reading about it and real world practice is invaluable when getting to grips with something new.
This approach certainly has its drawbacks. For example you need to make sure that you don’t bet the farm on a project that’ll be abandoned by the author as quickly as it appeared. And of course, project constraints (such as time, manpower and budget) need to be taken into account. How many people will be working on the project and how long you will be expected to maintain it for are also important considerations. Nonetheless, this approach works for me, not least because I gain a valuable insight into how different projects approach the same kind of problem.
Another interesting point of view to come out of the podcast discussion, was that of host Tim Evko. Tim prefers to see what he can get done with “just” vanilla JavaScript. Again, I guess it depends on what you’re trying to achieve, but I’m of the opinion that the majority of these frameworks and libraries exist to solve a particular problem, and that you need to get bitten by that problem before you can appreciate what the technology in question is doing for you. For me, writing everything in vanilla JS would be way too painful — the first thing I do when starting a new project is to include jQuery (out of general principle if nothing else).
That’s not to discount the importance of understanding vanilla JavaScript. If you use something like Angular, but have no concept of the language it is built in, you’re going to have a bad time. However, once you have a handle on vanilla JavaScript, frameworks and libraries are your friends. They’re usually battle tested and will help you before you even know you need it.
But what do you think? What do you reach for when starting a new project? Do you go with tried and tested technologies that make you productive? Do you roll your own with vanilla JavaScript? Or do you go for the latest shiny goodness?
Let me know in the comments below, and don’t forget to check out the podcast.
(in PHP land, of course - in JS, I landed on VueJS and won’t be moving soon)