remove AsseticBundle

[fabpot]

see https://twitter.com/fabpot/status/648520881145253888

We should probably update the docs on symfony.com to add some default/sensible configuration that we are removing here.

[Mandragora2]

+1

[cedvan]

👍

[Shine-neko]

+1

[rpg600]

👍

[jjsaunier]

👍

[soukicz]

What about linking of images in template? It seems like everybody reacted just on postprocessing of CSS/JS.

[stof]

@Soukiii AsseticBundle is not needed to reference assets. Don't confuse Assetic and the Symfony Asset component

[Mandragora2]

@Soukiii twig asset function is not linked to asseticBundle ;)

[soukicz]

Oh, sorry. My bad.

[welcoMattic]

👍

[AlexandreKilian]

+1

[javiereguiluz]

I'm sure that most people will say +1 but please remember that symfony-standard != symfony. The standard edition is about being useful. If we remove something without providing an alternative, we are providing less value to the end user.

[bastnic]

👍

[stof]

@javiereguiluz you don't always need to use Assetic. There are several alternatives:

• not using any build system for your JS and CSS (unlikely in real projects, but it is good for a start, and might even continue like this. Packagist is an example)
• use gulp/grunt/whatever and then reference the asset. This will give you the flexibility to use any frontend tool you want btw

[javiereguiluz]

@stof I'll explain my concern with an example:

• If you ask 10 people which CSS framework to use, 8 will tell you Bootstrap, 1 will tell you Foundation and the other 1 will tell you to not use a framework.
• If you ask 10 people which workflow/technologies to use for JavaScript Asset management, you'll get 15 different answers.

[TomasVotruba]

👍

[stof]

@javiereguiluz and this is precisely why letting the user choose may be better. Assetic is probably the worse of the 15 answers you get (it depends on the actual tools, and generally does not give access to latest features of these tools because the Assetic integration is not provided by authors of these tools).

[Koc]

If you removing assetic bundle, so please provide clean recipe hot to combine+minify assets without it and add migration guide first.

[AlexDpy]

👍

[rande]

@Koc a starting point: https://github.com/ekino/webpack-cheatsheet/blob/master/webpack.config.js

[zilongqiu]

👍

[javiereguiluz]

@Koc this is the official article for using JavaScript to do this: http://symfony.com/doc/current/cookbook/assetic/uglifyjs.html

And this is the alternative article using pure PHP libraries: http://symfony.com/doc/current/cookbook/assetic/php.html

[stof]

@Koc Assetic will still be an option. But other options are OK too.

There is symfony/symfony-docs#5725 about writing a cookbook showing how to use Gulp in a Symfony project (@weaverryan already produced http://knpuniversity.com/screencast/gulp about the topic btw). And cookbooks for other tools are also possible.

[theofidry]

👍

[robmorgan]

+1

[ppawlakov]

+1

[thadbryson]

I'm for getting rid of Assetic. There are better options now. Maybe even integrate Yeoman into it? Then we'd have code generators that could be imported, Bower for adding assets, and Gulp for managing the assets.

[dunglas]

@javiereguiluz because the web is changing. Symfony is a very good tool to build server-side apps (API, forms, server-side generators...) but it is not adapted to build webapps, mobile apps nor desktop apps.

We don't include helpers to build Swift, Java Android nor Swing apps in Symfony, however it's a very common use case to power such apps with Symfony as backend technology. It's becoming very similar in the field of websites. Advocating a frontend technology instead of another misses the point:

• Symfony is 100% independent of the frontend stack
• Supporting (installing in the standard edition) a specific frontend stack such as Grunt+Angular or Gulp+Flux+React will introduce a lof of complexity (including the Node dependency) for almost no benefit (it's easy to install such stacks without the help of Symfony)
• Other projects such as Yeoman already handle this problematic well and are supported by a strong community

We should focus on what we do well: a server-side framework.

[dunglas]

LDAP security and ISSN validator are perfectly valid features of a server-side framework.

[cedvan]

@dunglas totally agree, big 👍

[catchamonkey]

So, I would accompany this by a slight update of the docs, i.e. a big "How do I minify and combine assets?" cookbook article. There, we can give the user a few well-documented options, including Assetic, Gulp and (why not) other things like what @Swader mentioned. It should not be much different than the current situation, except that if you want Assetic, you'll need to composer require

I think this sums up my thoughts on it nicely.
No possibility is being taken away, it's just no longer the default in the standard edition.

[sroze]

@fabpot In the full stack framework, I totally disagree with this idea. A lot of people are using Symfony for API-only applications, but we need to keep in mind that's not the case for everybody. Especially for beginners it's far better to have Assetic already installed in the standard framework than having to manually setup an option to manage complex assets (whatever that option is). I've run the DX initiative and that PR is not going at all in that direction IMO.

@dunglas if "Symfony is 100% independent of the frontend stack" we should also remove Twig in that case, JsonResponse is enough 😉

[dunglas]

@sroze Twig is useful for forms, mails and when doing apps not relying on Javascript at all. But I hope one day the JsonResponse way will be the norm :-)

