Foundation 6: JavaScript feedback

[gakimball]

The current JavaScript for Foundation 5 is about 18 months old, and for version 6 we're looking to rewrite it all from scratch. This will allow us to follow more recent best practices and generally modernize the codebase.

Here are some requests we've gotten related to JavaScript:

• More modularity. Some folks have asked that we make it easier to use the individual plugins standalone, or wrap the components in a module system like RequireJS or CommonJS.
• Automatic plugin initialization. There's a problem right now with components added to the DOM dynamically, and components inside of components, not getting initialized properly. At the moment you have to manually run Foundation's reflow function ($(document).foundation('reflow')) to catch new plugins and initialize them. We'd like to find a way to streamline this process.
• Create a plugin directory, to increase discoverability of Foundation-specific plugins. Most likely we'd piggyback on Bower, not actually create our own registry.

  Common API

One plan we already have for version 6 is to create a common API for certain components to tap into. While building Foundation for Apps, we realized most UI components are just different ways of opening and closing things, so we built a single API that can transmit open, close, and toggle commands to modals, panels, off-canvas, etc. We're going to take this same approach in Foundation for Sites, so:

<a data-reveal-open="modal">Open Modal</a>

Becomes:

<a data-open="modal">Open Modal</a>

We're also interested in potentially porting the Motion UI library from Foundation for Apps, so that both frameworks have access to the same set of animations.

To jQuery or not?

We've had some internal discussion on if it's worth writing the new plugins in pure JavaScript instead of using jQuery. The main reason is the file size, but jQuery 2 is just 32kB gzipped these days. And to be sure, there will be plenty of cases where we have to work around cross-browser inconsistencies, at which point we could have just used a framework that handles those edge cases for us. You may recall we used Zepto for Foundation 4, but we had to drop it because it wasn't as performant as jQuery, by a

Plugin Structure

Reworking the plugins also gives us the chance to change the way they're accessed in JavaScript. Right now we put every plugin inside a foundation() function on the jQuery object, but there's a few other routes we could take as well.

// Give every plugin its own function, although this could be a namespacing issue
$(document).reveal();
$(document).orbit();

// Use a separate object instead
var modal = new Foundation.Modal();
modal.open();

What we'd like to hear is how we could better structure our JavaScript. If you have feedback on the features of the plugins, we have other discussion topics for that as well.

View our other discussion topics for Foundation 6 here.

[michaelBenin]

@gakimball is it agreed you will publish in UMD?

Babel is mature enough, foundation should use it.

Remove the dependency for jQuery if you are that concerned about size.

My suggestion is author in babel and build with browserify with a babelify and envify transform. Create modules that have a dev and production build.

Write tests using gulp mocha/karma in babel.

FYI many people I talk to refuse to use Foundation's JS.

[gakimball]

@michaelBenin We're definitely supporting multiple module loader standards, with a fallback to assign libraries to a global object like we do now.

What features of ES2015 do you think would benefit us? Looking past the convenience things (classes, fat arrows, default params), a lot of the really interesting features require polyfills. So for a suite of UI plugins, what could we get out of using Babel?

Lastly, why do developers you talk to refuse to use our JavaScript? Are there any common reasons?

[michaelBenin]

@gakimball if you look at any other popular js lib they are authoring with babel.

Developers refuse to use your JS because their calling $el.foundation(); or this.$().foundation(); any time the dom is modified. That's the general feedback.

[joelkinzel]

@michaelBenin - I'm not sure that the goal of those js libs is the same as Foundation though. Most are app-centric. Foundation for Sites is mainly concerned with websites, not applications. I don't believe other UI frameworks (such as Bootstrap) use Babel/ES6 (perhaps I'm wrong, but I didn't see anything). While initially I wanted the same thing, I think given the goals of Foundation, it wouldn't be a good move (at least not at this point in time).

One of the big things Zurb has to balance is the ease of adoption by a wider audience. Developers wouldn't have any issue with a build-process. We're used to it. But I have a feeling it would scare a lot of other people who use Foundation.

Once ES6 becomes more widely used, then I think it would be worth transition to it (F4Sv7 maybe?), but at this point, the build process that is required may actually inhibit people from using Foundation.

[michaelBenin]

I disagree. Authoring in babel will bring respect and much better talent contributing to Foundation. Each library could be built to a UMD module and would support commonjs, requirejs, and optionally have a global namespace.

Foundation is already scaring off developers by not publishing to npm, not supporting UMD, and using a 'fire and forget' mentality. This is the perfect time to modernize the js portion of the project.

Top frontend browser js libs are leveraging babel. We can continue comparing foundation's js to bootstrap and achieve mediocracy or we can write foundation in a way to future proof it.

[michaelBenin]

Also this thread was started almost 6 months ago. When is a decision going to be made?

[joelkinzel]

It was started 6 months ago to solicit feedback from the community. Looking through the other F6 issue threads, they don't seem to be handing out decisions.

Also, I'm not really sure I agree with writing things in ES6 bringing better talent. There is a ton of talent in this community. I think it would be hard to make the argument Bootstrap's community is also not talented. I also think it is perfect fair to compare to your competition.

I just don't see how using transpiled code, or adding a build step benefits the vast majority of the community. I'm with you, I'd love to see ES6, but Zurb has to think about the wider community.

[pdlug]

I'm a fan of ES6 but I don't see the benefit in this case. It's far more important to just have Foundation JS support a module system and npm packaging without introducing a rewrite and a transpiler. It's just too hacky to use Foundation w/ browserify/webpack now.

I would also really like to see jQuery dropped, it's just something a lot of us are trying to get away from pulling in as a dependency. If helps to transition maybe there's a place for "foundation-light" which could include pure JS components and leave out anything that is heavily jQuery dependent for now.

[michaelBenin]

It would be nice to see the JS written in a way like this:

http://ponyfoo.com/articles/why-i-write-plain-javascript-modules

[chrisjlee]

I think it's about time to start writing ES6. Sorry to be, "that guy"; seems like bootstrap is now ahead of Foundation with it's alpha release: http://blog.getbootstrap.com/2015/08/19/bootstrap-4-alpha/

[zurbrandon]

Thanks for the feedback, all! We've looked it over and are really rocking away at getting Foundation 6 out very soon!

[michaelBenin]

@zurbrandon is there a document with the spec on how js is going to be written in foundation 6?