6 ms·

I'm writing a book: "JavaScript Application Design: A Build First Approach"

58 points by bevacqua 13y ago

danso 13y ago
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 13y ago
  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! :-)
filipedeschamps 13y ago
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.
joshuacc 13y ago
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 13y ago
  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.
mariust 13y ago
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
tristan_juricek 13y ago
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 13y ago
  What makes grunt better than the alternatives?
  - jdlshore 13y ago
    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/
  - lennel 13y ago
    I am wondering the same thing. I would imagine that if your whole stack (especially build system) is built ontop of javascript you could have a level of meta programming via esprima, but the rest is bla
deleted 13y ago
[deleted]
edwinnathaniel 13y ago
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.
- jdlshore 13y ago
  You might like my screencast, Let's Code: Test-Driven JavaScript. It covers everything you're talking about. http://www.letscodejavascript.com http://www.letscodejavascript.com
  - edwinnathaniel 13y ago
    Bookmarked and will definitely start watching today. As you can see, I'm in serious P.A.I.N on front-end (especially when I'm comparing with my process on the back-end).
jdlshore 13y ago
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?

58 points by bevacqua 13y ago

danso 13y ago

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 13y ago
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! :-)

filipedeschamps 13y ago

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.

joshuacc 13y ago

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 13y ago
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.

mariust 13y ago

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

tristan_juricek 13y ago

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 13y ago
What makes grunt better than the alternatives?
- jdlshore 13y ago
  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/
- lennel 13y ago
  I am wondering the same thing. I would imagine that if your whole stack (especially build system) is built ontop of javascript you could have a level of meta programming via esprima, but the rest is bla

deleted 13y ago

[deleted]

edwinnathaniel 13y ago

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.

jdlshore 13y ago
You might like my screencast, Let's Code: Test-Driven JavaScript. It covers everything you're talking about. http://www.letscodejavascript.com http://www.letscodejavascript.com
- edwinnathaniel 13y ago
  Bookmarked and will definitely start watching today. As you can see, I'm in serious P.A.I.N on front-end (especially when I'm comparing with my process on the back-end).

jdlshore 13y ago

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?