The past few months I've had the luxury of working only on Foundation at ZURB, which gives me quite a bit of time to keep up with the frameworks and supporting libraries, and get paid for it.

I do open source work in my spare time, most of which belongs to ZURB, but I also have some projects of my own as well.

But don't worry, I tend to sleep until noon on the weekends ;)

The parser can be used standalone (see documentation here), so that's definitely possible. If your backend is Node powered, in theory you could run the Inky parser before you send an email. The tool is fairly new, though, so we don't have any examples of it in the wild.

We are looking at server-side integration, however. We're also developing a Ruby version of Inky internally, which we're going to then get working with the Rails asset pipeline.

How do you think we could improve the tooling for recurring templates?

For example, we're interested in exploring server-side integrations. One of our developers is working on a Ruby port of Inky which could be imported into the Rails asset pipeline. You could probably hook the Node version of Inky into, say, an Express backend as well.

There are fewer built-in effects (for now), but each effect has many customization options. So for a slide you can set both the origin and length of the slide, for a hinge you can set the origin, rotation point, rotation direction, perspective, etc.

We want to keep building on this and adding more elaborate effects over time. The key is that any effect we add should be customizable. The five core effects built-in right now are meant to be a little more... tame ;) We're right there with folks who are afraid of abuse of animation in UI.

UnCSS allows you to whitelist classes, and we prefix all JS-dependent state classes with is- (e.g., .is-active, .is-open, and so on). This prevents JS classes from being removed during the processing.

More what I'm talking about is a library that lets you modify a Gulpfile without using a templating language. (Here's the library Yeoman uses for Grunt.) Slush is interesting, but when it was released I couldn't really figure out what it does different from Yeoman, other than be built with Gulp. (And Yeoman doesn't actually use Grunt for anything from what I can tell, it's just that most generators happen to use Grunt.)

It is funny though, having conversations about abstracting something that's already meant to be an abstraction. Because y'know, web development. ;)

I was thinking about writing something like this, glad somebody did it for me ;)

Have you looked into taking this underlying process and creating an API out of it? Recently I was learning how Yeoman generators work, and they created a tool that streamlines the modifying of Gruntfiles. A similar tool to programmatically generate and modify Gulp tasks could have some interesting uses.

WordPress out of the box isn't really built for single-page apps, or perhaps even apps in general. (To be sure though, I don't follow that community closely so I don't know what's up with it.) The distinction between sites and apps is often a fuzzy one, and it's arguably meaningless to users, but one good distinction is that a web app is closer to software. A portfolio, blog, or news outlet would be a website, while tools for chat, image editing, etc. are apps, and if they're on the web they're web apps. But there's a lot of overlap.

I helped build Foundation for Apps and I wouldn't recommend using it for a traditional WordPress site, although I expect the community will build themes for it eventually. However, FoundationPress is a great WordPress theme build on Foundation 5, which will continue to exist, and continue to be great for more traditional websites.

We use Ruby Sass to compile the .scss files, and Bundler to properly manage Ruby dependencies. Run gem install bundler to install Bundler.

Might have to do with your OS being set to always display scroll bars, but we'll look into it!