Wednesday, February 23, 2017 [Watch on YouTube]
Meet the new ThirstyHead…
ThirstyHead, c. 2006
ThirstyHead came to life in 2006, right around the release of my first book JBoss at Work. Of course, back then ThirstyHead was called Davisworld Consulting, Inc. — perhaps the single most forgettable business name incorporated that year.
It matched the single most forgettable haircut of the year.
I had just rolled off of two really meaty full-time gigs — working on a pre-release version of Google Maps in 2005 with DigitalGlobe, and writing an integrated Open Source Software installer in Groovy for a startup called OpenLogic. I was speaking at software conferences around the US and around the world — at least 20-30 weekends a year with No Fluff Just Stuff alone.
I didn’t realize it at the time, but 2006 was a major inflection point in my life.
Up until then, I’d been a fairly traditional J2EE web developer for nearly a decade. (I jumped into the Java stream at the 1.1 headwaters.) I’m certain that the first version of ThirstyHead.com (née Davisworld.org) was deployed using that tech stack, but I can’t prove it. I’ve searched my personal backups for minutes — MINUTES, I tell you — just for a glimpse of that glorious codebase, to no avail. So you’ll just have to take my word for it — it was a set of JSP pages, JSTL tags, and the occasional Servlet talking to a PostgreSQL database.
Up until 2006, my website had been just that — MY website. I had a Blojsom blog where I talked about MY newborn kids, MY cooking adventures, MY friends — me.
After 2006, I developed a state-sponsored split personality. ThirstyHead.com was no longer me — it was a brochureware website for this company I founded. In effect, ThirstyHead became a client of mine, and it didn’t feel right talking about my kids on "their" corporate website.
ThirstyHead, c. 2009
Flash forward a couple of years, and ThirstyHead is in full stride. I had already architected a new, fully F/OSS mapping website for TriMet — the Portland, OR transit authority. They came to me and said, "We want Google Maps WITHOUT the Google Maps…" In other words, they wanted the Google Maps experience, but on their servers, with their data, at their own URL.
This was right in my wheelhouse, having written GIS for Web Developers (possibly my favorite book and, sadly, out of print) as well as several books and articles on the Google Maps API. I was traveling the world teaching classes and giving talks like "Roll Your Own Google Maps" and "Adding Where to Your Applications".
I was also neck-deep in the Groovy/Grails ecosystem at this point, and ThirstyHead.com was solidly a Grails app. I had one of the first public-facing Grails-based websites back in the version 0.3 days, and kept up with each new dot-release for years to follow.
Groovy Recipes (also out of print — do you see a pattern forming?) was the right book for the right time — allowing Java developers to get up-to-speed quickly in this new paradigm-shifting language that offered full source code and run-time compatibility with Java. My talks "Groovy, The Blue Pill: Writing Next Generation Java Code in Groovy" and "Groovy, The Red Pill: Metaprogramming, the Groovy Way to Blow a Buttoned-Down Java Developer’s Mind" won me a couple of JavaOne Rock Star awards. (My hair at the time had to help…)
I had a voice — I wrote several long-running article series for IBM developerWorks, including Practically Groovy and Mastering Grails — but I was no longer writing about myself, for myself. Writing was work. Writing paid the bills. I was a professional author (for some value of the word "professional").
Around that time, this shiny new computer came out — called the iPhone — in 2007. I had already been writing websites for the mobile platform using WML (Wireless Markup Language) and WAP (Wireless Application Protocol). I was doing Palm Pilot development using J2ME — fun stuff like capturing signatures as SVG, uploading them to Java Servlets, and then using Apache Batik to convert them to JPGs for web consumption.
But the iPhone was a different beast entirely. It had a proper web browser, and it did what no other cell phone at the time was able to do — it reunified the web into a single platform, killing off the separate but equal "m-dot" websites with little regret.
The web on the iPhone was the proper web — albeit with an entirely new UX paradigm comprised of fingers and pinches and swipes — and I dove in head first. When the App Store came around with the iPhone 2.0 (and remember — HTML was the officially Apple-sanctioned way to do iPhone development up until then), I had no interest in catering to a single-platform solution like Objective C. I had been dipped in "Write Once, Run Anywhere" for too long to heed the siren’s call of a one-trick pony, however attractive that pony was.
This led to the next phase of ThirstyHead.
ThirstyHead, c. 2011
2011 started the modern era of ThirstyHead. I co-founded the HTML5 Denver User Group that year. I was slinging HTML5 on smartphones and tablets, desktops and laptops, even SmartTVs.
I headed up a team that designed and implemented the Samsung SmartTV interface for a major cable company, written entirely in HTML5. For another project, we wrote a mobile web app for the Colorado Department of Transportation that helped disseminate information about ongoing construction projects — lane changes, exit closures, and a traffic "thermometer" that included live camera views at key intersections atop a Google map.
2011 was the year that smartphones first outsold laptops. We’re now living in an era where mobile internet usage surpasses "legacy" desktop usage, and that tiny handheld 4-inch slab of glass is, in many cases, a person’s sole portal into the World Wide Web.
At this point, the ThirstyHead.com website was a NodeJS app with copious amounts of Twitter Bootstrap sprinkled over it for that extra tasty Responsive Web Design goodness.
It was around this time that I started feeling a vague, general malaise about web development, but I couldn’t quite put my finger on it. Not about the Information Superhighway itself, but moreso the vehicles we were building to hit the onramp.
I learned BackboneJS and Bootstrap. jQuery mobile. AngularJS. None of these are bad projects. I genuinely enjoyed my time working with each one of them.
Many of the gigs I was being brought in to tackle at the time were more than simple "Can You Help Us Make Our Website More Mobile-Friendly?" projects. They were, according to the client, full-on rescue projects. "We’ve had developers working on this for over 2 years, and we haven’t shipped a single release yet."
One manager said, "We’ve been doing Flash/Flex development for almost a decade. I have no idea why my team can’t get up to speed with mobile HTML5 techniques after a day or two of classroom training." I gently explained to him that, while Flash apps are run inside the browser, the Flash development process has almost nothing to do with core platform web development.
Client-side Applets were supposed to be the future of Java, but server-side Servlets are where Java rose to prominence. Perhaps this is the root of the pervasive sour grapes attitude common among many Java developers — "Server-side is where all of the civilized action takes place; the web browser is a Mad Max-esque post-apocalyptic lawless desert wasteland."
It amazes me that — even today — the web platform is often characterized as "impoverished" and "disjoint", and that UIs are better off generated from another (more powerful?) language than natively written. No company would dream of hiring a Java developer without Java experience (or a C# developer without C# experience; or a Ruby developer without Ruby experience), and yet back-end "web developers" (air-quotes intentional) who have never had any formal training in core web platform technologies are commonplace.
When the development team struggles to produce a viable web app, the culprit is almost always assumed to be the current framework in use, and the solution is almost always finding another, newer, more improved framework. Improving the team’s impoverished and disjoint core platform language skills is rarely considered when adding (and learning) Yet Another Layer of Abstraction can mask the symptoms for a little while longer instead of curing the disease.
So, what does all of that have to do with the shiny new ThirstyHead.com in front of us, Mr. Ranty McRantsalot?
ThirstyHead, c. 2017
Last year, I started a new project using a prerelease version of Angular 2. The early learning curve was quite steep — even (especially?) for a team of experienced Angular 1 developers. I initially chalked our struggles up to the new platform metaphors like ES6 classes, Web Components, and Reactive Streams. But even after we internalized these new concepts (by learning them outside of the framework), Angular 2 felt more like an opaque abstraction layer than syntactic sugar.
And don’t even get me started on the tooling requirements. Angular 1’s "Hello World" started with "Add this <script> tag to import the Angular library" and you had your first example up and running in seconds. Angular 2’s "Hello World" was a 10-15 minute byzantine multi-step, multi-file process that required build scripts, module loaders, and an especially fragile coterie of import-order-specific library dependencies — many of which were Angular-specific forks of independent projects.
I spent more time writing Yeoman scripts to automate the complexity away than writing application features. I invested heavily in writing custom Gulp scripts, hoping to encapsulate and insulate the team from the high ceremony of the framework. Instead, I ended up spreading on Yet Another Layer of Abstraction that ultimately hindered our understanding of the framework instead of enhancing it.
So, after nine months of development, we scuttled the codebase and started over. We had already been successfully using Polymer / Material Design for basic UI components (tabs, dialog boxes, form fields), so why not use it for the entire app?
The team enjoyed the dramatically simplified development process, and the Look and Feel far surpassed anything that we would’ve been able to come up with on our own. Management was initially concerned that we were chasing Yet Another Shiny New Framework (we weren’t — Polymer was stable at 1.6, with a 2.0 release around the corner). I reassured them that the core ideas we learned for Angular 2.0 (ES6 classes, Web Components) were at play here in Polymer as well, so this was more of a mild syntax change than a deep, semantic change of direction.
So, what does all of this have to do with the new ThirstyHead.com, Sir Rantsalot?
I like Polymer. I really do. (#useThePlatform, Yo!) But as I started to build out the new ThirstyHead.com in it, I finally came to grips with the general malaise I’ve been feeling all of these years.
For all of the hundreds (if not thousands) of development hours I’ve invested in ThirstyHead.com over the years, I have absolutely nothing to show for it. And here I was, about to do it again.
This speaks to a deeper, more uncomfortable issue. I don’t get paid by this customer, ThirstyHead, to develop their website. In fact, I’m paying my customer with precious personal hours that could be otherwise spent with my wife, my kids, my guitar, my oven, my grill, etc. So I am highly motivated to minimize the cost and time spent on this project.
And what have I historically invested my limited development budget in? Languages and frameworks instead of content. Scaffolding instead of substance. Ephemera masquerading as foundation.
Meanwhile, the very first website ever written by Tim Berners Lee is available and readable today, from any browser on the planet — even (especially!) from browsers and platforms that didn’t exist until decades long after the page was originally written.
The Bespoke HTML Challenge
Apparently, this is my cue to give a lofty, full-throated manifesto. After all of the buildup, I’m afraid it might be a tad underwhelming.
(Not dramatic enough?)
(Still not enough? How about a Call to Action?)
I think that you should, too.
Not everywhere, but somewhere. At least once.
Because this is what web development is. Don’t allow anyone to convince you otherwise. Don’t get fooled again.
Your first attempt may look janky and warty and nothing at all like Bootstrap or Material Design or WordPress or Medium. That’s OK. If it bothers you enough, it won’t stay that way for long. (And thanks for waiting a respectful amount of time before agreeing with the "janky" and "warty" parts as you gaze upon my first attempt…)
What you are witnessing here is a Minimum Viable Website. Interestingly, back in 1995, they were just called "websites".
(In the spirit of full disclosure, I wrote the long-form prose of this page using AsciiDoctor, but only to automate the mundane <p> and <h1> insertions. Everything else you see here was lovingly hand-crafted.)
GitHub (with GitHub Pages) is a completely free place to host your website. (You can see the raw source for this website at https://github.com/ThirstyHead/thirstyhead.github.io) There are many other sites out there that offer similar functionality.