- ペーパーバック: 209ページ
- 出版社: Oreilly & Associates Inc; 1版 (2010/3/15)
- 言語: 英語
- ISBN-10: 059680279X
- ISBN-13: 978-0596802790
- 発売日： 2010/3/15
- 商品パッケージの寸法: 17.8 x 1.5 x 23.3 cm
- おすすめ度： 1 件のカスタマーレビュー
- Amazon 売れ筋ランキング: 洋書 - 156,420位 (洋書の売れ筋ランキングを見る)
Kindle 端末は必要ありません。無料 Kindle アプリのいずれかをダウンロードすると、スマートフォン、タブレットPCで Kindle 本をお読みいただけます。
Through his writing and speaking, Nicholas seeks to teach others the valuable lessons he's learned while working on some of the most popular and demanding Web applications in the world.
For more information on Nicholas: http: //www.nczonline.net/about/
Amazon.com で最も参考になったカスタマーレビュー (beta)
One thing that should be clear is that this book is NOT intended for BEGINNERS, since it already presumes that you have a good knowledge and experience with JS programming.
The book has some typo mistakes (which doesn't affect the understanding) and some of the line graphs (used to show browsers benchmark) are hard to read since all the lines look the same (as of 1st Edition).
(2) The frustrating part about working at a well-organized shop is that you get yourself all excited for a book like this and then half the recommendations in there are things that you're already doing. Put scripts at the bottom of the document? Check. Minify and compress? Check. Concatenate and package? Check. So on the one hand you say: "I guess I can sleep a little easier at night knowing that our build system adheres to the best practices recommended by the experts out there." But on the other hand, you're a little disappointed because you were hoping for some startling revelations. Again: not that this makes it without merit. From this perspective, what is noteworthy about this book is that these best practices and techniques are all gathered up in one place and presented in a logical order; even if "you're already doing it right", it is still a worthwhile exercise to meditate on the specifics, and to really go deep on why these best practices are important. (Plus, it's great to see the data -- nothing beats a little chartporn for proving the point.) [Rated: 4 of 5]
The title of the book is of course a throwback to Steve Souders' epitomous High Performance Web Sites: Essential Knowledge for Front-End Engineers, released a few years back by the same publisher. In much the same way it covers all aspects of performance in its chosen realm. That book gained Souders much appraise for making the web developer community at large aware of the various performance issues connected to the frontend, and how & why optimizing time was better spent there than on the backend which had previously been the prime target for such efforts. Last year Souders piggybacked on that appraise by releasing a sequel titled Even Faster Web Sites: Performance Best Practices for Web Developers (EFWS), where he - along with a group of co-authors, including Zakas - delved even deeper into frontend performance.
Definitely yes. Although a Venn diagram would show quite a bit of overlap...
* HPJS chapter 1 (Loading and Execution) is largely made up of the same content as EFWS chapter 4 (Loading Scripts without blocking)
...the books have enough diverse content, difference in tone of voice and primary focus, to make for two quite different reads.
The question of unique content, I feel, is largely moot anyway, as it is very rare to find a book containing knowledge that cannot be found elsewhere. That's not a bad thing, it's just the way of the web. When buying a programming book, you're paying for the convenience of having lots of related material collected in one place. The research behind HPJS chapter 2 (Data Access), for instance, has been detailed on Zakas' blog, just as Stoyan has already blogged a lot of what ended up in chapter 3 (DOM Scripting).
So downrating the book for being a "compilation", as one of the few not-so-positive other reviewers here does, is rather unfair and beside the point. HPJS should be judged, instead, by how well it weaves it all together, and of course by the quality of the individual chapters. In my book, it receives top scores in both of these categories.
Some co-authored books while inevitably feel rather fragmented. There are moments in EFWS when the (very) different writing styles of contributing authors gets in the way of seeing the whole picture. Similar moments arose for me while reading the semi-recent jQuery CookBook, which - while excellent - at times feels very schizophrenic. Of course co-authors need to be given some artistic leeway as to how they express themselves, but when they seem to have different takes on the main ideas behind the book, it becomes a problem.
This never happens in HPJS, which obviously has been the target of some very loving editing. Even though the different performance aspects have quite a different flavour, as does the writing of the contributing authors, you never lose the sense of context. The fact that the book stays true to its gospel - performance - is one of its biggest strengths.
There must have been innumerable temptations to mention non-performance related things that could be made to sort under a chapter's domain, but not fit inside the book as a whole. I'm sure, for example, that Steven Levithan bit his tongue while writing the (brilliant!) chapter on regexes, forcing himself not to share parts of his vast regexp knowledge that doesn't relate directly to performance. Because he and his peers withstood that temptation, HPJS is a better book.
So, to finally bottom-line this; both books have their place. EFWS and HPJS are partly speaking about the same things, but in different voices under different headlines to different people. Also, HPJS is a bloody brilliant book, and not owning it should be reason enough for ostracication from the frontend community.
Upon running the app in IE7 the app lagged to a point where it was unusable. Intensive processes that took 2 seconds in Firefox took upwards 10 minutes in IE7 (not exaggerating). We complained about how much of a pain it is to program for IE for a while, but realized that we had to find a solution to these problems; they weren't just going to disappear by us complaining.
A Google search revealed some ways that we could optimize our code, and it worked to a degree; but what really helped our application pur was this book. By learning about the amount of load associated with certain processes, and discovering alternate, better ways of executing them we were able to make our application work in IE.
Looking back, I wish I'd know of these best practices and tweaks earlier, and certainly wish that I'd read this before we started with our app.
After reading it, there are perhaps four tips from the entire book that are relevant to developers today. The rest are based off micro-benchmarks of browsers like IE 6 and Firefox 4 - needless to say, how browsers handle JS has changed a lot since then, so these benchmarks are useless.
In conclusion: if you absolutely /need/ to write the absolute fastest JS possible, this book might be worth a quick skim and should not be taken too seriously. If you aren't concerned about shaving off a couple of ms from your code, you can find much of this advice for free, online, with up-to-date benchmarks and comparisons.