It could easily keep up with Lua if Mike Pall agreed with the changes made to Lua, but he didn't.
The Lua ecosystem is very different than almost any other; It's primary use case, probably 95% of projects using it or more, is being embedded into another project for scripting/configuration/control. As such, it is common for projects to pick a version of Lua and stick with it, rather than upgrade to the latest-and-greatest-with-slight-to-major-incompatibilities. Pall liked 5.2, and thought 5.3 didn't offer enough to break compatibility.
- When typescript came out, I was an early adopter, and a lot of it's touted benefits were the class-like syntax and constructors to make it more palatable to enterprise shops (not for me, but it was easier to sell to higher ups), this is mostly a moot point now.
- flow can be attached to any codebase as the codebase stands easily. It is, I have found, difficult to bring TS into an existing project.
- flow fits nicely into existing popular js tooling, mainly babel and react.
- no risk of vendor lock in. Maybe TS compiles to pure 100% syntactically correct javascript today, maybe it doesn't in the future. It isn't javascript, so I won't know.
At the risk of probably repeating myself, allow me to give my $0.02:
> - You are writing javascript, not typescript.
Flow's and TypeScript's distance to JS world are the same, and are very similar in most cases. If you want to add type to one, it's the same as in the other. The only difference here is the file extension, since TS tends to like .ts/.tsx.
> - When typescript came out, I was an early adopter, and a lot of it's touted benefits were the class-like syntax and constructors to make it more palatable to enterprise shops (not for me, but it was easier to sell to higher ups), this is mostly a moot point now.
True, although IMO the greatest feature of TS is making your code stronger, not compiling things that are already part of some ECMAScript version.
>- flow can be attached to any codebase as the codebase stands easily. It is, I have found, difficult to bring TS into an existing project.
True, with TS it's more of a lateral move rather than drops here and there.
>- flow fits nicely into existing popular js tooling, mainly babel and react.
TS works just as well; better, IMO, because dev tools (editors, linters) have better TS support in my experience. Writing React in JS to me makes me feel like I'm using Notepad since there's so much TS helps me with that is lost when using a purely dynamic language.
>- no risk of vendor lock in. Maybe TS compiles to pure 100% syntactically correct javascript today, maybe it doesn't in the future. It isn't javascript, so I won't know.
It does compile to pure JS so ejecting TS is easy; it's trying to follow future standards and proposed changes, not create something different; the project is open source. There is no vendor lock in.
There's a few subtle things here. Flow does support annotating types with comments, and can type check React's flowtypes, so you actually can get a fair bit without a compiler at all. In practice, no one does that, so you're still right, but it's worth nothing.
And it's worth noting that TypeScript having its own parser vs the rest of the world using Babel is a pain in the rear. See the time it took for ESLint (having to us TSLint in the meantime), now Prettier, having to use TypeScript with an ES6 target and piping the output in Babel to get proper plugin support, the difference between webpack's resolution mechanism and the one used by TypeScript in tools (an issue Flow also shares), and so on.
Some features like enums (omg, TS enums die die die) namespaces, decorators, and the old module system are also pretty awkward when blending with modern javascript. Makes you want to add lint rules to prevent them from being used.
One reason flow might be considered "better" (context is key) is that it plays well with the babel ecosystem, letting one pick and choose their language features.
Picking and choosing language features via babel plugins (many of which will never become part of JavaScript) is an anti-feature. You essentially are creating your own language that only you understand.
The parser features are fixed. The plugins enable/disable them, but they're already "there", just toggled. As far as I know at this point the parser is not pluggable. Babel is a playground for the official TC39 proposals so it might get stuff a little early, but that's about it.
Where the plugins shine is when compiling those (part of the standard) features to something interesting for production. Better inlining, adding debugging and instrumentation, compiling away certain things, optimizing your views for performance, etc.
All things that don't change the language whatsoever, but can improve your debugging or production experience.
That can be done in TS world (and is quite common) by targeting ES6 and piping the result in Babel though. It's just annoying.
You do have things like Prettier not being compatible with TS because different parsers, though.
We don't support custom syntax that isn't already a proposal (meaning it has potential to be in JS), and we also encourage using presets like https://github.com/babel/babel-preset-env instead of providing your own configuration of plugins unless you are more of a power user.
It's our intention as a tool to align with TC39 and transition users to using native JS when it's supported
Yeah, I personally don't mess around with Babel but I imagine you could just take TypeScript's ES6 output and feed it through babel in your gulp/webpack pipeline.
Some people were doing that before TS got async/await compilation directly to ES5 (in TS 2.1). Right now, having Babel in the TS pipeline is not that useful anymore.
I've had some major headaches getting TypeScript to work with Babel and Webpack 2. The main reason I had to use Babel was because I wanted to use Webpack 2's tree shaking feature. Do you know if it's possible to use just TypeScript and Webpack without Babel, and still take advantage of tree shaking?
Honestly this is the main thing keeping me from using TypeScript. I've spent hours, maybe days trying to deal with the mess of Babel/webpack/TS combined with ES6 modules (necessary for tree shaking).
Another problem I ran into was using various packages that weren't typed, but I suppose I can solve that by 'allowing' implicitAny.
I'd really love some advice on this because I want to use TypeScript. It's just been a major headache so far because things are complicated enough with all the other moving parts (Babel presets, import vs require, better but still not well documented Webpack 2, etc.).
Yeah, that's what I use with Webpack. It's just one more rule on Webpack config, so no reason not to do it. There's many things that are out of scope of TS that are better handled by Babel (like embedding corejs methods based on target browser versions).
If you're using Webpack is it possible to gradually opt files into TS type checking _without_ having to rename them, since you can specify which filename patterns loaders apply to?
It might be worth checking ts-loader or awesome-typescript-loader. I'm not sure how it detects js vs ts in those pipelines. TypeScript can also "compile" JS to check for syntax and other errors, so it may still be extension based. An interesting scenario though.
I believe you might be able to with --allowJs, but to be quite honest I haven't done so. All my projects were TypeScript-based from the start, even if sometimes I end up using JS dependencies.
Avoid vendor locking. Someday in near future if you don't like flow anymore, you can just strip all type annotations with Babel and move on. You are not risking ending up like coffeescript.
TypeScript compiles to JS in a straightforward manner as well. If you wanted to move away from TS, you could simply have the TS compiler compile to ES6 and you're done.
But that'd still be transpiled code, right? After getting rid of flow it will be exactly same minus the type annotations. Same cannot be said about typescript considering various language features and syntactic sugar TS offers. Will it run? Yes. Will it feel that it was written by me? That depends.
> Same cannot be said about typescript considering various language features and syntactic sugar TS offers
I think you're vastly misinterpreting what TS is.
It's not anything like CoffeeScript. It's JS plus types and a few other features like Interfaces or advanced ECMAScript features when targetting older versions of the standard.
If you strip away types by exporting to your ECMAScript target of choice, you'll get real JavaScript with the same style as it was written in TypeScript.
It's exactly the same thing you'd get with Flow in that sense. The only additional code you'd get would be for polyfills, but a) those are minimal and b) those will only appear if you export to an older ECMAScript version than the one you wrote it in.
there are a few minor things like enums and decorators that will need to be compiled because they're not standard and are not just types either (well, const enums are i think?, but the rest are not?).
Your equivalence with transpiling coffeescript is false. TS doesn't really have "syntactic sugars". Just about everything in it(less the types of course) is pretty far along in the ES adoption process. There are a couple exceptions like decorators that are called out in a very visible manner.
If you target ES6 your code may look identical. Even much of the ES5 down leveling produced code that looks like a person wrote it.
I converted a 10k line coffeescript project(with async/await !) to JS and then TypeScript. The similarities are so far apart they might as well be in different dimensions. But, if you don't want to take a rando posters word for it, it's pretty easy to make a little sample project and see if the output is to your liking.
That's an objectively incorrect assertion if you're applying that to TypeScript.
The same can be done to it that would be done to Flow: you can just either strip types manually, or just do a single export to your ECMAScripttarget of choice. It'll be native JavaScript. Even the little shims/polyfills it does (to support older ECMAScript versions if you wish to export to it) are optional and can be disabled.
TypeScript has `--target ESNext` this will strip out any TypeScript-specific type annotations, and leave you with standard-track-only JS code that looks identical to your input (modulo type annotations).
FYI we do have an issue open about TS https://github.com/babel/babylon/issues/320 so that we could eventually support TS in Babel as a plugin and then create the same strip-types-plugin just like Flow.
TypeScript type inference is minimal though and doesn't go very far. It falls back to "any" very quickly (and if you use the noImplicitAny option, then you have to type almost everything).
It does a decent enough job at return types, but not a whole lot beyond that.
I don't think you're familiar with what TypeScript is trying to achieve. It's not supposed to be another language entirely, but a standards-compatible type-safe version.
And that means they aren't good, not that the person using good practices isn't good.
If it is a business requirement that good developers must be slowed down for bad ones to catch up, then do it by encapsulation and mentoring. Not by decreeing that good developers must act exactly like bad ones.
Absolutely this. While it might be tedious to put those pieces together at first the knowledge that you gain is very transferable to the other app that you build instead of being one-trick pony in angular.
1. Typescript. If your team isn't familiar with it it's not trivial to get everyone on board. The up-front cost can absolutely be worth it in the long run, but there's some friction in the day-to-day work with managing type definition files and looking up esoteric lint-errors from the Typescript compiler.
2. RXJS. Canonical NG2 should use Observables, and rxjs is not a trivial library to learn the ins and outs of. Add to that that there's no clean way of doing testing with Observables at the moment (integrating with the rxjs testing schedulers is very finicky). This is doubly true if you're using ngrx (which you probably should).
3. Template language. I'm one of those who don't think it's a very good idea to bring a new DSL into html. I'd much rather do it the React-way of bringing HTML into JS instead of relying on a very complex compiler to do magic behind the scenes.
This becomes a bit better with the template pre-compilation, but it's still new syntax that you need to learn and keep in mind. Some of which is not intuitive nor well documented (i.e. how pipes and parentheses work together).
4. It feels unfinished. This is to be expected since it's just on it's initial release, but the sharp edges do show up quite a lot. For example we very often have to do manual subscription and unsubscription of Observables in Components.
This feeling also goes for quite a few of the community addons, such as the browser-extension. While I absolutely applaud their efforts, it's far from reaching the quality of e.g. the Ember-Inspector.
5. Sub-par debugging experience. When you get any errors there's a mile long stack trace filled with rxjs and zone.js garble, making it very hard to actually figure out what's going on.
When there actually are custom error-messages they are not very informative, with you having to fundamentally grok how parts of NG2 works to even come close to understanding why it's not working (getting this a lot with the change detection).
6. Lack of documentation. I tried to stay very far away from Angular 1 since I found its documentation to be very low quality (probably a symptom of Angular 1 being poorly engineered as well). The NG2 docs are definitely better, but I feel like my mental model for reasoning about how things work was still very weak when I had finished going through the docs. There's some really huge gaps in there (testing) and a lot of the really complicated stuff that you will stumble over is only really documented in semi-old blog posts.
> 5. Sub-par debugging experience. When you get any errors there's a mile long stack trace filled with rxjs and zone.js garble, making it very hard to actually figure out what's going on. When there actually are custom error-messages they are not very informative,
And they said your angular 1 experience wouldn't carry over.
On 3. I've found Aurelia templates to be much better in that regard. Their templates are valid HTML and compile well. I'm not a huge fan of embedding html within the JS (even with JSX) been easier to work with separate template files and keep as much JS out of them as possible. This has helped reduce harder to debug errors that crop up when the JS inside templates fails.
I concur. Aurelia feels much more like the standard HTML that I've been working with since the 90s, only more powerful. Hence we get power without unnecessary complexity.
I've worked with AngularJS and React. After spending enough time with each framework that I'm "productive" with them and don't get constantly confused by what's going on, this is now by far the most important reason to me when adopting a framework. React(and Redux) just spoil you with an awesome debugging experience, and it's just painful for me to go back to any set of tools that takes some of that away. The rest of the points I've already "suffered" through with AngularJS, and it is my opinion that they are a rough, but surmountable cost. Having a poor debugging experience, however, just kills my willingness to work.
(For the record, AngularJS has some debugging aides - you can inspect scopes pretty easily given a DOM element. However, the watches and digest cycles, which do all the heavy-lifting, are pretty much opaque - you need to have a good understanding of how your watch expressions are compiled into watch functions and place conditional breakpoints deep within the framework in order to inspect why a certain watch is not being called/being called too many times)
> I tried to stay very far away from Angular 1 since I found its documentation to be very low quality (probably a symptom of Angular 1 being poorly engineered as well).
I haven't found either of these to be the case. Is your experience recent? If so, will you expand on it? I like Angular 1(.5) quite a bit, but I'd be interested to hear more about a different perspective.
My experience with Angular documentation was similar, as well as the getting starting guide.
I remember posting an issue on stack overflow about an issue I was having on the first few pages of the guide, I realised I had misread the docs, and I answered the question myself. But that post is now my top voted question on SO, so I don't think I was alone on my experience with the Angular docs. Mind you this was 2014.
Compared with my experience with the Ember docs, the Ember docs & getting starting guide was way more readable & easier to follow. (also in 2014)
In 2014 when I started using Angular, I could not make heads or tails out of the docs and went stright to 3rd party tutorials. Today, if I know what I need and just need to remember the syntax, I will go to the official docs, but if not, I search elsewhere. I still don't think it's suited for learning.
I had the same reaction. What made it worse for me was that there was no "standard" way of doing things so different third-party tutorials would take different approaches. There was nothing I could find that suggested what the team would recommend how to approach different things.
Other libraries and frameworks have multiple ways of doing things but most times the documentation would provide an example that could be considered the way to do things.
It's very strange to me, any one of the cons from 3-6 will make me avoid a framework. Do you think the pros of the framework outweigh these serious cons?
To be brutally honest I think the only reason why this is on HN frontpage is because of its name. It's quite telling that they kept the name despite it being a totally different beast with (imho) an entirely different audience. No way they'd get this much support from the webdev community otherwise.
However I do see the potential, and one should not forget that this is just the first version, straight out of the oven.
To be fair, outside of testing I have generally found the documentation to be excellent. Also, the debugging tools seem to be pretty nice. In particular, Angular Augury looks amazing: https://augury.angular.io/
However, if you dislike the approach to templating, you will definitely dislike angular. This is one of those things that is controversial, regardless of which approach they had chosen.
Solid list. Having just used Angular 2 on a side project, I'd also add that I'm not the biggest fan of passing properties between components. @Input and @Output don't seem particular intuitive nor necessary, but maybe I'm just used to React.
I haven't tried ng-2 yet but that does seem like an improvement over ng-1 where AFAIK the best way to do this was to declare some service that directives could depend on.
I felt like I was writing really bad code passing stuff around like this. My project became ugly to look at, even though it worked. This was in February and I'm hoping that either better docs will prevent this from happening to me again or maybe that some changes they made in the 7 months since fixed all that.
You might want to reconsider using RxJS on backend, since it is significantly slower than Bluebird promises (which you should be using instead of native V8 promises at least for now) http://bluebirdjs.com/docs/benchmarks.html
Well 3 is a preference (as you've indicated), while I have nothing against transpiling I'm not a fan of having a XML DSL in my Javascript. I can't speak for angular, but I much prefer templates along with a build system that bootstraps everything.
