9 ms·

Announcing TypeScript 3.1

163 points by DanRosenwasser 8y ago

theodorejb 8y ago
Seems like a pretty small release in comparison to previous updates. Probably a good thing, though - it demonstrates that the language as reached a very mature state with few remaining gaps.
- pjmlp 8y ago
  Now it just needs to become the official JavaScript's strong mode. :)
  - daveidol 8y ago
    Seriously: this language is amazing. I have to admit I was a holdout for a while, but TS has been fantastic to work with compared to Flow
    - k__ 8y ago
      Good to know. I dad the impression Flow was the better approach, but using it wasn't nice.
      - WorldMaker 8y ago
        For a brief period Flow had more type algebra (type unions and intersections) and better inferencing, but Typescript has greatly shrunk the gap between type system capabilities where the differences are much fewer, and rarely anything that matters for most projects. Flow was popular for the ability to put all of its type annotations in JS comments and not need a transpilation pass. Typescript also added a mode that supports that. Flow was popular for the slipstream integration into Babel as the type-stripper was just an "ordinary" Babel plugin. Typescript now supports this as well. So for the most part a lot of the old impressions that Flow was the better approach are out-of-date, and par-for-par Typescript is an equal approach (if not a better approach, depending on your preferences/needs, and due to things like the fact that there are vastly more Typescript type definitions than Flow definitions in the npm wilds now).
        k__ 8y ago
        Ah. Yes, I read about how TypeScript is a more classical approach, and Flow would use "flow based" typing or something, which was a more modern approach. Also, it came out of the box with non-nullable types. While I had the impression the TypeScript language designers didn't deem these features to be important, they added them anyway.
        WorldMaker 8y ago
        I don't think it was ever a matter of "not-important", Typescript and Flow started from two different perspectives and took different routes to get to what today is a somewhat more converged place. Overall, I also don't think it's "modern" versus "classical" that much. In terms of the different philosophies it's "language" versus "linter" / "compiler" versus "observer", and there is a huge spectrum of options there. Typescript starting from a place of prioritizing "green field" development at first, where teams had the option to start fresh or similar. Like CoffeeScript or Dart, it wanted to provide a good way to organize and develop new code. (Unlike CoffeeScript or Dart, the "pure superset" approach still provided easier migration; I worked on several projects where conversion was simply rename .js to .ts and then fix compiler warnings until it worked again.) Taking the compiler approach also provided an early focus on providing some transformations to the code. In Typescript projects I typically don't feel a need for Babel, because Typescript handles everything I want in terms of "downlevel" transforms to support the version of JS in browsers. Flow starting from a place where you've got a huge line of code investment into an existing codebase, can't "stop the world" to migrate and absolutely need to start "linter style" evaluating data types. Over time Flow has picked up more reasons to use a cleaner syntax for type annotations than what just comments alone can deliver, driving more Flow projects to adopt Babel transforms for that (in addition to whatever other Babel transforms a project wants). Over time Typescript has wanted to get better at migrating existing JS code. The team proved the language worked great for greenfield projects, and got a lot of interest from customers internally and externally to extend that make it a lot easier to do grayfield work. Also, Typescript found its "pure superset" proved better than expected at evaluating almost all JS. This pushed Typescript to power more and more IDE intelligence features for both JS and TS (in an increasing number of IDEs, beyond even the Visual Studio family). That in turn pushed more JS mode features and support in the language, and increasingly better type inferencing and flow control analysis especially when working in large forests of untyped JS. As for the typing systems themselves, "modern" versus "classical" almost is descriptive, from a certain point of view, modulo the fact that both typing systems are "ancient". Typescript started from a type system that started out seeming more in common with the C++/C#/Java family of "Object Oriented" typing systems, whereas Flow started from a place of being much more directly inspired by the "functional" ML family of type systems. (Though calling this more "modern" than the ALGOL-style "OO" type systems belies the fact that the ML family dates to the 70s and about all of our type systems have equally ancient roots; and that like Typescript versus Flow, in a larger sense they've done almost nothing but slowly converge over the intervening decades, learning and growing from each other in both directions.) Typescript didn't start with a lot of the more abstract or higher level type algebras, partly it seems because they wanted to work towards it from a "pragmatic" standpoint of build something that works, find out where the new pain points, build something that works to fix those, and iterate as so forth. Flow started very directly with a powerful abstract type system (with well known inferencing techniques) that was theoretically sound, but arguably not as easily pragmatic to what you might consider the average developer, which is exactly why you would expect Flow to have an early lead from the perspective of the type system. The convergence towards very similar type systems after all that work shouldn't be surprising either, as the drive for more robust type descriptions has indeed pushed Typescript to continually pragmatically iterate, and the realities of the dynamic JS language Typescript tries to type involves a need to describe with types a very wide and diverse range of behavior. Both approaches have their advantages. Arguably, Typescript's "pragmatic" focus I think has helped Typescript end up with the lead that it has in type definitions across the JS ecosystem. Both because the ramp to more advanced/abstract type features is easier for a wider spectrum of developers (in my experience even relatively junior developers can write a Typescript definition file relatively well; Flow that's not necessarily the case from what I've seen, which Flow tries to balance by making inferencing more powerful and definition writing less necessary) and also that the pragmatic/iterative approach in the language itself reflects in a more "perfect is the enemy of the good" attitude in type development in general. (It's fine for a type definition to only describe ~90% of the API/behavior/quirks of a library if that's good enough to get the job done. You can come back and tighten up that remaining 10% in the next pass, or when the next type system features gives you a knob you need to help get it more accurate to how it behaves.) That turned into maybe more of a ramble than I intended, but maybe there's some useful perspective there.
