Wow, this is huge!<p>I'm stoked for the book. I'm surprised-but-not-really that it will use JavaScript as its main language to teach the concepts!<p>> When I wrote the first edition I was frustrated that I was having to write the book's code in a language that was significantly worse than the language I preferred (Smalltalk). Little did I know that I would take another step downwards twenty years later.<p>Oh, the irony!
The Refactoring book in Javascript looks like an early April, 1st joke :-)<p>What I really miss is the integration with the automatic refactoring tools in our IDEs. How would I make a heavy refactoring if I already have a "extract method" in my interface? Would it be the same? Some of the refactorings are easier to automate so are more common in the IDEs. Would are better paths considering what is automated?
I realise this is an unpopular opinion, but I really didn't like the previous book. Don't get me wrong, I definitely think refactoring is a good thing (in moderation!). But Fowler presented a list of possible refactoring operations, including step by step instructions... for <i>very</i> trivial things.<p>In the introduction he drew comparisons with GoF design patterns book, saying he wrote it hoping people would refer back to it as they do to that book. Yes, sometimes I need to rename a function or split it in two, but do I really need to dig out a reference book to look up how to do that? And the comparison to design patterns is crazy, those are at a far higher level of abstraction and are correspondingly less obvious (and more interesting).
I'm hunting around these days for good books on general programming. I'm a fairly pragmatic programmer (not <i>everything</i> needs to be a class). Has anybody here read the first edition, and what was your impression of it?
Am looking forward to the book. Read the first one in the early mid 2000s and it changed my view of programming forever. Java in the modern climate isn't the best choice anymore to do this.<p>The move to a less class-centric approach is a much needed and welcomed shift. It helps to illustrate the spirit of the pattern or technique without getting weighed down with the restrictiveness and arguably dogmatic nature of java.
Am I the only one who thinks that using javascript is a <i>terrible, horrible, no-go</i> decision?<p>He could have chosen Python which is also one of the top languages and it does not have the quirks of javascript.<p>I can't help but feel that he only chose this language because this is the language which will net him the most ROI.<p>And we'll take the collateral damage which is an influx of people who will wave his book and say "Let's use this language! Even Mr. Fowler uses it! This must mean that this is the best language there is!"<p>Imagine the damage this will do to us grunt programmers in the field. Now it will be even harder to push <i>real</i> languages through management now that a celebrity in our little scene is using javascript.<p>I bet that Mr. Fowler doesn't have to program in that crappy, quirky, horrible 9nth circle of hell language.<p>Sorry for the rant but this had to come out.
This is intriguing, though personally I never connected much with Fowler's writing in the past (though I have gotten into his <i>ideas</i>).<p>Anyone know of any other good books about high-level design/architecture for javascript?<p>Actually, thinking about it, maybe what I'm really looking for is something for designing/architecting things in dynamic/weakly typed languages... (Been doing JS for a bit now, but I spent much longer in Java before).
The book will be released in a series of ten thousand editions, each one modified slightly from the previous one but still correct and self-consistent.