Web Apps - Bane of my Existence

I have a confession to make.  I hate writing web applications.  

Whatever modicum of credibility I may have had with "real programmers" I am about to douse in gasoline and light on fire with this article.

Reduced programming efficiency

There are many reasons for this.  The first has nothing to do with web applications, per se.  The problem is that by the time I've shifted my brain into thinking in whatever different programming language I'm writing in, I'm done with the project and I'm back to writing in my "native tongue": VBA.

I'm so proficient writing VBA and I have such a deep code library built up after 10+ years, that I spend all my time in Access and VBA thinking about how to solve the problem I'm working on.  When I'm working in another language for short spurts--a few weeks to a few months--I spend all my time looking up syntax and figuring out the canonical way to recreate the VBA Mid() function in whatever my language du jour happens to be.

The problem is not the difficulty in learning a new language.  Most seasoned programmers, when fully immersed in a new language, can "carry on a conversation" within a couple of weeks and speak it "fluently" within a month or two. The "idioms" and other nuances that separate a native speaker from someone learning it as a secondary language may take several months, but that's about it.

Therein lies the problem for me.  My project is done just as I'm starting to speak this new language natively.  By the time I come back to it, several months or years have gone by and I'm back almost to square one, needing to knock the rust off to get back into the groove.

I actually enjoy writing in different languages--writing C# in Visual Studio is like nirvana for an IntelliSense junkie like me and python is just plain fun.  In other words, there's nothing inherently wrong with any of those other languages.  I think most of them are better than VBA, though the difference has more to do with the support around those languages than the languages themselves.  For me personally, though, I feel like I'm walking through eighteen inches of mud with a 75-pound ruck on my back when I'm writing in those other languages, whereas with VBA I feel like I'm running on a track with a 20 mile-per-hour tailwind.

What am I even supposed to use?

There are so many choices.  And that is the problem.

I often spend almost an entire week trying to choose a language, platform, and/or framework for my web application projects.  I have done web projects in the following languages/frameworks:

• Python/Django
• Python/web2py
• C#/ASP.Net Framework
• C#/ASP.Net Core

I also wrote a scheduling application using C#/WPF and the calendar add-in from DevExpress.  I try to pick platforms with enough support that I don't have to worry about them disappearing any time soon.  Also, I usually need a lot of help so a strong community is important.

To make matters worse, it seems like I can never simply use what I used the last time.  There's always something newer and shinier out there.  I don't generally like going for the newest, shiniest object, but in the web application world those are the only ones that seem to get ongoing support.  

Desktop development platforms tend to have 10-20+ year lifetimes.
Web application platforms seem to have 6-18 month lifetimes.

This part drives me nuts.  I write the vast majority of my applications in Access with a SQL Server back end.  Those two tools have improved incrementally over the past 20 years, but they remain fundamentally the same products.

Our company writes lots of $5,000 - $20,000 projects that we go on to support for decades.  With those kinds of support timelines, reading tea leaves becomes critically important.  Which frameworks have staying power?  Which frameworks will be gone and unsupported in five years?

The utter disregard for backwards compatibility

Here is where I really lose my mind.  Nothing frustrates me more than willful disregard for backwards compatibility.  Especially when the only goal seems to be to clean things up in the framework's codebase (I'll get to this in a minute).

I have no problem with deprecating old functions.  By all means, show warnings and encourage users to use new and better ways of achieving their functionality.  But unless we're talking about a security issue with NO OTHER LESS INVASIVE WORKAROUND, then leave the old functionality in place.

I'm currently moving several small websites from Webfaction to Opalstack (affiliate link).  I've been with Webfaction for over 10 years.  GoDaddy bought them out a couple years ago.  On October 13, I got an email letting me know that my account would be migrated to a new host sometime between November 2020 and June 2021.  Three days later, I got an email that said, "Nah, just kidding.  We can't migrate your site so everything will be deleted on December 9."  Whoa, whoa, whoa, what was all that June 2021 talk?  

But I digress.

As you might have surmised, the underlying reason for this 1,300+ word rant is that I'm dealing with web application issues as I migrate between shared hosting providers.  One of the applications I wrote in Django over 13 years ago.  I've upgraded it a few times since then, but have not made any major changes.  I'm currently upgrading it to run under Django 3.

As I'm doing this upgrade, I ran into the following error:

Sure enough, under Features removed in Django 3.0, the following note appears:

The staticfiles and admin_static template tag libraries are removed.

Hmm, I wonder why?  Oh, there's a link to version 2.1 when these features were first deprecated.  Let's see if there's any extra information or background at that web page:

{% load staticfiles %} and {% load admin_static %} are deprecated in favor of {% load static %}, which works the same.

Whoa, whoa, whoa, let me get this straight.  You made a change to your framework that would one day break existing code because...you wanted to condense two different routines into one?  And you were so worried about how clean other people's code is that you made this a breaking change?  You couldn't simply redirect calls to load staticfiles and load admin_static so that those routines passed through to load static, and thus would continue to work in perpetuity?

To reiterate, I have absolutely no problem with the deprecation.  By all means, deprecating code is a good way to boost your Signal to Noise ratio.  But, my goodness, there is a Grand Canyon between deprecating code and introducing breaking changes.  Do the former all you want, but you better have a good reason before you ever do the latter.

Closing thoughts

Thank you for sticking with me if you made it this far.  This post is rantier than normal, but it came as a result of my frustrations.  It felt good to get some of that off my chest.

Finally, I would be remiss if I failed to mention that I chose to use web2py--a python web framework you've almost certainly never heard of--in large part because of their commitment to never break backward compatibility.  Over ten years, they have been true to their word.  I've updated the software several times over the years and every update has gone smoothly.

I also felt kinship in the web2py community. The Django developer community looks down on them with disdain because web2py is not "pythonic enough." A small group of developers writing productive applications in a platform that's not deigned sufficiently difficult by those who consider themselves to be "real programmers." Sound familiar?

Image by Åsa K from Pixabay