This post is more than a year old. Information may be outdated.
I've recently come to an epiphany that my dev stack or philosophy doesn't fall under any existing categories. I'm not
a PHP indie-preneur who makes millions
a Java engineer who engineers systems for millions
a C++ engineer who optimized codes at the nanoseconds level
a Python scientist who programs as a mere means for their maths
Some saw me as overengineering while another saw me as inexperienced when the others saw me as hype-chaser. It could look so. But I wanted to sit down and explain my philosophy and reasoning behind the stacks. Hope it makes sense to you.
This is NOT for everyone NOR I don't intend to persuade you. All techs are driven by needs, and your needs differ from mine.
0. Red Queen's Race
Now, here, you see, it takes all the running you can do, to keep in the same place.
Everything changes, and you will, too. Your defense to A will perish into history with B's new update and C's unpopular push. Your job is to disprove yourself as often as possible.
Instagram's Engineering Philosophy in 2011
One of the most popular philosophies is Instagram.
Keep it very simple
Don't reinvent the wheel
Go with proven and solid technologies when you can
While the first two still sound relevant today, I don't agree with the third option. Things change, and they change for good. New tools are built for a reason. Find and learn from that reason.
The goal of the GANGNAM is to build systems in hot-replaceable chunks, with every module destined to be swapped out at one point. (i.e., this will be your last rewrite.)
So, experiment more, learn more, ask more. Become a wanderlust and aggressively explore new tools.
Also, hear out when people have different opinions.
Experiment a lot, but make sure a "Revert" button is in reach and works!
Dafuq is hot-replaceable
Something that you could switch with a press of a button. I initially thought of the word "interoperable," but I think it doesn't fully grasp the point.
Why is it called GANGNAM, by the way? I live in Gangnam right now, and I conversed with a lot of smart people on this topic at Gangnam. What other good names could it have? So naturally...
1. Ergonomics over Anything
Your most valuable asset is your energy and a few slim time windows to gauge the market. Choose the most 'ergonomic' tool, whatever that is. If you can do the same thing with one of the codes, then there's no reason not to choose it.
For example, take config hell: If you need to configure something just to get it to work, it's not ergonomic. Things should work out of the box.
TypeScripted Node is unergonomic because you need to touch tsconfig and ts-node to get it to work. A better approach will be a runtime that just understands TypeScript natively. As of today, it's Bun.
CJS-ESM are unergonomic because you need to set up interops. A better alternative would be a runtime that agnostically takes them all. As of today, it's Bun.
The Python PIP System is unergonomic because it doesn't guarantee requirements and dependency consistency. A better approach would be something like an auto-updated dependency list or hot-loading model. As of today, it's package.json (acceptable) and Deno (better).
Webpack is unergonomic because you need to touch webpack config, loaders, and plugins to do what you want. A better approach will be a loader that just knows all popular file formats and accepts them accordingly. As of today, it's Parcel (although these days, tools like Next abstract away webpack good enough, so the need for another bundler is smaller than ever)
Storybook is unergonomic because you need to configure story files to get it to work. A better approach will be a watcher which reads all the components and looks at the props to generate the 'stories' files automatically.
IaC is unergonomic because you need to 'maintain' dockerfiles and terraforms to get things to work. A better approach will be an intelligent command that reads and chooses the best option. As of today, it's Nix.
In general, imperativeness is unergonomic, and declarativeness is ergonomic. You define how things 'should be,' not the nitty-gritty in between.
If you can do the same thing with 5 lines of code instead of 100, then you should opt-in for 5 lines of code.
This is obvious but for the record
Type Safety is ergonomic. That's why I hate Python.
2. Clever Hackiness over Secure Busywork
I'd choose an unstable but elastic tech over a proven boring tech.
Proven boring techs are often not hot-replaceable.
I'd prefer a simple go script over a factory-patterned Java Spring Boot.
Simpler, more elastic, and hot-replaceable.
I feel like Mr. Kessels put it best. He makes a point on database, but I think it applies to way more stuffs.
Don't use the database when avoidable. Which is always more often than I think. I don't need to store the 195 countries of the world in a database and join when showing a country- dropdown. Just hardcode it or put it in config read on boot. Hell, maybe your entire product catalog of the e-commerce site can be a single YAML read on boot? This goes for many more objects than I often think. It's not Ruby that's slow, it's your database
3. Use SaaS up until you 'study' it
Deep SaaS is a SaaS that does one thing only and one thing great.
Offload SLA to a SaaS whenever you can, up until you need to "study" it.
Mass Market is often accurate. If they solved 99 other people's problems, it'll solve your problem, too.
For example:
Resend is acceptable because it uses a simple HTTP request
Zapier is unacceptable because you need to 'study' to make it work
If you use Zapier, only use it to the point of Webhooks
Google BigQuery is unacceptable because you need to learn GoogleSQL
If you use BigQuery, don't invest too much in learning GoogleSQL dialects.
I plan on using Firecrawl, which is acceptable with this criteria, because it's just an HTTP request, and what it does is super clear (I already built the same thing anyway. It's just cumbersome to maintain Playwright workers and handle exceptions or DOM errors of websites out in the wild)
SaaS is fine. I'm just saying keep Deep SaaS hot-replaceable. Don't study proprietary tech unless it's the industry de facto! (I'm talking to you, AWS)
This is just my preference but
If there's an OSS alternative for that SaaS, I'd rather use that OSS and GitHub-Sponsor them. See Open Core Models.
Need LogSnag? Check out PostHog. Need Resend? Check out Plunk. Need Substack? Check out Ghost.
Why?
Self-hosting = Controlling the Database = Better Chance of Being hot-replacable with Bulk Data Exports
4. Occam's DollarShaveClub
Opt-in for a solution that requires the least amount of work. Don't overcomplicate it.
If doable with HTML, do it with HTML.
If doable with CSS, do it with CSS.
If doable with ECMAScript, do it with ECMAScript.
If doable with Pure React, do it with Pure React.
If doable with Next.js or Meta React of your choice, do it with that.
If doable with Vertically Integrated Framework with any of the above, do it with with that.
If doable in less than an hour, build one yourself.
Now look for any NPM libraries.
Similarly, with tools:
If doable within Git, do it with Git.
If doable within GitHub, do it with GitHub.
If doable within GitHub Apps, do it with those.
For example, IRL,
Prefer HTML input date over building your own calendar input
Prefer CSS Animations over Framer Motion
Prefer Fetch over Axios
Prefer React Suspense instead of Next.js Dynamics
Prefer SWR over other data lifecycle management tools (it's by the same company, vertically integrated)
Prefer Oslo's Argon2ID over other libs when using Lucia (it's by the same dev, vertically integrated)
Prefer GitHub Actions over other CI tools
To override this chain of command, you will need a good reason, such as better ergonomics.
makes dependency deduping and code sharing a breeze across repos.
interoperable and hot-replaceable (works on top of npm workspaces)
Bun
minimal setup
lightweight and fast
no bullshit configs (its tsconfig is only for the editor)
Elysia
minimal setup
super ergonomic
super fast
no bullshit configs
not hot-replaceable right away, but very similar to Express
Hono
Web Standards!
Would love to explore a more centralized options like Supabase and Convex. Supabase is known to be terribly hard to self-host tho.
Lucia
minimal setup
ergonomic
vertically integrates out-of-the-box with oslo and arctic
oslo: Many auth-related helper functions
arctic: Provides OAuth 2.0 bridge with almost all popular providers
not hot-replaceable right away, but it's just an ergonomic wrapper on industry-standard session tokens
Biome
minimal
vertically integrates prettier and eslint
AWS with FlightControl
minimal setup (vercel-like setup)
hot-replaceable since it's just a super ergonomic wrapper of AWS API calls under the hood, and basically, it's just starting a $5 VPC with a NixPacks Docker image
HTTP-Only Cookie Authenticated REST APIs
Most GitHub and AWS features
As many automation as I can find
I am skeptical of this but could use:
Next.js
I don't like they try to 'override' or 'rebrand' some web or React feature
but I must admit, hell yeah, they're ergonomic.
not interoperable, but I don't think any web framework is
Remix
I feel it's better than Next, but recently the team had been a little haywire
SWR
minimal setup
vertically integrates with next.js (by the same Vercel people)
Tanstack Query & Table
If I need to use Tanstack Table, I'd use their entire series. Doubts on the recent "Start" thing but optimistic.
UI by @shadcn
minimal setup
one could argue it's ergonomic
vertically integrates with Next.js (shadcn works for Vercel)
hot-replaceable because it's just copy-pasting Radix Tailwind codes to your component folders.
I recently purchased Tailwind UI and Catalyst -- for reference and studing
Tailwind
minimal setup, although I hate postcss and tailwind configs
near one-to-one mapping with CSS
ergonomic in a way that it does automatic optimizations
Jest or Vitest
It's fine. They have similar APIs anyways.
Prisma
it's fine.
I'm not writing raw SQLs anyways--it's not ergonomic.
It's not hot-replaceable per se, but worst case, I could just shim the object with @vercel/postgres direct SQL calls
Postgres
it's fine.
Lefthook (or Git Hooks in general)
it's fine.
minimal setup
explicitly shows commit hooks (unlike husky)
Lefthook is hot-replaceable because it's just git hooks wrapper
GraphQL
it's fine
a bit of a setup and maintenance work,
but it makes API calls much more ergonomic once past that stage
it's not hot-replaceable
I wouldn't want to use it unless absolutely necessary
Docker
Web Packages are, in a way, already containerized. Setting them up is fine, but it's an extra step.
If I need to use it, I'll use it through NixPacks.
Vercel
It may seem hot-replaceable, but you'll lock up if you start using its edge functions or Postgres plan.
Bun Specific APIs
I would not directly use Bun.test or Bun.serve because they are not hot-replaceable.
I might write a wrapper that internally uses these APIs to make things faster while keeping things interoperable.
Serverless Architecture
I think it makes more problems than it solves
6. Do Things That Don't Scale
Many misread this as keeping things boring, repetitive, and predictable. I think it's the opposite way.
Founders or engineers, who especially prefer to be in deep tech, must bet on the dangerous, unsustainable way of doing things.
First, create a safety net, then try out unreliable but bold things over and over.
Opt-in for standard-based interoperable, hot-replaceable, elastic, and ergonomic wrapper technology instead of proprietary, proven, boring, old tech.
Ofc you need to do your own research
Don't email me after you set something on fire after following this!
Comments0
No comments yet. Be the first to share your thoughts.