2 years with Angular - <AUTHOR> http://www.fse.guru/2-years-with-angular <comment><USER5> I find the rise of Angular kind of baffling.

Angular's scope system is exactly analogous to the scope system of a programming language. This is a solved problem! When you make a scope system, make it lexical, and require explicit declaration before use. If you're not making those choices, then at least acknowledge that these are the standard answers, with very clear advantages over other scoping systems, and explain why you are not using these answers. But with angular, we have a dynamic, implicit declaration scoping system. New scopes are introduced somewhat unpredictably, at the discretion of each directive. I thought that introducing dynamic, implicit-declaration, non-block-scoped variables in 2014 was like introducing a new car with a coal-burning engine, but no one even seems to remark on it.

Then there's the dirty-checking loop. After every event there is a digest; every digest runs every watch. To me, just reading this description makes a voice speak up in my head: "Uh-oh! That sounds like O(n^2)!" Now that angular is being widely used, people are noticing that it's slow as shit. But why did the framework get to this level without anyone remarking, "this dirty-checking algorithm is fundamentally, irremediably not scalable"? Do people not have a sense even for the most coarse performance characteristics of algorithms like this? Or do people simply think that nowadays "performance does not matter"?

Angular's "module" system is the strangest of all. It doesn't do namespacing or dependency tracking. What is even the point of it? What thought process led to this useless module system?

It's just strange. Hundreds of years of people's work are spent on something, which the most cursory, CS 101 analysis shows to be seriously flawed. Is analysis simply a lost art in this industry?

Oh well, people are finally realizing Angular has its faults, because they've seen them with their own eyes and now they believe them. It would be nice if we could learn from this, and maybe skip the next boondoggle (web components for instance), but I have no hope for it.

<comment><USER6> I knew someone who consulted a large bank not to use Angular for financial apps. They were insistent to use Angular until he finally showed them a fairly typical requirement of an app like that in angular: 5 tables with 100 rows and columns. It literally crawled when running on a Dell Workstation laptop.

It is kind of nuts that angular is big.

<comment><USER7> My team is using Angular for an app that contains large tabular data all over the place. We ended up having to rewrite the table generation in jQuery and now we've got a POC in development using React. Most other places we've had to use shims like angular-once to make menus performant. At this point we're building work-arounds for most of the things that makes Angular special.

<comment><USER8> > has perf issues with angularjs

> writes a solution using jQuery

Angular tries to be clever and solve loads of problems, sure tables and table rendering sucks anyways, but a simple querySelector with jQuery is 98% slower than just using normal DOM methods.

If you're gonna write your own bits of code to improve the caveats of any framework, especially in the financial industry, you go full hog and you write it properly.

Fixing an angular problem with a jQuery solution will get you marginal gains. Fixing an angular problem with a DOM solution will get you the best results and it isn't even that hard.

<comment><USER9> _a simple querySelector with jQuery is 98% slower than just using normal DOM methods._

A simple querySelector with jQuery maps directly to a normal DOM method in browsers that support it.

<comment><USER10> apart from the overhead of finding out if the normal DOM method will work - and the overhead of parsing the selector to make sure it's not using jQuery extensions.

</comment></comment></comment></comment></comment></comment><comment><USER11> This seems to be the summary of every tech flame war ever, and applies rather well here:

A: I've used tech X in a lot of Y contexts, and I find it's not great. I will generalise slightly imply that tech X is not the panacea that it has been presented as.

B: Yeah? Well, I've used tech X in a lot of Z contexts, and I find it works fine! You're wrong! You're using it wrong! Maybe you're not wrong in context Y, but for most other contexts X is still the best tech!

C: I haven't used tech X at all, but here's my opinion on it anyway.

<comment><USER12> Amen. Look back 10 years ago and we were having the exact same discussions about mod_perl, php, and java servlets. Nothing has really changed except perhaps for an increase in the number of regurgitated comparisons.

<comment><USER13> Except that php won. As weird as that seems. CGI.pm was removed from the core Perl distro this year. React learned a lot from php/xhp and is easier to use because of it.

</comment></comment></comment><comment><USER14> I've worked on Angular projects of varying sizes -some as large as 30KLOC (products where every page has enough interaction to justify an Angular controller)- and I can never find myself agreeing with these articles.

Have I just drunk too much kool-aid? Or is it possible that with the right team, the right architecture, Angular can actually be a really great framework to use? The common theme for every large Angular project I've worked on is that the teams have leaned towards a more functional design where state is rarely used. This has always seemed to encourage smaller, decoupled modules which don't suffer from many of the problems that the author mentions.

But hey, it's probably the kool-aid.

<comment><USER15> YES! Thank you! I think I'll die if I have to read another developer arrogantly defining what should and should not be, and how he, in all his glory, hereafter defines this framework to "NOT BE WORTHY".

I can't stand how some articles simply s&*t on years of software architecture principles and the work of very talented engineers and simply dismisses them like it's nothing.

If you disagree with a framework's perspective, AT LEAST be respectful.

BTW, I also have used Angular for 2 years and, given the pros and cons and existing alternatives, I will choose it again for my next big project. The structure is simply too solid. This is invaluable when you have a large team that must work together.

<comment><USER16> I am always conflicted about writing about Angular on a negative light because the team has put some great work into it while raising the bar in how rich apps could be built on the web. Being a back-end developer for a long time, it let me build some great interfaces on the front-end really quickly, and I'm very thankful for that.

But we should also learn from where Angular succeeded and where it failed. Making XML declarative is fraught with difficulties. Things like ng-repeat are but a thin declarative veneer over the fundamentally imperative nature of constructing views. The biggest difference between most existing templating frameworks and React is in this world view: is the view constructed imperatively, or is it declared?

The other question of contention is how much implicit magic should the framework supply vs how much explicitness the user should bring into the code. Angular's design decision is to make bindings work magically, while React identifies explicitness as a virtue.

Having used both, I'm liking the imperative+explict camp.

<comment><USER15> Finally, a respectful and well founded analysis. Thank you for improving the quality of the debate.

My 2 cents: I actually prefer the declarative approach. My attempts at imperative view generation resulted in far more shooting-on-the-foot. Naturally, this is the very specific conclusions of me and my team, not the entire human race. I always think you should try both!

Also, I'm a huge fan of Polymer, which is also very much declarative. Going to use Angular instead of Polymer simply because of better project structure and browser support.

</comment></comment></comment></comment><comment><USER17> This post reminds me of these other two [0, 1] that ultimately lead Leo Horie to create Mithril [2], a tiny (5 KB down the line) but complete MVC framework that also eschews most of the criticism raised by the OP.

The Mithril blog is also worth a look, it addresses a lot of concrete scenarios with recipies to solve common front end problems with the framework. For example, here's a post on asymetrical data binding [3].

————

