Front-End Handbook | Hacker News Reader

Front-End Handbook

frontendmasters.gitbooks.io

A word of caution from a worried developer -

Implicit in this laundry-list of technologies is that learning the technologies implies you will be good at frontend dev.

This is simply not true and encourages the incorrect philosophy that knowing technologies makes you a good developer.

Aspiring frontend devs should just practice building and maintaining stuff, not worry too much about the technology, and that itself would put them on the fast track to becoming better developers. Along the way they will encounter problems and evaluate the pros and cons of various solutions to solve those problems. That's the valuable experience you need to be a successful frontend developer - not simply knowing what gulp or angular is.

If you want to be a successful front end developer you need to learn JavaScript. The more JavaScript you know, the more valuable you will be. If you know JavaScript then you can pick up Angular / React / Gulp / Node / Backbone / whatever web tech someone needs.

Having experience with a specific technology might help you, but I'd hire a JavaScript expert with no experience in my tech stack more than an someone who has become an expert in a specific framework / library.

I think implicit in "learning JavaScript" is learning patterns. This is not picked up through books (except perhaps one of the patterns books), but through experience, reading good code, and talking with other developers.

I agree. If you can come to grok CSS, HTML, and Javascript, there's no limit on the abstractions around those three concepts that you can pick up.

As an anecdote, I am not a front end developer. I try and shy away from it as much as possible; I don't have the design chops to make my own designs, and I dislike the chains of following someone else's design to the pixel. That said, I was able to pick up an abandoned sass/React/Flux/gulp/bower/lodash/... project built up by an intern and make it work in under a day.

Because I knew the basics, I could follow the execution path, consulting documentation where necessary, and figure out why things didn't work.

Learn the basics; it makes understanding the abstractions easier.

This basically says: Learn all the things!

But the best front-end people I ever saw did not learn all the things. They learned a few things, mastered even fewer of those things, but ultimately understood how to make what they had learned work for them to do whatever they needed to do.

If anyone is reading the handbook and thinking this is too much, you'll never get through it... you're right, it is and you won't. Just learn HTML really well, CSS fairly well (and pick a tool to help manage the CSS) and learn raw JS and one of the helper systems (JQuery). That's it... get the core skills right, get those mastered, and the rest will come easily and you'll understand when and why to use them.

This is great advice. Especially in a time where people from varied backgrounds are scrambling to learn software development, it is critical to stay focused on what matters to avoid getting bogged down. So, for anyone getting bogged down, just get back to handling your CSS and learning your JavaScript fundamentals along with one framework.

Perhaps should link to here:

https://www.gitbook.com/book/frontendmasters/front-end-handb...

or here:

https://frontendmasters.gitbooks.io/front-end-handbook/conte...

Current link points to a list a front end developer job titles which had me wondering what the context was for a minute.

