$ ls -R ~/








Dev Log: Creating art on the web – tech stack


Date: 07/29/2019

Creating art on the web isn’t entirely different from creating art in any other medium; you have your tools that you use, and there are a variety of them out there for each medium. Brushes & paints for painting. Cameras and lighting for photography. For the web, you’ve got.. Well.. A lot more to deal with. So, continuing my discussion on the redesign process, I’d like to talk about tech stack considerations.

What tech stack do I use?

I’ve been a LAMP stack fan for years upon years. For those of you who aren’t web geeks, that’s short for Linux, Apache, MySQL and PHP (or Perl). You can’t run WordPress without those last 2, so obviously, I’m pretty comfortable in it.

The benefits are well documented, but ultimately, a LAMP stack is a tried-and-true method for delivering websites.

Beyond that, I utilize the standard HTML5/CSS3/Javascript for my work. I used to avoid Javascript unless it was absolutely critical, but we’re at a day and age now where I no longer have to worry about whether people have JS disabled (or even have a browser that supports modern JS).. Which brings me to my next point.

What tech stack should I use?

I’m actually changing things up a bit. While I am planning on sticking with my current traditional LAMP for back-end work, I’m shifting my front-end work more.

Since learning React, I’ve come to embrace a number of front-end solutions. SASS, Babel and Webpack are now all part of my toolkit, plus a number of other great plugins that make my life easier when coding.

SASS is just fantastic because it allows me to be so much more efficient in my CSS, as I discussed previously. Variables, imports and a variety of great things make this CSS pre-processor part of my “must have” toolkit now.

Babel has allowed me to stop worrying about compatibility, so I can write ES6/7/8/9, and have my code prepared for maximum compatibility after the fact. I love having access to const and let, promises, and more that come with recent versions of Javascript.

Ultimately, though, I’d be hard-pressed to consider any of it without Webpack. Sure, there are other tools out there, but Webpack (once configured – and yeah, it’s a pain to configure) is spectacular for my dev environment. I’ve got boilerplates set up for both React and standard web projects, and I can do much cooler stuff in a much more organized fashion because of it.

How to code web art

With all the above noted, I have a decision to make. What libraries/frameworks do I utilize? Do I focus more on CSS animation, or Javascript? Do I utilize HTML5’s canvas, SVG elements, or what?

I’ve got a few considerations in mind. Part of me wants to finally make use of Three.js, a SPECTACULAR WebGL library for rendering 3d stuff. The biggest problems with Three.js are 2-fold; one, I don’t feel like it’s very well documented, so I’ll be investing more time trying things and fixing what breaks than actually building. Two, it is pretty resource-intensive, so people on slower mobile devices may need to be served an alternate version of the site.

Another part of me is considering building utilizing the tried-and-true methods I’ve used before; JQuery is a standard as much as anything else, and it just plain works. I’ve already evaluated some JQuery plugins that would be useful, so we can go that route, too.

Finally, I also have to consider the theme backend code. While I’ve used Oxygen for a number of website builds, I’m actually thinking about skipping it and building a theme from scratch. It has been a long while since I’ve done so, and I could avoid some headaches by going that route. Plus, I can utilize my dev environment fully with that (SCSS, Babel, Webpack, etc).

Or.. Do I finally bite the bullet and go headless? Building a React-based front end served via Node and querying content via the WordPress API could be cool. A little over-engineered, but still cool.

So, that’s where we are at. Keep checking back for more on the redesign process.