the_other_guy 8y ago
For me, Javascript now means Typescript, thanks to all who contribute to this great language!
monkmartinez 8y ago
Is TypeScript worth learning? I know that is a loaded question, but I need to ask it anyway. I am super frustrated with lack of screens for python. I don't want to pigeon hole into an ecosystem where I am limited to a certain platform like Java/Kotlin or even (dare I say) Swift (no real web, still need JS). As a single developer, mostly hobby, I want options for all the things!!! I have been migrating my Python scraping to JavaScript with node, puppeteer, and it has been quite illuminating, and the speed is ridiculously better. Furthermore, I can easily turn my scrape into a desktop app with electron with an api that is consumed by a mobile app with react-native. Long story short, I can now think about making some of my Python ideas into cross platform desktop apps with mobile versions as well. Not super easy with Python. The question is would TypeScript be even better for a long term bet?
- WaxProlix 8y ago
  I use Python for all of my one-offs and automation scripts still. If I were going to make a large-ish web service on my own, I'd choose Typescript. It's a fantastic middle ground and transpiles to a target that's guaranteed to see constant adoption & incremental performance gains that you'll get 'for free'. If you're looking at Node anyway, definitely consider TS. Low barrier (I just added a loader to my webpack config but there are other ways) and great reward in terms of writing and maintaining code.
- wes-k 8y ago
  Get good at JS and then def. learn TypeScript. It’s incredibly valuable for medium to large projects. It combined with an IDE makes coding JS a lot more manageable.
- alangpierce 8y ago
  It's probably best to think of TypeScript as a relatively light JS language extension (like JSX, Flow, or enabling proposed future JS features), not as its own language, even though it's been called a separate language in the past. It's not an alternative to JavaScript, it's a set of guardrails for JavaScript that makes your code safer and hopefully makes you happier when programming. (I'm certainly happier in TS because of all of the editor features it enables, for example.) If your goal is to grow as a developer, you should absolutely try it out and at least learn the basics. There are valid gripes, like some find it cumbersome for smaller/prototype projects (though I still prefer it over untyped JS even for small things), but it's probably best to try out both worlds (and maybe try out Flow as well) and make an informed choice from experience.
yawgmoth 8y ago
What is the lowest ceremony way to start building a TypeScript SPA? I would love to avoid Webpack if I can :)
- mdgrech23 8y ago
  See the quick start page. http://www.typescriptlang.org/samples/index.html http://www.typescriptlang.org/samples/index.html
