Our great sponsors
-
proposal-types-as-comments
Discontinued 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 [1] 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.
-
Typescript, by the virtue of not being javascript, has evolved pretty rapidly, and has come pretty far. Would the addition of types to javascript and typescript's conformity to those type annotations slow down typescript's development? There's still some hope, at least on typescript's roadmap[0], for nominal types in addition to structural types. Will the standardisation of type annotations impose further constraints on typescript?
[0] - https://github.com/microsoft/TypeScript/wiki/Roadmap#future
-
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.
-
CoffeeScript, for one, is already at least talking about emitting TS [1]. These kinds of changes are vigorously debated though, e.g. [2]. 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.
-
typescript-eslint
:sparkles: Monorepo for all the tooling which enables ESLint to support TypeScript
This is why "no-explicit-any" should be enforced in every project.
https://github.com/typescript-eslint/typescript-eslint/blob/...
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
