replace grunt with gulp

[markshust]

Grunt has a very slow building process. Gulp should replace Grunt as the recommended method for building static assets.

This would also be a good time to decouple PHP calls from the nodejs build process. Any PHP calls from nodejs should be moved to ./bin/magento so node/js code is kept node/js only, and PHP scripts are only called from PHP. This will help streamline the deployment process.

[piotrekkaminski]

@tkacheva can you look into it?

[sedax90]

+1 for this improvement

[jahvi]

:+1:

[brendanfalkowski]

+1. Have used Gulp extensively for M1 and it's way easier for frontend people to understand than Grunt.

[KAB8609]

+1 . I believe the majority of Magento Developers are using Gulp vs other build systems.

[alankent]

I am not a frontend dev - just wondering what people thought the gaps were. For example, we do some preprocessing of "//@magento_include". Are there other gaps external people know of that we would also need to support?

[brendanfalkowski]

This article nails why frontend devs like Gulp better: https://medium.com/@preslavrachev/gulp-vs-grunt-why-one-why-the-other-f5d3b398edc4#.keufgveaj

1. Grunt focuses on configuration, while Gulp focuses on code
2. Grunt was built around a set of built-in, and commonly used tasks, while Gulp came around with the idea of enforcing nothing, but how community-developed micro-tasks should connect to each other

@alankent Can you explain what you meant by this part?

we do some preprocessing of "//@magento_include"

At the Meet Magento Poland hackathon, I sat with five other developers and tried to trace through the M2 Less includes. We all kind of concluded it's unnecessary and overly complicated to fallback the CSS partials across themes. Also we looked at those commented out //@magento_include statements but had no idea that was processed separately by Grunt.

Aside: the frontend compilation is so unbelievably slow. It took about 7 minutes to rebuild all the CSS + JS + translations, which is a complete dealbreaker for how frontend devs work (make 3-5 changes, save + watcher re-processes + refreshes browser). We're doing that 2-3 times per minute while working.

It would probably take a day of work, but I think a lot of frontend devs will just abandon the Magento-bundled pre-processing for CSS and move everything to a decoupled build process to get around all the complexity. Even having to re-enroll every extension in a non-standard M2 build process, I think it will still be more maintainable and much faster to work with.

[markshust]

There are two main gaps between the two: configuration & speed. Gulp is tremendously faster than grunt. What @brendanfalkowski said; frontend devs won't really work with grunt anymore. To provide an analogy for backend devs, grunt:gulp as svn:git.

[jahvi]

I wouldn't mind it if it was just a matter of configuration vs code because most of the time the config is something you tend to do just once and once it's running you forget about it, it's more about speed and compilation times which is something that you have to deal with every time you change your resources.

On Fri, Oct 23, 2015 at 10:07 PM, Mark Shust notifications@github.com wrote:

There are two main gaps between the two: configuration & speed. Gulp is tremendously faster than grunt. What @brendanfalkowski https://github.com/brendanfalkowski said; frontend devs won't really work with grunt anymore. To provide an analogy for backend devs, grunt:gulp as svn:git.

— Reply to this email directly or view it on GitHub https://github.com/magento/magento2/issues/2104#issuecomment-150692786. Untracked with Trackbuster https://trackbuster.com/?sig

Ing. Javier Villanueva

[alankent]

There is no reason we "dislike gulp" - we just have "grunt" working today. There are just so many things to get done.

I was imagining what might be Magento specific. One thing I knew of was //@magento_include. We use that to search through all modules and allow them to contribute to the Less files for the site. It expands to @include <module>/<path> for every module where that path exists in the module. So that is one "magic" Magento feature. The other one is the path fallback model - we look for files in a series of directories, so themes say can override a file (when @include is used) or extend (when //@magento_include is used).

I don' know Gulp (or Grunt). The challenge seems to be how to integrate Gulp with our fall back rules and special directive, in an efficient manner.

[markshust]

We use that to search through all modules and allow them to contribute to the Less files for the site.

@alankent Why? I agree with @brendanfalkowski -- this entire LESS building process seems to bloated, overbuilt & impractical. No one's going to use it if it takes over a few seconds to build new CSS files.

[markshust]

The other one is the path fallback model - we look for files in a series of directories, so themes say can override a file (when @include is used) or extend (when //@magento_include is used).

I think overriding a file makes sense, but extending a file does not. Can't the same be accomplished by just creating a new less/css file and adding it to the assets being built? I just really don't understand "extending" a less file.

[alankent]

"extending" just means "append to the end of". Less forllows the CSS pattern of "last specified rule wins". The question is how to let a module be loaded and contribute the styles it needs to a site. The current approach "plugs in" that additional content, just like modules can plug in PHP code via di.xml, plugins, event observers, etc.

I want to do a little more research on how grunt works now. I was wondering how feasible it was to generate a Gulp friendly Less file, so little tweaks to CSS would be fast (and regeneration required only if files were added or removed). That could then be a CLI command. I just don't know how feasible it is yet.

[markshust]

My question is why do you need to 'extend' the CSS? CSS is not an object-oriented technology. Last rule wins, can't we just leave it up to the module to define which styles it needs to define, since CSS is all merged together when interpreted anyways? A module can always use higher-level node specificity if it needs to traverse up the DOM tree to style an appropriate element. One thing that would help is to be able to define the load order of CSS/JS files (not sure if this already exists). Stylesheets are just text files -- creating a new file is essentially the same as 'extending' an existing file.

[alankent]

I believe the import order is the load order of modules, which uses dependency information in modules.xml to determine the ordering (like all other cases). That is, app/etc/config.php order is worked out, then everything just uses the order in that file.

Just as one module's layout file can change/extend that of the layout files of modules loaded previously (e.g. module A adds a footer, module B adds a side bar, module C removes the side bar and adds a different one), modules (and themes) contribute to the CSS to be generated for a page (and can override CSS of previously loaded modules, allowing for example a system integrator to write a custom module for a site and have the "final word" on what styles will be used.

For example, the Magento UI library (a set of Less files defining buttons etc) uses lots of variables. You can change the color of lots of things just by changing a single variable. Variables follow the "last rule wins" rule as well. You cannot set the variable in a separate CSS file - it would not globally affect all buttons then. Remember Less variables you can use for things like lighten(@button_color,25%), so by setting one color you can change the whole theme (including shaded out colors, highlights, etc). So it is not lots of little CSS files that get imported, but rather lots of Less files that get compiled into a single CSS file that gets imported (which can also be minified).

For example, if you look at https://github.com/magento/magento2/blob/develop/app/design/frontend/Magento/blank/web/css/styles-l.less you will see it imports a few things, then finally //@magento_import "source/_extend.less";. The idea is this allows all modules to contribute to rules (e.g. add new widget related Less), but still have the ability to have a final say in _extend.less, which is a true "final say".

So how to control what Less files get loaded or not loaded? You just load (or not load) a module. You don't have to write a Less file that lists all the modules you have loaded for your site and maintain that file.

[markshust]

Thank you for the detailed explanation -- makes a lot more sense now

[alankent]

Nothing like trying to explain something to force yourself to learn it! (To be honest, I still don't understand all the rules - we have modes like client side Less compilation, where we make all the individual Less files available for download by the browser, so it does the compilation. I am still trying to understand all the subtleties myself.)

[markshust]

Having sort ordering was always a prob in m1, so this will actually completely fix that. Really like that now that I know what is going on (and why) :)

Where is the magic @magento_include being processed?

Edit: Never mind, was searching for @magento_include instead of @magento_import. Thanks a lot @brendanfalkowski :)

[alankent]

If you mean in the source code, I use "grep -r" myself to find it! I don't know how the code works to be honest - there are multiple modes going on (client side compilation, server side on demand, precompiled, grunt, etc). I have not looked at the actual code that implements it.

[CyberCookie]

+1 for this improvement. Just give us chance to do simplest changes in 1-2 sec. It's not a modern approach to wait for less build more than 6 sec as example, when you do changes every 5 sec in css and must watch all changes instantly. Developing must give pleasure but no pain.

[pawel-dubiel]

+1

Currently it seems almost impossible todo any serious work in timely manner. I have to wait a minute to rebuild all locales. Would be interesting to hear from others how they improve development speed and make the whole thing less painful.

[code-K]

+1 for this improvement

[Oregand]

