This composability was also a defining feature of Launchbar.
I loved it, but eventually found that Raycasts approach of having predefined plugins for each use case is more performant , discoverable and usable.
Kinda like how the unix philosophy was beaten by integrated full-stack applications.
* since anything can be composed, everything must be in the same search index. This slows down the index, and means you need to sift through more irrelevant results.
I felt so vindicated when Halide finally released Process Zero, years after the iPhone 13.
I still remember that 50-page community thread of people complaining about the ugly camera, and one guy swearing up and down that “it's fine, it's fine you're all wrong”.
> It's your *expectations* that are wrong, not the phone. If you go out and buy a "professional" $6000 DSLR and $6000 lens… you will have many of these same issues.
Then Process Zero comes and solves all of my issues...
The biggest immediate win that we can achieve for our users is to remove all (!) technical jargon from our landing pages and product ui.
This is a problem throughout all FOSS. For example in KDE:
> Do x when Plasma starts.
Wtf do I care what Plasma is. Oh, you mean my computer? Yeah makes sense.
Raycast: You can search files, have a calculator, a translator…
KRunner: You can run terminal commands and convert characters to hexadecimal.
It is so obvious that these products are designed by developers for developers. From my experience, this friction is everything. You cannot expect people to intuitively figure it out.
We also had a bunch of problems. The DNS resolution didn't work, and support was unable to figure out the reason.
A coworker reported domain access breaking when he went to office 1, but fixed itself when he went to office 2.
For a while, when you logged in with the wrong account, it was near impossible to replace it. This on is fixed now, but the entire thing still feels very much like paying for beta software.
The no-unsafe-* type-aware eslint rules are important.
Even with strict mode and noImplicitAny, secret any's can sneak into the codebase for the weirdest reasons (for example, poorly typed libraries. looking at you, Knex).
And also don’t tip your waiters because that just helps the owner /s.
I work in a Windows-dependent company, and would very much like to see all MS-products thrown out. Withholding features is ignorant and will make everyone’s lives miserable. Users won’t see it as a problem with Microsoft, they might not see it as a problem at all, they will just quietly suffer.
A slightly better path is to guide users to standardized, open applications on Windows. Then, an admin might have an easier time eventually pulling the cord without breaking too many workflows.
As a single anecdote, I will say that when I personally migrated from Windows to Linux, it was a lot easier because I was already using mostly FOSS applications. It turns out, if you use Windows to run Firefox and Libreoffice and whatever, there's a lot less friction to using Linux to run Firefox and Libreoffice and whatever:)
Have you engaged with the advanced features? TS is the only mainstream language that lets you express pretty much everything in the typesystem, to the point where I frequently have to hold myself back.
Having used Swift and Kotlin in the past, their typesystems don’t come close to the flexibility with which you can wrangle data in TS. Many concepts that I would consider fundamental are either not present or require complicated syntax eg.: product types A & B, sum types A | B, { …spreading }.
And where Swift needs custom syntax such as `guard let` and `case let` to narrow types, Typescript is able to analyze normal control flow.
For practical reasons, there are a ton of ugly workarounds, but I’d rather live with those than go back to the rigid “Java++” languages.
those are intersection types and union types and are much more unique and rare in type systems eg all typed functional languages have product/sum types but typescript is the only mainstream language I know to have unions and intersection.
The problem is the type system is not strong, where structural typing can cause a lot of issues, such as adding a property to an object for example and the typechecker will not care. This does not happen in more strongly, non-structural typed languages.
Yeah that's one of the practical workarounds I mentioned. It mostly comes up while spreading (which is why spreads should usually go first) and when persisting (which is why your ORM should have a runtime schema).
But it's a double edged sword:
- You can brand types with additional information. For example, React Query does this to keep track of which type is stored under which cache-key. This is where most strongly typed languages just give up.
- You can progressively extend/narrow types without having to worry about inheritance. Invariants can be statically checked by encoding them in a type: eg IssuedInvoice = Invoice & { … }. A function that needs only a subset of a domain-object can specify this rather than requiring the email-address to verify a phone number.
- You can even emulate nominal types using keyed unions.
The first two alone have saved me from more errors than structural typing introduced.
I loved it, but eventually found that Raycasts approach of having predefined plugins for each use case is more performant , discoverable and usable.
Kinda like how the unix philosophy was beaten by integrated full-stack applications.
* since anything can be composed, everything must be in the same search index. This slows down the index, and means you need to sift through more irrelevant results.
reply