2025-01-17 05:54:00
I watch, I think, I write: the latest in a string of thoughts on what’s been happenin’.
It’s been about a year since the previous entry in this series of observations on things going on at the time. While that’s hardly a requirement for another — ah, well, let’s just do this, shall we?
The one-man development band behind one of my long-time app faves, the unbelievably full-featured MailMate email app for macOS, has announced a move to the subscription model. Previously, MailMate was a one-time purchase of about $50 but came with encouragement to donate to the project as a patron, particularly if the app was in play within a business environment. Starting with the currently-in-beta v.2.0, this changes to a $40/year subscription (i.e., $10 every three months). One interesting aspect is that a non-business user can still download and use MailMate without paying for it but, after a while, it will start to put identifying text in headers that make clear one is being a freeloader; those who’ve seen online videos that are “watermarked” with logos of unlicensed video-editing apps will get the idea. Business users are required to get the necessary number of per-user subscriptions, although the enforcement mechanism will still be the “header shaming,” if you will. Those MailMate users who bought their one-time-purchase licenses years ago are grandfathered until as late as July 1, 2025; after the applicable date, each such user must either drop MailMate or avoid the “header shaming” by starting on the subscription plan.
It’s increasingly likely that most web browsers will be affected by the ongoing battle between the U.S. Department of Justice and Google over the latter’s perceived search monopoly, but it’ll be later this year before the planned ruling that could clarify what the effects will be. A November, 2024, DoJ filing pushed for Google to divest itself of the Chrome browser. However, at this time, it’s unclear whether that would also require Google to cease being part of the Chromium project on which not only Chrome but also Microsoft Edge, Brave, Opera, and numerous other browsers depend. As one observer put it:
If [the DoJ is] is really just saying, ‘Give up Chrome,’ that would be very weird because Google would still control all the underlying technology and they could just tank anyone who would try to do stuff with it, including anyone who ends up owning Chrome.
Given that Google made well over ninety percent of 2024’s code commitments to the Chromium project — and that many other key projects, such as Electron, are Chromium-based — it will be extremely important how Chromium itself falls out from all this. And then there are Google’s counter-proposal and the creation of Supporters of Chromium-based Browsers, each of which is a completely different story.
One other aspect of the DoJ/Google snarl is that Google could be forced to stop paying other browser-makers to include Google as their default search engines. If so, the organization behind the already ailing Firefox, which is the last major cross-platform browser not based on Chromium, would lose the vast majority of its annual funding. (And there are other, lesser-known browsers which depend on Firefox’s Gecko engine. I’d guess they also would go down the drain soon thereafter, no matter how industrious or high-minded their developers might be.) Given how low Firefox’s market share currently sits, one can imagine the DoJ wouldn’t spend much time worrying about it.
Whether one definitely does get more cynical as one ages, I can’t say. In my own case, however, I increasingly realize and reluctantly accept that most of my choices in life are from among products and services controlled by really nasty people and/or entities, and my only true alternative would be to go totally off the grid à la Ted Kaczynski — which I’m not going to do. If that makes me a lesser human being, well, then, it does. In the same vein, I did find considerable common ground with Kev Quirk’s blog post, “On Virtue Signalling.”1
My writing app marks signalling as a typo. Of course, my writing app doesn’t know that Quirk is using the UK spelling. ↩︎
2024-12-09 00:33:00
The Hugo team releases intriguing nuggets about the next full version.
If you typically don’t follow the social media postings from the team behind the Hugo static site generator, you might have missed yesterday’s highly interesting disclosures about the next full version of Hugo.
In case you didn’t see these posts, here you go:
Coming in next Hugo: Site wide JavaScript code splitting, build JavaScript/TypeScript/JSX/TSX in page bundles (see video), much improved source maps support, and more:
Also new and visible in the the video: CSS import/bundling, dataurl etc. loading of imported PNGs.
As of this writing, the latest major release of Hugo is v.0.139.0 (2024-11-18). There is no fixed cadence for Hugo full releases; but, given that the Hugo team is now willing to share these intriguing nuggets about what I presume will be v.0.140.0, one could guess that we won’t have to wait long to get our digital hands on the promised goodies in this next version.
Same-day update: After I announced this post on Mastodon and Bluesky, I received the following reply on the latter platform. You may find it of interest.
Not that it matters. Because the Hugo team has been stuck in beta for years and refuses to follow semantic versioning, any upgrade is potentially breaking in very major ways. Most folks I know never upgrade as a result.
— Chris Ferdinandi (@cferdinandi.bsky.social) 2024-12-08T16:53:56.242Z
2024-11-19 06:15:00
If you upgrade to Dart Sass 1.77.7+, you may need to move around some nested items in your styling.
In recent months, I’ve settled on keeping this Hugo-based website’s styling on a combination of vanilla CSS and, in production only, PostCSS. However, I still have code that allows me to use Sass if desired; so, out of curiosity I thought I’d see how it’s doing with newer versions of Dart Sass, to which I keep my repo updated. Turned out I had to make a number of changes, specifically due to a fairly recent change in Dart Sass.
I had missed the fact that, as of Dart Sass v.1.77.7 (the release of which apparently dates from sometime between 2024-06-11 and 2024-07-11), one has to be more careful about the placement of nested items. The following worked fine prior to that version:
.example {
color: red;
a {
font-weight: bold;
}
font-weight: normal;
}However, since then, such SCSS would trigger a deprecation warning and, in the case of using Embedded Dart Sass with Hugo, cause Hugo to crash. The emitted warnings pointed me to the Sass page “Breaking Change: Mixed Declarations,” which explained why the newer Sass versions no longer accept this styling and, borrowing from the example above, require it to be like this:
.example {
color: red;
a {
font-weight: bold;
}
& {
font-weight: normal;
}
}In my own case, I had various media queries scattered about, and fixing them proved to be slightly more challenging. Here is a simplified version of such SCSS, which was fine in the older versions but not post-v.1.77.7:
.example {
font-family: sans-serif;
@media (min-width: 720px) {
font-family: serif;
}
color: #000;
}. . . and its newly required replacement:
.example {
font-family: sans-serif;
color: #000;
@media (min-width: 720px) {
font-family: serif;
}
}While I could also have gone the & {} route with the color statement, as suggested by that Sass deprecation documentation, my actual affected SCSS in most cases was sufficiently snarled up that I found it easier just to move media queries to the end of each declaration. I was fortunate that this sort of fix, although I had to make it in quite a few files (since I split up my styling for organization’s sake), apparently solved all my violations of the newer Sass version.
Thus, if you’re a Hugo/Sass user who hasn’t upgraded Embedded Dart Sass recently, you might want to make time for testing your existing SCSS with a post-v.1.77.7 version.
2024-11-14 02:45:00
While it doesn’t do static embeds, this shortcode gives you an easy way to show content from an increasingly popular social network.
The Bluesky social media network, initially hampered by a wait-for-your-invite policy while capacity was being enhanced, recently has hit a growth spurt. Bluesky is now getting increasing attention from not only individual users but also a variety of larger entities, including a number of major sites which have been leaving Twitter/X for hoped-to-be-greener pastures. This post gives you a simple Hugo shortcode for embedding Bluesky posts in your content.
I shamelessly based this shortcode, called bluesky, on Hugo’s existing twitter shortcode for embedding Twitter/X content through the oEmbed protocol, which Bluesky also uses. Please note:
twitter. This document explains what Bluesky’s oEmbed endpoint recognizes.bluesky shortcodeThe bluesky shortcode takes only one parameter: link for the URL of the Bluesky post you want to embed. Here is an example of the bluesky shortcode in use2:
{{< bluesky link="https://bsky.app/profile/bsky.app/post/3latotljnec2h" >}}. . . which produces the following:
15M people on Bluesky!!! 💫 The Verge beat us to our own announcement — that's the beauty of an open network with public stats!
— Bluesky (@bsky.app) 2024-11-13T15:43:47.612Z
bluesky.html
{{- $link := .Get "link" -}}
{{- $query := querify "url" $link -}}
{{- $request := printf "https://embed.bsky.app/oembed?%s" $query -}}
{{- $jsonOembed := resources.GetRemote $request -}}
{{- $jsonOembed = $jsonOembed | transform.Unmarshal -}}
{{- $jsonOHTML := $jsonOembed.html -}}
{{- $jsonOHTML | safeHTML -}}If the embed appears without JavaScript running, you’ll see a bare-bones, text-only representation which, actually, is very similar to how the Hugo twitter shortcode handles tweets if you have Hugo’s privacy settings set appropriately — and, in fact, that may be preferable to those who are likely to disable JavaScript in their browsers. ↩︎
If you happen upon this site’s repo out of curiosity and check out this post’s Markdown file, you’ll notice that this example’s curly-bracketed boundaries also have wrapping /* and */, respectively. That’s because, otherwise, Hugo sees it as real code, not just a representation of it, and acts accordingly — in this case, once again displaying the image. See “Highlight Hugo/GO Template Code” in the Hugo documentation. ↩︎
2024-10-03 00:07:00
The latest major version of the best JS-based SSG brings quite a few enhancements.
Version 3.0 of Eleventy, which I’ve long considered the best JavaScript-based static site generator (SSG), has emerged from testing. Eleventy creator Zach Leatherman issued the v.3.0 release yesterday. This new major version comes with a lot to offer, regardless of whether one’s site is already on Eleventy, but there are things for which to watch out as well.
I haven’t tried Eleventy 3.0 since its alpha-test period, so you’re much more likely to get good information about this new version from other bloggers who are using it actively. Also, there’s no point in my reiterating everything in Leatherman’s release announcement, so let’s just say that v.3.0’s most notable raison d’être is adding support for ES Modules (ESM) while retaining legacy support for CommonJS. As the JS world shifts more and more toward ESM for the countless packages in its orbit, this long-awaited enhancement removes what had been a drawback for using Eleventy with many items. Of course, v.3.0 has many other goodies (and, yes, breaking changes for sites using older Eleventy versions), so be sure to read — and heed — the full release announcement.
After bouncing around over the last couple of years between self-supported status and corporate sponsorships that turned out to be all too temporary, the Eleventy project recently became part of Font Awesome. It’s a transition which, one hopes, will firmly bolster the long-term stability of this justly popular SSG.
2024-09-15 01:54:00
If you count your JavaScript load, be aware of this recent change to the 1Password browser extension.
In much the same way as I previously decided to advise of a Bitwarden script that could inflate your JavaScript load, I’m passing along some word of what I assume is a recent change to the 1Password browser extension.
Here’s what I posted on social media earlier about this:
The @1password browser extension adds `injected.js` (674 Kb) to each page.
If you use this extension and are trying to measure your pages’ download size, be sure to filter out this script by name in the Inspector view of your preferred browser **or** just use Inspector within a private/“incognito” tab/window.
#WebDev #WebDevTips #HTML #JS #JavaScript #1Password #Browser
