The first thing I learned to do with JavaScript was swapping images.
It was 1998 and that was the "state of the art" web application programming that I had any access to. It was a time before the web was filled with MM_swapImage, although I remember Dreamweaver being around. I knew HTML back then and hacking some JavaScript was my first foray into programming proper. The fact that the src of an <img> was something that I could programmatically change was a profound realisation for me at the time, although that now seems a very long time ago.
My web hacking went along with what everybody else was doing, maybe with a delay of a year or two because I had to wait for stuff to arrive in Germany (the Internet was very slow back then). Netscape and IE 4 came out and brought new ways of dynamically manipulating and animating HTML content. DHTML was born, and I tried to figure it all out until I could swap out content with layers (layers!) and divs that worked in both browsers.
It was cool to play with, but at that time building things that worked consistently was not much fun, so I turned to the dark side and got involved with backend web development. I could let others worry about all the quirky browser differences. The backend is where I found my passion for databases.
But then 2005 came around and everything changed. Google unveiled Maps and the world was a different place. I distinctly remember, to this day, dragging the map inside the browser window — and I still get goosebumps thinking about it. Google Maps was the Beatles coming to America moment for the web.
Around the same time, 37signals came along with their web based apps for freelancers and small businesses and not only showed the world what can be done on the web, they started a year long discussion between supporters of what we call native desktop apps and web apps. We now go through the same thing with native mobile apps and the web.
37signals even wrote a book about how to build a bootstrapped business around the software as a service model that sparked a whole generation of web app entrepreneurs who built great products that touched the world in their own ways.
Truly inspired, a friend from university and I set out to do our own software as a service. We spent a good amount of time on it, but ultimately, it didn’t go anywhere. There were a number of issues, but my poor understanding of frontend web technologies certainly didn’t help. We managed to build a functional prototype, but the code was a mess, bugs were impossible to fix, new features wouldn’t land, and refactoring efforts failed multiple times until we gave up. We folded and I went back to the backend and database side of things.
Fast forward to where I start Hoodie and find myself in the company of excellent frontend developers. Now, the best I can do for the project is build out all the backend so they don’t have to worry about a thing while they knock out the frontend.
However, I am still longing for a deeper understanding of the frontend world. I can dabble, but I want to be confident.
Computer science is fundamentally about building things. Unlike architecture or structural engineering, the what, how, and why of doing our work changes on a scale of years, if not weeks sometimes. Stuff we learned last year is proverbially obsolete today.
The flip side of this nature is that it is very hard to build a canon. Sure, we have algorithms and data structures as the foundations of modern teaching and yes, they are part of everyday work, but programming and building products is just so much more.
It is on us to figure how to get the missing pieces into a curriculum that informs future generations of web developers.
When Henrik told me he was working on Human JavaScript I begged to be added to the list of reviewers. Not because I thought I could point out all the places where he is wrong, but because I am still curious about the field of frontend web developers. I also liked the angle, thinking “I’m a human, this book is for me!” Joking aside, technical books tend to be very dry. This one promised to have a different approach, one that I could relate to.
I read the draft in one sitting, took lots of notes and at the end of it, this whole space of the frontend world that wasn’t accessible to me, became clearer. I saw the necessity for more complex MVC frameworks on the client than I had experience with. I started to understand why structuring your code in certain ways makes it more robust in the face of having multiple people work on it. The book managed to illuminate well known concepts in the unfamiliar frontend territory. Human JavaScript made frontend development accessible to me.
Truly inspired again I went on and built a small side project. It isn’t much, but it makes me excited about building more web apps.
Human JavaScript is the collected wisdom of the team at &yet, where Henrik works, and all the blood and sweat that goes into their excellent client projects, and their own products. It couldn’t come from a better group of people. They care about the right technology as much as teaching it. They take it upon themselves to fill the gaps of missing canon for web development.
&yet are the 37signals of our generation and I just can’t wait to see what the people they inspire come up with. I can’t wait to see what you come up with.
— Jan Lehnardt
Berlin, September 27th 2013
Jan is an Open Source Software developer from Berlin, Germany. He is the Vice President of Apache CouchDB, the database that replicates. He’s the co-curator of JSConf EU, a partner at The Node Firm and his one famous JavaScript project is mustache.js. He currently works on hood.ie, an open source noBackend solution that aims to do for frontend development what Rails did for the backend: make all the tedious pain go away, and hide it behind an intuitive JavaScript API.