I was just going through the list of possible interview questions (http://www.frontendhandbook.com/practice/interview-q.html)... Am I the only (mediocre) Front-end dev that has problems answering these questions? I always start doubting myself when I don't know the answer to basic questions like "Are there any problems with serving pages as application/xhtml+xml?". All these questions ring a bell somewhere, but I have no idea how to turn that into a good answer at an interview... Whenever I run into problems I just try to fix them... I'd like to think that's more important than this factual knowledge.

> "Are there any problems with serving pages as application/xhtml+xml?"

That was more relevant when XHTML was still vying to be the future of markup on the web. The issue was that the XHTML content type mandated a strict XML parser that hard failed if your markup wasn't well-formed, whereas HTML is more lenient. With XHTML, it was easy for a single stray closing tag to kill your entire site. This was an especially common concern if you allowed markup in, say, comments.

> That was more relevant when XHTML was still vying to be the future of markup on the web.

Unfortunately many interviewers still ask these types of questions even if it's no longer relevant.

Who can look at this list and actually want to start getting into frontend development? 30 learn X entries not to mention 30x lists of tools for each area. Front end development seems to have gotten beyond ridiculuously complicated - especially when you consider half these entries will probably be outdated in 6 months time and almost certainly in 2 years time.

The best frontend developers I know are those that actually stick to frontend development. Imho its one of the most frustrating job in the field yet underappreciated and looked down upon.

Seriously, how is this on the front page and why do I get down voted for pointing out that it is less than excellent? If you want to be a better developer, especially as a front-end developer, you need to learn how to write and value good documentation. Let's take a look at the first paragraph:

> Below is a list and description of various front-end job titles

Completely redundant, just makes reading and editing it harder.

> The common, or most used (i.e. generic), title for a front-end developer is, "front-end developer" or "front-end engineer".

Common/most used/generic? There's no need for this clarification and developer versus engineer is already covered by that subsection.

> Note that any job that contains the word "front-end", "client-side", "web UI", "HTML", "CSS", or "JavaScript" typically infers that a person has some degree of HTML, CSS, DOM, and JavaScript professional know how.

So HTML, CSS and JavaScript means HTML, CSS and JavaScript? Even if you want to keep this line it's an easy rewrite to 'Jobs that contain "front-end", "client-side" or "web UI" imply work experience with HTML, CSS and JavaScript'.

I could go on and on, like the use of "when the word" everywhere. Half of every description is fluff that is already obvious by the context. It's not properly written for it's audience. If you don't know what testing is you're not going to be enlightened by a list of tests, you need to describe what someone in testing does and what purpose it has.

> When the word "Acessibility" is included in the job title, this will denote that the developer has extensive experience crafting front-end technologies that support accessibility requirements and standards.

Again, seriously?

Your comment was almost as long as the page you're complaining about. Maybe channel your time into writing something useful instead of just complaining that what others do isn't good enough.

Your complaints were all about on the first page. There are a lot more pages, and decent enough content on subsequent pages.

And what does your own condescending remarks add exactly? This was the page that was linked and frankly it wasn't good enough for HN nor did it reflect particularly good on front-end developers. Maybe something you yourself should think about when posting comments with a claimed employer in your profile.

I may have been a little condescending in my response, but I stand behind my point. You listed a bunch of surface level complaints about the structure of the text which had little to do with the content. They weren't constructive at all.

And it's worth pointing out that though HN doesn't have many guidelines, complaining about downvotes and that a submission isn't appropriate are two of the things that they ask people not to do (https://news.ycombinator.com/newsguidelines.html).

At least my comments add something to the discussion, yours is just meta complaints that helps no one. My comment was constructive, I even offered suggestion how to rewrite things to make it better. It wasn't more surface level then any other comment and I did "complain" about the content if you read the last two lines. My main complaint wasn't about the structure at all, it was about signal to noise level and not providing value. The part about accessibility is a perfect example, it has structure but says nothing to someone who doesn't already know what it is.

I wonder is this how you treat code at Facebook? You let glaring faults just sit because criticism are seen as complaining? Just because it's text and not code doesn't make it less important. In fact is often more important since the value is in the text itself, while code can be "good enough" if it produces the right output.

You have now made two comment, but still haven't actually disagreed with content of my comment. It's comments like yours that ruin HN by making it into lowest common denominator meta discussions where everyone just states opinions without having to present any form of argument.

Since you are so concerned about my time I can inform you that I was going to write another comment about something that I had researched which five other people were cluelessly speculating about, but now I wrote this one instead.

a successful frontend developer is more than just the sum of the tools he/she knows. the individual needs to have an interest (dare I say passion) in art & design. Needs to continuously evolve his design vision, and have enough of interest of the subject to peruse work of his peers to get inspiration.

Very cool! Does anyone know of anything like this for back-end development?

Is this useful? It looks like a ton of links with very modest curation.

Perhaps not for someone of your (or my) level of experience with the subject matter. But when I was a beginner, this was exactly the level of curation I needed (and could not find at the time). If the links provide all the details, there's no need to pad the book with redundant content. I'm familiar with almost everything mentioned here, but I still appreciate what the author has done. I just shared this with my entire team.

I'm sorry but that page is a big mess. There's no structure, too much redundant information and confusion of terms.

How do you save on hacker news?

Upvote it.

Reply on news.ycombinator.com