The Holy Grail of Frontend Development: null
For a number of a reasons I was reorganising and reshaping some projects I did over the past four years. By the way I’m primarily a front end developer with an interest in design and back end development from the Netherlands. From the outside, my archiving methods seems well-structured, with moleskins and flashdrives neatly marked with a date. But when I opened the flashdrives I encountered an disordered mess. Now I’m that kind of person that throws his entire harddrive into one folder and names it … desktop, yes I know, I should feel bad. But that’s one of the many other lessons I’ve learned during my Stanley and Livingstone expedition trough the wilderness of files. Note to myself and the rest of the world use version control also for personal projects you won’t regret it!
After searching for hours I found the six projects I needed on two different flashdrives and without any README-files or explanations. What then remained to be done was take screenshots and write a concise appealing description per project.
The first application I opened was “Thizz” a mobile XTC-pill scanner prototype which I created about two years ago. Off course errors everywhere; xCode older version errors, API 404 errors and some more. But I got it surprisingly back on track within in no time and I was thrilled about it. Because unsuspectedly the code I wrote two years ago wasn’t that bad after all. Nowadays I develop my applications very different from the way I did back then. Looking at the techniques I used with Thizz I started questioning myself; “should I start using Angular.js again?” and “why do I even use Jade with my current projects?”. Even tough during discussions with my front end friends I always state that I firmly believe in the way I develop right now. For my colleagues front end developers I use: Backbone, Sass, Coffeescript and Jade.
Next up was the three year old Bitcoin geo visualisation I made with Three.js and Backbone.js. That was also not working as planned because the API couldn’t connect to some of the Bitcoin brokers that disappeared over time. That piece of code refuted my first questions about my workflow. I agreed with myself that Backbone was ideal for structure and you should write most of the logics yourself, sounds logical, right? But again a fast fix and it was up and running again.
I hear you think, allright good for you that you got your results, but what are you trying to say? The revelation I got was that there are many other constants in the way you work rather than workflow, frameworks and preprocessors. Off course you will become better at something in time and get to know more insights and little hacks. After my code repair journey it became clear to me that the most important constant is logic. I still understand the logic I wrote three years ago. And around me people are talking about the Holy Grail among frameworks that ends up to be yet again a falsely self-proclaimed all around framework that isn’t that flexible after all. Or LinkedIn messages with freelance jobs or acquisition that require experience with a lot of preprocessors or frameworks. In my opinion that’s a wrong focus. The main focus of a front end developer should be to make a web-based application as useable as well that the target group loves to use it over and over again. The ingredients to do that are page speed, cross browser/platform support, positioning etcetera. Way behind are the tools that the developer needs to use to accomplish that. But what about team projects? Try to make your internal workflow as flexible possible for the developers. Why should anyone reluctantly adapt techniques that they don’t want to use. In the end there is no Holy Grail (at least still not found) and multiple ways that lead to Rome.