…​same as the old ThirstyHead.


See, here’s the deal. It’s still me — Scott. Always has been. But a lot has changed since this URL first hit the web.

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.

Scott Davis, 2006

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 (née 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. 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 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…​)

Scott Davis, 2009

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.

Scott Davis, 2011

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 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.

His developers had no understanding of HTML, CSS, or JavaScript because they simply hadn’t been using it — for almost a decade. To add insult to injury, any meager platform experience his team DID have was hopelessly out-of-date — by at least a decade. They were experts in Flash, but a Flash app is like flying a UFO into the browser — you rarely interact with the natives, and when you do, it’s with pity and contempt through the jaundiced eyes of an "advanced civilization".

And believe me, at this point I was quite familiar with the contemptuous attitude most "real" developers had towards this "toy" programming language called JavaScript. Don’t forget — I spent the first 10 years of my programming career as a Java developer. That patronizing attitude was almost required of us.

Jeering at the diminutive junior namesake of a "real" language wasn’t simply being petty or provincial — it was baked into the official history and narrative of JavaScript from the start. No less an authority than Brendan Eich — the creator of JavaScript — characterized JavaScript as a language for "hobbyists", a stepping stone towards the more advanced, "real" language capabilities of Java.

Sibling rivalry is rarely the foundation of thoughtful, nuanced discussions — especially when people aren’t willing to acknowledge the familial history in the first place. It’s a revelation to many of the seasoned Java developers I meet that Java and JavaScript were introduced to the public on the same day, in the same place — a little web browser called Netscape Navigator 2.0 on May 23, 1995.

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."

Even I’m willing to admit that in the earliest days of JavaScript, perhaps those grapes were a bit tart. But they were not nearly as inedible as contemporaneous Java developers would have you believe, and in case nostalgia clouds your memories, allow me to remind you that Java was differently yet similarly immature as JavaScript was back in those primordial 1.0 days. It’s folly to think that 20+ years of active development has added sophistication to one of the languages and left the other in its 1996 infant state.

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 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.

We avoided using TypeScript from the beginning, largely because I was concerned about the potential drag on our project’s velocity as a result of bringing in 3rd party dependencies that didn’t have the associated non-optional TypeScript artifacts. As it turns out, even bringing in plain old JavaScript libraries was unexpectedly, punishingly difficult. Few of the libraries utilized ES6 modules, so we were faced with the unsavory choice of either metaphor-shear (this one is global; that one must be imported) or fiddly retrofitting old stable libraries to satisfy our new module loader’s demands.

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, Sir Rantsalot?

I like Polymer. I really do. (#useThePlatform, Yo!) But as I started to build out the new 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 over the years, I have absolutely nothing to show for it. And here I was, about to do it again.

I have full codebases in Java, in Groovy, and in JavaScript, and yet I have no foundation to build this latest version of the website on. My content is all tied up in legacy databases I no longer want to support, and my exoskeleton is implemented in artifacts that aren’t reusable across languages and servers (JSPs, GSPs, etc.) Once again, I am pursuing the "del *.*" upgrade method (technically, "rm -rf *", but a rose by any other name…​).

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.

I’m gonna write this website in HTML. And CSS. And JavaScript.

(Not dramatic enough?)

I’m only going to use my own handwritten HTML, CSS, and JavaScript — no third-party libraries. No frameworks. No UFOs.

(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…​)

I limited myself to only HTML and CSS for this first pass — not a lick of JavaScript to be seen, and it made me more uncomfortable than I care to admit. I copy and pasted chunks of text around that would be better served by Web Components. I have a ton of duplication that is crying out for Templates and pagination. But for this first pass I wanted to feel that pain personally, and understand what needed to be built up instead of fearfully relying on a YAGNI-laden library all full of someone else’s pain-relief.

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.)

This is not a screed against web frameworks or programming languages other than JavaScript. I will certainly continue to use them professionally, write about them, and talk about them at a software conference near you. But what you read here at from now on will be unapologetically my voice once again, and what you see will be unapologetically my source code.

GitHub (with GitHub Pages) is a completely free place to host your website. (You can see the raw source for this website at There are many other sites out there that offer similar functionality.

Your move.