
I'm writing a book: "JavaScript Application Design: A Build First Approach" - bevacqua
http://bevacqua.io/buildfirst
======
edwinnathaniel
I've been dabbling with JS more and more lately at work or at home.

I miss the structured approach provided by
Maven+Java+JUnit+Mockito+Selenium/Sauce-lab/any-functional-test combo and am
looking for good resources to replicate this on the JS side (preferably the
front-end side as I don't care much of NodeJS at the moment).

I'd like to learn:

1\. Better build process for all of the front-end (HTML/CSS/JS) components

2\. Better UNIT-testing approach (not half-unit-testing-but-with-browser-dom-
faked-out-approach) maybe a'la MVP pattern like the one in GWT.

Basically I'm not going to entertain anything that requires a browser to be
launched (because it requires a lab/dedicated machine) because I'm looking for
Unit-Testing not "Integration/Functional-testing"

3\. Better automation (in general) of the UI/front-end component

For example:

\- replace build version => main.css?{some_build_num} (or
main_{build_num}.css)

\- LINT-ing

\- Compilation/obfuscation (could be merged with LINT-ing to some degree)

\- Auto-generate JS documentation (provided the code has proper comments) and
auto-publish JS documentation [Maven supports this for Java]

4\. MUST have xUnit output (crucial for my next point)

5\. EASY to run/configure on CI servers (Jenkins, Bamboo, etc)

\- continuation from #4, code coverage + unit-tests result should be available
on the CI build report

6\. Packaging? Dependency management?

So far front-end development has been.... less desirable because of the tools
are far less superior than doing back-end development (regardless how
beautiful/ugly JavaScript is, I'm 100% or even 1000% way more productive on
doing back-end development).

I'm very much interested in learning the best practice and to increase my
productivity developing front-end and this book seems to cover some of the
points I mentioned above but not sure how meticulous/detailed the coverage is.

There's TDD.js book but I'm not sure if it has done a good job covering pure
unit-testing and strategies to refactor/perform unit-testing correctly.

~~~
bevacqua
Hi there,

Regarding your bullet list, the book covers all of your concerns. Grunt just
depends on node/npm, and I describe how to get CI working properly with Grunt.

The first part of the book is entirely dedicated to automation and the build
process, and it definitely covers things such as asset revving, linting,
bundling, and minification.

When it comes to modularity (commonjs, amd, etc), dependency resolution
(circular or otherwise), and package management, that's detailed in Chapter 5,
at the beginning of Part II.

Unit Testing is covered in Chapter 8. I won't talk about TDD other than
briefly mentioning it, but what I _will_ be talking about is automating unit
tests, abstracting browser interaction, using PhantomJS to avoid firing up a
browser, and using karma to run tests using Chrome automatically.

The testing chapter will go over real-life case scenarios, as well. To be
honest, I'll cram as much high quality content as I can in the book/samples,
but if you're looking for testing-heavy (or TDD) content, I'd suggest you look
elsewhere

Most of the content covered in the book is further expanded in the code
samples, which are open source:
[https://github.com/bevacqua/buildfirst](https://github.com/bevacqua/buildfirst)

~~~
edwinnathaniel
Thanks for replying my concerns!

I here you and I understand the approach you take for this book and I agree
with your approach because I don't think a single book can have everything on
my bullet points.

I really really hope that there's a de-facto stack for front-end development
and let that stack stabilize for a while so that people can build on top of it
(as opposed to keep on solving individual problem with a single specific
brand-new-hip-tool-which-will-get-outdated-soon).

I hope Yeoman (Grunt and Bower) can be a part of the solution for the long-run
and hopefully your book can be a foundation where people based-off future
books (i.e.: JavaScript test automation should be based-off something).

------
joshuacc
This is a fantastic idea. I've been using a version of this process to build a
client-side app over the past few months and have found it to be a huge
improvement over my previous approaches.

Looking forward to seeing what suggestions the author has for making my
process even better. :-)

~~~
lennel
I am in the dark, the pasge describes a build tool, what's the fantastic idea
here? What is your build doing. or do you mean simply build vs using an ftp
server? sorry if this sounds weird, but the blurb explains nothing new, and
nothing which cannot be done waaaaay better.

------
tristan_juricek
edit: I could see this being just a good general approach to development. Like
a concrete how-to on doing continuous delivery from day one.

I've even started using grunt with a C++ project I'm working on, and if I make
sure that from day one I can start up from a new machine:

    
    
       % grunt init
    

... my life is better.

It's interesting, grunt is a nice "automation layer", as opposed to a build
tool. I'm now using it to automate my build setup. Having that extra thing to
bring it all together into one command makes it all so much easier.

~~~
taeric
What makes grunt better than the alternatives?

~~~
jdlshore
Grunt is not a great build tool. It's not terrible, either, but it puts too
much emphasis on a giant declarative config object.

But Grunt has a _huge_ library of plugins that cover all your build automation
needs, and that's made it the de-facto standard for build automation in the
JavaScript world.

I'm working on a universal build format that would allow you bring the
convenience of Grunt plugins to other tools as well. (I'm fond of Jake,
myself.) PM me or follow my Github [1] for more. The first version's going up
next week.

[1] [https://github.com/jamesshore/](https://github.com/jamesshore/)

------
jdlshore
Looks really good! I've been working on a universal build task format to
supplement Grunt plugins. Basically, the idea is to get the flexibility and
convenience of Grunt without the lock-in. Do you mind if I email you about it
and get your feedback?

------
mariust
The red on red links don't really work. I would change the color because they
are hard to follow along.

Other than that, nice concept for a book.

I would be interested in reading this book. Thanks

------
filipedeschamps
That's a perfect book topic, congratulations.

Do you have any interest in translating them to other languages? I would love
to republish it in brazilian portuguese.

------
danso
Interesting. I'll be one of the first to buy (does pre-order include early
editions of the book?).

I tried out continuous design when trying to learn and build with Angular and
CoffeeScript for the first time...and I loved it...made me want to quit Rails
development entirely. I still don't know much about grunt except how to copy-
paste the commands to set things up, but more insight on how this all works,
plus best practices, is a winning topic for me.

~~~
bevacqua
Pre-order includes early access to chapters as they are released. The program
kicks off with 3 chapters which you can start reading right now, and then one
additional chapter will be released each month.

If you go for the print book too, you'll get a physical hard copy as well when
the book goes to print.

Glad you're thinking of buying it! :-)

