kraftvaerk / generator-rammevaerk

Scaffold a web project in kraftvaerk style
MIT License
5 stars 4 forks source link

Any reason for not have installing step for 3-part javascript plugins #9

Closed rammi987 closed 6 years ago

rammi987 commented 6 years ago

In version 1, we have some installations step for 3-part Javascript plugins. Witch could delete Lightbox or include a slider plugin - is there any reason for why that step is taking out?

In the project i am on, do we not need Lightbox, so when installation is done, i need to remember to manual delete those files and dependency. And for slider - witch nearly all customers run; i need to install it manual.

I think maybe, get this install step back, for Lightbox and slider, and for the slider get a agreement for witch one we all maybe use so we does have 100 project with all an unik slider?

kristoforsalmin commented 6 years ago

@rammi987 @mi2oon I'd actually like the idea of moving all our components and helpers to their own repos, so you can pick and choose (using npm, webpack, Sass) exactly what you need for a given project. It's also easier to test and maintain.

Same as well might be applied to Bootstrap and jQuery. I highly doubt that every project needs them, so maybe they could go optional.

What's your opinion on that?

This also might be related to #8.

rammi987 commented 6 years ago

@racse1 Boostrap is our new base, in previous verison of rammevaerk, @mi2oon have build a grid and form grid and some utils as bootstrap, but instead trying til build our owns, and maintain it is a lot of work and time we not have, so using bootstrap for our base guidelines is a better solutions.

For jquery all project i have been on jquery is used, in some sort, so having them as our base.

But for other pluigns as Ligebox, slider, datepicker, validation and more, could be options, so we always get the same base and helper scripts for those 3-part plugins.

for bootstrap we could meaby make options for witch javascript plugins we want, not all use bootstrap slider so we include that.

kristoforsalmin commented 6 years ago

@rammi987 Thanks for the explanation 👍 What do you mean by base, though?

I currently see that we import all kinds of Bootstrap stuff. Bootstrap is awesome tool for prototyping, no question about that, but when you have a design why would you want to use it? From my experience, it usually comes down to overriding a handful of rules...

The other thing is that we use BEM (yes?) and Bootstrap doesn't, so you'll end up having mixed naming conventions (e.g. btn btn-primary btn--something, wait a minute, is btn-primary a component or modifier).

I'm just trying to understand what you use Bootstrap for. If we need simple things like grid, then maybe we could just use our own classes and some mixins from Bootstrap. This way we'll keep it aligned with BEM methodology and won't have to maintain the whole thing on our own.

mi2oon commented 6 years ago

@racse1 @rammi987

I feel like I also owe an explanation. We do import bootstrap and sub-sequentially jquery as I've realized that most of our projects lately have been fast pace and needed a certain familiarity which is provided by bootstrap. I would in general sense agree with you. But bootstrap does provide predictability when it comes to form elements and grids(main for Backenders). In most cases that probably the only thing we'll ever need. 🔦

However, that brings us to a good point, what about BEM? As you correctly pointed out we can't use BEM as bootstrap doesn't.. unless we wish to have a odd mixture. So, lately we've sacrificed BEM over the overall maintainability as it was geting hard to keep custom mixins and dependencies in check. However, with that added I do miss the explicitness of BEM. But perhaps bootstrap will align with BEM in the future. 🙏

As for us, if we had more frontend resources I would go for the BEM no questions asked. But lately we jump a lot between things and it's just hard to keep everyone aligned and bootstrap helps with that also when we have customers IT department working alongside us. We can always minimize the footprint of bootstrap and better our file and folder structure and still achieve great maintainability.

As for the 3part dependency question being removed. It's mainly to simplify the install process. I am hoping to put it on a little more diet so be can remove fancybox completely. But lets see. The point of rammevaerk is to quickly get started with a web project in KV and still follow a certain standard.