[tvlooy]

@fabpot Anyhow. I think the question whether Symfony should change it's vision about frontend is an important one. Do you want to be a full stack framework or do you want to deliver components to Drupal, Laravel, ...
Components like Assetic, Twig, form builder, all have valid use cases, but for a lot of projects things like GraphQL in particular and component based frontend frameworks will become much more important in the future. These are the things that should have better integration, get easier to start with in future releases, ...

[stof]

we should also remove Twig in that case

Twig is not part of the frontend. It is a server-side technology.

[theofidry]

@fabpot Anyhow. I think the question whether Symfony should change it's vision about frontend is an important one. Do you want to be a full stack framework or do you want to deliver components to Drupal, Laravel, ...

IMO there is nothing wrong with moving away from the "full stack framework" that Symfony claimed once to be. It's an old approach that becomes less and less relevant given how the front-end stack evolves. We're not talking about prohibit the Assetic, we removing as it as a pre-installed one. AFAIK, it's always easier to add a bundle rather than removing one. Moreover keeping it as pre-installed is pretty much promoting it as if it's one of the best solution existing. It's a good one, but that's it. As of now, there is nothing to justify placing it before another solution anymore.

[andreia]

👍

[hacfi]

👍 Was always removing it manually

[tvlooy]

👍 super

[anacona16]

-1

I'm agree with @javiereguiluz this is a feature of the Symfony Full Stack Framework, the Symfony components are independents, the full stack require a set of components, assetic is very useful, don't remove it.

[stof]

@anacona16 it will still be possible to use Assetic in your project if it is the way you want. We won't stop maintaining it (at least for now). but instead of being pre-installed when starting a new Symfony project (and forcing you to remove it when you don't want to use, for instance because you use a gulp-based stack), you would just need composer require symfony/assetic-bundle to install it (just like other bundles).

[jzawadzki]

👍

[stof]

Please stop saying +1. The decision has been taken now (this PR has been merged), and each comment triggers emails to many people. A +1 alone does not bring value to them at this point.

[sagikazarmark]

I have various feelings. I am a bit sad that Assetic is removed. Mainly because it is harder to use grunt/gulp/bower/npm instead of pure PHP. But I also understand it, as PHP tools for managing assets are bad quality or not available at all. So moving towards the mainstream way of handling assets seems to be an obvious decision.

[rodrigobb]

It's merged so this is just my point of view.

+1 to remove Assetic and be replaced by recipes in documentation and a list of alternatives (vm agnostic if possible).

But I don't like the possible second intention this movement can include: I think Symfony should remain being a (great) FullStackFramework and not only a server side tool.

[dsteplight]

+1 @stof w/ using Grunt or Gulp.

[psrpinto]

Apologies for hijacking this thread and spamming all of you but I couldn't think of a better place to post this.

For the past couple of months I've been working on a bundle which attempts to bring a modern frontend workflow to Symfony projects. I know this sounds like shameless inflated self-promotion but I would be grateful if you could give it a look.

The bundle allows you generate a tailored gulpfile.js (though the goal is to be asset-pipeline-agnostic) and to reference assets in the templates as you usually do, using the asset() helper, and with automatic cache-busting in production. In addition to that you get other features like livereload, bower integration, etc.

It was designed to be beginner-friendly while not limiting more advanced use cases.

There's still lots of things to do but I think it might already be useful for many people and it would be great to have your inputs on whether there's something to it or if it was a waste of time.

Since this is kind of off-topic, I created psrpinto/frontend-bundle#13 to discuss this so if you have anything to say (I hope you do!) please comment there instead of here.

[The-Don-Himself]

I know I am very, very late to the already committed changes and closed thread but I just wanted to give my 2c nevertheless.

I started coding just a little over a year ago, with an app idea already in mind. I started from bottom, the real bottom. I had no idea of what http headers were, response, in fact, I had never heard of JSON, and had never written one line of PHP code. To a large extent I am still learning, I still make stupid mistakes, open issues that either need not be opened or open them for the wrong package, etc.

After a lot of research, I chose Symfony for a variety of reasons but mainly because I read with the Symfony-Standard and third party bundles, I could be up and running quickly and start to build my app/start-up. Now, after understanding how things work, I have even “composer removed” a few previously installed bundles and rolled out my own code specific to my needs.

The point of the short story here is that, I think its best that the Symfony-Standard mindset should be rapid development and not really best development. I think the ultimate success of a framework is determined by how many people use it and not necessarily how people use it which means converting noobs(well, former noobs) like me to staunch users, advocates and defenders. Removing AsseticBundle in, my view, was a step to making that just a little bit harder. I know you can easily install it but remember, we are not taking about seasoned pros like @stof here, but probably someone who is also being introduced to Composer as well. I concur with @javiereguiluz sentiments here.

Maybe, there could be a step to optionally install [default yes] Assetic when installing the Symfony-Standard?

[Pierstoval]

@The-Don-Himself Yep : install Symfony standard, and then run composer require symfony/assetic-bundle and you're set!

Then, just read AsseticBundle's doc