RFC - Cake 4.x App built-in UI Framework

[cleptric]

I wanted to discuss some details about the new app template for Cake 4. Given the massive amounts of improvements introduced in Bootstrap 4 and it's big market share, I'm suggesting to move away from Foundation.

We have some options on how to include Bootstrap:

• link tag, pointing to a CDN
• via yarn or npm
• Just copying the css file into the webroot

Some additional things:

• This template is a quick way to start prototyping. If people are unhappy with Bootstrap, they can switch to something else. Beginners tend to don't care when they start using Cake and just want something "Out of the Box"
• This extents also to SASS/LESS compilation. I think it would be good to add something people can work with.
• I want to add FriendsOfCake/bootstrap-ui as a dependency to benefit from their FormHelper
• Additionally, I think it's quite important to add support of an auto setup for the new auth plugins

I know that people in the past where not happy with the idea of having a bloated app template, but I think it's time to change that for the sake of delivering something nice for our users.

[ADmad]

Given the massive amounts of improvements introduced in Bootstrap 4 and it's big market share, I'm suggesting to move away from Foundation.

I personally don't see much improvement in BS 4 from usage point of view, it still creates tags / css class soup. :slightly_smiling_face:

But given Bootstrap popularity and I do agree that switching to BS 4 might be a good idea.

We have some options on how to include Bootstrap:

link tag, pointing to a CDN via yarn or npm Just copying the css file into the webroot

I am in favor of just linking to CDN.

I want to add FriendsOfCake/bootstrap-ui as a dependency to benefit from their FormHelper

If it is to be included by default in the skeleton then as one of it's maintainers I would prefer it to be brought under CakePHP's account and made into an "official" plugin.

Additionally, I think it's quite important to add support of an auto setup for the new auth plugins

That would be nice. Based on the limited feedback we have got some users are finding it difficult to use the new plugins.

I know that people in the past where not happy with the idea of having a bloated app template, but I think it's time to change that for the sake of delivering something nice for our users.

Since we strive to be a RAD framework providing a better out of box experience to user should be a goal. As long as the "bloat" can be easily removed it shouldn't be a problem.

[dereuromark]

We could also continue using foundation (please latest then^^), and still support bs4 via this de facto standard community plugin.

[ADmad]

Yeah if we continue with Foundation then we should upgrade to it latest version and use the full library instead of our current subset, so that users can properly take benefit of it to develop their complete app layout / design.

[dereuromark]

The advantage of Foundation would be a slimmer app as less Form/Html helper overwrites are needed, and the template files look easier for app ones and bake plugin generated ones. At least by default.

Then people can still switch to bs4 and stuff on their own.

[inoas]

What we should do is supplying an scss file and a dist (css) file build upon bootstrap4 components and using @extend instead of class soup. We can keep our very slim templates and remove class clutter.

BS4's grid, responsive utilities and alerts are a very nice base I use in conjunction with MarxCSS as a basic reset stylesheet.

[markstory]

What do we get out of sticking with foundation? When 3.0 was started we wanted to avoid coupling to bootstrap in CakePHP core and using a subset of foundation allowed us to do that without requiring breaking changes in the HTML generated by FormHelper.

Would adopting bootstrap for 4.x require changing the templates that FormHelper uses? Or would we be providing a small CSS file to make the HTML that FormHelper generates work well with bootstrap's input styles?

This extents also to SASS/LESS compilation. I think it would be good to add something people can work with

I think whether we not we have opinions on a JS build tool and which one should be a separate issue.

[cleptric]

@markstory I would simply add FriendsOfCake/bootstrap-ui as an dependency, so the core FormHelper stays untouched. @ADmad Yep, the plugin is great and I don't see any issues moving it into the cake namespace :)

[ADmad]

Would adopting bootstrap for 4.x require changing the templates that FormHelper uses?

BS requires few classes to be added by default to get proper styling, but I don't think modifying FormHelper's default template is really an option as then if someone doesn't want to use BS then they would have to customize all the templates. Even the widgets need to be modified for BS.

So if we want to use BS by default for the skeleton than using a plugin for BS support is the only reasonable option IMO. The BS4 compatible version of FriendsOfCake/bootstrap-ui while functional still has few issues and is under development.

Simply upgrading to latest version of Foundation would probably require the least effort.

[dereuromark]

The app skeleton can only contain one version of a CSS framework. If someone wanted to provide support for more (e.g. foundation5/6/...), then this would also already have to be its own plugin etc.

So given the fact that BS4+ would be way more work (especially to maintain and allow future versions), I think keeping it to a simple Foundation update here sounds really like the most pragmatic way moving forward for the default skeleton.

Also note the dependency towards bake and generating tools. They also favor a more simple one for the time being.

[cleptric]

I've never worked with Foundation so far, neitehr have I met anyone using it 🙂 Given that the current version of Foundation is 6, and we're using 5, it could come with some work.

Third option is to not use any css framework at all.

[dereuromark]

Foundation is basically rather vanilla. Not using anything is not practical.

[inoas]

@dereuromark well that is not entirely true. https://github.com/mblode/marx does not require any modifications. Beyond that we can simply use native display flex/display grid to achieve much with very little efforts/maintenance.

