kamilafsar

That's pretty insane Dimitri. If you like stuff like this I really recommend Dimitri's TypeScript challenges series: https://www.youtube.com/playlist?list=PLOlZuxYbPik180vcJfsAM...

This sounds like a marketing post for this feature to me.

That’s not a downside. That’s part of building and being a team. We’re human, not machines. If you hire the right people, they’ll know when to have a laugh and when to work their ass off.

I personally hate the TS bindings. That's one of the reasons that drove me to create Phero: https://phero.dev

I think the majority of people here understands the commercial considerations Apple makes.

But you asked what would you expect. At least don’t block me to update. Tell me it’s not officially supported. But let me install whatever OS I want, at my own risk.

The problem is not even the OS. It’s the whole ecosystem of apps that require a certain OS version.

I’m stuck on 10.13 with my iMac from 2012. The hardware serves me well, it does exactly what I need it to do. I’m just stuck on an old OS.

I’m gonna try OpenCore legacy patcher for sure.

There is a difference with approaches like openapi/swagger/graphql though.

With Phero you define your models with plain TS. Our code-gen will "just" copy the exact same models to your client SDK. The DX is night and day.

We believe domain models are the most important part of your codebase. We don't like to define them in an intermediate language like graphql/swagger/graphql/you-name-it.

Because we support plain TS as "input" if you will, you can use all features and greatness TS comes with. Like generics, conditional types, mapped types, even template literal types!

Yes, Phero has a build step. Phero does come with a CLI and will watch code changes, build your TS alongside with an client SDK.

In our experience the latency between changing something in your API, and seeing compile errors arise in the client is just a few seconds. And this only matters when your API contract changes, which is of course not always. Not a biggy in our eyes. In order to run, you'd need to compile TS anyways. :)

In our opinion this is well worth the "magic" Phero adds: it will work with plain TS. No "t.string" like apis to build your apis/models. Matter of taste I guess :)

Good point!

We use Phero extensively in mobile apps projects, so we know the pain of maintaining API versions and backward compatibility hell.

Phero generates a declaration file with all functions you expose, and bundles dependent domain models (interfaces, type aliases, enums, etc) with it. Currently there's only one version. Our plan is to let users pin versions of this declaration file (we call it the manifest file).

Then we build cli commands to compare them and actually tell if they are compatible. This way you know if it's safe to deploy a new version of your API without breaking existing clients. These are all future plans of course, but in the scope of the project.

Shameless plug: I’m one of the authors of Phero [1]. It’s goal is similar to tRPC: fullstack typesafety between your server and client(s).

One difference is syntax: Phero leverages the TS compiler api to generate parsers for your backend functions. It will parse input and output of your api functions, automatically, based on the types you define for your functions. It will generate a declaration file of your api and generate an RPC style client SDK for your frontend. Another difference is that it aims to be more batteries includes.

[1] https://github.com/phero-hq/phero

Comparison: https://phero.dev/docs/comparisons/tRPC

The relevant TS feature is called template literal types:

https://www.typescriptlang.org/docs/handbook/2/template-lite...

Yeah agree 100%.

Unless you’re implementing a standard, software engineering is 50% communication with peers/clients/users, if not more..

Please keep in mind, he didn't send you there personally. The algorithm did. I've experienced this several times my self, very frustrating and sometimes even dangerous. I think it's unavoidable if you take into account that they operate on planet-scale. Not saying that they can't do better, but probably it's not "someone's" fault.

I wonder what the correlation between consistency of written/spoken language is for the breakdown per language here: https://github.com/openai/whisper/blob/main/language-breakdo...

For instance, I know Turkish is very consistent: it was refactored in 1928 with the birth of Turkey. Turkish is quite high in the rankings. I don't think because there's loads of data available, but because of its consistency. Contrary, English has loads of data, which should compensate for it inconsistency.

But then in “userland”..

So you could use it on a chromebook as well.

I like the idea, and as PG often says the best ideas often sound crazy at first.

Glad someone other than me is trying I guess :-)

Shameless plug to my project Phero [0]. It’s a bit like gRPC but specifically for full stack TypeScript projects.

