Skip to content

it just works

If you visit this website, it’s likely it won’t look or act any differently right now. Maybe you’ll see a new dark mode! I spent the last two weeks moving to a new WordPress theme, one which I’d call a younger cousin to the previous theme I used. It has less under the hood, uses slightly different syntax, but the ideals behind some of the tech are similar.

Here are some small updates I made in the transition:

  • I added a new CSS function called light-dark(), pretty much the result of Dave Rupert’s experiment. You know what this unlocked for me? I was able to remove almost all declarations of color and background-color from the code, outside of a few instances. I couldn’t believe how it simplifies light and dark mode code.
  • I was using CSS mixins to drive fluid sizing, borrowed from this Codepen. This was a Scss based mixin that gave the site fluid responsive superpowers, added around 2017. Since that time, utopia.fyi is now a much easier, more efficient way to provide fluidity. And, I don’t even have to use Scss for this.
  • All variables are now CSS custom properties, aka CSS variables. I love removing abstractions!
  • I have a new plugin called Lite Video Embed, which now won’t require YouTube to load everything until the visitor interacts with the video. Performance win!
  • I’m now using another new CSS function called color-mix(), and it’s pretty badass how it just works. This is another Scss abstraction I didn’t need to use.
  • Switching themes means I transitioned from using Webpack to using Vite. It’s such a refreshing difference!
    • One major difference that I noticed immediately is the ability to run the vite server environment, and allow it to hijack the development environment for reloading.
    • In other words, I don’t need to have two environments to see live reloads anymore. If I’m using https://example.local/ to see WordPress work locally, Vite will use the same environment for live reloading. No need to switch to a different URL like https://localhost:3000! Truly, I’ve been annoyed by this for more than a decade about Webpack! No more!
  • With all of this, I changed every CSS partial from .scss to .css. Since CSS now supports nesting natively, Sass and Scss aren’t necessary for my personal work.
    • Now, that said, this theme does include PostCSS and Vite is still doing some kind of transpiling. I need to figure out how to turn off transpiling and allow Vite to just concatenate all CSS partials into the global CSS file, as well as generate a critical CSS file that I can insert into the <head> for even better performance. UPDATE: fixed transpiling from happening!

The fact that this new theme has likely half the dependencies that it used to is a big win for me. If I walk away from the theme files and come back in some time, it seems more likely that I won’t encounter legacy issues like I did with Webpack. In fact, here’s what the dependencies look like right now:

asuh.com development package dependences in May 2024 from package.json

I think I might clone the original theme at some point and update it to either remove whatever possible above as well as add back in some of the changes I made for this theme. So my Github might have one more repository before too long!

The takeaway from this work, at least for right now, is that I really enjoy working with Vite. It’s such a cool builder and feels so much easier than anything else I’ve used. I needed this kind of enjoyment with tech since my career has been such a rollercoaster of stress!

Oh, and I hope this automatically syndicates to Mastodon and Bluesky. So that’s another test of posting this.

1 reply

Vite with WordPress theme

I’ve been on a digital journey this week to prepare for updating my personal site. I haven’t truly updated my site’s theme in so many years that it’s broken to use as is.

So, I decided to search for a similar type of theme, which is Roots Sage theme. When I chose it, it was a fascinating alternative to the type of WordPress themes of the late 2010s. The file organization and progressive nature of tooling and packages was quite attractive to developer me. This came as the expense of letting it sit there and technology changing, with multiple upgrades on my personal machines to disrupt the ability to use the same tooling and tech stack.

That leads me to this week’s priority. Knowing how convoluted Webpack is, it’s a complicated bundler. There are so many additional packages that’ll enhance the experience but add additional overhead for upkeep.

Sage also moved on to a new major version and that team refactored the theme enough that it has at least one or two external dependencies from new repositories. I tried to work with this new architecture a couple of years ago or so and it was just too much.

Knowing I didn’t want to continue with a theme using Webpack, I searched for non-Gutenberg centric themes that includes a newer bundler called Vite. Why Vite and not others like Parcel? Honestly, because Vite seems to have better momentum. And I was able to find plenty of themes using it, most of which are not useful to me.

One stands out and I believe it’s going to work. I can’t remember exactly how I found this theme, and it’s buried in a develop branch, but so far this Footmate Pro theme is working pretty well. There are enough similarities between the Sage theme and this theme that I’m intending a 1:1 transition where possible.

I had a couple of days of issues trying to copy some of the old template file code into this new theme, primarily because using a newer version of Laravel meant new functions are sometimes needed for templates. I temporarily stopped and tried working with a different Vite based WordPress theme, but it was just too outdated to work. I returned to this theme, reviewed Sage’s newest version to review newer Laravel code updates, and applied a newer function that finally fixed the issue. So I believe things shouldn’t be as difficult.

One of the amazing things this theme offers with Vite is the ability to do live page reloading using the same local URL, rather than an additional localhost address. This means that saving an HTML, CSS, or JS file with updated code will immediately update your site at https://example.local rather than needing to use http://localhost:3000. This is a long standing pain point we’ve had using reloading tools!

