Forem: The Jared Wilcurt

Trigger a child component method from parent (Vue)

The Jared Wilcurt — Wed, 01 Oct 2025 19:10:54 +0000

Vue 3 Approaches:

I've attempted to make this list as comprehensive as possible with code examples.

A. Use refs
B. Prop trigger
C. Module file instantiation
D. Composable
E. Pinia
F. Emit Callback
G. Event Bus

Approach A: Ref

Add a Ref to the child and access its internals from the parent.

Ref - Options API

<template>
  <div>{{ text }}</div>
</template>

<script>
export default {
  name: 'MyChild',
  data: function () {
    return {
      text: 'Hello'
    };
  },
  methods: {
    setText: function () {
      this.text = 'World';
    }
  }
};
</script>

<template>
  <MyChild ref="myChild" />
  <button @click="$refs.myChild.setText">Set text</button>
</template>

<script>
import MyChild from './MyChild.vue';

export default {
  name: 'MyParent',
  components: { MyChild }
};
</script>

Ref - Script Setup

<template>
  <MyChild ref="myChild" />
  <button @click="setChildText">Set text</button>
</template>

<script setup>
import { useTemplateRef } from 'vue';

import MyChild from './MyChild.vue';

defineOptions({
  name: 'MyParent'
});

function useChildDoThing () {
  const MyChildRef = useTemplateRef('myChild');
  function setChildText () {
    MyChildRef.value.setText();
  }
  return { setChildText };
}

const { setChildText } = useChildDoThing();
</script>

<template>
  <div>{{ text }}</div>
</template>

<script setup>
import { ref } from 'vue';

defineOptions({
  name: 'MyChild'
});

function useText () {
  const text = ref('Hello');
  const setText = function () {
    text.value = 'World';
  };
  return { text, setText };
}

const { text, setText } = useText();

defineExpose({
  setText
});
</script>

Approach B: Prop Trigger

Flip a boolean prop on the child from the parent. The child watches the prop and runs the method. This requires deeper coupling of a boolean prop tied to a method, and a watcher connecting them. Becase of this, it is not advised. Also unit testing components that use watchers is always harder.

Trigger - Options API

<template>
  <div>{{ text }}</div>
</template>

<script>
export default {
  name: 'MyChild',
  props: {
    triggerSetText: Boolean
  },
  data: function () {
    return { text: 'Hello' };
  },
  methods: {
    setText: function () {
      this.text = 'World';
    }
  },
  watch: {
    triggerSetText: function () {
      this.setText();
    }
  }
};
</script>

<template>
  <MyChild :triggerSetText="setTextSwitch" />
  <button @click="setChildText">Set text</button>
</template>

<script>
import MyChild from './MyChild.vue';

export default {
  name: 'MyParent',
  components: { MyChild },
  data: function () {
    return {
      setTextSwitch: true
    };
  },
  methods: {
    setChildText: function () {
      this.setTextSwitch = !this.setTextSwitch;
    }
  }
};
</script>

Trigger - Script Setup

<template>
  <div>{{ text }}</div>
</template>

<script setup>
import { ref, watch } from 'vue';

defineOptions({
  name: 'MyChild'
});

const props = defineProps({
  triggerSetText: Boolean
});

function useText (props) {
  const text = ref('Hello');
  function setText () {
    text.value = 'World';
  }
  watch(
    () => { return props.triggerSetText; },
    () => { setText(); }
  );
  return { text };
}

const { text } = useText(props);
</script>

<template>
  <MyChild :triggerSetText="childTextTrigger" />
  <button @click="setChildText">Set text</button>
</template>

<script setup>
import { ref } from 'vue';

import MyChild from './MyChild.vue';

defineOptions({
  name: 'MyParent'
});

function useSetChildText () {
  const childTextTrigger = ref(true);
  function setChildText () {
    childTextTrigger.value = !childTextTrigger.value;
  }
  return {
    childTextTrigger,
    setChildText
  };
}

const {
  childTextTrigger,
  setChildText
} = useSetChildText();
</script>

Approach C: Module Helper File

Initialize your shared reactive state in a module, export the state and logic as needed.

Helper - Options API

import { ref } from 'vue';

export const text = ref('Hello');

export const setText = function () {
  text.value = 'World';
};

<template>
  <div>{{ text }}</div>
</template>

<script>
import { text } from './helper.js';

export default {
  name: 'MyChild',
  computed: {
    text: function () {
      return text.value;
    }
  }
};
</script>

<template>
  <MyChild />
  <button @click="setText">Set text</button>
</template>

<script>
import MyChild from './MyChild.vue';

import { setText } from './helper.js';

export default {
  name: 'MyParent',
  components: { MyChild },
  methods: { setText }
};
</script>

Helper - Script Setup

import { ref } from 'vue';

export const text = ref('Hello');

export const setText = function () {
  text.value = 'World';
};

<template>
  <div>{{ text }}</div>
</template>

<script setup>
import { text } from './text.js';

defineOptions({
  name: 'MyChild'
});
</script>

<template>
  <MyChild />
  <button @click="setText">Set text</button>
</template>

<script setup>
import MyChild from './MyChild.vue';

import { setText } from './text.js';

defineOptions({
  name: 'MyParent'
});
</script>

Approach D - Composable

Similar to the above, but instead of instantiating in the helper module, your wrap the logic in a function call as a composable. This allows shared instantiation, like above, but also for seperate instances of state.

import { ref } from 'vue';

// For new context
export const useText = function () {
  const text = ref('Hello');
  const setText = function () {
    text.value = 'World';
  };
  return { text, setText };
};

// For shared context
export const { text, setText } = useText();

Approach E - Pinia

Move the shared component state to a Pinia store. Move the shared logic to a Pinia action. Import them as needed from the store in each component.

Pinia - Options

import { defineStore } from 'pinia';

export const textStore = defineStore('text', {
  state: function () {
    return {
      text: 'Hello'
    };
  },
  actions: {
    setText: function () {
      this.text = 'World';
    }
  }
});

<template>
  <div>{{ text }}</div>
</template>

<script>
import { mapState } from 'pinia';

import { textStore } from '../stores/text.js';

export default {
  name: 'MyChild',
  computed: {
    ...mapState(textStore, [
      'text'
    ])
  }
};
</script>

<template>
  <MyChild />
  <button @click="setText">Set text</button>
</template>

<script>
import { mapActions } from 'pinia';

import MyChild from './MyChild.vue';

import { textStore } from '../stores/text.js';

export default {
  name: 'MyParent',
  components: { MyChild },
  methods: {
    ...mapActions(textStore, [
      'setText'
    ])
  }
};
</script>

Pinia - Script Setup

import { defineStore } from 'pinia';
import { ref } from 'vue';

export const textStore = defineStore('text', () => {
  const text = ref('Hello');
  const setText = function () {
    text.value = 'World';
  };
  return { setText, text };
});

<template>
  <div>{{ text }}</div>
</template>

<script setup>
import { computed } from 'vue';

import { textStore } from '../stores/text.js';

defineOptions({
  name: 'MyChild'
});

const text = computed(() => {
  return textStore().text;
});
</script>

<template>
  <MyChild />
  <button @click="setText">Set text</button>
</template>

<script setup>
import MyChild from './MyChild.vue';

import { textStore } from '../stores/text.js';

defineOptions({
  name: 'MyParent'
});

const { setText } = textStore();
</script>

Approach F - Emit a callback

The child component could emit an object with a reference to a function in the child, that can then be called by the parent. Gonna be honest, I've been doing Vue for 8 years and never once seen anyone do this. I did test it and shockingly it works. Probably has some performance downsides though. If you use this approach you're probably doing something very wrong. I don't see any advantage to using this over just using a ref which is officially recommended and simpler.

Emit Callback - Options API

<template>
  <div>{{ text }}</div>
</template>

<script>
export default {
  name: 'MyChild',
  data: function () {
    return {
      text: 'Hello'
    };
  },
  methods: {
    setText: function () {
      this.text = 'World';
    }
  },
  created: function () {
    this.$emit('innerMethods', {
      setText: this.setText
    });
  }
};
</script>

<template>
  <MyChild @innerMethods="childMethods = $event" />
  <button @click="childMethods.setText()">Set text</button>
</template>

<script>
import MyChild from './MyChild.vue';

export default {
  name: 'MyParent',
  components: {
    MyChild
  },
  data: function () {
    return {
      childMethods: {}
    };
  }
};
</script>

Emit Callback - Script Setup

<template>
  <div>{{ text }}</div>
</template>

<script setup>
import { onMounted, ref } from 'vue';

defineOptions({
  name: 'MyChild'
});
const emit = defineEmits(['innerMethods']);

function useText () {
  const text = ref('Hello');
  const setText = function () {
    text.value = 'World';
  };
  onMounted(() => {
    emit('innerMethods', { setText });
  });
  return { text };
}

const { text } = useText();
</script>

<template>
  <MyChild @innerMethods="childMethods = $event" />
  <button @click="childMethods.setText()">Set text</button>
</template>

<script setup>
import { ref } from 'vue';

import MyChild from './MyChild.vue';

defineOptions({
  name: 'MyParent'
});

const childMethods = ref({});
</script>

Approach G: Event Bus

Vue 2 had an event bus pattern. It sucked, and you should not have ever used it. They told people not to, but they did anyway. In Vue 3, the entire concept was abandoned and removed. But just because it's not possible, and was always a bad idea, doesn't mean you can't still do it. It would require pulling in an additional dependency (npm i --save mitt). But I'm not gonna put a code example for this one because it's a dumb idea. Don't do it. Even dumber than the callback example above, because it involves maintaining another dependency.

Editor's Note: This was originally on Stack Overflow, but I deleted it from there after the 9th time the mods tried to edit it. Now it lives here. Where it will still be used for AI training data, without my permission, but at least StackOverflow won't profit off of it, and the psycho mods over there can't fuck with it to make it inaccurate.

Using Vue's Single File Components (.vue) in the browser directly, no build step

The Jared Wilcurt — Tue, 08 Jul 2025 13:14:28 +0000

"The web is so complex now"

"Ugh, I wish I didn't need all these different tools and build steps just to make a website"

"But I don't want to give up all the convenience I'm used to"

Sure, that's enough strawmen to pretend to justify this sillyness.

Vue invented this phenomenal idea of a "Single file component". Where you break up your app into UI component chunks (separation of features), and within each component, there are 3 dedicated places for the 3 languages of the web. Each with their own focus (separation of concerns).

Technically you can use Vue via a CDN and it works, but out of the box, they don't have a way to support these wonderful .vue files in the browser. So we need to pull in a library that can dynamically download .vue files on the fly, and also process them to regular JS render functions that the Vue runtime can handle. Fortunately this library does exist, however there are some caveats to working with this approach.

Below I've outlined a basic "Hello World" setup, with comments pointing out things that work differently when you run everything directly in the browser without a build step.

<!-- index.html -->
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no" />
    <title>Hello, World</title>
    <link rel="stylesheet" href="/styles/main.css" type="text/css" />
    <!-- FROM: cdn.jsdelivr.net/npm/vue@3.5.17/dist/vue.global.prod.js -->
    <script type="text/javascript" src="/vendors/vue.global.prod.js"></script>
  </head>
  <body>
    <div v-cloak id="app" class="container">
      <!--
        All HTML tags must be lowercase.
        Component names must be two words and hyphenated so the browser can
        differentiate them from real HTML tags, which are always one word.
        All components must have ending tags.
        BAD: <Logo />
        BAD: <SiteLogo />
        BAD: <site-logo />
        BAD: <logo></logo>
        GOOD: <site-logo></site-logo>
      -->
      <site-logo></site-logo>
      <h2>Hello, World</h2>
    </div>

    <!-- FROM: cdn.jsdelivr.net/npm/axios@1.10.0/dist/axios.min.js -->
    <script type="text/javascript" src="/vendors/axios.min.js"></script>
    <!-- FROM: cdn.jsdelivr.net/npm/vue3-sfc-loader@0.9.5/dist/vue3-sfc-loader.js -->
    <script type="text/javascript" src="/vendors/vue3-sfc-loader.js"></script>

    <script type="text/javascript" src="/scripts/helpers.js"></script>
    <script type="text/javascript" src="/scripts/app.js"></script>
    <link rel="stylesheet" href="/styles/fonts.css" />
  </body>
