Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing TypeScript 2.1

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

191–200 of 226 posts

Re: Announcing TypeScript 2.1

#191

Post by Sankozi »

WorldMaker wrote: post #141
ng12 wrote: post #5

Hurrah for object spreads! Time to go grepping for calls to _.default and _.extend.

Also, Object.assign

Unfortunately

  newThing = {...thing, propertyName: value}
Will always compile, even if propertyName is invalid. The only advantage over Object.assign I see is IDE support (at least in Intellij IDEA). I will still use:

  newThing = Object.assign({}, thing);
  newThing.propertyName = value;
This will not compile if propertyName is invalid and is IDE friendly.

Re: Announcing TypeScript 2.1

#192

Post by pitaj »

thewhitetulip wrote: post #177

I recently started learning JS, and now I am confused between TS and babel. Can anyone give me a reason why I should use either of the two and when I should use either of the two?

TS adds a complete static type-checking system, and also will compile down your bleeding-edge JS language features into supported syntax.

Babel will do the second part.

Re: Announcing TypeScript 2.1

#193

Post by pitaj »

ausjke wrote: post #90
ygra wrote: post #41

Earlier quoted context omitted.

They are not related at all, except in who is their original designer. However, if you are really so fundamentally opposed to anything and everything a certain language represents then you've got to hate a lot of languages for a really, really petty reason.

For the record I embrace all new stuff except for two, that is Microsoft at-large and systemd.

Oracle should probably on that list

Re: Announcing TypeScript 2.1

#194

Post by boubiyeah »

twfarland wrote: post #185
edblarney wrote: post #98

After 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…

I've stopped using those OO-ish paradigms in JS (no 'this', 'new', 'prototype'), but even still, have much preferred using TS. You can get a long way (and have great flexibility) with only interfaces and generic functions.

Same, it's so much saner. classes or prototypes bring nothing but troubles to the table, except when you want to have tons of objects in a memory efficient way in library code.

TS does a great job without OO thanks to structural typing.

Re: Announcing TypeScript 2.1

#195

Post by mattmanser »

taspeotis wrote: post #169
mattmanser wrote: post #168

Earlier quoted context omitted.

async/await in C# is pretty nasty and usually overused and overhyped for nothing but downside. It screws debugging, it screws call stacks, it dictates you to write bad code and it's just plain complicated. It infects your code up and down the stack and every new method MS now releases seems to be .SomethingAsync(). I likened it today to having a garden hose in a Victorian sewer but then declaring the sewer is the bot…

I think it is unfair to compare async/await on top of poorly performing code with async/await generally. Fast synchronous code being faster than slow asynchronous code is kind of tautological. async/await keeps your UI thread unblocked. Or, more generally, it keeps your threads unblocked. I have an ETL process that benefits from async/await greatly: I can stream more data in/out of the database with fewer threads. Th…

Why is it tautological? There is no performance gain for most people using async/await, at all. That's simply not how it works. You have to be in a specific scenario, high load on the server's resources, not the DB, to see any benefit.

And while keeping the UI thread unlocked is great, how many people are using this in C# web code instead?

Where the entire web pipeline is already set up to naturally multi-thread by itself.

Re: Announcing TypeScript 2.1

#196

Post by vog »

ryanSrich wrote: post #68
timruffles wrote: post #11

If 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?

I'd like to throw in OCaml in this mix, which can be translated to JS via bucklescript or js_of_ocaml.

So how do TypeScript and Elm compare to OCaml?

Re: Announcing TypeScript 2.1

#197

Post by taspeotis »

mattmanser wrote: post #195
taspeotis wrote: post #169

Earlier quoted context omitted.

I think it is unfair to compare async/await on top of poorly performing code with async/await generally. Fast synchronous code being faster than slow asynchronous code is kind of tautological. async/await keeps your UI thread unblocked. Or, more generally, it keeps your threads unblocked. I have an ETL process that benefits from async/await greatly: I can stream more data in/out of the database with fewer threads. Th…

