DEV Community: James Robert Lund III

It took me a long time to settle on a "good" note taking system. See what I have to say!

James Robert Lund III — Mon, 14 Apr 2025 12:57:17 +0000

James Robert Lund III

Apr 13 '25

✍🏼 How I Take Notes As A Dev

#softwaredevelopment #documentation #webdev #excalidraw

Comments 1

3 min read

✍🏼 How I Take Notes As A Dev

James Robert Lund III — Sun, 13 Apr 2025 15:50:01 +0000

TL;DR I now use these things:
Obsidian
Obsidian Excalidraw Plugin
Obsidian Git Plugin

My full config 👉🏼 Obsidian Config

How we got here

I think every dev is on the lookout for a better way to organize notes and convey their ideas. Each dev has their own way of writing notes and staying organized which is totally fine. This article talks about what works for me and if it works for you, awesome! 🎉

Let's get into the tools I've used and where I ended up. I was using Excalidraw on the daily.

Excalidraw is a great tool for making diagrams. However, I wanted to save diagrams and access them on any machine I needed to. This was a problem because I needed to make sure these files were up to date and backed up on a cloud.

So I needed a cloud... 🤔 why not use git and host these files on GitHub? It's free and I can access my stuff on any device that has Git. So off I went, saving notes to a folder on my computer and backing changes up to Git. The only issue is I had to manually back stuff up.

Wouldn't it be good to backup when I saved a file?

That got me looking into a smarter notes app, something that could automatically back up to a cloud, work on different operating systems, and something that allowed me to own my data.

Things I've Tried

I tried using the notes app on MacOS but that's not compatible on other machines I use. Especially Ubuntu 🐧

I've tried using evernote but it seemed like too much noise for what I needed.

I tried using anydo which worked for awhile and has support for multiple platforms but I needed something richer than a TODO app. Something that let me create diagrams and have control over my data.

My Current Solution 💡

It's not for everyone, but over the past year I've really enjoyed using Obsidian. I have it configured to backup my notes on save and push to a remote git repo.

This perfectly satisfies my fulfillment criteria:
1. Cloud-based backups
2. Automatic backup on save
3. Excalidraw support
4. Community support
5. Owning my data
6. Accessing notes between machines

I don't want to reinvent the wheel, so if you're interested, please checkout this video. It'll get you the majority of the way there.

Outside of that, let's talk plugins.

🔌 Bridging The Gap With Plugins

In addition to the git plugin, I also installed Excalidraw, advanced canvas, CSV table, and emojis.

This works for me since I'm used to Excalidraw, now I get to have my notes in 1 place! 🎉

👇🏼 Example of a simple user form in excalidraw.

I also get to read CSV outputs and leave comments on them (super useful for back-end work I do).

The Canvas plugin lets me style my canvas'. This might be a bit redundant since I have the Excalidraw plugin too but it's good for linking to in-depth notes on an ERD (entity relationship diagram).

I'll add more as time goes on but this works for me now 🙂

✅ Closing Out

That's it!

Would you try Obsidian? Are their any plugins you think I should try? Let me know in the comments below!

Thanks for reading!

Obsidian Config

Photo by Jez Timms on Unsplash

Taking a short hiatus

James Robert Lund III — Mon, 13 May 2024 18:27:13 +0000

Hey all!

Thank you for the love and support over the past year. I wasn't expecting to get this much out of dev.to but certainly glad I started 😄

I'm gonna take a break for a few months. There's a personal project I wanna focus on instead of writing articles. I'm sure I'll write some on the project once it's in a MVP stage. It'll be open source too! I really hope you try it out!

Thanks again for the support over the past year, until we meet again ✌️

James

Reflecting On My Programming Career

James Robert Lund III — Tue, 23 Apr 2024 13:48:20 +0000

It's been a long 5 years.

5 years of stand-ups, posture issues, fixing staging and production sites, and code, so much code. It's hard to imagine that it's been that long, it seems like ages ago.

From starting my career as a back-end Python engineer working on healthcare websites to building full-stack applications with Typescript, I've seen a few things and led myself astray along the way.

One of the ways I disadvantaged myself was to be a "yes man".

🚨 Spoiler Alert - don't do that.

