ECMAScript proposal for type syntax that is erased - Stage 1 [Moved to: https://github.com/tc39/proposal-type-annotations]
To be frank, I hate to be the typical HN luddite, but this proposal  feels like it will add too much parsing complexity to runtime JS.
The counter-argument to that is: everyone minifies code anyway, but this feels like a very poor argument. "Adding cruft is OK because most people have complicated build chains to get rid of it" is very different from "we've opted into a build chain (tsc) and now have access to adding cruft"; there's a default situation here, which is the many people who write JS (FE or BE) and aren't minifying it.
Additionally, their pipe dream of allowing TS to become standard JS "if they stick within a certain reasonably large subset of the language" (an actual quote from the TC) is... wild. Wild. No thoughts, just vibes. Typescript is an extremely mature, fast-moving, complex project. Their list of TS features not supported under this TC is only three items long (with enums and namespaces among the list, lol), but I guarantee there are TONS of very complex type-level assertions typescript is capable of which JS is years, maybe decades, from reaching considering the glacial speed ECMA moves at.
Typescript will always be a superset, which they admit. The problem is: I hold extreme doubt that JS/ECMA is even capable of communicating what that differential is to average users. Will JS support control flow analysis for dependent parameters, aliased conditions, and discriminants? Const assertions? Middle rest elements in tuples?
Typescript adds all these assertions, and more, every couple months, because it turns out that type systems are something of a pandora's box. Few language-level type systems remain at the simplicity of, say, Go; most become TS, or Rust, or Java. That's not a bad thing, but not everything should be that.
If this gets traction and built, JS will in-effect, though not in-requirement, turn from an interpreted language to a compiled language, whose compiler isn't even maintained by the core development teams. That's a major, major shift; and I'm not sure the proposers have even considered the ramifications of it.
Appwrite - The Open Source Firebase alternative introduces iOS support . Appwrite is an open source backend server that helps you build native iOS applications much faster with realtime APIs for authentication, databases, files storage, cloud functions and much more!
CoffeeScript, for one, is already at least talking about emitting TS . These kinds of changes are vigorously debated though, e.g. . Once ECMA type comments get to stage 4, CS would probably also adapt the new syntax. Other compile-to-js languages that already ship with their own type system will probably be indifferent to the debated proposal.
:sparkles: Monorepo for all the tooling which enables ESLint to support TypeScript
This is why "no-explicit-any" should be enforced in every project.
Next generation frontend tooling. It's fast!
AWS Cloud-aware infrastructure-from-code toolbox [NEW]. Build cloud backends with Infrastructure-from-Code (IfC), a revolutionary technique for generating and updating cloud infrastructure. Try IfC with AWS and Klotho now (Now open-source)
Getting started with NestJS, Vite, and esbuild
7 projects | dev.to | 15 Sep 2022
How to setup a vanilla TS webdev project
2 projects | reddit.com/r/webdev | 31 May 2022
Should I learn typescript?
4 projects | reddit.com/r/reactjs | 24 Apr 2022
Overwhelmed when picking Libraries! Recommendations on my stack/libraries
5 projects | reddit.com/r/reactjs | 26 Jan 2022
x=10 vs let x=10