DEV Community: Roy Tang

Tales from the Old Web (Development)

Roy Tang — Wed, 05 Feb 2020 13:03:44 +0000

There was this great (and long!) article that came out recently about the history of CSS. It reminded me a lot of the old days when I started out in web development. So join me in a walk down memory lane as I reminisce about the trials and tribulations of early web development. (This one isn't about CSS as much as that linked article.)

I started out with web applications during the heyday of the much-maligned Internet Explorer 6, and pretty much the start of the age of webapps. Most of our projects during this time involved government agencies wanting to upgrade from their old existing client-server style systems. Those were often written in programming languages/tools like Delphi, Oracle Forms, PowerBuilder and such. That meant there was a lot of pressure on the web applications we developed to be able to match most of the client-side functionality available in those kinds of programs, which was often a challenge due to the limitations of the HTTP model.

ActiveX

Typically, the government agencies at that time used only Internet Explorer in their workstations, so we could write our web applications to target just IE specifically. This meant we could use things like ActiveX to attempt to do things browsers normally can't do. Some of it was for security purposes, like confirming the user's authentication matches the current workstation user, or for Single-Sign On purposes, things like that. There were also some for interfacing with things outside the web browser, like document scanners.

We also had to use some ActiveX to get around browser quirks. For example, IE6 had this problem with combo boxes/select elements where the width of the drop window would always match the width of the select element, but this means if the option text was longer than that width, they would not be readable. We had to make an ActiveX component just to fix this, by making the drop window wider on document load! Sample screenshot recovered from the vaults:

Some other ActiveX uses were to do things that would later on become standard features in browsers. Some other examples I can recall:

spellchecking. We used an ActiveX component from a company called WinterTree software. I was surprised to find this particular product of theirs is still available, when practically all modern browsers have spellcheck support! I suppose it's still useful for legacy environments maybe?
we had this one project that needed a complicated graphing diagram. Think about those pinboards with pictures and documents connected by wires that conspiracy theorists use in memes, something like that. These days that kind of thing can be done using modern HTML+Javascript only, but during the IE6 days we were still pretty limited. We used another third-party ActiveX (can no longer recall the component name), that we wrapped in our own Delphi program for customization purposes.

As far as I can tell, we ended up using ActiveX in some projects up to the early 2010s.

GMail and Ajax

Our initial webapps also did the thing where we would reload the page whenever doing something like going to the next page of results. This was pretty bad user experience-wise, especially compared to the client-server programs of old, which felt a lot more snappy since they were only loading the database results via the database driver, instead of an entire HTML page. By 2005, we were already using Ajax/XMLHttpRequest to get around these limitations in IE6. (The wikipedia entry says XHR didn't officially exist in IE6, so I'm not sure how we did that, but I'm pretty sure we did). Our main use was for paging search result grids, but we weren't even fetching XML or JSON back then, the XHR response would be the grid HTML itself, which we just plop right where the previous page was.

I remember I was talking to the SA for the project about ajax, he asked what it was and why we were using it, my explanations was:

Ajax is "Asynchronous Javascript and XML"; it's a method of using
Javascript and XML data that allows us to make server-side (database)
calls without having to resubmit the entire page.

We use it because it's cool =p With Ajax, we can do something like allow
the user to re-sort a grid of records without reloading the rest of the
page. It is easier for us to meet the performance reqt.

If you've seen the Google Maps or GMail webapps, they both use Ajax.

The response was (unedited):

I've used Gmail. AJas is client side library??? Seems they process very
fast.

(I would later kind of regret using Gmail as a comparison!)

Cross-browser development

Most of our projects were for internal systems where the workstations had controlled environments so we were free to target a single browser only (usually IE). Some projects also had a public-facing portal though, and that required we do some cross-browser frontend stuff. Early on, the typical targets other than IE where Netscape and Firefox. This is where the IE6 compatibility headaches come in. It was usually a game of write the code for IE first, then let the testers find any NS/FF issues, then quash accordingly.

We started checking in Firefox around the quirks mode era, as described in the article linked at the start of this post. The biggest challenge really was getting everything pixel-perfectly the same between browsers. The typical problems were:

browser differences in CSS models (the famous box model issue)
differences in native controls (typically the select and input type='file' controls were the more problematic ones)
for cases where we needed ActiveX plugins for IE6, we would also need to develop corresponding FF add-ins, usually targeting Firefox 2.x (It's fun to think about how the current version of Firefox is 70 major versions ahead of that!)

We did very little cross-browser work at the start, with the proportion accelerating in tune with Firefox/Chrome's rise in marketshare. By around 2010, it was common for projects to be testing across at least 2 versions of IE (6 and 7), 2 versions of Firefox (2 and 3), Google Chrome, and often Safari as well. (We didn't really start thinking about Mac users until around 2007ish).

Google Chrome came out in 2008, I found some old comments I made to our internal tech team when it came out:

I have an installer in t:\roy

It's not an OS, but it runs browser tabs in separate processes (literally...each one has a different PID), such that a single webapp won't crash everything else.

More info here: t:\keis\Google_Chrome.pdf

If it gets widespread adoption, it may affect the webapps we develop - it uses Webkit as a rendering engine (used by Safari), so it's different from Firefox and IE. Haven't encountered any problems yet though.

I also tested the memory usage of Chrome vs FF back then:

Try this:

Firefox - open 9 tabs. Check the memory consumption. Close 8 tabs. Check
the memory consumption. (Remains around the same as previous one)

In Chrome, the memory usage of closed tabs is 0.

This is a far cry from Chrome's modern reputation as a memory hog! (Although I guess that reputation is probably related to people keeping too many tabs open.)

Side story: while looking up old files for this post, I came upon a thread where we were discussing printing issues across browsers, and there was a problem in printing some pages from the browser because of limitations in IE6, and some management higher-up chimed in with a suggestion to "just tell the client to use IE7" as if the client will magically upgrade all their workstations for that one problem. 🤷

jQuery

As the linked article mentioned, jQuery raised the bar when it came out, allowing developers to easily paper over cross-browser JavaScript concerns and providing an API that became so prevalent, years later parts of it would become built-in to modern browsers (i.e. document.querySelector).

I shared the link to jQuery via delicious in 2006, but for sure we weren't using it yet in our projects at that time. Based on my own CV, the first time I used it in a project was in 2009. It quickly became part of our standard libraries. I still remember in one particular project I spent some time thrashing out a bunch of issues because we needed to upgrade from like jQuery 1.3 to 1.4? Or something like that. Normally we'd fix to a certain version, but I think we needed to upgrade because of a jQuery plugin we needed. This was before the modern frontend development frameworks where you already have dependency management tools, so we had to make sure none of our other third-party JS components would break with the upgrade. The company ended up using jQuery as a standard in projects up to the time I left in 2015. (I'm told they later on switched to Vue.js, so more power to them.)

I identify as a "full stack developer", but these days the "frontend" half of that usually implies usage of one of the modern frontend frameworks: Angular, React, or Vue. While I am cognizant of those frameworks and have tried them all in some form or another over the past few years, my frontend development experience is still largely defined by the jQuery era. So when setting up personal projects or quick prototypes that's still what I default to.

CSS

The linked article was about CSS, so I figured I should have some CSS stories too, but I find that I don't have much, other than the cross-browser compat above. My main issue with CSS back then was that in a large project with a nontrivial amount of developers each working on separate screens, the CSS style sheets tended to get longer and denser with time. And with bug fixes and whatnot, it would tend to be full of hacks and workarounds like randomly placing !important in so many places. I just assumed we had a whole bunch of CSS selectors that were no longer necessary but no one would bother cleaning up the style sheets because who knows what you'll break? Basically a whole chaotic mess. IDK if modern tooling handles this because I haven't been on larger projects since leaving the company, but I suppose the stronger delineation/specialization between frontend and backend dev work means less people to mess up the stylesheets, and those who do handle the styles are more aware of such pitfalls.

That's it (for now)

Well, this was a fun trip down memory lane. This post is already longer than I thought it would be, but those are all the old-timey stories I can recall right now. There's a good chance there's some more of them lodged in my brain somewhere that will come out sooner or later, so maybe there's a part 2 sometime in the future.

Adding Developers to a Late Project

Roy Tang — Thu, 13 Dec 2018 01:56:56 +0000

For any nontrivial software project of at least moderate team size, there can be a significant cost to onboarding a new team member, especially at later stages when you are rushing to meet deadlines.

The most signifiant cost is of course the communication overhead as described in the Mythical Man Month. Fun story, the CEO of a company once told me they would add more developers to a delayed project to meet the deadline and when I pointed out the increased overhead he said to me that it wasn't a problem because they would just assign modules to those devs that have minimal dependencies so they don't have to communicate so much. Ha! I just shrugged and let him think it was a good idea.

In my experience, it's never a good idea, especially late in the game. Even if you are somehow able to minimize any domain overhead (which I seriously doubt), there is also the nontrivial matter of technical overhead that any new developer intake needs to go through. I'm not just talking about learning the programming language or the technical stack - presumably if you are adding someone to the team, he is either already familiar with the stack or you have factored in his being a newbie and needing training time.

No, I'm talking about things like templates, UI standards, coding standards, devops processes, configuration, libraries in use, data dictionaries, and so on. Most projects will have "preferred ways of doing things", and the more work that has been done on the project, the more such "tribal knowledge" is often undocumented and you will need to bother someone to figure the stuff out. And if the project is behind schedule and everyone is trying to catch up, it's more likely people are going to forget to tell you stuff.

Slightly related side note: If there is very little in the way of standards or tribal knowledge global to the project, that might be a warning sign. I once worked with a client who had several subcontractors to work on the different modules in their system. Each module/subcontractor worked more or less independently from the others, with very little documentation or standards in place. The result was a weird hodgepodge system where one module did things one way, and the next module did things a completely different way, and so on.

As an example, I was once asked to help in a project with a relatively large codebase and significant deadline pressure and I was coming in hot with no knowledge of the domain and minimal experience with the framework in use. I told them I wasn't sure I could hit the target given I had to learn a bunch of stuff, but they were in desperate need and so ok we proceeded anyway. Now, I'm an experienced developer, so pulling me in was a better option than pulling in some newbie since there's a lot of stuff I can figure out myself, but off the top of my head, I had to explicitly bother other people about:

proper access rights to the repo
proper access rights to the google drive with all the documents
CRLF problems when I use windows to clone the repo
database credentials for the provided dev VM
errors encountered due to undocumented steps missing from the setup document
where should I put new configuration options
where should I put my new module in the menu
how to map data in other tables to my new tables
the proper HTML markup and CSS classes needed to conform to the way they layouted pages
how to implement form validations the same way as other screens
standard methods for displaying messages/errors
how to setup role permissions for my new screens
preferred library for making third party API calls
JS errors encountered when using a particular component
problems with dynamically created reccords not behaving properly when the page redirects on error

... and probably a lot more I'm unable to recall anymore, and that's not accounting for any comments that would be later logged by QA because I was unfamiliar with how other screens usually behaved.

If you're adding developers to a late project, you have to account for these onboarding costs, in addition to the increased communication overhead. That means sounding the alarm and asking for help earlier. If there's a module that's estimated by your devs to take say, one sprint, you can't ask for help one sprint before the needed delivery - you need to look for help maybe one or two sprints earlier. (Of course, the best approach would be to avoid painting your project into this corner at all, but as we all know in this industry, sometimes things just happen!)