Hacker News new | past | comments | ask | show | jobs | submit login

As if we didn't have enough reason to move on from Angular. Now you need to learn Typescript to contribute or grok the source files?

This is the main reason why I don't like using languages that transpile into JavaScript. I don't mind the languages themselves but transpiling into JavaScript now means you have to be effective in both languages instead of one to properly debug and you're also subjected to bugs that may or may not be known in the transpile itself.

Everyone seems to hate on JavaScript but it's really not that bad to use.

Have you actually tried TypeScript? It feels just like writing JavaScript, but with a thin layer of type annotations that bring you the familiar advantages of static typing.

It seems to me that JavaScript haters would be better off moving to a completely different language, like ClojureScript. TypeScript rather feels like it's made for people who enjoy JavaScript but wish it provided the peace of mind of static typing.

I tried TypeScript for the first time a few months ago and it was a breeze. I felt "fluent" almost instantly and only had to look up the docs a few times. With ES6+ picking up steam, TypeScript-specific features are being replaced by their ES6+ equivalent, so TypeScript is going to feel even more natural going forward.

I think the problem is that everyone freaked out with the angular 1.x to 2.0 changes. The angular team, not wanting to lose the 1.x momentum, decided to attempt to write a 1.x to 2.0 conversion tool. The major hurdle to doing this successfully is reliably interpreting javascript code such that it can be understand and converted by an automated programming. Now imagine if instead, all that code was written in typescript. Such a conversion tool would be arguably more simple.

It would seem that if you want angular to evolve in possibly non-backward-compatible ways, then conversion tools would be a requirement. And this is going to be a simpler task with a typed language.

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 place.

> 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 ECMAScript 5 and 6 and you open yourself up to possible bugs in the transpiler.

Instead you could just write ECMAScript 5 until 6 is more widely available. Sure no one likes to wait but it requires the least amount of expertise and lower chance of bugs from a 3rd party interfering with your application.

> 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.

I feel more comfortable writing TypeScript rather than using an ES6 transpiler, really. The compiler is built really well - you can observe the team's development process on github and I have to say the level is quite impressive (extensive code reviews and great discussions on the issue tracker).

I'm sure the compiler is well built but stability is my main concern. JavaScript, even with its many flaws, is used by millions of people every day and is one of the most used programming languages in existence. That's a ton of testing through real world use. Since transpilers just compile to JavaScript, they can take advantage of some of the same stability of JavaScript for its output but the act of transpiling is only used by maybe a few thousand users. Sure they'll find bugs and fix them but that's nowhere near the same level as simply writing in native JavaScript (native JavaScript, is that an oxymoron? lol).

Besides all that everything ever created has bugs; why risk introducing bugs from a JavaScript engine and from a transpiler when you can risk a single one?

As an aside my first and last time using CoffeeScript I ran into an issue that, since this was about two years ago, has already been fixed but at the time it cost me hours of debugging time. It really soured my experience with any transpiler.

You have a very valid point regarding bugs. Transpiler bugs definitely happen. When I first tried using Babel - still named 6to5 then - instead of Traceur, it immediately broke my code because of an incorrect TCO implementation in Babel. Babel's maintainer (sebmck) is insanely responsive and the bug was fixed almost immediately, but still.

If I used Babel or any other transpiler for critical production code, I would only enable a whitelist of features that I thoroughly understand: for example, how a fat arrow is translated into a regular function. This vetting would be time-consuming, but that's a price I'd be willing to pay because I enjoy writing ES6 much more than ES5. That's highly subjective though, so I completely understand how some other people would rather just stick to ES5 and get stuff done with the lowest possible risk of weird things happening.

Babel is a completely different transpirer than all the others. It's goal is readable, understandable transpiled code and Sebastian (sebmck) is a genius robot wunderkind. I check the repo everyday and see new updates, bug fixes, etc. It is heartening to see someone give a project so much dedication.

I have an affinity for Babel unlike any other JS project (except React). They team works really hard to keep it interesting.

Yeah, Babel and the Babel team is great. I got very suspicious of the project after my first experience with it broke perfectly valid code, but after reporting the issue and then another and having them fix it almost immediately they won my confidence back. :)

For production code I'd still stick to a whitelist of features that have been released for at least a month though. Babel is aggressively pursuing ES6 coverage and new features might not have all edge cases covered when they're released. Give them one month though and with their responsiveness it's 90% likely it's going to be fixed.

