My understanding is that TypeScript will be used in place of AtScript—the language the Angular folks created to be able to cross-compile a single codebase to both JS and Dart. JS and Dart will still be first-class supported target languages.
Nope, AtScript was doing runtime type checking (AtScript is basically traceur with some experimental features) while Typescript DOESNT. To be fair , I don't care, but that's an important precision.
It means that the Angular team is giving up on traceur or maybe traceur and typescript will merge somehow in the future.
Angular is built with AtScript. AtScript is an extension of ES6 (ECMAScript 6), the new specification of the JavaScript language. This quickstart features AtScript, but you can write Angular in ES5 or ES6 as well.
ES6
AtScript compiles to ES6, which is not widely supported in all browsers today. The es6-shim.js file allows you to use ES6 or AtScript in the browser.
es6-shim
The quickstart repository includes es6-shim.js. The es6-shim.js file includes dependencies (such as Traceur) needed to compile ES6 in the browser. Traceur is an ES6 compiler that transpiles ES6 to ES5 code.
I don't see why anyone would want runtime type checking the way AtScript does it.
With static typing, the compiler can catch type errors early, at the cost of rejecting some otherwise valid programs.
With dynamic typing, that type checking is delayed until execution time. More programs are valid, but type errors are caught late.
With AtScript-style late type checking, they took the dynamic type system and introduced more type errors. This decreases the amount of valid programs, yet catches no errors at compile time. It does nothing but increase the amount of bugs.
You want both. Compile-time checking is necessary but not sufficient. Applications are not monoliths anymore, and web applications especially will interact with multiple other processes and services. For these you really need dynamic type checking. You can either try to do it in an ad hoc way in the application code, or building the check into the language.
Exactly. And even when you receive data from your "own" services that you have type definitions automatically generated for, maybe there's a version mismatch in a deployment somewhere and so on.
It describes an extension to TypeScript that includes efficient runtime type checking. They encode type information only in situations where checks are necessary, and only information that cannot be otherwise deduced from the context.
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.
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.
Yes Dart compiles to javascript, but it has pretty different semantics from javascript and needs to insert extra javacript to get your transpiled javascript to run. For example, noSuchMethod isn't available in all js engines so using https://www.dartlang.org/articles/emulating-functions/#inter... in dart would require a non-trivial amount of wrapping code to be generated.
I imagine they've improved the runtime size since that stack overflow post was posted a few years ago. However I've never used dart and just tried it out using a basic html sample from the tutorial page and I see:
264 Mar 5 12:21 a.dart
237K Mar 5 12:21 a.js
101K Mar 5 12:22 a.min.js
If you add gzip compression, it's still smaller than doing the same thing with jQuery. "dart:html" provides an idiomatic DOM API where all list-like things are actually Lists, events are streams, Futures instead of callbacks, and so forth. It's pretty nice to use, but it's also one of the bulkier libraries.
Also note that you could now add a thousand lines of code and the file size wouldn't increase much. You already paid that one-time cost.
You can further improve the size by using a better minifier on top of --minify.
Ah, that makes sense re:same size as if you added jquery, and the API abstractions do sound better.
Though as a counterpoint (and relevant to angular 2 :) I read they're going to just use the raw dom api's instead of a jquery/jquery-lite abstraction layer as the dom api's don't need the smoothing over in modern browsers like they used to.
Dart can be run in both modes. Chrome (dunno if enabled by default and/or in stable) contains a Dart VM, so you "only" need to transpile into JS for non-Chrome.
The main problem I had with Dart was [a year ago] that using existing JS libraries like jQuery wasn't as seemless as I would liked. So that would be a reason against Dart, if Angular wants to make that aspect easier.
Haven't looked at TypeScript's interop with JS. I got frightened by the name Microsoft and the fact that they only had a huge language spec PDF and not a single tutorial or something easier to digest.
In production, it's only ever transpiled to JavaScript.
> Chrome (dunno if enabled by default and/or in stable) contains a Dart VM, so you "only" need to transpile into JS for non-Chrome.
Not the real Chrome. A version of Chromium that you can use to make the development cycle smoother. When you deploy, you still transpile to JavaScript for all browsers.
All JavaScript is valid TypeScript. This was one of the founding tenants for TypeScript. So interop is "just use the JS".
You can optionally also provide a binding file that tells TypeScript about the JS code so that it can perform compile-time checking on calls. There is a repository of these bindings for common libraries called DefinitivelyTyped [0].
> ... They only had a huge language spec PDF and not a single tutorial or something easier to digest.
Not sure when you originally looked, but there is now a tutorial [1], handbook [2], and samples [3] in addition to the language spec [4].
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.
Because Dart isn't a viable option for writing libraries or frameworks which are meant to be used from JavaScript.
You can interact with JS libraries, but exposing some API to JS-land is a completely different matter.
There are some vague plans to improve this, but there hasn't been much interest, because if you use Dart anyways, you do of course want to use it as the "host" language. It has the tooling and all that jazz. Of course you'd want to use it for as much as you can.
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.
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.
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.
> 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.
So where is the example of why I would want to use Angular? And if it's so great Google would have transferred some of their websites over to it. I see no example of Angular being some awesome framework that inspires me to use it.
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.
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.
> 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.
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.
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.
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.
> 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 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.
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
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!).
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.
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).
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.
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).
So Angular has gone from being written in plain JS, to Dart, to Atscript, and now Typescript? Why so much jumping around? Isn't that creating a lot of technical debt issues?
It's a bit confusing, but basically right now there are two Angular products: AngularJS 1.x and AngularDart. These two efforts are supported by completely separate teams. Now the JS and Dart teams are merging and the new Angular 2.0 will be written in TypeScript and transcompiled down to ES6, ES5, and Dart. So while it may look like jumping around, the message seems to be consolidation.
They made an Angular.js rewrite in Dart that has nothing to do with Angular 2.0.
Angular 2.0 was written in ATScript which was basically Typescript with annotations. Now Typescript added annotations so there's no point in mantaining ATScript anymore.
If you're talking about TypeScript, I don't believe that mantra is applicable when the extensions are open source, liberally licensed (Apache License), cross-browser, and developed in the open. There's nothing proprietary or exclusive about it.
Hard to say. It didn't seem like Microsoft had a good strategy for modern web development (javascript/rest/etc.) at least from the client side. They had webforms/MVC but you pretty much had to use client side controls from other sources, like Telerik, if you wanted to do something modern. One assumes that tooling with javascript would be difficult for them to add in Visual Studio, say as compared to the tooling offered for C#. So moving to a typed language allows them to have nice Visual Studio tooling as well as picking a path for modern web development.
To extinguish, you introduce incompatibilities to make the life of people outside your inner ecosystem (compared to the greater, standard-compliant ecosystem) harder. But since TypeScript compiles to JavaScript and interfaces with plain JavaScript wells, there is really no "extinguish" part here.
Also, the EEE accusation doesn't really apply to open source projects. EEE is bad since after the proprietary product supersedes ("extinguishes") an open product, the community loses control forever. However when an open product supersedes another, the community always have the choice of forking the project to take back control.
Prob not from Google/Angular themselves. Maybe someone will be willing to maintain a 1.x branch for support $ ala what some people did for Rails 2.9.2+
FYI the new router module (https://github.com/angular/router) is going to be a separate project, with semver'ed releases. It'll expose bindings for both Angular 1.x and Angular 2, but it isn't bound to the Angular release cycle.
The official word[1] from the Angular team now is that they will support it as long as there is still a significant number of companies using it - it will be longer than the original 1.5 years after the release of 2.0 mentioned.
[1] Mentioned in the ng-conf keynote IIRC, but this was also told to me directly by one of the Angular core team members when I spoke with him today.
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 going on.
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)
Oh, I have no problems with strong typing. In fact I think it's a good thing to add to angular. Angular, (And I say this as once upon a time contributor to Protractor) however, is kind of a step in the wrong direction, and I concluded this before they started flapping about with all these giant course corrections.
To be fair, JavaScript started out as a language that looks like Java.
"JavaScript was designed with Java's syntax and standard library in mind. In particular, all Java keywords were reserved in original JavaScript, JavaScript's standard library follows Java's naming conventions, and JavaScript's Math and Date objects are based on classes from Java 1.0" -- http://en.wikipedia.org/wiki/JavaScript#JavaScript_and_Java
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 standard library in mind. In particular, all Java keywords were reserved in original JavaScript, JavaScript's standard library follows Java's naming conventions, and JavaScript's Math and Date objects are based on classes from Java 1.0,[116] but the similarities end there.
The differences between the two languages are more prominent than their similarities. Java has static typing, while JavaScript's typing is dynamic. Java is loaded from compiled bytecode, while JavaScript is loaded as human-readable source code. Java's objects are class-based, while JavaScript's are prototype-based. Finally, Java did not support functional programming until Java 8, while JavaScript does, as it contains many features based on Scheme."
Aye, I did cherry pick a bit, sorry about that. But still, if you go to Brendan Eich's wiki page [0], it says that he wanted to put Scheme in the browser, but was commissioned to create a language that resembled Java instead. I guess he ended up doing a little bit of both :)
> Whole web is a mess and people are trying to monkey-patch it.
That has been true for the last 20+ years, but it gets less and less accurate as time goes on. The web today is way less messy than it was even 3 years ago. The way we write JS is way less messy, the way we write CSS is way less messy. Standards have improved, lighten up.
I don't personally find TypeScript a rejection of JavaScript in the way that some other transpiled languages are. It feels to me like optional typing plus a bunch of features JavaScript will get in ES6 or beyond.
My main feeling about this is not so much about typeScript (which, meh, some syntax sugar I don't care about, and tooltips for an IDE I don't use) -- more it's that just the mere whiff of Microsoft's involvement will be enough to snuff out remaining developer interest in Angular 2.
I remember being a MS hater as a kid. Now I hate all the big software companies. Just some more than others. And MS is heading in the right direction these days, so I'm optimistic. Hopefully it'll stick.
> The second-system effect is the tendency of small, elegant, and successful systems to have elephantine, feature-laden monstrosities as their successors due to inflated expectations.[1]
Angular 2.0 is removing a lot of complexity and "magic" of 1.x. I've moved onto React but I think it's a bit too soon to say Angular 2.0 will be a bloated monstrosity relative to 1.x.
I definitely concur. Having just attended emberconf, there's a stark contrast in how each framework is choosing to evolve with the web. Personally, I favor ember's approach of smaller, more iterative releases that are largely backwards compatible with previous versions. It not only means that teams building ember apps now can continue their efforts with confidence, but it's also a testament to the amount of thought and care the core team has placed in developing ember's abstractions; no major rewrite needed (so far). And ember's version 2.0 due out next quarter will be no different; same release cycle, same emphasis on compatibility with the added benefit of removing cruft that has built up in the codebase.
Perhaps I'm speaking from the perspective of our products at Yahoo, but ember has suited us well for precisely these tenets.
Thanks, Sam. Like all things in technology, there are tradeoffs to make and a cost-benefit analysis that every project will do differently. We spend a lot of time on backwards compatibility in Ember, but my goodness, it's painful.
Recently, the results of the Ember Community Survey were released and the aspect of it I'm most proud of is the number of developers who are using the latest release version[1]. The majority of respondents were on either 1.9 or 1.10, and 1.10 wasn't released until halfway through the survey.
I have specifically avoided angular because I feel like it's a monster in that you are so tied to learning and understanding it's proprietary system. I too have moved directly to react. Can anyone comment on how the skills learned by learning Angular can be applied any where else?
You're 100% right. Once you're in Angular-land you are completely tied to the framework. You don't think about "how can I make X in my domain happen?" you think about "how do I make X in Angular happen". This coupled with the horrific Angular docs make it really tough to justify using from a productivity standpoint.
I've moved to React as well and feel it's a 10x boost in productivity because I'm constantly thinking in my domain and not in a framework.
I am a newer developer, and this is how I feel. I didn't think it was normal. I always had problems grokking the docs as they are obtuse and thin. Also, things I find straight forward to implement in JS seem laborious in NG.
I am going to start learning react as well, and if you have any suggestions on how to get started, I would be appreciative of a few resources.
It's not like anything you build in React is going to transfer over to another framework either. In fact, I've been to a lot of React talks and people mostly ask "how do I do X" in react. The last talk I went to they spent 10 mins talking about how you might make a spinner when data is loading.
React is a rendering engine, it's covers the final piece of your web app (rendering a data structure into DOM). But whatever you do to create the data structure that gets passed to React is up to you. This keeps most of your domain logic outside the context of React, you just use React to render data->DOM. So basically the API you have to learn is just Javascript, which most people know already and is easy to lookup answers to your questions.
With Angular your domain logic exists in the context of the framework. i.e. if you ng-repeat something you can't just filter that collection with Javascript you have to use an ng-filter to do it which is a special Angular construct. So the API you have to learn to manipulate data isn't just Javascript it's Angular. And how does ng-filter work? Well, you're tied to the Angular docs to figure it out. The Angular docs are of particualary poor quality so this coupling turns into a really serious problem if you're trying to be productive.
To me React vs. Angular isn't a matter of preference like Ruby vs. Python -- it's more like git vs. FTP where there is a clear right answer if you're trying to be productive in a team envrionment.
Sigh... this is such an annoying comparison. If you want to compare, compare React to Angular Directives since that's a valid argument.
Your entire complaint is that full-stack front-end frameworks are bad and modular systems are good. It's great that you prefer modularity and the ability to mix and match tools.
But stop pretending React vs Angular is a thing. It isn't. git vs FTP... just stop.
This will not be the case at all with Angular2. Most of the "angular" stuff will be in annotations and your code is going to be vanilla ES6 for the most part (well, with TypeScript). So, you actually are going to have a lot more freedom to mix and max other technologies.
Also, FYI, the barrier in 1.x is not that high, either. There are many integrations between Angular and other frameworks (including React, FYI).
>>> I have specifically avoided angular because I feel like it's a monster in that you are so tied to learning and understanding it's proprietary system.
I actually had to exact opposite feeling about Angular. I loved that it was a complete framework and I didn't have to mix and match several libraries to get the functionality I needed.
Having said that, I've completely soured on Angular. From the big changes coming in 2.0, to not making this backwards compatible hasn't left me with any confidence they won't do this again in future releases.
I've already moved to Ember and haven't had any issues yet.
Yes, some parts are just basic structuring. Breaking an application into services, knowing what parts are singletons and not and finding ways to communicate between parts. If AtScript/TypeScript is used more you can use those skills in any project using the same language. Other parts are specific to Angular.
I think this is more of an impression because Angular 2.0 is embracing many other things that have nothing to do with Angular, like ES6, web components, typescript.
I notice that with people trying to learn TypeScript, and see that their struggle is with classes, lambdas and modules, not with the type system that is basically the only thing TS adds to ES6.
In the end, if you look at it there is not really much to understand and all the other things you will learn anyway with Ember, React, etc. I believe most of this fear will disappear once its released.
Yay! I have tested TypeScript in hobby projects with a very positive experience. I have actually used typescript together with angular once. I was very disappointed when angular announced that they were going to make some kind of fork, for the runtime annotations they needed, instead of working together.
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.
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 been kicking ass for a while now and making many improvements that are compelling to developers. It's a modern framework, but also easier to understand than some competitors like react.
I see the Typescript move as a positive because it shows they are at least trying to do what's right even when using tech from one of the biggest competitors. How this played internally at Google to overcome executive knee-jerk/bureaucracy/pettiness I don't know, but it's a good sign.
The community has clearly spoken, and the future of Angular is now riding on how well they absorb and react to the feedback and advances from competing teams.
The best part of this announcement is the reminder that Typescript is worth adopting. Sorry "Angular 2" your just not welcome in my leading edge reality.
The typescript move is more along the lines of "we had these extensions to typescript we were calling AtScript, but now they're included in the forthcoming release of TypeScript, so we'll just call it Typescript". It doesn't seem to actually change any on-the-ground syntax, just what you call the language.
another, more important piece (IMO) of response to the pushback they've been getting came during the new router demo at ng-conf today. Apparently, you'll be able to mix-and-match ng2 and ng1 routes within the same router, so the commitment was: if you use the new router, there's a clear incremental upgrade path as you port parts of your app to ng2.
I'm still in wait-and-see mode, but there's apparently also talk (from the same router talk) of tools to convert ui-router built routers to the new router, which would be double-rad.
Being part of an existing project that's backed by both MS and Google is a significant value proposition though. I wouldn't have learned AtScript, although I'll probably end up learning Typescript now even though they're the exact same thing.
About breaking backward compatibility - they mentioned at ng-conf an interesting thing today: you'll be able to partially migrate from Angular 1.x to Angular 2 in both ways - having either Angular 1.x app with some Angular 2 components, or Angular 2 app with some Angular 1.x components.
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 the view, and if the user changed it, I could react accordingly. Data changing became an actual event that I could subscribe to. It abstracted away the onkeydown, onkeyup, onclick, etc. so that it just became ng-change. So much less mental noise when I'm developing when all I have to do is react to data having changed.
I hope this gets picked up. ES6 and TypeScript have so much to offer, but without a data-centric paradigm, I find I'm just not interested anymore.
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.
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.
> The main mistake, in my opinion, that Angular 2.0 is making is removing two-way data binding
They talked about it in the ng-conf available on youtube. They are not removing 2-way databinding from Angular, they are just changing the way it works.
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.
To be honest I feel like learning JSX is the Achilles heel to using ReactJS. Now Angular is forcing you to learn TypeScript? What's next, Polymer will make you learn Coffeescript?
I like React except for JSX, since React seems to be headed in the all JSX direction I jumped ship to Polymer.
I hate the idea of having to learn a proprietary language that boils down to straight JavaScript. I hate the extra compile, I hate the lack of dubugging support. Most of all, I hate the fragmented documentation when a project has straight JavaScript examples and other examples using some abstraction.
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 tokaido-dns are the big ones) that I developed separately along the way.
I guess you cannot say that yourself for fear of appearing to brag, but a project such as Tokaido is an EXTREMELY complicated task to tackle. So well done. And thanks for all the hours you're sinking into commercial and non-commercial projects alike, committees and everything.
Interestingly, I was just talking to someone yesterday about how Yehuda is very good at handing off projects. When he doesn't personally finish something he started, it's because he's handed off the work to someone else who is taking it to completion. I've never seen him abandon any project.
My brain just broke. I can't even imagine Google and Microsoft working together on anything as big as Angular. The Universe just took a 90 degree turn.
Looking at the example source code & having experience of AngularJs & TS, I would say this is a huge development in term of enterprise adoption.
Statically typed, annotations, built-in dependency injection, comprehensive test support (easy to write testable code), declarative UIs, 100s of already available libraries & above all support from Google and Microsoft. I can say this with confidence that even with a complete rewrite & not backward compatible, AngularJS 2 with TS is going to be a huge success for everyone.
And sooner or later, all other frameworks will adopt ECMA Script 6 because of standardisation of so many things (modules, classes etc.)
I would also like to add that this is a very exciting time for JavaScript developers because there are so many things happening & companies of all sizes will keep investing good amount of money moderating their JS code bases.
234 comments
[ 3.1 ms ] story [ 240 ms ] threadThey must have convinced Microsoft to accept their patches into mainline TypeScript.
It means that the Angular team is giving up on traceur or maybe traceur and typescript will merge somehow in the future.
ES6, AtScript, and the es6-shim AtScript
Angular is built with AtScript. AtScript is an extension of ES6 (ECMAScript 6), the new specification of the JavaScript language. This quickstart features AtScript, but you can write Angular in ES5 or ES6 as well. ES6
AtScript compiles to ES6, which is not widely supported in all browsers today. The es6-shim.js file allows you to use ES6 or AtScript in the browser. es6-shim
The quickstart repository includes es6-shim.js. The es6-shim.js file includes dependencies (such as Traceur) needed to compile ES6 in the browser. Traceur is an ES6 compiler that transpiles ES6 to ES5 code.
With static typing, the compiler can catch type errors early, at the cost of rejecting some otherwise valid programs.
With dynamic typing, that type checking is delayed until execution time. More programs are valid, but type errors are caught late.
With AtScript-style late type checking, they took the dynamic type system and introduced more type errors. This decreases the amount of valid programs, yet catches no errors at compile time. It does nothing but increase the amount of bugs.
http://www.cs.umd.edu/~aseem/safets.pdf
It describes an extension to TypeScript that includes efficient runtime type checking. They encode type information only in situations where checks are necessary, and only information that cannot be otherwise deduced from the context.
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.
var length = rtts.type(name.length, rtts.int);
https://docs.google.com/document/d/11YUzC-1d0V1-Q3V0fQ7KSit9...
Very much looking forward to seeing what insights come out of rebuilding something like angular with types.
edit actually on second reading, I'm not sure what's been rewritten in what?
http://stackoverflow.com/questions/8815437/why-is-javascript...
> And the size of helloworld.dart.app.js is 102k
> When ran in optimize mode, it generated the following javascript - helloworld.dart.js which is of size 20k
No, it's not.
Results in a 5 KB JS file.This game is 35 KB (procedural graphics included):
http://mbtic.com/games/fuzetsu
Anything I'm missing?
https://gist.github.com/ratbeard/70902d6347ad448de0a4
Also note that you could now add a thousand lines of code and the file size wouldn't increase much. You already paid that one-time cost.
You can further improve the size by using a better minifier on top of --minify.
Though as a counterpoint (and relevant to angular 2 :) I read they're going to just use the raw dom api's instead of a jquery/jquery-lite abstraction layer as the dom api's don't need the smoothing over in modern browsers like they used to.
The main problem I had with Dart was [a year ago] that using existing JS libraries like jQuery wasn't as seemless as I would liked. So that would be a reason against Dart, if Angular wants to make that aspect easier.
Haven't looked at TypeScript's interop with JS. I got frightened by the name Microsoft and the fact that they only had a huge language spec PDF and not a single tutorial or something easier to digest.
In production, it's only ever transpiled to JavaScript.
> Chrome (dunno if enabled by default and/or in stable) contains a Dart VM, so you "only" need to transpile into JS for non-Chrome.
Not the real Chrome. A version of Chromium that you can use to make the development cycle smoother. When you deploy, you still transpile to JavaScript for all browsers.
All JavaScript is valid TypeScript. This was one of the founding tenants for TypeScript. So interop is "just use the JS".
You can optionally also provide a binding file that tells TypeScript about the JS code so that it can perform compile-time checking on calls. There is a repository of these bindings for common libraries called DefinitivelyTyped [0].
> ... They only had a huge language spec PDF and not a single tutorial or something easier to digest.
Not sure when you originally looked, but there is now a tutorial [1], handbook [2], and samples [3] in addition to the language spec [4].
[0] https://github.com/borisyankov/DefinitelyTyped
[1] http://www.typescriptlang.org/Tutorial
[2] http://www.typescriptlang.org/Handbook
[3] http://www.typescriptlang.org/Samples
[4] http://www.typescriptlang.org/Content/TypeScript%20Language%...
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.
You can interact with JS libraries, but exposing some API to JS-land is a completely different matter.
There are some vague plans to improve this, but there hasn't been much interest, because if you use Dart anyways, you do of course want to use it as the "host" language. It has the tooling and all that jazz. Of course you'd want to use it for as much as you can.
https://pub.dartlang.org/packages/angular2
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.
Just curious, what and why are all your reasons to move away from Angular?
- Obtuse, verbose, non-performant code
- Did I mention breaking changes?
IMHO, Angular isn't progress, and neither is painting yourself into a corner.
Opinions maybe useless, but some opinions are more useless than others.
[1]: http://flowtype.org/
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.
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.
- 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™.
what are the performance issues with TS?
I would strongly disagree. Watch this link to when Igor talks about Angular performance.
https://www.youtube.com/watch?v=QHulaj5ZxbI&t=35m30s
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.
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.
The same way that Google's shuttering of services over and over earns them a bit of discomfort amongst their users.
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.
Seriously, stop the FUD
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.
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.
Everyone seems to hate on JavaScript but it's really not that bad to use.
Not all transpilers may be to your taste, but they have their place.
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.
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.
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.
I have an affinity for Babel unlike any other JS project (except React). They team works really hard to keep it interesting.
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.
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.
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.
For a certain style of Javascript, making it Typescript is a no-op
http://crystae.net/2015/01/22/typescript-is-not-a-superset-o...
Try running jQuery's source through the TypeScript compiler some time.
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.
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).
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).
Also, the EEE accusation doesn't really apply to open source projects. EEE is bad since after the proprietary product supersedes ("extinguishes") an open product, the community loses control forever. However when an open product supersedes another, the community always have the choice of forking the project to take back control.
Angular 1.4 is well underway and there's a lot of good stuff coming out of it, for example the reworked router module.
Here's a presentation from ng-conf today about the new router: https://www.youtube.com/watch?v=vecg70fPDFw
[1] Mentioned in the ng-conf keynote IIRC, but this was also told to me directly by one of the Angular core team members when I spoke with him today.
Edit: Why did this question get down voted? It was an honest question...
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 going on.
NOW LET'S SEE SOME FREAKING DOWN VOTING!!!
https://news.ycombinator.com/newsguidelines.html
That feeling you get when you see code with lots of type checking... A lot of engineering effort could be recovered with static typing.
"JavaScript was designed with Java's syntax and standard library in mind. In particular, all Java keywords were reserved in original JavaScript, JavaScript's standard library follows Java's naming conventions, and JavaScript's Math and Date objects are based on classes from Java 1.0" -- http://en.wikipedia.org/wiki/JavaScript#JavaScript_and_Java
"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 standard library in mind. In particular, all Java keywords were reserved in original JavaScript, JavaScript's standard library follows Java's naming conventions, and JavaScript's Math and Date objects are based on classes from Java 1.0,[116] but the similarities end there.
The differences between the two languages are more prominent than their similarities. Java has static typing, while JavaScript's typing is dynamic. Java is loaded from compiled bytecode, while JavaScript is loaded as human-readable source code. Java's objects are class-based, while JavaScript's are prototype-based. Finally, Java did not support functional programming until Java 8, while JavaScript does, as it contains many features based on Scheme."
And read this part too, it has much relevant info: http://en.wikipedia.org/wiki/JavaScript#Beginnings_at_Netsca...
[0] http://en.wikipedia.org/wiki/Brendan_Eich#Netscape_and_JavaS...
He said it looks like Java, I believe. Not "it's similar to Java".
http://wtfjs.com
Whole web is a mess and people are trying to monkey-patch it.
For example, I don't think it's particularly bad that array[-1] and array.charAt(-1) return different values.
Also, I don't get the Math.Max() example with booleans. Seems perfectly logical to me.
That has been true for the last 20+ years, but it gets less and less accurate as time goes on. The web today is way less messy than it was even 3 years ago. The way we write JS is way less messy, the way we write CSS is way less messy. Standards have improved, lighten up.
That said, static typing does help with intellisense/code completion, on-the-fly error checking, refactoring, etc...
I remember being a MS hater as a kid. Now I hate all the big software companies. Just some more than others. And MS is heading in the right direction these days, so I'm optimistic. Hopefully it'll stick.
http://en.wikipedia.org/wiki/Second-system_effect
Angular 2.0 is removing a lot of complexity and "magic" of 1.x. I've moved onto React but I think it's a bit too soon to say Angular 2.0 will be a bloated monstrosity relative to 1.x.
Perhaps I'm speaking from the perspective of our products at Yahoo, but ember has suited us well for precisely these tenets.
--Sam
Recently, the results of the Ember Community Survey were released and the aspect of it I'm most proud of is the number of developers who are using the latest release version[1]. The majority of respondents were on either 1.9 or 1.10, and 1.10 wasn't released until halfway through the survey.
1: http://www.201-created.com/ember-community-survey-2015#relea...
I've moved to React as well and feel it's a 10x boost in productivity because I'm constantly thinking in my domain and not in a framework.
I am going to start learning react as well, and if you have any suggestions on how to get started, I would be appreciative of a few resources.
I think that's the nature of any framework.
React is a rendering engine, it's covers the final piece of your web app (rendering a data structure into DOM). But whatever you do to create the data structure that gets passed to React is up to you. This keeps most of your domain logic outside the context of React, you just use React to render data->DOM. So basically the API you have to learn is just Javascript, which most people know already and is easy to lookup answers to your questions.
With Angular your domain logic exists in the context of the framework. i.e. if you ng-repeat something you can't just filter that collection with Javascript you have to use an ng-filter to do it which is a special Angular construct. So the API you have to learn to manipulate data isn't just Javascript it's Angular. And how does ng-filter work? Well, you're tied to the Angular docs to figure it out. The Angular docs are of particualary poor quality so this coupling turns into a really serious problem if you're trying to be productive.
To me React vs. Angular isn't a matter of preference like Ruby vs. Python -- it's more like git vs. FTP where there is a clear right answer if you're trying to be productive in a team envrionment.
Your entire complaint is that full-stack front-end frameworks are bad and modular systems are good. It's great that you prefer modularity and the ability to mix and match tools.
But stop pretending React vs Angular is a thing. It isn't. git vs FTP... just stop.
Also, FYI, the barrier in 1.x is not that high, either. There are many integrations between Angular and other frameworks (including React, FYI).
IME, it's a shit show, and totally inappropriate for production code. It's the mating of wrong sized dogs in the park.
I actually had to exact opposite feeling about Angular. I loved that it was a complete framework and I didn't have to mix and match several libraries to get the functionality I needed.
Having said that, I've completely soured on Angular. From the big changes coming in 2.0, to not making this backwards compatible hasn't left me with any confidence they won't do this again in future releases.
I've already moved to Ember and haven't had any issues yet.
I notice that with people trying to learn TypeScript, and see that their struggle is with classes, lambdas and modules, not with the type system that is basically the only thing TS adds to ES6.
In the end, if you look at it there is not really much to understand and all the other things you will learn anyway with Ember, React, etc. I believe most of this fear will disappear once its released.
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.
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
https://github.com/facebook/flow/blob/master/lib/dom.js#L359
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 been kicking ass for a while now and making many improvements that are compelling to developers. It's a modern framework, but also easier to understand than some competitors like react.
I see the Typescript move as a positive because it shows they are at least trying to do what's right even when using tech from one of the biggest competitors. How this played internally at Google to overcome executive knee-jerk/bureaucracy/pettiness I don't know, but it's a good sign.
The community has clearly spoken, and the future of Angular is now riding on how well they absorb and react to the feedback and advances from competing teams.
pun intended?
another, more important piece (IMO) of response to the pushback they've been getting came during the new router demo at ng-conf today. Apparently, you'll be able to mix-and-match ng2 and ng1 routes within the same router, so the commitment was: if you use the new router, there's a clear incremental upgrade path as you port parts of your app to ng2.
I'm still in wait-and-see mode, but there's apparently also talk (from the same router talk) of tools to convert ui-router built routers to the new router, which would be double-rad.
https://www.youtube.com/watch?v=vecg70fPDFw (the router talk in question)
Being part of an existing project that's backed by both MS and Google is a significant value proposition though. I wouldn't have learned AtScript, although I'll probably end up learning Typescript now even though they're the exact same thing.
https://www.youtube.com/watch?list=PLOETEcp3DkCoNnlhE-7fovYv...
I could just bind the data to the view, and if the user changed it, I could react accordingly. Data changing became an actual event that I could subscribe to. It abstracted away the onkeydown, onkeyup, onclick, etc. so that it just became ng-change. So much less mental noise when I'm developing when all I have to do is react to data having changed.
I hope this gets picked up. ES6 and TypeScript have so much to offer, but without a data-centric paradigm, I find I'm just not interested anymore.
They talked about it in the ng-conf available on youtube. They are not removing 2-way databinding from Angular, they are just changing the way it works.
I like React except for JSX, since React seems to be headed in the all JSX direction I jumped ship to Polymer.
I hate the idea of having to learn a proprietary language that boils down to straight JavaScript. I hate the extra compile, I hate the lack of dubugging support. Most of all, I hate the fragmented documentation when a project has straight JavaScript examples and other examples using some abstraction.
Why is the web world doing this?
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?
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 tokaido-dns are the big ones) that I developed separately along the way.
https://news.ycombinator.com/item?id=35079
All JS lib compile out of the box in TypeScript.
(oh! You meant as, in, externally, not internally. I see...)
Statically typed, annotations, built-in dependency injection, comprehensive test support (easy to write testable code), declarative UIs, 100s of already available libraries & above all support from Google and Microsoft. I can say this with confidence that even with a complete rewrite & not backward compatible, AngularJS 2 with TS is going to be a huge success for everyone.
And sooner or later, all other frameworks will adopt ECMA Script 6 because of standardisation of so many things (modules, classes etc.)
I would also like to add that this is a very exciting time for JavaScript developers because there are so many things happening & companies of all sizes will keep investing good amount of money moderating their JS code bases.