By James Hibbard

How Do You Start a New Web Design Project?

By James Hibbard

This is the editorial from my latest JavaScript newsletter, you can 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 and offers 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.

  • Ricardo Rodriguez

    I start with tested technologies because if I start with a framework that I don’t know well, as you say, it can be painful all the time, and the project will delay more time to deliver and it can turns very frustrating. If I know that I need to make a project in a special technology I can’t handle good, I prefer to research how does the framework work and take a decision if maybe I can work with it, but I prefer to work not accept something I can’t handle good. So in the minimum free time I have, I try to learn some little things to complement my skills

  • I tend to go with a cross between Tim and Chris. *If* a project needs more than just CSS and HTML, I reach for some vanilla javascript. If I can avoid using JS at all I will do – the content’s the most important part – but if there’s something like a selector that I can’t do semantically with HTML and CSS, I’ll happily learn how to do it in JS.

    I avoid using frameworks mostly because I want to learn how to do it myself. Frameworks are great for getting specific things done quickly, but I don’t like the sometimes huge overheads, nor do I like not knowing *how* it’s doing something.

    There’s also the fact that the framework is great for a problem at a particular time, but the majority of frameworks I’ve seen don’t get updated when new ways of doing things are discovered. Modularising the code myself means if I find a better way to do something, or someone shows me a better way, I can rewrite or scrap the existing function and change the JS without changing the HTML.

    That said I have been incredibly lucky that the projects I work on haven’t involved massive amounts of bespoke interactions or animations beyond what CSS does, so if I started getting involved in those kinds of projects I probably would start reaching for frameworks more often.

    • James Hibbard

      I avoid using frameworks mostly because I want to learn how to do it myself. Frameworks are great for getting specific things done quickly, but I don’t like the sometimes huge overheads, nor do I like not knowing *how* it’s doing something.

      Fair enough, and while that’s a valid point if you have a sensible build process in place, the overheads shouldn’t be that massive. Plus, don’t you find that using a framework that has a reasonable amount of documentation makes it considerably easier to revisit your old code, as opposed to trying to work out what you were thinking six months ago when you have to update something?

      • A well-documented framework can be useful, true, and if I was working on something far beyond my abilities I’d reach for them.

        However, I think it’s important to write the code yourself and document what you’ve done. It gives you the chance to think things through and plan what you need, as well as giving you a chance to learn and optimize.

        For example, I wrote a video selector a couple of years ago. About 18 months ago I swapped out the jQuery I was using for vanilla javascript (mostly because I wanted to learn some more vanilla javascript). I had to think carefully about the names for functions and variables, and I had to think very carefully about what the functionality actually has to do (detect a click, read some data- attributes, switch a src depending if it’s a youtube or vimeo link, and swap some text). It’s a small enough piece that it became self-documenting, but I also took a bit of time after proving it worked to write down the steps in a more formal document so I can jump back to it.

        I see your point about documentation, though, especially on bigger projects where timescales are underestimated (read: nearly every project, ever). It’ll be a timesaver – but I’d recommend that any developer also learns *how* to document.

        After all, these frameworks we’re using came from someone finding solutions to problems and taking time to document them; the next framework could be yours :)

  • Brandon Chrisman

    I am hesitant about inserting jQuery or any other framework into a project without good reason. To justify using a js framework I have to first be convinced I’m going to be using more than just a couple perks provided. I guess this depends upon the size of the project. Typically, I go for Vanilla JS but, I mainly work with smaller scale projects that only require me to write a handful of rather simple functions.

    • James Hibbard

      I think the important thing is to understand what the framework/library is giving you and to understand how to implement that feature in plain JS. Take $.ajax() as an example — it’s not hard to implement that in vanilla JS, but the syntax is ugly and you have browser support to consider. jQuery on the other hand offers several very convenient shorthand methods, has your back in a number of edge cases, and, if you’re concerned about page weight, allows you to include only the library’s Ajax functionality.

  • As a developer, what I do to stay updated with the many JavaScript libraries is to fish some of them out and bundle them into larger projects. For example, I don’t need a new JavaScript library just because I want to build a custom scrollpane for a cross-platform app, but if I have an already existing project that has that functionality, I just fish it out and save a lot of precious time.

    In building the projects, I separate every single library in its own file so as to get to them easily. So for the scrollpane example, assuming I have a project called “App builder” which has a library called “interface” and within which has another library called “scrollpane”, I can jump straightforward to the scrollpane library without worrying about touching other parts of my project.

Get the latest in JavaScript, once a week, for free.