I took any opportunity I could to prove myself and advance my career. Build my skills and keep my clients happy. I wanted to be known as a competent engineer. I wanted people to want me on their team. I wanted attention and to be recognized for my efforts, no matter what.

I would work extra hours during the day or weekends to keep people happy. Anyone besides myself or my family.

Stretching myself like this would only get me so far. I voluntarily did this to make my clients happy or to make up for a fumble I had during a meeting earlier in the week. I felt like I owed someone something.

As long as my clients were happy, I was happy. Or at least that's what I told myself for years.

😬 Yikes

I was becoming the person I set out NOT to be, the workaholic programmer who only made time for work. Work work work. A cog in the machine that only stops to rest.

I didn't stop and think about the negative impact my workaholic tendencies would have on my mental health and family. They craved more attention from me. Attention that I denied them so I could focus on developing the skills I thought I needed for the future.

I was right on some of the skills and wrong on others. Let me explain.

Things I didn't need:

Google Cloud Certifications
Saying yes to all demands
Influencer trends (Rust, Flutter, AlpineJS, RedwoodJs, etc)

Google Cloud Certifications

Looking back, I feel like this wasn't the move. I was studying to earn a Google Developer certification to show to companies that I knew Google Cloud. What does that even mean? Knowing "Google Cloud" is a HUGE goal for anyone to learn (same goes for Azure, AWS, etc), I didn't set the right expectations for myself.

A better use of my time would've been to better understand the exact features of GCC that would've benefited my projects. At the time, I was using Firebase on every project to speed up development. Learning more about GC Cloud Functions, App Engine, Storage, and IAM would've pushed me further in my career besides just knowing the basics.

Couldn't the cert help me with those things? Yes, but it probably was overkill.

Saying Yes

This was my biggest mistake.

I was eager to prove myself and fearful of letting people down. I wouldn't turn someone down because it was an opportunity for me to learn and get more experience.

It was easy for me to feel like this was progressing my career but it lead to sooner burnout. That sooner burnout hindered my performance and my drive to learn.

Influencer Trends

There's new technologies coming out all the time and I felt like it was my responsibility to keep up with the trends. There's some truth to that but I was a bit starry-eyed thinking I should learn everything tech-bros were talking about.

Is it okay to try new things? Absolutely.

Is it okay to force yourself to try new things when you should be around those who care about you? For me, no.

The reality was that I just needed to stick with the things that employers were looking for. For my specific line of work, this would mostly be React, React Native, JS/TS, Firebase, HTML, CSS, etc. A framework, a language, and the tools to build full stack apps.

That's what helped me get the positions I was in, understanding tools and having the skills that employers were looking for.

In my experience, employers weren't looking for a full-stack dev that had a Google Cloud certification or knowledge of Rust. They were looking for someone who knew one of the big three front-end frameworks (React, Angular, Vue) and could write nodejs code. Also someone who could adapt to older/different codebases than current standards.

At the times I was applying for new opportunities, I never saw positions that were looking for Svelte, Rust, RedwoodJs, etc experience. Mainly full-stack positions that asked if you could provide value with knowing more common technologies.

Rust is a neat language but it doesn't have much use for me in my area of webdev. I typically work on full-stack apps that use Typescript. Typically a CMS or CMS-like back-end and React front-end. Why should I learn Rust?

It's not like I was building CLI tools or infrastructure to support my web apps, I just thought Rust was cool. I thought it would give me an edge.

And let me stop for a moment, there is nothing wrong with learning new things. There is nothing wrong with learning Rust or anything on this list. My point is I was forcing myself to learn something that I didn't need to learn. I thought I was advancing my career but I was just holding myself back by not investing my time into the things that companies would want me to do (mostly front-end stuff at this time).

What actually gave me energy to continue learning wasn't to force myself to learn, it was to spend more time with my family and recharge. After all, the point of me working so much was to have more family time by being better at my job, wasn't it?

But that's enough of the negative, let's focus on the things that pushed me along my career.

Things that helped me:

Communication
Typescript/Javascript
CSS/HTML etc
Saying no
Establishing boundaries
Learning to protect those boundaries

Communication

To most of you, this is a no-brainer, but I learned it the hard way. Instead of communicating my hiccups to my team, I'd silently iron all bugs in my way. "I can fix anything!" I'd say to myself, not considering that I could save time by pair programming with someone else.

What happens when you can't fix something and your deadline is coming up? Panic.

What happens when you can't fix something, your deadline is coming up, and you leverage your team? More often than not, the team will help you get out of your situation. Either by helping you get unstuck, developing the work with you, or communicating with the client that we should push back the deadline.

Typescript/Javascript

Another no-brainer for those who work in webdev. Looking back, I wish I focused on Typescript a lot sooner. I'd have more experience and would have more job opportunities. Most places are asking for TS experience these days.

I'd also grow faster. If I implemented TS sooner, more of my legacy projects would be more maintainable because my code would've been more intentional with its data flow.

CSS/HTML

If you work front-end, you need to know these. I was decent at it but for most of my career I'd use divs for everything. Who cares about SEO or accessibility anyway? Yeah, totally not my attitude these days.

Saying no

If you're having a hard time, this might be your skeleton key. Learning to say no and protecting my boundaries was a game changer!

When I learned how to protect my boundaries, I was able to properly set expectations with my team. Expectations that were manageable led me to get more sleep, keep work at work, generally feel less stressed, and not feel burnt out as quickly.

You have to swallow your pride to do this. Accept that you can't do everything and you should leverage your team when you need them. They're there to help you, as you are to them.

These things actually helped me progress in my career. The cool thing was they didn't take much time outside of work. They're mostly day-to-day things that made my life easier. And with my life easier, I was able to make more time for my family.

What also helps motivate me is having a sense of community. Something outside of my job that connects me with others who feel the same way I do. For me, there's a non-profit organization called GRWebDev that hosts events in my local area.

Maybe there's an org like that around you too ☺️

Thanks for reading! If you liked this post please give it a heart or another emoji. Did this post help you manage learning and your mental health? Or do you have some tips from your personal journey? Let me know in the comments below!

🐺 REST APIs with Elysia.js 🌿

James Robert Lund III — Mon, 25 Mar 2024 12:56:53 +0000

Hey API Dev, tired of building express apps that don't perform well under high loads? Want something that feels a bit cleaner and modern to build your next multi-million dollar project?

You may have heard of Bun, the newest JS runtime before, but have you heard of an ergonomic developer-friendly API framework that uses Bun?

If not, this article is for you 🎉

There's a few contenders out there but the one that really stood out to me is Elysia.

What is Elysia?

Elysia is a HTTP API framework written on Bun with developer experience being the main motivation of the framework.

Essentially, a faster Express.js replacement.

Elysia is set up for you to write functions and returns for your API. Need to send a response to the client? Just return your data in the callback function. No need to rely on req/res explicitly.

A basic Elysia endpoint could look like this:

Which will return a 200 and the string Test inside the response body.

The implementation syntax looks similar to express but cleaner, in my opinion.

Elysia Paths

You can leverage all the regular HTTP Methods and also add your own:

Or if you don't care about the method, you can use .all instead of .get .post etc.

You can also handle 404 errors like so:

Need dynamic paths? No worries:

Need multiple dynamic variables on an endpoint? They got you:

What about wildcards? Don't worry about it:

As you can see, Elysia has a lot of power baked in. But what about returning data?

Elysia's Handler Function

Those callbacks you saw in the code-snippets are the "handler". A handler is a callback function as the second argument in an endpoint. As you saw, we can extract params, path, and the request context by destructuring the request object:

The request object isn't lost to us tho. To alter request headers or redirects, we can leverage set like so:

More info on request context here.

Elysia Responses

Elysia will automatically create the response object for you from whatever you return in your handler function.

If you want, you can also return a new Response() object and Elysia will handle it.

Want to move your routes to different files? Leverage Elysia's plugin system.

Need some additional functionality? Checkout the community.

Life Cycle Events

I won't go into too much detail here but this is an illustration of what's going on under the hood.

When a request is made and accepted, the system will transform the request to the object we receive in our handler function.

If we have validation in place, that occurs next. The handler function is executed and returns data in form of a HTTP Response.

If this all makes sense, let's move on to a demo!

API Demo

💻 Completed code here

Let's start by creating a new Elysia app!

