Angular 2/4 Is Too Little Too Late - <AUTHOR> https://medium.com/@chriscordle/why-angular-2-4-is-too-little-too-late-ea86d7fa0bae <comment><USER2> Re-post of what I wrote about this yesterday on Reddit:

I think Alan Kay was right: computing, at this point, is pop culture. Articles like this are are kind of like identity politics for programmers.

I don't say that that to disparage the author, because stuff like this is nothing new. Programmers have divided themselves into warring tribes for almost as long have there have been programmers. You used to see C programmers saying that Pascal is for idiots, and Pascal programmers saying that C is for neckbeards. Or similar arguments between C++ and Visual Basic camps or C vs asembler. And there are dozens (probably hundreds or more, actually) of other examples.

So it's not a new phenomenon, and I don't expect it to go away. The way I look at it, it's usually more productive to mostly ignore the pop-culturists and just pick tools that allow you to get things done quickly and happily. I've used Angular 2/4, React, and Vue. I like them all, and I'd be happy to work on a project using any of them. Aurelia looks equally enjoyable.

At this point, I don't think it's especially likely that a project will fail because you chose Angular over React, or vice versa. Pick what works best for you and your team, and don't worry about what the chattering bloggers say you should be using. :)

<comment><USER3> It's even dumber than contemporary identity politics, because at least there you (usually) can't choose your identity and so there's a defensible case for firing back at people who try to make your life miserable because of it. But language/platform/framework fanboyism is just pure sunk cost fallacy: you spent a lot of time learning X, but if X was the "wrong" choice, then was all that time wasted? To avoid that outcome, people invest tons of emotional energy defending X.

<comment><USER4> > But language/platform/framework fanboyism is just pure sunk cost fallacy: > you spent a lot of time learning X, but if X was the "wrong" choice, then > was all that time wasted?

A lot of these articles give me this vibe. So what if a competing technology is "bad". What does the author get out of saying "X technology is the best and Y is fail"? Are these guys now thought leaders?

Also I tend to see these more often in front-end land. Not sure why. Possibly because the cost of switching technologies is so low that you need to convince people constantly that X is the best so they stick around.

<comment><USER5> I have a hypothesis about this: The lower your skill is at software development (or some subset of it), the more likely you are to be strongly opinionated about these kinds of arguments.

If you are highly skilled, you're far less likely to be married to any one bit of technology, even if you have prior preferences. You're also likely to have been through a few fad cycles before, so you probably learned to tune out the holy wars and focus on being productive. And if some stack X is really a giant turd, you should be able to figure that out quickly and avoid it, so you don't have a reason to write about how much it sucks.

On the other hand, if you know next to nothing, you're going to be more likely to read "Don't ever use X!" stories because you don't know what to use and are looking for advice. And you may be more dependent on whatever things you do use, because you don't yet know many other things, and you may be more likely to believe that it's better for your career to establish yourself as an expert in whatever you know.

I think the "front-end land" sees more of these now because front-end land is a new and bizzare place that only came into being a few years ago; people generally don't understand it as well as they do other things.

</comment></comment></comment></comment><comment><USER6> This reads as react fanboyism to me. I used React/Redux on a project and was unable to bring people up in my aging team. Now we are fully Angular 2+. It is much better for my newly grown team of 15. The action creator approach of Redux isn't very readable or maintainable. The module system in Angular is better for us.

You can use webpack with Angular. RxJs is a great addition that will eventually be removed when Observables become implemented in JS. The declarative style of templates are different than JSX, but are not hard to deal with in practice. Native script allows for mobile dev, although I don't personally use it.

Before I switched to Angular, I preferred React. Now that I use this framework approach, I am much happier and have more faith that my code base will be consistent. I read somewhere that google used Angular for adsense so I think it is good enough for production use for us.

<comment><USER7> I guess when you say "aging" team then I imagine your team members mostly spent their time in the OOP world, and Angular is definitely a better fit in this case.

React and Redux promotes a more functional style (even though React components are classes...), and a lot of OOP people I personally met were not so comfortable with it.

Personally I love the functional concepts that it taught me, and I would never want to use a framework like Angular again. I'd rather make the leap and look into a real functional language for the frontend, like Elm, ClojureScript, PureScript,...

<comment><USER8> Honest question: why are React developers so fixated on functional programming? Why are objects - bundles of state and action that represent entities in the problem domain - automatically painted as an antipattern?

<comment><USER9> Because they're not old enough to remember what '80s GUI code looked like when the "Global god object + functions" pattern was last popular?

That's a snarky reply, but there is a kernel of truth. OO was practically invented for GUIs (Smalltalk). Throwing it out entirely on principle just makes large programs harder to understand, IMHO.

<comment><USER7> True, I'm not old enough with my 33 years to remember that ;) But I do have quite a few years of experience in OOP and GUI programming (not just web stuff).

</comment></comment></comment></comment></comment><comment><USER10> >> Benchmarks for React consistently show its superior performance over Angular 2/4: [https://auth0.com/blog/more-benchmarks-virtual-dom-vs- angula...](https://auth0.com/blog/more-benchmarks-virtual-dom-vs- angular-12-vs-mithril-js-vs-the-rest/).

Intellectually dishonest. The article linked to was from January 2016, around the time the first beta of Angular 2 was released. That code has all sort of debugging code in it, and the architecture changed quite a bit between then and the release in September 2016. (To say nothing of the fact that those benchmarks don't cover Angular 4, despite the preface in the article) With AOT in Angular 4, a site running in production is quite fast compared to JIT.

</comment><comment><USER11> Here's a litmus test for if you should use Angular or React: how do you feel about the fact that React has ~4 major routing libraries?

I've written a book on both Angular 2+ and a book on React. I've talked w/ hundreds of developers on both sides and I can tell you that people with different constraints (and backgrounds) will have a different response.

The author of this article cites "more ReactJS libraries on npm" to imply that React is the better choice. Some people love a la carte infrastructure and the power that comes from choosing each element in your stack.

Some people love to have those decisions made for them, because they just want to build their app.

It's often cited that React is "simpler" than Angular, and if you look at just the core that's true. But by the time you pick a data architecture, styling choice, router, etc. you're back at the same level of complexity.

Actually in React, you've spent a lot of time researching which components you want (and if they'll even fit together). The pro here is that you get just the stack you want! The competitive evolution of these libraries means that you _can_ have 4 routers and pick the best. But also, if you'd just picked Angular, you just use their router and move on.

Here's another litmus test: Do you want 'string' templates or JSX? (Now, I know it's technically possible to do either in both frameworks, but it's almost never done in practice.)

Almost everything that seems "more complex" in Angular is a result of string- based templates. DI, AOT, the *ngIf and `let` syntax, is all because you're doing templates in strings instead of code. How do you feel about that? Would you rather write templates in JavaScript/JSX? Then use React. Do you have designers doing HTML on your team? Then use Angular.

(Also the other opens by citing webpack, npm, and third-party libraries as a React-specific benefit, but that makes no sense because angular-cli uses Webpack, it's on npm, etc.)

<comment><USER12> _> The pro here is that you get just the stack you want! _

I don't disagree with the facts-on-the-ground of your post, but I think you're drawing a mighty false equivalency and this line highlights it. The _pro_ here, for a React-based stack is that you are forced to understand the tools involved well enough to make meaningful decisions (if you're a competent developer). By the time I was done evaluating routing libraries, I was confident in my ability to write my own, effectively--and so I didn't have to because I was able to adopt the library of my choice's mental model immediately. If you "just want to build your app", your app is gonna blow up (not might, _will_ , given a long enough timeframe) and you're not going to be equipped to fix it.

Passive consumption is unwise for programmers. We've seen it bite people forever (be it the "all things come from Microsoft" era of .NET that they're just shaking now or the "Spring does it for us" era of Java or most of Rails pre-3.0).

<comment><USER11> The history of technology is using the progress of others as a foundations on which to build something new. Once it works, it's a given, a building block. No one can understand it all the way down and we need to be careful about saying what 'real developers' do or don't do.

<comment><USER12> It's not a given at all. All of your abstractions break. These high-level abstractions break much, much more often than lower-level abstractions (because they try to encompass more, it's a surface-area thing). There are abstractions that are so fundamental to _doing your job_ that you must, must must must, understand them at an implementation detail and then use them to improve productivity.

The stump-dumb-simple routing layer of your JavaScript handwavey crap is one that You Really Just Gotta Know; it's literally central to everything you _do_ in a SPA. And yet the overwhelming majority of AngularJS folks I have ever met --and, to their discredit, way too many keypuncher ReactJS folks, but a significantly smaller proportion--have no idea what to do if their web framework spits the bit. And my contention is that having to make choices means the likelihood of a baseline understanding of what chose choices mean is way higher.

There are plenty of capable developers who work on and choose to use AngularJS. I've worked with _great_ ones. But, like the other environments I mentioned before, it sure seems like they brought that capability to AngularJS rather than had that capability fostered by AngularJS in a pedagogical manner. And that's troubling to me, because these folks are going to be writing software that you and I depend on, too. I'm not hanging people for not being able to work meaningfully with the JavaScript runtime or understand how the browser works internally (though these are handy to know, most of my knowledge of JavaScript comes indirectly from embedding first SpiderMonkey and then V8 in a game engine once) or how their OS handles process segmentation to sandbox off their web runtime environment (not a super complicated topic but, sure, out of scope) or how their OS handles memory (this one, ditto) or or or--I'm saying _you gotta understand the thing your hands are on all the time_ and that tools that attempt to swaddle you in a nice comforting "you don't need to worry about that" are gonna put you in a real rough place when that doesn't hold.

<comment><USER13> So, I've had to maintain (upgrade) a Node/V8 extension, an Angular1 and an Angular2+ but never stopped to understand routing. (We talked about it briefly around that ng1 app.) And I have no idea how Node extensions hook into V8 under the covers.

There were no abstraction breaks. C++ compiled, the thing works, the same goes for ng2 with TS. Ng1 is just plain ugly, but works fine.

I like React/JSX, FRP, I hate the size of the bundles Angular spits out, the byzantine boilerplate required to put something on screen and to make components interact, but it works, and it comes as a full package, and it keeps getting better.

The design principles of Ng are sound. Ng1 was overcomplicated. Ng2 is okay- ish.

I think ng lacks the "documentation" that the React ecosystem must provide due to its separatedness/modularity.

But my main point is, that basically good developers will compare those routing plugins/libs, and those same devs can solve problems when ng2 spits at them. And newbie frontend devs jump on the React is small and simple hype train and take the first tutorial and then get lost in that jungle. (And I'm not saying this can't happen with ng1/2, but neither codebase is about teaching programmers, so that's a very fringe aspect of this topic.)

</comment></comment></comment></comment></comment><comment> anton-107 Angular 2+ user here: \- Components have nice API and are pleasant to use \- Dependency injection containers out of the box are good for those who value inversion of control in their codebases \- Change detection is good and fast. Gone are the times of leaky abstraction of the digest loop \- Tooling has caught up: Angular CLI for rapid start, server-side rendering works just fine. You are using npm, webpack, typescript (brings es2016 features to you), modern testing frameworks and what not \- Redux works nicely with Angular2+ as well, it's not exclusive to React \- You can wrap pretty much any 3rd party browser widget into Angular component within maybe one hour of work

I guess when your open source library passes a million downloads per month, you are not worrying too much about marketing anymore. So i'm not quite sure why it's so important for the author to declare one and only one winner in the race. Both React and Angular users are benefiting from the competition

<comment><USER14> > Gone are the times of leaky abstraction of the digest loop

But now you have zone and it's leaky. See this stackoverflow question for example: [https://stackoverflow.com/questions/43097291/firebase- datasn...](https://stackoverflow.com/questions/43097291/firebase-datasnapshot- observable-not-updating-immediately-after-login-via-redire)

Edit: wrong link

</comment></comment><comment><USER15> I agree with the article's main point. In the market share fight between React and Angular, React has won — and for good reason, I think.

Angular 4 is an improvement over Angular 1.x, but Angular's main problem is still needless complexity, both in syntax and concepts added by the framework, and a totalitarian approach, in the sense that Angular seems to want to replace vanilla JavaScript/DOM/Browser API's with it's own slightly different and unnecessary versions. What you learn developing in Angular is therefore specific to Angular and not transferable to other domains. Personally I find that depressing and demotivating.

Angular 4's HTML templating syntax is terrible. I get the feeling the deliberately set out to make it as complex and inconsistent as possible — it's hard to phantom how else they ended up with such a mess.

Angular seems to have been inspired by the worst of Java EE from days of yore, it's riddled with needless complexity and ceremony. No one should have to work with that with the nice alternatives we have today.

<comment><USER16> "In the market share fight between React and Angular, React has won...."

All the data I've seen indicate that both Angulars, combined, account for twice as many production code bases as React. I wonder where you got the idea that "React has won"?

<comment><USER17> ... and non-SPA, full-page-load-driven, jQuery-based web apps dwarf BOTH by an order of magnitude, even in 2017. You're just not going to receive many blog clicks or discussion forum upvotes by pointing that out.

"Won" usually means, " _the thing that people most want to read or talk about at the moment_ ".

<comment><USER16> Actually, the same data indicates that jQuery is around 45% market share as the primary front-end JS tool. That's almost exactly the market share of both Angulars and React combined.

And yes, this represents a steep drop-off in the number of jQuery-centric applications in the past couple of years.

Edit: I thought I had bookmarked the Web site where I saw these numbers, but I couldn't find it before running out the door this morning. Suffice it to say, the JS landscape is changing rapidly, and assumptions that were safe even 12 months ago are not valid today. jQuery is fading quite rapidly, and though it won't disappear any time soon, and, increasingly, it is no longer seen as a good choice for large apps with tons of business logic.

<comment><USER17> I'd be interested in types of applications those numbers are using as the pool for its comparisons.

What I'm saying is not that jQuery is the end-all-be-all. It isn't, and trying to build a highly dynamic web application with tons of client-side logic around jQuery is indeed a recipe for spaghetti.

What I AM saying is that most web applications (especially in the enterprise business world), simply AREN'T all that dynamic. They are primarily driven by full page loads rather than AJAX, and server-side logic rather than client- side code.

On HN, the terms "web application" and "SPA" are practically synonymous. But outside of a few social media titans, and the startup community, that's hardly true.

</comment></comment></comment></comment></comment><comment><USER18> >>time-travel debugging, hot module reloading, and simple and easy undo/redo capabilities

These things are prime selling points of Redux and it's interesting that they are simply unimportant bells and whistles not worth the massive increase in complexity and cognitive load that Redux brings to ReactJS applications. Use Redux and you have to write a lot more code, really for no good purpose when in most cases you can just store a (HERESY!) global variable and get straight on with the job without twisting your mind around actions and all the other Redux guff.

Redux is an anti pattern.

This article also breathlessly praises webpack, which is a massively complex and configuration heavy JavaScript tool and one of the prime culprits responsible for the JavaScript build tool ecosystem being so damn complex. Webpack needs to go the way if it's predecessors and he replaced with something simple.

<comment><USER19> I don't know enough about React to say whether or not I like Redux, but I've written enough Angular code to know that Angular's lack of a good state manager _is_ a problem. A lot of Angular apps end up storing an object in $rootScope that's treated like a global state, and that leads to weird side effects and bugs if you're not careful. Something like Vuex would be be a great addition to Angular.

<comment><USER18> Maybe I'm doing it wrong but when I (rarely) need state between components I just plop it into a global variable, of which there only ends up being s handful, and it's never been a problem. When I tried to use Redux first it burned my brain trying to grasp its architecture and how to write the various bits of code it needed, all replaceable with this.app.globals.foo=42

</comment></comment></comment><comment><USER20> The prevailing opinion on HN seems to be that React is great, and monolithic frameworks are bad bad bad - especially Angular.

On a recent project I started for a client, we did a full evaluation of React + Redux vs Angular 2/4 and NGRX.

Angular's first-class support for TypeScript, and RxJS is incredible when leveraged properly. Integrate this with NGRX for Redux style state management, and you get a compelling solution that is miles ahead of the React/Redux combo _if_ you can get over the template syntax (instead of JSX) and the opinionated flavour of Angular.

It's difficult to offer an alternative opinion in the HN echo chamber, but we're having _excellent_ results using Angular CLI + Angular 4 + RxJS + NGRX. It's worth the steeper learning curve, IMHO.

<comment><USER21> To add to that, most new React/Redux projects are settling on the same technology decisions as the Angular team. TypeScript/Flow, RxJS for async/effect handling (or Sagas). React vs Angular is pretty negligible at this point. They are both component focused frameworks and that's the important paradigm and shared quality amongst all these frameworks.

Anyone who understands the architecture of one should be able to learn the other relatively quickly. I haven't personally used Angular 2/4, but it looks like a really solid and opinionated solution. Some people don't want to spend 3 days researching thunks vs sagas vs observables, so I'm glad something like Angular exists.

</comment></comment><comment><USER22> I am using Angular4 and am pretty happy about it. Especially I am happy of the fact that Angular is opinionated framework thus it is easier to work in teams on one project because there is usually just one way (angular way) of doing things instead of 100 different ways in React.

Also, author is praising features like rx, time travel, webpack but does he know that all these are baked in angular as well? ngRx is very solid maintained project that actually works with all time-travel debuggers. And webpack is built-in in every angular project.

</comment><comment><USER23> I agree with this. It's a mistake to characterise this solely as Angular vs. React though. It's really about these things,

\- Declarative UI as a pure function of state

\- One way data flow

\- Frameworks that use plain language features and functions, rather than template-like DSLs

No need for framework holy wars, but objective speaking these sorts of approaches are objectively the right future for UI development imo.

<comment><USER6> Angular is mostly a declarative UI. I don't usually put logic in my templates. I do, however, like how react leans towards using language features instead of abstractions.

Angular does one way data flow. It also allows for two way binding. The choice is the developer's.

So your argument boils down to using language feature over the template DSL. I think it's more important to consider state management, code reuse, and inter component communication (perhaps also a part of state management if using something like Redux).

</comment></comment><comment><USER24> I'm a mostly-backend dev that's been pressed into service on the frontend recently and I've worked on React and on Angular.

In my experience, I like the React way of defining components and functionality a lot better. The errors that Angular spits out from the HTML- templates are difficult to parse. There's also an unfortunate combination of a fractured community and incomplete first party documentation that makes Angular hard to ramp up on.

That said, Angular has a huge advantage that has made developing in it a lot faster for me. It's got everything right there. Angular doesn't have unique functionality, but it starts you off with a standard set of design patterns that stand you in good stead. React is just a frontend and when you're new to the space you don't know what else you need. Frequently, the productivity gain of not having to think about how to solve a problem is greater than solving the problem the "right" way.

Realistically, most teams solve this problem by having a senior team member who can pick technologies and design patterns. I haven't had that luxury on this last project, so I appreciate the Angular ecosystem. Javascript is great, but it's still very wild-west like.

</comment><comment><USER25> How to get upvotes on hackernews: write yet another clickbait medium article on how bad angular is.

I don't think the OP has ever used Angular CLI or followed Angular development. If he had then he would have not written this article since a majority of his claims about Angular are wrong.

</comment><comment><USER26> I moved to Vue from Angular 1 instead of React when I started a new project last year.

I regret nothing.

<comment><USER6> I keep hearing good things about Vue. Do you know how it compares to Angular 2? More framework than library? State management built in?

<comment><USER27> The Vue guide has a comparison just for you. (might or might not be too biased, I don't know ng2) [0]

Vue deals only with the view layer. So I would't directly compare it to Angular. But the authors do give you Vuex, for Redux-style state management, and Vue-Router which does exactly that.

Alternatively:

\- use a second Vue instance as an event bus. Bonus points as the Vue devtools list all the events fired. Makes it easy to debug.

\- due to it's reactive nature, Vue let's you implement a single source of truth quite easily. [1]

\- Using dynamic components, you might not even need a router [2]

Personally, I've tried to use the single source of truth pattern but quickly resorted to Vuex. It just resonates with me.

[0] [https://vuejs.org/v2/guide/comparison.html#Angular- Formerly-...](https://vuejs.org/v2/guide/comparison.html#Angular-Formerly- known-as-Angular-2)

[1] [https://vuejs.org/v2/guide/state-management.html#Simple- Stat...](https://vuejs.org/v2/guide/state-management.html#Simple-State- Management-from-Scratch)

[2] [https://vuejs.org/v2/guide/components.html#Dynamic- Component...](https://vuejs.org/v2/guide/components.html#Dynamic-Components)

</comment></comment></comment><comment><USER28> React won and those of us stuck on Angular 1 are mostly fucked. From that perspective, you'd have to be absolutely fucking insane to even consider Angular 2 after how badly the Angular team fucked up Angular 1 and all its users, leaving them in the dust. It's not about tech. Tech is irrelevant. I cannot trust this team to stand behind their software. Maybe that's because they build really shitty software. Fool me once and all that ... but IMO, you'd have to be a fool to use Angular 2+ after this fiasco.

<comment><USER29> Is your problem more with the lack of proper migration to Angular 2 or with the differences between 1 and 2?

<comment><USER28> My problem is that I don't trust the Angular team not to abandon Angular 2 like they did with 1. Angular 2 should have been named something else to avoid all this confusion around Angular 1's abandonment.

</comment></comment></comment><comment><USER30> It's hard to take this post seriously when this guy has barely 5 years in the industry.

If you're building a large enterprise app with lots of engineers not familiar with either framework, Angular 2/4 wins hands down.

<comment><USER31> Angular 4 is a few months old. It's not mature and the ecosystem is immature. Even the official Angular Material2 project is still in beta. You contrast this with React's ecosystem of UI components that have been built up over years...it's no contest. You can build better looking, better performing UIs with much less effort and they work great, even in IE11 and Edge.

</comment></comment><comment><USER32> I can't help but feel like all of these posts are a bit overly dramatized.

As much as people complain about Angular, I think it's completely fine for the majority of use cases at large scale. So is React. So is Vue. Even Angular 1 is fine. In practice I've never run into most of the issues people preach about. Two way data binding isn't the devil. One way data flow isn't a panacea.

My developer happiness has always been contingent on the quality of my coworkers, and not on the framework itself (all of which, I feel, are great in their own ways.)

</comment><comment><USER33> Occasionally I have thoughts like these. And I often write them down. But rarely (never) publish because I am always hit by the idea that no matter how bad a certain framework/project is (especially open source), unless it's actively malicious, there are real people who are actually putting time and effort building and maintaining these projects.

There is absolutely no reason to dismiss all their efforts.

I can provide a critique and state my preferences for a certain framework over another without demeaning the project I don't find preferable.

The O/S

</comment><comment><USER34> I stopped reading at

> mature ecosystem of tooling and libraries

That tells me the author is either blind or so lost in his world that he thinks this is actually true.

This fanboyism around languages and frameworks is apparently ever-growing. Haven't we learned by now that everything is about trade-offs and there is no One True Way?

<comment><USER35> Unless you're coding in [https://en.m.wikipedia.org/wiki/Brainfuck](https://en.m.wikipedia.org/wiki/Brainfuck)

</comment></comment><comment><USER36> Though I do think Angular 2/4 is inferior to React/Redux combo this article is very biased and not good for a constructive discussion and comparison of those frameworks.

</comment><comment><USER37> I strongly disagree with the claim that "React Is Much Simpler." React on its own may be simpler, but by the time you add libraries for routing, HTTP, dependency injection, date/currency formatting, animations, and all the other stuff that Angular provides out of the box, the complexity starts to look pretty similar.

Furthermore, because you have to rely on third-party libraries for all the features that React doesn't provide, you have to worry about separately keeping them all up-to-date. What if there's a critical bug fix in the latest version of your HTTP library, but it's only compatible with the latest version of React, which isn't compatible with the router version you're using? In my experience it takes a lot more time to keep dependencies up-to-date and working together with React than with Angular.

<comment><USER38> There are already browser standards for HTTP and date/currency formatting. At most you need a polyfill if you want to support really old browsers. CSS transitions also take care of most use cases for animations. A library for dependency injection is just over-complicating things. You don't really need it.

The only thing in that list that I have ever felt a need to use a library for is routing.

</comment></comment><comment><USER39> I doubt we will ever do React.

All the SPA projects at our company are Angular based and I don't see any plans to change it.

</comment><comment><USER40> My experience with Angular is that it was sort of the gateway drug of SPA architecture.

Back in 2010-11 I first tried out Angular to experiment with the SPA concept. This was hard to reason with back in those days, as most client DOM was still server-generated (at least for initial requests). It was really a big paradigm shift for a lot of developers, myself included. I found that Angular's foundations (directives, services, controllers, etc.) helped to constrain my thinking in ways that made the SPA concept more clear. The angular ecosystem in those days was really a haven of SPA-oriented thinking that couldn't really be found elsewhere on the web.

Fast forward to now, SPA architecture is essentially the norm. Almost every web-enabled device now has a full javascript runtime. Additionally, it has actually become an anti-pattern in some cases to force server-generated DOM on the client, as each clients' JS runtime is usually better suited for interacting with its specific DOM quirks and handling device features.

Now that SPA has become a more mainstream way of thinking, developers have begun to seek out ways of implementing this architecture with fewer constraints (and arguably bloat) than Angular could bring to the table. Frameworks like RiotJS are starting to explode in popularity because developers still want some fundamental SPA-style framework, but also want to maintain the ability to interact with the DOM in a more direct and vanilla way. When working with Angular, I found myself constantly trying to find (or god forbid write) the angular-compatible directive wrapper for whatever 3rd party javascript component I wanted to add to my project. Being able to simply include something like moment.js directly in my project and use it exactly as their documentation indicates has been a massive productivity gain for me and my team.

I took a few cracks at Angular 2, but there was something that always felt off about the component system and how more complex pages were composed. Their attempts to bring typescript into the fold only served to confound things even further for me. I know this is a hugely-subjective thing, but it was basically the end of the road for my Angular experience. It took me 5-6 weeks to get my team truly productive on Angular 1.x. I was able to bring them up to speed on RiotJS in a single afternoon (the router being the hardest bit).

</comment><comment><USER41> This article includes a statement I've seen several time before: "flux is more of a design pattern then a library or framework". This statement drives me to unspeakable levels of fury. What does that mean? It's like saying "Alvins ball is more a boulder in Yosemite than a mid century school of literary criticism". They're two totally different things!

Someone who understands the statement, could you help me? Does it mean that there is a design pattern so light that some particular library which implants it would be trivial to recreate?

Any answer, I beg you, please clearly distinguish between the very different concepts of design patterns and named code projects which implement them.

</comment><comment><USER42> Having just seen a whole bunch of React shops when interviewing for a front end position, a _lot_ struggle with React but also really enjoy it. Definitely don't see a significant difference in the end from Angular, they're really similar frameworks.

I think the ones that really have invested in making React work in their org but move a _bit_ faster, but Angular making strong decisions and providing really good patterns out of the gate is extremely valuable.

Both are great frameworks, so adopt works best for your company, your team, and your product!

</comment><comment><USER43> From the article:

> We can be almost certain that React & React Native are a competitive > advantage. We can see evidence in how Facebook simultaneously launched > Snapchat-like "Stories" across four applications (WhatsApp, Messenger, > Facebook, and Instagram) in its product suite.

> It's not hard to infer that React was a key reason why Facebook was able to > do this so rapidly.

Is there any actual evidence that React / React Native was used to build the Stories feature for any of these apps?

<comment><USER31> No. And it's a fair point. I might be reaching a bit. But I do think Facebook sees real productivity gains from using React Native in production and those gains benefit their velocity as a whole.

</comment></comment><comment><USER44> _At the peak of JavaScript fatigue in 2013_

I don't think JavaScript fatigue peaked in 2013. FTA:

 _it is quite easy to maintain a large, flexible, well-engineered SPA with React, Vue, or other lightweight JS libraries, even at enterprise companies with large teams._

Vue's initial release was just over three years ago. Other technologies used by enterprise companies has usually proven itself for a decade or two. Articles like this don't help with JavaScript fatigue.

<comment><USER31> Front end technology has advanced rapidly in the last 5 years. You can't compare the back end as much. Although there's innovation there too from new languages and functional paradigms.

</comment></comment><comment><USER45> This article ignores the power of Microsoft backing Angular in ASP.NET as a first class citizen with typescript. Most companies don't care about what stack they use, and if their Microsoft partnership agreement offers free Angular + TypeScript training? Most companies will go with Angular if they don't have specific performance needs.

</comment><comment><USER46> I'll just be the sad puppy sitting in the corner writing everything in vanilla es2016/17\. I never had any problems and everything works. The amount of code I write is no more than the angular code I write at work. Never used react but it looks like a jumbled mess. Vanilla JS is pretty sweet and has everything I could ever need.

</comment><comment><USER47> I'd agree that angular 2 was a letdown. Seems like most people are like me and like typescript, the cli, and a better router, but those could have been incrementally added instead of starting from scratch.

It still boggles my mind thinking about the massive amount of effort google's large team spent on ng2, library authors spend porting ng-bootstrap, plus every app that will be rewritten, plus the interim confusion of having 2 versions of libraries, documentation pages, etc. For improvements in some areas, more complexity in others. And I think to the point of the article, it feels far behind react in a lot of advanced development features as it is still trying to get a solid footing. Just saving a file and waiting a few seconds for a full page reload is much worse than the gulp then webpack browserupdate system I setup for ng1 apps, and the cli is not _that_ much better than a custom gulp task I setup to generate new components and services in ng1.

My theory is the primary motivation for ng2 came from the angular team not wanting to maintain a js and dart version of the library, so they wanted to move it to a single codebase that could compile from nativescript/typescript to both, and it was an easy sell to all the people who identify in the angular tribe.

Some specific things I don't like in ng2:

\- Too many ways to do forms. Template driven vs reactive, with some things like mdAutocomplete I could only get working w/ reactive. You can do [ngModel] + name attribute, [ngModel]="name", [(ngModel)], formControl, formControlName. Little things like adding `Validators.required` isn't picked up by the view, so you have to specify required there too to get the little (*) asterisk in the view for mdInput

\- Testing got much harder to do, with mocking every dependency. Just when ng1 made frontend unit testing pretty painless to do, it feels like a step back.

\- The DI system in general feels like waaay too much complexity for the much smaller benefits it brings now that `import`s are available. I was reading the docs to try to figure out an equivalent to a factory function and I realized even if I could figure it out, another developer or myself in 6 months would not understand it. Mocking imports for testing would be good enough, I think.

\- Unless you plan to be an "ng2 developer", dipping into the 100+ ;) rxJS observable methods is a good way to confuse your teammates or future self. Have fun remembering what mergeMapTo vs switchMap vs forkJoin do. Observables are cool, but imo another case of too much complexity and too many ways to do things for the benefits. I haven't seen good guidelines of at which point in your app do you transition from observables (returned from http request) to plain objects - should you pass observables down through components for things that can change, or rely on the component seeing its input property changed? Should I implement a snapshot property on my objects that can change, similar to how they do routes? It is silly to me an http request response is modeled as an unending sequence of events, instead of a promise. The only benefits I see like being able to specify `retry(3)` could be implemented as an option in your api service that wraps http, and would probably be more consistent that way.

\- A lot of small things are gone, like a capitalize pipe, ngFor iterating over objects. A little slower when getting started on an app when you have to add them yourself. They got rid of things like http interceptors and route resolves, and are adding them back in now after people complain. Even stuff like adding a query param to a url required a bad java-like api and multiple lines of code. They improved that since, but why start w/ a step back from ng1?

\- Speak of route resolves, they have gone from a simple 1 liner in the route definition to being a 10 line standalone service, which you have to import and add to your providers array.

\- Hasn't been an issue for a while, but having your global ng-cli which housed the webpack and typescript config(?) go out of sync w/ your local version, and your angular/core version, was a really confusing and painful upgrade.

\- I like typescript, but it does have strange errors where it seems to have an older version of a file cached and you need to restart the server to fix it. Seems to happen more when importing a class that isn't @Injectable()?

\- It is slower. My livereloading browsersync ng1 apps were faster and more fun to work on.

\- It is a huge pain to rename things or reorganize your files. VSCode was rename symbol which is nice, but to stay consistent when renaming a component you need to rename: each of the 4 files+directory, all the imports, the `selector` and all tag references to it across the app, the `.my-component` css classes. I do a lot less refactoring of component names or directory structure in ng2 than a glob import style ng1 app, where you don't need to manually requiring everything.

Hmm, maybe should write a blog post about this.

<comment><USER48> > It is slower. My livereloading browsersync ng1 apps were faster and more fun > to work on.

Wasn't performance meant to be the whole raison d'etre of the rewrite?

</comment></comment><comment><USER48> What I'd like to see is really mostly for them to just keep maintaining Angular 1.x. I don't care about "microlibraries;" I want a sane set of components that work well together, even if they're not all necessarily the absolute best in class.

</comment><comment><USER49> I'm hoping Polymer 2 will gain more traction. Anyone out there hoping for the same thing?

<comment><USER50> It is gaining traction - almost 8k users on slack channel stedily growing - new components are getting released on webcomponents.org every day.

<comment><USER49> I somehow find the dependency management system of Polymer 2 (loading script tags in a component), is going back to the old school ways/days. There is no dependency isolation, modules are loaded to the Global... v.s. ES6 imports via webpack, for example. Granted, module imports are not browser ready yet. Guess we'll just have to live with it for now.

Happy for someone to point out a better way for Polymer 2 dependency management that feels... less dirty.

</comment></comment></comment><comment><USER51> > Two way data-binding was a feature in 2013 and Facebook said it was a bug. > It turns out they were right. Ember, Angular, Vue, and others would later > adopt the one-way model.

No, they weren't. It's just a different way to manage state. And VueJS employs two-way binding so I'm not sure what was the intent here.

> Redux brought predictable, functional, maintainable state management to > JavaScript.

Stopped reading here. Too sensationalist.

<comment><USER52> >And VueJS employs two-way binding

Two way binding is an anti-pattern in Vue. [https://vuejs.org/v2/guide/components.html#One-Way-Data- Flow](https://vuejs.org/v2/guide/components.html#One-Way-Data-Flow)

You actually get console warnings if you try to affect state in that manner.

<comment><USER51> That's about parent and child components, not about the state of a particular component. VueJS keeps two way data-binding between the template and the component; react does not and needs to handle events from jsx (or whatever one is using as template) explicitly.

And making child controllers directly alter the state of their parents is generally thought as an anti-pattern in angular 1 too, as far as I understand.

<comment><USER52> Thanks for the clarification but I'm still a little confused.

>VueJS keeps two way data-binding between the template and the component

In what sense? If you need to update your data on the JS side from the DOM you have to use events. There's v-model, but this is just syntax sugar for binding an event on input to update the value prop.

<comment><USER51> > In what sense? If you need to update your data on the JS side from the DOM > you have to use events. There's v-model, but this is just syntax sugar for > binding an event on input to update the value prop.

Which is why calling two-way data binding in js a "bug" is so weird (for lack of a better word). In angular, two-way data binding is, ultimately, also syntactic sugar over DOM events.

For that matter, _everything_ every frontend framework provides is syntactic sugar over vanilla javascript.

<comment><USER52> All I'm saying is that Vue doesn't do two way binding. v-model translates directly into a DOM event, ie

<input v-model="someProp">

is equivalent to

<input v-bind:value="someProp" v-on:input="someProp = $event.target.value">

Which, as far as I understand, is exactly how React handles it and is deemed one way binding. ¯\\_(ツ)_/¯

<comment><USER51> We seem to be about to start going in circles so I'm cutting here with one last remark: For what it's worth, in Angular one can also make the events explicit, and yet in there it is called two way binding.

</comment></comment></comment></comment></comment></comment></comment><comment><USER53> Chocolate vs Vanilla argument here

        while(true){
          if(dislikeAllCurrentFrameworks?()){
            inventNewFramework()
          }
        }

</comment><comment><USER54> This is why I like Aurelia, its much lighter in terms of speed and amount of code, while still being a fully flared framework like Angular. Sure theres React/Redux Vue/Vuex but why do that setup when you can literally go au new hit enter about 4 times and your app is ready to code and build.

</comment><comment><USER55> Article is basically why use React over Angular.

One thing though - Facebook succeeded because of the sheer amount of money plowed into the team. Our team is succeeding with Angular at the moment and feel pretty strong that it solves our front end rather splendidly.

Disclaimer - I do like React, it has its place.</comment>


Using Repository Analysis to Find Single Responsibility Violations - <AUTHOR> https://michaelfeathers.silvrback.com/using-repository-analysis-to-find-single-responsibility-violations

<comment><USER2> That's an interesting approach to cohesion. Historical updates certainly seem an underused resource.

For me, though, both coupling and cohesion have become a little ... muddled ... [http://edmundkirwan.com/general/c-and-c.html](http://edmundkirwan.com/general/c-and-c.html)</comment>


Amazon Elasticsearch Service - <AUTHOR> https://aws.amazon.com/blogs/aws/new-amazon-elasticsearch-service/ <comment><USER2> Seems very expensive compared to just running ES on instances yourself. Using i2.xlarges (as we do for our ES cluster) it's $1.194/hour for managed ES and just $0.853/hour for spot i2 instances. If you're will to reserve for a year, it's only $0.3555/hour.

Given how easy ES is to operate, I don't know why anybody would pay for a less flexible, more expensive hosted version.

<comment><USER3> > Given how easy ES is to operate, I don't know why anybody would pay for a > less flexible, more expensive hosted version.

Easy. Amazon's service is fully managed. Getting ES running on EC2 is easy enough. Making it fault tolerant, automated backups to S3 and multi-az capable, takes more work. Even more to make sure it works properly.

Add the time and complexity required to test your recovery/tolerance/redundancy plans, and you pretty much lose out on the savings.

Given the choice of spending 2-3 days getting everything configured right, vs letting Amazon deal with it, I'd pick Amazon.

Using platitudes: the time I save not dorking with infrastructure is time that I can spend solving my customers problems.

<comment><USER4> +1. This is the reason I pay for Amazon RDS/Aurora, where the price difference versus the same EC2 instances is even greater. Sure I could set up a database... and replication to another database... and script scheduled snapshots... and build monitoring and fault tolerance against all the ways things can break... but by the time I've set all that up, I've wasted a week or more building servers instead of building a business.

<comment><USER5> Are you using aurora? How's your experience been so far? It sounds interesting but I haven't heard much real world experience yet.

<comment><USER4> I'm running W3Counter on it now. That's ~100GB of data and a couple hundred queries per second. It's about equal read/write load with one insert and one select for every page view I log. Nothing you can't do on a single server, but it's all I can talk about.

I was renting two ~$300/mo servers at Softlayer to run MySQL (Percona), with one as a backup + failover + to run my monthly browser/OS market share reports against without killing the website by overloading the main server. I regularly spiked high loads that killed latency anyway this spring. I was going to have to upgrade soon anyway, so I decided to try out Aurora during the free preview period, and migrated everything over there one weekend.

Turns out a single R3.Large instance (the smallest) was more than sufficient. It's sitting at under 25% CPU and 50% memory usage right now, which means there's plenty of room to grow too. I'd say performance is as good or better than native MySQL based on that. I'm paying less now than I did for the two servers, and get more for it, with free multi-AZ replication, nightly snapshots, and the ability to spin up a live replica in just a few minutes to run backups/large reports against, then shut down and only pay for the hour.

<comment><USER6> That's awesome; thanks for sharing. To me, the managed aspect where I don't have to worry about monitoring the hard drive space is a big win.

How long does it typically take for the live replica to come online?

</comment></comment></comment></comment></comment></comment><comment><USER7> Will Elasticsearch ban queries for AppleTV and Chromecast?

<comment><USER8> Solr and Sphinx

</comment></comment><comment><USER9> Interesting, This would be Amazon's version of Found ( [https://www.elastic.co/found](https://www.elastic.co/found) ), which is Elastic's (makers of elasticsearch) aws based cloud solution. I wonder what this means for cloud search?

I should note that I work for Elastic on the Logstash team and used to work on Found.

</comment><comment><USER10> We will definitely be checking this out. Our experience with another vendor and ES has not been great. From having the whole cluster come down when we're doing batch inserts for initial loads to having 10s timeouts on random queries during low activity windows with the vendor saying "dunno, everything looks good here" (when we measured that this 10s were spent waiting for ES).

<comment><USER11> If you're looking for a search backend without having to worry about managing infrastructure, you should check out Azure Search. I'm a dev on the product. If you're interested in trying it out let me know. You can ping me at my username @microsoft.com if you have questions or need pointers.

<comment><USER12> Side question: Do you know if Azure will every allow traceroute through their network?

<comment><USER11> no idea, sorry

<comment><USER12> ipv6 support?

</comment></comment></comment></comment></comment><comment><USER13> For reference:

[https://aphyr.com/posts/317-call-me-maybe- elasticsearch](https://aphyr.com/posts/317-call-me-maybe-elasticsearch)

And the updated:

[https://aphyr.com/posts/323-call-me-maybe- elasticsearch-1-5-...](https://aphyr.com/posts/323-call-me-maybe- elasticsearch-1-5-0)

</comment><comment><USER14> Well that's a tiny bit annoying, since I just set up our own cluster 3 days ago to centralize all our logging...

</comment><comment><USER6> I wonder what this says about Amazon CloudSearch?

<comment><USER15> It says it is not very good. There are a lot of problems with Cloudsearch. By contrast, Elasticsearch is great and not too difficult to run yourself in AWS, or indeed elsewhere.

Aside from product differences, Cloudsearch was phenomenally expensive, particularly if you had a larger dataset but low read/write volume, as Cloudsearch did not use EBS (at least not in a way you could control), unlike RDS for example.

</comment></comment><comment><USER16> Will amazon support the head plugin? Can we enable our own plugins?

<comment><USER17> They support just ICU and Kibana. Shield is not there too.

</comment></comment><comment><USER18> This new aws service offer is really boring, I don't see a real advantage migrating to it anytime soon.

What will be the expectation here:

\- Autoscaling functionalities out of the box

\- Better speed than on regular EC2 instances (I/O, Network)

\- More visiblity, better monitoring out of the box (e.g. Marvel)

\- Lower pricing than running on plain EC2

Still a long way to go here...

<comment><USER4> RDS seems to be doing just fine with a large markup over EC2. Why would the managed version of a service be lower priced than the same infrastructure being managed?

<comment><USER18> Amazon has more possiblities to run a really huge cluster and balance the different load peaks of the search nodes. The whole business model of AWS is based on this... but you're right as well, price isn't everything and comfort worth money. And yes, I love RDS as well, especially Aurora... it's a great deal!

<comment><USER19> Running one big cluster and using application level separation would make lots of customers apprehensive...

</comment></comment></comment></comment><comment><USER20> Opinions on the price being high seem to miss the point of AWS.

AWS is very expensive relative to other clouds, with exceptions so some _very_ nice services (S3, SQS, SES, Route53).

"Core" (Very Important™) services such as EC2/RDS are (appropriately) expensive due to the tooling and high availability options available. I'd expect the tradeoff for their hosted ES to be price, since I'm buying availability and less headache, not just the search service.

I know for sure that I don't know enough to monitor JVM applications. I'd love to pay for their ES service if/when it made sense for a business.

</comment><comment><USER21> It seems weird to handle the number of instances on top of AWS service, I mean it's AWS they should provide a solution where you don't have to think about that...

It looks like ES installed by Puppet on top of EC2.

</comment><comment><USER22> I thought there was already an AWS Elasticsearch product? Am I remembering something different or is this coming out of beta or something to that effect?

<comment><USER23> There is CloudSearch however it doesn't support schemaless stuff.

Looks like this is AWS' answer to that.

There's also the issue of CloudSearch taking in document batches rather than individual documents, which means you have to do a fair bit of more leg work to get your stuff in there. ElasticSearch can take in Logstash inputs which is handy and quite performant.

Plus a lot of data analysts are used to Kibana so there is some appeal there.

</comment></comment><comment><USER24> How would this compare to Algolia ? Does anyone have experience with elasticsearch and algolia to shed some light on this ?

</comment><comment><USER25> Nice, they even support Kibana.

Just few days after I managed to finally set up ELK stack correctly by hand.

</comment><comment><USER26> sa-east-1 gets the short straw again.

> The service does not support any i2 and r3 instance types in the sa-east-1 > region.</comment>


The fiddle that prints phonetic transcription for a given text - <AUTHOR> http://jsfiddle.net/andrey_cheptsov/rzMc3/

<comment><AUTHOR> Click on a transcription to listen pronunciation</comment>


The jet plane that shot itself down - <AUTHOR> http://datagenetics.com/blog/august22017/index.html <comment> M-arcus Interesting. I've always wondered if this scenario could really happen, turns out, it already did.

Glad that the pilot survived.

</comment><comment><USER2> Does gun propellant really use oxygen from the air? Don't think so

<comment><USER3> You're right. I'll fix this later this afternoon! Thanks. /\/ick</comment></comment>


Album de Statistique Graphique - <AUTHOR> https://richardbrath.wordpress.com/2018/12/31/album-de-statistique-graphique/ <comment><USER2> What stands out to me (other than this being an amazing collection, especially as a big Edward Tufte fan) is the use of radial/web diagrams.

The idea that variables can have relationships in more than 2-dimensions seems to have been lost.

I'm actually using a d3 version of these for a blog post I'm working on about machine learning and data companies, and the example code for creating beautiful radial charts (not mine) can be found here: [https://github.com/kolektiv/maturity- radar](https://github.com/kolektiv/maturity-radar)

As someone who has developed a product that uses Sankey diagrams to represent complex relationships, this catalogue from the past gives me some hope for the future. :)</comment>


Essential Maths for Games Programmers - <AUTHOR> http://www.essentialmath.com/tutorial.htm

<comment><USER2> Damn, I read "Essential Maths Games for Programmers" and was disappointed to find old-fashioned book learnin'.

<comment><USER3> I was disappointed that most of it is Powerpoint, dead links, and blank pages.</comment></comment>


Show HN: Your Face Is Your Mouse - <AUTHOR> https://twitter.com/JColeH/status/1120093682852618240 <comment><USER2> Eye tracking and smile for press? Disabled interface?

<comment><AUTHOR> You can also map hotkeys to left or right clicks. This is particularly convenient when I am in a keyboard-only workflow.</comment></comment>


50% off O'Reilly ebooks and videos today - <AUTHOR> http://shop.oreilly.com/category/deals/cyber-monday.do

<comment><USER2> Can anyone comment on the quality of O'Reilly books these days? I used to read them long long ago but then their editing standards seemed to take a dive and companies like Apress and pragprog started producing much better quality.

<comment><USER3> I can only speak anecdotally, not across a wide sample of books. But as an author, O'Reilly's editing staff is _way_ better than Apress.

I haven't written for the prags but I like their books.

</comment></comment><comment><USER4> So far I haven't found a single book that I can't get from Amazon for less than their 50% sale price (or with a $1 difference). I think they need to re- evaluate their pricing structure.

<comment><USER5> What I dislike about Amazon, though, is that you don't get the PDF, only "Kindle Edition".

<comment><USER6> I think he's referring to the print books.

I buy ebooks from o'reilly; idk why anyone would purchase a technical ebook from Amazon if they weren't forced to.

</comment></comment></comment><comment><USER7> i cant help but wonder why on earth they're giving promotions without preparing their infrastructure. reminds me of "free ebook from Packt" promo that lasted for days but never managed to get any since the website was always down.

the one that went well was Pragmatic Programmer, bought an Arduino ebook. it was posted here last week. those who complain that book promo shouldn't be here have their reason, but i'm glad i see this kind of promo in HN.

<comment><USER8> I missed the PragProg one, slightly disappointed now I've found out about it.

The free ebook from Packt was a slight disaster, hopefully they're getting on top of it now.

<comment><USER9> So far as I know, the PragProg discount is still valid[1]. I think it's valid all day today. Load up your cart, and as you go through the purchasing process, there's a button to apply coupons. Click there, and enter the word TURKEY (not sure if it's case sensitive; all caps works for me). That should get you a 40% discount. Enjoy.

[1] Yup, just confirmed. Here's the original blog post, which I'll submit to HN as well: [http://pragprog.com/news/black-friday-cyber-monday-40-off- sa...](http://pragprog.com/news/black-friday-cyber-monday-40-off-sale).

<comment><USER8> Oh, awesome thanks. Got myself confused on the expiry time.

</comment></comment></comment></comment><comment><USER10> > Our site is temporarily unavailable due to routine maintenance.

Isn't it weird to do a maintenance during a sale?

<comment><USER11> I suspect they don't mean that. I'll wager that's a default message and that, in fact, their site is overloaded.

</comment></comment><comment><USER12> I'm fairly certain that if you create an account with o'reilly, you get a 'buy one get one free' code for their ebooks, so with two books it basically works out to be 50% off anyway, any day of the year.

<comment><USER13> I'm getting 60% off today, not sure why. Also, one could wish to buy just one book and would still get a good discount today on that one instead of paying the full price for one and having another as an offer.

<comment><USER12> You get 60% off on orders over $100, so you've probably stocked up on ebooks :)

<comment><USER14> I know I did :)

Bought 6 ebooks, and I'm happy it was posted and upvoted on HN, otherwise, I would have missed it.

</comment></comment></comment></comment><comment><USER15> I could use a good book on learning Javascript. Anyone have any recommendations?

Background: I'm not a programmer, I just do some things in my spare time. I did a little something with Django and Bootstrap over the weekend, but I could really only use Bootstrap for the CSS to make it look good without knowing how the Javascript end works. So I'm not completely new to programming though still really a beginner but would be completely new to Javascript.

<comment><USER16> Eloquent Javascript seems to be pretty highly recommended. You can buy it from O'Reilly, but the author also offers it for free online[0].

0: <http://eloquentjavascript.net/>

<comment><USER17> (The pay version is newer. I haven't read it, can't comment on the differences.)

<comment><USER18> Is it? The last modified date on the free web version seems to be October 30, 2012. That's less than a month ago, whereas the print version on Amazon was published in February 2011.

<comment><USER17> eloquentjavascript.net says "I have published a revised version of the book on paper. The structure of this version remained largely the same, but the whole text has been thoroughly edited and updated."

</comment></comment></comment></comment></comment><comment><USER19> The DRM-free is nice, and they get some large amount of points for doing so.

But ads in hacker news, masquerading as an article? Can we keep commercials out please?

(interesting to see that people are not contesting that the link/title is an actually an ad, but that people are arguing that ads should exist because they are useful. The role and appropriateness of ads alongside other content looks to be a controversial subject.)

<comment><USER20> Who thought it was an article? Some sort of O'Reilly coupon gets posted a couple times a year. In fact, deeply discounted tech books from most publishers are welcome.

What you're suppose to do here is recommend great books on the list.

<comment><USER19> Are you saying that the goal of hacker _news_ is to post commercial ads with coupons for people to see? Really? that's the goal of this site?

I wouldn't mind an article which talked about different books and in that context, which just happened to mentioned that there was a sale going on with 50% off. That would give room of discussion. But this is just a text banner ad with a open comment field. If it had been a real banner, positioned at the right side of the screen, I would not complain as it would be clear that its an ad and not ordinary content. I would even consider a small disclaimer tag in the title ([hacker news commercial] to be fair, but to actually be listed as any other news article?

<comment><USER21> > Are you saying that the goal of hacker news is to post commercial ads

Are you suggesting that O'Reilly paid to have this link posted to HN? That's not correct. They didn't. Someone saw the offer, knew that many people on HN would find it useful, and posted it.

It's valid to not like it, and to ignore it or flag it, but don't dislike it for something that didn't happen.

<comment><USER19> I dont think they paied for it, and I dont dislike O'Reilly. They didnt do anything here beyond having a sale and selling non-drm products. Like I initially said, they get major points for this.

I only pointed out that this is an ad promoting a sale. No one seams to contest that. What people seems to have an issue with is the claim that ads should not sit alongside other articles.

It would be interesting to hear why having a ad promoting a sale posted in a news aggregate is a good thing, or why in this case we should have an exception that sites like amazon or newsegg does not deserve. After all, they too have done 1 day's sales, some very interesting for hackers. Thus, I am failing to find an attribute that this ad differ from all other ads. Does anyone has an insight to what that attribute is?

<comment><USER22> _What to Submit_

On-Topic: Anything that good hackers would find interesting. That includes more than hacking and startups. If you had to reduce it to a sentence, the answer might be: anything that gratifies one's intellectual curiosity.

<http://ycombinator.com/newsguidelines.html>

</comment></comment></comment></comment></comment></comment><comment><USER23> FYI, _every_ day at O'Reilly is 50 percent off ebooks. If you're a logged in member, one of the perpetual in house ads will be for a code for "Buy 1 ebook, get 1 free"

Also FYI, the most recent purchase I made was a book that made HN's front page last week: interactive Data Vizualization for the Web. And I highly recommend it

<http://shop.oreilly.com/product/0636920026938.do>

<comment><USER24> Thanks for the recomendation, I just bought the book. I am trying to learm more about visualizations (and D3). Any other recomendation?

<comment><USER23> The cupboard seems dry in terms of D3 right now. But there seem to be quite a few good books with R. The ggplot2 book is great, but I don't think it's on O'Reilly [http://www.amazon.com/ggplot2-Elegant-Graphics-Analysis- eboo...](http://www.amazon.com/ggplot2-Elegant-Graphics-Analysis- ebook/dp/B0041KLFRW/ref=kinw_dp_ke)

</comment></comment></comment><comment><USER25> website is slow as molasses. Cant even buy a book!

<comment><USER26> Apress.com has a $15 eBook special on all Apress and Springer eBooks today only and they were already very slow at midnight Eastern Standard Time when it started!</comment></comment>


Ask HN: Looking for hackers in Argentina - <AUTHOR>

Hey guys
Im a designer living in Buenos Aires, AR.
And Im currently looking for kick ass local hackers to build projects together.
Im always looking to meet new people and build stuff... so if you are coder living in Buenos Aires you should totallys send me an email!
Lets chat,
Saludos! <comment><USER2> I just got back from spending 3 months in Argentina. I'd recommend the Urban Station coworking spaces as a place to meet hackers. I met some cool tech folks at their Palermo SoHo location, and I think they just opened another location closer to the Microcentro.

</comment><comment><USER3> Brazilian here. Anyone else in to create a "HN wannabe" for us southern guys?

Edit: no hijack intended; there are a bunch of hackers in Foz do Iguaçu, if that matters.

<comment><USER4> I'm Brazilian and I'd really like a HN like community for us. I know that it won't be much active, but it's a good starting point.

<comment><USER5> Hey, I'm Brazillian too! What if we start with a subreddit?

<comment><USER3> Just created: <http://latinoup.org>

I'll just wait for the DNS propagation and then I'll "Tell HN".

</comment></comment></comment></comment><comment><USER6> Don't want to hijack you but I'd love if anyone in Uruguay contacts me! I'm not there yet but we're opening an office down there hopefully at the end of the month!

<comment><USER7> ben, i'm from uruguay, feel free to contact me if you need any pointer.

Regards

M

<comment><USER6> There's no email on your profile but you can get me at ben@playtomic.

</comment></comment></comment><comment><USER8> Hola Nicolás, I am from Buenos Aires. Feel free to contact me, my email is in my profile. It is always great to meet new people!

</comment><comment><USER9> I'm not affiliated with them but 10pines.com is in Buenos Aires

</comment><comment><AUTHOR> I think im gonna call the Internet Police for über hijacking

<comment><USER3> Sorry :)</comment></comment>


A Survey of Non-Rails Frameworks in Ruby - <AUTHOR> http://blog.codeship.com/a-survey-of-non-rails-frameworks-in-ruby-cuba-sinatra-padrino-lotus/

<comment><USER2> I think Roda[0] should also be on this list.

From its Github[1] page, it cites Cuba and Sinatra as inpiration[2].

[0]: [http://roda.jeremyevans.net/](http://roda.jeremyevans.net/)

[1]: [https://github.com/jeremyevans/roda](https://github.com/jeremyevans/roda)

[2]: [https://github.com/jeremyevans/roda#inspiration](https://github.com/jeremyevans/roda#inspiration)</comment>


Reading the Classics (UCB Course by Papadimitriou - mostly Game Theory)   - <AUTHOR> http://www.cs.berkeley.edu/~christos/classics/cs298.html

<comment><AUTHOR> There is a list of readings in the philosophy and history of science in the web page. Link:<http://www.cs.berkeley.edu/~christos/classics/readings.txt></comment>


At 20 Amazon is bulking up. It is not yet slowing down - <AUTHOR> http://www.economist.com/news/briefing/21604559-20-amazon-bulking-up-it-notyetslowing-down-relentlesscom <comment><USER2> I'm amazed by Amazon. Some of their moves follow a playbook. Books -> Clothes -> Diapers. A non-technical CEO turning the company into an API machine that outsources it's own technology... Every textbook would say crazy, but he's on to something. Makes one wonder about the drones.

<comment><USER3> > _I 'm amazed by Amazon_

I, on the other hand, am underwhelmed.

Their AWS services is a pretty cool tech and business.

But as for their other stuff:

1) Their core business (the store) barely makes any profit. Their profit margins are razor-thin, and until recently operated at a loss IIRC.

2) Their ebooks and music store are ho-hum.

3) Their hardwares, Kindles (Fire and plain) are simply loss leaders for content sales. Which (1) is not that profitable in itself anyway. Not that difficult to sell stuff like readers and tablets at a cost or slight loss.

Anything else I forget about?

<comment><USER4> > 1) Their core business (the store) barely makes any profit. Their profit > margins are razor-thin, and until recently operated at a loss IIRC.

The choose to do this. I read an excellent article on it some months back but can't find it again, but suffice it to say there is far more to their low margins than you think.

<comment><USER2> Yes - the general idea is they could monetize their business to get profits now, at the expense of future growth later. They write to their shareholders to be patient, so it's transparent.

</comment></comment></comment></comment><comment><USER5> Reasons not to buy from Amazon:

[https://stallman.org/amazon.html](https://stallman.org/amazon.html)

<comment><USER6> Hmm. Every time I see the name Stallman I just conclude it's all about materials not distributed freely. Essentially, don't buy anything from anybody who don't support free redistribution (iTunes, App store, Play Store, etc).

<comment><USER5> To conclude something from a name without reading the works and criticizing it factually is just prejudice.

<comment><USER7> But in cases like this, it's useful prejudice.

I for one don't need to read every rant by RMS against Digital Restrictions Management, _even if I agree with him by and large_. I have much better things to do with my time. A lot of useful prejudice work that way in a lot of domains.

I have my own personal boycotting policies, and one of them is to never, ever buy digital media with DRM. Which, strangely enough, Amazon has long allowed me to avoid if the rights holder allows, e.g. I have a nice set of MP3s I got from them for a CD of Scandinavian music that in physical form was by then out of print and way too expensive.

They also tell you if a Kindle digital book has no DRM at the bottom of it's description. _They don 't really care_, and I respect their choice to abide by rights holder's restrictions and sell the stuff anyway.

<comment><USER5> No it is not useful in this case, because Stallmanns page is much more about than just materials not distributed freely. For your convenience the headers of his page about Amazon:

* Restricting and Shafting Customers

* Censorship

* Exploiting workers mercilessly

* Shafting others in the publishing world

* Dodging taxes

* Political harm

<comment><USER7> The additional stuff pretty much falls into categories of:

Already covered by my policies.

Don't believe it.

All big companies have some insanities; if that bothered me I'd be living off the grid.

Don't think it's a problem.

And RMS and I have _very_ different political views ... and a lot of his are remarkably uninformed (disclaimer: I knew him rather well in the early '80s, e.g. we were roommates when he started the GNU Project).

This covers the whole Political Harm section, I'm "right wing" myself, so it's not axiomatic I'd mind ALEC's lobbying, the Left's campaign against "voter suppression" is a existentially dangerous campaign for more voter fraud, and Stand You Ground laws have nothing to do with any sort of "Shoot First" policy. Heck, I'm not sure I've even seen that insane phrase before, but the gun-grabbers are ever inventive in their total dishonesty. (RMS is also one of the last people in the world you should be paying attention to when it comes to the self-defense area, it's a miracle he's still alive.)

Note, there's a relevant point in going into details below; this is an area of personal expertise going back to the early '70s:

Stand Your Ground is shorthand/American value invoking propaganda wording simply for having no duty to retreat, nothing more or less, although I suppose if you're a rabbit it's antithetical. It's extremely valuable against abusive prosecutors who insist in the calmness of a courtroom there was some plausible way for you to retreat:

In two Massachusetts cases I'm familiar with, convicting when retreat wasn't really possible, or would have required abandoning a child to the tender mercies of a home intruder. As of late, it's been noted that more blacks have benefited from Florida's Stand Your Ground law than whites....

The major point I'm trying to make is that RMS's sophistication about things outside the domains where he's good, the ones relevant to me limited to computer stuff, is _very_ poor, sometimes to the point of implicitly suicidal, and I have nothing to gain from reading them, as I have just reconfirmed.

But e.g. when he coins a new relevant meme, like Digital Restrictions Management, I do pay attention.

<comment><USER5> Thankfully a lot of bother care about insanities. They are in the grid of thinking, good people. The whole free software movement is a an evidence that a lot of people care about insanities. RMS is the founder and forerunner of this impressive socio political movement.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Interesting: how little was said about AWS.

<comment><USER9> AWS was 4% of Amazon's revenue for 2013. I think about 4% of the article was about AWS too... Seems appropriate.

<comment><USER10> That said, AWS has something like 80% profit margin [1] vs almost no margin for the rest of the business :)

[1] [http://venturebeat.com/2013/09/05/amazons-mountain-of- margin...](http://venturebeat.com/2013/09/05/amazons-mountain-of-margin-in- cloud-services-over-80-profit/)

<comment><USER11> Disclaimer: I'm a software engineer working for AWS. But not on EC2.

I feel the margin number conclusion is deeply flawed for variety of reasons.

There are some questions the author cannot have answers for, that greatly change the margin numbers for EC2. A couple that comes to mind are:

1\. What percentage of time are customers being charged for the available servers? 2\. What percentage of instance hours are being charged at on-demand prices, vs reserved instance?

Also it completely ignores services that makes EC2 stand out from plain hosting, and adds much value, such as AutoScaling, CloudWatch, Elastic Load Balancing, OpsWorks, and Elastic BeanStalk. And believe me when I say that support cost is NOT trivial. In many cases, the number of engineer hours involved makes the support pricing look like a real bargain.</comment></comment></comment></comment>


Ask HN: Is Hacker News too Anglo centric? - <AUTHOR>

I don't think the HN community gives enough value to the input of entrepreneurs from countries other than the USA. This is even more true about countries with an emerging  market. A company (Inode Entertainment) from the capital of Chihuahua (my home state) in Mexico, got a 100 million downloads (from different games), they are profitable and growing. What's even more interesting, they achieved  this success on Nokia platforms and nobody seems to  take notice, this  is insane.<p>P.S. I have no direct/indirect interest in this company, I don't even live in the same city. I am just expressing my love/hate for american IT dominance. <comment><USER2> If you find relevant news/articles from other countries, please post it, but make sure it is in English. We do get some European and the occasional Asian piece of news, but it would be nice to get more South American and African news as well.

P.S. Where I come from, "Anglo" does not mean "American".</comment>


Show HN: Iran's army prevents couchsurfers to host foreigners - <AUTHOR> https://www.couchsurfing.com/people/peace-gulf <comment><USER2> Not a 'Show HN' but an (important) news item, should be re-titled</comment>