Hurrah for object spreads! Time to go grepping for calls to _.default and _.extend.
Also, Object.assign
Announcing TypeScript 2.1
141–150 of 226 posts
Re: Announcing TypeScript 2.1
#142It's interesting to me that all of the initial reactions I've seen to this announcement have been around the introduction of async and object spread, which are available with babel, but the typescript specific features such as mapped types are completely ignored. I don't really have any particular meaning behind that observation, only that it tickled my funny bone a little bit.
TypeScript PM here - the reason for that is that when we implement a feature in TypeScript, we take lengths to ensure that it is typed appropriately and that its performance characteristics are reasonable. That means that when using object rest/spread, we didn't want to just ship an experience where type type is effectively `any`, leading users to be frustrated if they make an error. With async/await, we had to rewri…
Did you mean to reply to my comment? If so, to help clarify, I wasn't critiquing the long delay of those features; I merely was amused that they've gotten so much more attention than the far more novel features that were also released.
Re: Announcing TypeScript 2.1
#143Can someone comment on the difference in reliability between using typescript and a natively statically typed language like haskell or scala? Is there any? Or is the type safety really as good when you use ts
One thing you might miss in TS is the ability to just try to check or cast an object at run-time to check that it's really of some nominal type, or structurally compatible with some type/interface. TS can't do that because it doesn't have runtime type information for its types - the types are a compile-time only thing. TS does allow creating functions that return type predicates, but that requires your own manual che…
ahh interesting, that seems like a pretty significant difference. just to clarify, this means that you wouldn't be able to do things like:
if (my_var instance_of MyCustomType)
in TS, but you could in normal statically typed languages, correct?
Re: Announcing TypeScript 2.1
#144Dear TS authors: Thank you (!) for your amazing contributions. TS is the best new thing in tech. That said: Your linguistic genius is way ahead of the tooling. I feel as though some of these 'new and cool' 2.1 things are a little bit intellectual, maybe useful in some cases ... But getting TS to work in the real world, the various build configurations, tool-chains etc. - it's still clumsy. It was difficult to grasp t…
Your pain point sounds like a runtime problem with your module loader. You may want to investigate your module loader's issue tracker. (I recommend SystemJS [and jspm] over AMD these days, for what that is worth. It handles module loading quite well including all the complexity of circular dependencies that ES2015 specced and TS supports.)
«I feel as though some of these 'new and cool' 2.1 things are a little bit intellectual, maybe useful in some cases ...»
async/await and object spread should be useful in quite a lot of places. The other "intellectual" additions are immediately useful indirectly because they were built to support object spread (so that object spread types make sense), even if you don't wind up using the directly (because you aren't writing complicated type definition files for instance). Even then, you might find a bunch of uses for the types Partial (partial objects) and Readonly (shallowly frozen objects).
Re: Announcing TypeScript 2.1
#145How does the development cycle work? With plain JS I load up my html page in browser (chrome) and head to the console to check for errors in the JS. Then I do user testing. Can type-script be debugged by a browser on a source code level - ie not on a transpiled level? If not, I am not sure if it's worth it. And I say that as someone who is a huge fan of explicit optional typing.
There is typically a quick transpile process in the IDE/toolchain of your choice. Most browser dev tools now support sourcemaps quite well which means that debugging shows the TS source and breakpoints are set directly there and typically show error stacktraces with your TS files.
Another option is to load Typescript in your browser and let it transpile directly in the browser. Sourcemaps in this case are a bit more iffy in their browser support, but it can be an option for a quick debug cycle if you wanted to try something like that. Not particularly the fastest idea for a production app, though.
Re: Announcing TypeScript 2.1
#146Earlier quoted context omitted.
One thing you might miss in TS is the ability to just try to check or cast an object at run-time to check that it's really of some nominal type, or structurally compatible with some type/interface. TS can't do that because it doesn't have runtime type information for its types - the types are a compile-time only thing. TS does allow creating functions that return type predicates, but that requires your own manual che…
ahh interesting, that seems like a pretty significant difference. just to clarify, this means that you wouldn't be able to do things like: if (my_var instance_of MyCustomType) in TS, but you could in normal statically typed languages, correct?
I shouldn't have included nominal typing - it seems the instanceof operator actually works, e.g. see http://stackoverflow.com/questions/24705631/typescript-myobj....
But in TS itself structural typing is used everywhere for actual type checking (except for classes with private members), and from my understanding there's no way to have TS help you check at runtime whether a type is structurally compatible with a value.
Re: Announcing TypeScript 2.1
#147Dear TS authors: Thank you (!) for your amazing contributions. TS is the best new thing in tech. That said: Your linguistic genius is way ahead of the tooling. I feel as though some of these 'new and cool' 2.1 things are a little bit intellectual, maybe useful in some cases ... But getting TS to work in the real world, the various build configurations, tool-chains etc. - it's still clumsy. It was difficult to grasp t…
Your pain point sounds like a runtime problem with your module loader. You may want to investigate your module loader's issue tracker. (I recommend SystemJS [and jspm] over AMD these days, for what that is worth. It handles module loading quite well including all the complexity of circular dependencies that ES2015 specced and TS supports.) «I feel as though some of these 'new and cool' 2.1 things are a little bit int…
Yeah, agree with async/await and spread.
Re: Announcing TypeScript 2.1
#148After trying TS, I basically never want to write JS again. I know that 'OO' and 'typing' is not the solution to everything ... but aside from all the nice things you can do in TS ... the 'enforced architecture' of OO-ish paradigms, combined with typing, and essential obfuscation of the prototype paradigm ... has cut the time to development in half. I can hardly think of a reason to use JS now that TS exists. Of cours…
What OO does typescript have that js doesn't?
+ Member access private/protected
+ Static members (theoretically exist in JS, but much cleaner and 'compiler aware' in TS)
+ Interfaces
When I write JS, I end up with closures within closures within closures.
When I write TS, I find myself sticking to much cleaner abstraction. I end up (having to) create classes, and usually it's for the better.
Re: Announcing TypeScript 2.1
#149If you still haven't given TypeScript a go as a Javascripter, now is a great time to do so. Whether you end up adopting it or not, it's interesting to get the types out of your mind and into the code. The first time you feel the speed/confidence of refactoring with accurate 'Find usages', you'll decide if the undeniable overhead of types is worth it.
Can anyone weigh in on TypeScript vs Elm?
------------------
Elm
------------------
[Pros]
- Good language design (immutable, based on haskell+OCaml, nice type unions/pattern matching, everything is an expression, etc) Most people who write Elm are seduced by its elegance.
- Very, very typesafe. If it compiles, 99.5% of chances that you won't get runtime errors (baring a few bugs) handy when you're tired.
- It was made for beginners, it's easy to pick up, the tooling is simple, the compiler errors are easy to read.
- The "Elm architecture" provides a way to build simple SPAs, out of the box, without having to use 10 libraries like some people do in the JS world.
[Cons]
- The community is tiny
- Elm is... by far the most opinionated environment I've ever seen. More so than RoR/Ember. Elm the language and Elm the framework have no clean escape hatches. It provides guidance for newbies, but when you encounters problems, it stings.
- The Elm framework is entangled with the Elm language. One person pretty much maintains both; developments go at a very slow pace and potential contributors don't feel overly welcomed.
- Elm's type system is extremely simplistic. You won't be able to express many things with it, and your code will have a LOT of boilerplate.
- if you're a front end developer with a sharp attention to details, it's a pain to build complex things with it, especially SPAs who have a lot of state. You need hacks all the time as the language + the framework are fairly under powered and it gets new features once every blue moon. There are many things that are impossible to do in pure Elm, so you have to write javascript anyway. The official way is to use ports, but many teams seem to rely on the frown upon Native modules, which are written in awkward JS.
- Talking to Javascript (foreign interface) is a bit of pain (less so now than in the past though!) and so is reading/writing JSON, compared to typescript.
-------------- Typescript --------------
[Pros]
- Extremely productive, you're never stuck with a problem
- There is an entire team of professional developers behind this project. beta and RCs are actually more robust than Flow releases, for instance. You can even depend on nightly builds... It's solid.
- Very typesafe (way more than Java for instance), if you know what you're doing.
- The type system is now very, very expressive (version 2.0 and 2.1 helped a lot)
- It's extremely easy to use JS libs in your typescript project
- Performances are good as the generated JS is pretty much just the TS without the types annotations. There is no runtime, shim, etc.
- You still have access to everything JS, so for instance you can use CSS modules with webpack just like if you were using JS. The community is enormous.
[Cons]
- It's still crappy old javascript underneath. Everything is mutable (worse, Array apis mix mutable and immutable styles), if/else are not expressions, the "this" keyword, prototypes, classes are complete madness.
- Not typesafe enough if you are careless. Lots of traps. Unlike Elm, you can actually shoot yourself in the foot by not knowing about certain compiler flags, using too often (I use a no-any tslint rule) or generally not paying attention enough (you need to give hints to the compiler in the right places) It's always going to be less typesafe than Elm though. For instance, functions are bivariant, ewww.
So for me, Elm is interesting conceptually and it has the potential to become good in a few years (perhaps compiling to web assembly) but typescript is the pragmatical choice in the short/medium term, unless you're building something fairly simple, in which case you can use absolutely whatever you want anyway!
Re: Announcing TypeScript 2.1
#150Earlier quoted context omitted.
One thing you might miss in TS is the ability to just try to check or cast an object at run-time to check that it's really of some nominal type, or structurally compatible with some type/interface. TS can't do that because it doesn't have runtime type information for its types - the types are a compile-time only thing. TS does allow creating functions that return type predicates, but that requires your own manual che…
ahh interesting, that seems like a pretty significant difference. just to clarify, this means that you wouldn't be able to do things like: if (my_var instance_of MyCustomType) in TS, but you could in normal statically typed languages, correct?
It's a bit more complicated than that because of JS's prototype-oriented object system. If MyCustomType is a proper prototype (say you built it with the class keyword) you can certainly instanceof it. (That said there are strange edge cases where statically typed class-based object intuition falls down against prototype-oriented reality.)
The issues tend to start cropping up as you get further into TS-specific types like generic types. In a statically typed language you can inquire about the specifics of an implementation of a generic directly, and often even dispatch directly on that type. JS has no concept of your generic wrapper type and you need some other flag or logic to determine the runtime type of your generic code.