3 ms·

The client has to adhere to the shape of the JSON that the API is generating anyway. Defining those types just makes it easier to avoid mistakes. There's no rea

The client has to adhere to the shape of the JSON that the API is generating anyway. Defining those types just makes it easier to avoid mistakes. There's no reason that need to be any more rigid than the API would otherwise be.

jondubois 9y ago
But the schema can change over time with different API versions. So you need different schemas on the front end for different versions of the API? It just seems like a lot of hassle when ultimately all you need to do is get a string property from the API and put it in a textbox.
- bitoneill 9y ago
  Microsoft addressed this and says Typescript is most beneficial to manage large code bases
  - jondubois 9y ago
    I've worked with TypeScript on large code bases. I found that the compile step becomes really slow and it slows down the debug cycle. On my last large project, I had to wait 10 to 15 seconds for the code to build every time I saved the file (and yes the compilation step was optimized to only include relevant code; a large number of dependencies don't help). So every time I made a change to the code to check something, I had to wait... You can't use console.log() to quickly check stuff anymore; the compile overhead is so significant that you're forced to pull up the debugger and manually step through the relevant code every single time you want to check something (you want to get as much info as possible from each debug cycle because it's so slow). When writing plain JavaScript, I only pull up the debugger when it's a particularly difficult bug (e.g. a race condition). For most bugs, I can get all the information I need with just a couple of calls to console.log() in my code. The debugger is just unwieldy.
    - bitoneill 9y ago
      I used to be a c++ dev so a 15 sec compile time doesn't seem that bad. But what if you're compiler told you what was wrong faster than your console.log() could help you find it. I think is a trade off a lot of people want to make.
      - jondubois 9y ago
        I agree, that makes sense for C/C++ because working with pointers and dynamic memory is a lot more complicated - Types make sense for C/C++ because the focus is execution speed and flexibility (not development productivity). The case you describe very rarely happens to me with JavaScript; having fewer primitives to work with greatly reduces these kinds of issues... Sure it opens up the possibility that you'll do something stupid like trying to add an object with a string; but that's a pretty silly thing to do. If you name your variables properly then that never happens. With C/C++, there are many primitives so you might get errors when you try to assign an int64 to an int8 (for example)... With JS, however, because there are fewer primitives so the odds of that happening are much much smaller. Because there are so few primitives in JS, it's easy to remember how they all interact with each other. The only exception is the boolean truth table for '==' (which is a mess); that's why it's usually recommended to use '===' instead.
- skybrian 9y ago
  The simple thing would be to avoid making incompatible changes to the public API. If you keep the same schema and loosen the types a bit (accepting more kinds of requests) then there's no need to have more than one schema. But you're describing a fairly complicated scenario where you have multiple public API's with different request types, internal data (hopefully canonicalized at the border) and response types. How do you keep track of all that data conversion without types?
- ascorbic 9y ago
  If the schema is changing you'll need to document it and change the client code anyway. If you're able to auto-generate a schema then that's a hell of a lot easier.

jondubois 9y ago

But the schema can change over time with different API versions. So you need different schemas on the front end for different versions of the API? It just seems like a lot of hassle when ultimately all you need to do is get a string property from the API and put it in a textbox.

bitoneill 9y ago
Microsoft addressed this and says Typescript is most beneficial to manage large code bases
- jondubois 9y ago
  I've worked with TypeScript on large code bases. I found that the compile step becomes really slow and it slows down the debug cycle. On my last large project, I had to wait 10 to 15 seconds for the code to build every time I saved the file (and yes the compilation step was optimized to only include relevant code; a large number of dependencies don't help). So every time I made a change to the code to check something, I had to wait... You can't use console.log() to quickly check stuff anymore; the compile overhead is so significant that you're forced to pull up the debugger and manually step through the relevant code every single time you want to check something (you want to get as much info as possible from each debug cycle because it's so slow). When writing plain JavaScript, I only pull up the debugger when it's a particularly difficult bug (e.g. a race condition). For most bugs, I can get all the information I need with just a couple of calls to console.log() in my code. The debugger is just unwieldy.
  - bitoneill 9y ago
    I used to be a c++ dev so a 15 sec compile time doesn't seem that bad. But what if you're compiler told you what was wrong faster than your console.log() could help you find it. I think is a trade off a lot of people want to make.
    - jondubois 9y ago
      I agree, that makes sense for C/C++ because working with pointers and dynamic memory is a lot more complicated - Types make sense for C/C++ because the focus is execution speed and flexibility (not development productivity). The case you describe very rarely happens to me with JavaScript; having fewer primitives to work with greatly reduces these kinds of issues... Sure it opens up the possibility that you'll do something stupid like trying to add an object with a string; but that's a pretty silly thing to do. If you name your variables properly then that never happens. With C/C++, there are many primitives so you might get errors when you try to assign an int64 to an int8 (for example)... With JS, however, because there are fewer primitives so the odds of that happening are much much smaller. Because there are so few primitives in JS, it's easy to remember how they all interact with each other. The only exception is the boolean truth table for '==' (which is a mess); that's why it's usually recommended to use '===' instead.
skybrian 9y ago
The simple thing would be to avoid making incompatible changes to the public API. If you keep the same schema and loosen the types a bit (accepting more kinds of requests) then there's no need to have more than one schema. But you're describing a fairly complicated scenario where you have multiple public API's with different request types, internal data (hopefully canonicalized at the border) and response types. How do you keep track of all that data conversion without types?
ascorbic 9y ago
If the schema is changing you'll need to document it and change the client code anyway. If you're able to auto-generate a schema then that's a hell of a lot easier.