Tech Talk 2: Front-end Fever

Despite the amount of care I've put into mocking up the homepage for travelectable, I haven't really added much front-end code to it (front-end code being defined as Javascript, not HTML and CSS).  Part of this is simply because we need to limit ourselves to sketching the basic outline of the site before we cast our spells and add our magic, but part of it is also by measured design.

Even though I haven't started any earnest front-end efforts, I'm more confident about the tools I'll use than I was with the back-end, which is crazy, because I've been much more familiar with back-end programming over the course of my career.   But, in the case of the front end, my decisions are based more on what I don't want to face than what I'm looking to leverage.  Here's a (mostly) complete list:

• HTML (duh)
• tailwindcss for CSS
• Flowbite for HTML components
• htmx, hyperscript, and Alpine.js for Javascript functionality and client-side state management.

My hope is that my reliance on each of those technologies degrades exponentially in the order they're listed.  Keeping that in mind, I have to give a special shout-out to HTML over the years.  It's added a lot of common sense constructs that used to require funky workarounds in Javascript in years past.

Ditto CSS.  I'm constantly amazed at what a simple combination of HTML and CSS can accomplish.  Originally, I wanted to use Bulma as a CSS framework (and you can see in my initial commits that I did).  However, I'd already grown familiar with tailwindcss and I found myself struggling with Bulma's differing methodology, so I thought I should make a sensible substitution sooner rather than later.

I didn't choose tailwindcss to begin with because it drives me nuts that, for production systems at least, I need to install node to use it.  WHY DO I NEED TO INSTALL NODE FOR ANYTHING CSS?  This is one of my largest pet peeves with modern web development.  Everything is Javascript.  I either need to install node (in the most merciful cases) or I need to become intimately familiar with React to add the most basic functionality.  I opted to use Flowbite because its HTML components are composed solely using tailwindcss styling and HTML.  This isn't common among the myriad frameworks that provide components.  They usually require the injection of a much larger JS framework.

In defense of tailwindcss, it uses node to optimize the classes you use and mix in your customizations.  It also offers a cdn so you don't constantly need to keep node running during development.  So, any reliance on node is a build step during deployment rather than a run-time dependency.  This seems to be a reasonable trade-off.

I get the criticism against tailwindcss that permeates the internet - it's verbose; it essentially litters your HTML code with style elements (which is what CSS has fought against throughout its history); and it ostensibly presents problems managing it at scale, because you can't simply tweak a class, you need to tweak every occurrence that uses its styling.

But, as someone who isn't as competent in CSS as others, I appreciate that it's explicit, its documentation is rock-solid, and it's very easy to see the immediate effects of the changes and iterate if they're not quite correct.  The knock that it takes time to learn is a dubious one, because everything takes time to learn.  If you already know CSS, then, yeah, it can be a pain to learn, but you shouldn't be forced to use tailwindcss in that case (then again, companies will often die on the hill of standardization even if it acts against their own business interests all in the name of appeasing the myopic god Synergy).  

I also find the arguments in favor of managing tailwindcss that follow the thinking of "establish a corporate standard for the order in which you write tailwindcss classes for your HTML elements" to be naive as well.  If there's nothing that enforces that order other than corporate culture, it's going to fall apart quickly (*cough* Hungarian notation *cough*).  You're falling prey to the tool's idiosyncracies rather than making it work for you (or at least writing additional tooling to minimize the idiosyncracies' visibility).

You can likely get around these problems by creating custom classes in tailwindcss config.  I can hear purists exclaiming "then why not just do it in CSS?!?"  Well, because nothing's perfect.  Why not just use a sensible, mixed solution that's simple and easy to follow rather than hunting for the philosopher's stone and unicorns simultaneously?

Now that we've chatted about HTML and CSS, what about Javascript?  As I mentioned in my last post, I like Javascript.  I think it typically gets a bum wrap from the back-end community.  But, just because I like the language doesn't mean I like the way it's being abused on the front end.  

When Ajax first reared its head about two decades ago, it was a novel concept.  We now had the capability to have a website respond similarly to a desktop app and users appreciated the streamlined interface.  We didn't have to suffer through page reloads for every action anymore.  The page just felt more intuitive.  

So what did we do?  We added more, more, more!  We created frameworks that essentially pushed all the overhead of the server onto the client along with all of the complexity server-side programming encapsulated.

In most modern designs - just for a simple website that accesses data - we need to run two servers: one for the back-end and one for the Javascript framework (like React).  This seems a little excessive.  In some cases, you can just run the client-side server, but anything that needs a database (that's any non-trivial app) needs a back-end server.  This isn't two services running on separate servers - that's a common engineering pattern that makes sense.  This is one service split into two to accommodate today's typical design sensibilities.

Luckily, people are starting to reevaluate the need for this complexity.  The three tools I mention above (htmx, hyperscript, and Alpine.js) attempt to minimize the use of Javascript without sacrificing its utility.  They eschew the encapsulation in components that frameworks like React shine at, but they do so by introducing less boilerplate code and complexity.  And there are existing constructs that allow code to be re-used that help mitigate this lack of encapsulation.

I hope to make the site look and act like a modern website.  A responsive design is paramount in the age of mobile computing and there are Javascript features where the usability of the feature far outweighs the maintenance (type ahead search being the first key one that springs to mind).  However, we shouldn't become beholden to our need to make things flashy.  Users want, first and foremost, a site that works and a full-page reload isn't going to dissuade them from using your site if they find it useful.  In addition, the less complex the site is, the less we have to worry about browser and device compatibility, and the more likely we are to have a working model we can understand.  To quote Einstein, "everything should be made as simple as possible, but not simpler."

Until next time my human and robot friends.