It has a minimal API, literally one function, with which you can expose your server’s functions. It will generate a Typesafe SDK for your frontend(s), packed with all models you’re using. It will also generate a server which will automatically validate input & output to your server.

One thing I’ve seen no other similar solution do is the way we do error handling: throw an error on the server and catch it on the client as if it was a local error.

As I said, it’s only meant for teams who have full stack TypeScript. For teams with polyglot stacks an intermediate like protobuf or GraphQL might make more sense. We generate a TS declaration file instead.

[0] https://github.com/phero-hq/phero

I was shocked when he "knew" I had a sodastream.

I wanted to believe this thing so badly. It had nice things to say about me.

One of the benefits of these extra steps is being able to use enums.

Using enums is not really that different from using type aliases. It’s a nicer way to write string/number values.

Interesting, we’re the opposite: use enums where possible. We think it adds more clarity to the reader.

Besides, sometimes number values make more sense then string values. Especially when you want to do bitwise operations, which are not possible on string unions.

Smart move to be compatible with TypeScript’s declaration files.

Not sure if this provides me enough benefit to move from TS. On the contrary it removes “non JS” features like enums. I can’t live without enums..

For me moving farther away from my family has been key to spend more time with them.

They live about 150km away from me. Because it’s a relative long distance they will always sleep over when they come (and me when I go to them), and we get to spend the weekend together in one house.

My brother, who lives in the same city, meets them more often but for just an evening or afternoon. He always complains I get to spend more time with them even though he lives 10m away.

BTW, I realize that 150km would be “close” for US and other big countries. In the Netherlands that’s the difference between east and west. :-)

Whoa, that’s so similar to our project [1] it’s almost scary :)

How are errors handled though? What happens when you “throw Abort()”.

https://github.com/samen-io/samen

> The name "Hotmail" was chosen out of many possibilities ending in "-mail" as it included the letters HTML, the markup language used to create web pages (to emphasize this, the original type casing was "HoTMaiL").

https://en.wikipedia.org/wiki/Outlook.com

Ahh.. never knew that's where the name comes from.

Haha, oops, in Dutch it means "together".

Hi HN!

After years of lurking and reading, I'm thrilled to post my very first Show HN.

We are a small development agency from the Netherlands, we build web apps, mobile apps and API's for our clients. All with TypeScript. For most of our projects we are responsible for both client (app) and server (api).

We used to do this with express and similar frameworks. In this situation you need to write code for your client to call the API, parse the incoming data on the backend, and then there is always hassle sharing your models between client and server.

Since about a year or two we use our home grown backend development kit we call Samen, and never ever looked back. Samen has a minimal API (just one function) with which you export functions in a special file called "samen.ts" in your source code. Samen will analyse your exported functions and generate an SDK for you. The SDK will include the models you use, and all the endpoints as regular async functions.

We're very excited to get feedback from the HN community.

Thanks! Yes, it will do that automatically by generating an SDK for your client (which will include all types you expose on your backend).

Wow, what a coincidence :D We are about to launch something similar: https://samen.io

I guess not all land is the same. Undeveloped land around NYC is scarce, and that’s where you want to have solar panels for the city.

People like to hate everything related to JS these days. But when I see libs like these I'm just very grateful for the person(s) who invented JSX [1]. And evenly for MSFT implementing it into TS as a first-class citizen. It's just so much more readable.

Scala is the only other language I know of which has some kind of XML/HTML syntax support (scala.xml). (But it looks like it got removed. [2])

[1] https://reactjs.org/docs/introducing-jsx.html

[2] https://github.com/scala/scala-xml

Wow, thanks so much for sharing your learning journey here. Gonna bookmark this comment.

AFAIK Amazon as a company is not really open sourcing a lot of their software. I was surprised that they would open source such a key component of their Lambda offering.

As someone here already mentioned, it certainly helped Fly.io steeling some of their customers. (Although Fly has no serverless offering, but uses it for a docker-ish deployment model.) And last time I checked there were a few more startups using it.

Can anyone (maybe Amazon folks here) shed a light on the rationale behind it, why they’d open sourced it and what they could possibly gain by it?