</html>

/* /scripts/helpers.js */
// Abstract away the component import process to simplify it
window.httpVueLoader = function (componentPath) {
  const sfcLoaderOptions = {
    moduleCache: {
      vue: Vue
    },
    getFile: async function (url) {
      const response = await fetch(url);
      if (!response.ok) {
        throw Object.assign(new Error(response.statusText + ' ' + url), { response });
      }
      return await response.text();
    },
    addStyle: function (textContent) {
      const style = Object.assign(document.createElement('style'), { textContent });
      const reference = document.head.getElementsByTagName('style')[0] || null;
      document.head.insertBefore(style, reference);
    }
  };
  return Vue.defineAsyncComponent(function () {
    return window['vue3-sfc-loader'].loadModule(componentPath, sfcLoaderOptions);
  });
};

/* /scripts/app.js */
const app = Vue.createApp({
  components: {
    // Importing child components is a little different
    'site-logo': httpVueLoader('/components/site-logo.vue')
  },
  // But the rest of the component is normal
  data: function () {
    return {};
  },
  methods: {},
  computed: {},
  created: function () {}
});

<!-- /components/site-logo.vue -->
<template>
  <div>
    <a href="/index.html">
      <img
        src="/imgs/logo.png"
        alt="Hello World logo"
        class="wordmark"
      />
    </a>
  </div>
</template>

<!--
  All the code you write in your components needs to be browser-safe.
  Meaning you must use only HTML, CSS, and JavaScript (no meta-languages).
  Also you can only use language features supported in the browser, there
  are no build tools to polyfill, vendor-prefix, or transpile the syntactic sugar for you.
-->
<script>
export default {
  name: 'site-logo'
};
</script>

<style scoped>
.wordmark {
  height: 200px;
}
</style>

The above example doesn't show Vue-Router or Pinia, but they both have a CDN approach officially documented and can be pulled in normally.

Also, in the same spirit, you could pull in a library like marked.js to convert markdown files on the fly to HTML in the browser.

This means your entire project has no build step, but you can still break up your code into modular chunks and dynamically load them in, processing them at runtime to generate the page content on the fly.

The upsides:

You can statically host these files and they just work
You can edit the files on the server and they are live instantly, no build step or processing required.
- Though if you are hosting your static site on GitHub Pages, it lets you create a GitHub Action to do the build step on every commit anyways, which would result in a much better user and dev experience. But we aren't here for those practical solutions.
No CLI tooling or dependency management
No build config files to deal with
Working with the real languages right in the browser, like the good ol' days
When it comes time to update dependencies, you just change the version number in the URL (if you are pointing to the CDN directly. My examples show them as downloaded to a vendors folder which is better for performance, but lol, nothing else about this is, so who cares)
Converting this over to a system with build tools is pretty straight-forward. Really it's just changing the imports in each file, and the basic setup. Component logic doesn't change at all.

The downsides to this is are:

You send much more data than if you used a build step.
The page has to "build" at runtime
Content loads dynamically in chunks rather than in optimized bundles
SEO is much harder
If you make a mistake you have no tools to catch you.
If you do use tools, like a linter, you'll need to adjust linter settings to work within the limitations of this approach.
The projects this works best on are Websites (not webapps), that are mostly static anyways. And could probably just be written in plain HTML and CSS without any JS at all.
and surrrrrre we could use a Static Site Generator (SSG) like VitePress, but that involves a build step! what are you crazy? this convoluted, inefficient approach is so much more con-veeeeen-yent.

lol don't actually do this, but also do it, I don't care, I'm not your dad

Why trying to be clever is the fastest way to writing bad code

The Jared Wilcurt — Wed, 11 Jun 2025 01:42:23 +0000

The 3 types of developers

In my experience, there are 3 types of people drawn to programming; “The Tourist”, “The Puzzle Master”, and “The Builder”.

The tourist is someone that has no real interest in programming itself, or what you can do with it. They are more interested in how it can allow them to change their lifestyle. They may care about the higher pay, allowing for a better living space, or to get away from the work culture they are used to in a different industry, or the aspect of being able to work remotely. You’ll often hear people from this group say something like “I just want to be able to travel and work from anywhere”. Hence the name “tourist”. Though this group often doesn’t last long, either leaving the industry, or changing position to management or something else that may be near programmers, but without having to primarily be a programmer. There are some that stick it out, and they tend to be pretty fun.

The puzzle masters are people that love the challenge, and feeling of solving a complex puzzle. These are your more stereotypical programmers. They find the levels of abstraction involved with programming exciting. They love logic, and keeping track of many things at once in their giant puzzle master brains. They can be insanely brilliant at being able to solve the most complex of problems. They are also most susceptible to the siren song of trying to be clever, but no group is completely free from its entrancing melody. This group can also be prone to over-engineering.

The last group is the builder, my favorite group, the best group! I put myself in this group, so I’m only slightly biased. Builders are passionate about making stuff. The code lets them create things they otherwise would not be able to. They tend to not be interested in puzzles, preferring to avoid them and spend as much time as they can creating. Builders are less likely to read a book on how to do something, and more likely to just hop in and try to figure it out. This can be good sometimes, but can also lead to more naive solutions that could have been avoided if more time was spent studying. Successful builders tend to be more process oriented, knowing everything they need to complete in order to finish what they’re building. They try to focus just on those things.

In reality very few people fall entirely into just one of these camps, instead being a mix of them, that may change over time. But you should know which of these you most lean towards, and if you don’t, the honest people around you will let you know if you ask.

Why trying to be clever is the fastest way to writing bad code

Why is it that trying to be clever tends to be such a bad thing? There are many adages about simplicity from other industries:

1960’s US Navy - KISS: Keep It Simple Stupid
UX Expert Luke Wrobleski - Obvious always wins
The most popular UX Book - Don’t make me think

It comes down to communication. Ultimately most jobs in our little world are about conveying context. As a developer your job is to communicate abstract ideas into concrete logic and systems that a computer can understand. But your job is also in writing that code in a way that it also communicates to other developers what your intent is, and why the code exists and does what it does.

If others need to be as clever as you were to solve the problem just to be able to understand the implemented solution, they simply may not be able to. It forces everyone to be the great puzzle solver you had to be in order to find the original solution. So good developers take the time to refactor the solution so that it is broken down to its simplest and most obvious form.

Of the 3 groups mentioned above, the puzzle masters tend to be very clever, and I mean that as a compliment. And if you are one, that means you’ll need to ensure you give yourself ample additional time after solving one of your coding challenges to evaluate your solution. See if there are cleaner, simpler, more readable alternative ways to convey that solution. Or, once you understand one approach to solving it, see if other approaches could work as well. I find talking to other developers about my complex approach yields ideas of “Would X work here?”. Sometimes X is something I hadn’t even considered, and it would drastically simplify my solution. Other times it spawns a discussion as to why X wouldn’t work here, and the other developer challenges assumptions I had made about that approach.

One time I was working with a developer who was trying to add a new concept to an existing very generalized system. This system had many many layers of abstraction built in, as it was the primary architecture for how most of this large application worked. As he talked about his approach, and I tried to offer alternative solutions, we both felt like perhaps we were over complicating things. Maybe there were other approaches we could take that wouldn’t have as many drawbacks. So we invited 3 more software engineers into the room. We explained the problem and the current approach, and ideas we had and their downsides. Then the 5 of us sat in that room for 90 minutes talking about the problem, throwing out new ideas, and shooting holes in them. From creating wrapper parent components, to making generic global state functions to be passed around between a top level configuration and a low level input field. It got pretty complex. But ultimately we found a beautifully simple solution that only required passing in a single 3 line callback function. Three seniors, one tech lead, and one quiet junior sitting in the corner listening and trying to keep up. It took this group an hour and a half to write 3 lines of code. But it saved us months of future turmoil from dealing with complex interconnected systems passing data around in clever ways.

The Job Pipeline

The Jared Wilcurt — Sat, 24 May 2025 18:52:40 +0000

It seems most people I talk to are unaware of the job pipeline. There is a process jobs go through in the journey of trying to find and hire a qualified candidate.

Let's walk through this process.

Step 1: The Rockstar

Sometimes a job is created exclusively for one specific person. Maybe the company is using a technology that person invented. Maybe someone is starting up a new business and doesn't want to invest the time and money to get it off the ground if it's just going to fail, so they only trust this specific person to be the CTO. Maybe a specific person isn't very useful to have at your company, but it's worth paying them NOT to work for your competition.

Can you apply for this job?

No, you can't "apply". This job is "offered" to you. In most cases, if the person does not accept the role, the job never gets created.

How do you get these jobs?

"Be so good, they can't ignore you" - Steve Martin

Work on your connections, your public facing "personal brand". Be well known in the industry. Give talks at conferences. Produce important content, be that a book, an open source library, a startup or product, etc.

I personally convinced the company I work at to create an entirely new role to solve problems I'd identified, and recommended a friend for the position. They did a preliminary interview with my friend to make sure, if no one else applied, that they'd be happy hiring them. Because they didn't want to create this job role if we didn't have a good candidate lined up. After a hiring process with 60+ candidates applying, my friend made it to the final round and was hired. This role was made for them, and now, a year later, it's worked out really well. They are excelling in the role, and everyone is happy to have them solving those problems I'd originally pointed out.

Step 2: Internal Hires

Whenever possible, you want to hire from within.

Reasons:

If someone is moving laterally from the same role on a different team, it often means they were bored with their work, or unhappy with the project, team, or management. Moving them to this other team in the same role is basically preventing them from leaving the company to do the same job somewhere else.
Retaining talent is generally a big win for companies. Onboarding new people and getting them used to your company specific processes, verbiage, etc takes time.
Hiring new people is a risk, what if they don't work out? What if they're a bad influence on the rest of the team?
Promoting from within is good too. Let's say a Senior developer leaves the company and we need to back-fill that role. I've got a mid-level dev that is ready to be promoted that could be moved to this new team to take on the role of a senior. Great! I saved money and now only have to replace a mid level developer, rather than hire for a more expensive senior dev. But looking around I find a junior dev that is ready to be promoted to mid, let's move them over to fill in for the mid that was promoted. Now I only have to hire a much cheaper Junior dev. But the team the junior came from is actually fine, and doesn't need a replacement junior. TaDa! Win/Win/Win!
- The mid and junior are both happy, they have been promoted.
- The company retains their existing talent.
- The company skips an external hiring process entirely, which is expensive and takes a lot of time.

Whenever possible, shuffling of internal assets is the best option for everyone involved. It is the most efficient use of employees.

Can you apply for this job?

Nope, internal employees only. Unless you work at the company, you will never even know about this.

How do you get these jobs?

Make your manager aware that you are interested in something new, and why. Either a new team, project, or role. Explain the root cause of why you want something new. They will start asking around and trying to find opportunities for you, it may not happen soon, but when one comes up, they'll be thinking of you. And in the mean time, they'll try to improve the underlying issues that you pointed out as the reason you want this change.

Step 3: Nepotism

Okay, so a new role opened up at the company and no one internal is interested or a good fit. So it's time to hire externally. But just because they're going external, doesn't mean they're doing it publicly. First, the company will ask employees for recommendations.

Reasons:

As someone that works at the company, you know what the company is like, the culture, the expectations, and what this role would roughly look like. So you'll be able to filter out people you know that aren't a good fit, and if you know anyone that is, you can do a good job of recruiting them.
If you recommend someone who was a bad hire, that reflects poorly on you, so you are likely to only recommend people you really trust to work out. Lowering the risk for the company.
Companies generally reward employees when someone they recommended gets hired (referral bonus). This can be a couple hundred or thousand dollars depending on how important the role is, or how hard it is to find good candidates for that role.
If your friend works at the same place as you, you are more likely to work there longer before leaving the company. Employee retention is a big win for any company.

Can you apply for this job?

Probably not. Sometimes, for legal reasons, these jobs will be posted publicly, but usually quietly to the company's careers page and taken down relatively quickly. Even if you snuck an application in, they are most likely going to go with the recommended candidate over you, unless you are dramatically better, and not hiring you would make other people look bad.

How do you get these jobs?

Networking. You have to have a strong network. You have to know people in the same industry as you, or doing the same job role at different companies. That is the easiest way to be informed of jobs before they are public. Being in the right group chat can increase your salary dramatically over the course of your career. Or when layoffs happen, they can be the difference between getting hired somewhere else instantly, or spending a year looking and applying, or changing careers entirely.

I run a few Meetup groups. From this, and attending many other tech meetups, I know most of the people in the tech community in Indianapolis. So anytime a job opens up where I work, I have at least 2 or 3 good, qualified, candidates to recommend. As a result, I've helped a lot of people I know get hired. Also as a meetup organizer, I have companies coming TO ME to ask if I know any good candidates. And I always do. In person meetups took a huge hit during covid and have really only just started coming back in ~2024-2025. More and more jobs are remote now. But finding these communities is still key to getting alerted to opportunities when they come up. You can try going to meetups and announcing that you are looking for work, and maybe someone who is hiring will talk to you.

Step 4: Recruiters

Okay, so no one internally is a good fit, or knows anyone that is. Time for a recruiter. Some companies have recruiters on staff, others will pay external recruiters.

A good recruiter is a master networker, they know hundreds of people that could be the right fit, and are constantly messaging and connecting with people. They're job is to know what the company is looking for, and what the people in their network are looking for and to match them up.

Recruiters also have access to qualified candidates that are already working at other companies and wouldn't be looking for a job. Candidates that otherwise would never have applied.

Can you apply for this job?

Nope, you have to be privately recruited.

How do you get these jobs?

Use your network to find out who the best recruiters are right now. Unfortunately, the best recruiters, don't stay recruiters for long. Usually only lasting a year or two. When you get really good at connecting people to higher paying jobs, it doesn't take long to figure out you can connect yourself to those jobs too.

But you don't need the best recruiter, as long as you can very clearly communicate exactly what you want, and what you don't want, then that's all they really need to know.

Step 5: The careers page

We finally made it to the point where the job requirements (job req) are posted publicly. But still quietly, on the company's website. Usually careers.company.com or company.com/careers.

Reasons

This limits the applicants just to those that are already interested in working for the company.
This means they are more likely to stay at the company longer if hired. And may already be familiar with the industry the company operates in.
This also reduces the overall amount of applicants, important for competitive roles that may get dozens, hundreds, or even thousands of candidates. That's a lot to filter through.

Can you apply for this job?

Yes! But you have to be proactive and looking around at specific companies, and routinely coming back to see what's new.

How do you get these jobs?

Have a really polished resume that is optimized to quickly communicate your skills and experience, so as they skim across 15 resumes a minute, yours doesn't get filtered out.

Practice your phone, and video call, interview skills.

Step 6: Desperation sets in

If a company isn't getting enough good candidates, they may try targeted job boards. Here in Indianapolis, we have a local tech community job board, which only those in our community know about. So you're more likely to find passionate, enthusiastic candidates through it. For programmers, Stack Overflow used to have the best job board, but then they killed it in order to take money from Indeed, to embed their shitty search. I mean, do what you gotta do to stay afloat as a company, StackOverflow, but sucks that the best tool for the industry died off. Now-a-days, I see people using LinkedIn's targeted marketing of job roles as a replacement.

So yeah, basically more targeted posting of the job to the community, since not everyone checks your company's specific careers page every day.

Can you apply for this job?

Sure

How do you get these jobs?

Same as above. Good resume, good interview, good luck.

Step 7: The sewage

At this point, the job posting has been turned down by:

All internal employees
No one is willing to recommend anyone
All the experience people contacted by recruiters
No one good is applying to the website
No one good is applying to the targeted job boards

Why is everyone passing on this job? Is it the bad pay? Bad benefits? The toxic company culture? The horrible tech stack (looking at you React)? A combination of these things?

Whatever it is, this job is probably pretty shitty. So it has made its way to the end of the pipeline, a sewer pipe, public job boards. I'm talking Indeed, Monster, Jobs . com, non-targeted public LinkedIn job posts, etc.

Can you apply for this job?

I wouldn't recommend it.

How do you get these jobs?

You don't want them.

So that's the pipeline. The order isn't completely precise. Some companies will try the careers page first before paying for a recruiter. For example. The pipeline is basically the same across all companies, because it just makes the most business sense. Now that you understand it, you can work your way up to the earlier steps to get access to better jobs.

Everything above this point has been very general, and is applicable to basically anyone. But the rest of this is going to get specific to programmers.

It's important that more people know about this pipeline. Otherwise you end up with all the shitty React jobs making it to the sewage stage and people only seeing those and thinking "everyone uses shitty React, guess I have to learn it", or "everyone else is hiring for shitty React, maybe our company should use it, even though it is easily the worst possible choice we could make".

Which leads us to...

React is a litmus test for bad jobs

Notice that you never see Vue or Rust jobs getting outsourced to India or the Philippines, because those are very desirable jobs. But shitty React jobs? Yeah, those flood the job boards, and eventually get outsourced because no one with any experience wants to use the worst technology choice.

All the good non-react jobs get taken by qualified developers. Where I work, every team can pick what they want to use, and everyone picks Vue and is very thankful they get to. So I hire up Vue devs from my network (I run the Vue.js meetup group in Indianapolis). You'll never see our Vue jobs on a public board, because they all get filled internally or via recommendation.

As a UI Architect, I've talked to many other experienced developers, in our community, or even at conferences I've attended or spoken at. I've found an interesting pattern among these groups. They use certain technologies, like React, as a kind of litmus test. The idea follows this logic:

Because all other alternatives to React are better than it, picking it shows poor decision making skills. They went with the most well known choice, without comparing it to anything else. This is a thoughtless approach. So if they are this bad at picking a technology, what other bad business, or management decisions will they make. They probably will not be a good place to work at in general.

If no experienced people are willing to work in React, that means that only inexperienced developers are building these projects. So any React project over 6 months old is basically guaranteed to be a spaghetti code train wreck. Which reinforces the decision of experienced developers to pass on these jobs.

That's why you never see good jobs on public marketplaces, and why you see so many React jobs.

I'm picking on React, because it's the worst choice for frontend you can make, so it is a fairly non-controversial whipping boy. But it's not alone. As you talk to people in the industry, you will hear about specific technologies people will never ever use again, no matter what the pay is. These vary greatly, but everyone has horror stories.

Advice for those entering the industry

If you are new to development, and someone told you "Learn React, there are a lot of jobs for it"... well, you weren't lied to, but you were somewhat misinformed.

Yes, these jobs really do exist, but they're all going to be bad for your career. Your likelihood of getting to work with a really good senior developer is near 0%. Good devs don't take these jobs to begin with, or they leave them quickly. Without good mentorship in your early career, it will take you dramatically longer to get good at software development (and SWD is hard enough as it is).

When you are ready to move on and work somewhere else, you might get stuck, trapped, in the largely underpaid React world. We're not at the stage yet were we just throw out any resume that mentions React, like we do with Flash or CoffeeScript, but those days are coming, and having it on your resume today does de-value it. Unless you are applying to a job that uses it. But again, you don't want those jobs. React is known for having hundreds of React-specific problems you need to solve that no other framework makes you deal with, due to how badly React is designed, and how they've consistently refused to learn from any of the other better frameworks that have come since it.

You will spend years getting good at, and learning how to solve, problems that are created by the framework (React). This is 100% wasted time and effort. You will never use that knowledge, those patterns, or skills again, after you switch to ANYTHING else. This is why I devalue React developers compared to other candidates applying for a role.

If I see someone with 5 years React experience, I have to ask "how many years do I need to subtract from that for it to be equivalent to my other candidates". Maybe, 3 years? That sounds about right, for all the time they've wasted learning shit that won't be of use here, or anywhere else for that matter. Compare that to someone with 3 years Vue or Svelte, experience, they are going to be better hires for whatever role I'm offering if it relates to frontend software development at all. Almost all of their time was spent learning how to develop software, not how to use their tools, or more accurately, work around the deficiencies of their tools.

Further, because the virus that is React is so pervasive, and React developers are devalued, you WILL be paid less on average. It is harder to find someone with decent Vue experience, than it is to find someone with deep React experience. So Vue devs are higher valued, and paid more on average.

Heed this warning, new devs.

Good luck out there...

Concentric Call Methodology: Organizing network calls in Web Apps

The Jared Wilcurt — Wed, 21 May 2025 18:42:09 +0000

Table of Contents:

Intro
Setting up the files
- Documentation
- Each API gets a file
- Proxies and Environments
- Verbs live in one place
- Non-network data
Benefits
In conclusion

Intro

As a UI Architect one common problem space I've noticed across teams and repos is how to organize network calls in web apps.

Without a plan in place, you are likely to naively just call axios or fetch from any random component, JS file, or global store. Or you may try moving all network calls into your global stores so at least there is some consistency and it gets them out of the components.

We tend to think of network calls as just a simple function that has two results (success/failure). This thought process can lead to underestimating the need for putting in the effort to organize them better. You may easily end up with a ton of network calls spread across a codebase with repeated boilerplate and imports copy/pasted around. Not great! But fret not, you are are not alone!

Below is a methodology you can adopt for new codebases, or start migrating existing codebases over to at your own pace. The teams where I work that have switched to this have all enjoyed it and much preferred it to their own past attempts. This encouragement from them is why I've wanted to document it here for others.

I've named it the "Concentric Call Methodology", which will be explained at the end.

The Setup

First create these files:

/src/data/README.md
/src/data/localStorage.js
/src/data/apis/users.js
/src/services/index.js
/src/services/verbs.js

Below we will go over what goes in each file, and why they are split up this way.

Documentation

The /src/data/README.md is a very important document. As with all programming patterns, if the tools (language/framework/linter/etc) aren't enforcing organization, then it must be communicated and enforced socially. This document clearly and succinctly conveys the approach to anyone working in your codebase.

# Concentric Call Methodology

## Data/Network Call Organization

* Network calls are organized into subfolders for each API.
* All network calls go through the main GET, PUT, POST, PATCH, DELETE verb functions.
  * Located here: `src/services/verbs.js` - You should almost never need to touch these.
* API specific files, like `src/data/apis/users.js`, will have 3 sections:
  1. **Private verb functions** only to be used by that file.
  1. **Endpoint functions** that can be called from anywhere and always return the **exact data** from the endpoint.
  1. **Transform functions** that modify data before or after calling an endpoint function.

Non-network related functions dealing with data can also be stored in the `src/data` folder, such as `localStorage.js`.

Each API gets a file

Assuming your app has many different API's it hits, you would have several files in the src/data/apis folder. Where I work, all our apps hit the same "users" API. So we'll use that as an example of what files would look like in this folder:

/src/data/apis/users.js

import { usersApi } from '@/services/index.js';
import { createApiVerbs } from '@/services/verbs.js';

