A build script is necessary

[paulirish]

• js/css concat and minification
• html minification
• filename revving for far-future expries.
• image optimization (jpegtran, pngcrush, etc)

others: http://daverupert.com/2010/06/web-performant-wordpress/

I'm unsure on how this could be added to the project in a general way.. something php/ruby/py/html folks could all use it.

[roblarsen]

To me, the optimization steps are, by nature, final so they're going to be used in a lot of different ways. I just don't think we can predict the way in which this is going to be used so optimizing the process against any one use case just makes it more awkward for some other use case. I can guarantee you I will NOT be carrying the actual boilerplate directory over to projects at work. I will be packaging up files in the publish directory and passing them along to back-end developers for integration in a CMS or application. This will happen almost every time I use the project. We'll leverage the ant tasks for the project builds (when we're using Ant, of course,) but the actual export of boiler plate will be long gone.

I'm fine with doing whatever people think makes sense, as I said, I'm going to customize this every time I use it anyway, so the folder structure doesn't matter. I just think sticking to easy-to-grok folder structure makes sense. By name, /build indicates "oh, this is where the build files live" without having to resort to reading documentation. Of course, moving the build.xml up a directory to the project root would make it more standard, but /build is pretty straightforward.

[mikkotikkanen]

The projects I'm working on, won't be using the build script either, as there is already one that is doing stuff and running on CI. To projects like this, the structure won't really matter as, just like you said, it's exported once and that's it.

However, I'm just trying to think this also from the point of view of lone developer, who want's to build his site off from boilerplate. A) they most likely would want to leverage the build scripts, instead of say, using optimization services and B) to web-developers, who haven't been doing application development with compiled languages, the conventions of build/ etc. folders aren't that clear, since there is no build/publish process in traditional web-development. Thus, it would probably make most sense to them, if the whole boilerplate would just live at it's own folder as a whole. The problem with this approach however is, where do you put the publish/ folder?

The folder names themselves will be configurable, so the issue could be remedied by the user themselves. However, I'm trying to think of an case which would require the least of configuration by the user, making the boilerplate true bolt-in enhancement.

[roblarsen]

There's just no way to make this work, without customization, for everyone. For the lone developer? Hopefully the documentation will be clear enough that they're be able to figure it out without too much trouble. You STILL need to go through the build step and that can only happen on a copy of the site files, so they're going to have to work in the idea of a separate directory for their files.

I'm just wary of overcomplicating it in order to have it be all things to all people right out of the box. People are going to have to customize this. All we can hope to do is make that customization as easy and as clear as possible.

[mikkotikkanen]

Not really seeing your point of having two separate directories.

Here's what I've been thinking for the Javascript build

Scripts folder (js/) would then have structure like this: js/libs (Contains all library files) js/helpers (Contains libraries for specific cases, like IE png fix) js/scripts (User written scripts)

The script would concat libs as one file, scripts as one file and then, if set, would concat these two together, so that the file containing the libraries would always be on top. Then the resulting file would be minified. Files in helpers/ folder would never be concated together, or to the main scripts, as these are meant for specific cases only. Wouldn't make to include these to main scripts. Then the js folder would be cleaned.

The reason there is /scripts subfolder inside the js/ folder is that this structure allows people to add other libraries, profiling tools etc. to js/ folder, while still having the ability to have any sort of structure (of subfolders) inside the js/scripts folder.

Now we would just need some regexp wizardy to replace all "/js/scripts/subfolder" etc. calls with "/js/scripts-008-min.js". Same with libraries.

[roblarsen]

I'm confused, are you suggesting we work directly on source files/directories and not have a separate ./publish directory? Working with a separate directory makes builds safe and cheap. Something went wrong? Fix your script and run it again. Since it cleans the directory you can make disasters go away with one line.

[mikkotikkanen]

Of course not. But can't really see why the user would be forced to work with two separate directories.

[paulirish]

"two separate directories" I guess you're talking about build and publish?

Ah I think you may be proposing ./build/publish as the destination for all files? That's not bad. I don't see too much wrong with that structure, assuming it is documented. :)

btw guys I'll be in here for a while today: http://www.chatterous.com/html5boilerplate/

[mikkotikkanen]

I was actually commenting on Rob's post :) ("You STILL need to go through the build step and that can only happen on a copy of the site files, so they're going to have to work in the idea of a separate directory for their files.") Not sure what he meant by that. I guess it's a common symptom today. :P

[roblarsen]

Ah, I see. I was only ever referring to the ./publish directory. Not that the developer would somehow need to keep two sets of source files.

[roblarsen]

hey, back from a free-time coding blackout. Any interest in adding this task in?

http://htmlcssjavascript.com/javascript/an-ant-task-to-comment-out-console-log-calls-from-javascript-files/

[mikkotikkanen]

Hey. That actually is already implemented in the current version of the build.xml. ;) Now that I finally finished things to do today, I could see if I can manage to commit (never worked with git or github before :/) the changes I did to github.

[roblarsen]

hah, shows you how much I've been paying attention. I was reminded of the task today because of this discussion making the rounds (http://www.w3.org/Bugs/Public/show_bug.cgi?id=10694) and then thought about boiler plate and how I've been out of the loop for a little bit (damn work-work getting in the way.)

[mikkotikkanen]

