DEV Community: KyleFontenot

Astro is awesome

KyleFontenot — Fri, 05 Aug 2022 02:18:45 +0000

Astro is my daily driver for creating websites in my freelance web development business, and I wanted to highlight the tool for anyone unfamiliar, and also to get readers acquainted easily to the code. I will have a second blog post on the usage: here.

Overview

Astro is a really lovely, well-thought-out framework for creating websites with little to no Javascript client-side. It uses Vite under the hood, with all the yummy features like CSS Modules, easy PostCSS, static route generation, and built-in SCSS. Astro is primarily a static-site framework because it builds everything into static assets to be served. The Astro team is leveraging a lot of SSR capabilities to not only optimize page load speeds but for using a full SSR implementation (in beta as of writing this).

It enables an "islands" approach to each component; each component created by default doesn't have any Javascript attached to it, forcing the developer to opt-in each component that needs some client-side code. When developers opt-in for JS, they have their own option for using a JS framework like React, Vue, Svelte, SolidJS, or just Vanilla with just a simple renderer installation with a CLI command like: astro add react.

Quick Background

I took up Astro the instant I discovered and read what makes it unique, because it fit into my development really well. Gatsby initially fulfilled this role of static-site generation for my small business clients, but discovering Svelte and SolidJS broke the React paradigm for me. By offering all modern capabilities of a major framework such as Gatsby (with the exception of the beta SSR), but with barely any runtime JS and a ton of flexibility. SolidJS is essentially what drove me to Astro, as it was one of the only ways of creating a MPA using SolidJS (at the time).

Page Load Comparison To NextJS

Astro mentions its benefits on its documentation site, but it's better to see a direct example for the statistics. I created the exact same basic website using NextJS and Astro. Here is the example website with each corresponding Lighthouse score.

For the purposes of consistency, I used the Image component per designated framework as an obstacle for page load, a simple external SCSS stylesheet import, and the SolidJS renderer installed for Astro. With the SolidJS renderer in Astro, anyone can literally do anything React is able to do (there's always vanilla, but just for React-fans).
For consistency, both websites are created:

From templates taken directly from each framework's official documentation website.
With Lighthouse audits executed on a Chrome private window to remove possiblities of extensions interacting.
With a cleared cache every test.
Using CSS Modules and Sass.

Out of the box, it's a bit surprising that such a simple website with only semantic HTML elements, and a dynamically presented image can show such a stark difference with frameworks (and let's not mention how we have to clarify a _document.js file for lang="en" for NextJS). With a previous project of mine, I used NextJS because it simply scored better in Lighthouse, being a more mature framework. But just as Astro surmises on their documentation site, it's all about content. And clearly, Google is heading in the same direction.

That's crazy.

The circled scores above are the most pivotal stats: Astro scoring and average ascore of 98ms, versus NextJS scoring values between 600 and 1000ms. Even viewing the amount of resources used for such a basic site is pretty shocking. Two big factors affecting these are React itself in the bundle, but perhaps Vite as well. Webpack looks remarkably sluggish compared to newer HMR bundlers. And speaking of bundlers, this Astro site would probably take around 6 seconds to build, costing the developers and clients even less for hosting.

Routing Patterns

Astro, like many modern frameworks nowadays, have a static file route option for easily creating pages. In the /src/pages/ folder, each .astro and .md file is automatically created into a page. For anyone familiar with NextJS's approach to this, it is exactly the same, particularly with dynamic routing using syntax like [blogPost].astro.

One perspective Astro takes, is clarifying layouts for use of pages. It's essentially just parent components that receive children components, and typically span or inherit the html, and head tags. NextJS's equivalent is a very special and particular approach by using proprietary <Head/> and _document.js tools to optimize its page load. Astro proves, if you keep it simple with great tools, these types of workarounds aren't necessary. In Astro, keep your <head> tags as they should be, and nest your components like you normally would.

Styling

CSS modules are natively supported in Astro, and are a great option for building, but Astro also has a built-in style method that assesses CSS from within a style tag inside the Astro component it belongs to. This style below is only applied to this specific component. There is a method of making this global if you need to though. Here's the example:

<button class="special">Button</button>
<style>
  .special {
    outline: 5px solid blue;
  }
</style>

Ease

Astro's team has offered really handy CLI tools for perpetuating their integrations idea of Astro's. Integrations are pretty much the same as any other frameworks' "plugin" system, with just a yarn astro ___ command. The integrations make it extremely easy to install Tailwind, SolidJS, native SSR tools, and more. I see this as very similar to Gatsby's plugin system, especially when/if the ecosystem expands in the future.

Misc. Built-In Tools

Markdown
- Out of the box, Astro natively supports Markdown, with even MDX-like capabilities for placing in custom components.
RSS support
A flexible Code component with tons of language support
Powerful directive configurations for finely splitting code.

Check out the official Astro docs for more!

I'm planning on making an Astro primer article next for to make it easy for someone to jump in!

Bionic Reading and "mini-library" for it

KyleFontenot — Fri, 08 Jul 2022 00:12:23 +0000

Bionic reading is a really interesting idea of improving readability –especially with dyslexic readers– by emphasizing the beginning letter(s) of each word of a paragraph.

It's a fascinating concept that can be used for many reading uses, and it seems like something that many people may prefer. The official website advertises an official API and a few other tools for enabling and mutating blocks of text into a "bionic"-style, but I wanted to explore implementing something like this simply with Javascript. I searched NPM for something similar, but with no solid results.

So I made a mini library for myself.

Obstacles

My qualifications for it was to create a drop and go function or class like most JS libraries that would affect all paragraphs(or specified selector or class) of text on the HTML document. There's quite a few obstacles to consider in this particular idea:

How would I be able to isolate only the first letters of each word while still retaining the inline, static dimensions of the original paragraph?
How would I stylize a way for the emphasized letters to be exactly the same font, almost like an outline, that is 1 pixel at most wider than the original font?
Do I implement this with CSS or some way with Javascript that will perfectly outline a font shape?
Are pseudo elements an option?
If I were to use CSS, what would be the best property to use?
- text-shadow?
- font-weight?
- transform: translate()?
How would web crawlers understand?

My Solution

I came to my solution that uses CSS's text-shadow and the Shadow DOM to create a distinction between the original light DOM content and the specifically styled bionic node attached as a child. I chose text-shadow as a default because it is the most likely to not be used and changed externally (since the shadow DOM is open for flexibility)., and becausetext-shadow also keeps the exact fidelity of the font used. Also text-shadow doesn't rely on the availability of a bolder font weight loaded.

This would still show indexable to web crawlers, but because of the requirement on keeping the added outline exactly the same as the computed font, it would be much harder, if not impossible to add in a shape without adding an HTML node. The shadow DOM at least creates the distinction, readable to devs, while still unaffecting the "light DOM" node's indexability.

class Bionic extends HTMLParagraphElement {
  constructor(elem){
    super();
    const root = document.createElement('bionic-reading');
    const shadow = root.attachShadow({mode: 'open'});
    const paragraph = document.createElement('bionic-reading');

    const elemStyle = window.getComputedStyle(elem)
    paragraph.style = elemStyle;
    paragraph.innerHTML = elem.innerHTML;

    root.classList.add('bionic');
    paragraph.classList.add('bionic');
    const style = document.createElement('style');
    style.textContent = `
      .bionic {
        position: absolute;
        top: 0;
        left: 0;
        width: 100%;
        height: 100%;
      }
    `
    elem.style.position = "relative"
    root.style.color = "transparent";
    paragraph.style.margin = "0";

    paragraph.innerHTML = paragraph.innerHTML.split(' ').map(word => {
      return `<span style="text-shadow:-2px 0 0 ${elemStyle.color};">${word[0]}</span>` + word.substring(1)
    }).join(' ')
    shadow.appendChild(style)
    shadow.appendChild(paragraph)
    this.result = root
  }
}

function bionic(selector = 'p'){
  customElements.define('bionic-reading', Bionic, { extends: selector });
  document.querySelectorAll(selector).forEach(elem => {
    let bionic = new Bionic(elem);
    elem.parentNode.insertBefore(bionic.result, elem.nextSibling);
    elem.appendChild(bionic.result);
  })
}