+1 for this, gulp would make the development for the fronted JS & CSS much faster.

You guys have built an amazing project here with 2.0, lets just make it a tiny bit better!

[alankent]

To be clear, is the request for Gulp because you want Gulp functionality, or the request for faster performance whatever way it is possible? From comments it sounds like desire is for performance, not Gulp specifically.

[markshust]

@alankent grunt is an old tech, gulp is a newer one. there is no way to achieve even close to the performance of gulp with grunt. grunt : svn, gulp : git. it's like trying to make subversion faster than git, when it's not even remotely possible. grunt really sucks for frontend devs right now, it's aged (and already dead to frontend world). this just needs to happen.

[alankent]

Background: I was brainstorming on this one a bit, browsing Gulp code etc. One of the issues is my personal ideal experience is to not have to list dependencies etc at all - why not have Magento work out what themes, locales, etc exist. I was trying to work out if getting something merged into Gulp was important vs doing something custom where it knows more about Magento's fallback schemes, theme structures, etc. The end result could be less work to implement if custom (we would use standard Less processors etc). But it would be zero configuration (and thus zero extensibility). Hence I was trying to understand if it was speed that mattered or Gulp. Would people prefer doing more manual configuration and have a standard tool, or zero configuration but no ability to use for anything else that Gulp can do. (I was trying to not bias people's thinking.)

Hence the question - do people want Gulp or do people want speed?

[brendanfalkowski]

@alankent: I believe the import order is the load order of modules, which uses dependency information in modules.xml to determine the ordering (like all other cases). That is, app/etc/config.php order is worked out, then everything just uses the order in that file.

@alankent: So how to control what Less files get loaded or not loaded? You just load (or not load) a module. You don't have to write a Less file that lists all the modules you have loaded for your site and maintain that file.

For CSS, the order that libraries, resets, vars, mixins, utilities, layouts, patterns, modules, and pages are loaded matters. It can't follow an arbitrary order determined by PHP modules. If Magento 1 did this, none of the sites I've built in the last five years would work, be as maintainable, or as lean.

@markoshust grunt really sucks for frontend devs right now, it's aged (and already dead to frontend world). this just needs to happen.

This is accurate. The people using Grunt today are invested in it previously. Every grunt vs gulp comparison has the same conclusion: if you like grunt it's good, but you'll like gulp better if you care to update. So nobody fresh picks grunt today. And now NPM scripts is apparently gaining traction as an even leaner approach than gulp.

@alankent: One of the issues is my personal ideal experience is to not have to list dependencies etc at all

This just doesn't line up with how frontend devs use Grunt/Gulp and prefer the simple/extensible nature of listing things. It's very very easy to turn things on/off this way and put them in the right order. Autoloading makes it a mess because CSS preprocessors do not have a dependency definition schema. You have to architect this and be somewhat smart about it.

@alankent: Would people prefer doing more manual configuration and have a standard tool, or zero configuration but no ability to use for anything else that Gulp can do.

Definitely standard build tools is preferred. This is how frontend devs are capable of working with basically any platform. Imagine if every PHP project had their own twist to Composer that wasn't compatible.

@alankent: Do people want Gulp or do people want speed?

Both :+1: — and without the Magento flavored stuff. Keeping it agnostic makes it better for frontend devs.

[mackelito]

Should really magento be pron of any of these tools?

I use gulp and would love to see this change from grunt.. but I think the "problem" runs deeper.. like the choice of less.. gotta say that I like scss better and would love to use that together with npm instead!

[hrvojejurisic]

Honestly... I've been bitching about this for more than a year now.

Less, sass, grunt, gulp, npm, post-processors... you may continue the sequence. And who can guess what will be "hot" frontend tool or technology in the next couple of years?

IMHO, Magento shouldn't integrate pre-processing in the system at all. I can see my self ( and most of frontend devs I know ) abandoning Magento 2 "best practices" and implementing my own, decoupled system ( probably sass with gulp ), similar to what we had in Magento 1.

[mackelito]

Agreed! :) Perhaps we should create a open git repo for such a setup?

[Igloczek]

