{"rowid": 88, "title": "Think First, Code Later", "contents": "This is a story that\u2019s best told from the end, and it\u2019s probably one you\u2019re all familiar with.\n\nYou, or someone just like you, have been building a website, probably as part of a skilled and capable team. You\u2019re a front-end developer, focusing on JavaScript \u2013 it\u2019s either your sole responsibility or shared around. It\u2019s quite a big job, been going on for months, and at last it feels like you\u2019re reaching the end of it.\n\nBut, in a brief moment of downtime, you step back and take a look at the code as a whole. You notice that the folder called \u201cjQuery plugins\u201d suddenly looks rather full, and maybe there\u2019s evidence of several methods of doing the same thing; there are loads of little niggly fixes in the bug tracker; and every place you use Ajax the structure of the data is slightly different. You sigh, and your shoulders droop slightly, and you think \u201cYeah, we\u2019ll do that more cleanly next time.\u201d\n\nThe thing is, you probably already know how to rewrite the start of this story to make the ending work better. This situation is not really anyone\u2019s fault \u2013 it\u2019s just an accumulation of all the things you decided along the way, all the things you agreed you\u2019d fix later that have disappeared into the black hole of technical debt, and accomodating all the \u201ccan we just\u2026?\u201d requests from around the team and the client.\n\nSo, the solution to this is easy, right? More interminable planning meetings, more tightly controlled and documented specifications, less freedom to innovate, to try out new ideas and enjoy what you\u2019re doing.\n\nWait, that sounds even less fun than the old way.\n\nMinimum viable planning\n\nActually, planning and specifications are exactly what you need, but the way you go about them can make a real difference, both to the quality of your code, and the quality of your life as a developer. It can be as simple as being a little more thoughtful before starting on any new piece of functionality. Involve your whole team if possible, or at least those working on what you\u2019re doing. Canvass opinions and work out what the solution to the problem might look like first, rather than coding speculatively to find out.\n\nThere are easy ways you can get into this habit of putting the thought and design up front, and it doesn\u2019t have to mean spending more time on the project as a whole. It also doesn\u2019t have to result in reams of functional specifications. Instead, let the code itself form the specification.\n\nAs JavaScript applications become more complex, unit testing is becoming ever more important. So embrace it, whether you prefer QUnit, or Mocha, or any of the other JavaScript testing frameworks out there. The TDD (or test-driven development) pattern is all about writing the tests first and then writing functional code to pass those tests; or, if you prefer, code that meets the specification given by the tests.\n\nSounds like a hassle at first, but once you get into the rhythm of it you should find that the time spent writing tests up front is no greater, and often significantly less, than the time you would have spent fixing bugs afterwards.\n\nIf what you\u2019re working on requires an API between client and server (usually Ajax but this can apply to any method of sending or receiving data) then spend a bit of time with the back-end developer to design the data contracts, before either of you cut any code. Work out what the API endpoints are going to be, and what the data structure you\u2019ll get back from a certain endpoint looks like. A mock JSON object documented on a wiki is enough and it can be atomic. Don\u2019t worry about planning the entire project at once, just plan enough to get on with your current tasks.\n\nDefinition in this way doesn\u2019t have to make your API immutable \u2013 change is still fine \u2013 but if you know roughly where you\u2019re heading, then not only can your team\u2019s efforts become more parallel, but you\u2019re far more likely to have an easier time making it all work. And again, you have a specification \u2013 the shape of the data \u2013 to write your JavaScript against.\n\nPutting everything together, you end up with a logical flow of development, from the specification agreed with the client (your backlog), to the specification agreed with your team (the API contract design), to the specification agreed with your code (your unit tests). Hopefully, there will be ample clues in all of this to inform your front-end library choices, because by then you should have a better picture of what you\u2019re going to need.\n\nWhat the framework?\n\nAs a JavaScript developer predominantly, these are the choices I\u2019m particularly interested in \u2013 how and why you use JavaScript libraries and frameworks, both what you expect from them and what you actually get.\n\nIf we look back at how web development, and specifically JavaScript development has progressed \u2013 from the earliest days of using lines and lines of Dreamweaver code-barf to make an image rollover effect, to today\u2019s large frameworks that handle working with the DOM, Ajax communication and visual effects all in one hit \u2013 the purpose of it is clear: to smooth over the inconsistent bumps between browsers and give a solid, reliable, predictable base on which to put our desired functionality.\n\nUnderstanding what we expect the language as a specification to do, and matching that to what we observe browsers actually doing, and then smoothing out the differences, is a big job. Since the language and the implementations are also changing as we go along, it also feels like a never-ending job. So make full use of this valuable effort. Use jQuery or YUI or anything else you\u2019re comfortable with, but it still pays to think early on about what you need your library to do and what the best choice is to meet that need.\n\nI\u2019ve come in to projects as a fixer and found, to take a recent example, that jQuery UI was being used just to provide a date picker and a modal effect. That\u2019s a lot of code weight to provide two fairly simple pieces of functionality that could easily be covered by smaller plugins. Which isn\u2019t to say that jQuery UI itself is a bad choice, but I could see that it had been included late on just to do those things, whereas a more considered approach would have been to put the library in early and use it more universally.\n\nThere are other choices, too. If you automatically throw in jQuery (or whatever your favourite main library is) to a small site with limited functionality, you might only touch a tiny fraction of its scope. In my own development I started looking at what I actually needed from a JavaScript library. For a simple project like What the Framework?, all jQuery needed to do was listen for .ready() and then perform some light DOM selection before handing over to a client-side MVC framework. So perhaps there was another way to go about this while still avoiding the cross-browser headaches.\n\nDeleting jQuery\n\nBut the jQuery pattern is compelling and familiar. And once you\u2019re comfortable with something, it\u2019s a bit of an effort to force yourself out of that comfort zone and learn. But looking back at my whole career, I realised that I\u2019ve relearned pretty much everything I do, probably several times, since I started out. So it\u2019s worth keeping in mind that learning and trying new things is how development has advanced to where it is now, and how it will keep advancing in the future.\n\nIn the end this lead me to Ender, which is billed as an NPM-style package manager for the browser, letting you search for and manage small, loosely coupled modules and their dependencies, and compile them to one file with a common API.\n\nFor What the Framework I ended up with a set of DOM tools, Underscore and Knockout, all minified into 25kb of JavaScript. This compares really well with 32kb minified for jQuery on its own, and Ender\u2019s use of the dollar variable and the jQuery-like syntax in many modules makes switching over a low-friction experience.\n\nOn more complex projects, where you\u2019re really going to use all the features of something like jQuery, but want to minimise the loading of other dependencies when you don\u2019t need them, I\u2019ve recently started looking at Jam. This uses the RequireJS pattern to compile commonly used code into a library file and then manage dependencies and bring in others on a per-page basis depending on how you need it. Again, it all comes down to thinking about what you need and using it only when you need it. And the configurability of tools like Ender or Jam allow you to be responsive to changing requirements as your project grows.\n\nThere is no right answer\n\nThat\u2019s not to say this way of working automatically makes things easier. It doesn\u2019t. On a large, long-running project or one where future functionality is unknown, it\u2019s still hard to predict and plan for everything \u2013 at least until crystal balls as a service come about. But by including strong engineering practices in your front-end, and trying to minimise technical debt, you\u2019re at least giving yourself a decent safety net to guard against the \u201ccan we just\u2026?\u201d tendencies that are a fact of life.\n\nSo, really, this is not an advocation of using a particular technology or framework, because I can\u2019t tell you what works for you or your team. But what I can tell you is that working this way round has done wonders for my productivity and enthusiasm, both for code quality and for trying out new libraries. Give it a go, you might like it!", "year": "2012", "author": "Stephen Fulljames", "author_slug": "stephenfulljames", "published": "2012-12-07T00:00:00+00:00", "url": "https://24ways.org/2012/think-first-code-later/", "topic": "process"}