bionic()

Essentially, it creates a child Shadow DOM, adds in an absolutely positioned clone of the light DOM node, and then injects a span that creates a text-shadow for every first letter of each word. Styles from the light DOM are inherited for the sake of keeping text-based styles like letter-spacing and color consist so that the emphasized letters line up perfectly.
It requires the light DOM node to be relatively positioned (which shouldn't make a difference from static in how we normally use semantic paragraphs anyways).

If I expand this tool potentially into an NPM package, I can easily allow for a few option parameters such as the property value that changes the CSS property used ('text-shadow' | 'transform' | 'filter' | font-weight ), heaviness, letter padding, HTML and/or class selector.

Let me know what you think!

My Vim config opinions and suggestions

KyleFontenot — Mon, 04 Jul 2022 16:55:28 +0000

Vim is awesome. And config files are half the fun!

For about two years, I've known about Vim and it's notoriety in both the developer community and the Linux community for being quicker, more expressive, and even a more native way of manipulating text. It was one of those things that I admired, knowing that once I took the dive, that I would never look back.
The possibilities are endless when it comes to Vim's and Neovim's config files, especially when accounting for the huge world of plugins available out there.
For a brief history, Wikipedia's entries on Vi and Vim show a good glance on the background of these programs: Vim. Vim was officially established in November 1991, so it's only a year younger than I! It's parent program it was derived from, Vi, was established near 1978! Besides it's historical significance, Vim has been automatically included in all Unix machines and will continue to be in the future, making it one of the most prevalent programs ever.

I wanted to share my Vim config and opinions on a setup to maybe persuade the common pillars of usage with Vim. I host in on a Github gist at the moment of this writing, and can be found here: my init.vim on GitHub

The characters: 0 and -

In Vim, 0 (the key for zero next to 9) is a very commonly used key for moving to the beginning of the line of your cursor. Inversely, the character $ is the key to move to the end of the line of your cursor. These are super handy to use, but why is the key to move rightward six keys to the left of the key to move the left most?

4$This moves to the right-most. Why? 5% 6^ 7& 8* 9( 0)This moves to the left-most. -_

So there must be a use for the character `-`, the key just adjacent to the right of `0` right? Well, not really. I can't seem to find anything of use on this key, but there must be reason for this. Perhaps it is one of the many small nuances in Vim that seem funky to modern keyboards because of the way keyboards have changed since 1978. One example of this nuance is why the directional movement keys are h, j, k, and l instead of j, k, l, and ;.

I can't seem to find anything except for tradition for why the end-of-line command shouldn't be the - key. Could be becuase of a change in keyboard layout historically as well. But to update your Vim to modern keyboards,tTry it, and never look back.

Map $ to - for obvious left-orientation and ease of finger placement

The config line would look something as simple as bellow. We use map instead of noremap because we want the - key to persistent into other commands that would involve $

map $ -

jj and/or jk

Now this is an extremely common configuration amongst Vim users. For anyone unfamiliar with jj or jk and know at least some Vim; mapping jj and jk to Escape allows the typer to exit insert mode into normal mode without having to leave the homekeys. This is essential for me, especially because sometimes I use my 2017 Macbook Pro that has a touchbar. Having zero physical feedback for the escape key is worse than scratching a chalkboard. Scratching chalkboards got nothin' on me.

What makes jj and jk usable in insert mode is because they aren't an occuring combination of letters in the english language. Well, in my normal flow when focusing on keyboard only, I often do a double h or a double k for when my fingers aren't aligned to the home row. So I was started pondering why wouldn't someone add in these binds as well? Unless you're typing in the word 'bukkake'... you should be fine.

inoremap <silent> hh <Esc>
inoremap <silent> kk <Esc>

d and x keys

So every Vim user knows d and x. d is for deleting, or more specifically cutting, which goes into a register. Well, I thought it was a little peculiar that d not only deletes, but cuts, while x only deletes one character. x has a use, but it's quite niche compared to modern text editing. So my suggestion is to change x almost entirely.

Since Ctrl-x or Cmd-x is typically used for cutting system-wide in default operating systems, it makes the most sense to change x to the previous functionality as d whereas it cuts.
So here is a snippet of my init.vim for how I rearranged these:

nnoremap d "0d
nnoremap x "*d
vnoremap d "0d
vnoremap x "*d

d deletes, and when you want to cut, use x.

There is a caveat with changing this. We're changing x to act just like d would, meaning it requires an operator (like in a verb-object way like kakoune explains). So something like xiw works to cut the word under the cursor. Because of this, to delete a single character (the old default x keybind), you can type dl. To cut a single character, it would be xl.

l is the default object for a letter in Vim. Taking this into account, I like to bind c in my operator mode to alias the l key, since c makes more sense for character more than letter, plus c on the keyboard is adjacent to both d and x.

onoremap c l

That makes it really simple to dc or (delete character).

June 16: update

Turns out, there is a very easy Vim plugin to do exactly what I outline with dand x called Vim-Cutlass
In addition, I converted my init.vim file to it's own git repository. I had seen others I follow on Github use gists as an easy
publication of their vim config, but I find that using a git repository for this helps tremendously becasuse of the occasional update,
and also for easier redundancy across different computers that I use.

Vimium

Also if you're a Vim user, you're most likely using the Vimium extension in your browser for simple navigation. Vimium is fantastic, and just works intuitively (check it out if you haven't). The default keybindings for Vimium has the handy keybinds for d for the Vim equivalent of <C-d> (Or Ctrl-d)for moving the page down, and also u for the same thing appropriately for moving a page up. My proposed keybinding is setting e to the same behavior as u in Vimium so that you're using the same hand and same finger for scrolling up and down the page. Setting e doesn't interfere with any other binding and can be done easily in Vimium's settings. In Chrome-based browsers, that is in Settings > Extensions > Vimium > Extensions settings, and then you can paste in:

map e scrollPageUp

Vimium's syntax is different from Vim's scripting, so no need for n before map or nore.

Another small Javascript Tidbit for enforcing a number

KyleFontenot — Sun, 26 Jun 2022 18:23:18 +0000

As I'm getting grasps with Typescript, I watched a really great Youtube tutorial video by Academind (Maximilian) that ran through tons of details on Typescript. In the video, he shows the difference between Typescript and the transpiled Javascript generated which shows a pretty great syntax tool.

...
const something = "5";
    > return +something
    > ...

The + character right before a variable is a way to enforce a number type! In Javascript, literal strings have become completely second-nature to most developers, and one use of it is to enforce a string by using interpolation. This + method is a really nice concise way of filtering a variable for numbers.

The + character before numbers assigns a positive values (and - for negative), so for a dynamic language like Javascript, it's assuming and enforcing the variable as a number under the hood.

This is the first time that I've seen an instance of this syntax used. Good stuff

Not A Beginner Ternary Statement

KyleFontenot — Sat, 25 Jun 2022 23:50:36 +0000

I've begun planning a JS library that I hope that would be published on NPM. As a self-taught programmer, I'm continually learning that observing other peoples' code is incredibly important. As I take notes for similar JS libraries to inspire me, I stumbled on this interesting line of Javascript.

debug = typeof value === 'boolean' ? value : debug

Here's the function scope for full context:

Object.defineProperty(ScrollReveal, 'debug', {
    get: () => debug || false,
    set: value => (debug = typeof value === 'boolean' ? value : debug)
})

I use ternary statements constantly in my freelance web development, but the beginning part of the line is very interesting, as I've never seen this type of assignment/destructing in a ternary before. I didn't know that it was a thing, and it's brilliant.

Left-to-right, the setter is returning (like all ternaries do) a value, but what makes this different is the debug = part, which is assigning typeof value to the lexical variable: debug. So, when using this setter function, if the parameter isn't a boolean, it makes a small referential loop to debug, which is whatever type the parameter is.

I see this being useful for more concisely skipping type clauses in functions, but for when approaching an interface in a negating direction (instead of adding allowed types like string | boolean). If you want to make a type by remove types from any(in JS instead of Typescript world), perhaps this is a nice clean way of doing that.

The beauty of Javascript (or just any programming): You'll always learn more.