Our great sponsors
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
bagel
A reactive and strongly-typed, but also pragmatic, new programming language. Compiles to JavaScript, designed to be comfy for people used to the JavaScript/TypeScript language and ecosystem.
-
If you'd like the Amazon JavaScript SDK to support Deno then make your support known on this thread:
I’m really strongly rooting for Deno. I’m even implementing my current passion-project on it (https://github.com/brundonsmith/bagel). But I have a couple of significant (but solvable!) criticisms, if anybody on the team is here.
1) The documentation for the standard APIs is extremely wanting. The main, and weirdest, problem is that it seems almost impossible for search engines to index (or at least DDG). I can search for very very specific things, and still get kicked to the home page and have to manually navigate to the part I’m looking for (and the navigation is also pretty difficult; I often can’t find the thing at all and have to rely completely on editor hover-overs for documentation). It can also be confusing- some things like certain standard APIs appear to have multiple conflicting reference-manuals? And it can be hard to know which one is current or correct. Even getting past all the obfuscation, the docs are just ok. They often leave out deeper details (this last part is less of a problem and more understandable, this being a young project).
2) The VSCode extension still needs work. It’s usable, and better than nothing, and it’s better than it used to be, but (ordered from most to least significant):
- When I open certain files - usually bundles or something; maybe files outside of the project directory? - the language server crashes over and over and over, each time popping the terminal back up to show the output and distracting from what I’m trying to look at. This doesn’t happen with my normal, in-project, Deno files at least.
- It doesn’t have auto-import as you’re typing; you can auto-import by clicking the lightbulb, so I assume it’s a relatively short hop to plug that in
- It chokes on absolute import-paths in Windows. Thinks they’re malformed remote URLs
- It has caching issues sometimes. I’ll change some type in one file and other files won’t get the updated type until I close and re-open them, or sometimes the whole editor. This is uncommon so it’s not a huge deal.
I list these criticisms because I want to see Deno succeed. Switching from using TypeScript on Node (with the build steps/configuration, ad-hoc testing and linting, and Node’s pathological legacy APIs) to Deno was a huge quality of life improvement, even with all these problems. Brought to its full potential, I think Deno could be a revolution.
> I enjoy writing code in typed languages. I am in full agreement that they have purpose and utility.
My apologies, that was a bit uncharitable of me.
And, you're right, I didn't quite understand the meaning of "coercion" - I misinterpreted it to mean "implicit coercion". So, my intention was to say that "implicit type coercion is bad engineering" - you're correct in that in general, it's not bad, and necessary.
However, you still don't understand my point, which is that adding types don't introduce any more coupling than what actually had to exist in order to make the program run in the first place.
Let's ignore implicit type coercions, because they are bad engineering, and not relevant to the following point. In a language without implicit type coercions, programs must be well-typed to run correctly. In dynamic languages, even though the code might not contain type annotations, the above principle must still hold. If you pass a string to a function expecting an integer, then your code will break, and all that dynamic typing does is push the error from compile-time to whenever in run-time that you hit that code path.
This is equally true for a client-server interface. If your client and server do not agree on their interface, which includes types (alongside packet header, and field length and order), they will break. If you do not explicitly state what those types are in some formal spec, the types still have to line up in the program! The types are still there, even if you don't explicitly state or check them.
> It would be infinitely worse to maintain the something type across all these different boundaries.
This isn't true; you already maintain types between the boundaries formed between functions in a single program, there are far more of those than inter-program boundaries, and after you set up the tooling for checking network communication schemas, it's barely any more work than maintaining "normal" types between functions.
> Imagine pickling types whenever we want to save something to disk or share it over the network.
I don't understand - "pickling types" is redundant because the pickle format already includes types automatically. Unless you mean building a schema for the pickle and machine-checking that the loading code and the saving code match? In which case, if you're in an engineering context, I absolutely advocate for this, because a mismatch means a runtime error at best, and data loss or corruption at worst. The argument for doing so in a client-server setup is even stronger, however, because data saving and loading code are colocated with each other (making errors easier to manually spot) far more often than sending and receiving code in a client-server codebase.
> Imagine being forced to write application code in the same language as your database!
There's absolutely nothing about type schemas that forces you to use a single language - most schemas are language-independent, like JSON Schema[1] (which is a schema (including types) for JSON data that is in JSON, so you already have a parser for it, and you write it once and then check it everywhere) and ASN-1.
> coupling your database to your server to your client just to share types between the three is obviously not a good idea
The point is that there's no more coupling than what exists in the first place. Programs must be well-typed to run correctly (if there's implicit type coercion, which is bad practice, the program must still be well-typed - you just now automatically insert type-level logic for the coercions) - that means the types are there, even if you don't write them, so the coupling is also there, even if you don't want it.
If your database sends a string to your server when it was expecting an integer, then either your program will crash, or there's implicit coercion - bad practice, but then either the program is well-typed, in which case it's actually technically expecting either a string or an integer (with runtime detection - also bad practice), or the program is not well-typed, in which case you'll get a runtime error.
Related posts
- AWS SDK v3 + DAX
- Why and how you should use AWS SDK for JavaScript (v3) on Node.js 18
- ts-dynamodb-attributes-transformer - A code transformer of TypeScript object to DynamoDB attributes
- Working with EKS: Using IAM and native K8s service accounts to access AWS S3
- AWS keeps dropping the ball with their AWS JavaScript v3 SDK