Hacker News new | past | comments | ask | show | jobs | submit login

The problem is, it's our fault that recruiters are now asking for Angular, because we sold our employers on Angular and built their apps in Angular. Now that Angular is mainstream and has fallen out of fashion, they need to hire more developers to maintain all those Angular apps we built for them.



There is no "our" and there is no "we". Developers, web developers, JS developers or even HN users who are JS developers are not:

* a tribe

* a close-knit group

* an industry union

You do not assign blame to hundreds of thousands of professionals, who live in different parts of the world, speak different languages and work on different projects.

The web evolves without intelligent design or regard of your personal interests. Deal with it or withdraw in denial to the perfect land of perfect web technologies.


> not:

> * a tribe

> * a close-knit group

> * an industry union

unfourtunately


I would love to see some sustainable structured cooperation with at least thousands of developers participating.

https://snowdrift.coop <-- this is a great example, btw


Oh ok, well then I guess it's just Google's fault.


It's Google fault as in a mistake, a defect, an offense that they've created a popular js framework? Is that a correct interpretation of your words?


Only if you feel that Angular itself was a mistake.

I do, primarily because it's yet another attempt in a long history of misguided attempts to bestow Turing completeness on XML.


Not at all! Honestly there are some WONDERFUL things about angular. There are some bad ones too.

- Polling for changes vs. event driven - two way data bindings causing infinite redraw loops. - "feels like O(n^2)" performance on ng-repeats / large pages

but things like the templating, directives, data-binding... they are all really good things.

And dependency injection! They have really moved the needle forward on client side testing.

No angular in itself is not a mistake at all. There are mistakes without question. I suspect the angular 2.0 release will address many of the major criticisms. Though, I haven't read much about it yet.


ng-if, ng-switch, ng-repeat? There's already a language in the browser that does these things, it's called JavaScript.

Why do you even need dependency injection and singleton services and factories in a dynamic language with closures and first-class functions? You don't. Client-side testing works fine without DI. Angular is just a way to do Java in JavaScript. It's a pile of unnecessary complexity designed to sell to enterprises that love over-designed Java projects and want to make client-side development feel more similar to what they know. In that regard I suppose Angular is a little better than Google Web Toolkit, but that isn't saying much.


> ng-if, ng-switch, ng-repeat? There's already a language in the browser that does these things, it's called JavaScript.

It's nice to have a largely declarative way to specify markup but still allow simple loops and conditionals.

Hasn't every template language in the world has come to a similar conclusion?


> Hasn't every template language in the world has come to a similar conclusion?

No, not even every mainstream template language. For example, I still use ERB and EJS extensively, and so do many other engineers. ERB and EJS use the control flow constructs of the underlying languages (Ruby and JS, respectively).

There is of course debate about whether templates should expose the full power of a programming language. I have tried templating languages that do and ones that don't. For now, I'm sticking with templates that let me mix in arbitrary code as I see fit. Could I abuse that power and make a mess? Absolutely. But I try not to, and my code stays pretty maintainable.


The overarching problem here is herd mentality. Using Angular is a bad idea, but lots of companies are using it anyway because The Herd stampeded towards the new shiny thing, mostly because of how cool two-way binding looked in Angular's demo toy app.

Now all those companies are bogged down by Angular, but feel like ejecting it would be too costly. Elsewhere, lots of new developers are introduced to Angular and invest time and effort into learning it because they don't know any better.

Herd mentality is a big problem. It's basically the polar opposite of thinking for yourself, and as such, extremely detrimental in other aspects too.


> Using Angular is a bad idea, but lots of companies are using it anyway because The Herd stampeded towards the new shiny thing

The most ironic thing in all this is that your comment is still full of Herd mentality, except that it goes the other way.

Angular is a framework, period. Using it is neither a good or a bad idea, it all depends on the people who actually use it.


The couple of times I've worked with angular, some things went incredibly smoothly, and when you hit those edges, it really reminded me of ASP.Net 1.0, it was nice for about 80% of your workload, but the other 20% took 10x the effort, and was a much bigger headache to work around.

Honestly, if/when browsers have better support, I think something closer to Polymer may be the best of all worlds with web development... for now, I find that React code tends to be the most sensible (with a decent framework around it)... not to mention shared client-server code with node/io.js


