TypeScript vs plain JavaScript conversation seems to never end, so I thought I'd share my thoughts on why I dearly love TS while also passionately hating it.

People usually tend to fall into two camps

TypeScript is our lord and savior, praise be TypeScript

TypeScript is a plague and all traces of it should be expunged

I'm the weirdo who's kinda in both camps and I think most people on both sides of the argument misunderstand what TypeScript is. So what is it? Well, I'll tell you one thing it's not:

When you're writing TypeScript, you aren't actually writing TypeScript. You're writing JavaScript with types merely as suggestions. I know we all like to forget that Flow used to be a thing, but Flow comments is a good illustration of what TypeScript fundamentally is:

```js
/*::
type User = {
  name: string,
  verified: boolean,
  email: string,
};
*/

function isUserVerified(user /*: User */) /*: boolean */ {
  return user.verified
}

isUserVerified({name: 1, verified: true, email: 69 }) // error
```

The TypeScript "compiler" essentially acts as a linter upon these suggestions. In fact I'm pretty sure it's possible for a really good ESLint parser+plugin combo to do the entirety of the job TS does. 

I said put the damn gun down, James. Listen.

The issue with TypeScript that is unsolvable by design is the fact that it has to compile down to JS. There's nothing you can do about it. This thing doesn't count cause you're not going to use it.

This Javascript compatibility requirement heavily hinders the evolution of TypeScript's type system and language features, as they must not conflict with those of JavaScript. As much as we might want a `do { try? await } catch {}` type flow control feature in TS, it's just not going to happen until it's either in the language or in Babel (which can be an entire topic of it's own).

Nowhere is this more apparent as with TS enums, which I have always said are a complete joke and should be avoided. Enums are a perfect example of a language feature that TypeScript attempted to implement which simply does not work due to it having to be compatible with the dynamic language it has been bolted onto.

Consider this example in Swift, a language actually designed with static typing in mind:

```swift
enum Permission {
  case viewer
  case editor
  case admin
}

enum UnrelatedShit {
  case something
  case weDont
  case careAbout
}

// ...

let value1: Permission = .viewer // syntax, because the language knows what enums are
let value2: UnrelatedShit = .something

print(value1 == value2) // will always be false because duh-doy, obviously
```

Now, let's see how the same code written in TypeScript would fare:

```ts
enum Permission {
  Viewer,
  Editor,
  Admin,
}

enum UnrelatedShit {
  case Something
  case WeDont
  case CareAbout
}

const value1 = Permission.Viewer // ew
const value2 = UnrelatedShit.something // ewww

console.log(value1 === value2) // will evaluate to 'true', because both "enums" desugar into [0, 1, 2]
console.log(value1 === 0) // 'true', lmao what
```

Desugaring into JS also requires types to be nuked at build time, making the actual code that runs in the browser/node runtime ultimately unaware of types. Which means that as soon as you use an `any`, you render the entire point of TS moot, because your precious "type safety" doesn't exist in the code you're running.

This is very clearly observed when working with JSON, say, from API responses you don't control. In Swift, if an object you're decoding doesn't properly conform to the `Codable` struct defined for it, it throws at runtime. In JS, your code will execute normally in all of its `undefined` glory, because types do not exist at runtime and you're using a dynamic language.

The language you're writing is Javascript. You can convince yourself of it not being the case because "uhm the compilation step is abstract, I'm totally writing a language with types", you just aren't.

It can be a good thing, it can be a bad thing but the unquestionable thing is the fact that there is no universally agreed upon approach to using static types in JavaScript. Teams will always have config disparities and use TS differently. Here, try a little experiment. Open a few open source projects on GitHub written in TypeScript and compare their TS configs. What do you see?

The fact that there is a concept of `tsconfig` at all is a huge issue, because what's an error in one codebase is totally fine in another. This is not an issue in real languages with type systems because the type system is coupled to the language itself and the way it works is universal. There's no `// @golang-expect-error`, and while there is an `Any` in Swift, it doesn't mean "yeah idk, runtime will probably figure it out, our language can multiply an array by string, something will happen, maybe" (no, seriously, how on earth is `[] - 2 * "2"` even legal syntax), it still requires you to handle it properly at runtime.

Remember how JS is still the language you're actually writing? Yeah well, not everyone is as enlightened and some people just write JS as is. Many of your dependency authors do, in fact.

There's nothing wrong with their code, it's perfectly functional, but for TypeScript to know what to do with it, someone must tell it. If it's not done by the library developer, it has to be done either by the community via DefinitelyTyped, or you. 

Those last two are not a thing in real typed languages because, once again, the type system isn't haphazardly bolted onto the language.

