The problem with Angular - <AUTHOR> http://www.quirksmode.org/blog/archives/2015/01/the_problem_wit.html <comment><USER2> I don't really follow many of the author's objections. I think he or she left out a lot of reasoning.

 _" This code reminds me of a simple server-side scripting language such as JSP or ASP that's used to fill HTML templates with database content. These languages have their place in the web development stack — but on the server, not in the browser."_

Says who? What's the rationale for where a language belongs?

 _" Although templating is the correct solution, doing it in the browser is fundamentally wrong. The cost of application maintenance should not be offloaded onto all their users's browsers (we're talking millions of hits per month here) — especially not the mobile ones. This job belongs on the server."_

Again, based on what?

 _" My point is that I expected far more front-enders to embrace Angular. I have the feeling their number is surprisingly low — see also the problems my clients had with finding good front-end Angular consultants. "_

More stuff based on feeling rather than empirical evidence. And clients have trouble finding good front-end developers these days no matter what the technology is.

 _" A more important reason may be pushback from the JavaScript community. Angular has evoked some serious criticism."_

Find me a framework that _hasn 't_ evoked serious criticism from some corner of the Internet.

Look, I'm no fan of Angular. In fact I've never written a thing in it. It doesn't really fit my style of front-end development (and I'm a Java programmer!). I'm more of a libraries-over-frameworks guy. But this article is not very well-reasoned.

<comment><USER3> Just thought I'd add a bit of meta context: PPK (the author of the article) is perhaps the first person in the js community to catalogue detailed per-feature cross-browser compatibility tables. You could say he's one of the old timers.

PPK has a very strong background in cross browser testing and high level technology evaluation for non-techie audiences, but (from my impression of reading this article, at least), it doesn't seem like he has much experience w/ Angular per se and sounds like he is writing his opinions more based on blogosphere echo than personal time spent with the framework (clue: lack of Angular-specific terminology criticism)

Some of the criticism is valid, I think: hiring "Angular" devs is hard, partly because of the over-engineered-Java-like feel. I've seen a few times overconfident frontenders think they could pick up Angular through Google-Fu just as they picked up jQuery, and then hitting a brick wall face first, with a looming deadline to add insult to the injury. The reality is that a lot of people (especially frontend people) don't have the CS foundation to understand why and when the design patterns prevalent in Angular/Java are useful (or even what patterns exist to begin with).

@jasonwocky The snippets you highlighted do seem a bit like a "get-off-my- lawn" reaction from the author. SPA architectures certainly have their places, and it does feel like the author hasn't had experience w/ building heavily dynamic UI apps.

>> Find me a framework that hasn't evoked serious criticism from some corner of the Internet.

I think the point is that Angular criticism is much more prominent (and sometimes vitriolic) than other frameworks.

<comment><USER4> > _The reality is that a lot of people (especially frontend people) don 't > have the CS foundation to understand why and when the design patterns > prevalent in Angular/Java are useful (or even what patterns exist to begin > with)._

That's hardly fair. Design patterns are not that difficult conceptually and in my (admittedly limited) experience Angular doesn't really introduce anything new. It's not hard to pick up because devs are lacking foundational skills. It's hard to pick up because it's overcomplex and difficult to adopt in pieces. Despite claims that it's easy to "add as much or as little of AngularJS to an existing page as you like", there seem to be no examples of piecemeal adoption in the docs. I'm sure someone with Angular experience could plug in a bit of Angular to an existing app, but someone just starting apparently has to choose to 1) go all in, 2) spend a lot of time learning Angular, or 3) use something else. If many competent devs are "hitting a brick wall face first", that seems to be indicative of problems with the framework.

Also, this is somewhat tangential, but I'm not sure software design patterns are part of computer science anyway. They belong to software engineering, which is really not the same thing.

<comment><USER3> > in my (admittedly limited) experience Angular doesn't really introduce > anything new

If one's coding experience is limited to jQuery et al, it does introduce a lot and very fast: you can't really get very far in Angular before stumbling upon IoC and services/factories, for starters. Just look at the comments for any article that talks about Angular service/factory/provider/etc to see that even the most basics of patterns are not exactly universal knowledge.

A lot of the complexity you talk about originates from other patterns. More advanced tools like parsers/formatters, interceptors, decorators are there specifically to be alternatives to procedural spaghetti code and it's hard for a lot of people to even guess that these tools exist, let alone figure out why they should (or not) use them.

To be fair, it's true that a lot of complexity is very much Angular's fault and not a lack of preparedness from developers (the directives API and the digest system come to mind).

But my point was that it's hard to find Angular devs. Around where I live, a typical non-angular frontend job pays between 60-70k (generous extrapolation from salaries of people I know) and might involve a job interview that talks about responsive design. An Angular job easily pays 90k-110k (from job interviews I've been to) and might have a job interview that talks about algorithms. Even though both are considered "frontend" jobs, the former is more likely to be filled by a self-taught person that reads html5rocks or whatever, while the latter is more likely to be filled by someone w/ a CS degree and backend experience (which, here, usually means either Java or .NET). I think we can agree that the skill sets for the two jobs don't overlap much, and the dissonance in qualifications is not merely because of the level of complexity in a tool.

> Also, this is somewhat tangential, but I'm not sure software design patterns > are part of computer science

If we're going to be nitpicky and pedantic, I said knowing _when and why_ to use them is part of a CS foundation. s/CS/software engineering/, as long you get the main idea.

<comment><USER4> My impression of Angular is that it makes simple things complex and that it's poorly designed and engineered. I think that it tries to do too much, and tries to be too clever, and doesn't try at all to be usable (beyond maybe trivial examples, which could still be simpler, honestly). It speaks very poorly of Angular that many (most?) people familiar with all the tools it builds on (CSS, HTML, JS) find it difficult and unpleasant to work with.

It may be the case that only people with deeper engineering experience can wrangle it because they have the necessary background. It could also be that people who are used to working with friendlier tools just aren't willing to put up with Angular's crap.