I can make functional prototypes very, very quickly with angular. There are things it does not do well, in my opinion, but it has given me a tool that previously didn't exist in the JS world.

I don't care about the turing completeness of angular.


I don't.

If Angular has produced a local optima of efficiency in the range of "misguided attempts" then it's effect on the development ecosystem was a net positive.

That said, I am extremely concerned that most popular frameworks/libraries are products of megacorps.


That is in part due to the complexity of problems in frontend and that most companies don't need to solve those problems (or don't have the resources to solve them).


Ember would be a notable counter-example.

I think a more important reason would be that Facebook/Microsoft/Google media influence and corporate support creates massive brand awareness and generates instant interest. Educational projects anticipate the interest from developers and create courses, tutorials and reviews. The cycle continues and bam! we have an information cascade[0].

Rich get richer and poorer get poorer (in developer mindshare). Megacorps reap the benefits while indie developers are not able to achieve critical mass.

I shudder when I think about the possible Typescript/Microsoft, Angular/Google, React/Facebook domination in web technologies.

[0] http://en.wikipedia.org/wiki/Information_cascade


I think that has more to do with developer evangelists/pr people and budgets. Most good ideas languish in obscurity, even when given the light of day.


Angular is helpful because it promotes things like loose-coupling, dependency injection, modularity, re-use and the factory pattern. I agree that two way data binding was oversold. It isn't a bad thing, just not the most important thing about angular. No doubt angular itself, and other libraries, will evolve. But I don't think angular is a mistake. It encourages developers to design applications the right way.


Angular is helpful because it promotes things like loose-coupling, dependency injection, modularity, re-use and the factory pattern.

Modularity and code re-use are like apple pie and motherhood. The real question is, do you need dependency injection and the factory pattern to get those things? In JavaScript, the answer is no you don't, because you have closures and first-class functions. Patterns like DI and Factory were invented to compensate for the deficiencies of Java, they are superfluous in JavaScript.


I have to agree.. factories and IoC/DI in JS just seems like such alien overkill in the space. Yes, it's great when you need to create a testable system in a strongly typed world like .Net or Java, but in JS you can simple spike your module loader for unit testing your modules in certain conditions (proxyquire and the like).

Even in those platforms (.Net and Java) unit testing is such a miserable experience, and adds so much complexity it's easier to just skip unit testing in favor of simpler classes/methods and better integration tests.


Agree - i think 2-way data binding is a more superficial benefit vs the other benefits you mention


I think it's not so much the fact that developers praised Angular, but rather this same above mentioned proliferation of frameworks - with so many choices, at some point it becomes paradoxically more likely that people will follow the herd instead of picking each his own framework (if I may oversimplify to make the point clearer) with the risks that entails (possibility of bad choice, of support ending while you still need it...). Nobody's gonna get fired for betting on a big name like Google.


It is our fault if Angular was not a best tool for a job at the time, otherwise we should be happy that we have better tools coming to help us doing our job.


What is problem for you - for some might be job security :) And I think Angular is still very much in fashion. At least this is impression I am getting from occasional talks with random recruiters.


this is impression I am getting from occasional talks with random recruiters

What's in fashion isn't what the recruiters are talking about, but what the developers are talking about. Recruiters will always lag a bit behind whats actually in fashion.


Exactly, recruiters are not cool, so when they are asking for a particular framework that is the strongest sign that the framework isn't cool anymore.

It's just like when your parents start listening to your (former) favorite musician.


I guess it is also depends on who is judge - either business (my case) or developers (yours :))


If you're talking about finding a job now, then I absolutely agree. But if you're talking about what technology developers will persuade their employers to adopt in the future, then developers are the ones who decide.

Employers seem to be influenced by what the developers push (maybe not short term, but longer term it seems to me to be that way). Recruiters go where the employers are. Therefore, IMHO, ultimately its the (vocal) developers who pick the fashion.


Right, his point is that it's in fashion with employers and recruiters because there are things to be maintained and sometimes even built. Where everyone else on HN that stays up with JS is trying to things with maybe a reactjs, or this, now.


Haha, yep. I did that. Sorry, Future Me.

Love, Past Me.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: