replace less with stylus

[markshust]

I understand the reasoning behind picking less over sass. It made sense. However, if the files were converted to stylus, it would provide the ability to use many other css code styles for development (indentation, brackets vs no brackets, eliminating semicolons, etc.), as well as pick up a lot of additional math functions & additional functionality. I think this update would be very welcomed by the community.

Migration from less to stylus would be very simple, as stylus can accept a very similar format (basically, the same format) as less. A pull request for this would involve renaming files from .less to .styl, and then just updating the grunt/gulp build commands. Everything else should basically remain the same.

Let me know your thoughts and I can work on a PR.

[orlangur]

The main reasoning to prefer Less over Sass for Magento 2 was existence of PHP pre-processor.

Is https://github.com/AustP/Stylus.php (or any other PHP pre-processor for Stylus, if it exists) production ready?

[markshust]

Can you provide a sample area of where PHP is pre-processing Less? That sounds like an area that would better be handled in the nodejs build/dev process (grunt/gulp) rather than PHP, in which case we have access to the npm package. We should never be doing preprocessing in production as that should always work with just the post-processed css files.

[orlangur]

We should never be doing preprocessing in production as that should always work with just the post-processed css files.

Why? Such pre-processing is now possible due to usage of LessPHP library. It was decided to not make nodejs a mandatory dependency at some point.

I personally suggested to use more flexible solution which allows both NodeJS-based/PHP-only variants:
https://github.com/kriswallsmith/assetic/blob/master/src/Assetic/Filter/StylusFilter.php
https://github.com/kriswallsmith/assetic/blob/master/src/Assetic/Filter/LessphpFilter.php
https://github.com/kriswallsmith/assetic/blob/master/src/Assetic/Filter/LessFilter.php

Besides the implementation details, is Stylus popular enough to be chosen as a default dialect for core styles? I understand that Stylus can compile *.less files successfully but such twist without usage of Stylus full power does not look good, it would produce a mix of good-looking and bad-looking rules.

[alankent]

We are unlikely to release 2.0 with Less, then immediately switch to a different preprocessor that we officially support as core. However, I believe the pipeline is pluggable - you can register other converters in addition. I recall that someone had hooked up Sass that way (??). I would suggest tracking that down to copy from it. (We probably don't document how to plug into the pipeline, but the code certainly supports it.)

And yes, the model is "you can develop with Magento just using Magento" which is important for small sites or developers. NodeJS (grunt/gulp) is definitely useful as an option for advanced developers, but we are not going to mandate it.

[markshust]

@orlangur It seems really awkward to do pre-processing on production, and it seems very inefficient. You're left with a visitor on the site who will wind up 'hanging' on a page reload while the pre-processing is taking effect (this is why a lot of the site 'crawlers' started showing up to prime the site after a deployment -- I never liked that). It's much more efficient to preprocess the files in some sort of build process, and then when you deploy, no additional work be needed to be done on prod, and there will be no lag or hanging for an end user.

Stylus is quickly becoming the new standard for CSS pre-processing because of it's ability to handle all of the different style formats. I do understand the non-mandation of coding styles, in which case I do agree this could lead to sloppy code or inconsistent style formatting.

@alankent thanks for the info. The pluggable model makes complete sense.

As far as not mandating node, how would one build all of the needed assets right now (can it all be done with ./bin/magento?)? I was under the impression you'd need to run grunt refresh after making updates to static assets. And if this isn't needed and there is a way to do it with PHP, why is nodejs involved here at all? It seems like an un-needed dependency in that case.

[alankent]

I believe it can all be done with bin/magento today. (If not, we have a bug.) Grunt was because it was brought up by frontend developers that our CLI approach was too clunky - they wanted file watchers to regenerate whenever a file is saved - no manual steps. (It might also be faster?) So grunt is useful, not mandatory.

Regarding preprocessing before being pushed to production, yes we need to support that. We need to turn a "developer" build into a production build that can then be pushed to a production site.

Regarding plugable - just to also point out that using that path also makes a transition plan in future to any new technology easier - we can announce support for new technology and deprecate old technology several releases later. But can get the code out there, judge community support, then make any change over time. If we do as good as job as I hope for the new Connect experience, I think themes should be able to depend on your extension, so themes can choose to use it before we officiall support it, again allowing experimentation before comitment.

[markshust]

How does one execute the php equiv of the grunt refresh? A sample installation didn't render correctly until I ran that. Perhaps it was just an older version. I like the preprocessor plugin route, makes things more declarative on needs.

Lmk if you want me to create another ticket for preprocessing before deployment. This would greatly help in standardizing a recommended deployment process.

[markshust]

@alankent see last comment. I think the php equiv is ./bin/magento setup:static-content:deploy -- is that correct?

[alankent]

@buskamuza what do you think?