Written 9/26/2022 — Last Updated 12/13/2024

Recommended Web Development Libraries and Tools

My recommendations for libraries and tools to be used in web development.

Priorities

Extensions to HTML, JavaScript, and CSS should generally follow the upcoming standards at various stages of adoption. For instance, using the babel preset-env transpiler to get the new EcmaScript features, or PostCSS to get the new CSS features. Then, the priority of adding features should be

As a transpiler, which modifies code behind the scenes’s. For example, Autoprefixer.
As a code fixer, which modifies the code automatically. For example, Prettier.
As a code linter, which detects issues. For example, ESLint plugins.
As a testing utility, which helps you to write detection of issues during testing. For example, “Ghost” testing to detect differences in the way your app is displayed on different browsers.

Have Used

Cypress
Firebase
Prisma
Sequelize
Deno—Alternative to node but with native typescript support.
- Aleph.js, the create-react-app of Deno js.
Next.js
AWS Lightsail
Render

Considering

Winston
inline-style-prefixer
astroturf
Podman
Supabase
Netlify
Koa—Like Express, but with promises
Zod—Schema validation library for TypeScript
tRPC—Remote Procedure Calls for TypeScript
Hasura—Create a GraphQL API from an existing, non-GraphQL database.
Astro—framework wrapper for server-rendered web sites.
NanoID—Alternative to UUID
PWA Builder—tools to build PWAs and convert them to native

Rome

Rome is a code formatter and linter with ambitions to also become a build tool, bundler, and test runner. This would make it a current competitor to my recommendation for formatting, Prettier, and linting, ESLint. If they succeed in expanding their utility, however, they would put themselves in direct competition with Vite, Vitest, and Babel.

I like the idea of a unified set of tools. There is an issue with tooling where my configuration for builds may not match that of type-checking or linting, causing my builds to choke on code which my static analysis permitted, or causing my static analysis to forbid code which my build tooling would have happily converted. Rome even ships with a vs-code extension, such that your IDE warnings and errors are the exact same as those that will occur on build.

Granted, I use NeoVim, but Rome’s integration with VS Code is based on LSP, so I might be able to integrate it into NeoVim myself, though it would take some effort.

Code formatters are simple to evaluate—objectively, do they work, and subjectively, do you like the resultant formatting? I suspect that Rome does successfully format code without errors. Not because code formatting is easy, but because it is a very do or die space to be in. If it ever fails, it would not be used. The use of Rome for formatting will then soley depend on whether or not you like the result.

As for being a linter, I don’t think that Rome can replace ESLint any time soon. Rome appearsto have 63 rules. Whereas ESLint appears to ship with 285 active rules, and that’s not to mention the rules made available by third-party plugins. Rule count will never be a direct comparison, but I suspect there are plenty of errors which ESLint will find that Rome will selently permit. Luckily, your linter need not be an exclusive relationship. Rome may be run alongside ESLint, and doing so provides a unique opportunity to vet their offering. Assuming you fix issues right away, whichever linter you run second will only report those issues that only it could detect, as the first linter’s results have already been resolved. Granted, this runs contrary to Romes value-proposition—that being one tool to rule them all—but in the case of static analysis, I believe more can never hurt.

One advantage I do believe that Rome has over ESLint is the clarity of its error messages. My configuration of ESLint will only report which error failed and where it failed, (in terms of a line and column), along with an hard-coded english explanation for the error. Rome appears to print a snippet of the offending code, which I find more helpful. When ESLint reports an error, I often find myself ignoring everything except the reported location, as looking at the code is almost always more useful than the report when trying to determine the issue.

* Based on using querySelector to count the rule elements.