Pros & Cons using Flex-Layout

[MarcusMorba]

Bug, feature request, or proposal:

At the moment for the development within an Angular 4 environment with Angular 2 dependencies me and my coding team have some different opinions regarding the use of flex-layout.
While I am in favor of using it they think it is better to use custom Markup/CSS or another Framework.

Their main cons are:

• inline styles are hard to overwrite
• the performance and frontend rendering is slower than just using CSS without JS
• Angular 4 sticks to Beta 10/11 and is not upgradeable

Are there any comparisons regarding frontend performance available?

What is the expected behavior?

Flex-Layout makes the crossbrowser development easier and still offers best performance compared to other solutions, especially for people with less flexbox, html & css know-how. Good integration with Angular.

What is the current behavior?

Flex-Layout has still issues in general and the additional JS-Layer may reduce performance of complex applications.

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

Angular 4, Flex-Layout Beta 10/11, All Browsers - especially targeted are IE 11, FF52.3esr.

Is there anything else we should know?

Give some feedback to the above mentioned cons. Thanks.

[intellix]

Also having the same conversation with developers on the team. FlexLayout was used throughout by me, but now everyone is going through and moving them to CSS.
Their reasoning is that CSS is easier to override and the styles written are easier to read as well.

One of the claims is that FlexLayout helps with cross-browser issues but to be honest I've not witnessed any and all the x-browser bugs are still open, so it seems like it doesn't really do anything in that regard.

Another:

• inline styles make debugging hard to read cause your code is just a huge block of them

[CaerusKaru]

I love this question, because it gets at the core of what we're doing/planning in Flex Layout. I have good news and bad news for your concerns, and please let me know if you need more clarification. As OSS, we really try to make sure that our library is useful for everyone, but we understand that it's not going to be for everyone. Don't worry, our egos can handle that 😉.

• We understand that inline styles cause clutter. This was not the intention. The original design had it this way for several reasons. 1) Inline styles have the most specificity, so for beginning developers, it ensures that the styles don't conflict with existing styles and confuse the resulting layout (ie there's an existing max-width that prevents the flex layout from rendering as expected by the beginning dev). 2) Managing dynamic stylings in a class-based approach is not ideal (and still isn't) because of limitations in the framework

  • This is something we're actively investigating, namely in Inline Styles clutter dev tools for HTML Inspection #632. If/when we were to do it, I could see it as a static method on the module, something like FlexLayoutModule.withClasses() so as to not compromise the goals of 1) above

• Performance is also an issue that we're aware of, but with a JS approach, it's something we can't really avoid. I call it directive drag, but I'm sure there's a more technical term for it. This is something else that we're investigating, but the support to handle this likely won't be available in Angular Core until v7 at the earliest. In the meantime, it's hard to beat a CSS-only approach to Flexbox simply because there is no JS to load

• Flex Layout is still in beta, so it can't and won't support older versions of Angular. We understand that Angular itself has LTS for v4 until the end of Q3 this year, but it's policy on the team that we can't have LTS while in beta. We make too many breaking changes too quickly for us to backport everything to a lower version. We understand this is a dealbreaker for a lot of people, but it'll make the day that we can offer LTS that much sweeter

Now to address some of the things Flex Layout offers that can't be matched in a CSS-only approach (or at least not easily).

• Dynamic stylings simply can't be done without some sort of JavaScript. They just can't. Plugging in to Angular's change detection system allows developers to take advantage of and control how changes are applied to their templates, and Flex Layout rolls right along with that

• We offer other utilities for helping detect layout changes by plugging in to the MediaQuery engine directly. While this isn't a template directive, it's still a very useful part of the library

• Flex Layout compartmentalizes the intention of Flexbox styles into easy-to-read directives. It's easier to simply read through a template and see fxFlex than to see a reference to a class that may/may not contain flex stylings (sure, there are ways around this, but it leads to CSS fatigue like in the original AngularJS Material Layout). This makes the code cleaner, and easier to reason about, and also easier to pass along to other team members

• As you mentioned, we offer excellent cross-browser support. While a few of these fixes are pending, namely some IE/Safari fixes in fix(fxFlex): fix non-wrapping behavior and default fxFlex value #669, the Flex Layout library captures a lot of weird behaviors (most documented in https://github.com/philipwalton/flexbugs) and preserves the intention of the directives. This is especially useful in handling column layouts in IE11, or wrapping behavior in Safari, etc. Not only that, but we are committed to supporting these browsers in the future should issues come up, instead of forcing you to debug Flexbox CSS, which can be a pain

I'd love to hear more from the community about these issues, we shape a lot of our design plan on community engagement/feedback (ie the CDK integration). If anyone has any further comments/concerns, please feel free to post them below.

I'm also sure @ThomasBurleson might have some things to add, so I'll see if he wants to comment as well.

[matpag]

I've a concern.

Should we really trust this project?
Because you are the only one actively working on it, we never seen a release cut without the "-beta" part on its name and in the past releases were far away to each other.
Will this project exit the beta phase with Angular v6 once and for all?

[CaerusKaru]

@matpag While it's true that Flex Layout is a small project, @ThomasBurleson are actively working on it with support from the rest of the Material team. So yes, you can trust us 😄.

The reason for the perpetual beta stage of the project is because a lot of the functionality of the project has yet to be finalized. As you may have noticed over the past few weeks, we've introduced a ton of breaking changes between betas. Not to mention the changes we have in the pipeline (switching to the CDK layout engine for one), most of which are going to have to wait until the Ivy renderer has been completed (which will be well past v6).

While the functionality of many of the core directives remains stable, we are still tweaking them and trying to improve them. And then there are the performance hits from using a directive-based layout library that we hope to resolve when the Ivy renderer comes out.

We understand the frustration/turn-off of using a project still in beta, but it gives us the flexibility to improve the project at a faster pace for now while we work out what the "stable" version of the library will look like. We'll hopefully have more updates on this over the next few months as Ivy is finalized and we can settle on a design.

[matpag]

Thanks for your reply :)

It's all clear now 👍

[MarcusMorba]

Thanks to all for the great feedback and help. This really helped us planning and also to convince my co-workers and management to keep Flex-Layout and also do the major updates to Angular 5 or 6.

[patrickmichalina]

The more I used it, the more I realized its better to just use css as long as you are judicious about your cascade. For devs without as much experience stying, flex-layout is pretty cool. Also, as with most of the libraries right now, there are some hiccups when rendering from the server.

[kamok]

@intellix I agree that there are some .html files in my app that is a monster. But those can be solved if you take advantage of componentization more. The only real monster in my app is one with 20 form fields, but they are uniformed and collapsable in my text editor.

Angular Flex simply structures where my components will be placed, (columns and rows).

@patrickmichalina It does help me more than using css for flex. I do understand flex more, and I feel that sometimes flex via css doesn't quite do what I want. flex-layout will always do what I want it to do.

[CaerusKaru]

Closing since it seems like this thread has served its purpose. When the new docs site goes live, I'll most likely pull some of the salient points from here and put it in one easy-to-find place.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}