I was reading HN on my phone, and this looked interesting, so I tapped the link. It took me to a brief page describing the three parts of the book, with a headline and one sentence about each part. At the bottom it said:
So I tapped the link. It opened a new tab with a brief page describing the three parts of the book, a headline and one sentence about each part. At the bottom it said:
So I tapped the link. It opened a new tab with a brief page describing the three parts of the book, a headline and one sentence about each part. At the bottom it said:
Hmm... Some faint little gray icons at the top. Nothing there jumps out at me as a way to read the book. I keep wanting to go back to that compelling "read online at:" link.
But this time I skip past it. I go all the way to the bottom of the page where there is a faint gray angle bracket. What does it do?
I did it! I made it to the first chapter! Now I can read the Front-end Developer Handbook.
This is a true story. I really did tap the link that many times. I am not making any of this up.
100% agreed. It's not well-designed on the front-end for mobile. That would make me skeptical about the book itself since it's supposed to be about...front-end design.
But I think one should be careful about the distinction between front-end design and development. This book seems to focus on development, and as someone who's taken a couple of courses from Frontend Masters, I trust it to be solid.
Indeed. And I'm sure Cody will see that this is fixed.
I had a chance to work with Cody on the jQuery Cookbook, and he's a smart guy. So Cody, if you see this, my apologies for poking fun at your new book's mobile experience!
My chapter of the jQuery Cookbook had a much bigger blunder. In a "recipe" called Coding Bare-Metal Loops, I recommended a particular loop style as the ultimate in speed...
> Use a for loop instead of .each(). To iterate over an array, it’s hard to beat this loop:
for( var item, i = −1; item = array[++i] ) {
// do stuff with item
}
> But there is a catch: this loop works only if your array has no “false” elements, that is, elements whose value is undefined, null, false, 0, or "". Even with that restriction, this loop is useful in many common cases, such as iterating over a jQuery object.
Well... It didn't quite turn out that way. This loop style can kick you out of the optimizer because it tries to access the nonexistent element after the end of the array. That's perfectly legal in JavaScript, of course - any nonexistent element evaluates as undefined - but code optimizers do not like it when you do that.
So a conventional loop turned out to be much faster:
I'm going to say something good about this handbook for a change of tone.
Imagine an area of work that you have no idea about. Let's say Aerospace. If someone put together a set of links and categorized the stuff you need to learn to be able to work in the field, it is immensely useful since the simple listing of the things you need to learn about itself is a learning. A 0 to 1 bit flip. Though this post is not a highly curated handbook, it educates you on what you should Google about. That is a huge win by itself.
Agreed, I currently do a mix of front and backend development but there is a tonne of stuff in here I didn't know about comes back to "known unknowns and unknown unknowns".
About a year and a half ago I started piecing together what I needed to know to get a job as a Front end dev. Spent tons of time spinning my wheels. Looking at this now that I have my first job, it would have helped a lot as far as knowing what I had to learn and how it all relates.
I take issue with the case against generalist or 'Full-stack' engineers. Of course you'll find people better at things if they specialize. But learning core javascript very well along with things like HTTP, databases, css, html etc. I'd say you're a pretty solid engineer that can build full products.
Yeah it confuses me when I meet backend developers who can't deploy their app for example.
If you can't:
a) Tell me what libs your app requires & how to install them in a resonable way
b) The privledges required to run said app
c) The security implications
d) How to scale your app, particularly what I need to do to get it to behave over multiple servers
e) be resonably sure your code is working
f) Write some code to automate the deploy of this.
Then you're probably just not that amazing of a developer.
Plus I think there's a big difference in respect a full-stack team / tech leader garners over someone who doesn't really understand the technical challenges of half the team.
If you want to work on the front-end, learning fundamental JavaScript will be your best asset. It will help you in job interviews, help you understand other developer's code, and help you make good decisions in your own code. The front-end is full of amateurs, it's easy to stand out as a serious developer by truly understanding the language of the web.
Do you have any tips on how someone with a solid background in CS fundamentals, js, and backend dev can learn a mental model of HTML and CSS layout such that it doesn't feel like playing Wack-a-mole?
Feel your pain - I remember vividly struggling with these things when beginning. here's a few hints..
- Avoid floats as much as possible. They are useful, but understanding where and when to use them takes time. Using display: inline-block will take you a long way.
- Height comes from the parent element, in general. A really common mistake is trying to do something like 'height: 100%;' when the parent element has a height of zero and not getting why it doesn't work. Here's an example that uses 80%/20% height layout, without any craziness: http://codepen.io/dazld/pen/jbrLoa
- Whitespace is important with inline elements. Trying to figure out why inline-block stuff has a gap? Check if there is any whitespace around the markup, remove it and see if that helps.
Playing with CSS & HTML is incredibly rewarding and fun once you develop fluency - and not as complex & arbitrary as may seem at first. Stick with it!
Learn about the DOM and then just start building stuff. Html and css have enough idiosyncrasies that you kind of have to learn by doing. Start with building something simple using mostly jquery and then learn about MVC and move on to more complex front end frameworks when you need them. Dealing with CSS will probably always feel like playing whack a mole.
DOM is a tree of hodes, HTML is used to define the tree. Each DOM node generates a box. Different node types generate different types of boxes by default. CSS controls visual formatting of the boxes, including changing the box type.
The CSS 2.1 visual formatting model specification no longer covers everything CSS can do, but I found it useful when trying to get a feel for what was going on back in the day: http://www.w3.org/TR/CSS21/visuren.html
I think you end up playing wack-a-mole for a very long time. Indeed I think browsers add new moles faster than they can be whacked. For every bit of horror that gets "fixed" we get a couple of new bits of craziness and the fix is usually I nconsisfenfly implemented and has its own issues.
There are two good things about jquery, flawed as it is — it lets you get stuff done without really understanding the details and it presents a usable idealized picture of what the DOM ought to be without pushing your face into the underlying mess. It also provides a pretty satisfying programming idiom for JavaScript.
Not that I don't like this book, but how is it that it was allowed to be re-submitted in such a short time frame? A few months I can understand, but I literally still have this book open on one tab from the previous time I saw it on HN, because I'm slowly going through it.
High level in many areas "full-stack" is not as mythical as is suggested, it just takes someone with the right aptitude, and a long time over a lot of roles to get there.
Whether it does such a person any favours in the employment market is another question as you can't build businesses on rare commodities.
The first article is called "What is a front end developer?" and a good 20% of the page is devoted to explaining what headless browsers are. That's a confusing start.
I looked through this and I don't like this. Having been a front-end engineer in SF for nearly a decade the number one thing you need to know is computer science. The Steve Yegge hardcore engineering fundamentals that apply to computer science jobs anywhere also apply to the front end where engineers are building sophisticated client side applications.
There's little of that in this handbook. Once you know how to program and understand computer fundamentals, then you can build good software and you can take that anywhere, from native apps, to front-end to working on distributed backends.
If you just learn the things outlined there you're probably going to build, slow hard to maintain barely functional applications. You'll struggle at most technical interviews, and you wont progress.
I don't think the problem is the lack of comp sci fundamentals (although yes, there is that) it's that aside from part 1 -- a pretty pointless ramble about "the front-end practice" -- this thing is a crazy collection of links to other stuff without much in the way of curation.
The author recommends three well-regarded books on UI design (I haven't read any of them, but I struggle on) but doesn't seem to have applied them to this handbook. Don't dump an unedited pile of crap on the user -- have an opinion and tell the user what you think they need to know, leave the list of resources to the end.
The problem with this thing is that it's not a "handbook", it's a collection of "useful" links.
I leave design to the designers. I think understanding how to use photoshop is a nice skill to have for working with designers, but I care more about a good engineering implementation for a mock than I do about the design ascetics of it. Front-end engineers aren't designers, they're engineers.
There is a surprisingly wide area of coverage for something titled "Front-end Developer Handbook". I also like the way the content is presented (not the technology used).
The JS testing section is a good example. Pertinent summary of high level concepts before the fold. Additional content to read if you want to learn more.
...was once called a "web master". Was great, haven't heard that term in a long time, although as I recall it's "webmaster". I don't think "web master" was ever a term.
Well, if you chase the latest complicated framework, it will become more difficult to be a "generalist". As you become more aware of fundamental principles & patterns, you are empowered to do more.
i cannot even get to the book on Firefox Android. maybe it only works with JavaScript? i just get one link "read it online" that takes me into a loop to the very same page.
it also does something weird, it prevents the browser address bar for scrolling out of view like it does normally when you scroll..
whatever this is, i truly hope what it teaches is not what the heck they're doing.
read online at:
• http://www.frontendhandbook.com
So I tapped the link. It opened a new tab with a brief page describing the three parts of the book, a headline and one sentence about each part. At the bottom it said:
read online at:
• http://www.frontendhandbook.com
So I tapped the link. It opened a new tab with a brief page describing the three parts of the book, a headline and one sentence about each part. At the bottom it said:
read online at:
• http://www.frontendhandbook.com
So I tapped the link.
Wait! Haven't I been here before?
There must be some other way to read the book.
Hmm... Some faint little gray icons at the top. Nothing there jumps out at me as a way to read the book. I keep wanting to go back to that compelling "read online at:" link.
But this time I skip past it. I go all the way to the bottom of the page where there is a faint gray angle bracket. What does it do?
I did it! I made it to the first chapter! Now I can read the Front-end Developer Handbook.
This is a true story. I really did tap the link that many times. I am not making any of this up.