I use Angular 2 in production since November 19, 2015 (alpha.46). Currently I've built 3 web apps (40, 60 and 20 components each), 3 mobile apps (with Ionic 2) and my employer have plans for more apps.
Breaking changes during alpha stage were expected, so I didn't have issues with it.
Most positive things I want to highlight:
1. Components are encapsulated and truly reusable (and without dependencies hell).
2. You don't need any "bridges" anymore to use 3-rd party JS libraries inside your Angular app. Nothing need to be "angularized" - twbs, D3, all just works out of the box. Maybe it's even most important part for me.
3. Idea of `(events)` and `[attributes]` is awesome, works really effective and makes code much more easy to read.
4. Performance is great.
5. Community is friendly and have a lot of fun and patience, even to newbies.
6. TypeScript gives a lot of bonuses with zero price - you don't need to learn anything (you can just rename js to ts and it will work) and additions to JS are simple and powerful.
7. Cool abilities like AOT-compilation, server-side rendering and tree-shaking.
Congrats to the all devs who are using Angular, congrats to the Angular team! :)
Any chance you can do a quick cons review too? Specifically comparing to the weakness of Angular 1 like bloated complexities, issue with custom directives or scope life-cycle.
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.
The main con I can think of are all the extra tooling and dependencies required. However, even though angular-cli is yet another tool, it aims to solve the extra tooling problem so you don't have to know how the tools work and how to configure them. Managing third party dependencies with NPM still isn't fun and can be frusturating IMO, but it sure beats script tags.
I love experimenting with ng-1: make a static HTML mockup; add a stub controller with a sample model and modify the HTML to insert the data and edit things as needed; add some event handlers with dummy actions. (add your REST calls later...)
All of the above can be done w/out any server or compile process - just keep reloading the page when you make changes (perhaps using something like python's SimpleHTTPServer module to serve files from your development directories). Once you get things about how you like them, start on the server side. This approach won't work for a page with a complicated workflow, but you can still prototype quite a bit for an initial learning experience.
This is the reason why I've been separating recent projects into two webpack bundles.
I put all libraries into a common bundle, which I blackbox in the browser debugger. This way only frames from my own code show up in the stack by default, and the debugger won't step into library code.
This also makes stack traces very easy to visually parse, as you can pretty much ignore all the ones ending in "... (common.js)".
React actually does a fabulous job of spitting out very readable error messages. It removes so many debug cycles from development that it alone is worth switching.
Right now, some of the Angular 2 error messages are cryptic - I find it very difficult to figure out what goes wrong in tests currently with Angular 2, the only utility of some of the error messages end up being that there is an error in Angular's compilation of a component (for example).
1) Build (compilation) system is complicated enough and all of these providers/declarations are not intuitive;
2) amount of boilerplate code for unit-tests (not e2e - everything is fine there);
3) some things were removed by performance reasons - I think would be smarter just rename them with prefix "slow". Sometimes it's more important to have some functionality than don't have it, even if your app is blazing fast.
No thanks for the next 1 year, after Backbone, Angular 1.x, React-Redux, I am going to take a break from learning a new framework. React-Redux is simplistic with most of my coding being JS, I don't want to keep looking up documentation for ng-this and ng-that. If the framework really takes off in 12-18 months then I might consider investing some time in it.
I really really really wish they'd called it something like Bosium just to make searching for issues a lot easier. I keep coming across angular 1 solutions.
I wonder if Angular will develop into a sort of "Perl 5 vs 6" thing? Perhaps if many people just aren't ready, willing and able to make the jump to the next version.
Having used ng2 in production for a while, I personally dislike the model behind this, mainly because it is not actually symmetric as it appears from a first look:
- input:
```
<foo [x]="y"></foo>
```
- output:
```
<foo (x)="y = $event"></foo>
```
To me this seems unfinished and inelegant; note also that everything is inherently mutable, but change detection will work best when the bound input values are reassigned, but if they are instead mutated at some deeper level, Angular will have trouble tracking those changes, and may behave in weird ways, which are often tricky to debug.
Well it's a bit confusing / weird at first until you get used to it but the real confusing syntax is the mix of both for bidirectional binding, e.g. [(ngModel)], but after reading the docs it kinds of makes sense. Awesome job, love it so far.
I haven't used Angular yet. From it's description it seems to be geared for making single page apps. Or a app with a few pages because it's good a binding data to an interface.
Is this accurate? What is a good use case for Angular?
Taking the load off of your server, and making the user's PC/tablet do more work, as well as greatly simplifying the server code to focus on data flow, business logic and data integrity, rather than mixing in presentation and minor U/I workflow complications. Having much of what you give to the remote client be static/cacheable content, with minimal data such as JSON passed rather than ballooned out JSP/JSF (etc) templated HTML, helps bring down bandwidth requirements, as well as server processing.
Of course, now you have A LOT of event handling in a client app on top of your middleware / micro-services, but I feel it is a helpful separation of concerns.
I suppose in my case it helps that I would rather do more of the app in Javascript, and less in Java. YMMV, substantially - I'm pretty sure I have a minority view at work :-)
We are working on a rewrite of a largish app (for a small team, anyway) at work. We already have a second, alternate, client app for our back end for a pilot project that we can now easily tackle with the new architecture. There were very few changes required on the server, just an alternate login method to automate an initial connection to a third party app (which then runs our alternate U/I in a frame), rather than an interactive SSO form.
We have a "Few Pages App", rather than Single Page App. By design, we reload a small number of alternate pages after a longish task, just in case (e.g. - resource leaks, whether from our own mishandling, or some library) - not because of known issues, mind you, but just out of my own paranoia that I would rather plan to allow for minor errors rather than requiring perfection.
I have used Angular in multi-page application, using Angular as a better JQuery in Spring MVC application. This setup worked well combining the best of both frameworks.
Angular provided two-way binding, rendering templates (in loop), dialog box interactions, better AJAX, etc.
Angular based component libraries provided calendar controls, dynamic tables, etc.
Spring took care of the routing pages, handling UI requests and returning JSON response from services.
I think we should not discount this style of building a web app. I've also had success with it.
You need to think hard about whether you really need a SPA for something complex, or whether you can go back to the server completely in some instances.
Can someone elaborate on point 2 about 3rd party JS libraries? How does Angular 2 allow these libraries to work out of box? For example, masonry or Google Maps JavaScript SDK.
In Angular 1 the only way to use them without resorting into angular-XYZ libraries is to put them in a directive and use the link function to write all the logic and DOM manipulation. What's different in Angular 2?
Op probably mean, that there is no Angular/ outside world barrier ( which often required using $apply function ).
>In Angular 1 the only way to use them without resorting into angular-XYZ libraries is to put them in a directive and use the link function to write all the logic and DOM manipulation. What's different in Angular 2?
Well, there is no $scope in Angular 2, so there is no need for link function ( which was used for linking scope and DOM)
Not sure if this helps, but trying to learn Angular2 I wrote a weather app with it using RC5. It is not the cleanest and I never used Angular 1 so I can't do a comparison.
A caveat: they are using the Dart fork (now maintained by the Dart team) which is not what this announcement is about. Not sure what the biggest Typescript app is.
I asked around at ng-conf earlier this year, and nobody outside of the speakers were using Angular 2. I did some proper digging again a month or two ago and still couldn't find any examples of large NG2 projects in the wild.
Not very promising...
React on the other hand, I stumbled upon looking at the source of the Wall Street Journal the other day. It is everywhere now.
I am really surprised to know that there are people that use an alpha version in production.
I would never ever do that even if it was allowed, and obviously it is not allowed in my company.
Oh, so that's what all these "alpha man" stuff on the Internet is about: folks who are manly enough to use alpha versions in production. Makes sense now.
People who only take it up at the beta stage are obviously inferior, and hence denigrated as "beta men". And then there's the detestable wimps who go only for 'stable' versions, I suppose they must be "omega men", not even worthy of a mention in discussions.
Glad to know Real Programmers[1] still exist amongst us.
I have found Angular CLI productive, because it helps quickly generate components (each component has an html, ts, css, and spec.ts file with some boilerplate code). It is fairly quick to get up and running with angular-cli as compared to writing a webpack configuration file. However, since angular-cli is in beta, it lacks the flexibility that using webpack directly would offer. (P.S: Angular-CLI latest release would be using webpack internally)
As someone who uses Angular 1 currently but would pick React for their next project, I'd love to see a list of reasons why I should use Angular 2 over React.
If nothing else, Angular just stranded all their developers, while React has a huge head start on mindshare/plugins/tutorials/etc.
I like the opinionated approach of NG2 over the flexibility of React because it takes a lot of decisions off of me that i am not too interested in when building a new project. I am a full stack developer leaning more towards backend in recent years and i found setting up and finding out about best practices and "what to use" for React a bit tedious, also it changes so much. The last Flux framework i used was alt.js which was popular last year but is hardly used anymore.
I also really like Typescript and believe enforcing it is a good way to get general JS code quality up.
I'm just writing a first React app, and read beforehand that it was going to be difficult to choose which libraries to use, and to get them to work together, but I haven't found that to be much of an issue in practice.
create-react-app set up all the build tooling, for a router the clear recommendation is react router, and for a flux implementation the clear recommendation is Redux. It feels like there's a well defined path for beginners. Over time you'll have to figure out how everything works, as is always the case, but you can learn more as and when it's necessary.
The bumps were more whether to use ES5 or ES6 (but then I found an official position in favour of ES6), and whether or not you need to use flux (although that was really just learning how flux worked, which wasn't wasted time).
The only uncertainty I have now is whether TypeScript will be necessary/useful in future, and if so how to integrate it.
The sanctioned way forward for React is Flow. It's not as comprehensive as TypeScript, but there's no compilation required - Flow annotations just get stripped out. As of a couple of weeks ago it is part of create-react-app.
Too bad flow doesn't work as well as typescript in practice. It has way more bugs, is not as tested.
It was very promising at first but typescript now has caught up with Flow best design decision: noImplicitAny, strictNullChecks.
Also, check on the "try typescript" website: typescript's JS output is almost left untouched. it's effectively a replacement for babel, if you only care for ES2015 stuff, and not some of the more recent stage 0 / stage 1 stuff.
this. tried flow, but it's too 'smart' for my iMac to handle. Flow reads all JS files without problems - which killed my iMac after using 6>gb ram. a partial solution was to manually set ignore on some node_modules packages. but still, really slow experience with atom/subl/etc.
Compared to this, typescript is actually dumb enough to require ts definition files to actually parse non-ts (js) files.
People seem to have forgotten that MicroSoft was a gigantic threat to our industry, and still is. It owns 98% PCs world wide. What would we think if 98% of gaz stations worldwide where belonging to one company? That would be dangerous, right? Same with MS except it's worse, because PCs are eveyrwhere controlling everything. It's Big Brother in real life. Just imagine one moment how many critical decisions having world wide impact on the life of billions of people are done using Excel? What if Excel was remote controlled?
So, no, sorry, I don't eat that stuff. Bill Gates has built the most dangerous edifice and no amount of charity will save him from the Hell of digital beings.
I replaced react-router with route-recognizer. The later is a simple tool your code is using, has proper documentation and stability, and do not get in the way of automated tests with jest. But react-router changed too much (i.e. removed named routes), has a lot of dependencies (browserhistory, etc), has very poor documentation, and did not allow me to do automated testing at the levels I wanted to. Moreover, it is a "framework": you're code lives inside of it, breathes through it, and that's something I dislike greatly (for such a moderate usefulness).
Agreed, react-router developers try too much to change and add new features to their baby. it has become a bit of a monster.
46KB for a minified router framework...
You're right. But I've avoided bringing transpiling or polyfill stuff into our big project at work. I'm the only dev at work who really like JS at all, anyway, so I'm trying to keep it simple for the Java-only crowd.
CRA isn't opinionated aside from the config and testing (Jest). It has no router, no Redux, etc.
It was made for demos, proof of concepts, and beginners (at the beginning, maybe not anymore). I don't know how Angular CLI works, but if it works like Ember's, then there's no comparison. Ember CLI generates models, controllers, etc. any kind of thing and it enforces a file and directory structure that makes all Ember apps look the same.
Don't have a dog in the fight-- I'm using both React and Angular2 in production. I just wanted to add that create-react-app (which was built by a few guys over a weekend or something like that?) I found to be IMMENSELY more useful than angular-cli.
I know a lot of work has been put in to angular-cli and it's been through a few iterations at this point, but I almost wish they would scrap the whole thing and fork create-react-app.
You can totally use typescript with React, in fact it's a game changer.
It's actually way more beneficial than with angular, as you have properly typed components all the way down. No crappy string templates that are not checked by typescript.
Regarding the "Flux" frameworks, that's not a problem anymore - basically Redux (which improves on some of Flux's faults) has won. Its developer was hired by Facebook, so I guess it's kind of officially sanctioned now.
I didn't understand this. Isn't MobX the "classical" way of databinding everybody frowned upon for years? And now that React finally eased that pain with Flux and then Redux, they bring it back?
I don't think that many people switched to MobX to be honest.
It's very similar to knockout observable and while it works, I don't think I would use that approach again. I suspect people like the familiar OO syntax of MobX. I can't think of advantages it has over plain old streams (most.js, flyd.js)
I've just finished my first major redux project and found it incredibly slow to develop with. Write an action type constant/action creator/dispatch/reducer/mapStateToProps just to show an element in response to a mouse click? I found myself cutting corners on the UI because the amount of code I'd have to write makes it seem like a huge task.
I'll be evaluating mobx for my next project, definitely, along with Relay. If I can maintain the same view-as-a-function-of-state approach of redux while writing less code, I'm sold.
Yup, this is a major strength of the front end frameworks. It can't be understated in my opinion.
I work daily on a large Angular app and a growing React app, and my React app, while being more pleasant to work with, is also much harder to keep standardised and clean. I'm also already experiencing perf issues because of not using immutableJS, which is quite annoying...
Both are similar in that they are component-oriented.
There are two important factors in my mind.
1. The ecosystem (as you mentioned). React has a clear head start here, but I expect Angular2 to make some gains over time.
2. Angular2 gives you a full framework, and as they say now, a whole platform. React is smaller and you rely on a bunch of other packages to get all the extra features you need. If you want a full solution, Angular2 gives you that.
This can be argued as a good thing or a bad thing. More flexibility with React, but also more things you need to figure out and make a decision about. With Angular2, once you buy in, you don't need to make all of those decisions.
In my particular circumstance, which is to migrate an Angular1 app to a newer framework over time (mainly for the server side rendering features), Angular2 provides a clearer path and offers some nifty features like component styles that allow a similar migration with CSS.
They didn't just do this "because." There were sound technical reasons to do so. Angular made the correct decision, in my opinion, and decided to cut its losses immediately and right the wrongs within the framework.
Well... I would argue that angular 2 is not even better than angular 1 so it will probably happen again :p
It's more performant, but that's about it. It's insane, java/spring like complex for no reason.
As someone who has never used Angular but is interested in Angular 2, can you give some examples of the framework-y things it provides that React doesn't? Redux is really the only thing I find necessary for what I've developed so far, and I'm sure Angular has it's equivalent, but what else does it have?
It gives the ability to do validation with form components, using a nice XHR abstraction, and a router - all optional. It also provides a robust DI framework and set of testing tools.
All three frameworks are excellent at helping us build ambitious front-end applications; you simply can't go _wrong_ by picking one over the other. If a particular framework's trade-offs don't for any part of the app (performance for example), you can always write just that part in a different way (manual DOM manipulation).
But to contrast all three, I'll pick the area I'm most interested in - templating. The purpose of a framework is to render a dynamic view without the programmer having to wire up every state transition with a corresponding view transition. This is done by templating content with state, mediated by the framework. And how this is done affects the entire design of the framework and apps written on them.
Angular and Ember allows state and logic inside HTML. They figure out which state variables and corresponding templates go together and re-renders them automatically. The pro is that writing a modified version of HTML without too much code lets us have a dynamic app running in no time. The con is that there is a new language to study - with its own parser, control structures, scoping, and quirks.
React on the other hand lets us specify templates as Javascript functions which are run whenever the state changes. The pro is that there is no new language abstraction to learn; it re-uses Javascript. External DSLs especially are in an uncanny valley - they're not full-blown languages but have enough quirks to be bothersome. Language abstractions forces a virtual machine (the language parser/interpreter) to evaluate the code, and it is an opaquely magical layer that makes it hard to see the entire stack of abstractions during day-to-day programming. It also forces a separation between our view (written in the templating language) with the rest of our code.
The con of this approach is simply more code to write; the programmer has to anticipate and inform the framework of any state changes. With setState this isn't as bad a trade-off as we'd imagine. And MobX meanwhile brings an Angular like state abstraction to React - it watches over observables and automatically fires re-render.
The other big difference is that React is not opinionated. It is a very much a framework alright, but it for example doesn't ship with a router, nor does it prescribe a framework for organizing the code. Ember has so far done a great job here - I often wish I could combine the Ember ethos of backwards compatibility, great documentation, and a fanatic love for the existing users of the framework, with the way React approaches templating and composing components. I haven't had the chance to look at Angular 2, but for me, Angular 1 started the front-end revolution happen, and I'm curious what they have done this time.
Have you seen yesterday's post about Cx? I'm curious what you would have to say about it.
Cx adds declarative data-binding, controllers and router on top of React and includes composable widgets and charts. It looks for a sweet spot between development speed and freedom to do whatever you want. Here's a quick example
https://cx.codaxy.com/fiddle/?f=42vDn4I1.
First impressions: looks like Angular's two-way data binding (using custom attributes in the template itself) added to React. This should make it possible to write complex views quite fast - without writing much code, and yet we don't lose out on the component-based composition of Javascript code offered by React.
What I need time to get around to is the concept of controllers and how it works when we want to compose things together. For example, how to write a multi-select widget that exposes a clear API to the rest of the world (onChange), and encapsulates all other details within. Cx does deserve a deeper look, and I'll definitely give it a whirl some time. Also kudos for the extensive documentation you've so far written!
> Angular and Ember allows state and logic inside HTML.
State updates do not occur in Ember templates. Templates specify the follow data from one component to another, as well as callbacks which are names of actions defined in a javascript portion of a component, or a parent component.
But it does not allow you to specify how state is updated within the template. In terms of Logic, there's just if statements & loops which is pretty conservative imo.
That is exactly what I meant, sorry for not being clear. State mutation definitely happen only in code everywhere, and not in templates (if we exclude two-way binding).
But by logic I meant all sorts of control structures, which though looks light-weight at first, needs a large number of language elements to function. To name a few: variables, expressions (which in turn need operator precedence rules), scoping, and even composition if we count partials/templates with it. Loops on the other hand requires not just simple array iteration syntax, but also over hashes, and it also needs other constructs like filtering (`todo in todos | filter:search`).
This is my biggest complaint with adding logic to text templates; behind the apparent simplicity there is always an entire language.
> That is exactly what I meant, sorry for not being clear.
All good, I'm probably tired (Australian time).
Maybe it's my inherit bias as an Ember user, but I'd argue Ember's templating language is alot simpler than you're suggesting
> But by logic I meant all sorts of control structures, which though looks light-weight at first, needs a large number of language elements to function. To name a few: variables, expressions (which in turn need operator precedence rules), scoping, and even composition if we count partials/templates with it.
Admittedly partials are a little weird, while I don't see them very often, it's still a fair point, however Ember templates don't deal with operator precedence as it doesn't have binary operators (entirely polish notation).
> Loops on the other hand requires not just simple array iteration syntax
Iteration doesn't have a blessed syntax, but instead utilises syntax that can be utilised by other components, and a better way to think of it is, the block inside the component is actually a function being passed to the component, which the component calls with every item of the collection.
> but also over hashes, and it also needs other constructs like filtering (`todo in todos | filter:search`)
It doesn't have pipes/filters, as that's easily expressed as a computed property in the js portion of a component. And I personally think scoping is pretty predictable imo.
Maybe you're just making a general remark about templates in general & i've read too far into it, then fair enough but in the case of Ember some of those don't apply, imo.
> behind the apparent simplicity there is always an entire language
Technically this is true, but I'm not sure why this matters, especially if it's trivial to learn? Because flip side of the argument, technically JSX is a different language to JS & HTML with even more complex semantics than a templating language because it carries the semantics of JS on top of it. You could make the same argument in favour of css over SASS/LESS, so I don't really see this as a big deal
I haven't worked with Ember's templating syntax, so don't have any thoughts to offer there. I was however bitten by Angular v1's templating, on which my comments were based.
SASS and LESS both add language semantics over CSS and suffer from the same problem. So does for example Jekyll's templating language. But in case of CSS, the language additions are a practical necessity - it lacks even basic abstractions, which the pre-processors provide.
I recently started a new front-end-heavy project and ended up just using Angular 1 instead of React. The decider for me was the amount of tooling that React needs you to have in place just to get up and running.
React expects you to do your development on some flavor of Unix, and really doesn't have a sane plan for Windows, so you lose VS.NET and its huge productivity gains. And it needs tools upon tools upon tools to set up, whateverify, transpile and pack the files you write into something that can display in a browser. Again, this all seems to want to run from a Unix command line.
I want to edit some HTML and Javascript, then reload the browser and see my changes. Angular isn't perfect, but at least it lets me do my thing without adding a bunch of extra hoops.
And it needs tools upon tools upon tools to set up, whateverify, transpile and pack the files you write into something that can display in a browser.
I think this was true six months ago but now there is create-react-app. You might want to try it out - you won't need to whateverify your code, you just need that one tool. Also it works on Windows.
The fun thing watching the new world of Javascript is that overtooling is so built in to everything that nobody even realizes how many tools they're using. You can't even install this thing until you have the standard pile of javascript tooling in place. And it never occurred to them to even mention how to get said pile set up.
Once set up, this still uses all the same stuff. It just removes a few steps to produce the Big Red Button you press to run it all.
This is the problem I have with all these "easy" setups and boilerplate projects. It doesn't matter how you set up your project, unless you do it wrong, it all comes down to a one liner in the end. All these things do is hide the complexity from you with the goal of being able to "get up and running quick", which I find fairly pointless for projects that are of a significant enough size that you're considering using React or Angular for them. You're much better off learning all the tools and understanding how your project works.
But then again, the thing about the overtooling is: I can't find anything in my React stack that is unnecessary or can be removed. And really, all it is is React, Redux and Webpack. I think the complexity of front-end Javascript development is blown a little bit out of proportion.
I can not share your experience at all. We are using React with Typescript for our projects at work and we have all common systems present (Linux, Windows, Mac).
Our projects compile from Typescript to ES6 and then ES6 to ES5 through babel. All of that takes place in webpack, and it was pretty easy to setup. We also all use Visual Studio Code and it's a joy to work with.
If you use something like hjs-webpack it gives you (hot-)reloading for code changes out of the box.
Visual Studio has task runner explorer now as well, it's easy to setup command line tools to run automatically, either on project open or on build.
I despair these days at the ridiculous number of command line tools you need to run, but once you've completely wasted 2 or 3 days of your life on these pointless things, cut and pasting command lines from setup instructions that give no indication what any of the flags actually mean, you can forget about them.
There were days when you just had to run an installer and then you were good to go. Or just get the latest version of the tools (and by tools I mean actual tools with a GUI and everything, gasp!) That's obviously really untrendy now.
But yeah, you can set it all up in VS to deal with the insanity for you. Good thing too, as the ASP.Net team have been drinking heavily from the command line insanity kool-aid.
Do you really want to point and click around on everything all the time? Maybe read the documentation on what various flags mean when you decide to use something.
Yes, the mouse + GUI is a lot more usable to me than typing in a CLI. The command line is from when we had terminals.
And worse still, yes, that's the case for most people. Most people prefer using mice + GUIs. Why are we going back in time? Why can't we have tools that work as both GUIs and CLIs?
CLIs are great for automation (and keyboard obsessed users).
GUIs are great for discoverability and making it obvious to users what the 'normal' usage is.
It's absolute madness to go back to the days of CLIs.
I'd disagree here. All the most productive developers I know make heavy usage of the CLI, and some of them, including me, are even developing in it with tools like vim or Emacs.
Self-selecting a bit there... Productive developer!
Have you considered that part of the problem is the stack you use causes other people to be unproductive because it's not clear what all the tools you're using are doing?
> React expects you to do your development on some flavor of Unix, and really doesn't have a sane plan for Windows, so you lose VS.NET and its huge productivity gains.
I've done both React projects with Python and C# apis. React is perfectly usable in VS.NET - are you aware of the Task Runner Explorer - https://blogs.msdn.microsoft.com/webdev/2016/01/06/task-runn... - hooks whatever you want into the build cycle, watches etc - once I discovered that, everything just clicked into place.
This mirrors my experience with react native. Not only did you have the react tools, but all the android tools. The abstraction leaked for me at the hello world stage where one dependency changed but I had no idea what our where without learning the entire stack.
I lost so much time with Angular 1. I don't care how much v2 is better than v1, I'm not touching it with a ten foot pole (disclaimer: switched to React, not looking back).
I'm really feeling the pain right now. Convinced previous company react was better. Even built my own app in React, now I'm at a new place that is using Angular 1.5. My god, it's so painful trying to get everything working correctly with jquery plugins. The blessed route often doesn't work, even though technically it should. I'm also getting performance issues for really simple scenarios...
The only thing in ng-1 that really bit me, speed wise, was long select/option lists. I wrote a bit to load them using jQuery instead of ng-options and now I'm good.
I like vue.js, the only and biggest concern is that it is a single developer project, I'm deciding between react and ng2 now because of that concern, leaning towards react right now.
React would mean to rewrite your whole application as it has a totally different basic concept. Following the ng2 migration path you're able to migrate slowly.
at my last job we did a gradual migration from Angular 1 to React. Its similar to the path to Angular 2 really. React and Angular can live side by side... All we did was build an Angular directive that can render a react component in a subtree (that's easy), and a React component that could render an Angular directive (that's a little harder, but not that bad).
With that, we could put a React component anywhere in our Angular app, and reuse Angular directives inside of React until we got around to rewriting them.
I wanted to open source it at the time...then my employer had layoffs :)
The "React component inside of Angular directive" is fairly trivial and there's a million examples on the net. Just make a directive that calls ReactDOM.render on the element in the link function.
Angular inside of a React component is harder to google for, namely because there's so much misinformation saying its impossible.
That would mean to live with a hybrid solution, more overhead and a bigger footprint. We currently deploy our JS base to web, Android and iOS (Cordova/Phonegap). It is and will remain one code base to be flexible and fast until we get "product/market fit" and until we have KPIs where we want them. This is cost effective but comes with the slowness of web-engine rendered apps. Therefore performance is big factor and we're optimizing for that.
By switching to ng2 we have have a cost-effective and performant compromise.
At the moment I also moved to react, but there are some obvious advantages in angular 2:
1. as others mentioned its a fuller framework, mostly akin to using react with redux (or flux etc...) and a di framework. This also means that angular 2 third party components are probably easier to integrate.
2. Reactive Expressions, which angular2 uses in many places, is a joy to work with (though they might become maintenance hell later on I think). You can use RxJs with React of course, but it's easier when your framework is based on it
3. It uses string templates - which means that some things such as dynamic templates and per user customization of html would probably be much easier to do then in React.
4. It has Ionic - which is much much faster to develop for mobile with then react-native (though obviously there are important differences). It's unlikely that an Ionic like framework for react will gain traction with react-native to compete with.
> It uses string templates - which means that some things such as dynamic templates and per user customization of html would probably be much easier to do then in React.
The key with React is that you manipulate JS instead of HTML. In my experience, using JS to manipulate elements turns out to be easier and a much better experience than the conventional way of using templates.
Because you have the full power of JS available to do whatever you want, however you want, to generate HTML. With a templating engine, you only have whatever the templating engine provides.
React would let you use JS-powered templates.
Angular would let your use ANY (static html, JS generated, or dynamic/server generated), because its pluggable.
For me, the power offered by Razor(cshtml) is too much to abondon.
Yeah, we have Angular 1 code in production, and I would like us to get off this train. I'm going to be evaluating Vue.js and Aurelia, and will probably push for Aurelia.
Yeah I've been looking at this recently. I like autowire's ability to create typesafe APIs shared across the client and server. Very promising, but not simple to set up...
Really? From reading that guide I thought that Autowire made it easier by automatically doing the serialisation/deserialisation. How does stock scala.js do that?
I've been very happy with the material-ui components for React. They cover every component I need, and it was trivial to integrate them into an existing app over time, no need to do a full conversion on day one. They also seem entirely React idiomatic, I've learned a lot about how to build reusable components myself from their API.
The problem with material-ui is that a lot of their components don't follow material design guidelines like their tables for example. It looks good, but it's not material. react-mdl is much closer to material, but incomplete due to missing components. Angular seems to have the best implementation so far, but I'm looking forward to material-design-lite v2
re:learned a lot about how to build reusable components myself from their API
material-ui's tutorials are really bad examples on this.
They teach you to import from specific dir path inside material-ui.
(e.g. import Pen from 'material-ui/lib/pen' or whatever)
Instead, they should recommend:
import { Pen } from 'material-ui'
since most of their exports are already in material-ui/src/index.js file (or some index.js file from package.json's main part)
I was put off by their TextField implementation. Their oversized <input> element doesn't play well with browsers, eg. the browser's auto-complete looks completely out of space.
You have to learn weird syntax such as ngFor whereas in React you just use a JavaScript for loop.
In React you embed HTML inside the TypeScript and VisualStudio treats both the HTML and the TypeScript as first-class citizens. You get compile-time checks and intellisense for both the HTML and the TypeScript code! You can even put breakpoint inside the template and step through loops whereas in Angular you can't step through an ngFor.
Note that some of the above may have changed since I last looked at Angular 2.
>The HTML template in Angular 2 is stored in a string. This has several disadvantages
This is patently false. Just use "templateUrl" instead of "template". This allows you to specify a file instead.
This is the way I always did it in angular 1 as well. I don't really understand why style guides & general practice recommend embedding html in the javascript though. It's horrible.
we can do both. In JIT mode, we XHR for them and compile them on the fly. In AOT mode, we do that at build time and turn the templates into TS code, which we can then typecheck (thus giving you typechecking against templates) - the benefit of this is you don't have to ship the compiler code to the browser, don't pay the cost of runtime compilation, and the generated code is monomorphic and thus highly optimizable in browser VMs.
Oh cool, sounds similar to what Ember is doing with it's glimmer engine. Are you guys compiling it down to dom api, like htmlbars did? or something similar to a VM style runtime like in Ember's Glimmer 2, where templates are compiled down to a series of opcodes? Or something entirely different from those approaches?
1 through 3 are false - in fact, it has been advertised by JetBrains that TypeScript with WebStorm can detect string templates when using the Component decorator in Angular 2 & the template option and parse them while doing debugging & syntax highlighting, and this was months ago.
I'm sure 4 can be solved by editors, if it hasn't been already.
I do agree that I really really was a fan of the backticks for ES6 / react for templating. Avoiding the whole " vs ' escaping nightmare is something i've always looked forward to.
That seems like a very simple fix for them though, potentially.
In the page you linked the template is stored in an external html file in which case you get syntax checking for html but not the embedded expressions.
The template vs. JSX argument is highly subjective; a lot of people go the other way because language extensions break existing plugins, require extra build tooling, and add complexity.
The same could be said about the "JavaScript vs TypeScript" argument. I can see that argument, but in my opinion, the safety nets provided by TypeScript and TSX are well worth the initial learning curve.
What editor are you using? I'm on IntelliJIDEA 2016.2 and it supports all first 4 items. But as for the latter 4 items, I hope those features will be available in IDEs in the future with the release of Angular 2 stable.
And exactly the worst performance of them all. Coupled with the kind of spooky side effects down your pipeline that you thought long gone since the first releases of ruby on rails...
But actully, the performance is not a question anymore, with the new Glimmer Engine 2 Ember will be the fastest framework, with full backward compatibility.
I'm not saying angular is better, but "can't" might be a bit strong. Maybe "don't currently" would be more appropriate since some of those things are very possible if not already in existence.
Serious question : Why are SPA frameworks so popular these days? When someone asks "What should I use for web development?", It's now all about React/Angular/Ember/etc.
But when I look at how are built the sites I like and visit frequently, I'd say 95% of them are not SPA, they are classic sites where the server generate each page (sometimes with one or two Ajax requests)!
The Single Page pattern is great for desktop-like applications such as Gmail, it's obvious. But otherwise, I don't know... I think I still prefere the "feel" of classic websites.
> I think I still prefere the "feel" of classic websites.
Your hacker biases are showing.
The sites where 95% of people spend most of their time (Twitter, Facebook, Instagram, etc.) are all built as single page "applications." Users expect rich interactivity from websites these days and are usually not tolerant of UI refreshes.
The comparison is not to "desktop" applications but to mobile apps. Users expect a mobile app level of interaction. Plus, if you're building mobile apps then it's a lot easier to just reuse those same APIs for a web app.
That being said, if your site doesn't have any interactivity then it does make sense to just render it statically.
One of the key advantages of a single-page application from the User Experience perspective is perceived response time. It takes well under a single frame refresh period (~16ms) to react to some event and either change the page using data you already have, or throw a loading indicator on the screen.
The app may have been slower to load the first time (hopefully not by much) but from then on, they get the perception of instant feedback even if they have to wait a round trip for the backing data sometimes.
SPA frameworks make this sort of interaction very easy to design and reason about as a developer.
Hyperlinks are a form of interactivity. That aside, there is no reason why one cannot have many individual pages which each have their own interactivity.
If you are going to argue that this is about "hacker bias" you will have to show user studies, not poll JS developers.
Well it must not be a very good 3 yr old laptop then? And firefox isn't exactly the slimmest or lightest web browser. Sucks ram just as bad as chrome used to. My 3 year old laptop can handle all of the google services just fine.
8gb RAM, great CPU. I'm playing counterstrike global offensive and civ 5 with very few problems. Lower FPS sure because the video card isn't great but it shouldn't be this bad. It was fairly decent in Win7.
Prevalence of API's. One common interface to query/update from. You don't have to do both server side, and client side requests. Rather do it all client side.
I've done of a few of these types, and now have moved onto mixed environments. Where most is rendered server sided, then only updates requested client side. Of course you're doing things twice for same queries.
What's with the "serious question", "genuine question", etc? Mostly I see this mannerism prefacing questions that could not reasonably be taken as a joke or provocation.
Serious question: are people so touchy these days that you have to assure them that you are not being hostile before even saying something?
If you look at some of the comments condemning him for not backing up his preferences with statistics it makes sense that he should preface his questions with something to provide levity. I don't know why programming communities are so touchy about their tools, particularly JavaScript frameworks. It must be a sort of buyer's satisfaction to convince themselves that they made the correct time investment.
This is a huge release for the Angular team, I'm happy for them and I don't want to sound like I'm "attacking" them with such question. Also, english is not my main language so maybe I don't understand perfectly when to use this expression or not. I see I should use it more carefully! ;-)
Someone having a different point of view online isn't that radical of a concept. Especially considering how easy it is to misinterpret the tone of someone's remark online. It just shows you're going out of your way to clarify your interested in a genuine discussion.
For me it has the opposite effect, it makes everything sound less genuine. But hey, I'm just some guy, if people like it...
I find unnecessary clichéd phrases very annoying (e.g "going forward"). Maybe I'm alone in this. It's not because of pretentiousness or language puritanism, it's that it makes me feel that I'm reading something created by corporate PR or some other soulless entity with ulterior motives. My rule of thumb: if you have nothing creative to add, just be simple.
Also I think it's more intuitive to develop. You do all your logic in the "app", and the REST layer is just a glorified DB wrapper. It matches the project's inevitable phone app more closely too so you don't have two entirely different paradigms.
Of course all that goes away when your boss says you need to support JS-disabled browsers.
> Of course all that goes away when your boss says you need to support JS-disabled browsers
Well seeing as this release of angular offers some form of server side rendering, as well as Ember with fastboot, & being implementable in React or something like that. It's more approachable these days, there's some tweaking that's required, but very much doable.
Unless of course you're dealing with an interaction heavy UI.
It loads faster, you can have a richer experience, you can use less compute resources and less bandwidth. And I'd say that HN users are not typical users.
In any event, if you're making a real Web application (as opposed to just a Web site that's primarily static content) the experience is much better.
IMO building classic websites is a solved problem, while building web apps isn't.
Classic websites have CMS, things like Wordpress, and a ton of MVC frameworks that have been tweaked over the last decade, like Rails, Django, ASP.NET MVC, etc. When it wasn't a solved problem, a new one like this was popping up in the news every other week.
Now, that that's done, people are trying to do other things, like complex web apps...and so that's where the brain time is being spent.
There's honestly no need for React/Angular/etc to necessarily power a SPA, you can just use it to build smaller components. I initially got started with Angular to power a reusable video "widget" component on a WordPress site - a far cry from an SPA! It's also a great route to getting your feet wet without committing wholesale to a technology.
+1. I've made nine react apps since last year, only the two last are SPA (because I wanted to try the golang/react combo).
React is super good to take control of a small piece of the page and build a complexe widget on it (can't speak about angular, I only used it twice without getting very far).
React, Angular 2, Vue 2 and some other SPA frameworks or view systems all support server-side rendering with very little coercion nowadays. That combined with google executing javascript during indexing means that SEO isn't nearly the issue it used to be.
Most websites and web apps have use AJAX to dynamically update certain parts of the site. Even though few sites would need to use it for everything, once you introduce good tools for dynamically updating the DOM and hire some Javascript developers, it's easy to say "Let's just use this approach to everything".
It's fair to say it's a lazy approach. I've built many SPAs that probably would have been better as static sites, and would have benefited from better SEO. But hey, we got then shipped fast.
I don't think that's entirely true, they allow for building experiences that weren't really possible with the previous model of rendering entire pages server side on every action but they aren't easier in all respect to that. If you site is mostly static data, it's probably still easier to use the older model. SPA frameworks start to make more sense when you want to build interactive pages with components that you want to individually update etc...
But they do add complexity that can't be ignored. that's why tooling and frameworks are hugely important as they smooth out that complexity.
The biggest "easier to develop" thing for me is the ability to have the SPA separate from the server. Being able to deploy beta builds, one-off builds, etc makes it MUCH easier to diagnose production problems.
So, I guess I'm saying that it allows for much shorter iteration times, ability to experiment with solutions in the production environment without requiring complicated server solutions.
Granted, that also lets me build experiences that weren't possible, because I can experiment more and have a faster feedback loop, but for me, it's because I can DEV better.
Because today there are websites and there are are web apps. Sometimes there's a combination of both - for example a blog - it's front end (user facing) part could be rendered by the server page by page and it's backend (admin access) is a single page web app. Each is used where appropriate - website - mostly static content, SEO and web app - a lot of user interaction.
There's no such thing as a web app, just javascript apps, and every time someone ships one the world-wide web of linked hypertext becomes smaller and less useful than it might have been.
You can have a lot of interactivity with plain Javascript + some Ajax requests, without the need for the application to be a single page developed using an almighty framework. Classic websites are not synonym of "static documents" in my opinion.
HTML5, CSS3, and Javascript have matured to the point where they are very powerful and flexible. I don't always see the point of over-complicating things with frameworks.
I recently built a small three 'page' game for a trade-show booth. By using Ember, I was able to: try out a new CSS framework based on flexbox, save data to localstorage, capture images from the webcam, have 'data binding' of variables so that they updated on the page when I changed them, and deploy to surge.sh in the first hour.
All-told, it took 20 hours, 7 of which was me getting used to the intricacies of developing a full-screen "App" (no scrolling) with flexbox and implementing the designs. I'm good with vanilla JS, but there's no way I could have done all of the coding (three 'game' pages, three 'admin' pages) in less than two days.
I guess the point is, a framework that you know and are familiar with can halve the time you spend on a project. I find that to be especially true with Ember because of the CLI tools and all of the various addons.
Front end development is crazy these days. I remember on my road to learning Java EE banging my head on the wall trying to put together things like dependency management with Maven, ORM's, and all sorts of arcane concepts and patterns. It took me a long time to get to that point but now it seems all too familiar.
As someone coming up to speed with frameworks like React and Angular 2 it feels like that all over again.
That's Conway's law for you. All three frameworks were built by meglogcorp, and they all feel exactly the same.
It is funny that after the Rails driven success web devs had moving away from J2EE they are falling right back into the same traps - ultra complex bloated frameworks built on a terrible language.
> ultra complex bloated frameworks built on a terrible language
Even if you consider JS a bad language, proper abstractions can change the face of it entirely. By your logic, assembly is also bad since it is absurd to write anything useful in it. IMO Elm is a step in the right direction.
I've been doing a lot of FE for many years now and have worked with all major frameworks and I love JS and its flexibility. That being said I think we've been building one framework after another trying to abstract the things that make JS a language not suitable for state dependent apps. Elm feels like the right step compared to anything else out there.
Javascript is definitely a terrible language, but it is the only language for the web unless you consider languages that transpile to javascript. Are you suggesting not using a javascript framework, using a transpiled language instead of javascript, not writing any front end code at all, or doing something ridiculous like turbolinks?
"Why would you consider JS to be a terrible language? "
JS is kind of a 'bad language' because:
1) It's missing some pretty important things. Try to determine if a value is a number. Seriously. Look into that mess. Or anything else. Doing simple type-checking is crazy, and we basically are resigned to 'best practices' - which is crazy.
2) Prototype chaining is a neat idea and has some merits - but in reality it makes things super-duper complicated. Ask 10 JS devs how it works and get 21 answers. That is bad.
3) Almost nothing is built in. You need to use a lot of 3rd party libs to do common things.
4) There is no such thing as 'JS' - ever browser, every version - you get completely different implementations. Maybe we can't blame 'JS' - but pragmatically, this means JS is a problem.
A minor issue is issues with packaging, encapsulation and scale, which is also a function of loose typing. When JS programs get complex, they get unruly, and you wish you might be able to do things in an OO language at that point.
JS is really light, and that has advantages - and I think it's the best language for a lot of async things - and UI's are inherently async - so that's good.
In 5-8 years JS might be 'stabilized' in terms of libs or de-facto standards and it will grow.
To anyone who's programmed in other, more established languages, I think it's clear JS has some weirdness that doesn't need to be there.
ES6 adds isNaN and isFinite static methods to Number that don't convert their argument to a number first, so Klathmon's version works. But I don't make any claim about whether it's correct or not.
1) Isn't it just (!isNaN(num) && isFinite(num))? I know that's pretty far from intuitive, but it's not as bad as you made it sound. That being said, i'd love an `isNumber` function at some point...
2) I felt the same way for a while, but recently I was working on something where I ended up really "abusing" the prototype system, and when you actually spend the time to learn it, it's not that bad! It's different, that's for sure, but it's not bad.
I like to think sometimes that if javascript came before C, would we still call many of these things "bad"? Would we call javascript's equality table "weird", or would it be C's that was the weird one? Would C be the star in a talk labeled 'Wat' where they laugh at the absurdity of 'a' == 97? So much of the stuff that people complain about in JS is because they have expectations from other languages. Sometimes those expectations are a good thing, but other times they are just different, and taking the time to actually learn how and why it's different can make you a much better programmer.
3) I genuinely like this about JS. There is no "one true way". The language is free to evolve, change, get new features, get new functionality, and easily "polyfill" old browsers outside of the release cycle. And that's important in JS because there is no one "authority". Keeping the stdlib small means that it's easier for new implementations to crop up, and it leaves the "niceties" to be developed by libraries. It's what allows libraries like ramada and lodash to be so powerful. They wouldn't be where they are today if the stdlib was more opinionated/complete.
4) But again I kind of like this. It does often make things more difficult, but at the same time it improves the ecosystem. I honestly believe that the fact that there are competing implementations is pretty much the only reason javascript (and in some ways, all dynamic languages) are as fast as they are today! Not only that but the fact that there are multiple competing implementations keeps most devs "honest". For the most part I don't need to worry about someone writing code that will run on version X on platform Y. I don't need to worry that the next "update" will require us to spend a week cleaning up removed functionality. It does lead to a lot of "crap" accumulating in the language, but over time that crap can and will be removed. JS is a fluid, constantly-evolving language, and because of that you tend target a point in time, not a "release", and the impressively awesome backwards compatibility means that while your older code might look outdated, it's not going to suddenly stop working.
I do agree that complex JS programs need much more tooling to be manageable, but it's working out very well in my experience. It's just different.
"1) Isn't it just (!isNaN(num) && isFinite(num))? I know that's pretty far from intuitive, but it's not as bad as you made it sound. That being said, i'd love an `isNumber` function at some point..."
You just proved my point!
A) Even if you are correct - it's terrible. This is completely ridiculous that there's no basic check for extremely common and mundane type-checking. Moreover, it's the same issue for other types!
B) Worse: you're wrong.
isNaN('100') = false
isFinite('100') = true
The string '100' would pass your check as a Number :)
Underscore uses:
"toString.call(number) === '[object ' + Number + ']';"
So noodle on that for a while: I'm assuming you're an experienced JS programmer and you can't test to see if something is a number! Embarrassed? It's ok. 9/10 JS programmers would get it wrong. I had to look it up! Which is my point - it's really bad!
2) Prototyping is not bad because it's prototyping - it's bad because it's really confusing. Point: nobody has - or will 'borrow' this idea form JS. Again - almost zero JS devs really understand how it works.
3) Again I disagree. There definitely should be a 'true way' for the most common operations. There should only be one 'true way' to test to see if something is a Number (!) - and for basic things like string operations - 'one true way' is better. For so, so many reasons.
4) "For the most part I don't need to worry about someone writing code that will run on version X on platform Y" - sure you do. You cannot use 'const' or 'let' in Safari/iOS. You can in Chrome. That's just the tip of the iceberg. There are dozens of such mismatches - and it's a fragmentation nightmare.
Now - I agree with your point about 'competing versions' hey, that's great. But they are 'not the same platform' - which is totally destructive.
Well that's because this is checking if a value may be a valid number.
It's not safely converting the value to a number.
That's done after a parseFloat()
1) well look at that! I guess i've gotten a bit spoiled relying on lodash as much as I do!
2) There are aspects of prototypes that JS makes much worse (mainly the whole "this" clusterfuck), but the base is pretty sane and easy to understand. But at that point i'm not even talking about javascript any more, so I guess you are right here too.
3) I still disagree with you here. Yeah, there should be a way for the stdlib to do simple low level things (like isNumber()), but for others "one true way" isn't the best. I'd love a better stdlib, but I don't want something like Go's stdlib. I'd rather the language define a "bare minimum" and let libraries take over the rest. Now, as with anything in life this should be taken in moderation, if there are massive gains to be had by including something, then it probably should be included.
Maybe this is stockholm syndrome setting in, but I'd rather have the choice of implementation of something in-language, because there are so many different engine implementations.
4) I was more speaking of things like a python library that only runs on 2.7, or a java application that only works on 6. For the most part, those things just don't happen in javascript. Yeah, you need to not use newer features until they roll out everywhere, but once they do, you are safe in using them for a pretty damn long time. In your example, you can't use const/let right now because safari is the last big holdout here. iOS 10 was just released, and with it Safari 10. In another month, i'd feel comfortable using const/let without transpiling it, and I won't need to worry about it again.
But another benefit of multiple different implementations is they are free to optimize for different things. For example, Espruino is a JS engine that runs on microcontrollers and is EXTREMELY low power. Chakra (Edge's engine) shoots for really fast startup speed. V8 is pretty much the king in terms of raw execution speed. Contrast this with the Java way of having a million settings, knobs, options, and flags in the engine to tune the system the way you want. Yeah, you can do that, but most don't because of the complexity and risk involved. And there is only so much that you can do while having to support every option in the same engine.
Like i said earlier, i'm not sure if it's stockholm syndrome taking effect, but JS is by far my favorite language, and despite all it's flaws, issues, problems, and mistakes, it's also the language i'm most productive in. And with ES2015+ it's only getting better. (although i'm dreading the time when modules start getting into implementations, and how they conflict with current solutions, that's going to be a NIGHTMARE in just about every way).
"But another benefit of multiple different implementations is they are free to optimize for different things."
Every language has that. There are different JVM's, different C/C++ compilers, different python interpreters.
JS is not 'at any advantage' here - and again - the drawback is the ridiculous fragmentation we see across browsers - which is ... bad - at least compared to other languages.
But I wouldn't even say that. Look at the C/C++ situation. Microsoft as a platform doesn't support a ton of C, every compiler has it's own ways of using undefined behavior, there are tons of extensions and "only works on compiler X". Look at python where even if you ignore the 2/3 split, you have ironpython, cpython, pypy, and more that all have their own quirks, differences, and incompatibilities. It's pretty often you see a python library that only works on cpython.
For all it's issues, JS has mostly moved past that. It's pretty rare to see a javascript program or library (that's not just a tech demo) that only works on one implementation. Hell Microsoft released a node.js fork that runs on chakra, and to my surprise every single one of our node applications runs on it without a single change or hitch. (i haven't looked up if this is "normal" or if i got lucky though, so take it with a grain of salt).
Now obviously it's not perfect, and we should strive to be better, to fix these issues, but it's not like javascript is in some unprecedented scenario here. I actually think that the IE6 days have pushed JS to fix a lot of the problems that are plaguing other languages in this area.
That's very true -- it is reminiscent of the old J2EE days 12+ years ago. But it didn't really take long back then for a consensus to emerge about how awful most of that technology was (enterprise java beans, etc) and for people to settle on more simplified, streamlined approaches. How long will it take for the momentum in the front end community to similarly shift away from these bloatware approaches?
I am a java programmer and I want to head towards web development. My first thought was learning JSP, Servlet and then move towards different frameworks like Spring. I don't know much - but can you tell me why JavaEE is an awful technology?
Yeah - we consult with an angular + Java group (for angular only) --- I can't understand half of what they are talking about when they talk about Enterprise level Java web projects. Java for Hadoop, Spark etc I work with daily.
Enterprise projects tend to have way more convoluted business logic and interfaces than consumer stuff -- it doesn't get nearly the love it deserves imho. Those developers, DBAs, devops folks, and sysadmins suffer sooooo much every day.
absolutely - but typically you can't get all this pain across to the 'business' because of an enormous lack of understanding. As long as the buttons in the GUI look nice and shiny, who cares what happens further under the hood..
If you use Ember.js, which is the most matured and serious on the market, you never had that feeling that JS changes a lot. Consistent and continuous improvement. The best choice.
I venture a guess that you learned JEE by rote and not from first principles.
Learning by rote is stressful since your mind has to retain effectively a bag of (to it incomprehensible) technical trivia. In contrast, first principles are compact and generative, and such a grasp also informs your intuition so you can actually make educated guesses and jump in the deep end when picking up a new stack. Same principles apply to learning programming languages.
The biggest headache in picking new stacks today is the current trend of technical neologisms, so a bit of initial squinting (for recognition) is required.
I have been using Angular 2 for 3 months now and so far have loved it (except for the breaking changes in RC series and updating each time). Glad 2.0.0 is here. Here are the few things I loved, amongst other interesting features:
1. Typescript awesomeness: You can write plain JS or give type hints in Typescript. Typescript is awesome, because it is a superset of Javascript and compiles to Javascript. (Typescript > ES6 > ES5)
2. Modular code: It is is much easier to manage Angular code as it grows (compared to AngularJS). Components could be made independently and reused within other components using component interaction [1] (@Input, @Output)
3. Template Directives: .html template directives are available unlike ReactJS. A ReactJS vs Angular2 blog post online [1] argued that that putting HTML in Javascript is better than putting Javascript in HTML. I'd argue that template directives like ngFor, ngIf, etc are much simpler to understand. Also, it is easier to collaborate with a designer/half-developer who knows some html/scss and doesn't know Javascript than working in ReactJS where every collaborator has to know JS. This way, it is also easier for someone to gradually learn the framework. For me, template directives are a big win. If someone wants to construct templates with plain JS, that is still possible in Angular.
4. @angular/router is better than AngularJS routing and we don't have to use a 3rd party library (like ui-router was more popular in AngularJS than the angularjs router)
One thing that I have found annoying is that: UI libraries for Angular. Example: material2 (currently at alpha.8) [3] are not complete yet and lack several useful components. This can be a problem if you are looking to quickly build a complete, good looking UI. Hopefully, now with Angular 2.0.0 out; Angular team could focus on quicker development of material2, so we have all the AngularJS Material UI goodness with Angular.
We've been using Angular 2 for about 6 months now. Having things deprecate several times like the routing engine was annoying but that's the cost of being on the cutting edge. The side benefit is that we learned a lot about the inner workings of Angular.
I agree with your annoyance with the UI libaries. It's been a PITA just to find a working datepicker. We eventually rolled our own starting with the source of an abandoned date picker project. Haha.
Be aware, it is not perfect atm, especially around validation, but it is pretty much the only datepicker out there for ng2 in the open source world (not even Angular Material 2 has one).
Just curious if you could speak to any of the performance / development time metrics? I.e. do you spend less time developing a component in ng2 vs. ng 1.x ? Do you get better performance with ng2 vs. 1.x etc?
I know it's supposed to be faster - I just am not finding people using this stuff in production seriously until now.
I don't want to clog up the angular group with these informal lines of questioning - obviously.
It's super easy to write a component in ng2. I feel like it's faster, but it's been about a year since I really used ng1.
My favorite thing about ng2 components over ng1 would be the annotations. One annotation turns my component into a component. It links the html template, sets up the services, injects the other components and directives it needs in one simple annotation. In ng1, I remember it being cumbersome to set everything up.
To use a component in your existing app.
You create a new ts file.
Add an annotation.
Write the template inline or in another file.
Reference that ts class in your other components. That's it!
We have been using Angular 2 seriously in the past month at my company.
There is a lot of roughness around currently when it came to upgrades during the RCs - Angular 2 was far from full-fledged even during the earlier ones, and has come a long way in the course of their development. Testing has a massive gap in documentation/articles on how to do it right. There are also some pains such as some (IMO somewhat poor) opinionation in the Angular router, especially when combining with server-side routing - had some battles integrating the Angular 2 app with the full server-side app for work, in large part due to hapi's major deficiencies when it comes to delegating routing to a frontend only application. Setting up can be daunting, although I got a large boost from using https://github.com/preboot/angular2-webpack, a great starter pack largely maintained by a member of the Angular docs team. Not all of the benefits are easy to tap into currently, such as the fairly recent AoT compilation, which lacks any plugin support for any build system such as Webpack currently. I intended to write one & open source it, but I was assured by a member of the Angular team that it was on the docket to complete. Documentation also needs a lot of work to be more developer friendly, I have found senior developers making easy mistakes with Angular 2 because they are not familiar with how to structure everything while having to produce on difficult story work. Testing is also a sore point, especially with the need for the karma shim to be produced for each app.
That said, Angular 2 is a phenomenal upgrade over Angular 1 in the ease of structuring apps. It also avoids incorrectly munging everything into components, avoids imperative logic to construct DOM/components, and imposes opinionation & more modern tooling such as the availability of observables to more correctly manage app state & app flow. It is fast, and much easier to tap into optimizations than Angular 1, where one had to be able to work close to the source code in order to understand everything one can and cannot do. It also offers the flexibility to do everything one can do with React, including server-side rendering (with the ability to do so on platforms such as PHP, Java, Node, and .Net in the pipeline), web workers, service workers, and multiplatform apps via React Native or NativeScript.
Awesome - thanks so much for this from a team running 1.3 in production (and looking now at moving to 2).
Just curious if you are indeed saying that the built-in router allows you to do EVERYTHING you could do with ui-router (nested states / targeted views etc)? I was planning on sticking with ui-router-ng2 when we kick over to angular 2.
How about testing? Was that difficult moving test suites over?
About testing: e2e test will take almost 0 efforts to migrate, unit-tests will be rewritten completely (although your code too, so nothing wrong with it).
> Bug fixes and non-breaking features for APIs marked as stable
> More guides and live examples specific to your use cases
> More work on animations
> Angular Material 2
> Moving WebWorkers out of experimental
> More features and more languages for Angular Universal
> Even more speed and payload size improvements
Ha! I foolishly thought that when ng2 hit RC, it actually meant things would be stable. Keeping up with the ridiculous amount of breaking changes (the router, for example) through the RC versions was a horrible experience.
Hahaha. No shit. Stackoverflow would be like "You are using the wrong router. Use version x." Then someone said "No, version x is deprecated as of last night. Use version z. They skipped y after abandoning that too."
Rob Eisenberg and his nimble team beat Angular 2 to the punch all the way back in July when Aurelia final was released. Before considering Angular, considering checking out http://aurelia.io - easier to learn, no third party dependencies and great support. I applaud the Angular team for sticking it out, but I am afraid they released far too late to compete with the likes of React, Vue and so on.
I now have several Aurelia apps in production. I've also created an app in Angular (v1), and another using Ionic (v1) - which was great. But, I can't express how well Rob and his team executed on this project. Documentation could be a little better in a couple areas but this is a place where they've done extremely well also (contradiction I know - but, for example the cheat sheets are amazing and documentation is complete on most things but there are some classes that are still not documented well enough). If you want to develop in Aurelia - just the community on Gitter - they are extremely responsive and very helpful.
The documentation has been improving since January, and I expect there to be plenty more in a short time because for over half a year they were focused more on getting from beta to a full release. But even with the cheat sheets it felt like there was plenty to get work done because the complexity isn't so high with Aurelia - less to get confused about! And I agree about the Gitter channel being very friendly.
You might be underestimating how much inertia the Angular name has in larger enterprise dev shops. They're still creating new projects in Angular 1.x, and will eventually starting using Angular 2 just because it is called Angular.
Please! The more of you that join us in Aurelia the better it will be, and I think the Angular community will benefit as well because at least they would become aware of some more best practices they could use to improve Angular.
As a developer who didn't care for Angular 1.x and strongly argued in favor of a simple approach for years (Backbone, etc).
I've been using Angular 2 in a major enterprise project since RC1. Even with some of the headaches between RC releases; all of the reasoning behind those changes is technically sound.
It's easy to write components and wire everything, and even small things like async validators are fluid and easy to implement.
I'm loving it, and while the entire build system is still a bit of a dumpster fire; we're doing great on things like testing, code coverage; etc.
There are a lot of problems with lazy developers hoping a blog will tell them how to do every little thing. The source code is on Github. If you can't get something working right; maybe go read the source code of the classes you are interacting with. I've found 99% of the time now that simply reading through the code gives me not only the transparency needed, but a clear path to a better solution. Kudos to them on the new forms; they're awesome.
One thing that is hugely helpful that many developers don't do is read the tests for the library they use - in particular with Angular, reading the tests in the Angular codebase actually assist greatly in how to use a feature.
It's a fantastic framework and I'm looking forward to building a ton of cool stuff with it.
Though next week's announcement...
Angular 2.0.1 RC 1
It's Change Log will read:
* Routing has been rebuilt.. all previous versions not compatible
* We decided to rename the NgModule decorator to NgYouMAD?
* All Internet tutorials no longer work... Good Luck relearning!
You know what, these religious debates need a war to settle the question. Let's get 3 of the best teams for each stack, have them build the same 4 apps that cover a few of the most common scenarios... and let's see who's solution is done the fastest, is most maintainable, and has the best performance.
I get the idea that it isn't really possible for a definitive one to exist, because all of the frameworks and their recommended accessories are changing so quickly.
I wish people would just stop pointing this out. While technically true when people refer to React they're referring to the canonical stack that people use (i.e. + Redux).
AngularClass's free project-based course on Angular 2 by Scott Moss has been pretty popular in the release candidate stage with 10k students so far. Will be getting updates with official release changes soon.
Never used Angular. I was considering it for one project, but the uncertainty around the whole Angular 1/2 thing made it too risky, so I stuck with what I knew at the time (Backbone/Marionette).
Tried Ember.js more recently, didn't much care for it. I think I'm just not a fan of large frameworks.
Right now, I'm considering which works best for me. Requirements: App for Android & iPhone plus Web-based app. The most complex part is a Graph with interactions (such as highlighting a specific value). It should feel snappy, although I don't make heavy use of neither gestures nor OS-related features.
Ionic 2 + Angular 2 seem to be the best choice, since I can basically write the app once and release for all three platforms.
React Native has the downside that React and React Native are two different things. Be aware that there is no such thing as React Native for the web. There's something in development right now, but nothing stable.
Truly native: I can't support three platforms as a single developer and I don't feel like outsourcing it.
I'll go with Ionic 2 + Angular 2, although Ionic 2 still has quite a few bugs. For example, the zoom attribute on <ion-scroll> doesn't work – which is critical for my app.
I'd be interested to hear people's experiences with running Angular 1 and 2 side by side in the same application for the purposes of incrementally migrating an Angular 1 codebase.
I heard that a particular company, Rangle, worked on AngularJS2 and from what I've heard of them they're an MVP/dev-agency so it isn't surprising to see some of the complaints here about broken backwards compatibility and bad documentation around testing.
Seems few people know how to steward a free/open source software project that has lasted over 5 yrs.
Rangle only created an Angular 2 successor to Batarang. They had nothing to do with core Angular 2 development.
Angular 2 in beta/rc was in many ways rapid iteration on top of experimentation to get the core APIs & developer experience right. They have finally reached a stability point where they feel completely comfortable with the framework they have ended up with as a result, thus the formal release of 2.0.
If you've actually paid attention to the development cycle of Angular 2, it was very fast - it turns out that Google moves much faster than most shops, which was seen in full display during alpha/beta/rc. However, that goes with the territory there, and the versioning did not lie. It is now following semver though, so we shouldn't be hearing of these problems anymore.
I expected angular.io to be a flashy example Angular 2 SPA and was disappointed when I realized it was just a regular old static HTML website. I guess most of the content is more suited for a static site. At least the search bar on the docs page looks like it has some Angular going on. Also it would be neat if the docs had dynamic examples instead of screenshots.
It actually is an Angular 1 app, for a very simple reason: when the docs site was started, Angular2 wasn't fully usable yet! There is an effort underway to rewrite it in Angular2, so it will be eventually.
We're all going to get a couple of nights sleep, but that project is in progress and should be out soon. We're making sure it shows off the best of ng2.
I think ultimately ng-bootstrap* (https://ng-bootstrap.github.io/) will be better, but I'm biased. API signature looks much better than shoehorning everything into components that don't belong there - we have a lot of work to go though, so it currently is still a work in progress.
* I am a part of the UI Bootstrap/ng-bootstrap team - we worked on ng-bootstrap starting back in last August/September and have the benefit of two of our team members currently working on the Angular team.
There seems to be a lot of advocacy for tossing everything into the component tree in the React ecosystem - recently I got linked to a snide remark by Ryan Florence on Twitter implicitly arguing for putting everything in the component tree, including constructs that should have a better separation such as routing (which the tweet appeared to be a reference to).
Some services don't belong in JSX though - this is why you have the idea of stores in Flux/Redux/etc. Some data doesn't make sense to couple to the component hierarchy - doing so makes it very easy to create dependencies on the component tree, which decreases modularity, as well as has perf ramifications by increasing the DOM elements that get rendered unnecessarily by React. Some examples are data models, routing, and interactions with non-element DOM api (window.location, XHR, etc.). This also has a side-effect of increasing difficulty of testing what generally should be vanilla constructs not tied to various frameworks/libraries unnecessarily.
From a purely pragmatic point of view, I can say that I write very little code when using react-bootstrap, can create screens quickly and the results look good. Not sure how much simpler of an API you can get. But to each their own. +1 to choice.
It's not about just simple - it's about making the right architectural choices that don't come back to bite you due to the need to make a change that brings down a house of cards from a library perspective.
ng-bootstrap avoids problematic apis such as component-based modals, and makes use of the much more natural service-based approach to allow developers maximum flexibility. If a developer prefers a component-based modal, a developer can very easily build a lightweight component on top of it. However, having poor design built into such a third party library that is meant to be used for a large variety of cases is a terrible experience for developers, speaking as a consumer and as a library maintainer.
Extensibility is the key here, and we maximize for that while keeping the library as small as possible - bloat is bad, and that shouldn't be the default in general.
I don't think that your service based model is more extensible. Yes, I could build a component based version on top of the service based version. But I can also build a service based version on top of the component based version.
In fact from a peek at the source, the NgbModal class is built on a NgbModalWindow class which acts much like react-bootstrap's modal. So, ng-bootstrap builds the service based version on a component based version. If either library can be accused of bloat it ng-bootstrap for including the serviced based version when I might just want to use the NgbModalWindow directly. (Its not in the documentation, so I wouldn't actually use NgbModalWidnow directly in practice, even if I'd want to.)
Now, I've drunk the react cool-aid, so take my opionion with salt. But in my assesment while modals can be somewhat awkward in the declarative style, they aren't awkward enough to make me break my rule of avoiding imperative apis.
A service based one on top of a component based one has inherent data flow problems. ng-bootstrap, following in the footsteps of UI Bootstrap, takes a promise-based approach because we believe this is clearly the best API pattern out there for dealing with modals from experience working with users' needs. An evented model is extremely cumbersome/awkward, and any component-based model must go that route to signal when it opens/closes. A promise best describes this situation.
How does such a service have inherent data flow problems? Especially since the NgbModal service IS built on a component that implements pretty much the same thing as react-bootstrap's Modal.
It uses components, it is not built on a component - the goal is for it to be able to manage multiple modals and some situations that are impossible to do right with component-based modals such as reusing a backdrop (I argue that multiple modals is a bad pattern, but it is a high demand user feature). It also allows flexibility into hooking into the lifecycle in the future with knowing when the modal renders, starts or finishes animation, and similarly for when the modal closes.
With component-based modals, you end up with bad APIs for these use cases, as well as less control over your state.
Yes, if you build a component based api that supports multiple modals, resuing backdrops, lifecycle hooks, that api would suck and be a real pain to build a service version on top of.
A React component should not be trying to do all that, but merely produce the appropriate HTML for a modal dialog. That produced HTML can equally be used to build one-off "are you sure?" dialogs, a modal service, or what have you.
Yeah it takes 2 seconds to render on my laptop. It's showing docs and examples of every component on a single page. It's convenient to use as a reference when programming. You probably wouldn't code your app like that.
I'm currently developing a mobile app using React (web, not native). And I'm using the regular bootstrap. What advantage does react-bootstrap have? I seriously don't want to learn a new framework.
I wonder what "Final" even means in this context. Google has already admitted that the Angular team uses the term "Release Candidate" to mean something completely different to how every other software company in the universe understands it. (Listen to Adventures in Angular podcast, episode 105.)
Polymer also has a lot of negatives - it still only publishes on bower for example, and the whole vulcanizing situation is sort of bleh. It also uses HTML imports for its components, which is unnatural and sort of munges concerns with the whole ES module import system - this includes importing HTML files for more traditional things such as XHR.
To me, all these things put Polymer far behind the curve as something I'm interested in ever adopting.
bower is pretty much abandoned in favor of npm - in the past 1 - 1 1/2 years, the frontend ecosystem has coalesced around npm as the dependency management tool of choice.
Polymer and Angular 2.0 seems to have a lot concepts in common and I don't fully understand why they are going to compete, given they come from the same source. But for me it seems that Polymer nowhere picked up as Angular.
When it comes to performance it is great in Chrome. In other browsers not so. I hope v2 will be much better once they can get rid of the compatibility layer for other ever-green browsers.
Have you actually benchmarked polymer in a non-chrome browser?
It is much faster than Angular - somewhere around React performance. Polymer is picked up by big companies already whereas "no one"(big) is using angular 2.x for now.
People here seem to project a weird bubble around Angular/React.
> In other browsers not so. I hope v2 will be much better once they can get rid of the compatibility layer for other ever-green browsers.
Browsers get rid of it on their own - when they implement the standards, shims load when specific functionality is found or not.
I'm not comparing against Angular (which in v1 is known not to be super fast) just between browsers. I was mainly looking at https://vaadin.github.io/gwt-polymer-elements/demo/#gwt/Java... . It uses a lot of widgets on one page. Take a look how on loads in Chrome, Firefox, Edge (refresh to minimize network effects). I didn't go really deep in it, but first look was that lots of time was used in registering custom elements. Sure, here it is wrapped in GWT (which would be my case), but it doesn't seem to add much, rather the fact it loads all widgets from Polymer.
But how can you be sure the problem is not in specific element implementation? DBMonster tests show that performance in rendering is ok.
FWIW - I develop on firefox with shady DOM and then test in full shadow DOM in chromium - performance was very good for us in both firefox and IE (at least for the things we used).
A lot of big companies have been using Angular 2 for a while from what I understand. Canon was using it while it was in the alpha stages. Tesla went all in on Angular 2. Thomson Reuters had the largest Angular 1 app in the world, and they are moving to Angular 2.
The Angular team has made significant efforts to court them/cater to them, even employing a CSM, and two developer advocates. Those are just examples I've heard/interacted with in the wild, but I'm just a developer at a small company & not part of the Angular team.
Ofcourse, tons of "enterprises", ING, Comcast, Salesforce, IBM, General Electric, Electronic Arts, (Slack?) and Google (obviously).
There are also tons of components to pick from, someone is obviously building them. We are rewriting parts of RhodeCode UI in polymer right now and everyone is very happy about how that goes.
There are plenty of job offerings on polymer job channel and in the wild.
It just seems that HN folks are ignoring anything that is not called Angular/React because its not hyped enough :)
Youtube Gaming, Google Play Music and IBM's Bluemix are probably the biggest projects built using Polymer. The main Youtube website itself also seemed to be playing around with Polymer.
agree with other comments that RxJS is a tough library to learn but I love that they used it instead of re-inventing that wheel. It is incredibly powerful and solves a lot of asynchronous programming problems. you can see all of the methods visualized with marbles here: http://rxmarbles.com/
Nice, played around with Angular 1 and 2 - Angular2 with its use of components reminded me of making front-ends with the Apache Wicket framework some time ago.
This might appeal to java full stack/backend engineers that need to once in while show case a nice and shiny GUI. It my experience, the combo of Angular with Bootstrap/Font awesome works just fine for that.
Very positive to have static typing through TypeScript as well. But also here I am quite biased for I never liked the concept that 'everything is just a var' ;)
TL;DR: Left Pad is a NPM package that was removed by it's author in protest. Apparently, a ton of other packages broke as it was a major dependency across the NPM ecosystem.
Looking at https://github.com/angular/angular/milestones I was slightly surprised to see 30 outstanding issues. Reading the announcement they have been careful to bring semver into the mix. This should speed up release as well as start bringing through some of the 2.1 stuff quicker.
I'd love to hear the experiences and opinions of anyone who knows about building iOS and Android apps with NativeScript and Angular 2 [1], or who has used NativeScript [2] itself, please.
NativeScript has a JavaScript<=>Java bridge on Android, and a JavaScript<=>Objective C bridge on iOS, like a cross platform version of Apple's ObjC bridge used in OS/X JavaScript for Automation [3] [4] [5] (but AFAIK Apple's ObjC bridge is apparently not available for developers to use as a framework, nor on iOS, nor of course on Android).
Unlike React Native's JavaScript engine, it runs in the UI thread, using V8 on Android and JavaScriptCore on iOS, and you can call all the platform specific APIs directly, subclass and implement Java classes and Objective C classes and protocols, call methods and functions, and pass objects back and forth, write your own plugins in TypeScript, JavaScript, Java, Objective C, etc.
So I have never used Angular before but work with Vue. Looking at the tutorial, why is there the syntax of [(ngModel)] (equivalent would be v-model for me) and ngFor= (v-for)? Why are they different? It looks kind of unnecessary to me. I would really appreciate if someone explained it.
Look at the weekly meeting notes: http://g.co/ng/weekly-notes .
So 3 days ago they were talking about an rc7 to test out and now all of the sudden we've got a final?
You cannot really compare these frameworks because Ember is far ahead of all. Super stable, matured, adopted the best practices, huge addon ecosystem, brilliant community, easy to learn, great documentation. Quite an obvious abd best choice. Life and development is just super easy and fast with Ember.
Nodody mentioned angular universal here. I think it's a big win to prerender the SPA on the server. It's faster, more mobile friendly and pages can be indexed by search engines.
IDEs have to implement better support for NG2 but this will come over time.
That's interesting. I previously researched this with regard to React apps, and the tenor was that server-side rendering was no longer required in order to get indexed by Google.
I have also encountered an Angular 1 app in the wild that was indexed by Google, but there are limits to the ability of their crawler - it apparently didn't follow through to other pages.
Angular's module syntax, while it makes sense, it's just easiest way to get version control merge conflicts. Even easier than import statements... since these can be put into oneliners.
Thanks and congrats to the Angular2 team! We've been building on the release candidates since March, and we're happy to see the breaking changes come to an end.
FWIW as someone who struggled early on with the "How do i use angular with <other technology that i work with>?" question.
It's important to IMMEDIATELY understand that the backend should not matter - so long as it returns JSON (or even XML i suppose) which AngularJS 1.x can consume with $http or $resource (or ng 2.x equivalent).
This is an advantageous pattern in my opinion because the front-end angular application is totally decoupled from the backend (we have separate code repos - and even separate developers) - you can keep the backend as Go, or PHP, or Python - or even a static JSON file with something like jsonserver. So long as the JSON is formatted appropriately and API does what angular expects - angular does not care!
Yeah absolutely same here - I think we would have hit that regardless though whatever lib we used, as I think I recall the CORS stuff is all baked into the browser. So it was really just the growing pains of moving over to a SPA for us.
You don't choose between those two routers, they are not replacements for each other.
At the risk of stating the obvious, the Angular router handles routing for the Angular frontend, the Go router handles routing for the Go backend (the initial page load, the AJAX calls made from Angular to get data...).
We use angular as an MVW for front-end
We use django + django-rest-framework for back-end.
It's important to understand that "routing" in angular is a bit "synthetic" - it's not actually requesting much from the server after index.html loads (it only changes address etc as part of the routing). So the routing is totally separate on the front-end, assuming you are using a back-end to provide the data.
I was really frightened with it. But webstorm from jetbrains has an EAP version which basically shows your compiled JS file "nested" under your typescript file. It's a small seamingly meaningless change that was the difference with me being comfortable with TS vs. not -- screenshot here:
Breaking changes during alpha stage were expected, so I didn't have issues with it.
Most positive things I want to highlight:
1. Components are encapsulated and truly reusable (and without dependencies hell).
2. You don't need any "bridges" anymore to use 3-rd party JS libraries inside your Angular app. Nothing need to be "angularized" - twbs, D3, all just works out of the box. Maybe it's even most important part for me.
3. Idea of `(events)` and `[attributes]` is awesome, works really effective and makes code much more easy to read.
4. Performance is great.
5. Community is friendly and have a lot of fun and patience, even to newbies.
6. TypeScript gives a lot of bonuses with zero price - you don't need to learn anything (you can just rename js to ts and it will work) and additions to JS are simple and powerful.
7. Cool abilities like AOT-compilation, server-side rendering and tree-shaking.
Congrats to the all devs who are using Angular, congrats to the Angular team! :)