zurb foundation 6.x support about awestruct HOT 9 OPEN

Zurb moved away from gems and has moved instead to the node frontend tools,
as have most frontend kits. You should be able to use it just fine, but I
can't interface with it as easily from the Ruby side. I can certainly look
into it a bit more though.

On Wednesday, July 20, 2016, Aleksandar Kostadinov [email protected]
wrote:

Now there is foundation 6. Are there any plans to support newer foundation
than 4.x? I see #418 #418
not fixed for 2 years. Should foundation support be considered deprecated?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#525, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB1E_BJgLTs0rqT8RMaR1pHq4AMz6Szks5qXfI2gaJpZM4JQnkZ
.

Sent from Gmail Mobile

from awestruct.

I'd love to hear suggestions on how to best interoperate with the node community using awestruct.

from awestruct.

I think that bower package manager would be a reasonable option. Appears to have some traction.

from awestruct.

from awestruct.

Ok, I don't have a hard opinion. Just saw a lot of bower usage when searching the web. But now searching, it appears npm is recommended over bower. I also see a ruby gem that appears to wrap npm.

from awestruct.

from awestruct.

Speaking with other people and reading more on the internet, it appears quiet a few people believe bower is much more suitable for frontend. Just FYI.

btw in #530 I wrote how bootstrap 4 can be supported in awestruct using the official gem which is nice.

from awestruct.

from awestruct.

According to download stats, it doesn't look like usage of bower has declined. Some people do not see npm as superior. In any case I don't care much which one would be used. I guess npm is a safer choice going forward.

I think that awestruct needs not much to be back to awesome. That is support for npm/bower and then support a couple of neat features:

• download dependencies into a _deps subdir which would not be included by default in the generated site (would be faster if we don't have to generate all useless and duplicated css/sass/less/etc.)
• allow automatic @require and //= require of scss and javascript
• somehow copying other assets like fonts and whatever else could be present in the deps (I have no idea how this should be done yet)

Unfortunately I don't have much experience with frontend tech and I'm only starting to understand some of the use cases, as well I don't yet understand how tilt and sprockets work (I think they might be instrumental for adding the features above).

• I have added for my project some hackish js //= require support (#534 (comment)).
• Also in #536 I'm adding Autoprefixer support (btw it is rather CPU intensive that's why I think we should limit dependencies to only what user requested, otherwise a lot of useless files are being processed).
• as I wrote above, I've no idea what would be a good way to select other asset types

If the project decides on a high level approach to implement such features, then that would hopefully allow me to contribute some of the bits. At the moment. e.g. it seems npm is the preferred deps manager. I'm thinking that the npm-rails gem might probably contain the necessary code to call npm. But then how to handle these downloaded dependencies is to a great extend unclear to me. I'm thinking that simply handling them all as source files would be useless as users can already call npm on the command line to achieve this.

from awestruct.