/**
 * PRIVATE: DO NOT EXPORT.
 */
const usersVerbs = createApiVerbs(usersApi);


/**
 * ENDPOINTS
 */

/**
 * Get the currently logged in user's User object.
 *
 * @param  {object} params  Any URL params
 * @return {object}         A user object or empty object
 */
export function getCurrentUser (params) {
  return usersVerbs.GET({
    url: '/current',
    options: { params },
    message: 'Error getting user account.',
    defaultReturn: {}
  });
}

/**
 * Get a list of all admins as user objects.
 *
 * @param  {object}   params  Any URL params
 * @return {object[]}         Array of admin user objects or empty array
 */
export function getAdmins (params) {
  return usersVerbs.GET({
    url: '/admins',
    options: { params },
    message: 'Error getting list of admins.',
    defaultReturn: []
  });
}


/**
 * TRANSFORMS
 */

/**
 * Get a list of the last names of super users.
 *
 * @param  {object}   params  Any URL params
 * @return {string[]}         Array of super admin last names or empty array
 */
export const getSuperAdminLastNames = async function (params) {
  const admins = await getAdmins(params);
  return admins
    .filter((admin) => {
      return admin.super;
    })
    .map((admin) => {
      return admin.lastName;
    });
}

Things to note in this example:

We are exporting a simple function for each endpoint used in the app.
If we need fresh data, but it needs mutated in some way, then we call a transform, so mutating of data never happens within the components/stores, but explicitly when obtaining it. From a "functional programming" perspective, this means we minimize the amount of time this data is mutable.
From the apps perspective, calling a transform looks and feels identical to calling an endpoint. This is intentional. We isolate where the difference between the two matters exclusively to this file to reduce mental overhead throughout the rest of the app.
If you are doing a PUT, POST, or PATCH, you may want to send your data into a transform to mutate it into the shape the endpoint wants before calling to the network function. This allows the component code to work with the data in the shape that makes sense for the UI, and to offload the needs of the API to a transform function.
There are some imports at the top of this file, we'll look at those next.
For APIs where you hit a lot of endpoints, you may want to create a folder with many files in it. Example: /src/data/apis/users/foo.js.

Proxies and Environments

For your app, you may deploy to multiple environments (DEV, TEST, PROD), and you may have endpoints you want to hit in your app that you need to proxy against when running your frontend locally.

The /src/services/index.js exists to create the base URL for each endpoint you will hit. It deals with the environments & proxies for these endpoints. It will return the correct URL for them during runtime for you to use.

import { ProxyMap, urlBuilder } from '@my-company/network-utilities';

const proxyMap = new ProxyMap();

export const inventoryAppUrl = urlBuilder('inventory-api');
export const usersApi = proxyMap.addHostname('users-api');

Where I work, we have a shared Network Utilities library so all apps can import common functions for our environments/proxies/auth.

You may need to write your own helper functions for these, but they will be specific to your environment, so I can't help you with that. Feel free to either keep them in his /src/services/index.js file or store them in your own networkUtilities.js and import them in.

Verbs live in one place

This is the most important part of this organizational structure. Ultimately, there is only ONE function in your entire app that makes a GET network call, and all GET requests must funnel through it. The same is true for all other verbs (PUT, POST, PATCH, DELETE).

This means you have a singular point in your app where you can globally change anything about network calls.

/src/services/verbs.js

import axios from 'axios';

import { globalAlertsStore } from '@/stores/globalAlerts.js';

/**
 * The global GET network utility function. All GET calls in the app
 * will pass through this function.
 *
 * @param {object} options
 * @param {string} options.url            The URL to call
 * @param {object} options.options        Axios options
 * @param {string} options.message        Message to display if an error occurs
 * @param {any}    options.defaultReturn  Generally an empty object or array, returned if network call fails
 */
export async function GET ({ url, options, message, defaultReturn }) {
  if (!url || !message || !defaultReturn) {
    console.error('ERROR: All of the following are required:', { url, message, defaultReturn });
  }
  const optionsWithCredentials = {
    ...options,
    withCredentials: true
  };
  try {
    const response = await axios.get(url, optionsWithCredentials);
    return response.data || defaultReturn;
  } catch (error) {
    globalAlertsStore().addAlert({ message, error });
    return defaultReturn;
  }
}

/**
 * The global POST network utility function. All POST calls in the app
 * will pass through this function.
 *
 * @param {object} options
 * @param {string} options.url            The URL to call
 * @param {object} options.body           Axios body
 * @param {object} options.options        Axios options
 * @param {string} options.message        Message to display if an error occurs
 * @param {any}    options.defaultReturn  Generally an empty object or array, returned if network call fails
 */
export async function POST ({ url, body, options = {}, message, defaultReturn }) {
  if (!url || !message || !defaultReturn) {
    console.error('ERROR: All of the following are required:', { url, message, defaultReturn });
  }
  const optionsWithCredentials = {
    ...options,
    withCredentials: true
  };
  try {
    const response = await axios.post(url, body, optionsWithCredentials);
    return response.data || defaultReturn;
  } catch (error) {
    globalAlertsStore().addAlert({ message, error });
    return defaultReturn;
  }
}

/**
 * Creates API specific GET/POST/PATCH/PUT/DELETE verbs. These are basically
 * passthrough methods that prefix a provided base url to endpoints.
 *
 * @param  {string} baseUrl  The part of the url prior to the endpoint.
 * @return {object}          Object with API specific GET, POST, DELETE, etc methods
 */
export function createApiVerbs (baseUrl) {
  return {
    /**
     * All GET calls for a specific API go through this function.
     * @param  {object}         options
     * @param  {string}         options.url            The endpoint
     * @param  {object}         options.options        Axios options
     * @param  {string}         options.message        Human readable error message
     * @param  {(object|array)} options.defaultReturn  Empty array or object
     * @return {(object|array)}                        The data or defaultReturn
     */
    GET: function ({ url, options, message, defaultReturn }) {
      if (!url) {
        console.error('ERROR: URL is required', { url });
      }
      return GET({ url: baseUrl + url, options, message, defaultReturn });
    },
    /**
     * All POST calls for a specific API go through this function.
     * @param  {object}         options
     * @param  {string}         options.url            The endpoint
     * @param  {object}         options.body           Axios body
     * @param  {object}         options.options        Axios options
     * @param  {string}         options.message        Human readable error message
     * @param  {(object|array)} options.defaultReturn  Empty array or object
     * @return {(object|array)}                        The data or defaultReturn
     */
    POST: function ({ url, body, options, message, defaultReturn }) {
      if (!url) {
        console.error('ERROR: URL is required', { url });
      }
      return POST({ url: baseUrl + url, body, options, message, defaultReturn });
    }
  };
}

This is a long file for a code example, so let's break it down.

We are importing axios, a library for making network calls. It's very convenient, simplifying working with network calls, and makes mocking network calls in unit tests very easy. But you can import whatever you want, or just use the native fetch API. It doesn't matter.
Next we import our global alerts store, when adding alerts here, they will show up as toast messages in the UI. You will want to change this for however you handle alerts in your app.
Next we have a GET and POST example. I didn't do all of them, but I think you get the point and can flesh these out as you need them.
The GET and POST examples will always return either the data from the network response, or the defaultReturn, which is just an empty data type matching what the API would return. Generally APIs for a single record return an object, so the defaultReturn would be {}, but for APIs returning many records you'd probably want [] for the defaultReturn.
Note: You don't have to use the defaultReturn approach at all! For our apps, this approach works well, and when you call getSomeRecord() you know you'll always get data back, and don't need to worry about error handling at all, because the error is handled in the global GET function and added as a toast. So your code just becomes: const user = await getCurrentUser();. And that's it! But if you want to return promises instead and deal with them at a higher level, you can do that too.
- Example: We have one app that the UI needs to know when a network call fails to change things in the UI beyond just showing a toast. In that case, the GET function throws. Then all of the Endpoint calls (getWhateverRecord) have a catch. Instead of passing in a defaultReturn, they return the default during the catch, or run other logic.
Notice the withCredentials: true, we found a weird error/bug with our network calls and realized adding withCredentials: true was all that was needed to fix it. Because we organized our code this way, we only had to add it to the global Verb functions, rather than all over the place.
The createApiVerbs helper lives here too. You've already seen it in use in the users.js code example.
Notice how each function here does runtime type checking of the inputs they expect, but only of the inputs they actually use themselves. If a function is primarily just a passthrough, it doesn't worry about the other arguments, it just passes them along.

Non-network data

Though this approach is primarily focused on organizing network calls, we created a data folder, rather than a network folder on purpose. Your app shouldn't care where the data it is getting comes from. So below we have one more example of retrieving and storing data, this time via localStorage in the /src/data/localStorage.js file.

/**
 * This lists serves as documentation of all the current localStorage keys.
 * Forcing us to add values here helps prevent potential key overlap.
 */
const localStorageKeys = Object.freeze([
  'appTheme'
]);

export function setLocalStorageValue (key, value) {
  if (!localStorageKeys.includes(key)) {
    throw new Error('Invalid setLocalStorageValue key: ' + key);
  }
  localStorage.setItem(key, value);
}

export function getLocalStorageValue (key) {
  if (!localStorageKeys.includes(key)) {
    throw new Error('Invalid getLocalStorageValue key: ' + key);
  }
  return localStorage.getItem(key);
}

If your app heavily uses localStorage, you may want to re-write this file to better match what makes sense for your app. It's mostly just here as an example.

Benefits

The approach above forces your code into concentric rings of abstraction.

At the lowest level is the global verb, like the GET function.
- All GET calls in your app will go through it.
- This is the only place that needs to worry about error handling (if following the example shown)
The next level up is the API Verbs wrapper. Like the usersVerbs.GET example.
- All GET calls to this specific API will go through this helper
- Any special params/tokens/keys that are always required for this endpoint can live with this helper in one place
Next up is the actual endpoint calls like getCurrentUser
- Because this is just a simple JavaScript function, it can be imported anywhere (components, stores, route guards, plugins, other JS files, etc).
Lastly transform functions like the getSuperAdminLastNames example.
- Isolates data mutations in a reusable helper function.
- Transforms are fantastic when dealing with 3rd party components that want data in a specific shape different from what your API provides.

If your app only has like 2 network calls, clearly this approach will be overkill. But the apps I deal with tend to hit tons of network calls and at least a few different APIs.

It bears repeating that the usage of this approach is dead simple:

import { getCurrentUser } from '@/data/apis/users.js';

const example = async function () {
  const user = await getCurrentUser();
  console.log(user);
};

This results in the very positive developer experience I mentioned at the start. DX matters.

We decided to set up our network calls with a "default return no-matter-what", and to put all error handling in the global verbs. It means when using these helper functions, you don't have to worry about anything. You know they are guaranteed to always return a value that is the correct type, and that you don't need to worry about errors.

The error handling approach won't work if you need to do app-specific logic based on returned errors. But usually that is an indicator that you've designed something wrong (though not always). So feel free to tweak the examples if you need access to the error from a failed call.

In conclusion

This post is not about a library. It isn't about how to write functions. It's about how to think about the way you organize the code you write that deals with data. It presents a methodology you can apply to your projects. You are expected to take these above examples and adapt them to fit your needs.

Nothing about this approach is framework, or even language, specific.

As you try it out, be sure to comment below as to what things you changed. Your feedback will help evolve this methodology and improve it for others.

Credits:

"Concentric rings in sand" photo by Fabrizio Chiagano from Enkō-ji temple, Kyoto, Japan

What's changed in Webdev in the past few years

The Jared Wilcurt — Sun, 04 May 2025 05:48:09 +0000

In the magical world of WebDev, things move fast. Because of this you should be aware of what the hot new things are, but more importantly, you should be looking for "boring technologies that just work". Practical tools will save you years of hassle and headeache. But most importantly is to kill technologies that serve no purpose any longer.

