3 ms·

At the expense of coupling which is not a trivial concern. Regardless, the browser is the only platform capable of using those types (even so the types aren't

At the expense of coupling which is not a trivial concern. Regardless, the browser is the only platform capable of using those types (even so the types aren't shared but generated). You don't use those types in Swift or Java or Kotlin. You don't use those types in a python client library.

danielvaughn 5y ago
In my experience this coupling cannot be avoided. At a bare minimum the client has to know the communication protocol of the server. This means you typically need to define this protocol in both the server and client. If you could define it once and have both the client and server pull from the single source, it's a win.
- stickyricky 5y ago
  The coupling is to the data interchange format. The server is not coupled to the client and the client is not coupled to the server.
wruza 5y ago
What expense?
The_rationalist 5y ago
throw10920 5y ago
Why does adding types result in any more coupling than what exists already? If your client and server both treat field "temperature" as a string for protocol version 1, and then the client upgrades to protocol version 2 and temperature is now a float, the server has to be modified anyway, type system or no type system, because otherwise it'll break. If anything, the type system helps to expose the fact that the client and server now disagree about the type of a field, which is helpful.
- stickyricky 5y ago
  > Why does adding types result in any more coupling than what exists already? Because the client and server now share a code base. The client requires the server to run. > If your client and server both treat field "temperature" as a string for protocol version 1, and then the client upgrades to protocol version 2 and temperature is now a float, the server has to be modified anyway, type system or no type system, because otherwise it'll break. If the data interchange format changes then yes both the client and server need to change. But if either the client or the server wants to coerce temperature to a different type they are free to do so. As long as the conform to the interchange format the internal representation of the data is irrelevant to third-parties. In a world where types are shared, updates to the server necessitate updates to the client even if the client doesn't want to change (and vice-versa). > If anything, the type system helps to expose the fact that the client and server now disagree about the type of a field, which is helpful. The coupling should receive the credit not the type system. Regardless this undoubtedly true. Two isolated pieces of code don't know what the other is doing. You need to test and you need to write design docs.
  - lucas_codes 5y ago
    Much of the point of TS is to make make this kind of refactoring easier, and it doesn't prevent coercing the data format later at all.
  - throw10920 5y ago
    > Because the client and server now share a code base. This isn't true. Types aren't "a code base", they're an interface - without which it is impossible for a client and server to talk with each other anyway. > The client requires the server to run. Not relevant. Nothing about a typed interface prevents the client from running without having a running server - it won't be very useful without something to exchange data with, but you can still run it, unless you've coded otherwise. > But if either the client or the server wants to coerce temperature to a different type they are free to do so. No, type coercions are bad engineering. They're brittle and only work in a very tiny number of situations - nothing approaching the general case. > As long as the conform to the interchange format the internal representation of the data is irrelevant to third-parties. Type coercions at the interface level are a hack that is not acceptable for anything beyond hobbyist work. An interchange format is a set of types. Types are not internal representation - they're a mathematical concept used in type-checking. Types happen to be used in the process of generating an internal representation of data, but that's not what they are. You're falsely equating the two, and your point is invalid without that equivalence. > In a world where types are shared, updates to the server necessitate updates to the client even if the client doesn't want to change (and vice-versa). This is false. If the server is changed, the client only needs to change if the interface between the two also changes. If the server makes a change to its internal data storage format, then that has nothing to do with the client, and so the interface stays the same, and so the shared type declarations/schema stay the same. If the interface changes, then you already have to update both client and server, so the tiny overhead of maintaining an explicit type schema dwarfed by the amount of effort you spent changing the rest of the code anyway, and more than made up for by the compile-time detection of warnings when you change the interface code for the server, compile, and then get an error that the client no longer compiles. > The coupling should receive the credit not the type system. A type system will detect type errors at compile-time. A tightly-coupled system with type coercion and no types will detect errors at run-time, if at all. It's obviously better to detect errors at compile-time. Therefore, even if coupling is correlated with the usefulness of a type system, type systems are still obviously beneficial to include. Regardless, it doesn't make any sense to talk about "credit" in this case. I think that you misunderstand the purpose (and utility) of type systems, but I'm not sure what to suggest to you so that you can understand.
afavour 5y ago
> Regardless, the browser is the only platform capable of using those types That and a Node/Deno backend. Which is what the OP is talking about.

danielvaughn 5y ago

In my experience this coupling cannot be avoided. At a bare minimum the client has to know the communication protocol of the server. This means you typically need to define this protocol in both the server and client. If you could define it once and have both the client and server pull from the single source, it's a win.

stickyricky 5y ago
The coupling is to the data interchange format. The server is not coupled to the client and the client is not coupled to the server.

wruza 5y ago

What expense?

The_rationalist 5y ago

throw10920 5y ago

Why does adding types result in any more coupling than what exists already? If your client and server both treat field "temperature" as a string for protocol version 1, and then the client upgrades to protocol version 2 and temperature is now a float, the server has to be modified anyway, type system or no type system, because otherwise it'll break. If anything, the type system helps to expose the fact that the client and server now disagree about the type of a field, which is helpful.

stickyricky 5y ago
> Why does adding types result in any more coupling than what exists already? Because the client and server now share a code base. The client requires the server to run. > If your client and server both treat field "temperature" as a string for protocol version 1, and then the client upgrades to protocol version 2 and temperature is now a float, the server has to be modified anyway, type system or no type system, because otherwise it'll break. If the data interchange format changes then yes both the client and server need to change. But if either the client or the server wants to coerce temperature to a different type they are free to do so. As long as the conform to the interchange format the internal representation of the data is irrelevant to third-parties. In a world where types are shared, updates to the server necessitate updates to the client even if the client doesn't want to change (and vice-versa). > If anything, the type system helps to expose the fact that the client and server now disagree about the type of a field, which is helpful. The coupling should receive the credit not the type system. Regardless this undoubtedly true. Two isolated pieces of code don't know what the other is doing. You need to test and you need to write design docs.
- lucas_codes 5y ago
  Much of the point of TS is to make make this kind of refactoring easier, and it doesn't prevent coercing the data format later at all.
- throw10920 5y ago
  > Because the client and server now share a code base. This isn't true. Types aren't "a code base", they're an interface - without which it is impossible for a client and server to talk with each other anyway. > The client requires the server to run. Not relevant. Nothing about a typed interface prevents the client from running without having a running server - it won't be very useful without something to exchange data with, but you can still run it, unless you've coded otherwise. > But if either the client or the server wants to coerce temperature to a different type they are free to do so. No, type coercions are bad engineering. They're brittle and only work in a very tiny number of situations - nothing approaching the general case. > As long as the conform to the interchange format the internal representation of the data is irrelevant to third-parties. Type coercions at the interface level are a hack that is not acceptable for anything beyond hobbyist work. An interchange format is a set of types. Types are not internal representation - they're a mathematical concept used in type-checking. Types happen to be used in the process of generating an internal representation of data, but that's not what they are. You're falsely equating the two, and your point is invalid without that equivalence. > In a world where types are shared, updates to the server necessitate updates to the client even if the client doesn't want to change (and vice-versa). This is false. If the server is changed, the client only needs to change if the interface between the two also changes. If the server makes a change to its internal data storage format, then that has nothing to do with the client, and so the interface stays the same, and so the shared type declarations/schema stay the same. If the interface changes, then you already have to update both client and server, so the tiny overhead of maintaining an explicit type schema dwarfed by the amount of effort you spent changing the rest of the code anyway, and more than made up for by the compile-time detection of warnings when you change the interface code for the server, compile, and then get an error that the client no longer compiles. > The coupling should receive the credit not the type system. A type system will detect type errors at compile-time. A tightly-coupled system with type coercion and no types will detect errors at run-time, if at all. It's obviously better to detect errors at compile-time. Therefore, even if coupling is correlated with the usefulness of a type system, type systems are still obviously beneficial to include. Regardless, it doesn't make any sense to talk about "credit" in this case. I think that you misunderstand the purpose (and utility) of type systems, but I'm not sure what to suggest to you so that you can understand.

afavour 5y ago

> Regardless, the browser is the only platform capable of using those types That and a Node/Deno backend. Which is what the OP is talking about.