- pietro 8y ago
  Parcel has first class support for TypeScript. It's amazingly simple: https://hackernoon.com/zero-config-typescript-bundling-with-parcel-ef76fabcbfe3 https://hackernoon.com/zero-config-typescript-bundling-with-...
  - theli0nheart 8y ago
    Seconding Parcel. Such a joy to work with compared with Webpack.
  - GijsjanB 8y ago
    First class? Parcel uses Babel to transpile. Ugh. https://github.com/parcel-bundler/parcel/issues/954 https://github.com/parcel-bundler/parcel/issues/954
- sandGorgon 8y ago
  The official create-react-app starter from Microsoft. https://github.com/Microsoft/TypeScript-React-Starter https://github.com/Microsoft/TypeScript-React-Starter
- aikah 8y ago
  > What is the lowest ceremony way to start building a TypeScript SPA? I would love to avoid Webpack if I can :) The only thing you need to build a SPA is Javascript, the DOM and history API. You literally do not need anything else. You can use CustomEvent and ES5 properties to observe a model changes, use string templates for the view,use event delegation to facilitate event handling, and implement MVC/MVP/MVVM yourself (3 classes...), you don't need a framework for that. Obvsiously you'll need a test runner, if you don't do automated testing, you can just download jasmine and run tests in the browser directly without the need to install node.js at all.
velox_io 8y ago
I was kind of hoping that they would get rid of null or undefined (or both). While I understand that null and undefined are not the same, are both truly needed? Seems like a missed opportunity to make the language cleaner. They seem redundant when you have exception handling, which I think makes the flow of the code easier see. Could they be removed?
- erokar 8y ago
  The point of TS was always to be a superset of JS, so in that sense I doubt they want to get rid of something that exists in plain JS.
- saurik 8y ago
  Part of the premise (and I think this is very noble) is that they are trying to be descriptive of what JavaScript is, not prescriptive of what anyone wishes JavaScript should have been. (That said, I don't even understand what you mean by saying that both null and undefined seem redundant when you have exception handling... how do you represent "this exists or it doesn't exist" in the type system if you can't do a union type of "X" and "null"? I don't see how exception handling has anything to do with null/undefined.)
  - kroltan 8y ago
    > how do you represent "this exists or it doesn't exist" in the type system if you can't do a union type of "X" and "null"? Like this, pick your flavor: https://doc.rust-lang.org/std/option/enum.Option.html https://doc.rust-lang.org/std/option/enum.Option.html https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html https://docs.oracle.com/javase/8/docs/api/java/util/Optional... https://docs.microsoft.com/en-us/dotnet/api/system.nullable-1 https://docs.microsoft.com/en-us/dotnet/api/system.nullable-... https://wiki.haskell.org/Maybe https://wiki.haskell.org/Maybe If you don't want to follow links: Instead of having nulls, have a type which is either a discriminated union (not possible in JS) or is a (isPopulated, value) pair, and accessing the value is an exception if isPopulated=false. Granted, that would be an extremely breaking change for a JS-compatible language, which would make it in fact incompatible. But answering the question, that's it.
erokar 8y ago
TypeScript is fine. I used it for about half a year when wokring on an Angular app. But for new projects with React now I seldom see the need to include it. Sure, TS gives you a little bit better autocompletion in VS Code, you can document your function signatures a little bit better and you can catch a few trivial type errors — but it also has some costs: Extra set up, extra build steps, the need to also import type definitions when including a library, cluttering the code with interfaces and type definitions. I find the extra value it gives over PropTypes in React is pretty low. And while types in function signatures arguably increase understanding, elaborate interface definitions, sometimes in their owen files with the need to import them, can clutter up the code and be a detriment to readability. Also, VS Code's auto completion is very good even without TS.
- erokar 8y ago
  ^ I knew this would get downvoted, but it would be nice to see some arguments as to why people think the benefits of TS outweigh the costs.
  - vosper 8y ago
    As a React developer who hasn't used TypeScript yet, I think of PropTypes as a pretty weak alternative to proper static types. 1. You have to manually keep the PropTypes in sync with the type of props actually being passed to the function. But nothing makes you do that, and it's pretty easy to neglect them - your editor's not going to complain (at least, WebStorm doesn't) so the first you'll see of a mismatch is if you happen to get an error (not really an error, it doesn't stop your code from running) in the browser or in your tests. 2. They don't actually enforce anything. Sure, React will complain about a prop type mismatch when you call the function, but your code will still run, and then it's up to you to figure out whether the PropType definition is wrong, or whether the prop itself is wrong. Maybe only one usage of the component is passing in the wrong prop type, maybe only under a specific set of conditions, and it's easy enough to miss that in tests (your test data matches the PropType, but your actual API data that ends up being a prop doesn't match the PropType - eg your PropType is a number but the API returns a string and you didn't convert it to a number, now you have a error-warning in production. That's your fault, sure, but you get no help with it from the tooling). 3. They're not very expressive. eg I can't define the shape of an object being passed into my component, I can only tell React that it's some object. 4. PropTypes only work at the boundaries of components. What about my functions inside the components? Or my helper functions that aren't part of a component at all? PropTypes do nothing to help me be sure I'm passing the right data to those.
