If I want runtime types, I reach for type guards. If I need to do this a lot, then I reach for io-ts or zod and pretty much exclusively write types as validators/codecs/schemas or what-have-you.

I don't think TS - as a specification, type-checker, community, or otherwise - needs to concern itself with runtime validation UNLESS JS gets some agreed upon way to do it.

First is the visibility of these pull-outs is often very poor. You'll be driving through long winding roads and then all of the sudden the pull-out appears. In an RV, you can't just slam on the breaks and swerve into the pullout, ESPECIALLY if you're going downhill.

Second, often times (in the USA at least), these pull-outs have rough terrain going in an and out of them. There will be a little bump or uneven ground that most vehicles wouldn't mind hitting every now and then, but in my rig, that causes the whole thing to sway back and forth (Class-C built on a Mercedes Sprinter). I REALLY need to upgrade the suspension.

Third is time. Since I'm slower than everyone else, people tend to pile up behind me pretty quickly. Pulling into the pull-out, coming to a complete stop, waiting for everyone to pass, then getting back up to speed takes a long time. If I did this every time there was a car behind me, it would take forever. So, I tend to wait until there's more than a few cars behind me before pulling off.

Fourth is my wife. She says I have "overly-considerate disorder" and I need to make our safety #1 and stop caring about other people so damn much.

I used this project as a training ground for a ton of different ideas and technologies. From server rendered react to typescript and design systems to how the hell kubernetes works. I went from dokku, to lando, to trying to figure out Consul and Hashicorp stuff to managed K8s on digital ocean. I decided to try to only write SQL and create my own typesafe patterns with TypeScript. It didn’t work out all that great but it wasn’t all that bad either.

This is half baked because I had so many more plans for a product no one asked for. Definitely one of the best learning experiences I had. I started with a monorepo of modules and realized that was a stupid idea for an app. I developed some strong opinions along the way. Oh I reimplemented email auth for the nth time but this time I used postgres’s built-in crypto functions. Man I like this implementation

To folks saying to “Just use server logs”, it’s simply too hard to connect the dots unless you really know what you’re doing. Digging through my nginx logs to find that the majority of my users are dropping off at the second step of sending an invoice would be nearly impossible. Oh I could connect those logs to my api’s database, now I need a place to aggregate that data together. Maybe I could send all of that data together to elasticsearch and query with kibana. Now I need to learn how To set those things up.

Or I could use Matomo for some analytics real quick

Just React and Mobx

Absolutely not. I chose kubernetes because I was interested in learning more about it

I've used this project as a test bed for learning new technologies. And what did I learn? That using Docker and Kubernetes effectively is harder than I thought it would be.

Some maybe interesting things about the technology used:

  * It's almost 100% TypeScript
  * What's not TypeScript is plpgsql
  * Postgres
  * Nodejs
  * Docker
  * Deployed to a Kubernetes cluster
  * React on the frontend
  * React also renders HTML on the backend (for the PDF generation and emails too)

Comments URL: https://news.ycombinator.com/item?id=21527234

Points: 11

# Comments: 5

Disclaimer, I freaking love JavaScript and TypeScript.

> TypeScript is a hack of epic proportions and every so often the reality rears its ugly head in the form of failed source mapping, version compatibility issues, unexpected types during runtime, poor architectural decisions aimed at pleasing the compiler instead of fulfilling project goals.

This just sounds like JavaScript to me. Maybe TypeScript has helped elucidate those problems for you. TypeScript adds some syntax to help formalize solutions to these problems that existed in JavaScript already.

> TypeScript is a very poor way to model real-world systems because it incorrectly assumes that real-world entities have a fixed type schema

This sounds to me like programmer error. TypeScript provides facilities for unknown structures, or structures that have multiple possible definitions. There is the union type for which we can tell the compiler that a value can be of type `A[ or B[ or C[ or... ]]]`. Perhaps even more powerful is optional types. In interface you'd describe an optional field with a question mark, like `{ foo?: string }`. Alternatively, you could use the union type described above, unioned with `undefined`. These structures help you create types that actually do model the uncertainty of data coming into your program. If you're not using these techniques, then you're missing out! Having the type-checker yell at me because I didn't check for the undefined case is a really really cool thing.

> Why not force the developers to account for as many cases and schemas as possible, it's our job!

I would argue that TypeScript provides the vocabulary for doing just that and that JavaScript provides no such niceties. Sure, you provide run-time checks on a piece of datas validity, but there's no system to check that run-time behavior before code gets merged to master.

If you're not running `"strict": true` and annotating your TS code with optional values when data is coming into your program, you might have a bad time.

(This is probably a naive comment. I have no idea if this would work the way I assume it would).

How's your experience been with TypeScript and oao? I've got a very large monorepo (using yarn workspaces) of TypeScript modules and it's been sort of a PITA. For instance, a typical yarn install will unnecessarily duplicate some dependencies across packages causing tsc to complain about duplicate identifiers. Running yarn --check-files fixes this, but it's still annoying. Also, following symbols with yarn workspaces is sometimes annoying since linked packages will use "main" and "types" fields in the package.json, thus following a symbol takes you to the generated type definition. I have a generated tsconfig.json that sets paths to their appropriate package paths to fix that. Again annoying.