ZURB Template Feedback

[gakimball]

We're working on some changes to the technical underpinnings of the ZURB Template (see zurb/foundation-sites-template#28), but we'd also like to collect some feedback on the featureset.

Here's what we're interested in knowing:

• Are there any common problems you run into with the existing features? (For example, BrowserSync reloading before HTML templates are done compiling, which is resolved with the PR referenced above.)
• Are there any new tasks you'd like to see in the current template? We're pretty happy with the core featureset (HTML, CSS, JS, images), but we're open to suggestions.

Current ideas:

• Notifications
• Accessibility audit
• Linting
• Deployment boilerplate (FTP, rsync, scp, etc.)

[colin-marshall]

How about implementing gulp-notify for error notifications through the operating system in addition to the console?

[Luciaisacomputer]

@colin-marshall +1 . I like this a lot because my console is usually buried under like 20 windows (I know its a terrible personal problem). It's very useful to a lot of people.

[colin-marshall]

I recently added gulp-notify to FoundationPress and I would also be down to do this for the Foundation templates, and/or Foundation itself if @gakimball and the Zurb people want this feature added.

[erutan]

+1 for notify, I notice that if I have a syntax with SCSS browsersync loads the last working css file, so it's a fairly silent fail I have to check manually.

Having template/layout changes show up in browsersync without a page reload fixed is nice. :)

update: One question on loading a js file manually - I'm using webshim - if I load it via the gulp build process I'd have to include every file the intitial polyfiller.js loads (which would bloat the js/css needed). The gulp process doesn't like copying over symlinks into dist/assets. Since the site is served from the /dist folder I can't do a ../ back to bower_components. So I suppose I either live with the extra file size or just copy /bower-components/webshim/ into /dist.

Loading polyfiller.js via gulp leads to the following on build:

[gakimball]

The updated template will fix the race conditions that currently exist with BrowserSync—it won't reload until the task is actually done. This is easier in Gulp 4 because you can be more explicit about running things in series vs. parallel.

Would that reduce the need for a notification? All of the compile steps are very fast, and if BrowserSync is working as intended then you don't necessarily need a reminder that it worked.

[erutan]

Notifications on success would be obnoxious, but I wouldn't mind them on fail. If Gulp 4 also solves Browsersync using the last good CSS file when SCSS has an error on compile I could live without them now. It could still be handy to see them pop up at a glance vs having to hunt them down though.

[erutan]

Off-topic (and out of scope for you!), but the discussion Wednesday made me want something in between panini and a traditional SSG. Laying some more sugar on top of a layout engine (archive generation, jekyll collections, tags) but not worrying about everything else and having gulp plugins handle it makes sense. The benefits of having a tightly coupled system are fairly slim (aside from a few interesting plugins like https://github.com/jaredly/hexo-admin) vs not splitting communities.

Let me know how the bower build stuff ends up working out. :)

update: https://github.com/paulwib/gulp-ssg looks interesting.

[gakimball]

@erutan I'm definitely interested in exploring options beyond Panini. We looked at gulp-ssg, but the issue is it's not quite integrated enough. It still relies on a lot of extra plugins to get all the functionality. Tools like Hexo, Metalsmith, etc. are valuable because they can more smartly manage data, page collections, and so on. That's the extra value that Panini doesn't provide right now.

Super long term we've looked at reworking our CLI to be backed by Yeoman, so each template is a Yeoman generator. If we do that, we could make configurable build processes. For example, swap out Panini for Metalsmith, add some extra CSS packages out of the box, add a deploy to live server task, etc.

[erutan]

@gakimball yeah, gulp-ssg wasn't enough to make me bite, but it's a nice proof of concept for using things like gulp-wrap, gulp-template. I'm digging the idea of just having a gulp chain for a SSG, but it's missing that "more than a layout engine, less than a full on SSG" markdown/HTML set of pipes. I haven't really dug into it, but it'd be interesting to see how much of current SSGs you could replace with gulp plugins to keep things a bit more universal. Using the same libraries / tools across different system is always a plus.