<comment><USER3> FYI, I actually agree with you that Angular is overly complex and has a lot of serious problems. I even wrote about my gripes with it back when Angular was still somewhat "cool" (here: [http://lhorie.blogspot.ca/2013/09/things-that- suck-in-angula...](http://lhorie.blogspot.ca/2013/09/things-that-suck-in- angularjs.html) and here: [http://lhorie.blogspot.ca/2013/10/things-that-suck- in-angula...](http://lhorie.blogspot.ca/2013/10/things-that-suck-in-angularjs- follow-up.html) ), and last year, I wrote a micro-framework of my own to get away from the frustrations I was getting w/ Angular ( I talk about it here: [http://lhorie.github.io/mithril-blog/lessons-learned-from- an...](http://lhorie.github.io/mithril-blog/lessons-learned-from-angular.html) ).

A lot of the stuff I wrote there is still relevant.

<comment><USER4> I didn't realize Mithril was yours. Seems nice, though I haven't used it myself.

The stuff you wrote is valid. I'm just not sure that dev ability is the major factor making it harder to hire Angular devs. Maybe I'm wrong. I'm thankfully not hiring Angular devs.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> I usually have a terrible UX with Angular websites, I don't know if the problem is Angular itself or the developers, but these are some of the problems I usually experience:

-No HTML hyperlinks. This means that I can not open pages in new tabs, which it's very frustrating.

-Slow loading times. Static websites are much faster. Even non-cached server-side dynamically generated websites are faster.

-High CPU usage. To be fare my computer (1.4ghz c2s) is almost 5 years old, but using 100% to render a very simple "About us" page is ridiculous.

-Broken style when using some add-ons. This _only_ happens with Angular.

<comment><USER6> No HTML hyperlinks is an annoyance, especially since part of Angular is being in the DOM, but that is something that can be handled, the lazy method is to just not do it. I guess that is something I like in a framework or library, that the laziest method it promotes does the most work by default.

<comment><USER7> The point of a framework though is to remove the boilerplate, best-practices should be part of a front end frame work's default settings. The problem with Angular's popularity is that it's often used for bad purposes (including in their own guide as an e-commerce tutorial). Angular's strengths, solely IMO, play up to large single page apps comprised of many small angular apps, apps that don't use hyperlinks and aren't driven by sharing or SEO.

There's a lot of weird choices in Angular, but it's not broken though, and enterprise will still use it because it is backed by Google, only a few frameworks are backed by big companies, and it's less of a departure than the other frameworks.

React and Backbone aren't frameworks in the sense that businesses need frameworks, where repetitive decisions have conventions.

I just wish we'd stop trying to wedge these frameworks in to the wrong types of projects. Angular is great, for our authwalled web apps, from my use. I bet it would be for other people with the same needs, and wouldn't be for people who are trying to build marketing sites, blogs, or e-commerce.

Edit: stray keystroke.

<comment><USER8> I'm working on a very large, single page app in Angular. I use HTML links everywhere, and I thought that was standard. The router makes it so much easier to use regular hyperlinks for navigation.

</comment></comment></comment></comment><comment><USER9> AngularJS is a great example of over-engineering. Pretty much everything is needlessly complex and poorly designed. Learning to use it was difficult, and watching new employees struggle with it was painful. Newer libraries that take a virtual DOM approach like MithrilJS are so much nicer to work with. They are easier to understand, simpler, and faster. I wrote AngularJS applications professionally for a year at my last job, and in hindsight I wish we had spent more time evaluating the other options available at the time. AngularJS got us away from a structureless jQuery mess (not blaming jQuery btw, but technical debt from an application that grew too quickly), but what it created was a new kind of mess that is much harder to fix now that the team bought into the "Angular way".

<comment><USER10> Wasn't the point of Angular, bach in the days, that it isn't over-engineered and was put together by some guy at Google to show that it can go easier than with GWT?

I remember, 2 years ago, I was on a JS-meetup, and some guy was rambling about how Angular is the hot shit.

Funny thing was, he always said "yeah we had often the feeling, that something was fundamentally wrong with Angular, but after a few days into a problem, we found that we were wrong and Angular got it right."

His main argument was, that he uses Angular, because it feels better to use something "a guy at google did for fun"

<comment><USER11> Which sounds more like pop-culture (to quote Alan Kay) and not science or engineering...

The guy might as well rock a yo-yo for the way he's into fads...

</comment></comment></comment><comment><USER12> The reality is, Javascript has problems, and smart people disagree about how to solve those problems. The proliferation of frameworks is a symptom, but the frameworks are not themselves the problem. Javascript has some quirks, that is for sure, and then, independent of Javascript, HTML/XHTML has its quirks. Most ambitious sites today are trying to deliver software as a service, but HTML was conceived as a publishing mechanism for documents. The emphasis on publishing brings in some baggage that complicates any conversation about doing HTML right. Consider the holy wars that have raged regarding the word "semantic". There are many GUIs in the world that focus strictly on visual representation and programming mechanics. Think about Java/Swing, or GTK, or Flash. Swing does not aspire to be semantic, it only aspires to give us a GUI for those who would create a GUI app with Java. GTK is the same, it is for programming environments. But Javascript/HTML is given the task of being both a programming environment and also a publishing platform, with semantics and a hierarchical document object model. This is a confusing burden to put on something that most people nowadays only want to use as a programming environment.

In the short run, I do not know what the solution is. I suspect developers will continue to invent new Javascript frameworks in an effort to create sufficient levels of abstraction to ease the pain of development for the Web. In the long run, the solution for the industry will be polyglot browsers, and polyglot protocols, that can work as a runtime and thus give developers the kind of freedom on the frontend that they already have on the backend. Despite the many brilliant minds working on the issue, Javascript is never going to work as the byte-code of the Web. Something more general is needed. On the server, the JVM gives developers a runtime that allows them to use many languages, and many different paradigms: Scala, Clojure, jRuby, Jthyon, etc. We need that kind of flexibility on the frontend. And we need protocols to support that runtime.

<comment><USER13> That sounds nice on paper. But would it not be a security nightmare and result in browser fragmentation?

I rather tell my customers to embrace HTML and a concept where a URI has a main concern and if I want to see that concern, I have to load the page. I like to build web applications that work without Javascript, but enhance the page for better user experience, when activated. (Like the old (sane) times.)

It would be so nice, if I can just mail a link or make a bookmark and when I follow that link, I don't get a firework from a client-side application that tries to magically restore state.

BTW. I have JS deactivated by default and I am not the only one (security measures, privacy, insane amounts of JS loaded by e.g. news pages). I tend to be annoyed, if the page does not work without JS.

<comment><USER14> You're obviously not the only one who deactivates javascript by default, but a quick google brought up numbers of around 1% for users with javascript deactivated. I can see why a lot of developers wouldn't be too concerned about that 1%.

<comment><USER15> It used to be that a significant portion of that 1% (and those that also turned off CSS) were from those leveraging screenreaders some years back; with the uptake of ARIA and better screenreaders, not so much the case anymore.

So there was once a definite use case for supporting them in a B2C context, at least. You still see it in .edu/.gov/.mil quite a bit as a requirement (Sec 508, et al).

</comment></comment></comment></comment><comment><USER16> Rendering on the client makes a lot more sense. By sending the user a template followed by the data necessary to fill it out you only send the structural code once. If the user views 100 pages then that's 99 times you've not had to send the HTML required to display the content. That's good news from a bandwidth point of view, an environmental point of view, and, if you're clever about how you code it, a rendering speed point of view because you only have to replace the _content_ in some DOM nodes rather than repainting the entire template. That can lead to a faster display than swapping in the rendered content for some situations (particularly if the changes are small text elements and you have a shadow DOM available eg reactjs).

If you're doing something _very_ complicated and your users have old or underpowered devices then rendering on the server is sensible, but in the modern web it really isn't appropriate.

<comment><USER17> Sending incomplete pages means those of us that don't run javascript[1] don't actually see your site. First impression matter, and when your page is:

        SomeSite

        {{storyTitle}}

        {{storyBody}}
        {{curPage}} of {{numPages}}

...the common interpretation is "broken site". This current fad of being too lazy to implement progressive enhancement is a regression. Rendering on the server so you server up a _actual page_ is trivial, and you can still provide javascript that loads the next pages faster. Serving up _only_ a template (or worse: an _empty body tag_ ) is insane.

The usual counter is that "javascript is always available" not only ignores the risks, I suspect the claim is based on bad data. How do you know how many people disable javascript? We aren't going to be in most analytics...

[1] for the numerous security and privacy reasons. Running arbitrary instructions in a Turing complete language is a bottomless pit of problems, and "analytics" is still spyware. Google shouldn't get to build a log of every page we visit.

<comment><USER18> I actually would like to get HN's take on this. Maybe someone should submit an HN poll. I'm still of the opinion disabling javascript is an extreme measure and those that do it need to come to terms with whatever broken internet experience they get. While I do think it's worth it to display to the enduser something like _" Looks like javascript isn't enabled; you'll need to turn it on for this site"_, is it truly reasonable to spend development time to make your site functional without client-side javascript? Probably depends on your audience. I bet sites that are more commonly accessed through Tor have people more likely to have javascript turned off.

But yeah, anyone here work webdev where your webapp is expected to fully work without client-side javascript?

<comment><USER19> I've worked on projects where that was the expectation; I've _set_ that expectation for projects.

The reasoning has both been concrete/practical and philosophical (but still practical):

* Mobile processing time is still costly in terms of battery life and performance. And the number of http calls (and their latency) also makes a difference in performance; SPAs tend to have smaller requests but larger numbers of them and it seems to me that's actually the opposite profile of what 3/4G cellular networks are good at. (And while this is all less true on the desktop I'm starting to find it annoying that we're nevertheless finding ways to make things choppy and slow on 2 GHz machines with operations not more complex than _scrolling_ ).

* This is more vague, but I find there's a discipline imposed in starting the conception of the app in terms of plain HTML/HTTP that seems to keep things better organized, while projects that start with a focus on a rich/heavy UI devolve into overspecific yet mixed concerns more quickly. This doesn't work for everything, since some apps just aren't about resources and media types. But honestly, your app probably is. :)

* Being able to debug/autotest with something like curl is pretty nice.

</comment></comment></comment></comment><comment><USER20> This article is ranting about single-page applications written with javascript frameworks. The word "Angular" was thrown as click-bait because it's the latest whipping-boy. From what I read there isn't a single valid complaint that's specific to Angular.

<comment><USER21> I think it is inaccurate to accuse the author of using Angular as "clickbait". To me that term is reserved for titles which don't match the content. Whether you feel every argument could also apply to "every" js framework, you cannot argue that this article was specifically about Angular. It included Angular code, anecdotal references to real Angular projects, and various quotes from sources all about Angular.

The one complaint the author made about the DOM parsing definitely doesn't apply to React, though not sure how Ember and Backbone handle that sort of thing.

<comment><USER20> He could have replaced the Angular code with Ember code and levied the exact same complaints. Re-read the article and try to figure out which complaints aren't also valid for other large JS frameworks. It's clear he's a libraries > frameworks guy, which is a perfectly valid viewpoint to have, but it's cowardly to frame such a debate as a thoughtful criticism of a specific framework because it won't draw rebuttals from nearly as many people who might otherwise feel the need to chime in.

<comment><USER22> He specifically mentions performance many times but has no statistics to back this up. I have created a web app with Angular and it runs fine on old Android phones and iPhones. We don't see any performance problems. Of course YMMV but he/she makes it should like the performance is a really big problem that everyone will get affected by which I thinks is wrong, most apps won't have any major performance problems.

</comment></comment></comment></comment><comment><USER23> I can't get behind the article's idea that Angular is built by people who are non-front-enders for non-front-enders. It's a bold statement that hasn't been supported.

I'm an avid user of Angular and as far as performance goes: you have to be aware of the hefty digest cycle.

We should all be well aware of the downsides of Angular. Just like any technology, there are upsides and there are downsides. When used right, Angular is a powerful tool and the downsides can usually be mitigated.

If I had to help support this article then I would restate the problem statement: the field of web development has exploded and the barriers to entry are nil. Frameworks now have to be built in such a way that they can hold up to the abuse and misuse by less experienced devs.

</comment><comment><USER24> I disagree with this:

"Although templating is the correct solution, doing it in the browser is fundamentally wrong."

We keep forgetting that the decision of where to run the view logic depends on the environment.

We have swung between cpu and bandwidth as bottlenecks in the last decades multiple times, and that's how framework moved between server side and client side mvc multiple times.

No approach is radically different. We moved to thin client when browser were good enough; increase in bandwidth and smaller latency enabled rich client application, making the browser thick again. Handheld devices however are getting more common, so people are facing problems with all the logic and content being manipulated on the client.

It doesn't mean the thick client solution is fundamentally wrong. Also it doesn't mean we have to invent new strategies and pattern to solve this.

When you take a step back from the technology and return to the problem it was solving, it appears to me that we are just back at the thin vs thick debate, and as before this is not an issue of 'which is better', more of 'which is more appropriate to the topology constraints we have'

</comment><comment><USER25> I've always respected the quirksmode blog, but this article is pure FUD.

Many of the criticisms are general to thick client web apps:

 _" I feel that Angular's fundamental proposition blurs the line between front end and back end."_

 _" Although templating is the correct solution, doing it in the browser is fundamentally wrong."_

Others are intentional ignorant.

 _" Ouch. Thou shalt eat thy own dogfood."_

Google also makes GWT and Dart. Should they use all three on every product? The more resources you have and the more demanding your circumstances, the less any general purpose framework will make sense.

 _" In other words, Angular requires you to spend a lot of time to teach yourself the Angular way of doing things."_

What part of this industry doesn't? Put the logic on the server and you're learning Rails, Flask, whatever instead.

 _" Google will eventually stop supporting 1.x."_

Yes, years after they release 2.0. They've been very explicit about that and it's a better policy than most libraries have.

I can't help but get the idea that the author just doesn't like the idea of doing things differently than he always has. Good luck with that.

</comment><comment><USER26> I disagree with the majority of this article.

There seems to be a theme in there that angular is too heavy (Java, templates, performance, time reading DOM on load) for the front-end.

There's really a false premise at play here - that apps these days are as simple as they once were. Imagine for a second that front-end applications are vastly more complex than they once were (because they are). For any of us who have built more complex front end tools, you need something to help you manage the complexity you're now carrying around.

Now the rest of it starts to make sense. More uptake from backend devs than front-end devs? The backend guys have built large complex systems in the past, they know that a tool like this can help them and it's something they're used to dealing with. Prescribed structure to your code? Yup, sounds good - I don't want to spend my day figuring out someone's callback spaghetti or DOM updating triggers from random locations. Front-end templates? If you don't need them and you're using angular you are using the wrong tool for the job.

<comment><USER27>
      > Front-end templates? If you don't need them and you're
      > using angular you are using the wrong tool for the job.

What if nobody needs them, and hence angular ir the wrong tool for the job? ;)

<comment><USER26> Well, true, you don't technically _need_ them :)

If you're building an app that can't be rendered on the server, at some point you've have to update the DOM - templates are one method that allows you to do that in a declarative fashion.

</comment></comment></comment><comment><USER28> Sorry, I'm calling bullshit on his argument for server-side rendering for increased performance.

Consider a typical SPA:

===

In my SPA I load one large html document and javascript file in. The html document contains the 30-or-so templates my system needs to use. The script contains logic and localization data for the user.

This is all cached.

As my users use app, Angular makes calls to my REST/JSON services, transferring just the data it requires with a very efficient encoding. Some of the data is even cached in local storage.

Now, imagine that I've moved the rendering to the server. Instead of transferring a couple of KB of JSON data when a user filters a grid, I have to transfer 30k of HTML markup. My HTML could be smaller, but my designers really like to have class names on all elements. Plus the German text I see is really long.

===

In this rather common scenario the SPA vastly outperforms the traditional server-side render-as-markup sites I was making three/four years ago. Network dominates, especially on mobile. It's not your CPU killing your battery, it's the screen and radios.

If you're making a simple informational site - a newspaper, blog, marketing site - then sure your performance will suffer, but that isn't the problem. The problem is that you're using a excavator to plant a daffodil. You shouldn't even need to use a server-side framework, let alone Javascript.

<comment><USER29> Agreed.

Server-side templates only make sense if you assume that every user action will end up needing the DB. If what you're building is really an _app_, and not just a webpage, you can't expect to compute its UI on the server, making the user wait for a network round-trip for every action.

If your app is built around server-side templates, but your UI doesn't need the server, then you end up with a royal mess. The client has to do DOM manipulation over the rendered page, so now the templates have to include convenient hooks for the jQuery selectors your client will need. There ends up being no clear separation between the server's responsibilities and the client's. In this situation it's much better to just let the client own the UI entirely.

</comment></comment><comment><USER30> This article could be right; I don't know the domain enough to say. And it did clarify for me why some people find Angular so contentious: different tribes. But at a number of points where I was expecting explanation, I got bare assertions.

For example, "These languages have their place in the web development stack — but on the server, not in the browser." Why's that? Personally, I'm looking forward to seeing languages that pay little attention to the divide, so that you can easily move code from one execution context to another as needed.

Or the already noted bit about client-side vs server-side rendering.

Or "Google aims to conquer the enterprise market, and Angular is one of its tools." Do they? I live in San Francisco and know a bunch of people who work at Google, and I have never heard the notion that they are aiming to own a lot of enterprise-developer mindshare. I'm certainly having trouble seeing how increased Angular usage leads to some billion-dollar revenue stream.

Or this, criticizing Angular's origin as a prototyping too: "I don't think that a rapid-prototyping framework should be used for complex, enterprise- level production code." This from a guy whose favorite language was created for some light mouseover animation and form validation? You could say that Rails fits his description precisely, and it seems to be doing ok in the enterprise.

So I wish this had had more meat. As it is, it seems more like a dressed-up version of "Angular does not match my tastes," than the serious examination it wants to be.

Also, fussy language note: please nobody ever say "pulled straight from the horse's mouth". If you're going to use a metaphor, use it fully and well. Pulling something from a horse's mouth is going to be a disgusting and possibly dangerous operation. One _hears_ something straight from the horse's mouth.

</comment><comment><USER31> Written by one of the most experienced JS developers. I wonder how he feels about EmberJS.

<comment><USER32> who is he ?

<comment><USER33> The author of the article we are commenting on.

</comment></comment></comment><comment><USER34> All I know of Angular is the pain our JS devs have using it. If Angular 1.x was so great why is Google tossing it out and building essentially a new framework in Angular 2.0? That would seem an indication that it isn't very good.

<comment><USER35> Because the web is changing at light speed and the frame work they designed years ago requires more than a bandaid to adapt. It doesn't mean it's not "good", it's just not great. The dev world is very opinionated, if you pick the most popular framework in for any language or environment you'll find a heavy amount of "haters" and rightfully so.;

Angular is the leader, they're rewriting to address some of the haters, and are getting more hate for it.

</comment></comment><comment><USER36> The author hit the nail on the head for me: "The biggest problem for many front-enders seems to be that Angular forces you to work in one specific way."

I'm opposed to opinionated frameworks. which is why I don't use Rails. And why with Python I use pyramid/flask instead of django.

And with JS/node, I've found the commonJS+modules approach a far better means to structure my code than any monolithic framework.

<comment><USER30> Opinionated frameworks have their benefits. If you're working in their chosen domain, they're often pretty cheap to use. And for some teams, it's especially handy to have plenty of opinions baked in to minimize arguments over every goddamn thing.

When he wrote, "Many front-enders, on the other hand, who have worked with JavaScript and browsers for years and have developed their own coding style, tend to have their doubts about Angular," my thought was, "Oh god, imagine a team of 10 of those people."

I too have developed many style preferences over the years, but long ago I learned they don't matter nearly as much for project success as having a common style.

<comment><USER37> Exactly yhis is the point PPK is missing imo. A generic structure is offered by Angular, versus the mismatch of libraries, plugins, templating engines (all with their own bugs) that we had before.

I've built a lot of HTML5 over the years, and handing over projects that include your personal preferences and nifty things (even if it's 'Object Oriented' Mootools) can make another developer that has no prior knowledge of it decide to throw everything away and start from scratch.

