If you find the book helpful - great! I'm glad. I can definitely see a lot of faults in my own work but I don't have infinite time to fix them, which is why the book is on Github ( https://github.com/mixu/singlepageappbook ).
There are things that I would definitely discuss differently if I wrote the book today - since things have developed a quite bit in the past year and half. I'll probably start working on a second edition late this year to rewrite the parts that I find most annoying in my book. I need to finish and ship a bunch of open source stuff before that though.
Excellent work. This is why I love our internet age. A single person can have a huge impact on many people, and he/she doesn't need to have massive media behind.
Any chance you could at least outline what you think the biggest changes in the past year and a half have been, for those of us who read the book? What are the things you would have written about differently?
I haven't yet fully formulated what I want to say so this is still just speculation on what the 2nd edition might contain. I can see a lot of room for improvement, especially in the latter chapters. Overall, the way I would frame the problem is much crisper now, and I think I have figured out how to better explain and implement my controller-averse approach, as well as server/client hybrid rendering and routing.
The community is more sophisticated about packaging these days so I would spend more time going beyond the basics and it's obvious what the most popular frameworks are (from ~8 contenders to ~3) so I should bring those in concretely to illustrate points. When I wrote the book, many of the frameworks were pre-1.0 and hadn't figured things out.
I also wrote another (to be released) book just on distributed systems which has helped with my thinking re: backend integration/caching/offline though I'm not sure how that will be directly reflected in this book.
Finally, I'd like to audit my use of indefinite articles, particularly within chapter headings.
Nice book, but seems to be very focused on 'this is the one true way'. There is very rarely ever 'one true way' for all problems, and the reasoning given for each choice isn't solid enough to consider it a closed problem.
It would have been great if there was a small part of each section given to a short discussion of other alternative options that could be taken if the first approach isn't working out for the team. eg, the book's requirement to use specific libs like CommonJS
> seems to be very focused on 'this is the one true way'.
Good. I hate when the goal (of building something, of answering the question) is obscured by the author's need to show how knowledgeable or insecure they are and share 15 different ways to do something. Not every piece of writing is a philosophical treatise.
Though sure, a short list of alternatives wouldn't hurt. The justifications for our choices OTOH expand quickly because humans seem to be really good at those[1].
Provided that one way is both achievable for beginners, and a healthy practice to continue in the absence of further development. You don't want beginners thinking some terrible practice is how they are supposed to build things, just because it was the only workable thing you could use to introduce them to the topic.
I didn't read it that way. The author goes to some effort to point out the reasoning behind the choices made, and also goes in-depth explaining the options between client-centric and server-centric designs, and where the trade-offs are. While it's true that only one type of implementation is discussed in detail, it would be impractical to discuss the popular frameworks without getting lost in pointless detail.
It's excellent for someone, like me, who's new to JavaScript development. Until you can build up a frame of reference, it's difficult to understand why one approach works over another, even when someone spells it out for you.
An article that just says "this works and is easy" is sometimes what you need to just start writing some damn code.
Can't believe something like that creates bad impression in tech materials, but I have always been surprised with myself about how my impression changed due to grammatical mistakes.
I wouldn't avoid the book because of that, but I don't know about others. Such mistakes might make one think the author is uneducated, sloppy, or both. In a free ebook and with english as a second language (guessing that is the case), it's totally excusable.
It has to do with attention to detail, and for me it raises the possibility that I can't trust the technical aspects of the writing. For sure that's a grammar-bigotry on my part, I'm not proud, but I simply look askance a bit after seeing that kind of thing.
Mixu, I have recently read your book front to back. I am new to javascript development and javascript MVC frameworks. I found your book to be both informative and concise. It shed a lot of light on the major aspects of single page JS and what the frameworks are trying to address. Thank you for your time
It's not well known, but https://circleci.com is a one-page JS app that seems to be very similar to the book. The datasource is slightly different (we use Knockout, and so follow their pattern, with simple jquery for "saving" and loading), but otherwise it's surprisingly similar.
I use knockout.js too and I had a look at your code: although you seem to follow a lot of best practices, I noticed your code is not minified. Any reason why?
Ah, yes. We use a dieter [1] for our asset pipeline, and it supports minification using Google closure compiler. Unfortunately, this breaks Twitter Bootstrap.
I did some measurement and I think we can save 19% through minification using uglify (once you included gzipping). That means its not currently worth the few hours of making it work and verifying that it doesn't break anything (versus other ways we can spend our time). Probably.
Really enjoyed the material, thanks for writing it. Hopefully the community can keep it fresh and relevant as the tech evolves, since it's on Github. It seems to have worked really well for Addy Osmani's Backbone Fundamentals, I'm sure we can do the same for your book as well.
Well the former is an interesting thought experiment, but very much yes to the latter (at minimum, there would be value in a "book viewer" program that embeds a code runner).
This has been the single most important book I've read in my JavaScript career. It's priceless, and really pushed me towards daily best-practices that I would have otherwise been unaware of coming from a different language.
Thank you so much for this book. Your writing is clear an concise. I am starting out with angular and this is just what I need, not another piece of angular documentation.
Aside from Airbnb's Rendr (and I've heard DirbyJS does something similar), you could also build your SPA on top of your server-rendered pages. After pageload, hijack the click events from your navigation controls and have it fetch and render content via ajax. It's certainly not "DRY", but it's easier to implement for existing content-focused sites.
Airbnb gets around this by rendering their backbone.js views server-side, then pushing them out upon page load. They call it 'Rendr', which they have released [1].
I haven't gone through much of the content, but I was expecting a site about single page apps...to be a single page app. I mean, I understand that there is probably a wealth of information on the site, but it not being a single page app is kind of a bummer. It feels a little less credible, but more importantly, it feels like a missed opportunity to show "What You Could Build If You Read This Site".
There are things that I would definitely discuss differently if I wrote the book today - since things have developed a quite bit in the past year and half. I'll probably start working on a second edition late this year to rewrite the parts that I find most annoying in my book. I need to finish and ship a bunch of open source stuff before that though.