221–226 of 226 posts
I recently started learning JS, and now I am confused between TS and babel. Can anyone give me a reason why I should use either of the two and when I should use either of the two?
TS adds a complete static type-checking system, and also will compile down your bleeding-edge JS language features into supported syntax. Babel will do the second part.
Earlier quoted context omitted.
VSCode has become a mind-blowingly good editor. It's closing in on the power of heavy-weight IDEs with much better performance than some code editors (e.g. Atom), even.
Both VSCode and Atom are based on Electron, which is slow and battery-intensive as it is based on NodeJS. Are you saying that recent VSCode versions are as performant as, say, a C++ based editor or even (shudder) a Java based editor such as Jetbrains (Webstorm, etc.)? I last looked as VSCode (on a KDE 4 CentOS 7 desktop) about half a year ago, and it was terribly slow, even without extensions.
Earlier quoted context omitted.
+ Member access private/protected + Static members (theoretically exist in JS, but much cleaner and 'compiler aware' in TS) + Interfaces When I write JS, I end up with closures within closures within closures. When I write TS, I find myself sticking to much cleaner abstraction. I end up (having to) create classes, and usually it's for the better.
A class is a pretty bad abstraction to try to fit the world into. It might work for some things, but it usually results in a lot of ceremony, and a lot of concepts in your program that exist only to service the abstraction. It's useful in JS for some special cases, but being forced into it is just going to make your code verbose and complicated for no reason. I'll stick to Flow for now.
TypeScript tries not to impose any sort of restrictions on coding style.
Earlier quoted context omitted.
+ Member access private/protected + Static members (theoretically exist in JS, but much cleaner and 'compiler aware' in TS) + Interfaces When I write JS, I end up with closures within closures within closures. When I write TS, I find myself sticking to much cleaner abstraction. I end up (having to) create classes, and usually it's for the better.
A class is a pretty bad abstraction to try to fit the world into. It might work for some things, but it usually results in a lot of ceremony, and a lot of concepts in your program that exist only to service the abstraction. It's useful in JS for some special cases, but being forced into it is just going to make your code verbose and complicated for no reason. I'll stick to Flow for now.
I totally disagree with this. They are basically one of the best forms, if not 'the best' form of abstraction we have, particularly when it comes closer to the level of 'real world' abstraction.
Classes are the basis of 'typing' - which is to say, typing beyond primitive types.
They provide us with the ability to 'define things' that are not simply strings, numbers or booleans.
It's why JS has moved onto classes, and almost all popular languages use them.
The only time I find they can be limiting, is when there is the necessity to deal with looser typing, i.e. quick litoral objects ... but even then, 9 times out of 10 when I want to 'get around classes' - I'm just being lazy.
Earlier quoted context omitted.
Flow tries to integrate with the existing ecosystem as much as possible. By taking advantage of Babel, ESLint, Atom, etc. With Flow you don't even have to opt-in to a new syntax. You can just use comments: function foo(val /* : boolean */) /* : string */ {} Using really powerful inference you can also write much fewer types. If you have well types libraries [you sometimes don't need types in your code at all]( https:…
> With Flow you don't even have to opt-in to a new syntax. You can just use comments: So you use a opt-in comment-based syntax instead of a opt-in non-comment based one for type-annotations. Hardly a big difference. > Using really powerful inference you can also write much fewer types I'm just going to assume you didn't know typescript does this too. Typescript is nice. You should give it a try once. You may end up s…
The easier imports solves my biggest issue with migrating an existing project over. I'd say TypeScript is "ready" now. The last feature I'd want is an easy way to map nested json into classes rather than interfaces. Anyone know how?
An approach I've seen is to have each class extend from some abstract base class (I know, OO blech) that looks like this: abstract class AbstractClassObject { constructor(json?: any){ if (json){ this.updateFromJSON(json) } } public updateFromJSON = (json: any): this => { Object.assign(this, json); return this; } } That gives you the "magic" just by extending the base, while also allowing custom behavior for a given c…
class Post {
id: string;
user: User; //