Build system and online download builder

[arschmitz]

We will want to make sure we have both an easy to use command line build system as well as an online download builder to allow people to pick just the modules they want. The online builder is important since we want to be accessible to designers who will shy away from a command prompt.

[cbracco]

I've really been enjoying using Gulp as a build tool/task runner for some recent projects, does anyone have a preference here? For the online builder, however, I'd be cool with whatever.

[jzaefferer]

For the download builder we might be able to reuse the existing download builder for jQuery UI: https://github.com/jquery/download.jqueryui.com/ @rxaviers may have some thoughts on that.

For CLI/build tools: Other jQuery Foundation projects use Grunt. We should stick with that, unless there are compelling reasons to use something else.

[arschmitz]

@jzaefferer +1 that would be what i was hoping on both accounts

[rxaviers]

jquery/download.jqueryui.com is very specific to jQuery UI. Although, we can reuse lots of it writing a new generic one. It's worth pointing out jQuery core is also interested in (https://github.com/jquery/jquery/issues/1691).

Having said that, I question its importance. What problem are we really solving with an online download builder? @arschmitz said "(it) is important since we want to be accessible to designers who will shy away from a command prompt". I agree with @arschmitz on the goal. But, I don't think download builder is the answer.

Correct me if I'm wrong, but I understood a designer in this context is using CSS Framework as is (in a read only mode) to implement a design in his/her own application. Designer might use a custom build instead of the regular released files, because he/she might want to customize CSS Framework with different color, etc (any other reason?). Designer places the custom bundle in his/her application and use it. Everything goes just well, until he/she needs to update CSS Framework. When that's the case, he/she needs to manually re-download the newer version of his/her custom bundle. The manual aspect of this workflow breaks all possibilities of using a package manager to automate this process. Aside the manual aspect, there is the compatibility issue. Eventually a new release will change customization-parameters and the download builder interface will have to handle the previous parameters into the new ones (map if possible, alert otherwise). Usually, these are lost.

Can't CSS Framework be made in such a way that customizations are held to designers? For example, by allowing him/her to override parameters using a variables.less (or sass or whatever)? After all, that's a language designers are expert at. They are free to upgrade CSS Framework without patching anything. They are free to automate this process. If newer versions bring breaking changes, they simply update their variables.less file.

[rxaviers]

Automation is important.

The line of code that the developer can write the fastest, the line of code that the developer can maintain the cheapest and the line of code that never breaks for the user is the line of code that developer never had to write

Steve Jobs

[arschmitz]

@rxaviers no that would not be the use case here the use case to to include or exclude different modules just like with the ui or mobile builders what your talking about is themeroller. We will be creating a new themeroller for this there is no issue for that yet though.

[sfrisk]

I would love to have the css-framework capable of letting the designers make customizations to colors/fonts/etc from the browser, and then download the css-framework with those variables already populated in the variables.scss file or whatever.

I think bootstrap does something similar to this: http://getbootstrap.com/customize/#less-variables

[sfrisk]

Aaand just noticed @arschmitz's reply. I'll go create a themeroller issue.

[arschmitz]

@sfrisk we will have something like that for sure but more like http://themeroller.jquerymobile.com/ or http://jqueryui.com/themeroller/

[arschmitz]

oh man timing... anyway to me the main difference here is theme rollers give actual visual feedback as you modify the values the less variables page gives no indication the difference these values make

[rxaviers]

@arschmitz

the use case is to include or exclude different modules

So, it's even easier: release the modules as consumable files and let users pick them.

Still think an online download builder is needed? Please, why? What problem do you want to solve with one?

[arschmitz]

@rxaviers yes i do to bundle them into a single file minified and account for dependencies. The audience here is like to have NO KNOWLEDGE of any time of local build process and we don't want them including multiple style sheets, and also don't want them including a monolith if parts are not needed.

[rxaviers]

An application certainly has other style sheets. So, it will still include multiple ones. In the end, our build step is useless. If we're really concerned with users not including multiple style sheets, we should think of a real solution.

[arschmitz]

@rxaviers thats like saying jQuery UI and mobile should not have builders because they should be using other systems maybe your right but its not realistic. As this framework grows to encompass full page layouts like mobile or bootstrap themes do, this will become increasingly important to avoid unneeded bloat. Its also needed to handle dependencies.

[kborchers]

Just thinking out loud but what might be good here is a hybrid of what both @rxaviers and @arschmitz are talking about. We should create a set of build scripts that can be used as part of someone's build process and provide a web interface on top of that set of scripts so we aren't maintaining separate build processes.

[dmethvin]

Definitely a <img src="whynotboth.gif"> going on here.

As far as uses, possibly break this into two questions. 1) Will this project use a CSS preprocessor for its own internal development? 2) Will the web devs be required to use a (local or online) CSS preprocessor, or is it optional? It sounds like item 1 is a "definitely" but as for item 2 I don't think devs should have to use a preprocessor before they can take advantage of this framework.