Even more off-topic, I'm always keeping an eye on a SSG for non-technical people - http://cloudcannon.com/ is intriguing for that reason, though at the point you're using a SaaS it matters a little less (since presumably they're keeping up with security/performance). Something like hexo-admin (it can even deploy from UI!) with https://github.com/yabwe/medium-editor instead of the typical dual pane markdown editing panel seems like it could work. Most brochure sites don't need to be calling a live DB, and hosting is such a pain. I could also see something like a large organization using something like Drupal 8 or Contentful as a data repository and having the context pulled into static sites for things like labs, teams, that tend to be pretty straightforward ala http://carrot.is/coding/static_cms

Does Slush allow for prompts ala Yeoman? It seems like it'd be fairly simple to do some component swaps.

[gakimball]

@erutan One fundamental issue with the stream concept in this context is that every file is processed in isolation. I'm sure there are ways around this, but by default that's how it works. So, for example, we had someone ask if Panini can generate an array of pages to use in Handlebars. And it can't, because it doesn't know how many pages it's processing.

I realized this weekend that Assemble hit 0.6, which adds Gulp compatibility and a more robust API. In the Foundation 5 days, we used Assemble to build our documentation, and used it in our client template. Once they update their website to match the new library, I could see switching back to Assemble.

[erutan]

@gakimball Having tightly coupled modules along the lines of current SSGs that deal with content + templating (md/html/jade/etc) but keeping image / style / scripts / preview etc in gulp what I was thinking of, but the pipe limit is a good point. There are ways around it (chain very specific plugins) but that gets unwieldy. Hmmm.

Switching to assemble.io if it solves your needs makes sense - less maintenance, more functionality.

I'm beginning to hit weird quirks with assets, having said that. Do I really want zxcvbn in my main app.js when one page actually needs it to create passwords (and it's perfect for being lazy loaded). I just ended up creating bowerDirectLinked under PATHS and replicated the behaviour for assets - the two I want (webshims and zxcvbn) already come with minned versions and I don't mind the extra HTTP request in their cases. This also solves my earlier issue re: webshim. :)

https://github.com/ucla/logon/blob/master/gulpfile.js

[gakimball]

@erutan suggested incorporating gulp-accessibility, or a similar plugin, to allow for built-in accessibility audits in our template. Very cool idea.

[erutan]

I can do a pull request if you want it. It's REALLY verbose and a bit slow (lets ask me if the link text in a footer on every page is semantically accurate, yay?), so I'm not including it in any common task. Right now I have it set to fire on npm start a11y. That could (should) be abstracted to npm start test or something if we wanted to include some other lint/hint stuff - though I generally find scss/js are useful on watch.

The alternatives out there are:

https://github.com/mpezzi/gulp-a11y https://github.com/dreamzmaster/gulp-pa11y

[colin-marshall]

@erutan that sounds extremely useful.

:+1:

[gakimball]

@erutan Still need to discuss it internally with the team. We probably won't release the revised template until 6.2 is out at the end of February, so we still have a decent amount of time to collect feedback and decide on what we want to add.

[erutan]

I didn't do a comprehensive audit of which tool to use, so having other people look at that before committing sounds like a solid idea.

It looks like scss-lint has a ruby dependency, so that's not ideal from a cleanliness standpoint. I have mixed feelings dealing with js hint/lint.

[colin-marshall]

sass-lint (uses node.js) will be replacing scss-lint in this repo in the near future. Sounds like an ideal candidate for the ZURB template too when it's a little more mature.

[Bnorus]

I recently changed computer, and reinstalled nodejs latest 5.5 version. Got a bunch of warning and ERROR, and bower not installed.

Most important I guess is to npm -g node-gyp marked bower and mark Python v2.7 as a pre-requisite as the version 3.x is not supported...

Additionally since I am on Windows and node-gyp has a lot for issue for Windows, pre-requisite should state: Windows VS 2015 express required, and npm config set msvs_version 2015 fixed installation issues.

[gakimball]

We have some longer-term ideas around how to extend these templates, and that involves Yeoman generators. There are good ideas here, but some of them aren't compelling enough to be a default. They could be optional, however.

After 6.2 ships, we're going to look at making a Yeoman generator out of the ZURB Template. Same structure and everything, but then we can make extras like linting, a11y audits, notifications, deploy processes, extra compilers, etc. all optional.

At that point the CLI also becomes a lightweight wrapper around Yeoman, which will make it much easier to maintain.

[hassanbinsafdar]

@gakimball I also want you fix the bug in magellan nav as well .

[rafibomb]

@hassanbinsafdar It would help to make sure there is an issue open that explains to the issue you are referring to. And we can continue the conversation there - thanks!

[hassanbinsafdar]

@rafibomb https://github.com/zurb/foundation-sites/issues/8062#issuecomment-182963541 here issue is discussed and i found out soulution too so you guys need to fix that too :) thanks

[gakimball]

Going to close this as 6.2 is shipping this week. Thanks again for all the feedback! :)

To reiterate what I said above, a lot of the features suggested here sound good as options in a Yeoman generator. That's the direction we want to take all of the framework templates—have good defaults, with optional Gulp plugins/tasks that can be added when you're first setting one up.

[erutan]

One thing that'd be handy, having an option to build and push the contents of /dist to gh-pages branch.

The one thing I really miss about using Jekyll as my prototyping tool was that I'd get a preview built automatically a few seconds after pushing up code. Right now I just built from master, switch over to gh-pages where I have a .gitignore ignoring a bunch of dirs, then copy over the contents of /dist/ into the root. It's not horrible, but not ideal.

[gakimball]

@erutan That could be interesting! What's the series of Git commands you run to do that? You could make it into a Gulp task using Node's exec() function.

[erutan]

@gakimball I, uh, use Tower (GUI client) for most of my git these days.

/hides

Good idea though, it's not complex to figure out what commands I was using.