@hrvojejurisic I already rewrite bin/magento static-content:deploy to not process any styles (messy @magento-import fallback "thing" and other theme/module styles fallbacks) and to do not touch any files in /lib/web folder - this is time consuming and totally useless when you care about performance of your frontend stack. Now I try to do as much as can to write Gulp tasks/configs to run all possible styles langs/processors, no matter whats is your choice.

[markshust]

The underlying issue imho is that Magento has tightly coupled PHP and JavaScript/CSS layers. These should be _completely_ decoupled. This is leading to a bigger issue with how the "glue" of the system is architected, with no clear-cut plan/roadmap to decouple it.

@hrvojejurisic has said it. We've all been talking about this for a while. I've just been getting pushback also. I'm hearing "this is how we architected, and why", but that is leaving a development platform that is extremely opinionated and forcing vendor lock-in, because the Magento team just isn't listening to devs.

There needs to be a clear separation of backend development vs frontend development. The fact that frontend devs need to use PHP tools/cli at all is really weird to me. This is complicating the build process and making things really hard to understand, and causing on-boarding for frontend devs to be really hard.

There should be an option for frontend devs (plug-and-play, third-party/community system as noted above) to use grunt, gulp or webpack. Less, sass or stylus. PHP templates, twig, react or angular. Foo, bar or baz. Chocolate, vanilla, or superman. Please just give us the options to use what we want to use... :pray: If the architecture is that monolithic that it can't or shouldn't be changed for whatever reasons, developers are going to start to flock...

[hrvojejurisic]

This is complicating the build process and making things really hard to understand, and causing on-boarding for frontend devs to be really hard

Honestly, if my first Magento experience had been Magento 2, I would probably continue working with Wordpress or some other software.

[Igloczek]

@markoshust Exacly! #letfrontendbefrontend Mine WTF/min score reading grunt tasks was so high, because many of them are just wrappers to run bin/magento CLI... and then to know what really happens you have to digg in Magento/Framework or Magento/Deploy modules - not so front-end job at all :disappointed:

[alankent]

It was certainly a goal of standardizing on class attributes, zero inline style= attributes etc to allow advanced external folks to decide whether to use our CSS or go their own way. It was purposeful. We will not stop shipping a CSS solution that extension developers can depend on, but similarly if advanced frontend developers want to tune it all from scratch for a particular site (which I think is what @hrvojejurisic is after), the product supports this today. (If not, let me know the gap - it was a design goal.) That would not be a reason to remove Less however.

If there is anything we can do to make it easier for the "advanced" front end devs to replace our CSS completely, please let me know. In http://alankent.me/2016/01/22/css-and-tooling-in-magento-2-quick-note/ I discussed the different use cases we are trying to cover. If I have that wrong, please leave a comment on that blog too.

[alankent]

Hi @markoshust, "This is leading to a bigger issue with how the "glue" of the system is architected, with no clear-cut plan/roadmap to decouple it." You are correct, there is no plan to drop support the segment of the market that does not want to engage a front end developer.

If someone can come up with a proposal where extension developers can release extensions that merge their required CSS in, theme developers can write themes that have a chance to cope with extensions they have not seen before, and advanced front end devs can do custom sites then I am all ears. If a proposal only addresses the third use case, then yes - I will reject it outright with no apologies. I have not seen any proposals that address all 3 use cases. I would love to simplify things here, but not at the sacrifice of part of our customer base.

[Oregand]

"The underlying issue imho is that Magento has tightly coupled PHP and JavaScript/CSS layers. These should be completely decoupled."

Couldn't agree more. Just offering the option of separating the front end development of the "Store" vs the Core PHP backend would make the world of difference for a smooth development process.

The call for gulp over grunt relates to this, as gulp is a better task manager for front end assets.

[alankent]

Hi @Oregand, could you (or anyone else) write up your vision of how this would work? Feel free to email it to me at akent at magento dot com, or submit it in the "Just Ask Alan" area of the Magento forums. I am hearing a lot of desire, but I don't know what it means in reality. What would the experience be for extension developers, theme developers, and solution front end developers? I would be genuinely interested.

Also, with the M2 separation of CSS from HTML, what more would you like from the core platform? What stops you from doing this now? Does taking a copy of the current CSS file we generate and then throwing out all our Less processing make sense for example?

And when the next patch of an extension comes along that changes the CSS, what would you imagine being the workflow to merge such changes in? (Use Git to capture the old merged CSS and the new merged CSS and diff them? Then manually apply to the custom CSS file you have produced?)