0\. [http://lhorie.blogspot.fr/2013/09/things-that-suck-in- angula...](http://lhorie.blogspot.fr/2013/09/things-that-suck-in- angularjs.html)

1\. [http://lhorie.blogspot.fr/2013/10/things-that-suck-in- angula...](http://lhorie.blogspot.fr/2013/10/things-that-suck-in-angularjs- follow-up.html)

2\. [http://lhorie.github.io/mithril/](http://lhorie.github.io/mithril/)

3\. [http://lhorie.github.io/mithril-blog/asymmetrical-data- bindi...](http://lhorie.github.io/mithril-blog/asymmetrical-data- bindings.html)

<comment><USER18> That framework has its own problems, like you have to wrap all your data structures into the mithril collections/models so that they can communicate with the views.

<comment><USER17> _> you have to wrap all your data structures into the mithril collections/models so that they can communicate with the views._

Only when you need bidirectional bindings, and you're not forced to use the builtin `m.prop()` helpers, you can easily whip your own if they don't work for your use case.

See my last link for an example.

<comment><USER18> Isn't that the whole point though? I mean, discarding existing DOM with forms is a horrible experience.

</comment></comment></comment></comment><comment><USER19> I work at Google, and have been using AngularJS in different projects for about three years. The OP raises a couple of good points (in particular his "The Bad Parts" are mostly valid), but I cannot understand some others, nor do I share his take away.

AngularJS is not a silver bullet or panacea. It has bad parts such as the directives API (making it hard to create reusable components), the global namespacing in the injector, and indeed, the number of watch expressions is an issue.

That being said, internally at Google:

\- we do have well working, shared, reusable UI components based on directives. So it's quite possible to write usable AngularJS modules.

\- There are multiple old (>3 years), large AngularJS apps that do not seem to have major maintenance issues. Maintenance of large code bases (>100k SLOC JS) is always an issue, but if you follow the style guide [0] at least it doesn't seem worse than with other JS frameworks

\- Code is minified and compiled, using Closure Compiler's @ngInject and @export annotations as required.

OP's comments mostly sound like they were burned by not following software development best practices (e.g. throw the prototype away, make sure to properly design your domain model, have a qualified tech lead, have qualified engineers).

His "Lessons for framework (and metaframework) developers" seem generally useful, but unrelated to particular AngularJS shortcomings.

[0] [http://google- styleguide.googlecode.com/svn/trunk/angularjs-...](http://google- styleguide.googlecode.com/svn/trunk/angularjs-google-style.html)

<comment><USER20> This is in an established corp (best practices, standards, workflows etc) - you could build things out of mud and they would still hold. Doesn't say much for/against this particular framework..

</comment></comment><comment><USER21> I'm late to the party, but I want to share an insight I've had regarding game development and UI applications. It baffled me for a long time why building UIs were such a pain, and doubly so in a web app. Why could I, and others, create such seemingly advanced graphics and interactions in a video game, but try to make a UI and you're stuck with thousands of difficult to discover bugs. After I started using react, I realised games are "easy" for the same reason react is a huge productivity multiplier: you re-render the game every single frame. You have the data that represents your game state, there's a game loop, and you render every single little damn thing, every damn frame. It's a one-way flow of information from your explicit state to the presentation layer. React works the same way, only it re-renders only if the state changed. That's it. Super simple, but it's a mind shift.

<comment><USER22> Also you can use a different exotic approach in every game - it's completely open!

In the modern closed web you unfortunately have to deal with legacy tech like HTML, JS, CSS which will never ever go away "because compatibility".

</comment></comment><comment><USER23> I've been using Angular on-and-off in professional settings since 2012. Angular is a framework obsessed with testability that treats usability as an afterthought. That said I've found Angular to be more than flexible enough to meet the needs of your typical CRUD apps, and generally enjoy working with it.

One thing I agree with the author about is the importance of expertise for a successful Angular project. Some specialized knowledge is needed to get a decent fit and finish, and the results can be horrible without that.

Strongly discouraging globals goes a long way towards improving code written by inexperienced engineers, but Angular's provider system is _still_ not clearly documented with practical examples, which makes those engineers more likely to shove everything into the unavoidable Angular constructs (controllers, directives, $scope).

The middling quality and small availability of third-party Angular libraries is a problem. I believe that greater awareness/better tooling for ngDoc would be a tremendous help there. Best practices are not well-presented anywhere in the Angular world, particularly for designing reusable Angular libraries.

The other big problem is the project source code which I find poorly organized and documented. If you want to get into the guts of Angular for debugging purposes, good luck!

<comment><USER24> You say:

> That said I've found Angular to be more than flexible enough to meet the > needs of your typical CRUD apps

The OP says:

> Are there any use cases where Angular shines?

> * Building form-based "CRUD apps".

So I guess you and the OP pretty much agree.

<comment><USER23> The author and I don't agree, except that Angular is not suitable for high- performance frontends (like games). The author suggests that Angular is only suitable for prototyping and that simply using the framework is technical debt. I particularly disagree with this statement: "Accept the fact that you will suffer in the future. The lowered expectations will help you stay happy sometimes."

It seems like the author is simply unhappy to be working in a framework not of his own design: "Create a metaframework based on angular, tailored SPECIFICALLY for your project needs and your team experience!" That's the one thing you _shouldn 't_ do if you want to reuse code between projects.

<comment><USER25> > The author and I don't agree, except that Angular is not suitable for high- > performance frontends (like games).

Would you really use DOM/virtual DOM templates to make a game? it makes little sense. I dont believe any "MV*" framework is suitable for games,even if the game is DOM based.

In a game,what you want is to make sure that at time T,the screen reflects the state of the game.Since you are manually pooling all states with a timer in order to render the game on screen,there is no need for databinding.

<comment> kuni-toko-tachi Actually that is the point :) The virtual DOM is equivalent to how you do write games. Declarative to imperative. React took its cues from how games are written. The renderer in react targets the DOM. React is a renderer.

</comment></comment></comment></comment></comment><comment><USER25> I'm a big angularjs fan butI agree with all the points made by the OP.

I will however stick with angularjs because frankly there is no better alternative.

the selling points for me are:

\- Testing:Karma,Protractor,dependency injection are fundamental when working with a team.Everything is so easy to test,so easy to mock.

\- Speed:Sorry but there is no other framework that makes front-end dev faster.I can come up with very complex apps within hours,fully tested.

\- Resources:20+ books,hundreds of blogs,1000+ directives on the web.

\- Easy to integrate with legacy jquery mess:since jQlite is compatible with jQuery,I can just drop a jQuery plugin in a directive observe something with no effort and have it rendered properly.

The main drawbacks:

\- Dont expect to understand angular without a serious understanding of javascript.

\- Performances: yes there are performance issues,but when they show up,one needs to work on these issues.

\- Probably too much hype.

<comment><USER26> I plan on looking into react and mithril in the coming months

</comment></comment><comment><USER27> While most of the arguments presented in this article are somewhat valid but I hope with the release of Angular 2.0 majority of the issues will be addressed (though does it make sense to make such drastic changes in the upcoming is another debate and already taken care of at: [https://news.ycombinator.com/item?id=8507632](https://news.ycombinator.com/item?id=8507632))

I'm currently working on a comparatively large webapp built in Angular and it was after about 7 months into the project that we started realising it's pitfalls, and it was very difficult to abandon it then.

So we worked it around by: 1) using one-way binding (or bindonce to be exact) to reduce watches 2) avoiding un-necessary $apply() and using $digest() carefully if required 3) using ng-boilerplate for scaffolding 4) defining our own style guides/coding conventions/design patterns to overcome Angular's bad parts 5) frequent code-reviews that made sure new team members are upto speed with the above techniques

luckily we haven't ran into much issues after that :)

<comment><USER28> Angular 2.0 seems to be a long ways off - to the point where the presenters wouldn't show actual code examples in their demos of it at ng-europe.

It rather makes me worry it is going to be the Python 3000 release all over again in terms of how much is changing.

<comment><USER29> > It rather makes me worry it is going to be the Python 3000 release all over > again in terms of how much is changing.

The underlying technology is changing so fast (ES6, web components, mobile web, etc.) that it's going to make upgrading an obvious choice even if it involves relearning a lot of stuff.

<comment><USER27> couldn't agree more on the Python example, I think one of the main agendas for the 2.0 release will be to make it more popular on mobile side of things ([https://www.airport-parking-shop.co.uk/blog/built- app-2-week...](https://www.airport-parking-shop.co.uk/blog/built-app-2-weeks- using-ionic-framework/) is one such example though not from the core AngularJS team) for which they may have compromised backward compatibility infavour of performance.

and also do you think they'll continue with the 1.x releases? since so many developers have already invested time and effort on their webapps and shifting it to an entirely new framework (read release) is a major cost to pay..

<comment><USER29> There is probably going to be at least a 1.4 release. The new 1.x dev team that Google just created talks about their plans for the future here:

[https://www.youtube.com/watch?v=LG9VkCDbte0&feature=youtu.be](https://www.youtube.com/watch?v=LG9VkCDbte0&feature=youtu.be)

They say the exact plans for how long they are going to support 1.x won't be finalized until after 2.0 gets released, so that they have some idea of how difficult it's going to be to migrate.

</comment></comment></comment></comment></comment><comment><USER30> _disclaimer: I 'm the author of Mithril.js_

I've also used Angular for around 2 years for a large application. This article resonates pretty accurately with the problems we were running into before I decided to write Mithril.

It can certainly work well (heck, the mobile part of our app was doing just fine because it was specifically designed to be a trimmed down version of the much more powerful desktop app), but performance problems aren't necessarily because people don't know how to use Angular. In our case, performance problems usually became obvious when we had UIs for editing large volumes of information, and large volumes of information did appear on the page. Two of the examples that we were running into problems with were a work breakdown structure UI, and a scheduling UI, which are far from being things-you-should- not-be-doing.

The team scalability issue is real, but I think it's not entirely Angular's fault per se. My general experience w/ co-workers dabbling w/ Angular was that they were accustomed to jQuery in terms of discoverability (i.e. if you don't know jQuery, you can fake it w/ Google-fu until make it). Getting into Angular is not like that at all. There are lots of places where you can shoot your foot if you don't do it the right way (tm), and deadlines _will_ trump doing it the right way if the right way is sufficiently non-intuitive. You can blame that on teams not having good processes or good developer or what have you, but hey, that's the real world for ya.

My main problem with Angular is the error messages. Imagine writing this:

        $(".foo").each(function() {
          this.addClass("bar")
        })

But instead of throwing a familiar native js error on line 2, you get an asynchronous ReferenceUnboxingException on line 3475 of jquery.js and your code is nowhere in the stack trace. That's what a lot of Angular errors look like (when they do show up, because null refs from templates don't).

<comment><USER31> Big Mithril.js fan here !

Mithril.js seems like something I would study in my maths class (its a good thing). I have spent a good amount of my last year trying to get better at angular and wasting a large amount of my time. Angular.js has seriously colored my image about google's engineering poweress.Looking back I put my intuition and education at the back seat - due to my own insecurity of my intelligence - google must be better than me right ?

</comment></comment><comment><USER32> Maybe I'm old fashioned but Angular just does too much for me. In fact many frontend frameworks simply do too much for me. I like to structure my web applications in a very minimal way.

I like having one layer that covers the UI display and UI events. This layer does nothing beyond styling, setting up the UI and using messages to pass back events in a generic way.

My business logic handles generic events. So say I have a button for saving, in my UI layer it registers the click event but then sends a generic message with a payload that is simply "Save". The business logic then saves it. This let's me drastically change any of the UI with zero affect on my business logic.

I wouldn't recommend it yet for production (very early) but I'm working on a small library that does much of this messaging and binding of messages directly to DOM objects. [https://github.com/KrisSiegel/msngr.js](https://github.com/KrisSiegel/msngr.js)

<comment><USER33> Question: I also like a minimally structured app. I've experimented with Backbone.js. Have you tried it? Did you decide to go with msngr.js after using Backbone?

I feel like I spend a lot of time trying frameworks, only to find very little benefit. Happy to learn more, but would love to have some basis of comparison to some tech I've worked with to date.

<comment><USER32> Backbone looks interesting and I've worked on projects that used it but honestly I've never really taken a hard look at it nor had to make huge changes with it to really have a good opinion one way or another on it. I mostly started writing and using msngr.js because I love messaging and I didn't see anything that did exactly what I wanted to do (and even if I had found something I still may have written it anyway as I've learned quite a bit in doing so).

</comment></comment></comment><comment><USER34> Angular is a result of the over-engineering that is endemic to web development right now. Programmers are taking strategies designed by Google and Facebook and places that actually need the high level of conventions prescribed by software like Angular and applying it to their personal blog, their half-done only on github "startup," etc.

JavaScript isn't really a good place to adopt convention - you're dealing in a mixed-code environment almost from the start, speed is constantly an issue if you're doing something complex, and there's no such thing as "one size fits all."

I've looked at almost every JavaScript framework out there, and they really don't offer much more than what you would get out of a very lightweight jQuery (or your library of choice) abstraction. I want very much to find something that is as useful as the programming friction it introduces, but I haven't really found anything that meets that criteria yet. React seems to be very good at face value, but in general it isn't saving you nearly the amount of code that you might hope it does. Ember is probably the best at this, but it has its own tradeoffs (namely speed).

</comment><comment><USER35> I can't speak of Angular since I haven't used it but one problem that is recurring with use frameworks, in general, is that thinking or getting used to "their" way takes a significant amount of time and seeing the continuous change of technology, I am not sure that time is justifiable in the longer run.

Take example of rails. I was trying to learn it sometime ago and was really amazed how it has a process for nearly everything. Migrations, asset pipelines, generators, and very extensive command line. Sure it does make it seem like "Once I learn it, it will be so much easy to make the next app" but it is easy to realize after sometime that you have to cross usual hurdles of Googling everything, learning these processes, facing issues, digging out new ways of debugging to finally be good at it.

My idea is that frameworks should be minimal which only ensure a basic working architecture and everything else should be extensible (via packages).

<comment><USER36> There's a term for minimal frameworks: libraries.

Ultimately, you should control the architecture of your application. When this is the case, you can develop abstractions around libraries that shield the rest of your code from their bugs, 'conventions', and error handling strategies.

</comment></comment><comment><USER16> I recently wrote about my experience with Angular in a different forum. Sharing it here:

I worked on Angular last year building an app with a few complex views. The initial days were full of glory. Data-binding was new to me, which produced much goodwill towards the framework.

Things started falling apart as I had to inevitably understand the framework in a little more depth. They practically wrote a programming language in the bid to create declarative templates which knows about the Javascript objects they bind to. There is a hand-rolled expression parser ([https://github.com/angular/angular.js/blob/v1.2.x/src/ng/par...](https://github.com/angular/angular.js/blob/v1.2.x/src/ng/parse.js)), new scoping rules to learn, and words like transclusion and isolate scope, and stuff like $compile vs $link.

There is a small cottage industry of blogs explaining how Angular directives work ([https://docs.angularjs.org/guide/directive](https://docs.angularjs.org/guide/directive)). The unfortunate thing is that all of Angular is built on directives (ng- repeat, ng-model etc.); so till one understands it in depth, we remain ignorant consumers of the API with only a fuzzy idea of the magic beneath, which there is a lot of.

The worst however was when we started running into performance problems trying to render large tables. Angular runs a $digest cycle whenever anything interesting happens (mouse move, window scroll, ..). $digest runs a dirty check over all the data bound to $scope and updates views as necessary. Which means after about 8k-10k bindings, everything starts to crawl to a halt.

There is a definite cap on the number of bindings that you can use with Angular. The ways around it are to do one-time binding (the data won't be updated if it changes after the initial render), infinite scrolling and simply not rendering too much data. The problem is compounded by the fact that bindings are everywhere - even string interpolation like `{{startDate}} - {{endDate}}` produce two bindings.

Bindings are Angular's fundamental abstraction, and having to worry about its use due to performance issues seems quite limiting.

Amidst all this, React feels like a breath of fresh air. I've written a post about what makes it attractive to me here: [http://www.jasimabasheer.com/posts/on- react.html](http://www.jasimabasheer.com/posts/on-react.html).

Compared to Ember, neither Angular nor React dictate as rigorous an organization of files and namespaces (routes, controllers, views), and have little mandatory conventions to follow. But React is as much a framework as Angular is. The event loop is controlled by the framework in the case of both, and they dictate a certain way of writing templates and building view objects. They can however be constrained to parts of the app, and so can play well with both SPA and non-SPA apps. The data models are plain Javascript objects in both (it is not in Ember), which is really nice.

Google recently released a new version of their developer console ([https://console.developers.google.com](https://console.developers.google.com)) which is built on Angular. So the company is definitely putting their weight behind the framework. However, Angular 2 is not at all backwards compatible. That was quite unexpected. If I had known this going in, I would have never used it for the project. But it felt like such a good idea at the time...

<comment><USER25> > But React is as much a framework as Angular is.

Sure,the difference is React doesnt tell you how to organize your application.AngularJS does,you have to use dependency injection.I like it,some people dont.

AngularJS is in no way perfect.But compared to other frameworks,Ember,Backbone,... In my opinion it's better.

I personally dont like React because of JSX,I dont want to have to learn a JS superset,and i'll probably wont like AngularJS 2.X because of atscript either,wether it's mandatory or not(understanding exemples on the web will make it mandatory).

<comment><USER16> You can use React without JSX. It is especially easy if you are using CoffeeScript which makes the syntax quite terse.

I personally like JSX. It is more of a variant of Javascript that lets us mix HTML into JS seamlessly. It was inspired from XHP ([https://www.facebook.com/notes/facebook-engineering/xhp-a- ne...](https://www.facebook.com/notes/facebook-engineering/xhp-a-new-way-to- write-php/294003943919)), a PHP extension developed and used by Facebook that lets PHP understand XML. I think that the cross-pollination of this idea into React might be one of the best things to have happened to front-end development in the recent past.

JSX is different from HTML in a few simple ways ([http://facebook.github.io/react/docs/jsx-in- depth.html](http://facebook.github.io/react/docs/jsx-in-depth.html)):

\- All HTML attributes are written in lowerCamelCase, like so: contentEditable, maxLength etc. React has a wonderful "is this what you meant?"-style warning system for when we slip-up on these details. More on HTML attributes in JSX is here: [http://facebook.github.io/react/docs/tags- and-attributes.htm...](http://facebook.github.io/react/docs/tags-and- attributes.html)

\- You can't use `class` to denote CSS class names. It is always `className`. You are going to forget this as you copy-paste a FontAwesome icon definition or Bootstrap snippet into the project and wonder what went wrong. But practice makes perfect.

\- If you want to write inline styles, the style attribute should be written as a Javascript hash (it is actually a blessing in disguise). React documents it here: [http://facebook.github.io/react/tips/inline- styles.html](http://facebook.github.io/react/tips/inline-styles.html).

I haven't found any other incidental quirks in JSX, and it integrates nicely with Javascript in practice. It is however different from the way things have always been done, which can be a good reason for resistance.

<comment><USER25> Sure,but you need to learn JSX to read code exemples around the web.So you cant really use React without knowing JSX.

That's a subtle thing but important enough when you're working on big projects.

<comment><USER37> Sure, but if you can read HTML and you've read the above list of caveats: congratulations, you can now read JSX. The attributes are simply passed to children as props. There's really not much to it.

</comment></comment></comment></comment></comment><comment><USER38> I'm currently enjoying angular after having spent a year and a bit working with it exclusively. I am keen to try out Flux and Mithril, but I've not had the time nor the opportunity. But as it stands, we're deploying several large projects into very demanding organisations that are stable, performant and easy to manage. We as a team owe lot to Angular in terms of our productivity. We're also a great team and that counts for a lot too.

The thing I would like to add to the debate is this: We've all learned that Angular is hard. It's a complex beast with it's own nuances and idiosyncrasies. It also offers plenty of ways to do things you probably shouldn't do (i'm looking at you expressions). But more than that, with Angular in the tool box, people push themselves to deliver products vastly more complex than would be feasible without it. And these two issues collide all the time. Learning a framework + the desire to deliver more; One should follow the other, but people tend to attempt both at the same time.

I personally don't think there's anything "wrong" with Angular, but people have to acknowledge that despite the marketing hyperbole, learning Angular means setting out on a long and difficult journey that will require the developer to rethink a lot of what they know about building web stuff. But that's web development in a nutshell. It's a different gig every year, and within an alarmingly short amount of time, Angular will probably be replaced with something better suited to the tasks that try to accomplish the thing we want to accomplish with mere HTML, CSS and Javascript.

There's also a lot to be said for how you organise your projects and what tools you use (eg Require or Browserify etc etc), but that's a very different kind of conversation.

</comment><comment><USER39> I'm really disappointed that not only is this article on Hacker News, but it's currently at #1. The article contains almost no substance at all.

Angular's a controversial topic. So if you're going to write a long blog post picking a side, you really need to back it up with examples and offer alternatives. The six part "detail" posts aren't much better.

<comment><USER40> I was hoping to read some examples and alternatives as well.. Presenting a problem without examples to back it up or a solution is just ranting. That's fine, but its just less productive.

</comment></comment><comment><USER41> I confess I am an Angular fan.

But this article is not Angular specific at all, it stays on a very high- level. Replace the word Angular with any other web framework and the article would still make perfect sense.

Not that the article does not have some value, just that it has very little to do with its title.

<comment><USER42> NOTE: Haven't used AngularJS and only scraped the article. But Rails for example, doesn't have a namespace problem, because ruby modules provide a namespace and prevent name clashes easily.

That said, I'm not sure Rails and AngularJS are _direct competitors_ as many apps use a combination of both frameworks or more generally Rails + JS- framework.

<comment><USER43> Rails and Angular are apples and oranges. Angular isn't a full-stack framework, it's a client-side framework that handles data source interfacing and view updating.

</comment></comment></comment><comment><USER44> I totally disagree.

I've spent the last year working on a complex and widely-used site that is built with Angular. It is maintainable, performant, has a smooth UX, and is mobile-friendly.

I'm usually extremely cautious about relying on frameworks for long projects, because easy setup doesn't matter after you've been working on something for a year. In our case, using Angular was the best choice we could have made. I would absolutely not replace Angular with my own in-house MVC, even if you gave me a year to develop it.

-The testing tools are some of the best I've used, and hugely contribute to making the app easier to maintain

-It's not as much of a framework as a set of tools. Angular mostly stays out of the way and mostly allows us to structure code to match our needs

-You _absolutely_ need to have top-notch developers, and ideally someone experienced enough to mentor people on the team who are new to Angular. There are a lot of JS developers who are former Flash designers who learned how to use a few jQuery plugins. If they don't know the fundamentals of programming really well, they will make a huge mess of the project.

-We've definitely run into performance problems, but they're manageable. We've had to write code that bypasses Angular's digest cycle, but it feels similar to writing a bit of inline assembler in a C++ program. I wouldn't stop using C++ because of that.

</comment><comment><USER45> I've been using Angular for a SaaS for 7 months, the project is launching in about a month from now.

It is not just a CRUD app. It has:

~170 views ~70 custom directive ~100 controllers

Many directives can execute on the same page.

A single page can have multiple tabs, forms, modals, charts.

I hit some situations where performance dropped a lot but if you take the time to benchmark and test you can fix it.

The key to keep it stable is to load the UI (directive) when you need it and destroy it when you are done.

Personally, I've not found any serious issue so far.

</comment><comment><USER46> I've actually never used any javascript framework. It is stuff like this that drives me away. If you pick any one framework, you get half of a crowd telling you that it sucks, and then a year later your version is now deprecated/replaced and you get to re-do everything again. I've attempted to avoid the whole web-app scene, but with the current job market, looks like one has to know one of these frameworks...

<comment><USER47> Angular got a lot of its popularity, I think, from people with a similar mentality as you. Since it had the Google stamp of approval, it was seen as being more stable. Unfortunately, this was not actually the case.

I say, be thankful for the flux currently underway, and realize that it will result in some really good tech when it's all sorted out. Until then, either get used to learning new things, or leave front end dev to the professionals.

<comment><USER46> The irony is angular was going to be the framework I learned the next time I had free time. Now I am not so sure.

</comment></comment></comment><comment><USER48> If Angular is not The Thing (a premise which I have no trouble believing), then what is a Good Thing to perform the task of, for example, consuming Django Rest Framework endpoints and making a frontend of them?

<comment><USER49> IMHO Good Thing is to have set of libraries and not a framework at all. Start with handcrafting all HTML,CSS with interactions you need. You HTML skeleton will depend greatly on what you want to achieve - like when one page changes to other and theres a ajax call between - where you put the wait screen: as separate, on old page, then wait, transit to new at once, then wait and so on. If that is done you know broadly what you need. Example configuration may be React for rendering, cherry picked Model (or State) from Ampersand, Backbone Events Standalone for event bus. Something for History/routes too, can't recommend anything specific because my projects did not had one (yes, you can build web-app without back button support). This way if something better comes up, you can switch, if something is abandoned, gets your way, you can switch. Or you can rewrite it in-house fairly easily. I imagine that when you discover that React is too much, too heavy, too bloaty (for example, i'm not saying, that it is, we are happy React users now), then preserving all API calls and replacing it with few lines of Mustache templates is doable. Not trivial, but doable.

<comment><USER36> Meta: digging the downvotes in lieu of actual discussion here. Stay classy.

<comment><USER50> The comment above yours is a giant, unbroken paragraph of dogma. I'd say it's worthy of downvotes.

</comment></comment></comment></comment><comment><USER51> I've got to build an SPA and I'm trying to choose between Angular and React, can you guide me a little, the app will :

\- create a big form based on an XML schemas, the form will be used to generate valid XML with the schemas

\- some schemas can be really big with more than 3000 elements, the whole thing won't be shown in full to the user directly but probably folded

\- because it is based on XML Schema, it must have interactivity to make some elements repeatable, and groups of nested elements repeatable, some elements with bounds, some maybe draggable to reorder them, everything an XSD can do...

\- it will also some kind of polymorphism where you can choose the children element type and have the corresponding schema showed

\- it will also show a leaflet map, with some interaction between the form and the map

\- there is also a rich text editor where you can arrange xml objects between formated text

I fear that angular won't be fast enough for that, but his support for forms seems better, I've tested JsonSchema forms generator like [https://github.com/Textalk/angular-schema- form](https://github.com/Textalk/angular-schema-form) and [https://github.com/formly-js/angular-formly](https://github.com/formly- js/angular-formly) the first one is slow when editing 3000 items the second seems fast when editing, and slow when it generates the json. I've done some angular tutorials and their concepts don't stick in my head. I've tested React and their concept stick easily in my head but there is less native support for forms.

I had just decided to go with angular partly because of all the hype around it, but I see the article and others as a bad omen and I want to go with react now. Any advise ?

<comment><USER16> Angular will force you to convert all your rendering logic into its declarative API: ng-if, ng-repeat, ng-include etc. With React, you can simply write your program logic in Javascript and compose, reuse and pass around parameterized components with ease.

Try building a simple nested tree in both Angular and React to see how both feels.

Khan Academy has open-sourced their QA builder that supports creating questions and answers with graphs, radiobuttons, multi-selects, images etc. It is built in React. Take a look here: [https://github.com/Khan/perseus](https://github.com/Khan/perseus)

<comment><USER51> Thanks, the idea to use code instead of a limited set of declarations to create the view is convincing.

<comment><USER52> And now we go around in circles. ASP and classic PHP were the forerunners of using code to do the view!

<comment><USER26> That is very, very different, and you know that : p

</comment></comment></comment></comment></comment><comment><USER53> We built a pretty complex app with Angular ([https://slimwiki.com](https://slimwiki.com)) and have had nothing but great experiences. The main issues are no guidelines about the right/wrong way to do things, it needs to be more opinionated.

<comment><AUTHOR> That's been my biggest problem with Angular too; I'd love some more opinions.

</comment></comment><comment><USER54> I think people are failing to see that not all apps are huge monolithic applications; for most of those apps Angular works just fine.

In fact we should be striving to get away from all of those monolithic code bases as much as we can. In the cases where we can't get away from that then we should be going with tried and trusted methods of building those apps and probably relying on the server a hell of a lot more for those kinds of really large/enterprise/corporate apps.

Most use cases for angular are to make a web app that pulls and pushes data from some Restful service. Angular lets us take that web app, through cordova/phonegap/etc, and wrap it into a mobile ready application that you can push to an app store.

Whats wrong with that?

<comment><USER47> Cordova has nothing to do with angular. Why do you bring it up? In fact, angular is probably one of the worst possible frameworks to wrap into a mobile app, because of its abysmal performance.[1]

[1] [http://matt-esch.github.io/mercury-perf/](http://matt- esch.github.io/mercury-perf/)

<comment><USER55> That's an older version of Angular being compared against - lots of perf improvements have been made since.

</comment></comment></comment><comment><USER56> Sorry, did I miss the part where the author explained the "right (tm)" way to do things these days?

Seriously though, I've used Angular just as long as the author and for the most part I wholeheartedly agree with the complaints (and I have complained myself for some time). However, what is the "better" way? People keep throwing out things like React, but React solves much less for app developers. Also, that answer doesn't help the countless people who began app development more than a year or so before React was released.

The Javascript ecosystem is evolving constantly and yet in some ways not much at all. Throughout that time, I've found that just about everyone can find excellent reasons not to use the various frameworks and libraries but few offer concrete recommendations in exchange for these criticisms. It's disappointing.

At this point in our own project, like many others I assume, we are reconsidering Angular. Not simple because we don't like it, but because clearly the Angular team doesn't either. Angular 2.0, like Sproutcore 2.0 before it, appears to be a complete rewrite. (Rightfully so.) As a result, we plan to examine our other options in detail while our work is still mostly in the prototype territory.

Right now however, I don't think I've seen anything yet, that makes sense for most people who've started out with Angular to do that re-write. I'm hoping as I spend more time examining this I'll find I'm wrong.

I've had many people ask me what framework they should use for new projects and every time I've said, it probably doesn't matter use right now, but be prepared to fully rewrite things in a year or so. The JS ecosystem is in so much flux right now that you can't count on any of these choices being the right one in couple of years. I've accepted that reality for now.

People hate this answer. They tell me that no PM/Exec is going to want to hear that. Fine, don't tell them. The silver lining is that whatever does comes to save us will hopefully be so much more productive than what you were doing before you won't care about rewriting it, you'll do it because it actually makes sense.

Let's all hope that's true.

<comment><USER47> Try vue.js. Same general idea as angular, way less bs. However, the author did just get hired by meteor, so that is something to consider.

</comment></comment><comment><USER57> The problem is not Angular specific, every Framework is designed to solve a certain problem in a certain way.

But most developers think, that when they learn once a Framework, they can use it for any kind of project.

When i read "xxx is really cool and fun" iam really careful. Most people create a "Hello World" and then THEIR favorite framework is the greatest thing in the universe and they communicate it to others.

Take a framework, live with the mistakes, until the next "better" framework appear... and it will appear, and the next, and .... ;)

</comment><comment><USER55> I also have been using Angular for my entire professional developer career, which in a few days will hit 2 years.

This article is pretty accurate for the most part, although some of the minor complaints are not quite so accurate.

Performance is something to be careful about, but the Angular team has worked hard at improving it and it has improved immensely with 1.3 - <USER2> such as bind once & $watchGroup and optimizations around the $digest cycle and $watch make it a huge improvement over 1.2. I want to say there is a chart floating around showing over 30% improvement.

As far as frameworks go, I believe Angular is the best we have currently. It does a lot for you without getting too opinionated in general, and some of its tooling is just flat out better than much of what you can find in the wild.

I have been experimenting with Polymer lately though with an eye towards web components - there is a lot of change coming in how we will have to structure our code. I suspect that those using React will also not be shielded from the pain of integration with ES6 and web components as well, and so I have been hesitant to recommend it in a core product. Ember claims they will make the breaking changes slower, but I also suspect that it will limit its growth as well.

Frontend seems to be rolling on as fast as ever - I don't see much of a way around everyone having to scrap their code regardless of the major library chosen for their projects. I'm hoping the pain dies down once ES6 and web components becomes the norm though.

<comment><USER58> I wouldn't recommend either Polymer or the current development version of Angular 2.0 for a production application just yet; Polymer leans heavily on the unfinished web components standard and other experimental and unimplemented browser features, and Angular 2.0 is still under heavy development. I also gather they're either going to use ES6-but-with-extras- because-we-can, or with AtScript, ES6-with-types-because-why-not. I can't say I agree with those motivations (and I'm sure I've got it wrong), and I quite like the more vanilla JS feel of Angular 1.x.

Anyway, my point is, both of those aren't production-ready.

<comment><USER55> Oh, I agree about not moving to either for a major project currently, although I'm probably going to use Polymer for a small static site project I'll be starting in the next month or two - web components are supported in Chrome currently (shadow DOM and custom elements at least - not sure about the data binding part yet), and Polymer's platform.js makes it very easy to polyfill the missing functionality.

I suspect Angular 2 will be the best we have once it comes out, but I also question some of the decisions made from certain perspectives. At least they're listening to the community, evaluating the feedback and suggestions, and incorporating it into their decision making though, such as the change with the HTML templates.

</comment></comment></comment><comment><USER59> As someone who has thus far only used with Angular for smaller projects, seeing performance raised as a concern is a bit of a concern for ever using it in a serious project. Would still like to see some numbers to back up the anecdotal evidence.

It's also hard to motivate starting a potentially large project in Angular right now, knowing that v2 is on the way that is basically a new framework.

<comment><USER47> [http://matt-esch.github.io/mercury-perf/](http://matt-esch.github.io/mercury- perf/)

</comment></comment><comment><USER60> The thing I really like about Angular is it makes composition of complex ideas relatively easy. The encapsulation and dependency injection is perfect way to allow you to be as structured or unstructured as you want / need to be.

I can understand how someone coming from more traditional frameworks, and working in an environment where you are rarely or never required to think outside the box, will have difficulty making the transition.

Where I personally think Angular could be better (yet was state-of-the-art when it originally came out) is with directives. Now, I'm not talking about run-of-the-mill directives that are easy, that implement relatively straightforward concepts. I'm talking about highly complex functionality that you want to encapsulate into a single "thing" in your code. I think Polymer is going to fill that gap. That being said, Angular team has already (if it hasn't changed) decided they're going to be moving forward with Polymer.

Personally I think Angular + Polymer is going to be hard combination to beat.

</comment><comment><USER61> "And whar are no-no factors for angular?

        Teams with varying experience.
        Projects, which are intended to grow.
        Lack of highly experienced frontend lead developer, who will look through the code all the time."

I am greatly interested in learning what is the alternative that would be a 'yes-yes' in these bulletpoints.

<comment><USER62> This kind of distorts the issue here. The problem is not lack of highly skilled devs but rather the fact that you _need_ highly skills devs to digest and maintain the level of complexity that Angular produces.

I'm big believer on light frameworks that does least amount of abstractions and can get out of way if you need. You definitely want to avoid frameworks that claims to abstract everything away and especially those that requires to learn entirely new way of doing pretty much everything and its own world of lingua franca. My preference therefore gravitates towards lighweight stuff like KnockoutJS and likes. Any average dev can understand KnockoutJS in just hour or two. More importantly, most devs can immediately have intuitive understanding of how things work under the hood and therefore can anticipate performance issues or easily extend it.

<comment><USER58> You don't need highly skilled devs, you need a disciplined team - which should review each other's members' code, stick to a style guide, research best practices, etc.

Like with every software development, actually.

</comment></comment></comment><comment><USER63> "2 years" and "10 projects" \- 2 months for each project? And he talks about "big enterprise apps"? lol.

Please links to examples of your code, author.

I wonder how people can't understand all the power of the 'directives' approach it's the MOST powerful thing in web development now and only advice I can give to future inventors of new frameworks: implement 'directives' concept, and then do everything you want else. It's advice after my 3 years with Angular, and counting ;)

Reusable code and TDD is the key for growing apps and directives - <USER3> successful following of this way.

\---/ please news.ycombinator, treat new line symbols as new line symbols and use ANY modern framework to make this site less slow and more mobile friendly

</comment><comment><USER64> All of the frameworks suffer from performance issues. Performance will get better, but we will always have to profile our applications. A slow web component used in a ng-repeat scenario will always bring the application down to its knees. We can't just design a spaceship and expect an engineer to build a performant application. Designs need boundaries and guides as performance is one if not the most important factor of the UX. We also cannot reason with the jQuery spaghetti demon. Practice some Feng Shui, write better code. Understand whats going on in your framework. Work through the limitations with your designers. We are at the mercy of limited computation until our browsers give us more, and there is no magic bullet.

</comment><comment><USER65> It's fair to highlight the less-ideal parts of AngularJS, but IMO the ecosystem and testing integration is as important as the framework code itself. Most of the issues the author mentions can be mitigated (eg. use ui- router).

The momentum behind AngularJS is huge, and with the 1.3 release I feel like 90% of webapps can be written well in Angular. Ionic is a great example of pushing AngularJS to the edge with mobile applications.

It really is up to the team to enforce good practices, pair or review code and refactor and unit test components. There is no framework which can make this happen, you need to be disciplined and always look to leanr more and improve the code you have written.

The author certainly does not recommend anything else, so where to now?

</comment><comment><USER66> I feel somewhat conflicted about this blog post. I can agree with what others are saying in the comments that all frameworks have there pitfalls. A lot of development is dealing with trade offs and your teams varying experience.

On the other hand, I agree with the author that there is a tipping point where a framework/tool becomes too much of a burden. Sure, we can all do it the "right way" but teams don't always have people with the experience to even know what the right way is.

We should think about the frameworks we use as tools. Make sure the tool is right for the problem and the team. Also, don't try to apply all your older experience to the new tool. Take time to learn about the thing you use.

</comment><comment><USER67> You know, I'm just going to say it:

Angular is the Rails of Javascript.

That probably sounds like a derogation. But behold: I offer nuance!

They're both big and powerful, and capable of rewarding dedicated study with enormous power. Thus they develop a devoted following whose members often do things lesser mortals find little short of wizardry.

They're also both built to be friendly and welcoming to the newcomer, and offer a relatively short and comfortable path from zero to basic productivity. Thus they trigger the "I made a thing!" reward mechanism which excites newbies and leaves them thirsting for more.

They also, in order to go from newbie to wizard, involve a learning curve like the north face of K2.

In both cases, it's a necessary consequence of the design decisions on which the platform is based, and those decisions, by and large, have sensible reasons behind them -- not, I hasten to note, decisions with which everyone will (or should) agree, but decisions which can be reasonably defended.

But that doesn't make it a good thing. When people start off with "I made a thing!" and then run smack into a sheer wall of ice and granite, initial excitement very often turns into frustration and even rage, as on display in some comments here in this very thread.

(I hasten again to add that I'm not judging anyone for being frustrated and angry over hitting that wall -- indeed, to do so would make me a hypocrite, given my reaction to hitting that wall with Rails a year or so ago.)

Further compounding the issue is that, often enough, wizards who've forgotten the travails of their ascent will condescend to say things like "Well, what's so hard? Just read {this book,that blog post,&c.} and it's all right there." Well, sure, for wizards, who are well accustomed to interpreting one another's cryptic _aides-memoire_. For those of us still toiling our way up the hill, not so much.

I will note, though, that while I hit that wall (hard!) with Rails, and in the end couldn't make it up, I haven't had the same problem with Angular. The sole significant difference I can identify, between the two attempts, is this:

When I took on Rails, there was no one else in the organization who knew (or should've known) the first thing about the platform. When I had a problem with Rails, I faced it all alone, with only my Google-fu, my source-diving skills, and my perseverance on which to rely. For a while I did well, but in the long run, for all but the most exceptional engineers, such expenditure of personal resource without resupply becomes unsustainable.

When I take on Angular, I do so with the support of a large team, composed of the most brilliant and capable engineers among whom I have ever had the privilege of working. When I have a problem with Angular, I have a dozen people at my back, at least one of whom is all but guaranteed to have encountered the exact same situation previously -- or, if not this precise permutation, then something very like it, from which experience more often than not comes precisely the advice I need to hear, to guide me in the direction of a solution.

Of course, whether this is really useful to anyone is an open question; I think it's a little facile, at least, to say "Oh, if you're having Angular problems, all you have to do is find a team of amazing people who mostly all have years of Angular experience, and work with them!" But, at the very least, if you're going to be fighting through the whole thing all by your onesome, maybe think about picking up a less comprehensive but more comprehensible framework, instead.

<comment><USER68> My opinion of Angular is now that it's basically the equivalent of PHP (if we're comparing it to other languages.) PHP is super easy to get started with and is magical and with enough forethought and planning, proves to be a serviceable language suitable for small projects.

However, if you don't draw lines in the sand for yourself and watch performance very carefully as you scale, your app will suck. For reasons of maintenance or user experience, it will suck.

It's awesome for tiny projects or things that won't need to be changed or internal use stuff. I personally am using it to build a prototype of a product. But I'm planning to convert this prototype very soon to React or Meteor.

<comment><USER67> Comparing Angular with PHP doesn't strike me as entirely fair; Angular, whatever else one might say about it, has a high degree of conceptual consistency in its internals, whereas PHP, for all that it's improved over the past few years, remains an utter farrago and likely always will. Comparing Angular with Laravel might be more reasonable, but my lack of knowledge of the latter framework forbids me from commenting further on the comparison.

</comment></comment></comment><comment><USER69> I really think that the bigger the app gets the smaller the framework should be. If it lacks functionality, it should be possible to easily add it using the frameworks core functionality.

IMHO in general the core functionality of a clientside framework is to provide a way of structuring the app and allow for communication between logical units that are nestable and modularized.

If a basic framework does that, and only that, it should be bulletproof. I admit, it took me 10 years to rethink and recode this over and over - <USER4> there is no end in sight.

I love this discussion, it reflects much of my thoughts about the issue.

</comment><comment><USER70> I really resonate with: "Do not make things easy to use, make your components and abstractions simple to understand."

And not only for AngularJS but as design principle.

</comment><comment><USER6> I am not a lover of angular, but the reason angular is so popular is because it gets the prototype out there.

So many things and places are just doing things "lean" and "iterating" so angular makes that easy.

I'm not sure anyone could tell me Angular isn't __very __productive and that it wouldn 't be tempting to use it so you can get some fairly magical experiences for users and in demos.

</comment><comment><USER71> So if not Angular then... what? If I wanted to do a single page app with REST backend (little to no db access), what would you recommend?

</comment><comment><USER72> I've been using Angular now for a year and half, and a year professionally. The only issues I've run into are pages with large data bindings. I would love if the Angular team could recommend a solution other than "don't do that." That answer is simply unacceptable in my opinion -- their silence on this topic has been very frustrating.

<comment><USER73> Take a look at step by step example improving angular web app performance: [http://bahmutov.calepin.co/improving-angular-web-app- perform...](http://bahmutov.calepin.co/improving-angular-web-app-performance- example.html) I think any framework or library could suffer from these problems.

</comment></comment><comment><USER22> "5 star performance requirements" \- Scala Play comes to mind rather than any JS MVC frankly speaking.

</comment><comment><USER74> I don't mean to be a jerk, but this article is really poorly organized.

</comment><comment><USER75> As author says in the comment, these are valid for Angular 1.x so I'm hoping that angular 2.x will be more carefully designed framework.

</comment><comment> kuni-toko-tachi AngularJS owes it success to an easy onboard that allows a user to easily create a gimmicky two-way binding demo. And then the pain begins.

It matters little whether some find it productive, what matters is that the engineering principles it is based upon are fundamentally unsound.

Control and conditionals in attributes are absurd. Especially when they require learning an expression language unique to that framework. Especially when they create side effects. Why should something as simple as a loop or if create a new controller and scope? This is absurd. The expression language is not statically analyzable to boot.

There is no reason for a framework to do anything beyond handling the last mile tranform between view model and DOM. Everything else can be done through JavaScript and modules.

JavaScript is a wonderfully expressive language, reinventing that through some hacked up expression language makes no sense and buys no advantage.

Bindings can be handled through a multitude of great npm modules.

Watch the video of the Google Analytics team explaining the cortitions needed to make AngularJS performant. Watch the videos where the AngularJS 2 team discards nearly everything from 1.3 (and then adds their own comical nonsense).

Declarative DOM manipulation through a virtual DOM is the future - every more than web components will be. Why? Because instead of being another "web framework", is it sound computer science.

<comment><USER58> > It matters little whether some find it productive, what matters is that the > engineering principles it is based upon are fundamentally unsound.

I disagree. What matters is whether you can produce a working application - and iterate on that, but after actually releasing. Angular is modular enough to allow for gradual optimization (like integrating React et al), instead of doing premature optimization.

Using vanilla JS like you recommend will lead to a lot of reinventing the wheel, and for new developers to have no clue what's going on (they have to learn the framework you thought up). At least you can make predictions about applications when it says 'AngularJS' on the job advert.

<comment> kuni-toko-tachi True, but Angular reinvents the wheel unnecessarily and at a cost of performance and being difficult to reason about.

JavaScript code can be easily written for reuse and composition. When a framework attempts to co-opt that there should be a very good reason. For Angular no such reason exists.

</comment></comment></comment><comment><USER76> Bizarrely enough, I've built about 4 web apps ( using Angular over the past 2 years also. However, I've found that scalability (mainly due to it's reusability) is one of the strongest points. I've worked with enormous applications built entirely with jQuery.

I love angular, but perhaps thats because I'd only worked with jQuery before.

</comment><comment><USER77> The real news should be : javascript framework is actually still considered useful for something after 2 years.</comment>


Ask HN: Best way to save page for offline reading? - <AUTHOR> What's the best way to save a website page for offline reading and archiving purposes so it can be used several years later? I don't want to rely on a service such as Pocket. A consideration is that sometimes the layout of the page is important so print preview and saving as a pdf is not always optimal. <comment><USER2> The "Mozilla Archive Format" Firefox add-on [1] can save pages to a single compressed MAFF file, or a MHTML file. Chrome has built-in support to save pages in MHTML format, but you have to enable it [2]. You can then view the archives later in the browser.

[1]: [https://addons.mozilla.org/firefox/addon/mozilla-archive- for...](https://addons.mozilla.org/firefox/addon/mozilla-archive-format)

[2]: [https://en.wikipedia.org/wiki/MHTML#Google_Chrome](https://en.wikipedia.org/wiki/MHTML#Google_Chrome)

<comment><USER3> I didn't know it could be enabled in chrome. Tried enabling it in vivaldi(as its chromium based) but now it crashes on launch.

I also use "too many tabs" add on so that the page content can be read later once added to too many tabs. To save page content I use different archive formats available upon installing "Mozilla Archive Format" Firefox add-on

</comment></comment><comment><USER4> Send to Kindle plugin works great for me. I usually wait till bedtime, then read most articles that I had sent to Kindle during day. If anything is interesting enough, I will save the article otherwise I just delete it.

</comment><comment><USER5> Depends on what content the page has and how the layout is in HTML. I have 3 ways of saving: 1\. as a web page - HTML only 2\. as a complete web page - HTML and assets (images, etc) 3\. a copy & paste into Word or a memo program

 __a lot of web pages nowadays, especially in blogs have so much crap like tracking links and advertising. When I save via #1 or 2, I first go into Firebug and delete DOM elements that clutter up the saved HTML.

If I copy & paste into Word, it copies the markup info like hyperlinks. If I don't want this, I first copy into Notepad, then into Word, to get rid of this.

</comment><comment><USER6> Pinboard (pinboard.in) provides this as a premium add-on to your account. It costs $25/year, and you can access your archived links at any time:

[https://pinboard.in/faq/#download_archived](https://pinboard.in/faq/#download_archived)

</comment><comment><USER7> Right click and press save as. Webpage (complete) will download all resources locally.

</comment><comment><USER8> wget with the mirror option, if saving the original markup is a priority.

</comment><comment><USER9> I use send to kindle</comment>


Steve Jobs' Doctor Wants to Teach You the Formula for Long Life - <AUTHOR> http://www.wired.com/wiredscience/2013/12/david-agus-rules-to-live-longer/ <comment><USER2> Single page:

[http://www.wired.com/wiredscience/2013/12/david-agus- rules-t...](http://www.wired.com/wiredscience/2013/12/david-agus-rules-to- live-longer/all/)</comment>


Ask HN: What is the fundamentally wrong with food delivery tech business model? - <AUTHOR> Food delivery tech is really a challenging and real problem to be solved. It really have a potential revenue model and solution. why multiple startups fail after spending lots of money on it? If we can't build a sustaining business model why this is being built? From US to India most food techs crumbled. <comment><USER2> I was recently at a Restaurant Tech meetup in New York. One of the panelists was a restaurant owner. Others were startups in the food space.

What I found repeated over and over again was that the food delivery services specifically Seamless, but also others, take too much of a cut ( 1/3 ).

Restaurants tend to operate on razor thing margins, especially in cities with high rent costs. If your product or service is going to be a significant cost to the restaurants bottom line, they most likely will not use it.

</comment><comment><USER3> I worked in food delivery for a few years before I was a software engineer.

\- Competition is fierce. There are at least a dozen food delivery services in my metro area. They are all spending a bunch of money on search advertising and free promos.

\- Drivers aren't paid for shit. I was averaging less than $6/hr on a 12 hour shift as a contractor. This was before Uber, so you had better figure out a way to pay your drivers at least as well as Uber otherwise they will just go and be Uber drivers.

\- Barrier to entry is low. Any schmuck can put up a landing page with their phone number and be in the food delivery business.

There are big problems with food delivery service business models. At their core, they are just a razor-thin profit margin middleman for lazy people. Is that the business you really want to be in?

</comment><comment><USER4> Here are 3 problems I see.

1) It seems to be too expensive. When we go to the store we only see the costs of the food we buy. We don't take into account the time and other expenses such as gas, wear and tear on the car and the frustration that goes along with getting the food. Show people that it really is not as expensive as it seem and people will be more willing to sign-up.

2) Lots of packaging material that ends up in the trash. Hard to see that stuff go in the dump every time a delivery comes. Delivery companies aren't taking this into account enough. Look at Apple, they make sure you know how environmentally responsible they are. It may not be 100% reality but they act as if it's true and convince the customer of it.

3) the hardest to overcome. People aren't used to getting food delivered. People's behavior can change but it's not going to happen in internet time but in people time. I'm thinking a generation or 2, 20-40 years. Look at internet retail, only now is it coming to fruition yet it's been around for at least 20 years.

<comment><USER5> Regarding point #3, I would be weary of putting my food in the hands of an unaccountable person. If the person works for the restaurant then they have some level of responsibility for the end user experience. If they are working temp for some service then they are less inclined to care about how the end user receives the food. They might even be resentful of the customer receiving the food. I've seen and heard of people doing some really horrible things to other people's food and I assume the worst.

But if you are going to make this a viable business model, you might do the following: enlist anyone into the process. If I am walking downtown at the moment and there is a delivery along my route anyway, I could pick it up and go. It would result in having many more workers who are earning less each. They are not employees by any argument, just people doing random tasks for a minimal part of their day. With a star rating, of course and possibly some upfront online training.

</comment></comment><comment><USER6> It's too expensive for most people to replace a regular trip to the market. Also I think people actually like food shopping.

</comment><comment><USER7> Push a button to get service,

      To scale 'push a button to service x' - do we need more human workforce ?

      Are margins on each service delivery low ?

      Does your country have minimum wage guidelines ?

Answering 'YES' to atleast two questions above means its going to struggle.

</comment><comment><USER8> Sometimes things cost more than people are willing to pay for them.

Public transit is an example. The postal service in some countries, lab-grown hamburgers, and most mobile apps are good examples.

Food delivery will be sustainable and profitable soon, when robots are delivering the food. Uber might actually be making money at it, for all I know.

<comment><USER9> Public transit is in massive use in many cities around the world where people are happy to pay for it. And it has huge economic benefits beyond the immediate costs of operating it.

<comment><USER8> > _Public transit is in massive use in many cities around the world where > people are happy to pay for it_

I know, but that has nothing to do with my point.

My point is that it's a money-losing public service, not a profitable business in the vast majority of (or all?) cases.</comment></comment></comment>


AT&T Enables Government Emergency Alerts For iPhone Users - <AUTHOR> http://appadvice.com/appnn/2013/06/att-enables-government-emergency-alerts-for-iphone-users

<comment><USER2> I got this update last night and immediately turned everything off. Call me callous but I really don't want to be woken up at 3am because a kid was abducted on the other side of the state. Also, from my friend's experience the weather alerts can be inaccurate; he once got a "blizzard warning" when the weather was absolutely fine (a blizzard in this area would be a nearly apocalyptic event)

</comment><comment><USER3> I find it tremendously creepy that "Presidential alerts" cannot be disabled and you must receive them.</comment>


Facebook shuts down page of lead DADT repeal group based on fake complaint - <AUTHOR> http://gay.americablog.com/2012/01/facebook-shuts-down-outserves-page.html Hello HN - Anyone have contacts at Facebook? They killed our page facebook.com/outserve on a false claim of IP infringement from a fictitious person. Any help from this group would be much appreciated.<p>Thanks! -Ty Walrod OutServe Co-Founder http://outserve.org <comment><USER2> I wonder how Facebook would react if people tried sending fake complaints about other, higher-profile pages?

<comment><USER3> Exactly my thought. What if someone decided to start doing this for politicians and political parties? And then goes to YouTube and reports a bunch of political ads for copyright infringement as well?

I'm not recommending that someone actually try this, but unfortunately I'm afraid that might be more effective than tech sites blacking out their sites for a day in protest.

</comment></comment><comment><AUTHOR> If anyone has contacts at Facebook who can help escalate this, it would be highly appreciated. Thanks! -Ty

<comment><USER4> If they're anything like Google, multiple employees have probably already read this and a few have probably already started the escalation process.</comment></comment>


Book about Launching and Running a Web Application - <AUTHOR> http://startingandsustaining.com

<comment><USER2> I've just skimmed through a preview copy. If you are running, or thinking about starting a SaaS business, it's a must read!

Awesome job Garrett :)

</comment><comment><USER3> Your call to action could be more prominent (I didn't notice it at all at first, then went looking for it).

</comment><comment><USER4> Loved the presentation and looking forward to the book. Appreciate you taking the time away from your business to do this — it's nice to get an honest feel for how someone else has done it, mistakes made, and successes achieved.

We need to share more like this among entrepreneurs — the Marc Andreessen quote about the entrepreneurial roller coaster of euphoria and doom is _spot on_.

</comment><comment><USER5> I read through the slide deck yesterday and loved it. There is a lot of good information in there. The personal touch makes it especially good.

</comment><comment><USER6> Love the presentation

</comment><comment><USER7> Waiting for it! Thanks for our last email conversation!

</comment><comment><USER8> Excellent deck.

</comment><comment><USER9> Nicely done, though it's more focused on launching a "web service/business"...yes, it's a business that consists of a web application, but the term in the title makes me think of it being a technical guide.

One of the things that would be useful, for technical and non-technical founders, is a nitty-gritty checklist of all the things you have to think about when launching a web app. Everything from deciding on the framework, the database, the schema, to having a favicon, og-meta tags, non-Javascript degradability, and setting up Google Analytics and Webmaster.

<comment><AUTHOR> Thanks for the feedback. That's definitely part of the plan. While I'm not quite sure just how detailed it's going to get, I've started on a one-page checklist of the items that I talk about in the book.</comment></comment>


A Critique of Krugman's Economic (not political) Commentary - <AUTHOR> http://blogs.zoho.com/in-the-news/coherently-yours-professor-krugmans-track-record-of-economic-commentary/

<comment><USER2> I am sympathetic to the Austrian critique, but there's a big problem with refusing to print any money and just letting the debt pyramid collapse. M0, the actual amount of green dollar bills in the world, is at $750 billion. MZM ( Money Zero Maturity, all the money in bank accounts and money market funds) is at $8.5 trillion. If the Fed refuses to use the printing press - ie it refused to print money or give loans to bail out the FDIC, and refused to bail out the money market funds - there will be a giant bank run as everyone with dollars in a money market fund rushes to redeem the holdings with actual green dollar bills. We're not talking about a couple big Wall St. banks going out of business. We're talking about every startup that has VC funding in a money market fund losing everything. We're talking about every mortgage in the world defaulting. Every bank account will vanish.

Of course, this won't happen, but only because Bernanke has guaranteed the assets of money market funds and the FDIC by promising to print money. Now, I think it is awful that MZM grew to be 10X the size of M0. The Austrians are right to condemn the fractional reserve policies that caused MZM to get so big. But the only thing the Fed can do now is to print money to make the two match, and then make sure it never happens again.

<comment><AUTHOR> _The Austrians are right to condemn the fractional reserve policies that caused MZM to get so big. But the only thing the Fed can do now is to printing money to make the two match, and then make sure it never happens again._

To even have that discussion, there has to be acknowledgment from academia & the Fed that their policies led to this. Right now, the intellectual climate is far, far from any such acknowledgment. In fact, the Nobel for Krugman signals exactly the opposite. It has conferred on him a degree of economic credibility (and perceived infallibility) that, frankly, he does not deserve - that was the point of my post.

Without that Nobel prize, he was easy to ignore as just-another-commentator. Not now. Yet another Keynes quote seems appropriate, why this debate is important:

 _The ideas of economists and political philosophers, both when they are right and when they are wrong, are more powerful than is commonly understood. Indeed the world is ruled by little else. Practical men, who believe themselves to be quite exempt from any intellectual influence, are usually the slaves of some defunct economist. Madmen in authority, who hear voices in the air, are distilling their frenzy from some academic scribbler of a few years back._

<comment><USER2> I don't expect much intellectual truth and reconciliation from academia. What will actually happen is the Fed will continue to informally create money ( via guaranteeing debt MZM rather than actually printing greenbacks) to get through the crisis, and we'll either end up with prolonged stagnation or a return to "the great inflation". As non-optimum as this is, I'd rather have Bernanke at the helm, than say Ron Paul. The Austrians don't realize that you can't just let MZM collapse and have everything turn out hunky dory after a bit of pain.

</comment></comment></comment><comment><USER3> The article has some good points, but Paul Krugman does too. The modern "keynesian" view that the Great Depression was caused by very bad policy of the Fed (keeping very high interest rates and desperately clinging to the gold standard) seems very close to the truth. But, on the other hand, the people running the Fed now, trying to avoid the mistakes of that era, might be going to the other extreme of keeping interest rates too low and printing too much money.While that might make the current recession relatively short and mild, it will prepare the ground for further bubbles - people, worried about their cash losing value, will invest like sheep into the next big thing, until it bursts again. So, maybe the right balance is somewhere between "keynesian" and "austrian"?

<comment><USER4> Part of the problem is that the central bank only measures inflation by consumer prices, and not investment asset prices. As long as consumer prices rise slowly, central bankers feel no hesitation in following loose monetary policy. This is true even as stocks and real estate prices take off into the stratosphere, causing potential instability.

<comment><AUTHOR> Recently, Bernanke seems to have come around to accepting that asset prices are important to monetary policy, breaking a long-held Fed orthodoxy, dating back to Greenspan. Contrast his speech in 2002, where he outlines the"don't burst a bubble but clean up the aftermath" philosophy:

[http://www.federalreserve.gov/BoardDocs/Speeches/2002/200210...](http://www.federalreserve.gov/BoardDocs/Speeches/2002/20021015/default.htm)

with this recent speech in October 2008:

[http://business.smh.com.au/business/bernanke-signals-new- app...](http://business.smh.com.au/business/bernanke-signals-new-approach-to- bubbles-20081017-52kv.html)</comment></comment></comment>


Barber Surgeons - <AUTHOR> https://en.wikipedia.org/wiki/Barber_surgeon <comment><AUTHOR> Seeing as many people are cutting their own hair during lockdown perhaps it's a first step on a new career in doing your own operations....</comment>


Why Subversion does not suck - <AUTHOR> http://blog.assembla.com/assemblablog/tabid/12618/bid/7437/why-subversion-does-not-suck.aspx

<comment><USER2> "it's radical because it's really easy to use."

Subversion is especially easy to use if you have to go through an HTTP proxy which doesn't forward WebDAV requests.

Another reason I love Subversion is that it remembers what revision I started a branch at. Could you imagine using a VCS which didn't do that? You'd have to write down the branch number somewhere and manually create a forward patch list anytime you wanted to merge.

<comment><USER3> Old versions of Subversion required you to remember the revision, but since 2009 and version 1.6, that is no longer the case.

A modern SVN workflow can easily look like this:

      svn co https://svn.example.com/myproject/trunk .
      svn copy . ^/branches/feature_branch -m 'Created feature branch'
      svn switch ^/branches/feature_branch
      svn ci -m 'Added foo baz'
      svn switch ^/trunk
      svn merge ^/branches/feature_branch .
      svn rm ^/branches/feature_branch -m 'Closed feature branch'

</comment></comment><comment><USER4> So because you've chosen a UI you like for Subversion, but haven't done so for Git (yet), git sucks, and by extension so does DVCS?

Even if you disliked all the Git UIs, there are some for Hg that are almost exact clones of their subversion counterparts.

Unconvincing.

<comment><USER5> SVN is not only a UI. If you get deeper into how scm's are implemented you should be able to appreciate the differences and tradeoffs between SVN and git. For one, git completely fails at bigger repos. It is just the reality.

<comment><USER6> In what way does it 'fail' at bigger repos? It was designed to handle the largest and most complex OS repo that exists.

For me the most amazing thing about git is how it is built out of very simple blocks. Each commit or object is a simple hash of it's contents. Which is just brilliant really. That's why it so fast and avoids any potential data corruption.

<comment><USER7> Incorrect. OS repos are miniscule compared to gaming and EDA companies with huge digital assets that need to be versioned as well (insert comments questioning why you would ever need digital asset revisioning with code, here).

The killer "feature" of SVN is partial checkouts. If im not mistaken, perforce and bitkeeper have this feature.

</comment></comment></comment></comment><comment><USER8> The core critical point that I have about subversion is that you'll likely ruin your perfectly working code by the having to "svn up" before you can "svn ci".

In git it's the other way round, you can go back to your working version and start over with fixing a conflict.

</comment><comment><USER9> The article is from 2008. Things change.</comment>


FPGAs becoming more SoC-like - <AUTHOR> http://semiengineering.com/fpgas-becoming-more-soc-like/#.Wxlg0Z4jrWM.facebook <comment><USER3> No. There is a more suitable tools now for every problem. Large volume - ASIC, and you can also put few ARM cores inside. Something highly integrated - <USER2> ZynQ. There are dozen different solutions for all the problems starting with big FPGA with couple softcore processors going to cheap spartan 7 device and going to tiny and dirt cheap Lattice chip for glue logic or IO expansion. Tools might be better, but this problem will be solved in the future for sure.

<comment><USER4> It wasn't a question.

ASIC isn't the tool for large volume, it's the tool for when you can accept a several year turnaround time for revisions, vs. a day or two. ASIC > FPGA... except if your design changes, ever. If anything high-bandwidth or design intensive is going on, you're definitely going to revise your design many times.

FPGA's are massively on the rise (although slightly less so than Xilinx would like), and they _all_ are effectively "SoC like", with DSPs, transceivers, hard IP's probably being a majority of the chip by now.

Zynq is a cute little chip, but with Intel's coming CPU-embedded FPGA's, thing will kick off even more.

<comment><USER5> What's the tooling like for a typical, production-quality FPGA project nowadays? Last I checked, which is admittedly a couple of years ago (and I didn't dive in very deeply), it was a horrible mix of badly programmed vendor- specific Windows-only GUI tools. It seemed a lot like the embedded processor market where every single vendor has their own lock-in strategy and the whole ecosystem suffers for it. Has this improved in the meantime?

<comment><USER6> Windows only tools? You must have been using Altera options (I briefly maintained the page for Quartus compatibility at wine, circa 2004). Even them have had Linux support for a while, Xilinx has Linux support for as far as I remember, at least some ten years.

The ecosystem is terrible, I agree with you. However, the lock in is restricted for the final synthesis part. Simulation is mostly done with (very expensive) third party tools, such as Mentor Graphics Modelsim, and in professional settings the build is automated to a point that opening the vendor's GUI is frowned upon.

There are some quality open sources tools on FPGA build automation, but most places I had contact with have their own internal tools.

<comment><USER7> I know someone who's implemented some string algorithms for FPGA with verilog. Is writing the code distinct from the tooling you're referring to, or simply an open source flavor of deployment? I haven't done any FPGA work.

<comment><USER6> When he talks about Verilog, he is referring to the language used for development and implementation. We're talking about a different part of the chain, something akin to the compiler, make, cmake and alike.

Of course, there's some dynamic between the tool chain and the language itself. For example, it doesn't matter if the language has the coolest feature if the compiler does not support it, and the toolchain will help you manage more complex code safely.

</comment></comment></comment></comment></comment></comment><comment><USER8> But isn't it becoming more like "SoCs gaining FPGA cores"? I know traditional FPGAs got hard CPU cores added, but from the CPU perspective the FPGA core is the new thing.

<comment><USER9> This article mentions that but doesn't give any details. Annoying since that's the interesting bit.

</comment></comment><comment><USER7> What does SoC stand for? I'm assuming not Summer of Code.

<comment><USER10> [https://en.wikipedia.org/wiki/System_on_a_chip](https://en.wikipedia.org/wiki/System_on_a_chip)

<comment><USER7> Thank you! I couldn't find anything in the article.

<comment><USER11> Yeah, took me several articles until I found out that the SD means Software Defined. Irks me when articles don't define acronyms.

</comment></comment></comment></comment><comment><USER12> Article says "CPU does not fit FPGA synthesis very well and uses almost whole thing".

People serious about prototyping usually get daughterboards for FPGA and/or FPGA stacks specifically to prototype big things with CPUs. The buses can go outside of main FPGA with CPU and into other things. I know at least one big SoC project which went that way.

I also think that having an ARM core in FPGA is a vendor lock in. For example, you cannot use AMBA/APB/AXB and other ARM buses with ARM CPU core in your design without paying ARM for license for these buses. It is not clear to me whether Zynq users have to pay for these buses and it may be case that they have to. Finally, ARM core in the prototype naturally extends into ARM core in the final product.

ARM itself is not very nice design from contemporary point of view. I expressed my dissatisfaction with ARM ISA many times here and just let me start with two points: 1) ARM is not RISC (multiregister load/store execute in several clocks) and 2) too much of initial design of first ARM (which was not planned for longterm evolution) is visible in ISA.

Basically, they put outdated (even for 2010) core design and used valuable silicon area so users have to use that instead of much more capable contemporary designs. Instead of trying to figure out how to change typical FPGA elements and layouts for CPUs to be more synthesable (which may bring benefits in other places), they decided to use that ARM thing.

I am deeply disappointed with that path.

<comment><USER13> > _ARM itself is not very nice design from contemporary point of view. [...] > they decided to use that ARM thing_

ARM CPUs are the de-facto standard in the embedded world (except for simple 8-bit MCUs), so what should Xilinx have done? Design their own, proprietary CPU architecture and ISA? Choose some other architecture with 2% market share? Both paths would have led to the immediate death of the whole product line.

> _1) ARM is not RISC (multiregister load /store execute in several clocks)_

So? Who cares?

> _2) too much of initial design of first ARM (which was not planned for > longterm evolution) is visible in ISA._

Ah, yes, technological purism – the quickest way to practical irrelevance.

<comment><USER14> > ARM CPUs are the de-facto standard in the embedded world (except for simple > 8-bit MCUs), so what should Xilinx have done? Design their own, proprietary > CPU architecture and ISA? Choose some other architecture with 2% market > share? Both paths would have led to the immediate death of the whole product > line.

Totally agree. IIRC, didn't Xilinx have another hard core CPU+FPGA design before the Zynq using a PowerPC? PPC is largely irrelevant these days. The high-performance embedded space is dominated by ARM today with x86 and PPC taking the rest. There's no way Xilinx would choose x86 with Intel owning Altera.

Maybe in 5-10 years RISC-V will start to eat some of ARM's share, but that remains to be seen.

<comment><USER15> > didn't Xilinx have another hard core CPU+FPGA design before the Zynq using a > PowerPC?

Yes; more than one. There were at least the Virtex II Pro, Virtex 4 FX, and Virtex 5 FX families.</comment></comment></comment></comment>