At least angular provides a standardized and documented way of doing everything.

</comment></comment></comment><comment><USER38> Well-written.

Monolithic and opinionated, in software libraries and frameworks, will always contrast with lite an modular. Some monoliths end up long-lasting (Rails?), some perish – as always, fitting the needs of your target audience is key. "Backend engineers", for a JS framework, is as good a target audience as any.

</comment><comment><USER39> _Adopting Angular 2.0 would require them to allocate massive amounts of budget to rewriting code that already works._

I really wish the team would rename "Angular 2.0" to "Angular for ES6". This would make the rebuttal to this point painfully obvious - one day most ES5 code will need to be rewritten / re-architected for ES6 anyway. The cost of rewriting everything is not just for upgrading a framework from 1.0 to 2.0, but to use a (then) modern language.

</comment><comment><USER40> Now I'm definitely more embedded in the backenders community than the frontenders, but from my perspective Angular.js has been a lot more popular than the author suggests. Of course my only metric for this is hearing other people talk about it.

When we started selecting technologies for a new frontend for our web application about a year and a half ago, I did a quick evaluation of the big frameworks. Looking at the TODO list implementations and implementing a small side project in Angular and a few others.

My conclusion was that the way angular works and how you use it was pretty horrible, and I was quite surprised to see so many so impressed and positive about it. I didn't even think about its performance (as it was promised it was going to improve as it stabilised). The whole idea of the dependency injections and factories, it just doesn't make sense. Within the company my colleagues agreed with my conclusions so we decided to pick something else.

My probably not so popular opinion on dependency injection in dynamic languages is that you shouldn't bother with it. Javascript (and Ruby for that matter) allows you to overwrite both properties and prototypes, this means that any dependency injection can be done dynamically at runtime whenever you want as long as your logic and data is nicely captured in properties. (Note that his last clause is something that often does not hold in Javascript projects as most/many authors love wrapping their stuff in functions with very harshly make lots of things private and immutable)

So designing a whole framework around enforcing this pattern, with a terrible syntax and un-fathomable semantics, on top of a dynamic language, it doesn't sit well with me.

<comment><USER20> Angular's dependency injection is very similar to AMD modules. In fact, the syntax is barely distinguishable. So if you have an issue with Angular's dependency injection, you likely have issues with AMD and perhaps javascript modules in general. I much prefer having my dependencies injected in a modular way than having to pollute the global namespace with every library and component I pull in.

<comment><USER40> Well this is exactly the point that people disagree on with me. I think your application owns the global namespace, as long as your dependencies are neatly defined somewhere there really is no downside to letting pulled in libraries 'pollute' your global namespace.

<comment><USER20> When you're working on large teams it's no longer your global namespace alone. I've worked on quite a few projects that abused the global namespace and it's very painful to try and recover from.

</comment></comment></comment></comment><comment><USER41> I can't really verify the authors thesis that most people using Angular are backend developers, but it does seem to have become the first thing everybody tries to learn after JS/jQuery. I've been interviewing a lot of entry level candidates lately, and "I've also started playing with Angular" has practically been a theme song.

<comment><USER42> Of the people dozen I know who were early adopters of Angular or do AngularJS now, only one wasn't a serious back-end developer.

I think the split may be better worded as programmer/scripter. Some of my unscientific sample were using other Javascript frameworks (Backbone mostly) but were definitely programmers, and wrote in assorted languages too.