crudbug 8y ago
Can we have a CLR backend now ?
dlbucci 8y ago
Glad to see that adding properties to functions will be easier now. I've been tripped up by that a few times before, and was always surprised at how painful it was to type such a relative common JS pattern.
tlarkworthy 8y ago
I love Typescript and the type system is getting pretty powerful. I would like to use it more in commandline utilities, but then I find the JS event loop makes sequential commands annoying, or REPLs need trampolining etc. There is nothing in typescript that actually ties the type system to the event loop. I would love the Typescript language applied to a runtime that was ok with blocking IO.
- rictic 8y ago
  For CLIs I end up doing something like: async function main() { } main().catch(e => { console.error(e); process.exit(1); }); Async/await is what I want, more than blocking, because frequently to make a CLI fast I need to do things in parallel. I'm often working against a network filesystem though, so doing as much FS stuff in parallel has a big payoff.
novaleaf 8y ago
self plug: i wrote a "corelib" for typescript: https://www.npmjs.com/package/xlib https://www.npmjs.com/package/xlib right now it's only meant for nodejs use (it's too big for browsers) but I use it successfully in my production code, and have been using it for years, so it's got that for it :) i plan to add proper browser support (minification, tree shaking, etc) when i do my next client side project, but that's still at least a few months off.
ZeikJT 8y ago
Another case of just blatantly ignoring semver[0] and only increasing the minor version while including backwards incompatible changes! [0] https://semver.org/ https://semver.org/

Seems like a pretty small release in comparison to previous updates. Probably a good thing, though - it demonstrates that the language as reached a very mature state with few remaining gaps.