Why is it tautological? There is no performance gain for most people using async/await, at all . That's simply not how it works. You have to be in a specific scenario, high load on the server's resources, not the DB, to see any benefit. And while keeping the UI thread unlocked is great, how many people are using this in C# web code instead? Where the entire web pipeline is already set up to naturally multi-thread by…

> There is no performance gain for most people using async/await, at all. That's simply not how it works. You have to be in a specific scenario, high load on the server's resources, not the DB, to see any benefit.

If you have two asynchronous things to do, and they are unrelated, start them both and then await Task.WhenAll(file1Download, file2Download). Look at the wall clock - it's up to twice as fast. Look ma, no threads or synchronization primitives!

> And while keeping the UI thread unlocked is great, how many people are using this in C# web code instead? Where the entire web pipeline is already set up to naturally multi-thread by itself.

Blocking operations ... block. Now your thread is doing nothing while your database churns/disk writes/network packet streams. As I understand it, using async/await with the SynchronizationContext in ASP.NET will yield the thread to another request. You get more requests per thread, which mitigates the problems with thread-per-request as described here [1]. Instead it's a combination of thread-based and event-driven models.

[1] http://berb.github.io/diploma-thesis/original/042_serverarch...

Re: Announcing TypeScript 2.1

#198

Post by mpawelski »

ausjke wrote: post #164
mpawelski wrote: post #135

Earlier quoted context omitted.

Once sometimes asked me "Isn't Typescript a language for C# developers that don't know JavaScript" It's unfortunate that people think that TS is similar to C# just because it came from Microsoft. Flow language is like 80% similar to TS, but no one says it's similar to C#. TS is just JS + new features from future JS specification + optional type system. And optional type system is fundamentally different than the one…

Thanks. That makes me feel better and I will give TS a shot this holiday.

great to hear that :)

Re: Announcing TypeScript 2.1

#199

Post by Fifer82 »

ausjke wrote: post #164
mpawelski wrote: post #135

Earlier quoted context omitted.

Once sometimes asked me "Isn't Typescript a language for C# developers that don't know JavaScript" It's unfortunate that people think that TS is similar to C# just because it came from Microsoft. Flow language is like 80% similar to TS, but no one says it's similar to C#. TS is just JS + new features from future JS specification + optional type system. And optional type system is fundamentally different than the one…

Thanks. That makes me feel better and I will give TS a shot this holiday.

You won't look back! Will look down at others even!

Re: Announcing TypeScript 2.1

#200

Post by z3t4 »

friendzis wrote: post #188
z3t4 wrote: post #136

Earlier quoted context omitted.

Thank you for actually providing an argument for having types. The parser could however in-line the function and replace obj for foo. I do advocate using the same variable names for function arguments though, as having different names for the same variable is not only hard to refactor, it's also very confusing! So instead of using "that", me, myself, obj, str, etc, use the actual variable name! Disclaimer: I'm workin…

Either I do not understand your point or you are walking a thin line. If a particular function can be tied to particular variable from scoping block, then the function is not entirely useful. On the other hand, if a function is general and has the same argument name as variable from scoping block, which is going to be passed in, mentally it is difficult to analyse the function without thinking about the variable whic…

I think the problem has to do with object oriented programming and classes. Like when you have an Apple that inherits from Fruit, witch later starts looking like a Banana. With prototype you do not have that problem as you copy-paste code instead of couple code. When you rename a variable and have to search more then one function or file, then there are bigger problems with your design, because you are basically using a global variable, even though it's praised as a module. Now does your refactor tool also fix documentation and other peoples code that depends on yours ?

  function Person(name) {
    var person = this;
    person.name = name;
  }
  
  var person = new Person("Jon Doe");
  
  alert("Welcome " + person.name);

  person.name = "Harry Houdini";

  // ES6 example:
  var messages = people.map( person => person.name += " is a rock star" )
Post reply on HN