If this truly works out, I’m going to attempt to keep abstracts to a minimum, and continue to include tools for an indieweb presence. PHP and Laravel will provide server side work, but most client-side code will be plain ‘ole HTML, CSS, and JS.

Beyond this, we’ll see where WordPress fits into everything. I’m evaluating other tooling like Astro and 11ty. I’m ready for a future proof technology that won’t pose huge issues if I have to pause for another amount of time.

fluid design utopia

Bookmarked

As a design focused developer, there is so much value both designers and developers can get out of this video from @trys.

The reality is that I have yet to be on a team which can retroactively apply a nice fluid responsive design.

It seems like so many visual designers are focused on easy-scaling numbers like the 8 point grid system.

Trys Mudford – Fluid responsive design – the Utopian futureTrys Mudford – Fluid responsive design – the Utopian future
1 reply

new syndications

This isn’t spam, I promise, but I’m spending a little time re-setting up some indieweb services to that I can syndicate new posts to services automatically. But, thanks for reading this message!

managing retrospective

I was just updating my tech i know and tech i use pages. It strikes me how far I have come since I started those pages and a lot of the i don’t know… section now belongs in the i’m learning section.

Also, my interests in web development and web design have matured. Today, I want my focuses to be on the design side of development, still very much the front-end, creating design systems, pattern libraries, and component libraries as well as supporting user interfaces for the web. This is a huge rabbit hole of technology that bleeds into everything from performance, accessibility, web components, libraries, frameworks, and so much more.

With all of this in my focus, where do I stand today?

best of both worlds

I’ve worn a lot of hats in the last decade of my career, most recently the hat of an engineering manager. There’s a point where you go from being a senior developer, who’s been in the throw of code and development for much of his or her career, and decide on how to move forward either with more contributor roles or with management roles. In fact, engineering management is a parallel track to engineering or development, it’s helpful to lead by example, when there’s time and availability.

As a manager, my strengths are in the collaboration and partnerships that are needed and required to move forward. I bring a lot of passion into the positions I take on various projects or ideas. In fact, I can be so eager to move an idea forward and the controlled chaos that ensues. As a product strategist, there’s so much potential to look for optimizations and efficiencies to get things done. In my last year of management work alone, I’ve come a long way to move the needle in the right direction, looking for compromise and yet pushing for effective outcomes.

I find it satisfying to put in any time I can on both coding and managing where it makes sense, where my abilities best serve the team. As a manager, I make a conscious effort to not to move the needle for a project. It’s my number one job to enable and support the lead developer/engineer to make these moves.

we are all designers

One of the main takeaways from the various projects I was involved with the last few years of my career is that the software development life cycle (SDLC) that we all know is pretty out of date. In so many companies, There’s still this mentality of waterfall models, hand offs, where all the concerns and ownerships are still so isolated from each other.

What I never really understood, but I feel is crystal clear today, is we’re all involved in the design phase of the SDLC. Our primary concern, regardless of content, components, code, copy, creations (how many Cs can you think of? :) is the design of everything. In the spirit of my interests at the beginning of this writing, we should all be talking to each other from the very beginning. Content people are writing primarily for what they know, but if they could talk about the user journeys from a design and development perspective, in addition to content management or SEO, it might unlock new potentials for what the most effective content is.

As a designer, we should also have the ownership to create in the medium we publish. This means relieving ourselves from leaning on a lot of abstract tools. What if we were all able to start and finish a project inside of the same, exact tool? Just as our desktops should get out of our ways to create, so should our tools get out of our ways to produce.

Each stakeholder, each expert in their domain, should have the autonomy to do their job. We all need a sense of ownership and agency in the work we produce. At this point, however, we shouldn’t be isolated or siloed in how we move together. You work with a team, move as a team, and succeed as a team.

the ideal

If there was anything that could feel the most relevant to my career, it would be to improve the SDLC to focus everything around the design experience, to congregate teams to use the same product from end-to-end of the cycle, and to heavily focus on systems. Web teams should put as much energy and focus into design systems as possible, encircling this idea with all the libraries and guides needed to move a product cycle forward.

The most efficient path is the one where all the stakeholders are included in the same suite of software and products to deliver results efficiently and effectively. We shouldn’t be waiting on each group to completely finish their work; how many times have I waited first on content managers, THEN on designers, THEN on project managers, etc, etc., before being able to move on code. So much wasted time and lots of problems delivered to the developers! Hand offs were kind of effective in the years past, but today’s agile environment needs more collaboration and teamwork.

1 reply

typescript, graphql and wordpress

I took a few days to reacquaint myself with GraphQL the last few days. It’s hugely popular with developers as a way to efficiently work with data, providing an efficient way to get a specific set of data to use in a code base. It’s compelling once you understand how to use it.

So I went ahead and installed WPGraphQL, on a WordPress instance I have, to put my feet on the pedals and begin riding. For a few months, I was contemplating creating a custom-built look to a website, and I also wanted to try out using Astro. This was a good opportunity.

It’s trivial to set Astro up, running:

npm create astro@latest

It asks if I want to use TypeScript, so sure, why not. I’m familiar with it, this’ll give me more experience to use it, all it’ll do is take up more time if it’s not easy to put together.