pjmlp 8y ago
Now it just needs to become the official JavaScript's strong mode. :)
- daveidol 8y ago
  Seriously: this language is amazing. I have to admit I was a holdout for a while, but TS has been fantastic to work with compared to Flow
  - k__ 8y ago
    Good to know. I dad the impression Flow was the better approach, but using it wasn't nice.
    - WorldMaker 8y ago
      For a brief period Flow had more type algebra (type unions and intersections) and better inferencing, but Typescript has greatly shrunk the gap between type system capabilities where the differences are much fewer, and rarely anything that matters for most projects. Flow was popular for the ability to put all of its type annotations in JS comments and not need a transpilation pass. Typescript also added a mode that supports that. Flow was popular for the slipstream integration into Babel as the type-stripper was just an "ordinary" Babel plugin. Typescript now supports this as well. So for the most part a lot of the old impressions that Flow was the better approach are out-of-date, and par-for-par Typescript is an equal approach (if not a better approach, depending on your preferences/needs, and due to things like the fact that there are vastly more Typescript type definitions than Flow definitions in the npm wilds now).
      - k__ 8y ago
        Ah. Yes, I read about how TypeScript is a more classical approach, and Flow would use "flow based" typing or something, which was a more modern approach. Also, it came out of the box with non-nullable types. While I had the impression the TypeScript language designers didn't deem these features to be important, they added them anyway.
        WorldMaker 8y ago
        I don't think it was ever a matter of "not-important", Typescript and Flow started from two different perspectives and took different routes to get to what today is a somewhat more converged place. Overall, I also don't think it's "modern" versus "classical" that much. In terms of the different philosophies it's "language" versus "linter" / "compiler" versus "observer", and there is a huge spectrum of options there. Typescript starting from a place of prioritizing "green field" development at first, where teams had the option to start fresh or similar. Like CoffeeScript or Dart, it wanted to provide a good way to organize and develop new code. (Unlike CoffeeScript or Dart, the "pure superset" approach still provided easier migration; I worked on several projects where conversion was simply rename .js to .ts and then fix compiler warnings until it worked again.) Taking the compiler approach also provided an early focus on providing some transformations to the code. In Typescript projects I typically don't feel a need for Babel, because Typescript handles everything I want in terms of "downlevel" transforms to support the version of JS in browsers. Flow starting from a place where you've got a huge line of code investment into an existing codebase, can't "stop the world" to migrate and absolutely need to start "linter style" evaluating data types. Over time Flow has picked up more reasons to use a cleaner syntax for type annotations than what just comments alone can deliver, driving more Flow projects to adopt Babel transforms for that (in addition to whatever other Babel transforms a project wants). Over time Typescript has wanted to get better at migrating existing JS code. The team proved the language worked great for greenfield projects, and got a lot of interest from customers internally and externally to extend that make it a lot easier to do grayfield work. Also, Typescript found its "pure superset" proved better than expected at evaluating almost all JS. This pushed Typescript to power more and more IDE intelligence features for both JS and TS (in an increasing number of IDEs, beyond even the Visual Studio family). That in turn pushed more JS mode features and support in the language, and increasingly better type inferencing and flow control analysis especially when working in large forests of untyped JS. As for the typing systems themselves, "modern" versus "classical" almost is descriptive, from a certain point of view, modulo the fact that both typing systems are "ancient". Typescript started from a type system that started out seeming more in common with the C++/C#/Java family of "Object Oriented" typing systems, whereas Flow started from a place of being much more directly inspired by the "functional" ML family of type systems. (Though calling this more "modern" than the ALGOL-style "OO" type systems belies the fact that the ML family dates to the 70s and about all of our type systems have equally ancient roots; and that like Typescript versus Flow, in a larger sense they've done almost nothing but slowly converge over the intervening decades, learning and growing from each other in both directions.) Typescript didn't start with a lot of the more abstract or higher level type algebras, partly it seems because they wanted to work towards it from a "pragmatic" standpoint of build something that works, find out where the new pain points, build something that works to fix those, and iterate as so forth. Flow started very directly with a powerful abstract type system (with well known inferencing techniques) that was theoretically sound, but arguably not as easily pragmatic to what you might consider the average developer, which is exactly why you would expect Flow to have an early lead from the perspective of the type system. The convergence towards very similar type systems after all that work shouldn't be surprising either, as the drive for more robust type descriptions has indeed pushed Typescript to continually pragmatically iterate, and the realities of the dynamic JS language Typescript tries to type involves a need to describe with types a very wide and diverse range of behavior. Both approaches have their advantages. Arguably, Typescript's "pragmatic" focus I think has helped Typescript end up with the lead that it has in type definitions across the JS ecosystem. Both because the ramp to more advanced/abstract type features is easier for a wider spectrum of developers (in my experience even relatively junior developers can write a Typescript definition file relatively well; Flow that's not necessarily the case from what I've seen, which Flow tries to balance by making inferencing more powerful and definition writing less necessary) and also that the pragmatic/iterative approach in the language itself reflects in a more "perfect is the enemy of the good" attitude in type development in general. (It's fine for a type definition to only describe ~90% of the API/behavior/quirks of a library if that's good enough to get the job done. You can come back and tighten up that remaining 10% in the next pass, or when the next type system features gives you a knob you need to help get it more accurate to how it behaves.) That turned into maybe more of a ramble than I intended, but maybe there's some useful perspective there.

the_other_guy 8y ago

For me, Javascript now means Typescript, thanks to all who contribute to this great language!

monkmartinez 8y ago

Is TypeScript worth learning? I know that is a loaded question, but I need to ask it anyway. I am super frustrated with lack of screens for python. I don't want to pigeon hole into an ecosystem where I am limited to a certain platform like Java/Kotlin or even (dare I say) Swift (no real web, still need JS). As a single developer, mostly hobby, I want options for all the things!!! I have been migrating my Python scraping to JavaScript with node, puppeteer, and it has been quite illuminating, and the speed is ridiculously better. Furthermore, I can easily turn my scrape into a desktop app with electron with an api that is consumed by a mobile app with react-native. Long story short, I can now think about making some of my Python ideas into cross platform desktop apps with mobile versions as well. Not super easy with Python. The question is would TypeScript be even better for a long term bet?