I will literally never shut up about this. Probably the biggest joke in modern software engineering is "enums" that desugar into an array of integers. It should be extremely apparent why this is horrendously bad.

TypeScript Is a Documentation/Refactoring Tool

What TS is, and what it's actually really good for, is documenting your code. Think of it as JSDoc with a linter built-in, because, and once again, put the gun down, it's exactly what it is.

TypeScript helps to understand what the code does/expects after you haven't looked at the code for a while. It helps to jump into an unfamiliar codebase and get around quickly. It does everything JSDoc does in a more concise fashion, unless you get too ridiculous with it. 

TypeScript is also very good at telling you which function call you forgot to refactor after you changed its argument structure. Not as good as languages with named arguments, but good nonetheless.

I absolutely love TS for these aspects. It is helpful and it does save time. When it works. The problem is, very often it doesn't because it simply isn't as smart as a real typed language. 

What I would really love for us to do as web developers is to stop religiously obsessing over the tools we use. My approach is not more gooder than your approach and your approach isn't less worser than DHH's approach. Some tools are good, some tools are shit. Some tools are good at some things and shit at others. 

There's a metric ton of extremely large, extremely successful software written in Ruby, JS and many other languages with no typing at all. And that's fine.

If you find yourself spending an hour trying to get past a TS error when you absolutely know better and actual Javascript code works, use an `any`. It's fine.

Web dev would be a better place if people who call themselves "TypeScript developers" and look down upon the typeless plebs got off their fucking high horse, because once your "compiler" strips types away, you're no different from everybody else. 

You write Javascript, like all of us do. Accept it and get over it.

TypeScript vs plain JavaScript conversation seems to never end, so I thought I'd share my thoughts on why I love TS while also passionately hating it.

Want to know how to make this sweet looking grid in SwiftUI in under 5 minutes? Keep reading ;)

Use FlowGrid package. Or! Or! Keep reading to see how it was made and maybe you'll find some of it useful for whatever you're working on.

I've been playing with SwiftUI in my spare time for a while. After working with React for 5 years, SwiftUI feels very exciting because it's basically React, but will all the missing stuff added in. And native! 

So I wanted to have an image grid in SwiftUI. As of this writing, there are a few options for achieving grids:

Introduced in SwiftUI 2.0, LazyVGrid and LazyHGrid are "Apple Certified" ways to make a grid in SwiftUI. And they're great for general purpose grids where your layout is at least somewhat predictable.

Unfortunately for dynamic data, such as photos with variable dimensions, this method doesn't work.

There are a number of SwiftUI grid packages out there, the most popular being Exyte Grid. It offers quite a bit more control over the layout than LazyVGrid/LazyHGrid, but unfortunately it suffers a similar problem. All the customizability it provides requires you to know the size of your grid tracks ahead of time. We're trying to achieve something that's fully dynamically capable.

So I needed another option. After some investigating, by which I mean googling dozens of combinations of "swiftui", "flow" and "grid", I came up on two resources that made it click for me. This Flexible Layouts in SwiftUI article and this CollectionView package by The Noun Project which has the exact implementation we need, but isn't SwiftUI. Luckily, we can combine the approaches! So let's get into it.

First things first, we need to create a wrapper view. We need it to measure the dimensions the grid will operate within.

```swift
// FlowGrid.swift
import SwiftUI

public struct FlowGrid<Data: Collection, Content: View>: View where Data.Element: Hashable {
  private let items: Data
  private let rowHeight: CGFloat // Baseline row height
  private let spacing: CGFloat // Spacing between cells
  private let disableFill: Bool // Whether or not to fill horizontal space
  private let content: (Data.Element) -> Content

  @State private var viewportWidth: CGFloat = 0

  public init(items: Data, rowHeight: CGFloat, spacing: CGFloat, disableFill: Bool, content: @escaping (Data.Element) -> Content) {
    self.items = items
    self.rowHeight = rowHeight
    self.spacing = spacing
    self.content = content
    self.disableFill = disableFill
  }

  public var body: some View {
    ZStack(alignment: Alignment(horizontal: .leading, vertical: .center)) {
      // Read and store the viewport width before we get started
      Color.clear
        .frame(height: 1)
        .readSize { size in
          viewportWidth = size.width
        }

      // This view will be our actual implementation
      FlowGridView(
        viewportWidth: viewportWidth,
        items: items,
        rowHeight: rowHeight,
        spacing: spacing,
        disableFill: disableFill,
        content: content
      )
    }
  }
}
```

Now, you might be thinking "Hey, Max, there isn't a readSize modifier 🤔

