Move to Bootstrap

[pusewicz]

I'm sure you are all aware of the presence of https://github.com/200Creative/spree_bootstrap_frontend.

How do you guys feel about moving to Bootstrap? It's a far better starting point for any Solidus based project.

[tvdeyen]

Moving to bootstrap in Spree 3 was one of the reasons for the Solidus fork, though...

Personally I think a framework like Solidus should not make any assumptions to the front end framework a shop wants.

I would even prefer to keep the front end separated from the core as much as possible and the core should only ship the barest minimum possible, with easy to override defaults, so that the frontend dev can choose which front end framework she likes to use. Foundation i.e. is also a nice framework, like suzy is and so on and so forth.

:+1: for solidus-bootstrap :+1: for solidus-foundation :+1: for solidus-suzy :+1: for a frontend framework agnostic core

[moholtzberg]

I would think that moving the backend to a fremework like bootstrap would be a good idea.

But I would agree with @tvdeyen that the front end should be framework agnostic.

[mtomov]

I vote for Foundation for the backend. Having struggled a lot with Bootstrap over the years, and seeing the latest version v6 of Foundation, those guys have really made working with the framework an ease rather than an override struggle. Much lighter, customizable, better code organized and lots of nice JS components that are missing from bootstrap.

[tvdeyen]

Foundation is great. We had a discussion recently about the framework in the backend. As I also voted for Foundation, the majority of the core team voted for rolling it's own framework. ¯\_(ツ)_/¯

[pusewicz]

I think it makes sense to have a framework that far more people are comfortable with. Adding a custom framework does not make the software easier to maintain. It's actually the opposite. Using something like Bootstrap (which is far more popular than Foundation) mean that the barrier to contribute is much lower.

[gmacdougall]

Please don't take our rejection of the Spree 3.0 bootstrap as the rejection of the bootstrap framework, but only as a rejection of the manner in which it was implemented.

On the front end side, we have discussed removing frontend from the main repository, and allowing the developer to pick one of several provided front end implementations, or roll their own. As part of this, we want to move to a more API driven front end and deprecate some of the magic that happens in places like Spree::CheckoutController.

On the backend side of things, we're more interested in maintaining the status quo. I would not have made the choice to roll my own framework, but in the current state of things, I don't know if I would support a rewrite all of the views in order to support a new framework. If our frontend extraction is successful, maybe something similar could work on the backend side of things.

[Senjai]

:+1: @gmacdougall

[Scalechange]

It's clear from the comments that the frontend should be framework agnostic. If a choice was made, my choice would be bootstrap as it has very good implementation and support for responsive sites, but I guess the problem is that pre 3.0 spree users prefer what they built with and post 3.0 prefer bootstrap, so the logical solution is to make spree an engine with separate front end frameworks being developed by the respective supporters of each framework. Or put it to a vote.

[hhff]

I used Foundation for spree-ember.com because it allowed us to write the frontend entirely in HTML, with Zero CSS files.

Writing verbose HTML without zigzagging between CSS files makes building a customizable frontend super easy to maintain, easy for new developers to understand, and easy to swap out. You can just do a find all and replace in your templates folder for your new grid frameworks' classnames.

Also want to drop a :+1: for a Framework on the backend. The (awful) Spree 2.4 backend is the main reason I'm pushing Shopify on new clients, rather than Solidus.

:heart:

[tvdeyen]

@gmacdougall thanks for the words. I appreciate the thoughts and am fully 👍

@hhff the backend currently gets redesigned and enhanced bit by bit. Please see #509, #487, #505, #520 and so forth. Please involve yourself in the very open and appreciating discussion. Would love to here your feedback on how we can approve the backend.

[hhff]

word! on it @tvdeyen :+1:

[sukhchander]

@tvdeyen i just updated #520 with screens of the work ive done so far to implement a boostrap|HAML|coffee|responsive dashboard

[cbrunsdon]

To throw my $0.02 into the ring the main thing I care about isn't that we implement $FRAMEWORK_$VERSION but that we start getting sanity and clarity in the backend.

In addition to the tickets listed above, we also have:

• The style guide in #602 that will make the backend more clear and structured going forward

• 630, #633 and #634 to improve the organization, structure, and logic of the backend.

Rather than bikeshedding over frameworks, we should be focusing on reducing chaos and insanity and make the experience for people working on extending and improving the backend a reasonable experience.

As we saw from spree 3.0, trying to YOLO commit in a giant backend overhaul is just going to fracture the community farther.

[erikaxel]

Since we are collecting cents, here are 2: (for the backend only)

I think the backend really should be implemented with the help from one of the big frameworks. I have used Bootstrap, but any framework would really do. Two reasons:

1) For developers: It considerably lessens the burden of extending and improving the backend for people new to Solidus. One of the things I used too much time on starting developing on Spree was to understand all the different custom solutions created at the Backend. All of the frameworks are better documented than Solidus backend, and probably always will be.

2) For users: Our users loved when we migrated to Spree 3. Even though many things felt unfamiliar, the admin pages now worked across ALL devices/browsers and that made a big difference. This was especially true for mobile, and the users that do small fixes "on the go". I am not very happy about issues like "this doesn't work on device X", and I assume that most devs don't either. And since this problem is solved by several other frameworks already, it shouldn't be an issue that we need to tackle.

I understand the history of the project and that the mega-commit was not the way, and that now is maybe not the time, but it feels like going forward with custom backend code might suffer from "not invented here"-syndrome.