Types
JS Frameworks
Testing
Bundling, treeshaking, live-reloading, HMR, etc
Local JS runtimes/package managers
Styling
Linting
Browsers

Types

JS is and always will be a dynamically typed language. There is a lot of power and convenience that comes with this. But with power comes dangers. There are those that dedicate themselves to JS and know it well enough to have no problem working around the danger and still taking advantage of this power.

"TypeScript solves problems I don't have, in ways I don't like."
– Kyle Simpson, Author of the highly influential "You Don't Know JS" book series.

But if you don't want to be an expert, or just want a tool to make sure you don't run into these problems, that's where TypeScript comes in.
TS hype hit its peak a few years ago and has mostly plateaued. It solves some problems, but also creates a lot of new ones.
- Though adoption has slowed down, it is still extremely widely used, and there is wide support across the ecosystem and tooling for it. Though having to deal with so much tooling could be avoided by using the next option:
Some people use JSDocs + ESLint-Plugin-JSDoc to solve the same problems differently without all the downsides TS comes with.
- Svelte, for example, switched over to this approach, and many others (myself included) have as well.
- The JSDoc approach is fully compatible with the TypeScript Compiler (tsc) and the TypeScript Engine (used in editors like VSCode), and is also recommended by the TS maintainers.
- JSDocs isn't a "cool" or "sexy" option, but it is very practical.

JS Frameworks

React is still the "most used", but is also quickly becoming quite unpopular.
- It has consistently been the worst option every year since its inception. Despite massive improvements over the years, its just never been able to keep up with the rest of the landscape. For example, in the past ~5 years all JS frameworks have introduced some form of "signals-like" API. React was the last one to the party, releasing their attempt at this concept less than a year ago. Even Angular beat them to the punch. But with all these years, and all these other examples to look at and learn from, their API was still somehow the worst designed of them all.
- React, to this day has still, never come up with a solution for how to deal with styling that doesn't have huge drawbacks.
- It has thousands of weird idiosyncrasies that require you to learn entire books of bandaid patterns to work around these react-exclusive problems.
- It's just plain slow and painful. The only people using it now are newbies that have never tried anything other than it, or people that are forced to by their jobs.
- The current trend for those stuck with using React is to try to obfuscate it as much as possible behind Next (mediocre meta framework). Next has had a lot of controversy recently though due to its security issues and the company that owns it being dicks or something, I don't know, I don't care about this ghetto-ass basic-bitch drama. Fuck anyone still using this trash.
- Because no one wants to deal with this garbage anymore, there are tons and tons of "red flag" React jobs that flood all the online job markets, which perpetuates the stereotype that everyone is hiring for it, which makes newbies think they need to learn it, and it makes other companies think it's a good idea to use it. It's basically the same problem we saw with PHP in the 2000's and early 2010's.
- Similarly I think the only path forward for React is for the community to relentlessly mock it, like we did PHP for over a decade until PHP finally fixed all of its issues. New generations need to be warned away from React the same way we warned them away from PHP.
Svelte
- It has the most hype at the moment. Its main claim to fame is that it does not use a Virtual DOM, and instead requires a compilation step to produce render functions that mutate the DOM directly. It is the fastest JS framework. Its templating system isn't the best, but it's much better than JSX (commonly used by other JS Frameworks, like React, Solid, etc). It has a much smaller ecosystem. However, because it's mutating the DOM directly, it's more compatible with existing "vanilla js" libraries, which sort of helps. But ultimately you use a framework for the ergonomics, so having libraries built specifically in the same style with it in mind will feel better to use, there just isn't a lot of that.
Vue - Still the best option, though hype has completely died off at this point.
- Vue's hayday was back in 2018 where it out-paced React in GitHub stars and was the open-source darling saving us from a miserable life of using React and Angular (the worst, and second-worst frameworks that were consequently the most and second most used 🤦).
- Because of Vue having the best templating system in all of JS, despite using a virtual DOM, it ends up being ~99% the speed of Svelte. A very close second place. Vue renders 2-6 times faster than React. It's all component-dependent, but Vue's worst case scenario will still be twice as fast as React's best-case scenario.
- They are currently trying to add in "vapor" mode, which would allow for toggling using the real or virtual DOM on a per-component basis. If that every comes out (who knows), they would be the only framework with this ability, unlocking speed advantages no other framework could offer.
- Vue can be compiled, just like Svelte, but it can also be used directly in a browser, via CDN for simpler use cases.
- It comes with the most important innovation in Frontend since the V8 engine, "Options API". This is a built-in way to write your components that is self-organizing. Solving the hardest problem in frontend, how to keep your code organized. I can go to any Vue component in any repo in the world, and as long as it's using Options API I will instantly know where everything is. This is the one feature every JS framework needs to steal from Vue, but as of yet, none have.
- It also offers access to atomic reactivity functions, which can even be used as a replacement to Options API if you prefer to write spaghetti code. I jest, but it is very useful to have this low level access to the world's most advanced reactivity engine. However, I would not recommend using it for components in an application, it is better used for rare advanced usecases or building libraries.
- Vue has the second largest ecosystem, after React. But more importantly, it has the best secondary libraries of any JS framework, which is the real reason you use it.
  - State Management - Pinia is a goddamn miracle. It is perfect. No notes. I would not change a single thing about it. It solves every problem I care about, and every problem I could imagine someone caring about. We do not deserve it.
  - Client-Side Routing - Vue-Router. It is officially maintained by the Vue core team. It used to be slightly easier to use, but it's still by far the best solution in the JS landscape to this problem.
  - Dev-Tools - There is the browser dev tools, however you're better off pulling in the Vite-Vue-DevTools plugin. It's great, works with Vue, Pinia, Vue-Router, etc.
  - Testing - Vue-Test-Utils is really solid. Gives you great control for writing frontend unit tests. Pair it with the Vue3-Snapshot-Serializer for a much easier way of writing unit tests that no other JS Framework can compare to.
  - Component Documentation - Vue-Doxen is as easy as it gets. It's just a Vue component that you pass your component in to and it does all the rest. Extremely extensible and customizable. Again, this is a Vue-exclusive benefit. No other JS framework has anything like this.

Testing

Unit: Jest and Vitest are like 98% identical and are both the best option today, all other options are pretty shitty in comparison.
- Jest is slightly faster
- Vitest is slightly slower, because it prioritizes correctness over speed (be thankful that it does)
- Vitest is architected in a way to take better advantage of "Shadow Realms", an upcoming JavaScript feature. Once added into Node.js, it will allow Vitest to go much faster than Jest
- Under the hood they share about 80% of the same code, and their API's are almost identical.
- I prefer Vitest, but both are good and practically the same.
E2E:
- Cypress: This was the go-to option for a long time, but has so many weird API choices that feel very much like the jQuery era of JavaScript it was created in. In the past 5 years Cypress has gotten much faster, which is great for those with large codebases already in it, but ultimately going from 50% as fast as Playwright to 80% as fast, is good, but still noticably slower.
- Playwright: This is honestly the only good option for E2E currently. The way it allows you to organize and write tests feels much more modern and cleaner. It's the fastest option, but ultimately it will still be orders of magnitude slower per-test compared to writing unit tests.

Bundling, treeshaking, live-reloading, HMR, etc

Webpack: It's long dead, no one misses it. Technically it is still useful in the sense that it can handle like 5 different JS module systems. But now-a-days if you are using anything other than ESM you are doing it wrong.
Vite: From the creators of Vue.js, the best JS framework, come the best JS Build tool. It is extremely fast, because it only supports ESM. Under the hood much of the underlying tooling has been re-written in Rust to make it as fast as possible. The config tool for it is also pretty straightforward and easy to use. Vitest (mentioned in unit testing) is built on top of it, and uses the same config file, making everything simpler.

Local JS runtimes/package managers