</comment></comment><comment><USER43> The problem with Angular is that it's 2005 technology masquerading as the new hotness. Angular existed in 2005 in almost the same state. Why? For people who wrote Java or PHP that didn't want to learn this "new" language, JavaScript. In fact, we had a half-dozen implementations between ASP, whatever the name of Google's solution was at the time, and the Myriad of "MooTools Helpers" and "Prototype Helpers" in PHP.

The reality is that Angular, as a framework, takes you 90% of the way there, just like any other framework, but it makes the last 10% almost impossible to do "right." This is in contrast to JS-based frameworks which don't conflate your entire application to add some questionable ease of use. ReactJS, Knockout, etc, are all superior in that they allow you to do some Angular things without getting in your way when you need to do non-Angular things.

<comment><USER44> I just had a panic attack and a series of stressful flashbacks reading the phrase "MooTools Helpers". Can we get a trigger warning on here? /s

</comment></comment><comment><USER45> "This code reminds me of a simple server-side scripting language such as JSP or ASP that's used to fill HTML templates with database content. These languages have their place in the web development stack — but on the server, not in the browser."

What is the problem? I make isomorphic apps and I really like this. DRY

</comment><comment><USER46> HTML templating belongs on the server-end? Well, that's... debatable.

I like Angular. It is backed by Google so it's less likely to be abandoned because of boredom. It ibolides the batteries; I don't have to learn about dozens of independent libraries just to get something simple together. It is fast enough. Lastly, Ionic is pretty neat.

That is not to say it doesn't have it's bad parts. I don't care for some of the boilerplate it has and how badly it fails if you screw any of it up. I am not a fan of the built in $http service. The state service and URL routing are also too confusing and often do not work correctly when doing slightly more advanced things (intercepting transitions, rewriting history). But overall, I like it better than, say, Backbone.

<comment><USER47> I'm not familiar with the word "ibolides", and a google search didn't turn up anything I could fit as something you could do to batteries. Could I convince you to explain what it means?

<comment><USER48> I'm guessing they meant "includes".

<comment><USER46> Yes, indeed. Typing on a mobile device is a pain, sorry.

</comment></comment></comment></comment><comment><USER49> This article is really bad. Having learned Angular and written an app in it, I liked Angular 1.x OK. I think between Angular 1.x and Ember it was mostly a six of one, half dozen of the other question. I went with Angular for my app because I thought "It's backed by Google, they'll grow it responsibly and smartly." Well, color me stupid. I feel pretty burned by Angular 2.0, now not only does the app I wrote need to be 100% rewritten, but everything I spent time learning about Angular 1.x is now wasted effort.

That is the problem with Angular. Angular 2.0. Nothing else this article talks about is really a valid criticism at all. See other comments about that.

</comment><comment> at-fates-hands Just a few points for me about Angular in my own experience. When I first started using it, it seemed rather straight forward and easy to use. I could use it in some of my projects, or build entire apps with it.

Then came the notice of the rewrite. At that point, I pretty much lost interest in it. I mean, if you're going to have a major rewrite and and not make any of it backwards compatible, what's to say you won't do it again in another few years? For me, this was a deal breaker. Why build apps now which be obsolete when 2.0 finally rolls around?

Also, I'm not sure why people think apps have some incredibly long life span. Almost every large enterprise app I've ever worked on only goes about a year, maybe two years before it gets a complete overhaul. Here's a good example:

Large Enterprise Healthcare App:

\- First iteration which was the longest and went from 2005-2010. Built on Java and Tables in HTML. Brutal, but effective and easy for the Java guys to maintain.

\- Second iteration was from 2010 - 2012. Built on Java and with mainly Javascript and the HTML is cleaned up and tables removed.

\- Third iteration was from 2012-2013, Built on Spring MVC, HTML5 and CSS3 with lots of jQuery and Javascript for several interactive charts.

\- Last iteration I was a part of was in late 2013 - October of 2014. Completely rebuilt with responsive design, built on Grails, with lots of CSS3, jQuery and some Ember and Backbone pieces.

Even when I left they were contemplating another total overhaul, possibly moving back to Spring, and doing more client side stuff with Angular or Backbone and possibly doing some NodeJs as well. The app basically went from 5 year re-design schedule, to essentially less than 14 months in between overhauls. I'm just chalking this up to a constant parade of contractors who come in and are using the latest and greatest stuff, and then push that for the app. When they leave, nobody has the ability to maintain it, so they just rinse and repeat with contractors and technology.

Either way, my point here is that apps seem to have shorter and shorter lifespans before being completely overhauled. It's like maintenance isn't even really a requirement anymore.

<comment><USER50> Can you clarify what you mean here?

The way I see these two sentences are contradicting each other:

> Why build apps now which be obsolete when 2.0 finally rolls around?

> It's like maintenance isn't even really a requirement anymore.

Also, your example application seems to have issues with management, rather than maintenance.

<comment> at-fates-hands They don't contradict each other.

> Why build apps now which be obsolete when 2.0 finally rolls around?

It's well known Agular 2.0 won't be backwards compatible with 1.X projects:

