Skip to content

Commit

Permalink
add more memes
Browse files Browse the repository at this point in the history
  • Loading branch information
vorant94 committed May 6, 2024
1 parent 8ba437a commit 4839b54
Show file tree
Hide file tree
Showing 3 changed files with 5 additions and 1 deletion.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Original file line number Diff line number Diff line change
Expand Up @@ -14,6 +14,8 @@ Prior to that it was written with Astro. Long story short I'm not a fan of the f

#### First rewrite: NuxtJS

![A huge and complex building standing on a small and fragile foundation](./dependencies.jpg)

First I looked on NuxtJS. It sadly also has file-based routing, but the app can be split into domain-specific "sub-apps" with Nuxt Layers. Underlying Vue still introduces its own file extension (`.vue`), but this one is old enough for IDE to have a good support. Just like Astro it has a plugin for working with Markdown files as a CMS, called Nuxt Content. It can be built with SSG or SSR-mode and has a mature ecosystem of all sorts of integrations.

Everything looked perfect from the outside, but when I glued everything together it started to feel like serious overkill, the mother of all overkills. Even worse than that I faced several issues that are there only because how the framework is build:
Expand All @@ -22,7 +24,7 @@ Everything looked perfect from the outside, but when I glued everything together
- when I retrieve post's slug from route params and then query for the post by it in the Nuxt Content, it returns `Post | null` type. It is totally valid for SSR-mode, when request params can be whatever user inputs, but in case of SSG I have finite known-in-advance list of slugs, so there is no possible case when `null` can appear. But dev server runs only in SSR-mode, so here it forces me to type gymnastics.
- Vue as every SPA starts by attaching the whole app to a specific element inside document body (`<div id="root"></div>` for example), so the only way to interact with document head is to use `useHead` composable or some similar solution. I'm not writing highly interactive SPA, that can justify usage of framework API's instead of interacting with HTML right away. I write a simple blog and want to have simple dev experience.

At this point of time I got really depressed about the project, because I didn't want to reinvent the wheel by creating yet another JS framework by myself, but all the available solutions on the market were too strict with their conventions. I took a break and after it still decided to remove meta-framework level of abstraction and write static site generator by myself, but with an asterisk.
At this point of time I got really depressed about the project, because I didn't want to reinvent the wheel by creating yet another JS framework by myself, but all the available solutions on the market felt too fragile as the result of their complexity and too strict as the result of their conventions. I took a break and after it still decided to remove meta-framework level of abstraction and write static site generator by myself, but with an asterisk.

#### Second rewrite: Fastify

Expand All @@ -46,6 +48,8 @@ Also since I now have a "custom" Node app that isn't built on top of a meta-fram

#### Less deps - less headache

![midwit meme about using all sorts of libraries compared to using just built-in stuff](./just-use-built-in-stuff.jpg)

Along the way with this rewrite I decreased the number of external dependencies as much as I could. I don't use third-party TS transpilers like `ts-node` or `tsx`. I started to use built-in NodeJS test runner instead of `Vitest`, built-in `--env-file` file support instead of `dotenv`, built-in `--watch` mode instead of `nodemon` or something. I don't use TS path aliases, since `tsc` by itself can't map those aliases back after the compilation and requires third-party solution. I moved back to `npm` from `yarn`.

All of it makes my developer experience a little bit worse, but I bet it will pay off in the long run. I have limited amount of time I can spend coding a website that almost nobody reads (as of now). I need to fill it with content first, not features. So I want the stablest project I can possibly get. Most of the dependencies I used up until now have regular releases at least once in a month. There was not a single time I upgraded my deps and felt like everything should be ok. Each time I was required to check stuff manually and often times file issues on GitHub. I don't want it anymore, I want to code other pet-projects and only write about them here.
Expand Down
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

0 comments on commit 4839b54

Please sign in to comment.