Personally I'd stick with Foundation 5.x as CakePHP4 suggests to be an easy upgrade from CakePHP 3.x and then with CakePHP5 either go for bootstrap or drop frontend support alltogether (which still allows things like MarxCSS).

That cake/bake has all that class clutter related to foundation is a big pain in the b*tt.

[ravage84]

link tag, pointing to a CDN

CDN doesn work offline, so it's not really "out of the box".

via yarn or npm

Please don't force another tool upon me. Especially not a non PHP one.

If it is to be included by default in the skeleton then as one of it's maintainers I would prefer it to be brought under CakePHP's account and made into an "official" plugin.

I Agree.

Since we strive to be a RAD framework providing a better out of box experience to user should be a goal. As long as the "bloat" can be easily removed it shouldn't be a problem.

I Agree.

Generally, I would prefer to have the least possible amount of JS & CSS in the app.

Instead of adding and fully integrating FriendsOfCake/bootstrap-ui into the app sleketon, we could also add a prominent step-by-step manual for that in our Cookbook. This way we do not need to adopt the plugin as core plugin but still can push its use and provide a clear path for people wanting a Bootstrap UI.

[markstory]

I feel like there is a higher level decision around CSS that needs to be made. Do we:

1. Intend for the base CSS we ship with the application skeleton to be disposable, and have its primary function to be so that getting started doesn't look awful.
2. Or do we want the default styling that ships with the application skeleton to be the 'seed' for a full admin backend.

Historically I've stuck with option 1, as I assumed that folks would have their own opinions on what they wanted and working within the tools we chose would alienate folks who didn't like the choice we made.

Going with bootstrap and additional plugins feels like it is in the vein of option 2. For the record this approach has worked very well for django's admin generator.

Before we get much farther on which libraries we should choose, I think there is a strategic decision that needs to be made around the purpose of the default styles we ship with the app skeleton.

[inoas]

In either case, both 1. and 2. scss + @extend and bootstrap 4 can do the job without adding class soup. However the trade off would be to require npm / gulp or webpack as part of cakephp/app.

So the decision could also be:

• We want to dump one or more static css libraries (for example: sanitize, marx, bootstrap, foundation) and adapt the app skeleton and cake/bake to the required class soup. This is a good approach for fully fledged admin panels; Then however I can't see why it is reasonable to use foundation in late 2018 / early 2019

VS:

• We are okay to have a build-step for front-end assets - be it integrated into deployed cakephp/app instances or running as part of cakephp/app merges/updates

I for one am always annoyed to have cake bake return a lot of html soup I have to clean up and maintain or be forced to maintain a fork of cakephp/bake that only keeps up with master bake / master cake not so well. I'd much more love to see only very very barebone html there so it is easy to build my own app the way my customers / I prefer.

[markstory]

I for one am always annoyed to have cake bake return a lot of html soup.

What would you remove from the current bake output?

In either case, both 1. and 2. scss + @extend and bootstrap 4 can do the job without adding class soup. However the trade off would be to require npm / gulp or webpack as part of cakephp/app.

Including build tooling and scss files seems excessive if the goal of the starter CSS is to be disposable.

[inoas]

What would you remove from the current bake output?

Just about any non-semantic (semantic: class="paginator", class="next") classes and non-required wrapping tags.

Including build tooling and scss files seems excessive if the goal of the starter CSS is to be disposable.

On the contrary - including say gulp/webpack and scss as an optional toolstack that can be used to rebuild the stuff that comes out of the box without adding dependencies into cakephp/app templates and cakephp/bake makes it easy to dispose:

• either by extending / replacing the scss libraries and/or our minimal customizations pre-defined in say gulpfile.js
• or by throwing away/ignoring the whole preprocessing pipe (and/or using your own)

As the html in app template and bake template results would be minimal, creating the application a specific developer wants will be faster to do.

Anyway - I burned my fingers at that once (prior to 3.x) and I am not attempting to do so again. My stance is:

• For 4.x we should keep the foundation version that is 100% BC to the one used in 3.x and not change the default app templates or bake templates. Updating the internal usage of foundation including app and bake templates to a non BC version seems to add unnecessary hassle to upgraders.
• For 5.x app templates and bake templates should become framework agnostic and keep only semantic classes, the rest can be done by either the developer, a plugin, or - if there is the will - by a pre-processing pipeline shipped in cakephp/app using bootstrap ^4.0.0 + .extends and targeting a semantic and minimal html/class structure.

[cleptric]

Thanks for the feedback. Given the outcome of the discussion, I basically wouldn't do anything here. Updating Foundation might be an option, but not a necessity.

[dereuromark]

Updating foundation to a current one and done, yeah :) That should be it probably.

[inoas]

So is the updated foundation BC?

[dereuromark]

That is not too relevant of a question IMO. The 4.x release of Cake allows us to clean things up here. And even if not fully BC, this is needed, as 5.x is becoming very very outdated and obsolete.

And this is especially not relevant in terms of boilerplate app code, since here this is for new projects and not existing ones. The syntax for bake and alike most likely won't change here.

[cleptric]

We recently merged #683 so I'll close this.