WaxProlix 8y ago
I use Python for all of my one-offs and automation scripts still. If I were going to make a large-ish web service on my own, I'd choose Typescript. It's a fantastic middle ground and transpiles to a target that's guaranteed to see constant adoption & incremental performance gains that you'll get 'for free'. If you're looking at Node anyway, definitely consider TS. Low barrier (I just added a loader to my webpack config but there are other ways) and great reward in terms of writing and maintaining code.
wes-k 8y ago
Get good at JS and then def. learn TypeScript. It’s incredibly valuable for medium to large projects. It combined with an IDE makes coding JS a lot more manageable.
alangpierce 8y ago
It's probably best to think of TypeScript as a relatively light JS language extension (like JSX, Flow, or enabling proposed future JS features), not as its own language, even though it's been called a separate language in the past. It's not an alternative to JavaScript, it's a set of guardrails for JavaScript that makes your code safer and hopefully makes you happier when programming. (I'm certainly happier in TS because of all of the editor features it enables, for example.) If your goal is to grow as a developer, you should absolutely try it out and at least learn the basics. There are valid gripes, like some find it cumbersome for smaller/prototype projects (though I still prefer it over untyped JS even for small things), but it's probably best to try out both worlds (and maybe try out Flow as well) and make an informed choice from experience.

yawgmoth 8y ago

What is the lowest ceremony way to start building a TypeScript SPA? I would love to avoid Webpack if I can :)

mdgrech23 8y ago
See the quick start page. http://www.typescriptlang.org/samples/index.html http://www.typescriptlang.org/samples/index.html
pietro 8y ago
Parcel has first class support for TypeScript. It's amazingly simple: https://hackernoon.com/zero-config-typescript-bundling-with-parcel-ef76fabcbfe3 https://hackernoon.com/zero-config-typescript-bundling-with-...
- theli0nheart 8y ago
  Seconding Parcel. Such a joy to work with compared with Webpack.
- GijsjanB 8y ago
  First class? Parcel uses Babel to transpile. Ugh. https://github.com/parcel-bundler/parcel/issues/954 https://github.com/parcel-bundler/parcel/issues/954
sandGorgon 8y ago
The official create-react-app starter from Microsoft. https://github.com/Microsoft/TypeScript-React-Starter https://github.com/Microsoft/TypeScript-React-Starter
aikah 8y ago
> What is the lowest ceremony way to start building a TypeScript SPA? I would love to avoid Webpack if I can :) The only thing you need to build a SPA is Javascript, the DOM and history API. You literally do not need anything else. You can use CustomEvent and ES5 properties to observe a model changes, use string templates for the view,use event delegation to facilitate event handling, and implement MVC/MVP/MVVM yourself (3 classes...), you don't need a framework for that. Obvsiously you'll need a test runner, if you don't do automated testing, you can just download jasmine and run tests in the browser directly without the need to install node.js at all.

velox_io 8y ago

I was kind of hoping that they would get rid of null or undefined (or both). While I understand that null and undefined are not the same, are both truly needed? Seems like a missed opportunity to make the language cleaner. They seem redundant when you have exception handling, which I think makes the flow of the code easier see. Could they be removed?

