I should start this off talking about why I went with React. When I first started doing webdev, I had to pick between Angular, React, and Vue for which one to learn first. Following more research, I decided that Vue was the one to start with. It seemed simple enough at the time, I liked the Single File Component (SFC) setup, and it had a feel of being less bloated than React, since it was newer and could benefit from lessons learned from React. After going through a tutorial, I ended up picking up Nuxt.js for a project, enjoying the features and opinionated nature.

Starting with Vue

Fast forward to working on a more recent project, and I started with Vue. After spending the hours setting up the various packages and config files... ESLint, Prettier, webpack, Typescript, VSCode, etc., I wrote the first bit of code... and it didn't work right. Spending another half hour or so troubleshooting that, I found that I had typoed a variable name in the <template> area. I assumed I had a mistake in my configs, spending more hours researching that, until I found that there is very limited error checking of the script in <template> areas. That was unacceptable to me, so I decided to give React a try.

Moving to React

Several things stuck out to me when I had finished React's tutorial. The biggest one being that JSX/TSX files had much better support in VSCode than Vue's SFC files. The boilerplate code I had to write for every component was reduced, thanks to the functional approach that v16.8 brought about. And it was all supported by the error checkers provided by the TypeScript compiler and ESLint.

Finally, to Next.js

Before starting this site, I stumbled upon a news article that talked about something called Jamstack. I'm not still really sure what that is, since the site is full of empty-feeling marketing malarkey statements. But it lead to me discovering a feature that I like: Static Site Generation (SSG) while still using a fancy JS framework like React. Between the different SSGs listed on the site, I looked at a few, deciding upon Next.Js since it was the most popular, and I was familiar with its concepts from using Nuxt.js previously.

So far, I'm happy with this choice. The SSG was painless to get working. I haven't used it here yet, but I like the simplicity of automatically generated routing based upon file names. Having an opinionated directory layout helped me get started on something that I'm not thoroughly experienced with. The popularity certainly doesn't hurt, specifically meaning there is a good amount of documentation and examples available.

I don't have much of a basis to speak on any significant drawbacks. I haven't yet tried out any other SSG framework that sits on top of React to make any valid comparisons. One thing I would like is including better configs out of the box for ESLint, Prettier, VSCode, and some testing frameworks. But that's also getting perhaps too opinionated for a project. At least, Next does take care of automatically handling the webpack/babel stage of transpiling JS and CSS into production files. The biggest thing would be adding another library your project is absolutely dependent on, creating a big headache to maintain and update the project if that library goes defunct in the future.

I just completed the basics of the blogging engine for my site. I certainly had a rough time getting started on it, particularly having to get all the config files and VSCode to play nice together. For now, it simply renders some Markdown files into this area, but I hope to add some more features over time. I'll be sharing a small series of posts explaining some of the tech/libraries that I decided on using for making the site. You can view the source code for the site over on Github!

Tech used

Here's a brief overview of the tech/libraries I decided to go with:

• Visual Studio Code (on Ubuntu 20.04)
• TypeScript
• Next.js
• MVP.CSS
• Marked
• SCSS/SASS
• front-matter

Why use TypeScript?

Pros

JavaScript is everywhere, but it's a fully dynamic language. Is that function giving me a number, a string, an instance of Foo, or just undefined? There's not really any guarantees on any of this, especially when dealing with imported libraries. My biggest peeve around this is not having any code completion assistance whenever the IDE can't figure out what type a variable is. This also comes into play regarding simple mistakes, like misspelled variables. I much prefer to catch these in the editor from the compiler than at runtime.

I love many of TypeScript's language features. Union types, tuple types, and strict null checking are just a few that come to my mind right off the bat. The type system provided has some very powerful features, and they keep adding more as the landscape develops. I particularly enjoy having the strict option enabled, as it helps prevent loads of runtime errors, particularly undefined errors. And we can't forget that the TypeScript team will often add in features that are still experimental or draft status in the ECMA standards, such as when they added Nullish Coalescing operator in 3.7, months before it was formally adopted into ECMA2020.

Cons

The biggest drawback is that it's not JavaScript. As in, it won't run in your browser. You have to pass your code through the compiler after every edit before the browser (or Node) will be happy, so you have to set up a process to automatically compile whenever you launch. This leads us to the next issue, which is the time and knowledge it takes to install and set up TypeScript into a project. When you add in Prettier and ESLint, that's more systems that you have to make sure will handle TypeScript.

Using external libraries can be a mixed bag. Most of the big JS frameworks out there include full TS support. While you can find a small helper library that does something amazing for you, it often doesn't play nice with TS, which requires stacking a virtual house of cards to get that part working. Many projects provide type declarations in an external package, such as @types/node, which is another step to get things working compared to vanilla JS. But worse than that, with the strict option that I love so much enabled, if a project doesn't have any type declarations... you're left to write them for yourself. Which is more files, more steps, more time.

Conclusion

For me, I'd say do vanilla JS if you just need to cobble something together quickly. Something small and simple, easy to keep track of the whole thing in your head. But the bigger the project is, the more you'll appreciate the error checking and prevention tools that TypeScript provides.