Maybe there is a way of integrating a framework piecewise (in parallell or after the other excellent backend fixes proposed?) Maybe start with using only the grid system from one of the big frameworks, or maybe just the CSS-reset, (ie just include the CSS as first include) or something similar? I do belive there must be a way of starting (and integrating!) this work without doing everything in one go.

[sukhchander]

@erikaxel great points. a few people have to get together around the admin dashboard. i volunteer to be in that group.

[jakemumu]

Hey guys, if solidus isn't using bootstrap for it's responsive css, what is it using? my default solidus app is acting responsively, so just curious what's up there.

Thanks!

[jgujgu]

@jakemumu skeleton right now https://github.com/solidusio/solidus/blob/master/frontend%2Fapp%2Fassets%2Fstylesheets%2Fspree%2Ffrontend.css#L4

[dt1973]

Personally I think we should worry less about front-ends and instead leave that up to each individual developer:

http://motherfuckingwebsite.com/

[graygilmore]

We're currently using v1.2 of Dave Gamache's Skeleton. Unfortunately, this has us stuck in a very rigid structure due to its fixed-width sizing.

I've spiked down two different paths to update us to v2.0.4 and neither work. The update doesn't work for two different reasons:

1. The new system uses twelve columns instead of the sixteen that we're currently using.
2. Even when modifying v2.0.4 to use sixteen columns we have a lot of nested columns which don't play nice with percentage based grids (the gutters end up being different sizes).

I was hoping we could bump to the newer version without needing to address nearly every view. This is not the case! So instead of trying to jam in a new version of Skeleton we might as well move on to something new.

I would like to see us:

1. Separate the front-end and backend grid systems. This is completed here: https://github.com/solidusio/solidus/pull/791
2. Introduce a newer, better known grid framework.

The frameworks that I prefer working with are the ones that are unobtrusive. I prefer working with Bourbon Neat and Susy because they are markup agnostic. They ensure the job of presentation stays where it belongs: in the CSS. Thoughtbot on why they created Neat:

Because we are not happy with other frameworks. We built Neat with the aim of promoting clean and semantic markup; it relies entirely on Sass mixins and does not pollute your HTML with presentation classes and extra wrapping div's.

This is the direction I wish to see us move toward. Too often markup and styles are treated as second class languages in administrative panels. What was made clear in my two Spikes of trying to update Skeleton is that semantic markup and clean stylesheets were abandoned long ago in Spree.

[tvdeyen]

@graygilmore everything you say is true.

I support to separate frontend and backend frameworks. :+1:

Also I like Neat and Susy, they are less known grids and since we provide a shop framework, where developers build shops in, we need to support better known grids.

I absolutely agree with semantic HTML and CSS. You probably know, but Bootstrap 4 and Foundation 6 (my favorite) support semantic HTML with Sass mixins as well. So everything we like about Neat is also possible with Bootstrap and Foundation and since these frameworks are far better supported (think of JS widgets, etc.) we really should think about using one of those.

If this here was a saas product or a website I would vote against Bootstrap / Foundation, but we provide a framework for developers and we need to make customization as easy as possible, while maintaining code standards.

Bootstrap and Foundation used correctly are a benefit, not a downside.

Everything already said, but I want to repeat again:

• No need to maintain your own grid docs
• New contributors can easily be adopted
• Browser quirks will most likely be fixed in one of the large frameworks at first
• Backend customization is much easier

-> Solidus adoption rate will raise

[pusewicz]

Exactly!

[graygilmore]

@tvdeyen that's great. To be fair*, I fell off the Bootstrap/Foundation wagon so long ago that I haven't bothered checking back in. That is great news and definitely changes my perception. I will have a look at Foundation 6 and play around with it!

* probably not fair.

[cbrunsdon]

The stembolt folk sat down for a meeting today and we've reached consensus that bootstrap would be a good way to move the admin forward, so long as we can execute on it reasonably.

Our tentative plan (needs more investigation) is to start by using just the grid and slowly fix our markup and add more components. Anyone elses help would be appreciated, of course, but we're going to try some experimental PR's to see how reasonable this is going to be to move forward.

[yeonhoyoon]

@cbrunsdon :+1:

[ajkamel]

@graygilmore :+1: on Bourbon it takes a nice approach however since Bootstrap is widely used I could see how it has a wider appeal.

[erikaxel]

A big :+1:

@cbrunsdon Do you already have some of these PRs ready? Great if you can mention this issue when you post them so that we get a notice. I would love to hear more about the approaches you are considering.

I have been thinking a little bit about how to do it with as small steps as possible, and have two thoughts:

1) Use semantic SASS mixings on the existing skeleton tags. Something like:

.sixteen.column {
 @include make-md-column(12);
}

Since the old Skeleton is 16 columns, and Bootstrap has 12, we obviously will run into the same problems as @graygilmore already mentioned, but maybe we then can fix those issues only where we need to in the first commit instead of changing all the HTML at once.

2) Only include some parts of bootstrap by overriding the main include I have used this successfully in multiple projects, such as one where we only wanted to use the grid and the reset.

You might already have discussed these options, but I haven't found anywhere where it is publicly discussed. Looking forward to hear your thoughts on the different approaches you are considering.

[cbrunsdon]

Hawth did some work in #955 to get bootstrap in an unobtrusive as way as possible, which should allow us to start moving bits of this forward.

[tvdeyen]

955 has landed!

[pusewicz]

:+1:

[pusewicz]

I believe we can close this?