```swift
// View+readSize.swift
import SwiftUI

extension View {
  // The scale factor, once we know it, needs to be accounted for.
  // Otherwise we will confuse the size reader when we apply the size adjustment
  func readSize(_ scaleFactor: CGFloat = 1, onChange: @escaping (CGSize) -> Void) -> some View {
    background(
      GeometryReader { geometryProxy in
        Color.clear
          .preference(key: SizePreferenceKey.self, value: CGSize(width: geometryProxy.size.width / scaleFactor, height: geometryProxy.size.height / scaleFactor))
      }
    )
    .onPreferenceChange(SizePreferenceKey.self, perform: onChange)
  }
}

private struct SizePreferenceKey: PreferenceKey {
  static var defaultValue: CGSize = .zero
  static func reduce(value: inout CGSize, nextValue: () -> CGSize) {}
}

```

There's one important thing to note here that I wasn't able to solve, which is that, the grid will expect it's children to stay still. If there's a view that appears on hover that widens the frame of a cell, SwiftUI will be confused trying to re-measure and re-adjust and if the conditions are just right, your app will hang.

So make sure whatever views you render inside the grid all behave such that the bounds stay what they are on first render.

So here's what we need to do to make our grid happen.

Create a cell for an item of our data with a set row height

Repeat this until there isn't enough width for the next element

Scale the previous row up to fill the leftover width

```swift
// FlowGridView.swift
import SwiftUI

// We don't know the scale factor before the row is built, it defaults to `1`
private struct FlowRow<T>: Hashable where T: Hashable {
  var items: [T]
  var scaleFactor: CGFloat = 1
}

// Main grid view
struct FlowGridView<Data: Collection, Content: View>: View where Data.Element: Hashable {
  let viewportWidth: CGFloat
  let items: Data
  let rowHeight: CGFloat
  let spacing: CGFloat
  let disableFill: Bool
  let content: (Data.Element) -> Content

  // Store sizes of the items as we render them, it's going to be important later
  @State var itemSizes: [Data.Element: CGSize] = [:]

  var body : some View {
    let rows = calculateRows()

    // Sorry, <11.0 users, scroll performance is really shit otherwise :/
    LazyVStack(alignment: .leading, spacing: spacing) {
      ForEach(rows, id: \.self) { row in
        HStack(spacing: spacing) {
          ForEach(row.items, id: \.self) { element in
            content(element)
              .frame(height: disableFill ? rowHeight : rowHeight * row.scaleFactor)
              .fixedSize()
              .readSize(row.scaleFactor) { size in // Size reader needs to be aware of the scale factor
                itemSizes[element] = size
              }
          }
        }
      }
    }
  }
}
```

Now you might be thinking, "Hey, Max, there isn't a calculateRows function.

And you're right. So let's write it. This is where all of the magic happens.

```swift
// FlowGridView.swift

func calculateRows() -> [FlowRow<Data.Element>] {
  var rows: [FlowRow<Data.Element>] = [.init(items: [])] // Start with a blank array of grid items
  var currentRow = 0 // Keep track of the row we're currently at
  var remainingWidth = viewportWidth

  for item in items {
    // Get the element size we measured in the parent component
    let elementSize = itemSizes[item, default: CGSize(width: viewportWidth, height: 1)]

    // If we have space in the row to fit the width of the item, dew it
    if remainingWidth - elementSize.width >= 0 {
      rows[currentRow].items.append(item)
    } else {
      // Otherwise, we're done with the row, so let's do some math
      // First, let's calculate the total width of all items in the row so far
      let totalWidth = rows[currentRow].items.reduce(0) {
        $0 + itemSizes[$1, default: CGSize(width: viewportWidth, height: 1)].width
      }
      // Now calculate the vertical scale factor, that will ensure that leftover horizontal space is filled completely
      // and write it to the row
      rows[currentRow].scaleFactor = viewportWidth / totalWidth

      // Move on to the next row
      currentRow = currentRow + 1
      rows.append(.init(items: [item], scaleFactor: 1))
      remainingWidth = viewportWidth // Remember to reset the remaining width on a new row 
    }

    // Update remaining width
    remainingWidth = remainingWidth - elementSize.width
  }

  return rows
}
```

The grid will nicely adjust to different scales, window resizing, etc. So long as the cell dimensions don't change, which they really shouldn't.

Hope at least some of this was useful. Be sure to check out the FlowGrid package which implements everything that's written here + convenient initializers and hit me up on Twitter if you have any questions.

Making a row-based image grid that automatically moves to the next row and (optionally) fills blank horizontal space, also known as "Flow Layout", in SwiftUI.

Max's Coding Blog

Thoughts on TypeScript

Flow Grid in SwiftUI