Okay, so then I begin setting up a very simple couple of template files in Astro.

+ src
  + data
    </> wordpress.ts # This is where I fetch the data
  + layouts
    </> default.ts # This is the baseline application wrapper
  + pages
    + blog
      </> [slug].astro # Blog post
    </> index.astro # Blog roll

Getting to this point wasn’t too difficult, just following the steps and updating to my project. The head scratcher comes from the actual TypeScript that’s required.

Here’s the blog roll code.

---
import	Layout from '../layouts/default.astro';
import { wpquery } from '../data/wordpress';

const data = await wpquery({
	query: `
		query LoadAllPostsExcerpt {
			posts {
				nodes {
					title
					slug
					excerpt
				}
			}
		}
	`,
});
---

<layout title="Test">
	<h1>Posts</h1>

	{
		data.posts.nodes.map((post: any) => {
			return (
				<article class="post-preview">
					<h2>
						<a href={`/blog/${post.slug}`}>{post.title}</a>
					</h2>
					<fragment set:html={post.excerpt}></fragment>
					<a href={`/blog/${post.slug}`}>read post →</a>
				</article>
			)
		}
	)}
</layout>

Here’s the focus of this code: data.posts.nodes.map((post: any) => {...}.

There’s nothing simple in WordPress about declaring a type on various data, like post: any. In my code, I’ve resorted to the data type any so many times it becomes pointless to continue using TypeScript.

So I have looked all over for a solution. It exists, of course, but from what I can see, it’d look something like post: Post after having to add another abstraction to define what is Post. Tedious and silly, if you ask me.

Already using TypeScript is an abstraction, one I’m finding to not be so useful.

With the above said, let me end this with a general headless WordPress confusion. The future of WordPress, clearly, is Gutenberg. However, according to the author of WPGraphQL,

“[…] much of WordPress was built with decoupling in mind, the WP REST API and Gutenberg were not.”

In fact, it’s worse than this for anyone using modern WordPress using Gutenberg.

“Gutenberg didn’t have a server-side registry for blocks. At this time, all blocks in Gutenberg were fully registered in JavaScript, which is not executed or understood by the WordPress server.

This means that unlike Post Types, Taxonomies, Meta, Sidebars, Settings, and other constructs that make up WordPress, Gutenberg blocks don’t adhere to any type of contract with the WordPress server.

This means that the WordPress server knows nothing about blocks. There are no agreements between Gutenberg blocks and other systems in WordPress, or systems trying to interact with WordPress via APIs.

Blocks were practically non-existent as far as the application layer of WordPress was concerned.”

So this means, if I have decided that Block Themes and Full-Site Editing is the future and I want to support it, and I also want to go headless, I’m in for a world of pain.

Are developers truly going to continue supporting or going with WordPress unless/until they fully get on board with Block Themes? I don’t think I can see myself continue with WordPress as it’s moving forward. With its forced use of React for Gutenberg, to the weird ways you have to set data, attributes, styles, or other options, this looks like a complete lock-in to a specific way of building websites. Maybe this is great for some, but I am having major doubts I’ll stick this out for much longer.

1 reply

jsdocs > typescript?

I might not be well versed in TypeScript, but I really like this article that goes into using JSDoc as a great alternative to keeping JS but defining types. It provides a lot of easy to understand example and context.

https://dev.to/what1s1ove/typescript-might-not-be-your-god-case-study-of-migration-from-ts-to-jsdoc-o99

1 reply

post-WordPress?

I don’t know if WordPress’ direction with Gutenberg really serves my interests. In fact, what does a world beyond WordPress look like now for this site?

My last system move was from MoveableType to WordPress in 2008. MoveableType was great to get used to CMSes, and WordPress was a huge improvement b/c of the growing community.

In 2024, Gutenberg is the future of WordPress. I’m not enthusiastic about it. Now that HTML, CSS, and JS are making regular strides with first-class APIs and modern upgrades like native Web Components, I’m kind of ready go back to something more native. The thought of development like I did back in the early 2000s is appealing, but with modern content management.

Maybe headless? Maybe all static generated? I don’t know. I’m exploring headless now b/c why not.

I’ll be on WordPress for a while, no doubt, but can I hit 2025 with something new here? or at least different? Who knows. Life is busy!

1 reply

firefox-wishlist-2024

Dear @mozilla, here’s my 2024 Christmas wishes for .

@Scope
View Transitions
text-wrap: pretty
JPEG XL
colorspace
CSS Relative colors
Declarative Shadow DOM
CSS Container Style Queries
CSS widows & orphans
Passkeys

1 reply

scss is just css now

Okay geeks, it’s almost January 2024 and, finally, Scss is now CSS.

Okay, not all of it, but primarily the biggest feature everyone uses.

Nesting.

That’s what we’re all using Scss for, right?

Right? Don’t lie…

Okay, let’s say we ditch Scss, as you should. Seriously, you should.

Do we… keep splitting CSS into lots of files like we did Sass?

Think about it, we take out the abstractions of Sass rules, we ditch the Sass build scripts, right?

Are we delivering lots of files now?

2 replies