[http://chariotsolutions.com/blog/post/angularjs-2-0-bold- new...](http://chariotsolutions.com/blog/post/angularjs-2-0-bold-new-step- typed-js-es-6-without-concerns/)

"Although Angular will run on ES 5 browsers (the current world), changes being made to the core Angular architecture will break every Angular application. See this InfoQ article for details, which include removal of controllers, current directive definition syntax, $scope, and more."

and from the Angular Team after the Euro conference:

"Our goal with Angular 2 is to make the best possible set of tools for building web apps not constrained by maintaining backwards compatibility with existing APIs."

Which is totally different than having to maintain an application over an extended period of time. They're two totally different issues.

</comment></comment></comment><comment><USER51> The problem with AngularJS can be summarised thus:

"Its marketing and documentation does not correct those who believe it is suitable for web-applications more complex than simple CRUD apps."

As soon as you have an application where you have to reason about the events ocurring in your page, with AngularJS you're lost. Note that CRUD apps are a sizeable proportion if not the majority of applications, so it's brilliant for a massive number of applications.

But for anything more complicated, you're on a knife-edge of performance- problems and ballooning accidental complexity.

</comment><comment><USER52> > Angular is aimed at large enterprise IT back-enders and managers who are > confused by JavaScript's insane proliferation of tools.

I pushed Angular for our team because it was so confining. Keep the code modularized and stick to best practices. Honestly, it's been a joy to work with. Instead of hodgepodge jquery soup, we have structured code that anyone can dive into and follow a common style.

It feels like the old guard keeps pushing back on SPA's. It is a so much more dynamic experience for the user than your typical oldschool postback driven site.

</comment><comment><USER53> Angular was written by Google for Google products. It had a big corp audience in mind from the start. It provides developer structure at the cost of agility. This makes sense in large teams where contributors come and go and have varied skill sets. Encapsulation and isolation of scope makes limits the damage one component can do. To achieve this rigidity a lot of background enforcement is required. The result is performance decline and lots of development overhead.

<comment><AUTHOR> Out of interest, which Google products are using it?

<comment><USER54> The biggest one I know of is their search trends page, which isn't really saying much.

</comment></comment></comment><comment><USER55> It's not just Java and Backend guys, I worked with Flash and Flex for 10 years, for me Angular makes perfect sense. I know I'm not alone either. Before these great "framework wars" of Javascript, there were framework wars in the Flex world, with frameworks of varying credibility and endless haters / fanboys publicly pronouncing their butt hurt about their whims. Google any "[enter framework] sucks" and get your opinions validated.

</comment><comment><USER56> I admit I haven't read all the comments. But what I have read from the author, in some comments here and in the follow up article, I get the impression that there get things mixed up, that actually don't belong together. In my opinion you have to distinguish between web apps and content pages.

In the first, client side templating is just fine and the right way. Everything changes and the users are making a great deal of changing the output. A round-trip here is destroying the feeling of an app.

In the second, client side templating is just unnecessary. But so is server side templating, in many cases. Taken that the pages to display are rarely changed it would be even better to have simple static html, pre compiled.

The hard task comes when we have some mixed scenarios. A CMS for example. In my opinion the content creation process is a very valid use case for client- side-rendering - an app for creating html output, if you will. But when it comes to display that content it should reside precompiled (no server side rendering) on the server. So that just plain html pages have to be delivered to the actual users.

</comment><comment><USER57> This article is mostly BS. He's got the knack of sounding like he knows what he's talking about when he actually doesn't. Some examples:

 _" Angular's ng-repeat directive will create or destroy DOM elements accordingly. This turned out to be quite expensive. ...

... what worries me is that this non-performant mode is Angular's default. Front-end framework defaults should use established front-end best practices. Angular's don't."_

He's talking about ngRepeat's "track by" function here and clearly doesn't understand that it _can 't_ be switched on by default as the user must specify the name of a unique id used in their data models. There is no way for this to be on by default.

 _" Although templating is the correct solution, doing it in the browser is fundamentally wrong. The cost of application maintenance should not be offloaded onto all their users's browsers (we're talking millions of hits per month here) — especially not the mobile ones. This job belongs on the server."_

What does that even mean. Consumer hardware contains heaps of resource for web browsing.

 _" Many front-enders, on the other hand, who have worked with JavaScript and browsers for years and have developed their own coding style"_

Cute front-enders with their own adorable coding styles. Code is code. Patterns structure code to increase maintainability. Stop imagining there's a group of people whose work this does not apply to.

 _" That's why most Angular developers come from the back-end, particularly from Java. As far as I know this situation where a front-end framework is supported mostly by non-front-enders is unique."_

More of this front-end/back-end discrimination bullshit. That's a distinctly enterprise paradigm that just has to go. It's 2015

</comment><comment><USER58> " _I'd say Angular is mostly being used by people from a Java background because its coding style is aimed at them. Unfortunately they aren't trained to recognise Angular's performance problems._ "

If I follow the logic correctly--people with Java backgrounds are not trained to recognize performance problems? Quite the curious line of reasoning.

<comment><USER59> _"...Angular's performance problems."_

It's specific to Angular running in the browser opposed to Java running on a server. You'll certainly run into different performance bottlenecks especially in long running client side applications. What works on the JVM will be very different than what works on the browser especially across multiple vendor's JS runtimes and versions.

</comment></comment><comment><USER60> Angular emanated some 'project smells' that have kept me at arms length. The size of the codebase was very large compared to alternatives. Lots of add-on solutions for various problems (ng-this, ng-that) kept cropping up. Articles explaining how to do X or Y in Angular indicated things were probably not as simple as they ought to be. And, it was mainly driven by Google as opposed to a small core team of diverse individuals. The tools that have turned out to be the best in my experience have often had one visionary lead developer, a BDFL- type champion. I expect Angular to appeal more to enterprises, while the early adopters and lean startups shift towards small libraries and microframeworks. I think web components will become more and more important, and that we'll begin to see more libraries to assist specifically with data persistence and synchronization between the client and server.

</comment><comment><USER61> This is really just a compilation of previous rants against Angular. If you want to get a more balanced view, you can read my article dealing with a lot of this: [https://medium.com/@jeffwhelpley/screw-you- angular-62b3889fd...](https://medium.com/@jeffwhelpley/screw-you- angular-62b3889fd678)

</comment><comment><USER62> The author's logic follows, the only problem is he's picked the wrong term. His argument is against using javascript and/or data-/ng- attributes to bind default data to a template. Wasted power and cpu cycles. I think we can all agree that premise is true. However, templating with binding is all about savings in bandwidth, memory, and http requests. It also keeps complexity down when done right.

So yes, quit using various unnecessary means of supplying binding references to the DOM and serve & send your HTTP correctly. But none of youo ever will.

</comment><comment><USER63> Why should I offload templating to the users?

Because it saves me lots of money since I don't need so many backend servers.

We are already offloading lots of stuff to the client already. CSS is a great example of this. We could have a server calculate the colour of some text, or just tell the browser which rules should be used to calculate that colour.

EDIT: For almost two years I've used Angular on most of our web systems at work, and also on most of my private ones where i make the client exceptionally thick and the server is just for persistence.

</comment><comment><USER64> Most of this seems a bit personal and a bit of a surprise from PPK.

The first few paragraphs are trying to convince you that Angular isn't popular and isn't meant for cool people. You don't need to consult Google Trends to sense that there is an ego on the wrong end of a popularity contest at play, but here it is:

[https://www.google.com/trends/explore?hl=en- US#q=ember.js,+a...](https://www.google.com/trends/explore?hl=en- US#q=ember.js,+angularjs,+backbone.js&cmpt=q)

</comment><comment><USER65> Poorly written article mostly. Largely just fluff and opinion, and rehashing of problems other people have mentioned. I swear everytime I read one, I expect a unique take, but they always end up the same. Two or three paragraphs hinting that it might not be performant, and another 3 or 4 paragraphs talking about how Google doesn't even use it and how Angular is somehow hard to learn. Only thing that surprised me is he didn't tell us about how great React is at the end of the blog.

</comment><comment><USER66> "Although templating is the correct solution, doing it in the browser is fundamentally wrong."

This statement alone sounds like someone doesn't want to learn new things.

I'm sorry, but I wrote ASP.NET webforms for years and you will pry Angular templates out of my cold dead hands. Of course if you have optimizations for narrow scenarios, then by all means refactor...but most activity in a SPA is pretty simple stuff. A template and a couple of REST calls and you're set.

</comment><comment><USER67> I think some of these front end frameworks come from developers looking the bloated mess that is Enterprise Development and they think, "Man! I gotta get me some of that!"

/S

</comment><comment><USER68> I don't think the author has heard of JSON,restful end points, and or design patterns, I don't understand why he would develop with the intent of rendering the pages on the server side, when the client can do that faster and you can reduce server load. Not only is that a performance advantage its a design advantage, now you can have mobile clients that render data natively and you don't have to work as hard to develop for mobile.

</comment><comment><USER69> This is what I have been saying since 2012. Angular was created by java developers for java developers. It's is an abomination to the frontend.

</comment><comment><USER70> >The biggest problem for many front-enders seems to be that Angular forces you to work in one specific way.

I am not sure this is a weakness. While everyone protests change and all developer's heads explode when you force them to use a specific convention, in the real world a common standard of coders in one company is a good thing.

</comment><comment><USER71> This guy would have been better off just saying "Angular 2.0 breaks Angular. The End."

They took out {{ }}, $scope, DDO, controllers, jqlite, angular.module, and are moving to ES6 when basically no browsers have even started supporting it.

Isn't that enough? Do we really need to complain about Java developers writing for the web?

</comment><comment><USER72> It is more than obvious that the author of this article __really __doesn 't understand Angular. Also, you can't say that poorly educated developers is a "problem with Angular", and this is essentially the author's primary argument here.

Honestly, how did this make it to the top of HN?

</comment><comment><USER73> In my experience, most of what people want can and should be done server side. Instead of big frameworks, something smaller like Knockout can be useful for adding some interactive javascript in a way that is cleaner than the standard pile of jquery.

</comment><comment><USER74> How did such a horribly written article with no substance or structure got so popular? This guy just explains how he "thinks" and "feels" with no supporting evidence.

One of his first points is: "I feel that Angular's fundamental proposition blurs the line between front end and back end."

Why? I feel it makes the line clearer. So there.

After I read the entire article I was still left wondering what his point was. He concludes with discussing Angular 2.0

"The 2.0 rewrite is aimed at front-end developers, but may not reach them, and in addition will turn off Angular's current following. I don't think Angular will survive the rewrite."

Well, no shit. Let me get this straight: a front end framework isn't going to survive because it's targeted at front end developers? Who writes this crap?

</comment><comment><USER75> I agree, specifically with the fact the Angular 2.0 will turn off all the corporate/Java devs and thereby kill itself.

</comment><comment><USER76> I don't like that Angular makes HTML pages very much useless by themselves (content-wise without javascript)

</comment><comment><USER77> If the author happens to chime in, that big Dutch corporation wouldn't happen to be ING, would it?

</comment><comment><USER78> I think bigger problem is with developers who are using Angular wrong way.

Before same story was with jQuery etc.

</comment><comment><USER79> Really disappointed with the quality of this article. PPK was such a valuable resource back in the day when it came to front end development and always had great content (especially when it came to compatibility issues). I'm not even saying I disagree with him here, but this writeup seems pretty half-assed, at least for someone of his caliber.

</comment><comment><USER80> I don't agree with this claim whatsoever - "Angular is aimed at corporate IT departments rather than front-enders"

I'd say it's the other way around, if you read "front-enders" as hobbyists, start ups and SME's. Angular is still far too new and unproven for most big corporate IT departments.

<comment><USER81> The tide might be about to change - I'm currently doing Angular work for a major car manufacturer.

<comment><USER82> The Angular juggernaut is like the Java juggernaut at light speed for corporate IT. I'm interested to see how the Angular 2.0 risk assessment is constructed within corporate IT today. Start on a 1.2 project with, potentially, a full rewrite needed within 2-4 years? That's not typically a risk slowly evolving LoB applications take on. Good luck finding Angular devs in 5 years willing to live on the 1.2 brownfield. Until the schism around 2.0 gets resolved, I'm not sure I see this playing out well for them.

</comment></comment></comment><comment><USER83> Angular is the new PHP didn't you know?

</comment><comment><USER84> Cross-posted to ihateangular.com

</comment><comment><USER85> Just A Crap

</comment><comment><USER86> My issue with AngularJS: Debugging is an absolute nightmare, error messages are far and in-between. And when working on a 50k+ line production code-base, one single comma a in a file where it is not supposed to be will shut down the whole GUI. And occasionally, it won't even show where in the console.

<comment><USER87> In dev it will show exactly where in the console, assuming you have a sane dev environment, and if you're running a tool like jshint, you can catch any such error fast. That is a non-issue, and not even one unique to Angular.

</comment></comment><comment><USER88> IBM invented rendering on the client in the 3270 terminal... In 1971.

<comment><USER89> I got my start as a professional programmer at an IBM shop on an System 38 --> AS/400 writing RPG apps with 5250 terminals. When HTTP/HTML started taking off in 1993 because of Mosaic I felt right at home.

RPG ran on the AS/400 and your DSPF (display file) ran on the terminal. DSPFs did screen layout, validation, etc...

</comment></comment><comment><USER90> The final paragraph I really don't get:

> Despite its serious technical problems Angular 1.x is a success especially > among corporate developers with a Java background. The 2.0 rewrite is aimed > at front-end developers [...]

... says who? I don't know any Java developer who does Angular now, and who ever said front-end devs are the target audience of the rewrite?

</comment><comment><USER91> Angular 2.0 addresses frontend and not corporate developers? Ridiculous! AtScript is more like Java/C# and supports strongly typing.

</comment><comment><USER92> People here at HN really love to hate on Angular for some reason. This article doesn't even make any sense, but it's still getting voted up.

<comment><USER93> There are generally two kinds of people who love to hate on Angular:

1) those who have used Angular, been burned by it and are now sour about it;

2) those who haven't used Angular but hate {JavaScript|frameworks|SPAs|the web|anything popular} out of principle.

The first category includes both those who hate it because they don't understand it and those who hate it precisely because they do understand it.

I wouldn't say I hate Angular, but I'd like to think of myself as being in the latter subset of the first category.

</comment></comment><comment><USER94> > I feel that Angular's fundamental proposition blurs the line between front > end and back end.

Sorry?

> Angular is aimed at large enterprise IT back-enders and managers who are > confused by JavaScript's insane proliferation of tools.

Wait, seriously?

> When AngularJS was first created, almost five years ago, it was not > originally intended for developers.

When I started using Angular 3 years ago (ver 0.9) it was already mature enough for serious web development and better (better structured, better documented, better for large web apps) than a lot of other frameworks (like Backbone). Back then it was developed by three Czech guys, that Google employed in the meantime and funded their project.

> Enterprise IT managers also like the fact that Angular closely mirrors the > preferences of their back-end developers.

This just pisses me off already.

> Many front-enders, on the other hand, who have worked with JavaScript and > browsers for years and have developed their own coding style, tend to have > their doubts about Angular.

Yes, because their old code used to be utterly crap compared to something written in Angular. Angular does not let you write such messy code as you could without a framework.

This article is all FUD. I have never imagined that I'll ever see such a bad piece written about Angular.

<comment><USER27> Tell us more how it is better structured and better documented than Backbone and what exactly makes it better for the large apps. The size of the app will hide the size of the framework better?</comment></comment>


Ask HN: Machine Learning service for databases? - <AUTHOR> I'm running Machine Learning as Service platform - https://mljar.com - it can accept CSV flat file and build machine learning models for data in it (binary classification or regression models).
The service is not popular. I think that building ML models from CSV file and then writing additional script that will use model by REST API is not comfortable to use. I'm thinking about adding feature to read data directly from database: (1) reading data from database for model training (2) listening to database updates (new rows) and using it to compute predictions and save it in database.
Do you know any Machine Learning services that have such feature? <comment><USER2> Are you sure your lack of uptake is due to features rather than marketing?</comment>


Pin.net.au announces pricing - <AUTHOR> http://createsend.com/t/j-BE42B41F1ADAD444

<comment><USER2> Is there a price matrix on different Australian payment systems? Here's what I was able to quickly glean:

Pin: $50 p/month, 3% transaction + 30c transaction Source <http://createsend.com/t/j-BE42B41F1ADAD444>

Braintree: $55 p/month, 1.75% transaction + $0.25 transaction + Visa/Mastercard Intercharge rate (0.33 to 1.98%) Source <https://www.braintreepayments.com/pricing>

PayPal: $0 p/month, 2.4% transaction + $0.30 transaction Source: [https://www.paypal.com/au/cgi-bin/webscr?cmd=_display- receiv...](https://www.paypal.com/au/cgi-bin/webscr?cmd=_display-receiving- fees-outside)

Am I missing something here or is there more to why I'd use Pin? Would love to hear a compelling case and a reason for why paying more per transaction adds value.

I'd say that at the end of the day, most merchants want the payment to be secure + cheap, that's it. Analytics etc. are nice but can come out of free open-source tracking methods.

Lastly as a developer, the per month cost is a killer. It completely shuts down the idea of having a boutique site earning residual money.

</comment><comment><USER3> Like Braintree's entry into Australia, the pricing isn't as amazing as I think people were hoping.

Whether it's because they too rely on nab (An Australian bank) to provide the multi-currency account (Also used by Braintree) or because they aren't looking to differentiate on price I am not sure.

<comment><USER4> We don't differentiate on price :)

<comment><USER3> Are you able to disclose whether the $50 a month is a result of nab's involvement somewhere in your end-to-end setup? To me, that's the most unfair part of payments in Australia. I can understand charging if an account is dormant but not just because everyone else is doing it. That's the problem with banks today- they all just copy each other.</comment></comment></comment>


Licensing followup - <AUTHOR> http://leancrew.com/all-this/2015/03/licensing-followup/ <comment><AUTHOR> (Follow-up to previous discussion from last week: [https://news.ycombinator.com/item?id=9118270](https://news.ycombinator.com/item?id=9118270))</comment>


Google asks Glass wearers to stop being such Glassholes - <AUTHOR> http://avc.lu/1jUVTkK

<comment><USER2> Prior discussion: [https://news.ycombinator.com/item?id=7261558](https://news.ycombinator.com/item?id=7261558) (2 days ago; 54 comments)</comment>


Dev.to is now open source - <AUTHOR> https://github.com/thepracticaldev/dev.to <comment><USER4> I was very surprised to open the gemfile and see a gem I wrote "s3_direct_upload" being used. Especially considering there is native support to upload files directly to s3 in rails 5.

Then I looked at the repo and realized, wow people are still using this gem, maybe I should maintain it.

<comment><USER5> I think this is a very common experience for maintainers.

I wonder if it would make sense to have a low friction way for people to notify maintainers that they're using a library? I guess stars are a little bit like that but people star stuff they don't use.

Or maybe have something that would automatically crawl github for you and find out how many projects depended on your library.

<comment><USER6> > Or maybe have something that would automatically crawl github for you and > find out how many projects depended on your library.

There's already a form of this: [https://github.com/waynehoover/s3_direct_upload/network/depe...](https://github.com/waynehoover/s3_direct_upload/network/dependents)

<comment><USER7> I learn something new everyday :)

Too bad the language/manifest support seems to be so limited. I wonder if others are in the works?

</comment></comment></comment></comment><comment><USER8> Not only is the content great on that site, the performance of it is absolutely spectacular. It's amazing how much people will jump to new fangled solutions when this site is a great example of what a well tuned Rails app can pull off from a UX perspective.

<comment><USER9> It's cool that it's open-sourced, but I've never been impressed with the content. Even when an article is about a topic I'm interested in, it's hard to get past the Buzzfeed-style "How do you do, fellow kids?" tone.

<comment><USER10> Yeah, I kinda feel the same way about the content. It's like 'coding, not programming', 'what was your biggest achievement today? Mine was no conflicts ;)' and other silly wholesome comments. But yeah, the performance of the site is phenomenal.

</comment></comment></comment><comment><USER11> "We run on a Rails backend with mostly vanilla JavaScript on the front end, and some Preact sprinkled in. One of our goals is to move to mostly Preact for our front end."

(what I consider the most interesting part)

</comment><comment><USER12> It isn't clear what dev.to is, so I was looking for the _About_ page. The link is at the bottom of the page, on a site with infinite scrolling. WTF

<comment><USER13> Got the same frustration just the other day this was here. Thehack was opening someother page and then was able to get to that link. Still don't understand much what the site is about. It feels like an interface to a specific subreddit.

</comment></comment><comment><AUTHOR> This is a very cool approach to building a developer community: let developers contribute directly to the platform, both in code and in content.

</comment><comment><USER14> Now somebody should make a PR to get rid of the nag notification for logged out users...

<comment><USER15> This one? [https://github.com/thepracticaldev/dev.to/pull/288](https://github.com/thepracticaldev/dev.to/pull/288)

<comment><USER16> Merged.

</comment></comment></comment><comment><USER17> Just whatever you do on dev.to don't ask hard questions to their AMA people. You'll get shadowbanned for that. (Even if the person handles the question well)

<comment><USER18> By "hard" do you mean "technically difficult", "socially awkward", "directly critical", or something else?

I've not yet commented on anything I've seen and would like to avoid irking their mods.

<comment><USER17> Directly Critical.

</comment></comment></comment><comment><USER19> It's lovely to see a sane backend language being used instead of shitty Javascript.

<comment><USER20> Instead of just dismissing all Javascript backends, can you tell me why using Ruby is better than Javascript here?

Personally I do prefer Rails over something like Express too, but that's more of a personal preference. I don't see why todays Javascript backends are all "shit"?

<comment><USER19> One answer: left-pad.

Seriously though, the language itself is a matter of preference, but you can't dismiss that the ecosystem sucks. Projects with hundreds of packages in their dependency graph seem common. I've worked on a (front-end) React project with 1,7k packages involved in the build process. That's madness.

<comment><USER20> I agree, left-pad was a mess, but while the huge amount of dependencies is the thing people most complain about, is it actually unique to Javascript? Looking at the Gemfile for this project, it seems like you're also going to have to install hundreds of gems if you want to get this up and running.

</comment></comment></comment></comment><comment><USER21> For some time I was looking for a discovery mechanism in database topics.. so combining the usual tags yielded already a good blog I can follow. People can use their blog rss to crosspost, and the text contrast is friendly.

</comment><comment><USER22> Awesome! Dev.to is a really nice community - I'm excited to see how this goes :).

</comment><comment><USER23> This is all great, but their Readme.md doesn't even explain what it is — they are just assuming that the reader knows!

<comment><USER24> To be fair, the url to the site is in the name and at the top of the repo

<comment><USER23> But the name doesn't tell me anything! It's generic!

</comment></comment></comment><comment><USER25> Are the politics necessary?

[https://github.com/thepracticaldev/dev.to/blob/65110550d8c22...](https://github.com/thepracticaldev/dev.to/blob/65110550d8c2231f73ff99ae305a46b7b0bcb4f9/public/offline.html#L90)

<comment><USER26> Did you try hitting the edit button and submitting a PR? If only to spark the discussion with the maintainers.

<comment><USER25> I don't want my github history to show any hint of politics.

</comment></comment></comment><comment><USER27> this looks like HN for devs in their 20's

<comment> yjftsjthsd-h ... HN _is_ for devs in their 20s.

<comment><USER28> No, it is not. I am 49 and I have no problems using HN. Also often it is clear, that some of the amazing answer found here, are from people way older than in the their 20s, because some of those answers requires the poster to have many many years of experience in order to come up with that answer.

There is a great mix of young and old here :)

<comment> yjftsjthsd-h Sorry; I didn't mean exclusively at all. I meant "why have a site for 20something devs when they (and everyone else) already have HN?"

</comment></comment></comment></comment><comment><USER29> Congrats guys! Great move to open source the code.

</comment><comment><USER30> Looks like the standard rails mess :/ Don't get me wrong. From time to time i am going to look at other peoples rails code to learn, how they solved common problems in grown rails apps. Most oft the time i leave rather disappointed...

I like the spec for Comment#id_code_generated ;)

<comment><USER31> Can you be more specific? The modeling/models don't look TOO insane - <USER2> some refactoring, but not too far off.

If you think this is a rails mess - you haven't seen anything yet. I am still able to hop in and reason about what this codebase does with no onboarding - <USER3> key benefit of rails. I've worked on codebases where all those niceties were thrown out the window.

</comment></comment><comment><USER32> What is Dev.to?</comment>


EyeTracking Study: camelCase vs. under_score style (2010) [pdf] - <AUTHOR> http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf <comment><USER3> In Perl 6, you can also use "kebab-case":

        my $is-it-time = True;

The hyphen is allowed inside an identifier as long as it is not the first and as long as it is followed by at least one letter.

        my $foo-42;  # interpreted as my $foo - <USER2>

<comment><USER4> This is also the standard for Common Lisp, Scheme, emacs-lisp.

<comment><USER5> Also Bash (for function names) (could be POSIX too), Make ...

</comment></comment></comment><comment><USER6> My current style convention mixes several naming styles to help in distinguishing code visually.

I prefer camelCase for variables, which need to be typed repeatedly, and camel is fastest to type. I use snake_case for functions, UpperCamelCase for classes/types, and ALL_CAPS_SNAKE for configuration variables a user would be expected to edit.

<comment><USER7>
        camel is fastest to type

iAgree but englishIsAlso fasterToType byRemovingSpacesAnd capitalizingFewerWordsThan usual. iDonT knowWhy weProgrammers shouldConsiderThat aWorthwhile tradeOff

<comment><USER8> iThink theGermansWouldAgree.

</comment></comment></comment><comment><USER9> For me it's more about ease in typing. I find typing underscore so many times a bug deterrent in fast typing speed.

</comment><comment><USER10> snake case...

I did it for years in Perl then moved to camel with Java. Now, I sort of like not having to type underscores.

<comment><USER7> I went the other way. I like it when my code doesn't look like a jumble of random letters with the least important words capitalized.

<comment><USER11> I went back and forth, both ways. I started out in Python with snake_case identifiers, then moved to Javascript with camelCase, and now I mostly use Rust with snake_case for names and UpperCamelCase for types.

I don't find either style better than the other, the only time I notice anything is when I switch between style conventions (e.g. switch between JS and Rust or C++), because I need to break the habit of typing one way rather than the other.

Still, I find readability of the two styles pretty much identical at all times once you get used to both.

<comment><USER12> I mostly find the readability the same, except for acronyms in the middle. RemoteHTTPIPAddr vs remote_http_ip_addr. I prefer the latter, but my go-to language these days encourages the former.

<comment><USER13> The "What is an acronym really and when should it be capitalised" debate is grey enough that it's easier to consistently use

RemoteHttpIpAddr

<comment><USER14> Not capitalizing the entire acronym is the convention in modern Java and C#.

[https://google.github.io/styleguide/javaguide.html#s5.3-came...](https://google.github.io/styleguide/javaguide.html#s5.3-camel- case)

[https://docs.microsoft.com/en-us/previous- versions/ms182249%...](https://docs.microsoft.com/en-us/previous- versions/ms182249%28v%3dvs.80%29)</comment></comment></comment></comment></comment></comment>


Home energy monitors - <AUTHOR> http://news.cnet.com/2300-11128_3-10001909-1.html?tag=mncol

<comment><USER2> Just pictures of energy monitors?

<comment><AUTHOR> The descriptions are on the right..</comment></comment>


Tools For C++ Programmers - <AUTHOR> http://virtualrealityblog.com/lists/7-great-tools-for-c-programmers/

<comment><USER2> Visual Studio, Boost, STL, the friggin' auto keyword? That's for a very, small audience (beginners, Windows, no resource limits) and a rather lenient interpretation of "tool"...

</comment><comment><USER3> #8:

Python.</comment>


Big GPL copyright enforcement win in Paris Court of Appeals - <AUTHOR> http://arstechnica.com/open-source/news/2009/09/big-gpl-copyright-enforcement-win-in-paris-court-of-appeals.ars?utm_source=rss&utm_medium=rss&utm_campaign=rss <comment><USER2> What is very interesting in this is that the case was won despite the GPL license being available in English only in distributions that I'm aware of.

In France this could have been a serious hurdle to overcome, but instead it seems as though that never even entered the picture.

</comment><comment><USER3> The interesting thing about this case is that the infringer was sued by a company that used their software, not by the copyright holder.

I'm not sure I'm happy about that, given the way a few rabid free software fanatics have acted in the past. In particular, I remember the QuakeWorld GPL fiasco, where zealots in the community took it upon themselves to harass the leader of an open source project, rather than giving a chance for a much more level-headed John Carmack to sort things out.

See: [http://www.bluesnews.com/cgi- bin/finger.pl?id=1&time=200...](http://www.bluesnews.com/cgi- bin/finger.pl?id=1&time=20000224183445)

</comment><comment><USER4> It took 7 years!?!? for this case to finish?

New business model:

      Violate GPL
      Earn money for 6 years
      Pay massive salaries
      Go bankrupt on the 7th

<comment><USER5> Welcome to the Law System.

But there are good reasons for the delay. Presumption of innocence, injunctions for relief etc all take time to consider.

</comment></comment><comment><USER6> This doesn't make sense at all -- the GPL is just a conditional disclaimer of copyright -- it doesn't even pretend to be a contract.

Only the copyright holder has standing to make a civil infringement suit under standard international copyright law. The copyright granter (national government) has the sole ability to initiate a criminal case, and most signatories only have criminal statutes for commercial piracy. France has draconian 'moral rights', but they are not transferable even in 'work for hire'.

<comment> Tuna-Fish > the GPL is just a conditional disclaimer of copyright -- it doesn't even > pretend to be a contract.

Whatever else the GPL does, it absolutely does not disclaim copyright. It maintains it, but gives you a license, _if_ you follow a certain set of conditions.</comment></comment>


What Happens When We All Live to 100? - <AUTHOR> http://www.theatlantic.com/features/archive/2014/09/what-happens-when-we-all-live-to-100/379338/

<comment><USER4> Probably a nitpick, but i disagree with this statement

"Evolution doesn't care about you past your reproductive age. It doesn't want you either to live longer or to die, it just doesn't care"

I've heard this statement a few times, and it appears to be untrue. Menopause, in particular, is evidence of this - that humans evolved to shut down reproduction at a certain age rather than allow it to peter out - <USER2> because grandparents are so relevant in the evolutionary prospects of their descendants.

This next part is most certainly a nitpick, but the statement "nature/evolution doesn't care", while not meant literally, does fall into the trap of assigning intent or purpose to evolution (in this case, more subtly, through the presence of absence of caring, rather than the non-existence of intent).

<comment><USER5> Who cares if evolution doesn't care (pun intended) - we are known as the hackers of this planet and we've evolved to start to master genetic engineering ourselves (for good or for bad), so, evolution will become less and less relevant with time.

</comment></comment><comment><USER6> I've actually always pondered about the economic effect of the aging population and had done some research here and there about it. If we do not increase the current retirement age more frequently and gradually towards 70, there will definitely be economic consequences. I don't want to bore you guys with the math here, but imagine if one lives to 90 years old, and retires at 65. This individual would spend more than half of his or her life being "economically unproductive" (either in school - 22 years or retired - <USER3> years). With that being said, there have been many successful individuals, Morris Chang (83 years old) from TSMC for example, who are well over their retirement ages, but still making great contributions to business and technology. I believe that there should be a movement, especially with the advent of online education, where individuals in their late 40s / 50s should brush up on their understanding of emerging technologies, so that they can continue to be available in the working force without being technologically outdated (clearly, this statement does not apply to many of the individuals on this site, but for general masses, a brushing up on technology can certainly be a great thing).

</comment><comment><USER7> Not stated explicitly but it looks like the article is referring to average age which is heavily skewed by infant death rates - which have been decreasing drastically over the last few decades (yay for that ;-). the real question when talking about the upper limit is "If you make it to 25, what are the chances you'll make it to 100". Last time i looked at this it wasn't nearly as spectacular as you'd think.

</comment><comment><USER8> Well, that's pretty simple: we'll need to consume _far_ less per capita otherwise the system will collapse. The good news is that you can start that today.

<comment><USER9> Or produce more.</comment></comment>


Career outside the Matrix - <AUTHOR> http://hugocaracol.github.io/career/career-outside-matrix/

<comment><AUTHOR> The Matrix shows the path most HN readers already know.</comment>


Beware of ads that use inaudible sound to link your phone, TV, tablet, and PC - <AUTHOR> https://arstechnica.com/tech-policy/2015/11/beware-of-ads-that-use-inaudible-sound-to-link-your-phone-tv-tablet-and-pc/ <comment><USER2> 2015 article. Something more relevant might be facebook getting a patent to control your phone via tv audio.

[https://metro.co.uk/2018/06/22/facebook-wants-hide- inaudible...](https://metro.co.uk/2018/06/22/facebook-wants-hide-inaudible- messages-tv-ads-force-phone-record-audio-7652112/)

</comment><comment> dj-wonk What counter-measures exist? (e.g. an audio detector listening above 20 kHz?)

<comment><USER3> Permissions is the simple, albeit flawed, answer.

It doesn't matter if your TV makes a noise if nothing is listening for it.

Deny access to your microphone. There are very few good reasons for an app to access it.

Use your firewall. Your data belongs to you, there are few good reasons that an app should be connecting out to services like SilverPush.

Unfortunately, this usually requires domain knowledge ("who is trustworthy?"), which is why the answer is flawed.

<comment><USER4> Would using something like pi hole at home help in that regard?

<comment><USER3> Yes and no.

Your pi-hole can block things, but if you leave home and the app framework has cached communications, what happens then? Can it now push the data?</comment></comment></comment></comment>


Github support done right - <AUTHOR> http://support.github.com/discussions/feature-requests/898-sortable-and-pinnable-repos

<comment><USER2> What am I missing? This seems like a reasonably okay exchange, but what's special about it that makes it worth singling out as an example that all other tech support folks should aspire to?

<comment><USER3> Never belittle your customer and never assume that they hold you as the pinnacle of excellence. Most customers understand with success come mediocrity. For those customers that don't, learn tact and how to close the conversation GENTLY or pass the support to your manager.

If you don't feel offended by the entire tone of this post, then I think we live in two very different worlds. Paying customer or not, public interaction is very difficult to manage well.

..... from Kyle... Will,

For reference, I deal with 89 repositories I have access to. I have no issues with the repository lists. Keep in mind:

If you don't know what repository you want to work on, alphabetical order will have absolutely no effect. Alphabetical order is only helpful when you know what the repository starts with. If you know this, use the filter.

If you're coming to a new project, I sure hope your co-workers / manager have told you what the name of it is. Just type in a few letters of that name and you've got it.

I have a really hard time believing you don't know any portion of the project's name you're looking for. I can see not knowing the entire name, but even two or three letters usually narrows the list down to ~5-10 repos.

If this is really important to you, you can always use our API to develop a custom dashboard for your company and implement all these features. <http://develop.github.com/> — or even write a chrome extension / greasemonkey script to re-order/re-arrange the repository lists as you see fit.

Really, if the problem is you need to communicate to your employees that certain repositories are important for a period of time... tell them. Email, phone, in-person. We don't deal with communication problems on GitHub, we deal with technical problems.

I know it can be sort of heartbreaking when companies don't accept your feature requests, but we're here to look out for all of our users, and a lot of times that means not implementing features for the greater good.

<comment><USER2> The overall feel of the sequence is a mixed bag. On the plus side, kneath offers a workaround (filtering + APIs), apologizes for initially misunderstanding which feature the customer was talking about, and doesn't promise miracles. On the minus side, the "hard time believing" and "sort of heartbreaking" lines don't sit so well.

I doubt kneath was trying to belittle his customer--which reinforces your point that customer support is hard. My original question should have been, "Why this particular title?" Was the poster holding this up as an example of perfect support, or mocking it as an example of terrible support? In reality, it was neither.

</comment></comment></comment><comment><USER4> ohmy kyle... wonderful guy at the lousy job. he'd be great at the suicide prevention hotline

</comment><comment><USER3> I have to hand it to Kyle. That's just how we roll on 3rd shift!!! But on a serious note, I suppose this just shows that customer service is quite a difficult thing to balance. I recall seeing some similar interactions between 37Signals and their customers as well. If you build opinionated software then unfortunately not all opinions agree with yours. But how you handle the exchange of opinions is quite a fine art.

I particularly like this line "We don't deal with communication problems on GitHub, we deal with technical problems."

ok...I'm done with my break. Time to go deal with those damn customers again. Can you wake me about 15 minutes before 1st shift arrives? I need to prepare the handoff report for the EMEA guys. :)</comment>


A technical comparison between the snap and the Flatpak formats - <AUTHOR> https://ubuntu.com/blog/a-technical-comparison-between-the-snap-and-the-flatpak-formats <comment><USER2> 404: Page not found</comment>


Digg: Not for Sale  - <AUTHOR> http://www.businessweek.com/technology/content/dec2008/tc2008121_004686.htm <comment><USER2> Translation: nobody wanted to buy it, so we took it off the market.

Granted, it's been about a year since I last used Digg, but it had really turned into a cesspool of stupid/useless/gamed links. Digg, Reddit, etc. all seem to have passed the apex of their value curves.

<comment><USER3> So true about those other sites. I'm so happy to have found HN, and I no longer even remember how it happened.

<comment><USER4> It'll eventually happen to HN like it has with every other social news site out there.

<comment><USER5> With respect, you've been here for 2 months. I think it's a bit premature of you to predict the demise of YC.

<comment><USER6> Yeah, our niche will out last those other niche(s)!

But seriously, Digg had a chasm to cross, I don't think HN can go mainstream.

<comment><USER5> Well, the goal of this site is not to grow large, it is to be useful (as per PG).

Digg and reddit are companies before all else; their goal is to grow as large as possible.

Artima hasn't "gone digg", I don't see why this site has to.

<comment><USER4> Artima doesn't look to be a social news site.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> I think they are right: there is potential for digg to become big. Too bad the IPO market is so screwed at the moment.

We need more independent companies and less of the ones that are selling at the first opportunity. I don't want to live in a world where the only chance of success is selling to one of _five_ big companies.

<comment><USER8> Hmm, I'm gonna make one of those positive digg comments I'm so well known for (not). There is a potential for a shakeout, they have lots of money to weather the storm, an established brand, traffic, revenue - it may happen.

<comment><USER9> Digg's a legitimate brand, courted by all the established media entities.

8 months ago, the Tribune company assembled a strike force tasked with figuring out a way to game digg to get their content out there. How many other startups are changing how people in other businesses hire and operate like that?

They may not have figured out how to be self-sustaining, but there's enough people with cash trying to get in with them that they'll find something eventually.

<comment><USER8> And just in passing, the Tribune should have contacted me. ;-)

</comment></comment></comment></comment><comment><USER10> According to this recent article, digg traffic has flattened:

[http://venturebeat.com/2008/11/06/why-hasnt-digg-made-any- pr...](http://venturebeat.com/2008/11/06/why-hasnt-digg-made-any-progress-its- worth-only-164m-now/)

</comment><comment><USER9> As long as advertising is based on pageviews, Digg's important because it can create a lot of pageviews for you.

<comment><USER11> Is advertising based on pageviews?

<comment><USER9> Sure. Pageviews/1000 x cost per thousand impressions = Payout.

Sure there's cost per click ads, affiliate links etc, but display ads are still a big force out there and as long as that's true, then Digg's powerful.

Huffington Post does monster numbers. They're also on the front page of Digg all the time for rewriting other people's reporting. Digg drives a lot of traffic their way, but how many of those people stick around and engage?

<comment><USER11> I meant that sort of sarcastically.

I know that a lot of display advertising is based on pageviews, but I don't think there is much of a business model in pageviews.

</comment></comment></comment></comment><comment><USER12> The quality of comments on digg sucks. We can host digg clone with <http://www.kubelabs.com/phpdug/></comment>


The Setup: Bret Taylor (Facebook CTO) - <AUTHOR> http://bret.taylor.usesthis.com/ <comment><USER2> While i understand the despise of IDEs somehow, after working with Visual Studio on a big C# project i cant really think how efficient refactoring would work without the IDEs features for just simple stuff like renaming.

Even if you have Unit tests for everything, it would still be alot more error- prone and require manual work. Where in a good IDE its a press of a button, without one i would think twice about renaming something and probably not do it at all.</comment>


Show HN: Kanbann.com - Simple task management - <AUTHOR> http://kanbann.com/ Here is a tool I am developing to manage tasks within my development team.
This tool is inspired by task management principles laid out in the Lean
Startup book. Here is the link to the demo
http://kanbann.com/. Please let me know your suggestions. <comment><AUTHOR> Here is a tool I am developing to manage tasks within my development team. This tool is inspired by task management principles laid out in the Lean Startup book. Here is the link to the demo <http://kanbann.com/>. Please let me know your suggestions.

Technologies used: Backbone.js, Node.js and MongoDB</comment>


The Dark Side of Android Hacking - <AUTHOR> http://www.engadget.com/2010/09/23/editorial-the-dark-side-of-android-hacking/

<comment><USER2> What the hell? He used an unsupported procedure to install software of unknown functionality, compatibility and provenance on his phone, and blames _Google_ for bricking his device?

It's never been very clear what "open" means, but I'm pretty sure it doesn't mean "untrained persons can perform major surgery risk-free".

<comment><USER3> Seriously, and just about every firmware upgrade guide tells you to _back up your existing ROM_.

[http://wiki.cyanogenmod.com/index.php?title=Howto:_Nandroid_...](http://wiki.cyanogenmod.com/index.php?title=Howto:_Nandroid_Backup)

</comment></comment><comment><USER4> Once your carrier gets its hands on the phone, it's not gonna be open, no matter how badly Google wants it to be.

Let's give kudos to Google for making it _possible_ for us to get open devices (either directly from Google, or through one of several niche manufacturers (I'm watching Always Innovating and the Open Pandora people here (also, I was a Lisp programmer in a former life))) and leave the blame where it really belongs: The carriers.

</comment><comment><USER5> Wow..

I assume he's just trolling for pageviews and links, but it makes me wonder if real people actually think like that? I suspect a few do.

<comment><USER6> It's sad to see that according to the comments in the article, quite a few people think that way.

The People to blame are the carrier (and perhaps the manufacturer).

</comment></comment><comment><USER7> The hardest part of rooting my android phone was reactivating it via Verizon's minimally qualified tech support. (I'm pretty sure it is required for all baseband upgrades but even then you could just write down the steps and codes for the next time)

The most _dangerous_ part was actually rooting the phone as I had to flash a downgrade then upgrade from the rooted downgrade, if I expected it to brick it was here.

I knew the risks however and this author doesn't seem to understand that this voids any warranty provided by the manufacturer and is most definitely not supported in any way other than instructions on how to do it.

</comment><comment><USER8> How is this a story? The author happily acknowledges that android doesn't prevent you from being stupid, and then he complains that it doesn't prevent you from being stupid.

You cannot have it both ways.</comment>


Ask HN: Learn coding by doing? - <AUTHOR>

	I am very interested in programs with a focus on learn by doing rather than lecture based instruction. Hacker School and App Academy are the only institutions I have been able to find thus far with such a structure. What other programs should I look into? <comment><USER2> You should definitely check out codeacademy.com

You literally read en explanation as you code in an interactive window right on the same page. Right now they offer HTML, CSS, JavaScript, Python and Ruby if I'm not mistaken.</comment>