81–90 of 128 posts
I think it's a very pointless thing to pick a winner. It's not a popularity contest. You will be able to tell that some technology is "lost" or is over, when the popularity will be declined to the 0.0.1 alpha release state.
Does anyone here have bad things to say about TypeScript? I haven't used it for any large projects yet (couple toy ones) but seems pretty legit. Based on my anecdata, people who have used it at scale seems to like it. I can't tell if that's because they're still in the honeymoon phase or if it really is a step forward for the long term.
Earlier quoted context omitted.
In terms of Javascript targeting languages, Typescript has been the only one that hasn't made me want to murder a thousand baby seals. The build system is fast and easily understood, the typing makes refactoring so much easier, and in probably its biggest win, I can read a Javascript tutorial and trivially write the same thing in Typescript. As a language, though, it still leaves a lot to be desired. Things like type…
Have you tried a async/await?
Does anyone here have bad things to say about TypeScript? I haven't used it for any large projects yet (couple toy ones) but seems pretty legit. Based on my anecdata, people who have used it at scale seems to like it. I can't tell if that's because they're still in the honeymoon phase or if it really is a step forward for the long term.
Top-level types can be permanently shadowed. For instance, if I name a type "Date" within a namespace, then every file within that namespace or a sub-namespace will no longer be able to access the JavaScript native Date type. This also apparently isn't something they're inclined to fix. [0] The tsconfig.json file does not allow for glob-type inclusion of files, or even inclusion of directories. However, you can exclu…
I could quibble with the conflation of correlation w/ causation for a lot of the comments this post makes about es6/babel or coffeescript. But each time i re-read this post, the cohesive point that pops out most is that this post is basically a Donald Trump speech about Typescript. The claim is that it's bigger, it's better, and everyone else is a bit sad. It disingenuously claims that it's not about about competitio…
I don't know what any of this has anything to do with Trump.
Earlier quoted context omitted.
The type system is not that great and inference is quite limited. Definitions are not always existent or up to date and a single repo like definitelytyped is a terrible way to manage all the definitions. The above sounds negative but TS is still the best bet right now imo. Some people will prefer Elm or Purescript for better type systems but I like staying close to JS.
Personally, I'm more excited about Flow because it introduces a modern type system into ES6/ESNext without me having to sacrifice Babel. With regards to types: TypeScript has only recently added support for any kind of Algebraic Data Types whereas Flow was built upon Unions and Intersections from day one. That to me speaks to their priorities.
https://blogs.msdn.microsoft.com/typescript/2015/01/16/annou...
Earlier quoted context omitted.
I can't think of any downsides of an optional type checker. Can you? Just curious if there's an argument I hadn't heard before.
If it's TypeScript versus pure JavaScript (not versus Babel), there's a transpile time hit you must consider.
[1] People will always still want to shave bandwidth, and the new hotness is Tree Shakers which shave bandwidth and computation/JIT time for the browser...
I could quibble with the conflation of correlation w/ causation for a lot of the comments this post makes about es6/babel or coffeescript. But each time i re-read this post, the cohesive point that pops out most is that this post is basically a Donald Trump speech about Typescript. The claim is that it's bigger, it's better, and everyone else is a bit sad. It disingenuously claims that it's not about about competitio…
On point 2, I don't think an optional type checker has any real downsides that I can think of (optional because with typescript you don't have to add type annotations to your code). It helps with debugging and possibly performance but you can choose not to use it. The rest of your comment I agree with.
Comparing TypeScript to transpilers in the same space, like Flow and Dart makes sense. They're trying to accomplish similar goals at least.
Weird comparisons. People who like Elm aren't going to switch to TypeScript because it's more popular. They are fundamental disagreements that can't be dismissed with a Google Trend chart. TypeScript is currently popular but popularity in JavaScript never last long. The cycle is: * A library that comes out that solves a problem with the previous iteration. * The new popular library has some different problem but peop…
It's backed by M$ and the Github repo is super active, especially in langauge proposals. This will be around for a while.
Earlier quoted context omitted.
If it's TypeScript versus pure JavaScript (not versus Babel), there's a transpile time hit you must consider.
Pure (vanilla) JavaScript will remain a bit of a rare unicorn in large projects, though, at least until HTTP/2 and maybe even after HTTP/2 for whatever other reasons [1]. Just about every large project has a bundler and/or minifier step and the Typescript transpilation fits right in there, instead of in the browser. [1] People will always still want to shave bandwidth, and the new hotness is Tree Shakers which shave…