Why is it not compatible with foundation-sites?

[soyuka]

This is a great and neat project, works with angularjs and so on, beautiful. But, I wonder why is it not compatible with foundation-sites in the first place?

I made an issue a few days ago (#733) about the action sheet disapearing for no reason. In fact I was using foundation-sites scss on top of foundation-apps. I'm asking this because components are usually the same, but foundation-sites has more features.

For example, label.middle, I've to add:

label.middle {
    @include form-label-middle;
}

But I can't @include foundation-form-label or the style of most foundation-app form components will be broken... I thought it'd be compatible.

Another example, tabs (sites vs apps). With foundation-sites I could make vertical tabs, those are not available with foundation-apps. The foundation-apps markup is different, but I'm assuming it's almost the same SASS component? So why so many differences? Why are you re-inventing the wheel (or maybe you're not and I'm lost alone in the zurbness).

Can't an app have breadcrumbs? What about tables? For now I'm including:

@import 'settings';
@import 'foundation';
@import 'components/table';
@import 'components/breadcrumbs';
@import 'forms/forms';
@import 'util/util';
@include foundation-breadcrumbs;
@include foundation-table;

The weird thing is that even _settings.scss is not compatible with the one from foundation-sites (missing global-* for example).

Apart from having the grid with flexbox (which is foundation-apps default but available in foundation-sites too), I don't understand why there are so many differences.

Please could you provide more information on this subject?

[marleneclayton]

I've run into a similar issue. I want to use components from Foundation Sites on Apps. Did you run into a lot of problems bringing components from Sites into Apps? Or was it only specific components that didn't work for you?

Hope we learn a solution to this soon!

[soyuka]

It works well, I'm building with node-sass by including both foundation-sites and foundation-apps directories to the includePaths option.

For now I'm only using table, breadcrumbs and the form-middle-label mixin. Using the foundation-forms mixin will fail, as stated above.

Maybe that those components will get into foundation-apps?

What are you trying to include on top of what's already available with foundation-apps?

[marleneclayton]

I'll have to give that a try. I wasn't sure where I could include those files where there wouldn't be a conflict or if including any foreign components would be problematic.

I would hope that Foundation Apps gets more components like Sites. Things still feel a little limited on this release, but I think it's a good start for building responsive web apps.

I'm working on a dashboard so presenting data is a big part of it. I found that some of the components are categorized a little bit on Sites and Apps, but similar function.

Foundation Sites components that’s not in Foundation Apps

• Top bar menu (I think Apps has something similar)
• Responsive Navigation
• Dropdown Menu (I think Apps uses action sheet)
• Pagination
• Breadcrumbs
• Table
• Progress Bar
• Tooltip
• Form validation (this is a big one)

[soyuka]

You can use the action sheet for the Tooltip. For the top bar I use a mix of title bar and menu ('d have to check).

For the rest :+1:

[soyuka]

@gakimball I'd be glad to make a Pull request about those missing components if you need me to.

[gakimball]

@soyuka I'd hold off on that for now, although we really appreciate the interest :)

We're in the early planning stages of Foundation for Apps 2, and we know we need to do a better job of sharing components between frameworks. So we're currently looking at which components are worth sharing, and how exactly we want to share them.

However, we want to keep the community in the loop so they can contribute, so we'll try to publish our thoughts on that soon.

[soyuka]

+1 would love to see those

I think that the list from @marleneclayton is a good start, IMHO most of foundation-sites components could be reused, except those that really belong to a "website" (orbit, slider, flex-video). Also, I really like what you've achieved with the action sheet that can easily be used for dropdowns, tooltips, typeahed (made a small proto and it did well) etc.

For the integration, I don't see why foundation-apps could not depend on the foundation-sites scss :).

[gakimball]

@soyuka I'm interested in exploring this option, although it begs the question "just how many of those jQuery plugins will we be rewriting in Angular?"

[soyuka]

Indeed @gakimball, that was also my thought while going through both docs. There is also angular-foundation, but I prefer your work, it feels more "natural". Also, angular v2 is now in beta stage.

May I ask why you build foundation-apps in the first place?

[soumak77]

@gakimball

How heavily is jQuery used in foundation for sites? Is it unthinkable to try to remove that dependency?

From an architecture standpoint, you shouldn't be writing core functionality in angular. Any components shared between F4S and F4A should be part of a shared core framework. This core framework should be javascript only with minimal dependencies. This will enable the framework to be used by ANY javascript framework and not just F4S and F4A (#587).

F4A is already in a predicament with angular in that angular 2.0 is stated to not be backwards compatible with angular 1.0. A ton of effort will need to be spent migrating the code to work with angular 2.0, so rather than making EVERYTHING angular, now would be a great time to figure out which code is not angular dependent and put that into the core JS framework. The core JS framework can then be wrapped by F4A to provide an angular solution and wrapped by F4S to provide a jQuery solution. The core JS framework can also be wrapped by others to provide similar functionality for other common web frameworks.

[gakimball]

@soumak77 I think @zurbchris (who wrote most all of the JavaScript for Sites 6) is very interested in this idea. You can probably count on two hands the number of jQuery functions that are useful when you need to support IE9: addClass, removeClass, hasClass, extend, on/off (not just for the easier syntax, but for event namespacing also).

Over time the F4S codebase will rely on jQuery less and less, mostly for speed reasons.

I think wrapping a series of plain JavaScript plugins in jQuery/Angular is sensible, but I've always wondered: are you losing a core benefit of Angular/React/etc., which is more efficient DOM manipulation? Presumably our plain JS plugin is going to be doing its own manual DOM manipulation, and the wrapper will just be calling those methods. So is it that problematic or not? Or is there a different way to address it that I'm not thinking of?

[soumak77]

You can do something similar to angular 1.0 (likely the same in 2.0, but haven't looked into it), where they use jqLite and allow for dropping in your own implementation if needed. This allows angular to work with jQuery without having to change any internal functionality as the drop in replacement (jQuery) is a superset of the required framework (jqLite). So if you want to use this new foundation core JS in angular, you could drop in angular.element and the framework should work. You can also drop in jQuery when using it for F4S and it should work as well.

I don't think there is a major issue here so long as the core JS is properly wrapped. So for instance with angular, you'll still want to use directives as much as possible as they are extremely powerful, but you'll need to ensure $scope.digest or $scope.apply is called in the correct locations after DOM manipulation is done via the core JS framework so the directive (and other scopes) reflect the changes.

[soumak77]

@gakimball @zurbchris

Here's an interesting article on Angular 2 I found that relates directly to this conversation. I would suggest reading the entire article as it mentions some good points you'll want to keep in mind when developing a plain JS UI framework. Here are some snippets:

2.3.6 jqLite

jQuery has been supported in Angular since day one. That support isn't going away, but Angular will no longer include it's own miniature version (jqLite). It's also in line with how Angular prefers declarative over imperative (as discussed in 2.1.2).

2.1.2 Controllers, providers, and directives

One of the most common use cases in web development is creating custom pieces of elements on a page, like tabs or buttons with spinners in them. Today the web lacks a good way to separate concerns and easily manipulate the DOM. While things are on their way (see section 2.2) we've had the need for some time.

jQuery is great for controlling the DOM in a direct way. We call that an imperative model. To help developers transition to Angular it has supported that way of thinking. But Angular has at the same time tried to give us a more declarative model where we're more concerned with what, rather than how. Data binding is probably the most notable of these features as we can just use our JS data in the HTML, rather than grabbing the element and pushing in the value ourselves.

[marleneclayton]

This is a great discussion! Thanks for your insight @soumak77, @gakimball, and @soyuka! I am trying to build a dashboard with Foundation 6 Apps as my base and then integrating Rails into the app. I'm trying to see if I can just "rip" out the components that I need from Foundation 6 Sites without breaking dependencies, if any.

[gakimball]

@marleneclayton You can rip the CSS out no problem, if you're fine writing your own JavaScript. There are some .ng- classes in the code, but I think over time we can try to make that stuff more library-agnostic.

[HughxDev]

@soyuka I would actually like flex-video in foundation-apps. I am surprised and annoyed that the two don't share UI components 100%. I feel the components from sites should at least be optional includes in apps.

This makes the choice between the two especially difficult for me, because I want the sites components but in Angular. There is Foundation Ultra, but I am implementing Foundation for a client and I don't want them to be stuck with an unofficial, immature, spin-off project that lacks documentation (and is possibly at risk of becoming unmaintained).

[gakimball]

@hguiney It would be relatively straightforward to import any of the Foundation 5/6 CSS components into an apps project, especially the ones that don't share a name with an Apps component, like flex video.

We're currently working on the next iteration of Foundation for Apps, and looking at how we can better share CSS between the two frameworks. Because ultimately, a lot of it is the same.

[soyuka]

@gakimball is it possible to follow discussions/ideas somewhere?

[gakimball]

@soyuka We need to solidify some of our thinking before we can announce anything, but we can say Apps 2 will be built on Angular 2.

I'd like to bring people in as soon as possible to get feedback on our ideas, but we probably won't have anything solid to show for another month.

[tunecino]

Angular 2 ?! Great News :+1: just take the time it needs. I'm sure a solid framework will came out when Angular2 & F4A are combined :+1:

[HughxDev]

@gakimball Thanks for your reply. What would be the recommended way of importing F6S components into F6A using Sass currently, and preserving my ability to upgrade? Do I just install F6S into a separate folder, and then @import certain SCSS files? I take it there would be clashes if I blindly imported everything?

[gakimball]

@hguiney Yep, you can install the foundation-sites Bower or npm package alongside foundation-apps. In your Sass file, you'll need to selectively @import things, and then also add the @includes to print the CSS of those components. Looking at the 6 component list, you could bring in:

• Top bar
• Callout
• Media object
• Table

Or if you turn off any Apps components, you could bring in the Sites equivalent.

[cfator]

What is this foundation-sites vs. foundation-apps?

This is a really odd naming scheme given the continued grey area expanding between the concept of "sites" and "apps". I'm am building an App (with Ember) yet I find myself using "sites" (with ember-cli-foundation-6-sass).

[gakimball]

@cfator We realized this, which is why Sites and Apps will be more tightly coupled in the future. The two frameworks will share most of their CSS, and the main differentiator will be how the JavaScript is implemented. Apps will still have some special components, like it's unique grid, notifications, etc. And of course Apps will be written in Angular.

[soyuka]

Is the grid not the same as the new flex grid from Sites?

+1 about the shared scss base components ofc.

[gakimball]

@soyuka You'll use the two grids in tandem. So in Apps, we have .grid-frame, .grid-block and all that, and that will still exist, but the naming scheme will be different. And we'll do a better job of explaining it so it's not crazy confusing.

That grid will be used to carve up the sections of your app, and make your fixed headers and sidebars and so on. And then inside that grid (which we're calling a frame right now), you'll use the traditional 12-column grid.

We tried overloading the two core apps grid classes, .grid-block and .grid-content, with these two kinds of functionality, but the more we built with it the more of a hassle we realized it was. So now there will be two grids.

Here's a possible example. Note that .row replaces .grid-container.

<div class="frame vertical">
  <div class="frame-block shrink"></div>
  <div class="frame-block">
    <div class="row"><!-- ... --></div>
  </div>
</div>

[tinyfly]

Excited about version 2. It be nice to have this be basically a wrapper around Foundation for Sites with angular compatible widgets.

[GCheung55]

I'm interested in using Foundation with Ember. While it's possible to use F4S, F4A definitely not. As @soumak77 mentioned earlier, it would be great if F4A was agnostic in such a way that it could be wrapped by other frameworks, such as Ember. This would enable Foundation to be even more widely used.

[edhatricksmith]

@gakimball - any update on a rough release estimate for Foundation Apps/Sites for Angular 2? We've started a project where we may need to work on some form of polyfill to get the Foundation JS dependancies working for us in the short term. However if a release is on the horizon that would save us a fair bit of work.

[gakimball]

@edhatricksmith I'm no longer with ZURB, so unfortunately I couldn't tell you :< But FYI for y'alls, ZURB is hiring a senior engineer if you want to be a part of the process!

[edhatricksmith]

@gakimball - fair enough, thanks anyway.

Anyone else have any info?

[mattgrande]

Wow, so @gakimball and @AntJanus are both no longer with Zurb? No wonder this project died, it seemed like they were the driving force behind it...

[tunecino]

also @zurbchris: https://github.com/zurb/foundation-sites/commit/fcb6c15e2194b29d08641405deaeccf4095e1bcb

[soyuka]

They should really mention on the docs that one should not use foundation-apps... Last update 9 dec 2015, issues count is growing and using a specific JS (read forcing the use of) framework on a front-end framework (read css) isn't a good idea (see good comments above).

[AntJanus]

@mattgrande I had no idea about geoff leaving. I was a contractor so it was kind of understood that I'd work on this only for a short amount of time.

[mattgrande]

@AntJanus - Ahh, didn't realise you were a contractor. That makes sense.