You can easily create a new Elysia app by running bun create elysia app in your terminal where "app" is the name of your new application. If you don't have Bun installed, you can install it via curl curl -fsSL https://bun.sh/install | bash.

Next, cd into the new directory and run the app with bun run dev. A dev server should start up at localhost:3000.

Building Our Endpoints

For this demo, we're going to be connecting to the Trefle plant API. This API contains a very wide variety of plants and we'll be performing get requests for the purpose of this demo.

We're going to make a few endpoints to get our plant data.

1. Get 30 plants
2. Search by query
3. Search by plant genus
4. Search by plant species

First off, we'll add those endpoints to index.ts

Don't worry about the handler function for now, we'll add those later after we complete the next step.

Next, let's create the file that'll contain these functions in src/api.ts. Add these functions below:

But before we can attach these functions to the plant API, we need to get a token to authenticate. If you create an account here, you'll be granted with an API token to use their API.

Once you get your token, add it to .env inside our project as API_TOKEN. We'll leverage Bun to securely access our secrets. No dotenv package needed! Env variables are available via Bun with Bun.env.${YOUR_ENV}.

After your token has been added, let's kill the current server and restart with bun run dev. Now our value for the env variable should be accessible.

Next we will connect our API to Trefle with a generate URL function. This function will construct a new URL object and dynamically append any query params to the string.

Now that we have a way to construct our url to the Trefle API, let's start getting some data. We'll need to complete those handler functions I mentioned earlier.

For each handler, call the generateUrl function we created. For the specifics on getting plants, refer to the screenshot below. The purpose of this article isn't to use the Trefle API, just to demonstrate how to setup an Elysia instance.

Cool, if your code looks similar to the snippet above, let's move on to wrapping up the endpoints inindex.ts.

We just need to import the handler functions and assign them to the proper endpoints.

After that's done, if we go to localhost:3000/plants in our browser, we should see a JSON object returned with 30 plants 🎉 🌿

Test out the other endpoints to get specific genus or species data! That about sums up the demo.

Additional Things About Elysia

There's still a lot about the framework that we couldn't cover in this article. Here are some quick links if anything catches your eye.

Cookies in Elysia
Swagger docs
Websockets
Lazy loading
Dos and donts
E2E type safety

Resources / Thank you

Thanks for taking the time to read! What did you think? Are you going to be trying Elysia anytime soon? Let me know in the comments!

If you want to know more about the API framework, checkout these links below.

Elysia Docs
Elysia Github
Official Plugins
Demo Repo

Image credits go to the Elysia repository image author. I did not create the banner image on this post

🍞 Bun, A Faster JavaScript Runtime

James Robert Lund III — Tue, 27 Feb 2024 21:41:03 +0000

⚠️ Disclaimer: This article is for those who don't really know about Bun but want to understand it in a hurry

A new challenger approaches in web development!

Bun has received a lot of attention in the past year. But what is it?

What is Bun?

Bun is many things but to sum it up, Bun is:

package manager
test runner
fast javascript runtime
bundler
so many more things...

Bun is basically, a smaller, faster Node.js replacement.

Do note that not all features of Node.js are currently available in Bun. Though they will be built out eventually as the community is actively pushing out new and improved features.

Thankfully, the Bun team provides a compatibility table to show what features are implemented and what still needs work. You can check that out here.

One neat thing about Bun is it's written in Zig. A programming language that first appeared in 2016 that is intended to be a successor to the C programming language.

Other languages on this level would be: Go, Rust, and Google's new interoperability language for C++, Carbon.

While Zig is "new" in terms of languages, it seems to hold up to what the Bun team is trying to do with it.

Bun vs. Node

As mentioned before, Bun isn't quite a 1:1 comparison to Node. So I'd avoid swapping out your back-end for it right now. However, if the features you use are fully implemented within Bun, I'd highly recommend trying it out.

Why? Check out these metrics:

As you can see, the results look pretty promising 👀

Also, here's a thorough breakdown article by Mayank Choubey going over some non-biased performance metrics. The results will shock you!

If you want to test it out yourself, refer to this page of their documentation.

And with that, there's also a bunch of applications we can construct with Bun. So many that there's a guides section on the bun site.

Awesome Bun Projects