Hehe. You're still in the loop since the build file has been sitting on my computer for ages, it's not on the internets yet. :/ Same here with work-work (building two businesses at the same time can be exhaustive, I've learned), been pretty much swamped with that stuff (12-16 hours per day) +had to finish a project ASAP (developers4cause.com) thus haven't had any extra energy to think about boilerplate. :(

But now, first something to eat and then I'll try to push some stuff to the general direction of the github. :)

[mikkotikkanen]

I'ts utterly infuriating how the good idea behind git has been completely destroyed by the useless complexity of the whole process. After an hour of screen after screen of completely unintuitive interfaces and random error messages ("rejected".. aight), finally got something pushed to my fork: the build.xml. However, no matter what I do, the new structure of js/ folder wont go anywhere. Nor can I get it rolled back to the form it is in github. Splendid. Makes me feel like smashing things into things.

So, the structure inside the js folder should be as follows: js/main - Should contain script.js and plugins.js js/helpers - Should contain the dd_belatedpng.js js/libs - Should contain the jQuery

Files inside main and libs will bet concatenated together, minified and moved to js/ folder If set, libs and main will be concatenated together as one file Helpers will only be minified, and kept in the helpers folder

[mikkotikkanen]

Oh. And forgot the the default.properties. Can't seem to be able to push that neither but made the commit by hand to my fork.

http://github.com/mikkotikkanen/html5-boilerplate/blob/build/build/default.properties

[paulirish]

mikko, i'm digging into your changes now and hope to land them in my build branch

[paulirish]

Okay cool. I made the new folders.. and tweaked a few bugs in the process. http://github.com/paulirish/html5-boilerplate/commits/build

A few questions for Mikko:

<replaceregexp match="(console.log\(.*\))" replace="/\*\1\*/"

Should this console log regex be ungreedy? I think code like: console.log('omgomg'); actualThings(); console.log('sldfj'); will break it.

Right now the default build will remove the unminified (but concatenated) scripts by default. Earlier we had it so they were still available (someone can remove the .min from the filename and see the thing). I'd like to have it like that by default. Does that mean js.delete shouldn't be run by default?

Also.. jQuery is included in scripts.min but we're also requesting it from the CDN. Probably better to keep it out of the minified scripts-xxxx.min.js. yah?

[paulirish]

Also this is super cool. :) I like the flexibility of the default props.

Still have some questions about how people add new CSS and HTML files and such.. Not really sure how we include them into this setup.

[mikkotikkanen]

Yeah, it probably should be. That was just the way I got it working, and since I'm not a regexp lover, I left it at that so that someone who is actually adept with that stuff can change it to something better. :)

That is basically the way our project does things (or used to do, currently doing a rewrite) so that's why it acts the way it acts. So it's not something that should be necessarily taken as is, but set to the way you want it to work. So yeah, if you want to, the script can still hold on to non-minified files. The reason I use it that way is that the stuff in publish folder is considered "final" and ready for deployment, thus there really shouldn't be any unnecessary files there, as the development itself happens in the main folder.

What do you want to do with HTML and CSS?

[maniqui]

Regarding the filename revving, what do you think about implementing this trick? http://www.askapache.com/htaccess/mod_rewrite-fix-for-caching-updated-files.html

It makes deployment easier, as files doesn't have to be renamed. Only the references on the HTML. Apache takes care of the rest.

[roblarsen]

That's very cool. I'm not sure it's that much of a saver here as we still need to minify and rename the files to indicate min.status. Still, a nice option to have and it would be seamless (at least for people using Apache- IIS, Nginx, lighttpd, etc. users would still be better served by the build process as it stands. )

So, yeah, what is the goal with the HTML and CSS? We can just sweep the directory for both (unless there's a desire/need to concatenate CSS as well, in which case we need to be a bit more discerning and do a bit more work) and process accordingly.

[paulirish]

CSS

we can only concatenate css if the media type is the same. (can't smush print styles along with screen/all styles). I think this means we gotta parse the markup? :/ is there a way we can avoid that? just have more configuration?

here are three recent sites done with BP to get a feel for how this'll pan out. http://www.waiterontheway.biz/ http://lostworldsfairs.com/ http://coleman.depaul.edu/

HTML

Doesn't seem as bad. We now have a config where a user can specify which files should be affected. (Though could someone help me with what that would look like?) http://github.com/paulirish/html5-boilerplate/blob/build/build/default.properties#L35-38

I imagine the two primary use cases here are people running the build tool on a bunch of HTML files that share the same header/footer/blah.. and then people who have a structured template setup. The build script should handle both those well.

[paulirish]

YEEEEE HAW!!!

I just merged build into master. All our build work will be in the upcoming release of HTML5 Boilerplate with a Beta sign on it. :)

I changed around some of mikko's work where the javascript got split into four different folders. (I moved script.js and plugins.js back in to just /js/) But this made some good headaches for me.. I'm still working on them now.. if anyone wants to help me take a look, that'd be great. I'll be in http://www.chatterous.com/html5boilerplate/

The remaining issue we had from before regarding making the buildscript flexible with additional html/css files has been broken into issue #143.

I'm closing this ticket now. :)

Thanks everyone for your help thus far on probably the coolest part of html5 boilerplate!

[paulirish]

If anyone didn't see.. we released v0.9.5 with the build script.. Now to get some feedback on it.. make it more stable.. and maybe some new features..

speaking of features: http://github.com/paulirish/html5-boilerplate/issues/issue/165

i've roughed out some ideas there. please feel free to add your own. and also give the build script a whirl!