Announcing TypeScript 3.1
blogs.msdn.microsoft.com
blogs.msdn.microsoft.com
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.
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)
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
// @ts-check
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!
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.
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.
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.
I find this super useful in many of my projects, I hope it helps with some of yours!
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
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.
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 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.
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.
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.
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?
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....
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.
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.
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.