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.
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).
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.
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.
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?
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.
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.
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.
Agreed that it’s pedagogically useful to think of Typescript as a light(ish) extension, hence literture on pure JavaScript will still repay study. But, overall it's best to treat TS as its own language, especially when it comes to developing libraries. This situation isn't dissimilar to Objective-C/Cocoa where the language is a strict superset of C (as in the case of TS and JS), but the real leverage came from framework.
It solves all the issues I have with Javascript, that are all related to its weak and dynamic type system: awkward, unwanted type conversions all around, tons of "undefined is not a function", and lack of IDE integration. So, yes, it's definitely worth it, even for small projects. And it's not like it's hard to learn once you know javascript, anyway. It's nothing more than a superset of the language.
Typescript has been great for me (someone who started with Javascript by writing code essentially through trial and error). One of the other benefits of TS I get surprised a lot less by what the "this" keyword evaluates to.
> that are all related to its weak and dynamic type system
It doesn't make JS strongly typed though. It's still possible to compare different types, it still allows type coercion,truthiness and what not. It add type definitions, but it does not turn Javascript into a strongly typed language.
TypeScript is a structural typing system, vs the normal nominal one we are used to. Now, I agree that even with this difference, still not a strong typing as it could be, however, get pretty close to it (with all of the added expressiveness added to it). So, all in all, for big app dev, Java vs TypeScript, from a typing point of view, it comes pretty close.
It actually does disallow various type coercion operations that you can do in JS, even when they're arguably useful. For example `1 == "1"` doesn't typecheck:
If you're already using JavaScript for the web, I think there's three main options for that domain:
* stick with JS,
* learn a language that's a superset of JS (like TypeScript), or
* learn another language which compiles to JS.
If you're looking for a language that can also replace Python for you, then maybe the 3rd option above is a good bet. Something which has its own VM (or other native target), but which also can be compiled to JS. For example, Haxe, Kotlin, Nim, Go, or Dart.
I don’t think so, and we build JS for enterprise and we were previously/are somewhat a mainly C# house.
Typescript has some advantages that are appealing to people coming from Java/c#, and it integrates sort of well into a codebase that’s a mix of JS and typescript. So you don’t really lose that much from using it. We found it relatively burdensome compared to plain JS, simply put, it made us less productive. You fix some of JSs problems, mainly typesafety, but the trade off is that you’ll need to keep updated on both typescript and JS as well as getting a more complicated approach to prototypes and testing that isn’t as smooth (at least not for us, and that may be us not typescript but it’s still something you have to account for).
If we were doing angular on the front end we might do typescript, but I honestly think we would’ve picked angularDart and flutter instead of typescript.
I don’t think you go wrong either way though, typescript has just been unnecessary for us.
Yeah, we use C# for the backend too and recently moved away from Typescript. It's a breath of fresh air getting away from all of the type complexity of Typescript. Like you said, it just bogged us down and made us less productive.
With VsCode and a jsconfig.json file you can get much of the benefits of typechecking anyway.
I'm still a fan of static typing, but Typescript ain't it. I need something much simpler that isn't dragging our productivity down.
I think using TypeScript with non-nullable types can rid your code-base of undefined errors, without the need of huge test-suites. These are, at least for me, the most frequent type of errors.
It's worth using. like flow it can validate plain js files and even supports a subset of JS doc (on that aspect I wish it didn't, I wish Microsoft established a more powerful format for type comments as an alternative to JS doc which is not well defined, but it does its job). So you don't even have to use ts files. In VSCode IDE, you can just had
// @ts-check
to benefit from typescript compiler.
At the end of the day, yes, JS today is a safe bet. You can develop native apps with react-native, desktop apps with electron even attempt to include 3rd party language libraries through WASM.
Is it faster than Python? I don't think so, but it's a trade-off. Javascript is ubiquitous now. I say it as someone who still kind of despise the language yet it's productive.
There are at least 4 reasons I can think of that you don't want to write JS without knowing how to use a transpiler, a search will probably find great lists and explanations.. Once you are using one, it makes sense to use typescript and stay close to JS (good for staying close to definitive DOM/BOM guides and debugger results) or an entirely different language that transpiler to JS, for some preferred style. But (once transpiling) there's very few advantages to JS itself over using typescript even with the most occasional use of types for debugging a bad return or variable etc.
The other route to take is to try to follow the cutting edge of webassembly, so you can continue to use a lot of python. Python is probably going to be first in it's class of languages for support at each step, but it's class is not as ideal for webassembly as non-gc strongly typed languages which are ironically less like Python than JS!
I would say definitely yes, good one to learn, and smart bet (and we have avoided lot of hype languages like coffescript, dart, ...).
1. TypeScript is just a modern expressive strutural typing system on top of JavaScript, not a full new language.
2. Modern JavaScript (es2017) is not our old JavaScript, the language matured very well. Not perfect, no language it, but as good as it get for a scripting language, and TypeScript has a lot of structure while keeping its flexiblity.
3. JS/TS really enable a Functional First, OO as needed programming style, which can greatly reduce boilerplate code and API code complexity, which in turn makes the code scale better.
Note: I have been doing Java for the last 20 years, building big enterprise Java app for a living for the last 10 years, and right now, I would say that Modern JS / TypeScript and all of its benefit, offer a better productivity environment for big app development, that traditional Java. We just ported one of our client's Java backend, 40% less code, better typed, and better scale (as most node libs are nio/async in nature)
> 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.
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.
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.)
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.
I should have been more specific. Yes, the --strictNullChecks switch almost gets you there.. I forget there's also the 'never' type, and '{}', which are very similar to null (I've seen someone use the string null in production).
The reason I bring this up is that if you remove null, it removes the need for both of '==' & '===' (could possibly be removed with something like strictEqualityChecks).
Exception handling and null checks are both conditional, so there is the potential to replace checking for null with exceptions. Plus, removing the null checks (is an object still an object when most of its properties are null?) could be fixed with better use of inheritance. And the '?' suffix.
This is not the first language Anders has been involved in developing, I'm sure remember him talking about his dislike for null somewhere (I could be wrong). Typescript is both an abstraction and adds features to Javascript. So TypeScript has the opportunity to remove such idioms. Scala and Java are very different languages despite running the same underneath.
The question at the end of the post was more hypothetical. Could this be done or is the concept of null is so ingrained that it can't be removed? (When Functional programming manages null.) I'm just interested, especially when null is known as the "Billion Dollar Mistake" - that's ignoring inflation.
How would you remove them while still being fully compatible with existing JS code? I mean they could do it, it'd just be orthogonal to their goal of TS being easy to bring into existing codebases.
Modern TypeScript aims to add typings to JavaScript, so eliminating a core language primitive—even a rather appendiceal one like null—is probably out of that scope, especially because some js libraries do differentiate between null and undefined.
I highly recommend using TypeScript's strict null checks mode as it makes undefined and null their own distinct types and requires that you explicitly state when a field or argument is nullable. The programming experience is somewhat similar to working with 'optional' types in languages like Scala or Swift. See the 'nullable types' section of this document for more info: https://www.typescriptlang.org/docs/handbook/advanced-types....
I've used it to differentiate between uninitialized (undefined), and a new record (null, not set yet) in my routing... navigation triggers a reducer action that will "reset" the underlying state if the id doesn't match the loaded record. In the case of a "/type/create" the "id" is null. In the case of "/type/:id/edit" the "id" is ":id" from the route. I can then reset to an object with an undefined Id, and the component can call an action to dispatch a load.
Probably a convoluted example, however there are distinctions that can be used between the two. Similar to how I've used null + boolean as a tristate with default, true, false where null is default. Undefinied or uninitialized is useful beyond simply null.
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.
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.
These are good points. A agree that PropTypes are neither as expressive/spesific nor as strict as using e.g. an interface with TS. I still think they are often good enough.
You are also correct to point out PropTypes offer no way of adding typing to component or utility functions. I've seldom seen errors arise from the lack of typing here, and if they do you'll usually discover them at runtime. However types as added documentation of function signatures would be nice.
Regarding 3, you actually can use PropTypes to define the shape of an object passed as a prop using PropTypes.shape({...})! You can also specify the types of all of the keys of the object.
I find this super useful in many of my projects, I hope it helps with some of yours!
You're making some good points and I feel ambivalent about prop types however I wanted give a few solutions to some of the things you said.
You can use eslint to enforce the use of prop types, it'll read through your code and will give you a warning if you are using a prop without a corresponding prop types declaration, the rule is called react/prop-types
I think your points are some of the best reasons to avoid TypeScript, but I still definitely prefer TypeScript. I think I just find the disadvantages less cumbersome and the advantages more compelling.
Even though editors can give reasonable autocomplete for JS these days, I think there's a certain amount of trust and comfort that you lose, and I find it really nice to have little mistakes flagged right as I'm typing rather than when running the code (even when I have a fast iteration cycle).
I also greatly prefer TypeScript when trying to use code I've never seen before, whether that's code written by someone else on my team or third-party code. The types add an extra layer of explanation that's hard to convey in docs or function/variable names.
And as discussed separately, PropTypes is much better than nothing, but I think it has plenty of gaps, and I feel much more confident and comfortable in a codebase with full typechecking.
(I didn't downvote; I upvoted you since I think your post is a good contribution to the discussion.)
Static vs dynamic typing aka catching type errors on compile and not on runtime.
Easily refactor code and all references there of. I would also say that I‘m faster using TypeScript BECAUSE of autocompletion, implicit code documentation through types, etc. The cost you listed are solved during the setup of a project.
I can just talk for myself, but I started a project at work and pushed for TypeScript. We now have automatically generated Swagger-clients fully typed, with a GraphQL layer infront of it with generated types for queries. Basically everything is typed now and I don‘t have to test or check incomming data or guess what kind of object I have to expect from our backend. The tooling is so good now, that the benefits outweigh any setup hassle you have upfront IMHO.
Good points. I'm not against using TS, I just think the it should be aknwoledged that it does have costs. The nice thing about TS is that once included you can use it as much or as little as you like (for function signatures only, for instance).
I also think project scope and team size is important -- the larger these are, the more I would consider TS.
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.
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.
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.
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.
64 comments
[ 6.0 ms ] story [ 377 ms ] threadI dad the impression Flow was the better approach, but using it wasn't nice.
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).
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.
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.
Th...
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?
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.
It doesn't make JS strongly typed though. It's still possible to compare different types, it still allows type coercion,truthiness and what not. It add type definitions, but it does not turn Javascript into a strongly typed language.
https://www.typescriptlang.org/play/index.html#src=const%20x...
So while there are still things like truthy/falsy values, the type system is stronger (not just static) in some sense compared with JS.
* stick with JS,
* learn a language that's a superset of JS (like TypeScript), or
* learn another language which compiles to JS.
If you're looking for a language that can also replace Python for you, then maybe the 3rd option above is a good bet. Something which has its own VM (or other native target), but which also can be compiled to JS. For example, Haxe, Kotlin, Nim, Go, or Dart.
Typescript has some advantages that are appealing to people coming from Java/c#, and it integrates sort of well into a codebase that’s a mix of JS and typescript. So you don’t really lose that much from using it. We found it relatively burdensome compared to plain JS, simply put, it made us less productive. You fix some of JSs problems, mainly typesafety, but the trade off is that you’ll need to keep updated on both typescript and JS as well as getting a more complicated approach to prototypes and testing that isn’t as smooth (at least not for us, and that may be us not typescript but it’s still something you have to account for).
If we were doing angular on the front end we might do typescript, but I honestly think we would’ve picked angularDart and flutter instead of typescript.
I don’t think you go wrong either way though, typescript has just been unnecessary for us.
With VsCode and a jsconfig.json file you can get much of the benefits of typechecking anyway.
I'm still a fan of static typing, but Typescript ain't it. I need something much simpler that isn't dragging our productivity down.
It's worth using. like flow it can validate plain js files and even supports a subset of JS doc (on that aspect I wish it didn't, I wish Microsoft established a more powerful format for type comments as an alternative to JS doc which is not well defined, but it does its job). So you don't even have to use ts files. In VSCode IDE, you can just had
to benefit from typescript compiler.At the end of the day, yes, JS today is a safe bet. You can develop native apps with react-native, desktop apps with electron even attempt to include 3rd party language libraries through WASM.
Is it faster than Python? I don't think so, but it's a trade-off. Javascript is ubiquitous now. I say it as someone who still kind of despise the language yet it's productive.
The other route to take is to try to follow the cutting edge of webassembly, so you can continue to use a lot of python. Python is probably going to be first in it's class of languages for support at each step, but it's class is not as ideal for webassembly as non-gc strongly typed languages which are ironically less like Python than JS!
1. TypeScript is just a modern expressive strutural typing system on top of JavaScript, not a full new language.
2. Modern JavaScript (es2017) is not our old JavaScript, the language matured very well. Not perfect, no language it, but as good as it get for a scripting language, and TypeScript has a lot of structure while keeping its flexiblity.
3. JS/TS really enable a Functional First, OO as needed programming style, which can greatly reduce boilerplate code and API code complexity, which in turn makes the code scale better.
Note: I have been doing Java for the last 20 years, building big enterprise Java app for a living for the last 10 years, and right now, I would say that Modern JS / TypeScript and all of its benefit, offer a better productivity environment for big app development, that traditional Java. We just ported one of our client's Java backend, 40% less code, better typed, and better scale (as most node libs are nio/async in nature)
https://github.com/Microsoft/TypeScript-React-Starter
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.
Could they be removed?
Like this, pick your flavor:
https://doc.rust-lang.org/std/option/enum.Option.html
https://docs.oracle.com/javase/8/docs/api/java/util/Optional...
https://docs.microsoft.com/en-us/dotnet/api/system.nullable-...
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.
Exception handling and null checks are both conditional, so there is the potential to replace checking for null with exceptions. Plus, removing the null checks (is an object still an object when most of its properties are null?) could be fixed with better use of inheritance. And the '?' suffix.
This is not the first language Anders has been involved in developing, I'm sure remember him talking about his dislike for null somewhere (I could be wrong). Typescript is both an abstraction and adds features to Javascript. So TypeScript has the opportunity to remove such idioms. Scala and Java are very different languages despite running the same underneath.
The question at the end of the post was more hypothetical. Could this be done or is the concept of null is so ingrained that it can't be removed? (When Functional programming manages null.) I'm just interested, especially when null is known as the "Billion Dollar Mistake" - that's ignoring inflation.
I highly recommend using TypeScript's strict null checks mode as it makes undefined and null their own distinct types and requires that you explicitly state when a field or argument is nullable. The programming experience is somewhat similar to working with 'optional' types in languages like Scala or Swift. See the 'nullable types' section of this document for more info: https://www.typescriptlang.org/docs/handbook/advanced-types....
Probably a convoluted example, however there are distinctions that can be used between the two. Similar to how I've used null + boolean as a tristate with default, true, false where null is default. Undefinied or uninitialized is useful beyond simply null.
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.
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.
You are also correct to point out PropTypes offer no way of adding typing to component or utility functions. I've seldom seen errors arise from the lack of typing here, and if they do you'll usually discover them at runtime. However types as added documentation of function signatures would be nice.
I find this super useful in many of my projects, I hope it helps with some of yours!
https://reactjs.org/docs/typechecking-with-proptypes.html
You can use eslint to enforce the use of prop types, it'll read through your code and will give you a warning if you are using a prop without a corresponding prop types declaration, the rule is called react/prop-types
You can us PropTypes.shape and PropTypes.exact to define the shape of props that are objects, see https://www.npmjs.com/package/prop-types
Even though editors can give reasonable autocomplete for JS these days, I think there's a certain amount of trust and comfort that you lose, and I find it really nice to have little mistakes flagged right as I'm typing rather than when running the code (even when I have a fast iteration cycle).
I also greatly prefer TypeScript when trying to use code I've never seen before, whether that's code written by someone else on my team or third-party code. The types add an extra layer of explanation that's hard to convey in docs or function/variable names.
And as discussed separately, PropTypes is much better than nothing, but I think it has plenty of gaps, and I feel much more confident and comfortable in a codebase with full typechecking.
(I didn't downvote; I upvoted you since I think your post is a good contribution to the discussion.)
I can just talk for myself, but I started a project at work and pushed for TypeScript. We now have automatically generated Swagger-clients fully typed, with a GraphQL layer infront of it with generated types for queries. Basically everything is typed now and I don‘t have to test or check incomming data or guess what kind of object I have to expect from our backend. The tooling is so good now, that the benefits outweigh any setup hassle you have upfront IMHO.
I also think project scope and team size is important -- the larger these are, the more I would consider TS.
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.
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.
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.
[0] https://semver.org/