Any suggestions, no matter how half baked, are useful and welcome.

Here is an example idea to kick it off: Policy should be that every module just creates a new CSS file for any HTML added by that module. A production site would merge (concatenate?) all the CSS files for speed - "advanced" front end devs to do this by hand (using Gulp if appropriate) with a fallback scheme in Magento for non-gulp users. The "Magento UI Library" of Less mixins can be used by the CSS files (Less files) if an extension developer wishes - but it is used to generate the CSS file for that module. (This would potentially allow different modules to use Less or Sass - we merge the result of the pipeline, the final CSS.) Theme developers can add more CSS to override the defaults, and can change Less variables that the individual modules would pick up.

Would this help? Any other ideas? The main difference in the above is the encouragement to generate a CSS file per module and merge them for production. Currently the //@magento_import is used to collect contributions from different modules. The above changes the thrust to generate one CSS file per module, and merge the resultant CSS files (if any). Would that be an improvement? (I have no idea if its feasible by the way - just giving a strawman proposal to get the community juices flowing.)

[Igloczek]

@alankent We already have "CSS merging hell" in M1, this not god way (but I get your point). Especially with non-strict rules about creating modules. If module devs "might" do something, they probably wouldn't do it (when they are not convinced to it i.e. because of complexity) and whole mysterious of "Magento UI" might gone away.

Overall idea of structure is good, but not ideal. Let's assume that we have 3 different themes on store and every of them use different modules. Magento ignores this case and load every of them for every theme - that's why we dislike idea of @magento_import, we lose control of what is really in our theme (remember about performance too). BTW. Here might be more problems, like styles overrides (module dev might use same selector and we are doomed), because lack of strict methodology writing styles/templates, like BEM (https://en.bem.info/method/).

Also PHP based asset processing "not helps" here, because almost any of front-end devs know what really happens. It take longer than we except and/or requires running some magical CLI commands over and over, i.e. dev:source-theme:deploy with so long list of parameters, witch no one want to type by hand.

In your latest blog post you ask about that why we like Gulp tasks builded for one purpose, with strict paths etc. Answers is - because it work's fast and it simple to maintain (have in mind that your example might be polished and simpler :) )

So what might be solution?

Simplify and move styles processing to node.js (whatever task runner or even without them, in pure npm as @brendanfalkowski mentioned). Then Magento CLI should run this tasks, to get same results of processing, no mater if we are on production or in local env.

What I mean by simplify?

Let front-ends do @magento_import job and decide what they want, but this solution are not compatible with client-side styles compilation (really some one might use this? As you know, working with Magento is not piece of cake, and thats why merchants should not be able to edit code on production...) Or write this in node.js, but let devs define what are default theme for each of them and maybe make some "active modules" list? Another thing is Magento UI styles in /lib/web/css - don't you think this should be placed inside of Magento UI module?

BTW. For me whole /lib/web/ is like old js (with some extra types of files) and might looks like :hankey: after installation of few modules.

Why?

Front-end things should be maintained by front-ends, in front-end way. That's give us ability to use modern tools of choice, any styles lang we choice. And... this still might keep previously designed structure.

[alankent]

Hi @Igloczek - thanks for this! One question, you mention different themes use different modules - how? Currently modules are globally enabled. Do you do this by changing the layout file to not reference the module? Or something else?

I am thinking through an approach where I think we can get it so you can use 100% gulp/grunt/whatever for CSS generation, but I wanted to make sure I support this use case.

(Approach is based on no magento_import and instead having a CSS file per module and merging the results later, with manual override available by front end devs who want it - does that sound like right direction? But still early days. I want to make sure it captures all requirements however, so your comments here were great.)

[Igloczek]

@alankent I mean real use of modules (if we display it on front). Your example of "hiding" it in theme scope via layout change was right.

This approach makes modules not depended on theme variables or even Magento UI (or I missed some point). Current idea of having module styles as partials (to be imported during styles processing) is much better, but requires some manual work or extra logic, to handle it.

[alankent]

@Igloczek I think it got it, if CSS importing was associated with blocks for example (this might be a bad idea due to number of blocks?) then a layout file in a theme that removed a block would automatically result in the CSS not being included (if that block was the last reference to the CSS files). You might have more little CSS files, but If you merge the CSS files later maybe that is okay.

I was almost wondering if you have an optional CSS (or less) file per phtml file. It helps relate styles with a particular fragment of HTML. But not sure if that is overkill. Any opinion on best granularity of CSS files for development? Per handle, per module, per block, per HTML template file, etc?

[Igloczek]

@alankent Unfortunately, there is no one good solution for handling styles - OOCSS, ACSS, BEM, SMACSS... and probably few more and variations of them, excluding "no methodology" style, like we have right now in Magento :)

