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

Angular 2: Built on TypeScript

blogs.msdn.com

Post reply on HN
Print view View original

171–180 of 235 posts

Re: Angular 2: Built on TypeScript

#171

Post by calgaryeng »

wycats wrote: post #124
coldtea wrote: post #119

Earlier quoted context omitted.

> How in the world does this man keep up with all these projects? He needs to write a book on motivation. By dumping them mid-way and getting to the next shiny one? Anybody knows how this RoR kickstarter project finally went?

Yep. I shipped Tokaido and people use it. It was mentioned on Ruby Weekly last week. You can get releases at https://github.com/tokaido/tokaidoapp/releases . Andres (who now maintains the project) released Tokaido for Ruby 2.1 (with support for Mavericks) recently and we're working on Ruby 2.2 support as we speak. The org is here: https://github.com/tokaido/ and there are a number of auxiliary projects (muxr and toka…

Big ups for the "bigger man" type response :)

Re: Angular 2: Built on TypeScript

#172

Post by sanderjd »

andrewstuart2 wrote: post #168
WhitneyLand wrote: post #82

Angular 2 is having a lot of pushback and challenges, but this may be a positive. First, there have been hard feelings over breaking backward compatibility. To rub salt in the wound the new syntax doesn't seem to buy you much for many basic scenarios. If you are going to push big breaking changes you need to show big benefits that are easy to understand at a glance. Secondly, the Ember community started small but has…

The main mistake, in my opinion, that Angular 2.0 is making is removing two-way data binding. The whole cornerstone of my love for Angular was the idea that wherever data was updated (view, model, server, another user's browser, etc.) it was trivial to make that update appear everywhere else. This is even more powerful when you add in a technology like WebRTC data channels or websockets. I could just bind the data to…

I had the same "wow" moment with two-way binding awhile back. Now I think that the important part is having a source of record that consumers can observe for changes, and a good way to update that source of record. Two-way binding is just one way to give you that. In my experience it's far more common to read data than write it, so making it more explicit where writes are happening is not burdensome and seems more maintainable and performant.

Re: Angular 2: Built on TypeScript

#175

Post by DDcsidsIOIDp »

dubcanada wrote: post #35
ratbeard wrote: post #11

Earlier quoted context omitted.

Dart requires loading a dart runtime js file on to the page, as far as I know. And I think they would claim Typescript is javascript + some extra stuff on top, whereas dart is a whole new language to learn.

No Dart compiles to JS. Obviously there is some overhead with transpiling languages, but it's actually pretty small. They have done a good job with it.

> "No Dart compiles to JS."

The question is not here, the relevant question is

"Does JS compiles in Dart ?"

Because, JS Compiles fine in TypeScript, which means Typescript benefits from all JS ecosystem and vice versa.

Re: Angular 2: Built on TypeScript

#176

Post by sethladd »

aikah wrote: post #41
electrotype wrote: post #5

Why not Dart?

There is angular Dart, I'm sure there will be angular Dart 2. The problem of Dart , well have you ever seen some Dart code ? it's miles away from javascript. Have you ever seen some Dart2Js code ? It's heavy , megabyte heavy. Who's going to work with a framework that weight that much ,developped in a third party language ? Good luck with that.

It's only megabyte heavy if you use all of Dart's reflection capabilities. If you don't use dart:mirrors, Dart is competitive in size when compiled to JavaScript, especially when you consider that a modern web app today contains a bunch of support libraries like jQuery (which itself is ~30kb). With Dart, you don't need jQuery because Dart's dart:html and dart:core libraries are pretty good out of the box. Of course, do your own measurements as each app is different.

Re: Angular 2: Built on TypeScript

#177

Post by dmarg »

andrewstuart2 wrote: post #168
WhitneyLand wrote: post #82

Angular 2 is having a lot of pushback and challenges, but this may be a positive. First, there have been hard feelings over breaking backward compatibility. To rub salt in the wound the new syntax doesn't seem to buy you much for many basic scenarios. If you are going to push big breaking changes you need to show big benefits that are easy to understand at a glance. Secondly, the Ember community started small but has…

The main mistake, in my opinion, that Angular 2.0 is making is removing two-way data binding. The whole cornerstone of my love for Angular was the idea that wherever data was updated (view, model, server, another user's browser, etc.) it was trivial to make that update appear everywhere else. This is even more powerful when you add in a technology like WebRTC data channels or websockets. I could just bind the data to…

I think that the Angular team has not decided on two-way data binding yet. They maybe keeping it and I just asked this question on the reddit ama that they are going to do over at the /r/ngconf subreddit.

Re: Angular 2: Built on TypeScript

#178

Post by BinaryIdiot »

DDcsidsIOIDp wrote: post #170
smacktoward wrote: post #127

Earlier quoted context omitted.

"You have a problem with JavaScript. You rewrite your entire code base in TypeScript. Now you have two problems."

Wrong, JavaScript is valid Typescript, so you don't have to rewrite anything.

This is a silly thing to say; why would you use TypeScript if you're going to leave everything exactly as it was in JavaScript? Wouldn't want to rewrite it using TypeScript features? Otherwise there would be zero point to TypeScript.

Re: Angular 2: Built on TypeScript

#180

Post by paulftw »

WhitneyLand wrote: post #82

Angular 2 is having a lot of pushback and challenges, but this may be a positive. First, there have been hard feelings over breaking backward compatibility. To rub salt in the wound the new syntax doesn't seem to buy you much for many basic scenarios. If you are going to push big breaking changes you need to show big benefits that are easy to understand at a glance. Secondly, the Ember community started small but has…

PHP was also very easy to understand. Maybe sometimes, as a professional you have to spend few weeks grasping a complex paradigm, if that is going to boost your productivity for a couple of years afterwards.
Post reply on HN