fartscroll.js
reflect-metadata
fartscroll.js | reflect-metadata | |
---|---|---|
3 | 3 | |
2,806 | 3,129 | |
- | - | |
0.0 | 7.2 | |
over 5 years ago | about 1 month ago | |
TypeScript | ||
MIT License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
fartscroll.js
-
TypeScript please give us types
We have types at home.
My litmus test regarding whether I can even consider using a library in production is: does it have more stars than fartscroll.js?
https://github.com/theonion/fartscroll.js/tree/master
Most of the entries there are below that number, which begs the question: is this really that much of a problem that it mandates the drastic changes required?
I actually don't know if it's even doable, considering TS's structural type system, where the answer to the question "what type is X?" is not straightforward.
-
Weekly Random Discussion Thread for 2/20/23 - 2/26/23
The best content produced by The Onion was a JavaScript library to make farting noises on scroll events: https://github.com/theonion/fartscroll.js
-
From TypeScript to ReScript
As a sort of litmus test I use the number of stars a superset of(or language compiling to) JavaScript has on GitHub and how that compares to fartscroll.js: https://github.com/theonion/fartscroll.js/
By this measure ReScript is still a niche language.
reflect-metadata
-
TypeScript please give us types
Counter to this post, as soon as I read the title I knew what this was, & I knew it was speaking exactly to something we've wanted for a long time. This is asking for more official & better supported https://github.com/rbuckton/reflect-metadata .
TypeScript is a compiler. It has a lot of type information during compilation. We could write that type information out into a file. Instead what we do is throw that information out when the compile ends. Taking all that typing information & throwing it away at the end of compile time is a bad dumb & silly limitation. Especially for a language like JavaScript, which historically could be semi-proud it had such a strong Everything Is An Object philosophy running through it (such as the malleable prototype-based inheritance system); so much type information should be on that Class object. Reflect-metadata for example defined new methods on Reflect to store this metadata.
I could not be more delighted to see the pennon of this website go up. We needed a rallying point for this. We needed a rallying point for keeping class data around. A rallying point for enriching the runtime with good actionable data is a good rallying point.
It's not what's afoot here, but I think you're a bit off-base about the impossibility of adding even some type-safety. We might not be able to get exact TS type safety. But we can definitely build some safety in. Owing to the malleable prototype-based type system in JS, we can add getters/setters to objects to do a lot of type checking. This doesn't even begin to explore the possibility of what we might do with es2015's proxies, which could allow even more interesting checks to be layered in. I also wish JS had an official AST (and renderer), so had more official options for code-rewriting that might let us weave in type checks.
What we can do as programmers is limited by what we have at our disposal. Not throwing out all the typing information, keeping it around at runtime, opens a lot of interesting doors.
-
Using modern decorators in TypeScript
Second, TypeScript 5.0 cannot emit decorator metadata. Subsequently, it doesn’t integrate with the Reflect API and won’t work with the reflect-metadata npm package.
-
Deconstructing an Object Relationship Mapper (ORM) in Typescript
Database columns will be mapped to domain object properties using decorators. This will include relationships and enum types. reflect-metadata stores metadata about the classes and properties. Most of the work is a simple map for each class, renaming db column properties to domain model properties and vice versa. Reflect.defineProperty holds a list of field metadata on the target class. This is where more database ORM logic could live in the future such as column type, length, etc. A base domain model entity will use this metadata to map the models appropriately.
What are some alternatives?
genType - Auto generation of idiomatic bindings between Reason and JavaScript: either vanilla or typed with TypeScript/FlowType.
protobuf-ts - Protobuf and RPC for TypeScript
lwt - OCaml promises and concurrent I/O
sequelize-typescript-decorators - Sequelize (SQL ORM for Node) Typescript Decorator that simplifies declarations of Sequelize models...
melange - A mixture of tooling combined to produce JavaScript from OCaml & Reason
arktype - TypeScript's 1:1 validator, optimized from editor to runtime
typescript-needs-types - TypeScript please give us types.
InversifyJS - A powerful and lightweight inversion of control container for JavaScript & Node.js apps powered by TypeScript.
di-compiler - A Custom Transformer for Typescript that enables compile-time Dependency Injection
ferocity - Write Java expression trees, statements, methods and classes with a LISP-like internal DSL
schemats - Generate typescript interface definitions from SQL database schema