And there is main problem - we have to care about CSS selectors, especially order and specificity of them. Without any strict methodology, witch makes selectors unique, this would be hard to maintain, because of possible overrides.

In Snowdog we decided to use BEM methodology as a foundation and it works great (we use it about year right now). Mine current style files tree looks like this (this is M1 project) - screenshot

Every folder inside blocks represents a bigger group of blocks - like view or bigger layout part, like header. Files inside this folders are in most cases single blocks or group of few smaller blocks (most of files keep limit of ~200 lines per file)

BTW. Idea of granularity styles might be great for incoming HTTP/2, but we have to care about good (unique) naming of files.

[brendanfalkowski]

@markoshust — There needs to be a clear separation of backend development vs frontend development. The fact that frontend devs need to use PHP tools/cli at all is really weird to me. This is complicating the build process and making things really hard to understand, and causing on-boarding for frontend devs to be really hard.

Exactly, this is why frontend devs are repeatedly claiming Magento 2 will be a lot better if we disregard the entire CSS provided, and start from scratch with a platform-agnostic un-coupled workflow. We know this won't include theme fallback, and that's a bonus because frontend devs doing custom work really don't want to have fallback in CSS anyway.

@hrvojejurisic — Honestly, if my first Magento experience had been Magento 2, I would probably continue working with Wordpress or some other software.

Exactly the same problem with installation as a frontend developer. I wouldn't have given Magento 2 a second chance if I wasn't already a Magento 1 developer. As a platform, the technical expectation is still M1+M2 very slanted to backend dev skill sets. This will continue to be a problem attracting and retaining good frontend design/dev people.

@alankent — There is no plan to drop support the segment of the market that does not want to engage a front end developer.

In the wild, there are no Magento sites that run without backend and frontend developers. Magento never was a plug and play product, and I don't think it ever will be. The lock-down needed for that just doesn't fit with an open source product — if you expect no conflicts/bugs upon integration.

@alankent — If someone can come up with a proposal where extension developers can release extensions that merge their required CSS in, theme developers can write themes that have a chance to cope with extensions they have not seen before, and advanced front end devs can do custom sites then I am all ears.

I can only see one way to do this, and it's not "the right way" but would work technically:

• Extension makers provide a manifest CSS partial, which imports all the genuine CSS partials from their module only
• Magento builds a command to symlink all those manifest partials into one directory
• The build process for CSS compilation includes a glob to that folder: @import 'abc/xyz/vendor-manifests/*';
• Every extension with code in the system would get imported
• The command would need to remove the symlink if the module was deactivated (it would not be happening live with compilation)

@alankent — Here is an example idea to kick it off: Policy should be that every module just creates a new CSS file for any HTML added by that module. ... This would potentially allow different modules to use Less or Sass - we merge the result of the pipeline, the final CSS.

Technically works, but worse in practice. The benefit of a unified CSS architecture is cascading utilities provided by the pre/post processor (mixins, vars, prefixing). If every extension contributes its final CSS then we need to run multiple build processes to integrate, override, and compile them. Not a viable workflow/maintainability. Would be easier to take what extensions provide and enroll it manually.

@Igloczek — BTW. For me whole /lib/web is like old /js (with some extra types of files) and might looks like :hankey: after installation of few modules.

This always turned to :hankey: because extension devs had no framework for loading frontend assets in a consistent way. Everything was smattered over /js, /media, /skin, and sometimes their own root folders.

@Igloczek — Front-end things should be maintained by front-ends, in front-end way.