There are options like Bun and Deno, but 99% of people still just use Node.
- Bun uses the same JS engine that Safari does, giving it some cool tricks. Its main purpose is to be as fast as possible. It's VC funded and many are skeptical of its long term utility.
- Deno is from the same person that created Node, but this time "done right". What that means, is your imports can point to URL's, and everytime any module tries to access the file system or make a network call, it has to ask for permission first. This is much more security minded, but also a massive pain in the ass to deal with.
- Both Deno and Bun are basically just "Node, but with TypeScript support". In the sense that they can process TS to JS, or can use .ts files directly without having to process them first. But the latest version of Node can also do this (kinda). When fed a .ts file, Node will now just ignore all the TS syntax (as if they were comments), and execute it as though it were normal JS. Because of this, there's really no one using Bun or Deno, except for rare, specific usecases.
Package managers
- Yarn - Dead, this was around for a few years. It came out with 12 features npm did not have and was much faster than npm. But then npm became faster than Yarn (and still is), and over time all Yarn-specific features got added to npm, so no one bothers to use Yarn anymore, as it does the same thing and is slower. Facebook created it, then handed it over to the OpenJS foundation to maintain it because they were done with it. If you are doing a monorepo (which you probably shouldn't be, but if you are), there are options like npm Workspaces, Lerna, Turbo, and Yarn. They are all basically the same and most people will be fine with npm Workspaces, but each has some unique thing it does the rest don't, so that's really the only thing Yarn is still used for. Some people need its niche monorepo features.
- npm - Basically 100% of people use npm. It's fine, and works well enough.
- pnpm - This does a few things differently, mainly using less disk space than npm, but who cares you have so much disk space, this isn't the 90's. Performance wise, in some cases it is much faster than npm, but not in a way that you care about as a human. The percent of people using it is a rounding error. Its got some niche edge case uses, but most of them are deprecated or recommended not to use by the maintainers.
Volta
- omg you guys, Volta is so fucking good
- Don't install Node or npm yourself, just install Volta
- Put this in your package.json:
```
{
  "volta": {
    "node": "23.11.0",
    "npm": "11.3.0"
  }
}
```
- With this, when you cd into your project, you will already be on the correct Node/npm.
- You can run volta pin node@latest or volta pin npm@latest and it will update the version in your package.json for you. Works on all platforms. Highly recommend.

Styling

Sass
- Sass was used for decades as a simple tool for everyone. Though it was extremely powerful, most of the people using it were just trying to get these main features:
  - Variables and nesting in CSS
  - File modularity and automatic concatenation/minification
- We all use tools like Vite now that handle the concat/minify for us.
- CSS as a language has added in CSS custom properties, which, are much more powerful than "variables", but can also be used as them. It also added in CSS nesting which has wide browser support now too.
- With these common problems solved outside of Sass, its utility has waned. So the maintainers of it pivoted and the new versions of the Sass language are no longer focused on being "an easy tool for everyone to use" and instead are now "a complex and powerful tool for people building large complex CSS systems and frameworks".
- So it doesn't get used much anymore
Bootstrap was for over a decade the go-to solution for "please god, just do CSS for me, I don't want to learn CSS". But it has fallen out of favor, as Tailwind and component libraries have taken its place.
Vue has really good solutions for styling. It has component specific scoped styles, supports Sass, Tailwind, and CSS Modules.

Linting

If you will be working in a project for more than 5 days, you need to set up linting, it will save you so much time and hassle. Any time you say "I don't get it, that should have worked, why doesn't that work", the first thing you should do is run the linter. If you are lucky it will solve your problem in a few seconds and save you 20 minutes of banging your head on the desk looking into why your code doesn't work just to find out you forgot a semi-colon.

ESLint is still the king, nothing else comes close. However, they've recently externalized all their style-based linting to a plugin called Stylistic. There are actually a bunch of really good plugins for ESLint to handle things like organizing ESM imports, accessibility, etc.
- Config Generator - Creates an ESLint config with a bunch of preset (TJW) options to make your life easier, while still giving total control right in the ESLint config file.
- AntFu Config - A JS function you import and run, passing options into. Handles a lot of cases, and offers some control, but not full control. May be too much of an abstraction for some.
Prettier - This is a technology that conflicts with all other technologies including itself. There really isn't anything it can do that ESLint can't do. It has a lot of really dumb default settings that don't match what anyone in the JS ecosystem uses, and most of its settings can't be changed. I seriously can't warn you against this enough, it causes so many problems with other tools. ESLint can auto-fix things on save as well if you want that.
There are several other smaller linting tool alternatives. ALL of which are much faster than ESLint, however, none of them support the insanely large ecosystem of plugins ESLint has, which is really the reason you use it.

Browsers

There's really only 3 browser engines in use now. Everything is either a derivative of Firefox or Chromium, or it's Safari. All Firefox based browsers will use Gecko and Spidermonkey. All Chromium based browsers will use Blink and V8. So you should manually test in at least one browser for each of those, and maybe Safari if you feel like it.

Chromium - There's really only one option, Ungoogled Chromium. Despite there being a bunch of Chromium based browsers, this is the only one that doesn't actively spy on you, or come with a massive amount of preinstalled junk and ads.
Firefox - Sadly, Firefox recently removed all mentions of "we do not sell your data" from their license, website, and legal docs. Which... means they sell your data. Sad times. But fortunately there is Waterfox. Been using it for a while and it's literally just "better Firefox". Doesn't spy on you or sell your data. Has better Tab UI customization. No built in "Try our Mozilla VPN" or any other product ads. Better default settings overall. It's just better.

Kill your darlings

Technologies come and go, new ones fix the problems of the old ones and we move on and evolve. This happens faster on the web than anywhere else, and so we must be vigilant not to get attached. Rip those bandaids off.

The following are my recommendations based on being completely practical and objective, based on the pros/cons of these technologies.

TypeScript is completely replaceable by JSDocs. It has all the same abilities (even enums/tuples), plus more, and none of the downsides. Some people don't like the way TS looks, some don't like the way JSDocs looks. But between the two, you can code-fold the JSDocs comment blocks (Ctrl+K,Ctrl+1) and you don't need to look at them. So even for this non-practical, personal preference, they win out.
Webpack is slow and hard to configure and use. Vite is faster, simpler, and easier to maintain. It has become the recommend approach by all major JS frameworks.
React is so bad that if you use it I will make fun of you, just use anything else. Vue is the obvious winner, but as long as you aren't using React, I really don't care what you are doing instead.
- Except Web components. These never got off the ground. There's no good tooling or options for them and they just flat out don't work in production.
nvm, nodist, n, and nvm-windows are all buggy, and platform specific. Just use Volta, it's cross-platform, stable, reliable, and doesn't require you to manually switch Node versions. You'll never be on the wrong Node version again, it's so good.
Yarn is long past it's prime. npm is faster and can do all the same stuff, and everyone else that switched to Yarn has switched back to npm.
Cypress has been usurped. Playwright is much faster, easier to use, and allows for better code organization and test writing.
There are a lot of unit testing tools (Jasmine, Chai, Ava, Tape, QUnit, etc) and they are all very dated compared to Jest and Vitest. Just use Vite and Vitest together. They use the same config file, so it's much simpler.
Unless you are doing a very complex CSS framework, you're better off moving away from Sass.
Uninstall Prettier from your editor. Disabling it probably won't be enough, it is extremely aggressive about doing it's one job (conflicting with other tools). Get rid of it. Use ESLint, it's worth the extra time to set it up, you'll get more out of it. You can also have multiple ESLint config files if you want to run a subset of your linting options for faster linting of specific folders with unique npm script commands.
It's a good day to switch your browser. Try one that actually respects you.

How to NOT do monorepos

The Jared Wilcurt — Sun, 04 May 2025 05:17:29 +0000

Who actually needs a monorepo?

Monorepos exist to solve the problems that arise when you you have deeply coupled and interconnected projects.

For example, Vue.js has many libraries that depend on it, like Vue-Router, Pinia, Vue-I18N, Vue-DevTools, Vue Test-Utils, etc. So when tweaking the internals of how Vue works, it's important to know that this new version of Vue won't break any of these other libraries, before doing a new Vue release.

Another example is Jest, a unit-testing library. It solves dozens of unique problems around unit testing. And consequently those unique problems have been isolated into their own independent repos solely focused on solving their one problem in a version controlled way, like Snapshot testing for example. These other libraries all live in the same monorepo as Jest to make sure that as each is updated, they all work together happily! Yay!

Why you don't want a monorepo

Though they do solve the problems outlined above they come with some drawbacks. In the past monorepos were notorious for not being able to run on Windows machines. However, with npm Workspaces, this is no longer the case. But if you are using a different monorepo tool (Yarn, Lerna, Turbo, etc). You will have this problem. They just don't play nice on Windows computers. But you don't use Windows, and worse you're a selfish piece of shit that doesn't care about others, so this lack of support doesn't bother you (seriously, just use npm Workspaces, they're good).

The real issue with monorepos is they have a ton of added complexity. It makes sense, you are combining all of the project setup complexity of all other projects into one system. So that requires it to be more complex than any of them would be on their own. Having multiple nested package.json files in a project also can cause issues with 3rd party tooling and editors. It's not always obvious where a dependency should be installed either.

Initial setup of the repo is also much more cumbersome for new devs, as it requires a massive npm install to create a huge shared node_modules.

Abstracting npm scripts across all your repos is more of a pain.

Setting up publishing of all packages at the same time is a benefit but also complex, and results in much uglier and harder to use GitHub Releases pages.

etc. etc. etc.

It's a technology, it has pros and cons, big whoop.

Some projects really do justify the need for this extra effort and hassle, but if you can avoid it, you should try your best to.

You probably don't need a mono repo.

Here's a case where you might think you need one.... but nehhhh you don't.

Let's say you have a component library. You'll need to be able to build this library to a "dist" folder, and publish it to npm (including the package.json).

You'll also need to create a documentation website. As you write a new component, it would be nice to document it as you go, so you can see the component live in the docs site locally and play with it as you build it to make sure it works.

This means that you will be updating the docs site and the component library in the same branch at the same time. Pretty convenient. But the docs site needs it's own build process. So it can create a "site" folder of static assets that gets deployed.

How can we solve this without all of the headache of a monorepo? How can we do this in a simpler way?

Solution

In this scenario the solution is actually pretty easy. Use multiple Vite config files.

vite.config.lib.js
- This config file has all the build options for the /lib folder to create the /dist folder. It also has all the Vitest unit testing options for the component library set up.
vite.config.docs.js
- This config file has all the build options for the /docs folder to create the /site folder. It also has options related to running the server locally for development.
In your package.json you will have different npm Scripts: like:

{
  "scripts": {
    "start": "vite --config vite.config.docs.js",
    "build:docs": "vite build --config vite.config.docs.js",
    "build:lib": "vite build --config vite.config.lib.js",
    "test": "vitest --config vite.config.lib.js"
  }
}

Then you can run npm start to start the docs site, or npm run build to build both the docs site and the library.

Benefits/Drawbacks

This system is dramatically simpler to deal with. It's just a few config files.

However, the downside is you have one package.json for everything, and you'll need to put everything in the "devDependencies" section, unless you want users of your library to receive them when they npm install your library.

Zorin setup

The Jared Wilcurt — Mon, 24 Mar 2025 00:28:31 +0000

General OS Setup

This first section would be applicable to anyone

Remove Firefox because they sell your data
- You can uninstall it from the store, but I don't take chances when it comes to spyware. This is the command to fully remove it:
- sudo apt purge firefox -f
- I think the newer version of Zorin comes with Brave? Which is 10000000% spyware. Easily the worst possible browser you could use. So absolutely remove that shit.
- sudo apt purge brave-browser brave-keyring
- sudo apt autoremove
- sudo rm /etc/apt/sources.list.d/brave-browser-*.list
- rm -rf ~/.config/BraveSoftware
- rm -rf ~/.cache/BraveSoftware
- rm -rf ~/.local/share/keyrings/brave-browser*
Install Waterfox via the store
- It's literally just "Better Firefox"
- Better default settings, no ads built in ("Mozilla VPN", etc)
- Has some fun UI settings, like changing the look of the tabs
- Just go through all the settings and change stuff however you like
- Or you can try Floorp or Ungoogled Chromium. Those are the only 3 browser's I'd recommend that actually respect you, and are easy to use.
Settings > Users > Avatar
Open Zorin Appearance
- Start with the 3rd layout
- Theme: Blue, Dark
- Icons - Dark Reversal Orange
  - https://www.pling.com/p/1340791
- Effects: idk
- Desktop: enable all, standard
- Windows: Centered, Super, Attached, no idea, Right, toggle max, minimize, menu, click to focus, no idea
- Interface: No idea, off, off
Wallpaper
- https://i.imgur.com/rSxpVtb.jpeg
Taskbar settings
- Style: intellihide off, override on, 70, dynamic on (all windows, 100)
- Position: Apply to all mon, bottom, 48, 100, left. All visible except Show Apps Button.
- Behavior: all checked, ungrouped (160, off, off), preview (on, 200, on)
- Action: no clue, keep orig: off
If you want to set some programs to launch on start up install "Ignition" from the store.
sudo apt update && sudo apt install tts-mscorefonts-installer
- This gives you common Windows fonts, only needed for software that expects you to have them, like some Windows programs.
Disable multi-touch gestures, like pinch/zoom or 3-finger-swipe to show all windows. It keeps 2 finger scroll, and 3 finger middle-click.
- https://extensions.gnome.org/extension/8066/disable-gestures-wayland/
Unfortunately NO operating systems give you control over how rounded the corners are on the windows. However, this is Linux, so if you want something done, you can just do it yourself.
- Create ~/.config/gtk-3.0/gtk.css and put this in it:
- * { border-radius: 4px; } decoration, window { border-radius: 0px; }
Install ArcMenu to replace the start menu
- This is a fork of ZorinMenu that better recreates the Windows start menu
- https://extensions.gnome.org/extension/3628/arcmenu/
- Use this settings file, tjw-arc-menu