The same can be said for Babel, and it is actually very simple to predict or retro-engineer the transpilation from ES6 to 5.

Some people really like static type checking.

"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.

No, JavaScript is not valid TypeScript. This might be a silly example but there are dozens of similar, small JavaScript programs that are not legal TypeScript (for good reason!).


Try running jQuery's source through the TypeScript compiler some time.

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.

You seem to be unaware of what TypeScript is. TypeScript is more of a high-powered linter than a new language. If you take Javascript and put it in TypeScript mode, most errors are due to variable reuse (x was a number and now a string) or actually an error in the javascript if you're trying to be well typed.

For a certain style of Javascript, making it Typescript is a no-op

I am pretty sure that TypeScript just adds type safety and is optional. I don't see this as a huge negative and I actually see this as a positive.

Just curious, what and why are all your reasons to move away from Angular?

- Not-so-great documentation.

- Lengthy learning curve.

- Not concerned with performance at all (can be a nightmare on mobile devices with low RAM).

- Google's history of throwing away and/or deprecating projects, (see Angular v1).

- I still have yet to see a Google website using Angular in any large capacity.

- Ecosystem lock-in. It tries to do a LOT of stuff, and you generally need to be doing all these things the Angular Way™.

> I still have yet to see a Google website using Angular in any large capacity.

Angular is not intended for typical "websites". It's for replacing what would previously have been desktop CRUD applications. Google use it extensively for internal tooling.

It's also worth remembering that most public facing Google applications have been around for years, decades even. It would take a long time to replace one of these with Angular, even if there was a desire to do so.

> Not concerned with performance at all

I would strongly disagree. Watch this link to when Igor talks about Angular performance.


> - Not concerned with performance

what are the performance issues with TS?

No, that's Angular that has the perf issues.

Oh, I see. NVM then.

I think this was a jab at Angular, not TS.

- Breaking changes

- Obtuse, verbose, non-performant code

- Did I mention breaking changes?

On the other side, the ember guys released a drop-in update.

Pretty performant, see notes: http://t.co/gyBhc5jWzI (or streaming video right now)

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.

According to you it isn't. And that's the fundamental problem here... opinions are like assholes, everyone has one and yours certainly isn't worth more than mine.

I don't know about that. I contributed to protractor and have worked with members of the Angular team in the past.

Opinions maybe useless, but some opinions are more useless than others.

If type safety was the issue, couldn't they have tried Facebook's Flow[1] which believe would have reduced the technical overhead by large?

[1]: http://flowtype.org/

TypeScript has been around longer, and is more widely used.

FWIW, the Angular team mentioned they talked with the Flow team - not sure what that will mean in the near term, but I get the impression that efforts might be in progress to unify the different libraries' efforts.

Flow doesn't work on Windows yet. Atom seems to be the only editor which supports it. That plugin had its 2nd release just 3 days ago.

If I can get Flow to work in vim, I am sure it works in more than just Atom

Define "get to work".

I mean something like this: https://atom.io/packages/ide-flow

Tool-tips, call-tips, auto-complete, type checking, and so forth. The kind of stuff you get with TypeScript or Dart.

Angular 2 was being written in AtScript - in practice, not much has changed, just that Google and Microsoft are collaborating here and unifying efforts.

I think the important part here isn't that it is AtScript or TypeScript or ES6.

It's that they're collaborating.

I'm pretty sure that's a sign of the Apocalypse. We may want to stop worrying about transpiling and pay closer attention to the skies, looking for raining frogs and or blood moons.

Would you complain if a c++ project started using c++/14 features, because "now you need to learn c++/14 to contribute or grok the source files?" Typescript is really just Javascript with type checking, and what would be used in browsers if they didn't have to deal with backwards compatibility.

I don't think that analogy is valid. It's more like if a C++ project started using a bunch of proprietary third-party language extensions, in which case, yes, I would complain because I have to learn some non-standard C++ derivative in order to be able to read the source code.

I disagree. Typescript is just ECMAScript 6, with type annotations. Most of the differences come from the language changes (ES5 -> ES6), than the superset that Typescript explicitly adds.

> Typescript is just ECMAScript 6, with type annotations.

