30 Years
In my office, I have an old Macintosh SE/30, the first Mac I owned myself (I used my dad’s 128 when he brought it home, which we upgraded to at Fat Mac and eventually to a Mac Plus). On the hard drive is an HTML file with a “last modified” date of June 3, 1993. That’s 30 years ago today.
I’ve been a web developer for 30 years.
When I started, there were about 70 web sites in the world. I think there were more gopherspaces than web sites at that point. I had a Sun workstation on my desk at work at the time, so when the NCSA at the University of Illinois released XMosaic at the end of April, I downloaded it and was able to browse the web the way we think of it today. More importantly, I was able to use the “View Source” menu item and look at how these pages were produced. What I found was quite similar to what I worked with every day, which was troff macros for formatting books. The troff tag .P was an exact match for the HTML P tag, for example. I’m sure I starting writing my own stuff up pretty quickly, but today is the anniversary of the earliest day I have absolute proof for. So today I mark 30 years as a web developer. I’m sure I had come across the web before that; Ed Krol came out with a book in September, 1992, called “The Whole Internet User’s Guide and Catalog”, and I got a copy of it very early on from a bookstore in Philadelphia. Internet books did not show up in your local Barnes & Noble at the time. That book had a chapter in it about the web, and I know I spent some time using the old line mode client before XMosaic came out, but it was XMosaic that really crystallized everything. When I was a broadcasting major in college, one of my teachers, who was an executive at the university-owned TV station where I was working, told us that they expected an upcoming convergence of broadcasting, computers, and publishing. At the time, in the mid 1980s, they thought it was going to be Teletext, which was transmitted in the vertical blanking interval of TV signals. When I saw XMosaic, I recognized it as the thing that was actually going to usher in that convergence.
I remember showing my boss the web, saying that this was the future. He nodded and forgot about it. In October, when NCSA released Mosaic for Mac and Windows, another one of my co-workers showed it to him and he asked if I’d heard of it. I told him I had demoed it for him back in May. I was working as a technical writer at the time, and we started discussing the possibility of licensing Mosaic to include with the programs we were documenting as an online help system. The thing that made us decide not to was that web browsers didn’t support tables at that point, something that anyone who worked as a web developer in the late 1990s might find astonishing, as tables were the hackish way we did layouts starting in the mid-1990s (before that there was really no way at all of controlling page layout other than using header tags for typography).
Within a few months, I had transitioned from being a tech writer to making web sites full time.
In 1996, the company I worked for, AT&T, split in two, and I wound up going with the part of the company that made hardware, Lucent Technologies. I was part of a three person team that worked on the Bell Labs web site. A lot of the work was repetitive, so I tried to automate the most repetitive parts. I created a little content management system that would help me turn around press releases very quickly. It was only a local thing on my own computer rather than something I built on the server. I used a piece of middleware called Tango and ran WebSTAR as the server on my local Mac. Tango talked to FileMaker Pro and generated the pages in the format I needed, which I would then upload to the Bell Labs site. I could post a press release much more quickly than the team that ran the main corporate site. But I would up getting laid off when Lucent ran into problems when the first Internet bubble burst. I went off to work for a startup for a year, which was a long story and not a positive thing, and wound up back at Lucent a year later as a contractor, working on both the Bell Labs site, which still had most of my code but with a new look and feel, and on the main corporate site. I did that for a few more years until Lucent was swallowed by Alcatel and my services were no longer required. That was in 2008. I saw that layoff coming, and had put some money away so I could take my time and figure out what I wanted to do.
What I wanted to do was work for an agency. I had seen so many instances where agencies were assigned all the interesting projects, and the in-house developers were left with the less interesting things. I wanted to work on the interesting things. Thanks to the efforts of a headhunter I worked with, I got a job at a small agency in NYC. I’ve been in agencyland ever since, a couple of months at the first place, then 2 years at a much larger agency that was part of a traditional advertising firm, then 13 years at one of the original digital agencies that spun up in the mid 1990s when the Internet caught fire, and now with a startup agency with some of my friends who also left that digital agency recently. One of the best things about moving to an agency was that I now worked for people who knew what I did. My direct supervisors actually did the same thing I did. That was not the case when I worked in industry, and it was the cause of much frustration and ultimately of layoffs because the people I worked for didn’t know what I did.
When I discovered the web in the early 1990s, the head of the group we were part of was a brilliant computer scientist named Jim Kutsch. He was blind. He had invented a talking terminal in the 1970s for his PhD thesis that connected a speech synthesizer to a VT-100 terminal (note that this is years before the first software commonly recognized as a screen reader). He was still using it when I worked for him in the early 1990s. From the very beginning of my career, I recognized accessiblity as a potential boon and potential problem for the web. At the time, really the only thing you could do to make a site inaccessible was to not include text in the alt attribute of images. Every accessibility professional I know is groaning as they read that, because 30 years on, that’s still the most common accessibility issue. I have talked peoples’ ears off about accessibilty for my entire career. For the first 20-25 years, they nodded their heads and then went on with their business. In the last 5-10 years, things have changed. That digital agency I spent 13 years working for got sued and that drove accessibility to the top of their agenda. Still, it’s not easy, but in the past couple of years, I see signs that accessibility is really going mainstream. Libraries and frameworks like React did not originally concern themselves with accessibility. But looking at component libraries for a new project at my new job in recent weeks, I was surprised and gratified to see that a hefty percentage of the libraries I used touted the work they had done to make their components accessible. That’s a sea change. We may finally be getting back to a point where it’s possible to make a site accessible by mistake or without intention as opposed to the standard approach for the past 30 years of making a site inaccessible by mistake or without intention. I say getting back to a point because the original specifications for HTML did not include the img tag, and the web was pretty much inherently accessible until that tag was introduced.
Web development has changed dramatically over the years. When I left Lucent for the final time, I was sick and tired of working on sites that didn’t understand semantic markup, SEO, accessibility, etc. I had resisted working in NYC because of the lengthy commute, but at that point, it seemed like the only place I could find work with like-minded developers was in the city. Web development standards were changing, thanks to the efforts of things like the Web Standards Project that drove browser makers to end the browser wars, and the development of the HTML 5 standard, which is like a million pages long mainly because it describes exactly how every browser has to behave in the face of broken code, so that all browsers work the same. But the distribution of that knowledge and those practices was uneven, and hadn’t made it to the suburbs. So I went to the city to work. I would say about ten years ago, things really started to shift. Young developers may have never encountered a layout done entirely in tables at this point. There were a few years there where semantic markup and understanding what the point of new tags like article is was the hot thing. And then we moved on and that was forgotten in the excitement of confusing new approaches to web development and frameworks like Angular and React.
About five years ago I went to the staffing person at our agency and asked to be put on a project that used React, because it was clear I would need to learn it in order to stay relevant as a developer (I had been working with Angular and really didn’t want to keep going in that direction). One thing that’s been constant through the years is that as web development has changed, with every change there’s a changing of the guard to some extent. I often run into people who tell me they used to be developers. And it doesn’t surprise me. When CSS became a thing, some developers decided that the easiest course as the entire approach to developing sites changed was to move into a different part of the business. When Javascript started becoming much more important, again, some people hived off. At certain points, this coincided with a switch from the old webmaster era, where one person could understand everything they needed to know to create a web site, to what we have today where creating web sites is complex enough that it warrants having people for every specialty; SEO, user experience, visual design, project management, etc. All of these are fields that my friends who used to be developers wound up moving into instead.
Getting back to React. I’m not a huge fan. I describe React this way: Imagine that the web is a red rubber ball. Red rubber balls have a seam. If you take a sharp knife and cut half of that seam, then reach in with your fingers and flip the ball inside-out, that’s React. For a few years there, all the computer scientists flooding into web development talked about Model-View-Controller as the proper way to structure a web application. I agree. My favorite MVC framework for the web is... the web. You have this language that you use to model your data. It has limited semantics, but you can extend it to some extent (use proper HTML tags to describe the data and extend with classes and IDs). Then there’s a language that describes the view (CSS). And you have Javascript to be the controller. And most importantly, you don’t mix the three. It always amused me that people who insisted their Javascript apps follow MVC didn’t get the irony that they were violating MVC at the most basic level.
Of course, React isn’t even an MVC framework; its proponents say it’s at best the V part. But the move to putting everything in Javascript seems insane to me anyway. The web is a three legged stool. You have HTML as the first leg. If you get your HTML wrong, there’s a million page specification to ensure that the browser deals with it in the same way and you probably get what you intended anyway. It fails gracefully. CSS is the second leg. If you get your CSS wrong, browsers will ignore the part that’s wrong and just render everything else. It fails gracefully. Javascript is the third leg. If you get your Javascript wrong, the code fails completely and refuses to run. So which of these three legs are you going to commit your entire site to?
One of the bad effects of React is that a lot of good ideas about web site development went by the wayside. One in particular is progressive enhancement, the idea that you build a web site that works no matter what, then use more advanced technologies like Javascript and some of the more recent additions to CSS to make the experience better for users with browsers that support them. This approach ensured that search engines could index your site, and that errors in your Javascript wouldn’t prevent users from completing their tasks. React and other similar frameworks just kind of overwhelmed that.
That said, there seems to be something of a backlash brewing. On my current project at my new job, we decided to use a server side framework called Remix that takes code written in React and runs it on the server, then hydrates the pages so generated so they work like a single page app like a standard React approach. It’s similar to Next.JS in that sense. Remix does a lot of work behind the scenes to ensure that sites you build with it work even if the Javascript on the browser side fails, which is to say, progressive enhancement (they actually use that term on their site). I actually feel like I can use all the knowledge I’ve built over the past few years about how to build React sites to build sites that work the way they should instead of the way the industry has collectively hallucinated that we should for the past several years.
It has been an interesting 30 years. It’s been a wild roller coaster ride, with lots of ups and downs, periods of unemployment and periods of making a lot of money, periods where we get better at what we do and periods where we forget all the lessons we’ve learned over the years. It’s been a hell of a ride. I’m not going to be doing this for many more years; I was almost 30 when I started making web sites and I’m almost 60 now. But it’s been an awful lot of fun. Things are changing again. Things like ChatGPT and GitHub Cockpit are amazing. I have occasionally used ChatGPT to help write code on a couple of personal projects like the Instagram and Twitter archive sites I recently created. It is a mixed blessing. It rarely gets code right on the first try. Cockpit is somewhat better. It’s like a really smart autocomplete most of the time. And you can really work it out by writing your code as comments and see what it comes up with. Again, it’s not always right and it’s not perfect, but it’s impressive. And I think it makes me a faster coder. It’ll be interesting to see if people starting as developers today can post articles in 30 years about their experience as developers or if the machine learning bots get better enough to take over. I’m glad I won’t be doing this so much longer that this becomes an issue for me.
One of the most interesting aspects of web development has been the low barrier to entry. At the beginning, it didn’t require a computer science degree to create a web site. In a lot of ways, the professionalization of web development has been the counterattack of the computer scientists and the move to Javascript as the primary way to build a site professionally a way of installing a gatekeeping function. But it is still possible to create a web site the old fashioned way, with HTML and CSS and a server somewhere for a few dollars per month. Browsers still understand those. And if View Source is less useful than it was 30 years ago because of obfuscation and minimization, at least there are web sites out there that explain how to build a web site. The best thing about this industry has been people’s willingness to share what they know. I hope that never changes.
Posted at 7:13 PM