[/]
arcmenu-extra-categories-links=[(0, true), (1, false), (2, false), (3, false), (4, false)]
arcmenu-extra-categories-links-location='Top'
avatar-style='Square'
context-menu-shortcuts=[['ArcMenu Settings', '/home/owner/.local/share/gnome-shell/extensions/arcmenu@arcmenu.com/icons/arcmenu-logo-symbolic.svg', 'ArcMenu_Settings'], ['Panel Extension Settings', 'application-x-addon-symbolic', 'ArcMenu_PanelExtensionSettings'], ['Separator', 'list-remove-symbolic', 'ArcMenu_Separator'], ['Power Options', 'system-shutdown-symbolic', 'ArcMenu_PowerOptions'], ['Show Desktop', 'computer-symbolic', 'ArcMenu_ShowDesktop']]
custom-menu-button-icon-size=34.0
default-menu-view='Frequent_Apps'
disable-scrollview-fade-effect=true
disable-user-avatar=false
distro-icon=17
enable-horizontal-flip=false
enable-standlone-runner-menu=false
extra-categories=[(3, true), (1, true), (0, false), (4, true), (2, true)]
hide-overview-on-startup=false
menu-background-color='rgb(30,37,41)'
menu-border-color='rgb(42,52,57)'
menu-border-radius=0
menu-button-appearance='Icon'
menu-button-icon='Distro_Icon'
menu-foreground-color='rgb(189,230,251)'
menu-item-active-bg-color='rgba(189,230,251,0.15)'
menu-item-active-fg-color='rgb(189,230,251)'
menu-item-hover-bg-color='rgba(189,230,251,0.08)'
menu-item-hover-fg-color='rgb(189,230,251)'
menu-item-icon-size='Extralarge'
menu-layout='Default'
menu-separator-color='rgba(99,99,98,0.56)'
menu-themes=[['ArcMenu Style', 'rgba(48,48,49,0.98)', 'rgb(223,223,223)', 'rgb(60,60,60)', '1', '14', '11', 'rgba(255,255,255,0.1)', 'rgb(21,83,158)', 'rgb(255,255,255)', 'rgb(25,98,163)', 'rgb(255,255,255)'], ['Simply Dark', 'rgba(28,28,28,0.98)', 'rgb(211,218,227)', 'rgb(63,62,64)', '1', '14', '11', 'rgb(63,62,64)', 'rgba(238,238,236,0.08)', 'rgb(255,255,255)', 'rgba(228,228,226,0.15)', 'rgb(255,255,255)'], ['Dark Blue', 'rgb(30,37,41)', 'rgb(189,230,251)', 'rgb(41,50,55)', '1', '14', '11', 'rgba(99,99,98,0.56)', 'rgba(189,230,251,0.08)', 'rgb(189,230,251)', 'rgba(189,230,251,0.15)', 'rgb(189,230,251)'], ['Light Blue', 'rgb(245,247,250)', 'rgb(18,51,84)', 'rgba(18,51,84,0.2)', '1', '14', '11', 'rgba(18,51,84,0.15)', 'rgba(18,51,84,0.08)', 'rgb(18,51,84)', 'rgba(18,51,84,0.15)', 'rgb(18,51,84)'], ['TJW-Zorin', 'rgb(30,37,41)', 'rgb(189,230,251)', 'rgb(42,52,57)', '1', '0', '11', 'rgba(99,99,98,0.56)', 'rgba(189,230,251,0.08)', 'rgb(189,230,251)', 'rgba(189,230,251,0.15)', 'rgb(189,230,251)']]
multi-monitor=true
override-menu-theme=true
pinned-app-list=['Files', 'org.gnome.Nautilus', 'org.gnome.Nautilus.desktop', 'Terminal', 'org.gnome.Terminal', 'org.gnome.Terminal.desktop', 'ArcMenu Settings', '/home/owner/.local/share/gnome-shell/extensions/arcmenu@arcmenu.com/icons/arcmenu-logo-symbolic.svg', 'gnome-extensions prefs arcmenu@arcmenu.com', 'Git Cola', '', 'com.github.git_cola.git-cola.desktop']
pop-folders-data={'Library Home': 'Library Home', 'Utilities': 'Utilities'}
prefs-visible-page=0
search-entry-border-radius=(true, 25)
searchbar-default-top-location='Bottom'
show-activities-button=false
show-hidden-recent-files=true
vert-separator=true
windows-disable-frequent-apps=false
windows-disable-pinned-apps=false

Developer stuff

The rest of this is my setup for programming related things.

Install VSCodium via store even though you'll never use it

Install Sublime via .deb file from website

https://www.sublimetext.com/download
Preferences > Keybindings

[
  {
    "keys": ["ctrl+tab"],
    "command": "next_view"
  },
  {
    "keys": ["ctrl+shift+tab"],
    "command": "prev_view"
  },
  {
    "keys": ["ctrl+alt+up"],
    "command": "select_lines",
    "args": {
      "forward": false
    }
  },
  {
    "keys": ["ctrl+alt+down"],
    "command": "select_lines",
    "args": {
      "forward": true
    }
  }
]

Install git cola from the store
Tweak terminal colors
Add "\C-i": menu-complete to ~/.inputrc
Git stuff:
- Auto fix git push needing upstream set
  - git config --global push.default current
- git config --global user.email "TheJaredWilcurt@users.noreply.github.com"
- git config --global user.name "The Jared Wilcurt"
- Create SSH key file, run this, enter > enter > enter
  - ssh-keygen -t ed25519 -C "TheJaredWilcurt@users.noreply.github.com"
- Start SSH Agent
  - eval "$(ssh-agent -s)"
- Add SSH keys
  - ssh-add ~/.ssh/id_ed25519
- Run this and copy the output to clipboard
  - cat ~/.ssh/id_ed25519.pub
- https://github.com/settings/ssh
  - New SSH > Title, Type: Auth, Key: paste > Add SSH Key
Install dconf-editor from the store
- org/gnome/desktop/wm/keybindings/move-to-workspace-up
- org/gnome/desktop/wm/keybindings/move-to-workspace-down
- Remove the keybinding from both of these, so Sublime can use ctrl+alt+up/down.
To get Ctrl+Tab and Ctrl+Shift+Tab to work in the terminal:
- gsettings set org.gnome.Terminal.Legacy.Keybindings:/org/gnome/terminal/legacy/keybindings/ next-tab '<Primary>Tab'
- gsettings set org.gnome.Terminal.Legacy.Keybindings:/org/gnome/terminal/legacy/keybindings/ prev-tab '<Primary><Shift>Tab'

Desktop apps for Windows XP in 2025

The Jared Wilcurt — Mon, 10 Feb 2025 21:38:16 +0000

Intro

Inspired by the Action Retro YouTube channel trying to get Spotify to run on Windows XP, I thought I'd share a quick walk through of using NW.js for Windows XP development.

NW.js is a modified Chromium browser with Node.js built in. It has an older "Long Term Support" (LTS) release (v0.14.7) that supports "Legacy Operating Systems", like Windows XP and OSX 10.6.

However, it is pretty old at this point and has some caveats. But we'll get there.

Boot up XP

First off I'm going to boot up my old Win Pro SP3 virtual machine. I'd recommend setting up your own, there are guides online for that, or just using real hardware.

Download NW.js

Go to this archive for version 0.14.7:

http://dl.nwjs.io/v0.14.7

I'll explain the different flavors:

"nwjs-sdk-symbol*" and "nwjs-symbol*" files are for advanced use cases, you won't need these.
"nwjs-sdk-v0.14.7*" Is NW.js with Chromium dev tools built in
"nwjs-v0.14.7*" Is the same thing, just without the dev tools, so it is slightly smaller. This is for distribution to end users
Then they'll have the operating system (win, lin, osx)
And then the architecture, 32-Bit (ia32) and 64-Bit (x64)

I assume you'll want nwjs-sdk-v0.14.7-win-ia32.zip. But if you plan on distributing this for others to download, they probably won't need the dev tools, so you can use the slightly smaller version for them.

The 32-bit version will run on both 32 and 64-bit versions of Windows just fine. It will also run on XP, Vista, 7, 8, 8.1, 10, 11, and 12, and likely anything else in the future as Microsoft has always prioritized backwards compatibility. But who knows, 11 and 12 are so bad I wouldn't be surprised at what they do anymore. Honestly, having to use 11 so much recently and then booting up this XP VM is just pissing me off at much better XP is.

Setting it up

You downloaded a zip file, good job! You should be able to open it and drag the folder out to your desktop or wherever. Feel free to rename the folder from "nwjs-sdk-v0.14.7-win-ia32" to "MyApp" or whatever.

Inside the folder is all the files NW.js needs to run, it doesn't need installed, it works sort of like a portable app. So you can just double-click on nw.exe to see a window pop up, then you can close the window.

The nw.exe file can be renamed to whatever you want, MyApp.exe for example, and you can even use a tool like ResourceHacker to edit it and change the icon to any ICO file you want. You can grab a random ICO file from the IconArchive website, or use a tool like Greenfish Icon Editor to convert any image file to an ICO. All of that runs fine on Windows XP+.

Creating an app

Inside your "MyApp" folder, create a new folder called package.nw. All of your code and files will live inside this folder. Which makes it easy to copy it around to other versions of NW.js later. As long as the package.nw folder is next to the nw.exe (or whatever you renamed it to), it will work.

Then, inside the package.nw folder create a package.json file. This is the first thing the nw.exe file will look for when it launches. It tells it what to do next. Inside the file there are only 2 required fields so we'll start with those:

name - This is the name of your app. It is required because any time you open NW.js, Chromium will control showing a window, and Chromium needs to make a bunch of user-specific files. So for Windows XP that would be at C:\Documents and Settings\YourUserName\Local Settings\Application Data\my-app. The "my-app" part is whatever you put in this name field. It must be a url and file-system safe name. I'd recommend all lowercase and hyphens instead of spaces.
main - This tells NW.js what to load in the window when it launches. Usually you'd set it to index.html and then create that file and put whatever you want in it to make your app. However you can also set it to a URL, so we'll start there, as it will show an XP specific problem we'll need to solve.

MyApp\package.nw\package.json

{
  "name": "my-app",
  "main": "https://google.com"
}

With that in place, now when you run nw.exe, it will open a window and take you to Google.com. Or at least, that's what it would do, but instead you'll see this:

Chromium dropped support for XP a long time ago. So we must use a very old version that still works with XP. However, the certificate it ships with is now long expired.

We can work around this by adding one more item to the package.json file:

{
  "name": "my-app",
  "main": "https://google.com",
  "chromium-args": "--ignore-certificate-errors"
}

Save that, and re-run nw.exe and now it should launch a window with Google loaded inside it.

There are a bunch of other settings you can put in the package.json, including adjusting the starting window size and position. More information can be found in the docs:

https://nwjs.readthedocs.io/en/latest/References/Manifest%20Format/

Version stuff

At this point you can make whatever you want. Well kind of. NW.js v0.14.7 was released on 2016-07-22 and comes with Chromium 50 and Node.js 5.11.1. Both of these are very old now. If you are used to modern webdev tooling, writing code for them will be more difficult.

Fortunately we have tools like PostCSS and Babel, that let you target your specific Browser version, and they'll do their best to transpile and polyfill your code to work with that version. This alone will do a lot of the heavy lifting for you if you are working with a lot of code. However, if you are just writing out a few HTML, CSS, and JS files, then that would be overkill and you can just figure out what code to use by consulting CanIUse.com.

Be aware, that many new web technologies have been added to the browser since 2016. Some specific websites, may not load. For example, using "main": "https://spotify.com" will load their site, but it will tell you that your browser doesn't support Widevine. Widevine is a DRM technology they use for playing audio files that wasn't added into Chromium until years after they dropped support for XP. So sadly, you can't just point to any website and expect it to work. Though, most sites actually still work with this older version of Chromium, overtime more and more will adopt new technologies not available in this old version of Chromium. The march of progress is sad for our friend XP. Fortunately, for just browsing the web MyPal, an XP focused fork of Firefox, is available.

Your own app

In the example above we just loaded a website, but as mentioned, you can also create your own apps from scratch. Let's do a quick example.

MyApp\package.nw\package.json

{
  "name": "my-app",
  "main": "index.html",
  "chromium-args": "--ignore-certificate-errors"
}

MyApp\package.nw\index.html

<!DOCTYPE html>
<html>
  <head>
    <title>My App</title>
    <style>
      body {
        background: #334;
        color: #DDE;
        font-family: sans-serif;
      }
    </style>
  </head>
  <body>
    <h1>Hello World</h1>
    <div id="example"></div>
    <script>
      const fs = require('fs');
      const files = fs.readdirSync('.');
      document.getElementById('example').innerText = files.join(', ');
    </script>
  </body>
</html>

In this example code we are:

Styling the app with CSS
Setting the window title with the <title> tag
Use Node.js's require function to access the computer's File System (fs)
Using fs to get a list of all the items in the current directory (.)
Targeting an element in the DOM by ID and updating its inner text value to be the list of comma-separated files.

You will be able to use any of the built-in Node modules, or any 3rd party modules you would npm install that are compatible with Node.js v5.11.1 (basically stuff from around 2013-2017).

But just using the built-ins alone, you have access to the hardware (CPU, memory, etc), file system (Read/Write/Create/Delete files), executables (child processes, spawns, forks), and more.