Then it's not "just ECMAScript 6", is it? Anyway, I'm not saying TypeScript doesn't have merit--in fact, I'm considering using it in my next web app. I'm just saying that using TypeScript is a tradeoff that's not without drawbacks, since you're now dependent on a new set of tools and new additions to the syntax (which means, for instance, that your editor/IDE has to specifically support TypeScript). You could say the same about ES6, but at least the latter is at some point going to be standard among browsers (and the tools won't be needed).

>Then it's not "just ECMAScript 6", is it?

It's not "Javascript with a bunch of proprietary extensions", either. Type annotations can't be the difference between understanding code in Typescript if you understand Javascript.

You have a point about tooling, but you would have the same problem if you had a project on visual c++ 6 and upgraded to c++/14, and again, you didn't mention it.

All of this is in spite of the fact that ES6 nearly had optional type annotation in the same syntax that Typescript does, along with many other Javascript derivations that use the same type annotation syntax (Actionscript and Atscript that I know of).

I don't see what the trade-off is. You can just take the transpiling output and go home if you want. Out of all the languages that transpile to JavaScript, Typescript is probably the least risky because it is just JavaScript if you want it to be just JavaScript.

The tradeoff is having to use a language other than JavaScript, which entails having to use a transpiler in the first place, versus just writing plain old JS.

Yes, but Typescript is worth learning IMHO.

That's why I only use assembly. Why would I bother learning C? Now I have two problems!

You can put "C developer" on your resume, good luck shopping around "Typescript developer" experience.

Typescript is a microscopic leap from JavaScript.

For some reason, I doubt that people here would be complaining about learning a language that resembles the next version of Javascript if it didn't come from Microsoft.

Probably, but that's a legitimate concern. Even with Microsoft's recent open source moves (which I think are pretty awesome), we've had a history of having Microsoft force languages and extensions down our throat in an attempt to usurp the open web and standards: ActiveX, VBScript in IE, .hta's, Silverlight, etc.

The counter to that is that TypeScript is Apache-licensed. However, you can't erase history by throwing up a Github repo.

Moreover, I'm hearing more people say they don't trust relying on a big corp for their client-framework. I think many don't disagree with that idea, but more or less trust Google, so they embrace Angular with prejudice. Anything with Microsoft's signature feels less open, and may push some past that tipping point.

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.

Your response seems defensive. I'm not speaking to Microsoft's motives, but to the psychology of developers who have been exposed to "embrace, extend, extinguish" for many years. They don't deserve trust just because "we're nice now, we promise".

The same way that Google's shuttering of services over and over earns them a bit of discomfort amongst their users.

"deserve's got nothing to do with it". The source is open and licenced. If you make technical decisions based on this kind of emotion you will waste a lot of time going round in circles. Because once you start looking for the spooks they're everywhere.

Technical forums ain't what they used to be. The problem for me is that this kind of Tarot card thinking is also now to be found in your local workplace. But there really isn't time for this if you are trying to build things. Do you want type checking in a language that's very close to js or not? If so then just get on with it.

Look at the list of contributors to the project (both in terms of numbers of committers and commits). Overwhelmingly Microsoft employees. Until it gains some serious momentum where it could successfully be forked and seriously maintained by the open source community at large, at this point it's a Microsoft product, and you have no choice but to trust their support and openness, so you can't hand wave away the trust issue as "Tarot card thinking".

Uhhh...lots of Microsoft employees working on Typescript is a good thing. Pulling the old, "We're happy to leave this in "the community's" hands would be a bad thing for obvious reasons.

Seriously, stop the FUD

You're right, no open source projects that weren't developed in the majority by a single large corporate benefactor have ever succeeded. We can trust those corporations: they have our best interests at heart. Now if you'll excuse me, I need to get back to my successful career building applications for the Google Glass.

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 ecosystem.

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

> For some reason, I doubt that people here would be complaining about learning a language that resembles the next version of Javascript if it didn't come from Microsoft.

Why? Sure, people here complain about Microsoft, but people here also complain about (1) novel things in domains where they think the existing thing is good enough (which, for many, JS probably is), and (2) things, new or old, that they see as fundamentally flawed (which, for many here, JS or any "next version" that isn't radically different, is.)

So, I suspect people here would be complaining about having to learn a language that resembles the next version of JS whether or not Microsoft is involved. Maybe not exactly the same set of people that are complaining with Microsoft involved, but people here nonetheless.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact