bootstrap vs material

[jscharett]

Has any thought been given to using bootstrap as the base vs material? Essentially, instead of using material2, use ngx-bootstrap? While I think the material stuff is probably nicer, it seems like cbp-theme is a bootstrap theme with changes for material. By using Material as the base, it's hard to reuse much of the cbp-theme at all. You have to redo it to make it work for material. I wonder if we used bootsrap as the base, if we'd be able to use more of the base cbp-theme.

Once cbp-theme moved to a material theme, we could then make the same change, and hopefully again be able to reuse most of the cbp-theme. Thoughts?

[yogeshgadge]

My thoughts....

The impact on each of the consumers apps of ngx-cbp-theme would be much larger if ngx-cbp-theme were to take a massive swing from bootstrap to material at some point later. This is how both the scenarios will span out.

bootstrap as baseline

In this scenario each consumer of ngx-cbp-theme application would have written their application extending ngx-cbp-theme and say ngx-bootstrap.
This means all the following code artifacts were written as follows:-

• HTML markup, templates etc. are written with HTML tags
  e.g.
  <button type="button" class="btn btn-primary"Primary</button>
  To convert the above to material you have to do this:-
  <button md-raised-button color="primary">Primary</button>

Important point to be noted here is that each of the consumer apps/teams will have to take this effort and change their end application as we move from bootstrap to material.

• Application specific Components

Each application specific component would be written utilizing low level building blocks of ngx-bootstrap.

All these would have to re-written due to the move. Each application/team must have to take this effort causing too much repeated work by many.

• SCSS files

All the namespaces, variables imported and utilized would be from bootstrap.
Migrating to material would mean change everything to mat- namespace with some combination of HTML tags and there may not be exact counterparts making this a much harder effort.

As cbp-theme moves to material ngx-cbp-theme will take a hit much later when the consumers have already used the older version of ngx-cbp-theme which spirals another wave of changes downstream.

material as baseline

On the other hand in this scenario (where the current ngx-cbp-theme is headed) all the end consumer applications wold have already coded their markup, styles, application components using ngx-cbp-theme and material so no need to change anything other than

• Update to newer ngx-cbp-theme so that the bootstrap hacks/look and feel removed from this version can be obtained.
  e..g. Say one team has used cbp-accordion-lite in their app which looked like bootstrap earlier. Now this looks more like material inspired as cbp-theme migrates. ngx-cbp-theme will shrink and get rid of bootstrap workarounds. Or ngx-cbp-theme may just deprecate cbp-accordion-lite for md-accordion. Now all this team has to do is update their ngx-cbp-theme dependencies AND/OR replace cbp-accordion-lite with md-accordion.

This is far less impact for the consumer application.

Impact on ngx-cbp-theme project itself

• ngx-cbp-theme would shrink as cbp-theme migrates to material as these workarounds cease to exist.
• Useful components e.g. cbp-header written in material stays as it is. No work is wasted here.

Based on my discussion with cbp-theme members it is going to evolve more towards material but it might not happen in the immediate

There is another angle to this - we need to think about the following as well:-

• Which cbp-theme components are going to be heavily used in the end consumer application ?
• Are these more bootstrappy or more 'materialistic` :) ?

This is important to quantify/understand which direction is tactically better in reducing efforts.

I am expecting most of our consumer applications to be more Forms oriented. And most Forms are material inspired. angular/material2 forms match exactly what we have in cbp-theme today. Also a developer of consumer of ngx-cbp-theme may choose certain components wisely e.g. favor material inspired select than using select2 flavored select.

In the long run it is harder to transition bootstrap->material than biting the bullet now.
My thinking is that these workarounds are allowed to be be hacky to a certain degree as long as they don't sacrifice the runtime and force the end consumer applications to a path that requires much work later on.

[jscharett]

I agree with much of what you say. The key though, is if/when cbp-theme will move from a bootstrap based theme to an material theme. With everyone implementing bootstrap, it may be hard for cbp-theme to move away from bootstrap due to the cost of everyone having to update their apps as you've pointed out. One thing that could happen is that cbp-theme completely materializes their bootstrap theme vs moving to material itself so as to reduce the cost of everyone having to update. If that were to happen, we'd not be able to benefit much at all. We'd be in the same boat now, if not worse, where we basically have our own material theme for angular which we continually need to update to keep pace with cbp-theme.

I much prefer material2 to ngx-bootstrap; I think the components are much nicer and it has a great community around it with angular devs. However, it seems risky with a lot of duplicate effort of us trying to match the current theme in hopes that they'll move to material. If they were currently working on a material branch, it wouldn't be an issue.

That's my 2 cents. We can continue to follow this path, but wanted to voice my concerns.

[yogeshgadge]

Got busy/caught in some issues to respond to another excellent concern raised above which I will attempt to address further below. I must say that we need to document these in a better way - update the readme.md to link to another document that addresses these concerns. Also some of the reasoning behind got buried in our internal discussions and another document before starting this repository :) hence the assumptions did not make it into the ant of the readme.md or the contributing.md I will start a new document as time permits.

cbp-theme materializes their bootstrap theme vs moving to material

Here I am assuming that cbp-theme is either replacing bootstrap with Materialize OR it replaces it with Material Design Lite which it is already using.

My thoughts are as below:-

All these libraries

Materialize
Material Design Lite
Material-UI (react)
Material2 (angular)

are only a means to achieve the ultimate specifications from Google Material

These libraries are merely there so that that individual applications can attain the Material specs.

For example the React developers created Material-UI (react) so that Reach applications can achieve Material specs.

Similarly Angular team created Material2 (angular) so that Angular apps can do the same. Just as AngularJS created [Material angularJS](https://material.angularjs.org} for the Angular < 2 users.

This perspective to bring forth 2 key points that:-

• All these libraries are striving to the same exact specifications : The Google Material which are only specifications i.e. width, height, colors, contrasts, how all that should respond on different devices etc. These specifications must be implemented by someone to bring to life.

So one might assume that only one implementing library written in pure Javascript and CSS would suffice ? But yet we have so many libraries. This brings to the next point.

• Native components

Yet so many component libraries exist to solve this problem because they all offer components that are native to their framework.

Quoting straight from Material Design Lite

Material Design Lite lets you add a Material Design look and feel to your websites. It doesn’t rely on any JavaScript frameworks and aims to optimize for cross-device use, gracefully degrade in older browsers, and offer an experience that is immediately accessible. Get started now.

and yet we have Material-UI (react)
Material2 (angular). This is because a certain class of applications can't scale without the components being native.

It is fair to say that native components will deliver better performance.
Easier to understand at runtime and hence easier to debug.
CSS/SCSS development becomes far less hacky than "override this/that from this/that".
Browser don't need to perform too many computations.

Throwing competing libraries in these applications is opening to a very complex runtime where the components runs, behave and render in a way which become very difficult to fathom. Hence the proliferation of so many libraries to achieve the same end goal : Material Specs.

If that were to happen, we'd not be able to benefit much at all. We'd be in the same boat now, if not worse, where we basically have our own material theme for angular which we continually need to update to keep pace with cbp-theme.

This is true only if cbp-theme diverges from Material Specs.

Bottom like is whenever cbp-theme will have any customization ngx-cbp-theme or another React version of it will get impacted this is because cbp-theme just like other UI libraries cannot cater to all the frameworks all at once. Hence the birth of ngx-cbp-theme.

I could be wrong in some assumptions or missing any supporting or opposing points. If the reasoning is satisfactory or if need to change something ideas are welcome. I will wait for a response/pm before I close since we are all so busy with so many things.

[yogeshgadge]

doc updated f197d97