The cool part is, if your app code doesn't use any windows specific code (like calling powershell or something), then it will be possible to ship your app on Linux and OSX too!

Installing Node

Installing Node.js on your machine is not a requirement for using NW.js. If you want to use 3rd party Node modules, you will need to install them via the "Node Package Manager", or npm. Node.js comes with npm when installed. Most likely all you'll need to do is download and run this installer:

https://nodejs.org/dist/v5.11.1/node-v5.11.1-x86.msi

Run it to globally install the same version of Node.js (5.11.1) that is built in to NW.js (0.14.7). You'll run into less issues if they match.

If you have issues installing Node, you can look into the other Node downloads for that version:

https://nodejs.org/dist/v5.11.1/

Or you can try Volta. Which I've gotten to work on XP in the past, but don't know how. Volta is a Node version manager that works on all platforms and is really great.

Also, depending on the updates you've done to your XP machine, you may be on an older version of "Windows Installer". You can check by running msiexec to see the version. If you want to install version 4.5, just go to Microsoft's website and, ha ha, just kidding, that will take you to a 404 page. So instead, go to The Internet Archive to get the update. Then donate to them.

Distributing your app

When you are ready to share your app with other cool XP users, just zip up your MyApp folder and send it to them. It's that easy. Then they just unzip it and double click on the nw.exe (which you probably renamed). Or you can download the non-sdk version of NW.js and move your package.nw folder over to get a slightly smaller file size. Then zip and ship it.

There are other options too. Another one is to use WinRAR to create a self-extracting executable (look up a tutorial). That will make a small installer file for your app.

Conclusion

Have fun making apps!

Check out NW Utils for additional NW.js resources (libraries, tutorials, boilerplates, examples, etc).

Here's an old XP compatible NW.js framework for making GUIs for CLI's:

UGUI: Universal Graphical User Interface

TS is bad at hover text

The Jared Wilcurt — Wed, 08 Jan 2025 04:53:01 +0000

A literal angel (AngelCMHxD), made a PR against one of my repos to add a .d.ts definition file for both auto-complete, and hover text. This is what happened next...

After testing his PR locally with the TypeScript .d.ts file, the result was this:

Note that I'm hovering over the windows key and it is not giving me any valuable information. It provides the same truncated mess of text (that is hard to visually parse), as when you hover over createDesktopShortcuts.

The repo was already written with JSDocs enforced everywhere via a simple linting plugin (use it, it's very good). In comparison, JSDocs provides identical type support as what TS does, and far better hints.

With JSDocs, we get a cleaner hover:

And on hover of the windows key, we get much better context, explaining that it requires a filePath string.

Ultimately, there was no way to get TS to generate a usable hover tooltip. Their official recommendation is to use JSDocs.

Because the TypeScript Engine and Compiler work exactly the same with types defined in JSDocs as they do with types written in the TypeScript syntax, my library does not use any TypeScript at all, but is fully typed and fully TS compatible.

Primary Responsibilities of UI Architects

The Jared Wilcurt — Tue, 03 Dec 2024 18:39:50 +0000

UI Architects are developers that deeply specialize in all things related to frontend. They should have expertise in JavaScript, its frameworks & tooling, as well as software patterns. They can build anything with pixel perfect accuracy in HTML & CSS in a clean, semantic, and accessible manner. They should be deeply familiar with all the different approaches for how to organize and handle large/complex CSS. They may be called upon to help with a specific team, or work on code that can be used across teams. They're familiar with UX patterns and terminology and can work and communicate with UX Researchers, Designers and Developers, and act as bridge between them. They tend to work across teams and disciplines.

Below we outline the core responsibilities of people in this role.

Code

UI Architects are expected to write and work on code, primarily used across teams within an organization. This includes libraries (CSS libraries, component libraries, utilities), tooling (linting, testing, building, documenting, deploying, etc), boilerplates, open source contributions to resolve 3rd-party issues, and more. The product of these efforts results in speeding up development, improving the developer experience, reducing rework across teams, and leads to an overall more consistent user experience.

Besides shared code, UI Architects may be pulled in to help with code specific to a single project or team. Such as rare events that members of the team may not feel comfortable doing as it is outside of their day-to-day work. Work that requires niche and rarely useful knowledge, not worth training others on. Or work with a much higher than normal level of complexity. Examples include setting up a repo for the first time, updating dependencies in old repos, code migrations, automating tasks, CI/CD/deployments, advanced optimization techniques, etc.

Consultation

UI Architects must be extremely knowledgeable in all things related to frontend development. They should be seen as a resource who assists in solving problems when others are stuck, gives advice or direction, and explains concepts or niche aspects of UI work.

A team may need help planning out large projects like migrating a code base between technologies (build tools, testing frameworks, frontend frameworks, state management libraries, etc). They may want counsel and recommendations around adopting a technology that is new to the team. UI Architects should be able to speak from experience, but also in an unbiased way, pointing out the situations that make technologies most useful, and the pros and cons of any potential technology choice, pattern, or approach.

Having this expertise internally also allows giving context of what internal resources exist for a choice that would make it more beneficial to adopt. Internal resources may be preexisting libraries compatible with the choice, or experts within the organization that could be tapped for assistance in the future.

A UI Architect should contrast choices to similar alternatives. Ultimately this is guidance, not rules. Teams can use this summarized information to make the decisions they believe are best for their team and the project. Even if it is differs from what the Architect would have chosen, or what other teams have chosen. Teams choosing to go in a new direction will have a harder time, but also are more likely to innovate, and may be trailblazers to allow others in the organization to follow in their steps.

Communication/Context

Part of the role of a UI Architect is to be a bridge between UI, UX, and PM roles. They should champion the needs of developers to designers, while also explaining the reasoning behind designs to developers, when a different approach is needed.

They provide and convey the context in either scenario so that the right corners are cut to make a deadline, or so that the same user outcome can be reached with a different design that could be developed in less time. They don't need to be an expert in User Experience Design/Research, but they should be able to speak the language of those in the UX field. Being able to effectively communicate with Project/Product managers, UX Designers, and Frontend developers is key to being this bridge. Understanding the goals of each of these groups and helping to balance them and find solutions with the fewest compromises, and where expectations are managed realistically.

The difference between UI Architects and UX Architects

There is a lot of overlap between these roles. While both have technical frontend expertise, a UX Architect will work closely with UX Designers and UX Researchers. Where as a UI Architect primarily works with Frontend and Full Stack Developers. UIA will tend to have more software and library development experience. UXA will have more design and UX experience. But this isn’t a clear and defined line that both fall on opposite sides of. It can often be fuzzy and the requirements put on those in these roles are very dependent on the organization they are in.

Photo Credit:
Smolensk fortress wall by Anastasiya Romanova

Windows 11 unsuckifying guide

The Jared Wilcurt — Wed, 26 Jun 2024 17:53:32 +0000

Here's an incomplete list of tips, tools, and settings to help make Windows 11 suck less.

Biggest pro-tip: If you are installing Windows 11 fresh, use English-Global instead of English US. This skips installing TikTok, Disney+, LinkedIn, Spotify, etc paid-promotional links everywhere. Also turns off MS Store by default until you set your region to EN-US (if you want to re-enable it).

It is technically possible to create a Win 11 user account without a Microsoft account, but you'll need to look it up as MS keeps trying to make this harder.

Go through every single setting on the OS and turn off all the bullshit, spyware, AI, etc.
Settings > Accessibility > Visual Effects
- Always show Scrollbars (why the fuck is this disabled by default)
Settings > Accessibility > Keyboard
- Sticky/Filter/Toggle Keys: OFF
- Underline Access Keys: ON
- Print Screen opens a stupid fucking program instead of doing print screen: OFF
Settings > System > Multitasking > Snap Windows:
- Turn off "Show Snap layouts when I hover over a Window's Maximize button"
- Turn off "Show snap layouts when I drag a window to the top of my screen"
Constantly leave feedback as you try to do common basic shit and Windows just sucks now and has no option to make it unsuck
- Example: https://old.reddit.com/r/Windows11/comments/s3f2y9/please_separate_calendar_and_notifications/
RegEdit: Make Scrollbars wider
- HKCU\Control Panel\Desktop\WindowMetrics
- Double click ScrollHeight and ScrollWidth
- Enter a value between -120 (thinner) to -1500 (thicker) and click OK. (-255 is probably fine)
- Restart to apply.
RegEdit: Stop taskbar app label widths from fluctuating constantly
- For some stupid reason, the width of apps in the taskbar expands and contracts as the title of the window changes, causing one app to shift the position of all other apps that come after it in the taskbar. Happens a lot when running commands that chain other commands (like npm t).
- There are two solutions, neither seemed to work for me. Regedit and WindHawk
- HKCU\Control Panel\Desktop\WindowMetrics
- Right-click blank space > New String
- Name: MinWidth
- Value: 38
- WindHawk - Note: Because WindHawk does code injection, it can be seen as malicious by some protection software. It isn't, but my work computer really doesn't like it.
- https://github.com/ramensoftware/windhawk/releases/latest
RegEdit: Stop sending start menu searches to Bing's servers
- HKCU\SOFTWARE\Policies\Microsoft\Windows
- Right-Click Windows > New > Key > Explorer
- Right-Click Explorer > New > DWORD32 > DisableSearchBoxSuggestions
- Double-Click DisableSearchBoxSuggestions > 1 (Hex) > OK
- Restart Explorer or computer to apply
Replace the start menu which is filled with ads and widget bullshit
- Replace Windows 11 logo with Windows 7 logo
RegEdit: Bring back the original right click menu
- Run reg.exe add "HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32" /f /ve
- Restart Explorer or computer to apply
Turn off rounded corners on every window
- IMPORTANT: Make sure only one dwm.exe is running before executing. Do not run this remotely, run it on the actual machine.
- NOTE: Unfortunately, after every Windows update, this gets reset on reboot. So you have to re-run this, but because it creates a backup file, it won't re-run until you delete the backup located at: C:\Windows\System32\uDWM_win11drc.bak.
Make any window resizable. Hey my Outlook notifications are in a tiny window that I can't resize and the buttons to dismiss notifications are so far to the right, they aren't visible. Guess I'll have to download a random tool to make the window resizable to have access to these buttons. Thanks Microsoft Windows 11, thanks Microsoft Outlook. Real cool.
Install MSEdgeRedirect to have News, Search, Widgets, Weather and more use your default browser instead of MS Edge.
Chris Titus Win Util (Win 11 Debloating/Spam removal)
- This utility does a TON of things, be very careful and read everything before applying changes as many settings it offers are bonkers and it even warns you not to do them. But it also does a ton of very useful things.
- Intro Video for it
The notification sounds on W11 might as well not exist, they are so soft and quiet and barely noticeable even when you are right in front of the computer, let alone in the other room when you want to hear the sounds.
- Download a sound pack: https://winsounds.com
- Go to Settings > Sound > More sound Settings > Sounds
- Select each sound in the list, click Test to hear it, then replace it with your downloaded sounds.
- When done, save your scheme

Alternatively you could just do this:

Install Zorin OS instead of Windows.
Install the "ArcMenu" Gnome Extension to get a more Windows-like start menu
That's it. It works fine, it's the closest thing you'll get to Windows 7 that isn't Windows 7. It even runs some Windows programs perfectly fine just by double-clicking them.
"Wait, did you just trick me into using... Linux, gross." Yes I did. I hate Linux too, but with how bad Win11 is, Zorin is legitimately better. No AI bullshit, no spyware, fully customizable. etc.
I've not had to use the commandline at all on Linux. That bullshit is in the past, modern Linux is finally usable by actual humans. Or at least Zorin is.
Here is my personal Zorin settings, but you really don't need it, you can just play with the settings yourself.