erokar 8y ago
The point of TS was always to be a superset of JS, so in that sense I doubt they want to get rid of something that exists in plain JS.
saurik 8y ago
Part of the premise (and I think this is very noble) is that they are trying to be descriptive of what JavaScript is, not prescriptive of what anyone wishes JavaScript should have been. (That said, I don't even understand what you mean by saying that both null and undefined seem redundant when you have exception handling... how do you represent "this exists or it doesn't exist" in the type system if you can't do a union type of "X" and "null"? I don't see how exception handling has anything to do with null/undefined.)
- kroltan 8y ago
  > how do you represent "this exists or it doesn't exist" in the type system if you can't do a union type of "X" and "null"? Like this, pick your flavor: https://doc.rust-lang.org/std/option/enum.Option.html https://doc.rust-lang.org/std/option/enum.Option.html https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html https://docs.oracle.com/javase/8/docs/api/java/util/Optional... https://docs.microsoft.com/en-us/dotnet/api/system.nullable-1 https://docs.microsoft.com/en-us/dotnet/api/system.nullable-... https://wiki.haskell.org/Maybe https://wiki.haskell.org/Maybe If you don't want to follow links: Instead of having nulls, have a type which is either a discriminated union (not possible in JS) or is a (isPopulated, value) pair, and accessing the value is an exception if isPopulated=false. Granted, that would be an extremely breaking change for a JS-compatible language, which would make it in fact incompatible. But answering the question, that's it.

erokar 8y ago

TypeScript is fine. I used it for about half a year when wokring on an Angular app. But for new projects with React now I seldom see the need to include it. Sure, TS gives you a little bit better autocompletion in VS Code, you can document your function signatures a little bit better and you can catch a few trivial type errors — but it also has some costs: Extra set up, extra build steps, the need to also import type definitions when including a library, cluttering the code with interfaces and type definitions. I find the extra value it gives over PropTypes in React is pretty low. And while types in function signatures arguably increase understanding, elaborate interface definitions, sometimes in their owen files with the need to import them, can clutter up the code and be a detriment to readability. Also, VS Code's auto completion is very good even without TS.

erokar 8y ago
^ I knew this would get downvoted, but it would be nice to see some arguments as to why people think the benefits of TS outweigh the costs.
- vosper 8y ago
  As a React developer who hasn't used TypeScript yet, I think of PropTypes as a pretty weak alternative to proper static types. 1. You have to manually keep the PropTypes in sync with the type of props actually being passed to the function. But nothing makes you do that, and it's pretty easy to neglect them - your editor's not going to complain (at least, WebStorm doesn't) so the first you'll see of a mismatch is if you happen to get an error (not really an error, it doesn't stop your code from running) in the browser or in your tests. 2. They don't actually enforce anything. Sure, React will complain about a prop type mismatch when you call the function, but your code will still run, and then it's up to you to figure out whether the PropType definition is wrong, or whether the prop itself is wrong. Maybe only one usage of the component is passing in the wrong prop type, maybe only under a specific set of conditions, and it's easy enough to miss that in tests (your test data matches the PropType, but your actual API data that ends up being a prop doesn't match the PropType - eg your PropType is a number but the API returns a string and you didn't convert it to a number, now you have a error-warning in production. That's your fault, sure, but you get no help with it from the tooling). 3. They're not very expressive. eg I can't define the shape of an object being passed into my component, I can only tell React that it's some object. 4. PropTypes only work at the boundaries of components. What about my functions inside the components? Or my helper functions that aren't part of a component at all? PropTypes do nothing to help me be sure I'm passing the right data to those.

crudbug 8y ago

Can we have a CLR backend now ?

dlbucci 8y ago

Glad to see that adding properties to functions will be easier now. I've been tripped up by that a few times before, and was always surprised at how painful it was to type such a relative common JS pattern.

tlarkworthy 8y ago

I love Typescript and the type system is getting pretty powerful. I would like to use it more in commandline utilities, but then I find the JS event loop makes sequential commands annoying, or REPLs need trampolining etc. There is nothing in typescript that actually ties the type system to the event loop. I would love the Typescript language applied to a runtime that was ok with blocking IO.

rictic 8y ago
For CLIs I end up doing something like: async function main() { } main().catch(e => { console.error(e); process.exit(1); }); Async/await is what I want, more than blocking, because frequently to make a CLI fast I need to do things in parallel. I'm often working against a network filesystem though, so doing as much FS stuff in parallel has a big payoff.

novaleaf 8y ago

self plug: i wrote a "corelib" for typescript: https://www.npmjs.com/package/xlib https://www.npmjs.com/package/xlib right now it's only meant for nodejs use (it's too big for browsers) but I use it successfully in my production code, and have been using it for years, so it's got that for it :) i plan to add proper browser support (minification, tree shaking, etc) when i do my next client side project, but that's still at least a few months off.

ZeikJT 8y ago

Another case of just blatantly ignoring semver[0] and only increasing the minor version while including backwards incompatible changes! [0] https://semver.org/ https://semver.org/