Feels like Typescript is building (or has built up?) more momentum than Flow.
Google Trends https://www.google.com/trends/explore?date=all&q=%2Fm%2F0n50...
NPM Downloads https://npm-stat.com/charts.html?package=typescript&package=...
91–100 of 226 posts
Feels like Typescript is building (or has built up?) more momentum than Flow.
Google Trends https://www.google.com/trends/explore?date=all&q=%2Fm%2F0n50...
NPM Downloads https://npm-stat.com/charts.html?package=typescript&package=...
Question: Is it possible to have a setup with TypeScript where it is guaranteed that no code changes occur other than removal of the type information? I started using Flow, found what it can and can't do and would like to try TypeScript. But only if I can have "types-only", I don't want my code "translated" in any way. I'm writing for the latest node.js version and not for x different browsers, I want to use exactly…
With flow you can do one better: type comments! https://flowtype.org/blog/2015/02/20/Flow-Comments.html You actually wrap the type annotations in comments and flow will recognize them. You can use the source with the type comments in your browser! As an example, the flow checker will read the annotations from `function f(n/ :number /, s/ :string /) { ... }` but since they are commented in the source code your JS engi…
So I had enough and started with Flow on one file, then two - then I spent a week converting everything to Flow. I actually found a few subtle bugs in my code, but also two or three minor ones in Flow (issues submitted). I also found clear limits for this type system, for example, when you clearly know 100% sure that a value cannot be undefined but Flow insists you add a type check before using the property because it does not follow your dynamic logic, only its types.
It's interesting to me that all of the initial reactions I've seen to this announcement have been around the introduction of async and object spread, which are available with babel, but the typescript specific features such as mapped types are completely ignored. I don't really have any particular meaning behind that observation, only that it tickled my funny bone a little bit.
TypeScript PM here - the reason for that is that when we implement a feature in TypeScript, we take lengths to ensure that it is typed appropriately and that its performance characteristics are reasonable. That means that when using object rest/spread, we didn't want to just ship an experience where type type is effectively `any`, leading users to be frustrated if they make an error. With async/await, we had to rewri…
Anyone knows any good resources to learn typescript? The tutorials on the official site are really... bad. Like I would not even call them tutorials.
You do have to pay for some of them, but there's some free ones as well.
If you still haven't given TypeScript a go as a Javascripter, now is a great time to do so. Whether you end up adopting it or not, it's interesting to get the types out of your mind and into the code. The first time you feel the speed/confidence of refactoring with accurate 'Find usages', you'll decide if the undeniable overhead of types is worth it.
Can anyone weigh in on TypeScript vs Elm?
Elm is pretty neat if you want to build a reactive GUI framework with everything immutable by default and have lots of functional programming idioms at your disposal. However that's all it does: if you want to do e.g. server-side rendering or use it in an angular project you're out of luck; if you want to interop with other JS code then it's a pain.
Typescript doesn't enforce any paradigm or bring any particular framework with it. It's just Javascript with type annotations and some extra features. So you can use it with React and Redux to create something like Elm's framework, but it won't be quite as safe or concise as you'd get with Elm. However it fits in much nicer with other JS libraries and can run on the server or alongside any JS GUI framework of your choice.
Elm is also still officially beta, and new releases often involve fairly large breaking changes.
Personally I started off a big fan of Elm but fell off the bandwagon as I ran into its limitations.
Any plans to add C#-like extension methods to TypeScript? Or is there a way to achieve the same thing already? I know that a previous suggestion to add extension methods was closed as out of scope. But maybe it's time to revisit that, since TypeScript is now doing significant code transformations for downlevel await support.
Earlier quoted context omitted.
> The first time you feel the speed/confidence of refactoring with accurate 'Find usages', you'll decide if the undeniable overhead of types is worth it. For your information: in VSCode, the "Find all references" and "Rename symbol" work out-of-the-box, even if your code isn't typed. Edit and disclaimer: Not sure why I'm getting downvoted, my comment doesn't contradict parent message. I personally type my code too (w…
> For your information: in VSCode, the "Find all references" and "Rename symbol" work out-of-the-box, even if your code isn't typed. I didn't downvote, but this seems incorrect to me. I'm sure that it works in small code bases, but once your code gets large enough (and dynamic enough) it's going to have to start missing things.
My current project has 10,000 LOC and 130 files. If I use "Rename symbol" on something imported in different files of my project, the editor will open all the files, edit all the names and just wait for me to save the changes.
I know that 'OO' and 'typing' is not the solution to everything ... but aside from all the nice things you can do in TS ... the 'enforced architecture' of OO-ish paradigms, combined with typing, and essential obfuscation of the prototype paradigm ... has cut the time to development in half.
I can hardly think of a reason to use JS now that TS exists.
Of course - there are some reasons, in some specific situations, but by and large, TS is the future.
One thing I never understood with Babel is which features are shimmed in the output JS and which features are re-implemented? What I means is: I didn't know how to tell Babel which browsers I was targeting, and I'm pretty sure that some of their feature implementations do not feature test the platform before activating, since they were so compiled in. Is that the case? Also, do you have to tell TypeScript your target…
For instance, I decided just now to check if `transform-object-rest-spread` included an Object.assign polyfill (because spread syntax transpiles to Object.assign behind the scenes.)
With the following input:
var foo = { x: 1, y: 2 };
var bar = { a: 3, b: 4, ...foo };
var baz = new Promise(function(resolve, reject) {
resolve("quux");
});
I get the following output var _extends = Object.assign || function (target) { for (var i = 1; i
The problem here, (to borrow phrasing from the docs) is that "Babel uses very small helpers for common functions such as _extend. By default this will be added to every file that requires it. This duplication is sometimes unnecessary, especially when your application is spread out over multiple files."To solve this problem, many people use the `transform-runtime` plugin [1] as well. To put it shortly, it replaces inline helper functions (like _extends in the example above) with imports from an adapter module called 'babel-runtime', which itself exposes the relevant polyfills (regenerator[2] and core-js[3]).
With `transform-runtime`, I get the following:
import _Promise from "babel-runtime/core-js/promise";
import _extends from "babel-runtime/helpers/extends";
var foo = { x: 1, y: 2 };
var bar = _extends({ a: 10, b: 11 }, foo);
var baz = new _Promise(function (resolve, reject) {
resolve("foo");
});
Notice that the Promise implementation was polyfilled as well.> I didn't know how to tell Babel which browsers I was targeting...
You might *really like babel-preset-env[4], a new project they just launched. Basically, you give it a set of browser targets (much like autoprefixer) and it works out exactly which plugins you need to support the latest (currently es2015, I think) version of javascript.
Hope that helps! Sorry for going on a Babel-related spiel in a Typescript thread, couldn't help myself. ;)
1: http://babeljs.io/docs/plugins/transform-runtime/#technical-... 2: https://facebook.github.io/regenerator/ 3: https://github.com/zloirock/core-js 4: https://github.com/babel/babel-preset-env
Earlier quoted context omitted.
> For your information: in VSCode, the "Find all references" and "Rename symbol" work out-of-the-box, even if your code isn't typed. I didn't downvote, but this seems incorrect to me. I'm sure that it works in small code bases, but once your code gets large enough (and dynamic enough) it's going to have to start missing things.
Why would their algorithm stop to work if your code gets large? It's not some kind of magic. :) My current project has 10,000 LOC and 130 files. If I use "Rename symbol" on something imported in different files of my project, the editor will open all the files, edit all the names and just wait for me to save the changes.
However Brackets does better at finding method definitions. Even in my mess of a project with non typed JS, Brackets can always find the method definition or at least give me possible choices.