I think this is the biggest gap between how Magento has architected the frontend, and how frontend devs actually want it. There shouldn't be a Magento/PHP flavor on the frontend. I always point to Laravel for having an opinionated backend, and extremely open/standard frontend. That's what Magento should follow.

@alankent — I was almost wondering if you have an optional CSS (or less) file per phtml file. It helps relate styles with a particular fragment of HTML. But not sure if that is overkill.

That would be a nightmare. Don't tie the CSS to each PHTML file. Classes, cascading, and inheritance are the CSS tools the make that unnecessary. That's why component/pattern driven development is loved by frontend devs.

@Igloczek — Unfortunately, there is no one good solution for handling styles - OOCSS, ACSS, BEM, SMACSS... and probably few more and variations of them, excluding "no methodology" style, like we have right now in Magento :)

We tried to get Magento using OOCSS (pre BEM) 2 years ago: https://github.com/magento-hackathon/operation-frontend-steward/blob/master/pivots/05-css-architecture.md

The chained classes approach in M2 is so dated and problematic — especially because it's bound to the HTML. I've adopted a blend of OOCSS + BEM techniques since then, and having a methodology significantly improved the CSS architecture and the ability to re-use code across projects. I'm working on updating my Field Manual for this, but it's half done now.

[fooman]

@brendanfalkowski

In the wild, there are no Magento sites that run without backend and frontend developers.

I would disagree with this statement and even go as far to say that a big proportion of sites do not have specialist frontend/backend developers (if they have a developer to start with). Granted these are not big merchants but there are a lot of them out there.

[brendanfalkowski]

@fooman — That's a fair point. For Magento 1, I would agree. Even though stores with no developer support were really setting themselves up for failure by choosing Magento. I saw plenty of my themes bought by people who really should have been on Shopify.

For Magento 2, I think the platform itself has quietly pushed those people aside. It's a lot less friendly even to beginner and intermediate developers. I'm still struggling with decisions made on the frontend, and quite honestly never could have gotten it installed myself without numerous sacrificed hours from the community building and re-building VMs.

If I'm asked "who is Magento 2 for", the answer will pretty clearly be stores with developer support. I just can't see anyone else realistically being Magento's customer, and I would rather the product not cater to someone who is going to fail with it.

Hence the requests for a frontend system that really works for frontend developers first.

[alankent]

Personally I don't think the platform has pushed aside the low end. We don't have the receipies in as common knowledge yet, not having marketplace launched yet is a delay, but I truly believe by say Imagine it is going to be pretty slick for people without devs. We started with the higher end, and the very bottom you have players like zoey commerce (built on Magento, so easy to upgrade later), but I admit I have more insight into things going on. So I understand the concern today, but I am confident its temporary.

And hey, people get to point at this post after Imagine if I am wrong! ;-)

[dsingleton47]

+1

I agree with many of the comments here, personally I prefer Gulp over Grunt, but honestly speed is more important to me than the specific technology.

I was really hoping M2 would get out of the way of front-end developers, but it seems you've found a way to make it more opinionated than ever. Lets take the LESS fall-back as an example as well as being over engineered, you've effectively tightly coupled the platform with LESS.

There is now a massive overhead for anyone wanting to use SCSS in terms of both the initial work and on going maintenance involved. So much so, I would argue its probably not worth the effort. Similar to the situation we faced in M1 with in-line JavaScript.

[crashtimer]

If someone wants can use my gulp.js file : https://github.com/poddubny/magento2-gulp

There are modules: -less -watch -sourcemap -minify -livereload

It's enough for development. Other commands like "exec", "clean" use PHP inside.

As tests show, gulp x2 faster.

[alankent]

@poddubny - cool! I have a blog post almost ready to run asking for help trying out an idea I think will work today (not perfect, but usable immediately).

@dsingleton47 - thanks for the comment. I just wanted to clarify if you meant "you should have tied Magento to SCSS instead of Less" or "Magento should not use Less or Sass or SCSS". Note that we have separated CSS from HTML, so you can generate your own CSS files for your own markup without issue, and I assume you can always merge CSS generated from Less with CSS generated from SCSS if you wanted to. That is, if you want to treat Magento as not having Less, then just close your eyes and use the CSS file we generate out the other end. Is there a reason that won't work? (It seems like you have an approach in mind, but I am not sure exactly what it is.)