With Bun reaching version 1.0, you bet that there's a ton of projects out there that use it. The makers of bun made a repository with a bunch of projects that use the tool, you can check that out here.

Most notable projects:

Conclusion

Thanks for reading!!

This was a short one, next month should be a larger article with a demo. In the meantime, here's some links to other Bun-related resources.

Bun Github

More Bun Projects

🚅 Building a Cypress Accessibility Pipeline with Next.js and Axe

James Robert Lund III — Mon, 18 Dec 2023 15:42:03 +0000

In the web development world, there's a LOT of things we should remember. We should remember to build applications that are accessible, responsive, scalable, maintainable, cost-effective, secure, and the list goes on.

But that first item, accessibility, gets overlooked way too often. Unfortunately, it's normal to see accessibility as an afterthought in a web application, much like those who need websites to be accessible. People are people and they have every right to use your website (assuming its public) as anyone else.

If a user wants to consume your content, why shouldn't they be able to?

If someone is taking time out of their day to use your product, why shouldn't they have the best experience possible?

These are the questions we should be asking ourselves as we construct things that we care about. But as the developer, that's another thing you need to be mindful of.

Is my application accessible? Am I meeting the needs of my users, ADA, and WCAG? Is my company or client at risk of being sued for not being above a certain accessibility score?

It's hard to keep up with all of these things, but hopefully this tool will make it easier on you.

Let's talk about Cypress and Axe.

What's Cypress? 🌲