Seems like there are still valid use cases where a site developer will want to include a static file from this framework (possibly from a public CDN) and not deal with a CSS framework build step. (Go to cdnjs.com and search Bootstrap for example.) No doubt they will pay a cost in bytes for doing that but it greatly simplifies development by avoiding build tools. Also think about an environment like WordPress where it might be hard to optimize the page globally, it's componentized on the server side.

If someone wanted to merge both their own styles and the framework styles together then they'd be able to (and required to) either a) preprocess the CSS into custom files during a local build process, or b) preprocess the CSS through an online service.

It's kind of similar to what jQuery core does with AMD modules. We organize the modules and dependencies via AMD, but the user is not required to use AMD in their own project. They can either include the standard built file on our CDN or build their own custom file via our grunt build process. But the AMD modules are there and they could instead pull in individual modules if they are using AMD in their own project.

[arschmitz]

I definitely don't think devs should be required to do any sort of preprocessing them selves while advanced builds may require it we should provide tools to help here. I think we should have both a command line and online build tool they don't need to be connected in anyway.

[rxaviers]

My suggestion: think why you want to make an online download builder. Don't do it because others do. Think what problem you are solving. Who the target users are. After all, this is a new project, which has no addictions/vices yet.

jQuery Core wants one to help in its build process (somewhat similar to pre-processing styles as Dave has pointed out). jQuery Mobile and UI have a completely different purpose, which is to help concat+minify consumable modules (as @arschmitz has pointed out and I said it's useless). I'm very confident we should re-think/re-evaluate this strategy in all these projects as well. Because, I do believe they create a bad habit in developers (e.g. maintenance becomes manual and error prone). But, this is a topic for each respective project.

[JoeBot0101]

I'm leaning toward @rxaviers argument. Maintenance becomes a lot easier if css-chassis is a whole. It can still be modularized and rebuilt locally for advanced users, but the package as a whole should be efficient and performant enough to avoid the necessity of a custom download builder.

This seems the best of both worlds, where users familiar with build tools can happily customize and rebuild (and we can make that process as easy and painless for them as possible), but designers and newer devs can confidently download the full package, knowing that they have an easy maintenance path going forward.

[kristoferjoseph]

I would really like to see an online configuration tool.

We found on @topcoat that this was one of the biggest hurdles to adoption.

We had created a modular framework but it required people to run a build script to use it. We felt that this was a pretty common prerequisite ( download, install, run build ), but ran into a lot of push back. The barrier of the terminal is very real to designers still.

We also found that high level influencers in organizations were very seldom computer savvy so they wanted a web page to configure and download from to show people.

We also discovered that developers would balk at any and all preprocessors if it was not the one they thought was best, but funny enough they would use a CDN version of the compiled CSS without even looking at it. Having a way to deliver just the CSS regardless of the preprocessing needed is very important.

I imagine a system, similar to jQuery's, where urls with query params could be used to hit an api that would return the customized CSS. This would have the ability to cache output for subsequent api calls. The web based tool would just configure the api call.

[jzaefferer]

jQuery Mobile and UI have a completely different purpose, which is to help concat+minify consumable modules (as @arschmitz has pointed out and I said it's useless). I'm very confident we should re-think/re-evaluate this strategy in all these projects as well. Because, I do believe they create a bad habit in developers (e.g. maintenance becomes manual and error prone). But, this is a topic for each respective project.

I don't think its useless, but its problematic, and I think it deserves a bit more explanation. I ran into that recently in a project using both jQuery UI and jQuery Mobile. For both we use custom downloads, and we list selected components manually in a text file committed to the repo. When updating those custom downloads to newer releases, we go through the previous list, pick those components again, possibly add or remove something and store a new list for the given version. Its tedious, but since those updates happen at most every other month or so, its not a big deal either. It would be nice to automate it, but for this project in particular its likely not worth the effort.

The barrier of the terminal is very real to designers still.

In many ways the terminal is a terrible user interface, I'm sure its not just designers. It would be great to have an web interface to build custom downloads that makes upgrades from one version to the next easier than what the jQuery UI download builder currently has to offer.

[mendeza]

I agree with Dave as to why not both, though I personally prefer maximum flexibility on the commandline. Downloading a custom build (and then hacking on it more) incurs a maintenance nightmare, arguably a form of technical debt. Despite extra weight, here at Thomson Reuters we often use an override approach to keep OSS source completely untouched, for the express purpose of easing updates. We have separate "theme" preprocessing that imports variables and mixins from the third party code so that we can "play with the same deck," so to speak, while keeping the third party in a pristine state.

[trailofdad]

I like the idea of having both CLI and a web builder. It caters to more than just one group of developers AND you get to make your build custom and lightweight (only the chassis). @rxaviers there are so many users of frameworks out there who don't care to use a command line and hate having bloated file systems (those tend to be the more design-centric developmers). Why not make using a framework more accessible to those who are casual developers? It in no way should affect the power users out there.

[rxaviers]

@trailofdad, making it more accessible is the idea. The problem is how. I'm not defending CLI is all we should have. I'm concerned that we provide + encourage a broken solution. A download builder is a bad habit IMO for maintenance purposes as discussed above.

[rxaviers]

I imagine a system, similar to jQuery's, where urls with query params could be used to hit an api that would return the customized CSS. This would have the ability to cache output for subsequent api calls. The web based tool would just configure the api call.

@kristoferjoseph, this is an interesting approach. It's like having css-chassis as a service. Although, technically it's very similar to a Download Builder plus being a CDN provider.

[rxaviers]

So far we've discussed three distinct roles for download builder (the online tool). Please, correct me if I'm wrong.

1. Customizes styles (became #20).
2. Allows usage without having to run a CSS preprocessor.
3. Concatenates modules and dependencies into a monolithic bundle.

Customizes styles

This topic became #20, so let's have any related discussion there. The summary is that a configuration online tool called ThemeRoller will be provided. It will generate the variables file.

Allows usage without having to run a CSS preprocessing.

This is the most concerning one IMO if css-chassis cares about having wide adoption.

@dmethvin well put these use cases:

1) Will this project use a CSS preprocessor for its own internal development? 2) Will the web devs be required to use a (local or online) CSS preprocessor, or is it optional? It sounds like item 1 is a "definitely" but as for item 2 I don't think devs should have to use a preprocessor before they can take advantage of this framework.

Dave is not the only one who thinks developers shouldn't have to use a preprocessor before they can take advantage of this framework. @kristoferjoseph said the same thing considering his experience on @topcoat:

We also discovered that developers would balk at any and all preprocessors if it was not the one they thought was best, but funny enough they would use a CDN version of the compiled CSS without even looking at it. Having a way to deliver just the CSS regardless of the preprocessing needed is very important.

Looking for a "market share" about the preprocessor worlds, I found out that 82% don't use SASS or SCSS (https://css-tricks.com/poll-results-popularity-of-css-preprocessors/), even being one of the top two most used preprocessors. It reinforces the need for distributing plain CSS.

I think that a simple solution that doesn't require the developer to go into a download builder webpage to download the generated CSS (which I believe is a bad habit for maintenance purposes as discussed above) is to simply include CSS processed files on each release. This way developers can use package managers like bower or npm and use the CSS files. Let me explain...

This problem is very analogous to the module loader on JS development, where source code is written using ES6 modules. But, distributed using different flavors (AMD and CommonJS). Similarly, css-chassis could generate dist/*.css files and commit them on detached tags for easier and wider adoption. I would expect dist/grid.css, dist/table.css, dist/button.css, dist/form.css, etc. Note a direct map between a .scss into a .css file is not strictly necessary. For example, scss/typography.scss + scss/utilities.scss + scss/mixins.scss + scss/helpers.scss could generate dist/core.css.

Concatenates modules and dependencies into a monolithic bundle

If one cares about developers using monolithic bundles on their applications, it's clear that Download Builder is not the answer. It's pointless encouraging them to use a custom tool for each of the libraries they depend on and ignore their actual need for creating the bundle for their apps. There are several real tools for managing dependencies and for creating the bundles. Let's encourage them to use that.

For the developers that want a fast and simple solution for prototyping and don't want to setup the bundle themselves, prototyping doesn't need optimization. Having multiple stylesheet link tags in their HTML won't be a problem.

[rxaviers]

here at Thomson Reuters we often use an override approach to keep OSS source completely untouched

@mendeza, I agree that keeping source completely untouched is the key for maintainability. Could you explain what's the override approach you use please?

[sfrisk]

A download builder isn't an unreasonable suggestion. Many CSS Frameworks and UI Toolkits use them, and thanks to pre-processors, it doesn't need to be a headache.

For example, take a look at what Bootstrap does:

Now going to the download page of bootstrap makes it quite easy to download the CSS as is - minified or un-minified. Downloading the source to do things the LESS and Sass way is offered as a secondary option, for those who would prefer a bit more control and don't want to use the CSS as is or the CDN version. Pre-processors are not required to use Bootstrap - they are merely there for the more advanced developers who want more control and flexibility.

However, if someone doesn't want the default CSS as it can be found in the CDN, or deal with LESS or Sass, then they have the option of using the customized download builder.

On this page you have the option of selecting which components you wish to include with your download as well as setting many of the base variable colors. Thanks to pre-processors like Sass or LESS, it's relatively easy to set variables to set up if() statements to chose to include certain components to compile. Then you just need to run the the pre-processor server side and give the user back the CSS that they require. This allows them to have some of the power offered by using a pre-processor on their computer, but without having to figure out how to use the pre-processor. This allows bootstrap to become more accessible for more junior developers and easier to theme.

I'm using Bootstrap as an example here, mostly because of its popularity, and I haven't seen people having a problem with this approach. The custom builder allows for the variables in the pre-processor to be manipulated in the browser, without having to deal with setting up a pre-processor locally.

Also, I don't think using an article from 2.5 years ago arguing that 82% of market share don't use a pre-processors works in this situation. Front end development has changed a lot in the past 2.5 years and will continue to change. Even if everyone isn't using pre-processor locally, it doesn't mean we shouldn't use one to make it easier to generate the CSS we need for users. If anything, it makes it much easier to make Chassis accessible for not only senior but junior front end developers.