Hacker News Reader

Ah but then you get http://www.100percentjs.com/just-like-grunt-gulp-browserify-... (and HN discussion) ... of course, despite this, I'm in your camp. Even as I'm doing mobile and now learning modern/ISO C++ for cross-platform development, the strengths that originally got me hired were in web programming and you can always pick up enough to work with views in one of the big technologies, be it Wordpress/Drupal (sigh), Rails (half sigh) or more abstracted GWT/ASP.NET components. (meh)

That said, I'm not sure where the bar is, even in web. Writing Chrome extensions and apps? Javascript injection on mobile? Dart? Web Components? Ember? (ouch) Angular, or React.js? Or a certain company's stack like Closure? And don't forget security vulnerabilities and keeping up with OWASP checklists or UX improvements, prototyping in HTML. And then there's performance considerations, eg. what Ilya Grigorik writes about these days. And touch screens, mobile, responsive... Front-end has a lot of transferrable skills, but it's a complex beast too, often full of legacy code.

Angular. Seriously.

Today that makes sense. But the react guys (at Facebook) have a point, Angular (developed for LOB apps at Google) can be slow unless you write optimizations for update looping, etc. Eventually Angular directives might be better supported natively as polymer-style components (those are slower still now, and lack IE support), or Dart might rise in popularity, at least beyond that of Angular. And then you've Google Closure, which, like any company-sponsored project/library will get the job done but at the expense of some amount of lock-in, since these projects tend to already have lots of internal code to build with. I'm not sure the answer's that simple. That said, I agree that for today's mix of browsers, Angular has the best compatibility if you want more than React.js. Ember just took too long to settle down and still has oddities in data handling.

> It's not too hard to learn JavaScript and jQuery inside and out

which is why the talent pool is larger and salaries lower.

The same holds for C/C++. You can find a wide variety of companies that use it in one form or another. Plus, it's a front-end technology too :) And it is kind of a superset of Java or C#, so you are a good fit for very many jobs.

Your assessment of the emerging front-end skillset is spot on. For better or for worse, if js frameworks are here to stay for the next few years (and it seems they are), the programmers who got in early are going to clean up as they are now sitting on 1-3 years of experience.

>It's just JavaScript, JavaScript, JavaScript.

No it's not. Because JavaScript the language is so bare-bones, you need to supplement language deficiencies with frameworks and libraries. So you go and pick from a menu of Backbone/Marionette, Angular, ExtJS, Ember, Kendo, jQuery or etc. - some of them work together, some of them don't. Most of those get you part of the way there, you may still need to pull in things like require.js to manage imports. Or, instead of raw JS, you go with TypedScript, or Dart, or CoffeeScript, or whatever, and then put a framework on top of those. You're still not done, because that gets you the JS part, usually you complement it with a CSS framework (like bootstrap) and a SASS framework. In the end, you have a hodgepodge of frameworks of libraries, that plug JS holes, and functionally look and feel different.

So no, it's not simply JavaScript everywhere.

So... javascript, javascript frameworks, and javascript variants. I think "Javascript, Javascript, Javascript" was accurate enough. And Bootstrap is easy.

>"Javascript, Javascript, Javascript"

Unless, Dart, CoffeeScript, TypedScript etc.

It's javascript, angular, and jQuery.

Seriously, jQuery > all the other "low-level" libraries out there combined, and Angular > all the other frameworks out there combined, several times over.

If you want to interview practically anywhere, learn those three and you're solid.

And what a depressing job that would be.

Says you, though.

Angular > all the other frameworks out there combined, several times over.

Sure. But according to my in tray, last week it was Backbone, next week React is taking over the world, and by March we'll have standardised web components anyway.

It may be true that today Angular is much more popular than all the other frameworks, but if so, it will probably be a short-lived peak and IMHO says more about developers putting too much faith in frameworks generally than anything else.

Angular can easily work as a facade to the underlying es6 features coming soon.

But why would you want it to? It's likely to wind up being a leaky abstraction at best, assuming it survives that long, which is far from certain given Google's track record. If you want to be bleeding edge with web components, I would have thought experimenting with Polymer would be more interesting and give an easier transition to native features as they become available. If you want a more production-ready component-style framework today, why not use React instead of Angular?

Because JavaScript the language is so bare-bones, you need to supplement language deficiencies with frameworks and libraries.

Since when? It's perfectly possible to build web sites/apps, even large scale ones, using no framework at all. Pick a handy utility library, whether it's jQuery or Underscore/Lodash or whatever, and get coding.

I don't know where this idea that you somehow have to build web apps using some humungous framework came from, but I hope it relocates that rock and crawls back under it. In the history of programming, very few frameworks (as opposed to libraries) have stood the test of time.

If the point is to easily be able to find work (which was the parent's emphasis), then yes, you need to learn the popular frameworks. No, it's not required for building your own web app, but companies use them, so they'll expect you to be familiar with them.

Where are you based? It seems like in most places it's an employee's market right now (assuming you work for an employer). Given the diversity of front-end frameworks and how new most of the trendy ones are, I find it extremely hard to believe that anyone who's any good at front-end development and has a decent track record to prove it will be short of work any time soon, even if they don't have a full complement of buzzwords on the resume. And of course it's certainly not necessary if you're doing it for your own business or if you're consulting/freelancing and have your pick of tools.

Portland, OR. I think you're probably mostly right with regards to frontend development. All my experience applying for non-contract work has been for backend positions, and I know for a fact that I lost at least two potential jobs because I didn't have the right language/framework on my résumé. But just based on my limited searching for frontend positions, it seems like companies do expect you to know at least one well-known framework really well, even if it's not the one they use. So you shouldn't need to master all of them, but you should definitely be familiar with their patterns.

So you shouldn't need to master all of them, but you should definitely be familiar with their patterns.

I certainly agree with that. I'd expect anyone claiming significant front-end development skills to at least be familiar with ideas like MVC and data binding these days. I just wouldn't much care which specific tools they used to implement those things, and I wouldn't hold it against them if they'd considered their options and then chosen different designs and/or tools instead.

I am stuck in a hiring war-room for the last 2 weeks (two to go). [1]

We are using jQuery/EmberJS/Bootstrap/Grunt. Everyone of the FEs agreed that experience in any JS MVC was acceptable. [2]

So while I agree that it's not JS, JS, JS but it's not quite as bad as what you're saying.

--------

[1]: We were having a problem getting front-end people so they had managers put 15 front-end engineers on the task full time for a month. Our mandate is 30 engineers in 30 days.

[2]: sdumas [at] yahoo-inc [dot] com if your looking!

> We were having a problem getting front-end people so they had managers put 15 front-end engineers on the task full time for a month

I have never heard of a hiring war-room or lockdown of that type. Are you redesigning/improving the current process, or just interviewing people until you meet the quota?

both and. the talent acquisition folk were very interested in how the engineers went about finding people. they shared all of what we were doing with the other talent acquisition people at their all hands meetings.

It's a real shame you guys chose ember over angular. Why did you do that?

lol, tons of reasons... a few off the top of my head; routes are central to EmberJS and are key to SPAs. AngularJS uses primitives as models which means that at the kind of scale we are hitting in our apps performance suffers (dirty checking 10k rows is killer) (also, computed props are easy, and we're into UAP). EmberJS' caching rocks.

But the big one is -- Google. When are they gonna pull the plug on AngulerJS, how broad is the contribution base outside of Google, and not using YUI was already a battle...

most boss think front-end programmer as code monkeys, and back-end guys as architects. Good luck.

You're either working for the wrong boss, or the wrong company then.

I know, but hey, as long as I am not getting the wrong salary, ay?