Cypress is a common name for some conifers in the Cupressaceae family (okay, I'm joking 😉, wrong cypress).

Cypress is (primarily) an E2E testing framework.

You can document user journeys, record where errors occur in your application, test components, and test E2E tests.

Cypress has tons of support and is available in any project that can install NPM dependencies.

What's Axe? 🪓

Axe is an accessibility testing framework that enables you to test your website against the standards of WCAG, A11y, ADA, and the like.

You can use Axe as a browser extension, GitHub CI/CD, and so much more. We're gonna use it in an automated CI/CD pipeline.

Building the Pipeline 🏗️

Okay cool, we know what the tools are so let's clone the repo and play around.

To start off, we'll install our dependencies with bun install or if you want, yarn install is supported too.

Next, let's spin up the site with bun run dev or yarn dev. If you see the site at localhost:3000 then we're good to go. But before we get ahead of ourselves, let's look at the folders inside the project.

The main takeaways here are the app, .github, and cypress directories.

If you're new to Next.js or Next.js 13, the app directory is a new way to implement SSR (server-side rendering) in your web application. Each folder is a route and will render content on the page as long as there is a page.tsx file inside of it.

To those of you who haven't worked with GitHub Actions, if you have a .github/workflows folder in your project (and your repo is hosted on GitHub), upon pushing your code, GitHub will look in this folder for YAML files to run as CI/CD.

This is a super easy way to implement CI/CD pipelines in your projects. The two files already in this repo are for e2e testing on push and verifying our Next.js site will build.

And as you may have guessed, the cypress directory will contain our tests and some configuration for Cypress. Let's take a peak at the resources there.

If you look in the cypress/support/e2e.ts file, you'll see that we're importing custom commands (if we had any) and the cypress-axe package.

That cypress-axe package import is crucial to using the functions that allow us to test our website against accessibility violations.

The cypress/e2e directory itself contains all of our tests for the UI of the application. The cypress/e2e/log-to-terminal.cy.ts file is mainly here to provide cleaner logs to us for debugging accessibility issues. The main tests exist in the sibling file check-accessibility.cy.ts.

What are we testing?

Each test should be self-describing. Some will target color accessibility for folks with color blindness, some will check for accessible HTML, and some others do custom things.

These "custom things" can be anything between excluding HTML elements, targeting specific ones, specifying custom rules, and only failing a test if serious or critical accessibility issues are found.

Here are some examples:

Checking All Potential Issues

Critical Issues Only

Custom Rules

Ignoring Specific Elements

Targeting Specific Elements

As you can see, there's not a lot of code that goes into these tests which is ideal if we're double-checking for any violation we might have missed.

Now, let's run these tests via bun run cypress:open or yarn cypress:open respectively.

If all is well, you should see this:

You can choose whichever browser suits your preference.
Next, click the E2E testing type:

After that, you should see a list of our spec files. check-accessibility.cy.ts is the only one we care about for the purpose of this tutorial. Click the spec and watch our tests run!

Reviewing the pipeline steps

Awesome, so we can spin up the Next.js project and run our E2E tests locally. What about the YAML file for the pipeline?

It's pretty simple but let's review the steps inside .github/workflows/e2e.yaml.

At the top of the file, the on statement specifies on push or pull request to the main branch. This filters the action to only run under those conditions:

On push to the main branch.
On a pull request to the main branch.

After that, we specify our job and the container it runs in (ubuntu-22.04).

Then as you can see, there's 6 steps the pipeline executes:

Checkout our repo.
Install Node (Bun isn't supported yet).
Restore the Next.js cache for faster build times.
Install dependencies
Build the Next.js site
Run Cypress

Conclusion

That's it! After we push to our main branch or make a PR, Cypress scanned each page we defined and let us know where we should fix our code to comply with accessibility standards.

Now could you imagine reading up all the WCAG and A11y rules yourself? Using a tool like this will save your team time, cost, and possibly a lawsuit.

I hope you enjoyed this article and learned something! Got a hot tip for implementing accessibility? Something cool about the tools discussed that I didn't mention? Let me know in the comments below!

Resources

Is your site accessible enough?

Cover Image created by Tomáš Hirsch

The Beginners Breezy Intro to Tailwind

James Robert Lund III — Sun, 26 Nov 2023 15:12:09 +0000

You've probably seen Tailwind somewhere around the internet. Whether it's recommended by your favorite web framework, criticized in another article for being "messy", or shouted on the rooftops by some web dev influencer, Tailwind has undoubtedly made its impact in the dev world.

In this article, I'll explain Tailwind's main concepts through the assumption that you have little to no knowledge of it. This article is not to persuade you but rather to inform you of what Tailwind is and how you could add it to a Next.js project. If you don't want to use Next.js, you can view the list of guides 👉 here.

With all that out of the way, let's dive in!

What IS Tailwind?

Tailwind, in short, is a CSS library made up of a bunch of utility classes that have been pre-selected for you with your interest in mind.

Interesting, how so?

I can only cover so much, but if you're interested, please please please read the book. Tailwind isn't just a bunch of RANDOM utility classes, they're specifically selected to help you build responsive and elegant design solutions.

What's a utility class?

Utility classes are generally agreed upon as being simple, single-use classes. In the realm of CSS, a utility class could be flex which could translate to display: flex or rotate-90 which could translate to transform: rotate(90deg) or even shadow which could translate to box-shadow: 0 1px 3px 0 rgb(0 0 0 / 0.1), 0 1px 2px -1px rgb(0 0 0 / 0.1);.

☝️ These are all Tailwind utilities by the way.

Hopefully, these examples shed some light as to why one would want to use utility classes.

You may be wondering, if Tailwind is a bunch of these "utility classes", why couldn't I just make my own in a *.css file?

In truth, you totally can. You can take the time to define your utility classes and create your design system. But if you don't have the time or resources, Tailwind would be an excellent option.

Tailwind has things like light/dark mode, theme support, hover and focus classes, CSS grouping, media queries, and a bunch of optional plugins that you can set up before your coffee maker finishes your morning brew.

More CSS vs. Tailwind things 👉 here.

How does it work?

Tailwind, like many tools, needs a configuration file so it knows what to do. This file is either called tailwind.config.js or tailwind.config.ts for you Typescript nerds.

When you're editing your tailwind.config.ts file, you're able to specify a "content" property. This property tells Tailwind where to look for its utility classes and which file extensions it should care about.

In this screenshot, I'm telling Tailwind to look at my pages, components, and app directories for files that end in *.js, *.ts, *.jsx, *.tsx, and *.mdx. If I had html files in these directories, I'd include *.html too.

When building your site, Tailwind will look at these files and see where and which utility classes are actually being used.

It will only care about the ones being used and disregard the other utility classes it knows about. This is part of its tree-shaking process.

How can I install it?

There's typically two routes you can take to add Tailwind to your project. Via the Tailwind CLI or as a PostCSS plugin.

According to the docs Tailwind CLI is "the simplest and fastest way to get up and running with Tailwind". Though this is true, I want to stick with a different approach. The one that you'd probably use to integrate it into your project by using Tailwind as a PostCSS plugin. This is the recommended way to integrate it into your project if you're using Webpack, Vite, Rollup or any other build tool.

See how your framework should use Tailwind 👉 here.

Before installing it though, we should probably understand two other tools that are needed for this. PostCSS and Autoprefixer.

According to their Git repo, PostCSS is "a tool for transforming styles with JavaScript plugins". In short, it "takes a CSS file and provides an API to analyze and modify its rules by transforming them into an abstract syntax tree" using JavaScript. "This API can then be used by plugins". Plugins like TailwindCSS and Autoprefixer in our case.

Autoprefixer, according to the NPM docs, is a PostCSS plugin to parse CSS and add vendor prefixes to CSS rules using values from Can I Use.

Here's a list of some browser prefixes as of the time of this article:

-webkit- (Chrome, Safari, newer versions of Opera and Edge, almost all iOS browsers, basically any WebKit or Chromium-based browser)
-moz- (Firefox)
-o- (old pre-WebKit versions of Opera)
-ms- (Internet Explorer and Microsoft Edge, before Chromium)

Okay cool, now that we understand what these things are, let's get back to installing Tailwind in our app.

Setting it up in a Next.js app

If you want to skip setting it up and just play around, you can install an already configured template and play around with it 👉 here.

Also, if you like this template or have suggestions, please star it or create an issue. Thank you!

Otherwise, let's follow the Tailwind docs and set this up from a clean slate.

To start off, let's install a VSCode extension to give us some IntelliSense:

Then, let's setup a new Next.js project:

Next, we'll install tailwind and our dependencies with npm:

In order to use Tailwind, we'll need to tell it which files to look at in the "content" section of our Tailwind config:

After that, we'll need to add Tailwind's directives to Next.js' globals.css file. This is needed to use it's utility classes. More info 👉 here.

Now that everything is set up, you should be able to start styling your site! With every tool, there's a learning curve and it's impossible to remember everything. So that's why I use a cheatsheet to help me build things.

Adding your own utility classes

What if we wanted to add our custom branding colors? We can do that by creating custom utility classes in our config.

There's a section in your tailwind.config.js file that allows you to add additional utility classes by extending your theme. You can see from the image below, I include two new colors, primary and errorOnLight. After making your changes here, you can now use them in your html.

I like to define my brand colors in the config so I can use them in the project. You can choose to either keep all the Tailwind colors or only keep your custom ones, the choice is yours.

Tree-shaking and production

So we're able to setup Tailwind in a Next.js site, but what happens when we want to build for production?

From the docs:
"Tailwind CSS is incredibly performance focused and aims to produce the smallest CSS file possible by only generating the CSS you are actually using in your project.

Combined with minification and network compression, this usually leads to CSS files that are less than 10kB, even for large projects. For example, Netflix uses Tailwind for Netflix Top 10 and the entire website delivers only 6.5kB of CSS over the network."

If you installed Tailwind as a PostCSS plugin (we did in this article) you can also use cssnano as a plugin to reduce the CSS bundle when we make a production build. More info on that 👉 here. However, I have not noticed this making a difference in a Next.js application. Probably due to Next.js minimizing things for us automatically.

I hope this leaves you with a better understanding of what Tailwind is! Did I miss something? Do you know a cool Tailwind trick? Let me know in the comments below!

Thanks for reading!

Cover image created by Булат Салихов

🔮 VSCode Extensions To Magically Accelerate Your Productivity

James Robert Lund III — Mon, 23 Oct 2023 12:10:16 +0000

Most of you reading this probably use VSCode extensions on a daily basis. Whether it's to lint code, show suggestions, type inference, or something to make you laugh, they impact your workflow and help you build products.

Below is a list of extensions that I use daily. It's safe to say I would be totally lost without them and my estimates on tickets would inflate.

I hope these help you as much as they've helped me!

Auto Rename Tag

Starting off this list is the Auto Rename Tag extension. This extension is super useful if you work with a lot of HTML. The general gist of it is it'll format the closing tag of the tag you're editing to be the same name so you don't have to. This saves me a lot of time when I'm working on legacy sites that have *.html files with tags that wrap 100+ other tags.

Id: formulahendry.auto-rename-tag
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=formulahendry.auto-rename-tag

Code Spell Checker

This one is really helpful if you work with international teams or you want to document words or abbreviations within a project.

Code Spell Checker allows you to fix misspelled words or save them to the project's settings.json file. This shows intention which is huge for onboarding new developers who might not be familiar with the business phrases of the application.

Id: streetsidesoftware.code-spell-checker
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker

EditorConfig

EditorConfig is ESSENTIAL for my team and me. It helps us keep our code editors in sync and reduce diff logs when making pull requests by establishing a formatting standard.

Id: EditorConfig.EditorConfig
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfig

Eslint & Prettier

If you've been in the webdev world for a short period of time, you've probably came across these two. I won't go into too much detail here but in short, Eslint is a linter, Prettier is a formatter. You can use them together to enforce a code standard in your projects.

Id: dbaeumer.vscode-eslint
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint

Id: esbenp.prettier-vscode
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode

Git-Rename

Git-Rename is very useful if you want to rename a file or change the casing in a filename. Instead of deleting a file to remove it from your Git history so you can change its casing, Git-Rename lets you rename your file and helps you track those changes in Git.

What?

Say you have a file called "myfile" in your project and it's already tracked by version control. If you change the name to "myFile" that's just a casing change and Git won't care about it by default. You can change your git settings to fix this but if you're working in a team, you'll need to convince your fellow devs to do the same. An easier option would be to include this extension in your extensions.json file in your project so they get prompted every time they open the project that they should download the extension.

Id: ambooth.git-rename
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=ambooth.git-rename

Import Cost

Import cost lets you know how many bytes each of your imported packages are. It's super useful for mobile apps where your bundle size means a lot to your end users.

Id: wix.vscode-import-cost
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=wix.vscode-import-cost

IntelliCode

Another great extension for TypeScript and JavaScript. IntelliCode works as that annoying friend who tries to finish your sentences. It provides method/object completion for the TS version it finds in your project and infers types for you, letting you know which properties on an object you can use.

For you Django fans, it works for Python too!

Id: VisualStudioExptTeam.vscodeintellicode
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=VisualStudioExptTeam.vscodeintellicode

Pretty Typescript Errors

This one isn't for everyone but I write a lot of TypeScript and it helps me parse out TS errors. Basically, instead of TypeScript giving you a long and semi-convoluted message, this extension will display a more human-friendly message to help you narrow down what you're doing wrong in your code.

Id: yoavbls.pretty-ts-errors
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=yoavbls.pretty-ts-errors

Do you use any of these extensions? Do you have a suggestion for extensions that work better than these? Let me know in the comments below!

Cover image created by GioeleFazzeri

Get Validated With Zod

James Robert Lund III — Wed, 10 May 2023 21:11:27 +0000

How many times has this happened to you?

You're writing a super sweet api that consumes some data from a database and tosses that data to some front-end where it can be consumed by users.

Maybe your api has a POST endpoint where users can upload data that's being consumed and viewed by other users. That's all fine and dandy until you start to get some bad data into your database. Maybe some data that doesn't fit a model and will blow up your application if not formatted properly.

See, Typescript is awesome in all, but it lacks data security. It might tell you (the developer) that a type is missing a property but it wouldn't actually stop data from going through that part of your application.

This is where Zod comes in.

Zod is an amazing library. You can use it to define schema's, create types, and most importantly... validate data. This data validation library was created to fill in the gaps that Typescript leaves behind.

That sounds great in all... but how about some examples?

Defining a schema:

Here we create a schema called "POST_SCHEMA", it expects some data to have an id with a length of 16, a postNumber that's a number, and a few more fields. You get the idea.

Inferring a Type:

We can now create a type from our schema to use anywhere else in our app.

This looks and will act the same as:

But the benefit is we also have a schema to validate our data.

Parsing data:

Now that we have a schema, we can validate or "parse" our data to make sure it fits our defined model.

Zod will throw an error if the data isn't matching the schema we created.

But what if I don't want to throw an error?

That's easy, we can just use the safeParse function instead!

If you're curious about this library, you can view the full documentation here. It's helped me a lot on production projects and hopefully it helps you too.

Thanks for reading!