178 karma · joined March 27, 2013
I've been a PonyFoo reader for a long time. You're obviously a talented guy. But I still want to get an idea of what you have produced before tweeting about it.
That said, I'm very much looking forward to "Mastering Modular JavaScript" and "Deploying Modern JavaScript Apps"! :) I'm sure you know better than most that the internet is full of unappreciative haters, but keep up the fantastic work. There are many of us who have benefited from your writing in amazing ways.
Whatever our collective gripes about JavaScript, HTML, and CSS, we all know how to use them. We know how to handle cross-browser compatibility and different screen sizes. What we need to do a better job at -- and I think this is the root of the problem you're describing -- is pushing back on businesses wanting to ship features too quickly.
We've all been at places where no one values good work on the client. The C-levels want to get things out the door as quickly as possible. They complain that our work has bugs and we tell them "Well that's what you get for telling me I had 3 days."
Because of this heat, front-end engineers rarely engineer their software. As you put it, they hack it together on top of libraries that have been hacked together by others. The solution is to take the time required to do things correctly. That means testing. That means not shipping features so we have time to refactor and upgrade frameworks. That means paying attention to performance and developing tools for debugging errors in production. If we want web development to get better, these things can't be afterthoughts. They must be considered before we say something is "done" and ship it to production.
That said, in my personal projects, I lean towards letting Django handle almost all of the client experience too. There are exceptions for areas that are inherently interactive (e.g. WSYIWYG editor), but the vast majority of my projects involve static content. To me, the complexity and overhead of using a JS library/framework outweighs any benefits the library/framework might offer.
Regarding documentation covering an overarching vision for the code: It is my experience that the person best-suited to write these docs -- i.e. The person who knows the codebase the best -- is always in demand at the company. This person has very little free time and I doubt they want to spent it writing docs for everyone else.
Is that something you've noticed?
By way of example, I frequently use inline comments to discuss things like how a given class is architected, which (if any) popular design patterns are used, usage examples, etc. This stuff is really only relevant when you have the file open in your editor, so inlining the comments makes perfect sense.
I also want to add a ton of documentation around the "Why?" factor. Why did we make this decision? Why are we using this technology? etc.
The first question is always "How do I do this?". The second question is almost always "Why do I have to do it that way?". ;)
With that said, what advantages are there to removing the bottleneck of "I updated the docs, please everyone check before release and send me your comments"? To me, personally, letting anyone update the docs without review sounds like a recipe for trouble.
Two questions for you:
1) I agree that documentation has to be a visible part of the workflow, but getting buy-in from the whole team is difficult even with small decisions. What have you done to get your team onboard with writing docs?
2) Why are wikis where docs go to die?
I know your feels. I've worked at companies that do things because "that's what people use". Never fun.
What sort of documentation do you and your team maintain other than your API docs?
Also: +1 for Sphinx! <3 ReST