Live data from Hacker News

Angular 2: Built on TypeScript

blogs.msdn.com

221–230 of 235 posts

Re: Angular 2: Built on TypeScript

#221

Earlier quoted context omitted.

Transpiling may actually be the safest way to use JavaScript, especially given its rate of change. Take, for instance, a number of features trickling down the ECMA2015 pipe: modules, classes, "let", etc. Using these features without a transpiler, such as Babel, is simply not possible. A transpiler allows you to use these features now without any worry. Not all transpilers may be to your taste, but they have their pla…

> Transpiling may actually be the safest way to use JavaScript, especially given its rate of change. [..] A transpiler allows you to use these features now without any worry. I disagree and my original statement applies as much to TypeScript as it does to an ECMAScript 6 transpiler. If you want to use the new features and you're transpiling now you need to have a good understanding of the differences between ECMAScri…

> Sure no one likes to wait but it requires the least amount of expertise and...

I would argue that knowing some of the implementations of features such as module/export/class/extends of TypeScript in native javascript requires a lot more expertise to create coherent OOP code than just opening up TypeScript and using a syntax for OOP that most people are already familiar with.

Re: Angular 2: Built on TypeScript

#222

Earlier quoted context omitted.

Ironically your comment could be taken as a classic example of the kind of FUD Microsoft used to spread. You give examples from the past that, you admit, clearly don't apply. You talk about "feels less open" when it is factually not. You speculate on others (who are they?) being pushed past a tipping point. Doubt, doubt, doubt and fear, fear, fear when in fact there's nothing you can point to in reality to back it up…

Microsoft is currently in the middle of a push to get more developers onto their proprietary platforms. Microsoft isn't doing these things because they are just so friendly and selfless. These are strategic moves. Not only are these strategic moves, they are strategic moves by a large company aimed at competing with people like me who develop software on multiple platforms and contribute, unpaid, to an open software…

Is this why they are pushing to allow Write/Compile/Run .NET on any platform?

Re: Angular 2: Built on TypeScript

#223

Earlier quoted context omitted.

Well, there's their problem... Edit: Ok, for the down voters. Angular is HUGE. And all that code has to get shoved onto the client side when someone visits a page. And that's JUST for the framework. We aren't even talking about the application code yet. More and more clients are mobile. Nobody sees a problem here? You're using more (precious) data, it's slower to load and slower to run. It's just a nasty little trend…

Only if you have caching disabled. If you use a CDN, the library is likely already on the users computer. That said their 25k loc code base is 123kb (45kb gzipped)

I find a common theme among the people who freak out about 45-100kb of js are often the people with 3MB of images on their page.

Re: Angular 2: Built on TypeScript

#224
post #89

Earlier quoted context omitted.

Until they tret null values as a separate type, I'm with Facebook Flow.

Although I haven't tried Flow, I have taken a glance at it's Maybe Types. I don't think that it is possible to work around libraries and browser APIs returning nulls, and undefined seems to be completely ignored. I think if you want to get rid of null/undefined then you have to use a complete different language, something like Elm, but I would welcome being proven wrong.

What do you mean it's not possible to work around libraries and APIs returning nulls? That's exactly the point I made, Flow solved it.

Yes, they had to write interface for all browser APIs (and it's incomplete, PRs welcome), and in places where API might return null it states that it may return it. And your code has to deal with null and non-null cases explicitly (or at least put an if).

You are right though that this type-system is much weaker than other languages like Elm or Haskell, and for me, being from a Haskell world, writing JS with Flow was still a disappointment. It's just that currently there's no better alternative I know in terms of interop with JS and good level of error-reporting.

Re: Angular 2: Built on TypeScript

#225

Earlier quoted context omitted.

- Breaking changes - Obtuse, verbose, non-performant code - Did I mention breaking changes?

Because progress sucks. I still don't see why we don't continue using IE 6.

Progress is great.

IMHO, Angular isn't progress, and neither is painting yourself into a corner.

Re: Angular 2: Built on TypeScript

#226

Earlier quoted context omitted.

It probably is if you have to deal with > 25k LOC code base like what Angular has.

Well, there's their problem... Edit: Ok, for the down voters. Angular is HUGE. And all that code has to get shoved onto the client side when someone visits a page. And that's JUST for the framework. We aren't even talking about the application code yet. More and more clients are mobile. Nobody sees a problem here? You're using more (precious) data, it's slower to load and slower to run. It's just a nasty little trend…

Please don't comment about downvotes or bait other users into downvoting you. Those are rules of the site:

https://news.ycombinator.com/newsguidelines.html

Re: Angular 2: Built on TypeScript

#227
There's clearly a corporate agenda with 2.0 but who cares. The most important question is "Is this the best thing for my scenario?" Probably not but it has a name.

There's too much talk about "typescript" and not enought about what problems Angular 2 solves compared to "not" having a ready made framework or how many problems it adds.

Re: Angular 2: Built on TypeScript

#228
post #207

Earlier quoted context omitted.

I think angular is not after runtime type checking , like the TypeScript compiler. I think what they're after is keeping type information beyond `instanceof`, like keeping information about interfaces and the ability to access type properties beyond `Foo.prototype.bar`. Edit: to clarify, runtime type information should not be used to check for types again , but rather to do things similar to Java's reflection.

The angular team designed atscript. Have a look at their doc. It does contain runtime type checking and it looks like this: var length = rtts.type(name.length, rtts.int); https://docs.google.com/document/d/11YUzC-1d0V1-Q3V0fQ7KSit9...

You're right, sorry.

Re: Angular 2: Built on TypeScript

#229
post #224

Earlier quoted context omitted.

Although I haven't tried Flow, I have taken a glance at it's Maybe Types. I don't think that it is possible to work around libraries and browser APIs returning nulls, and undefined seems to be completely ignored. I think if you want to get rid of null/undefined then you have to use a complete different language, something like Elm, but I would welcome being proven wrong.

What do you mean it's not possible to work around libraries and APIs returning nulls? That's exactly the point I made, Flow solved it. Yes, they had to write interface for all browser APIs (and it's incomplete, PRs welcome), and in places where API might return null it states that it may return it. And your code has to deal with null and non-null cases explicitly (or at least put an if). You are right though that thi…

> What do you mean it's not possible to work around libraries and APIs returning nulls? That's exactly the point I made, Flow solved it.

Sorry, I had the really stupid misconception that Maybe Types could not be applied to libraries and browser APIs.

So it seems like a good start, but it doesn't seem really useful if they aren't even in the basic API's descriptions: https://github.com/facebook/flow/blob/master/lib/dom.js#L198

Re: Angular 2: Built on TypeScript

#230
post #106

Earlier quoted context omitted.

That cherry picking you just made just completely reversed what was actually said in that article: "A common misconception is that JavaScript is similar or closely related to Java. It is true that both have a C-like syntax (the C language being their most immediate common ancestor language). They also are both typically sandboxed (when used inside a browser), and JavaScript was designed with Java's syntax and standar…

> A common misconception is that JavaScript is similar or closely related to Java. He said it looks like Java, I believe. Not "it's similar to Java".

And the article says it started out looking like Java. It didn't for long.
Post reply on HN