ConstraintLayout vs "Traditional" Layouts

I'd imagine that the FrameLayout is still a better choice than the ConstraintLayout when there is only one child View.

I think the power of ConstraintLayout really takes place when you go beyond simple layouts. I think the objective (at least for me) is to flatten your complex layout as much as possible. By using the ConstraintLayout's full suite of help such as invisible constraint views like Guideline and Barrier, to specifying vertical/horizontal layout_constraintVertical_bias and view distributions using layout_constraintVertical_chainStyle.

If you have a complex view that has nested ViewGroups, start using ConstraintLayout.

I am personally so accustomed to writing layouts by hand in xml so transitioning to the ConstraintLayout is very hard for me.

This is also true for me. I used to write layout xml files by hand, and i still do with ConstraintLayout. The editor is much improved, and i use it mostly to make sure the constraints look right. There was a bit of lead time to get used to writing the xml by hand, but once you get going, i am a lot more confident with it then the editor adding stuff that you might not be aware of.

Another reason to use ConstraintLayout: A great way to implement animations without too much hand coding by using ConstraintSet. Some great example: https://robinhood.engineering/beautiful-animations-using-android-constraintlayout-eee5b72ecae3

I am just wondering when to choose the CoordinatorLayout over "Traditional" Layouts or are they (or at least some of them) going to be deprecated?

So ConstraintLayout is useful, but (for now) it is not required for Android app development, any more than LinearLayout and RelativeLayout are. And, because ConstraintLayout is a library, you will need to take some additional steps to add it to your project (com.android.support.constraint:constraint-layout artifact in your dependencies closure of your module’s build.gradle file), and it adds ~100KB to the size of your Android app.

I am personally so accustomed to writing layouts by hand in xml so transitioning to the ConstraintLayout is very hard for me.

Drag and drop GUI builder

Google is trying to make life easier to developers and make they work faster and more productive so they continue improving drag-drop GUI builder. However drag-and-drop gestures, the developer is only providing you with X/Y coordinates of a widget, based on where the developer releases the mouse button and completes the drop. With LinearLayout adding widgets is easy. With RelativeLayout is difficult for GUI bulder to handle drag-drop and probably you will have to dig inside the XML code to get things done. ConstraintLayout was created with GUI building in mind, to make it a bit easier to infer the right rules based upon where the developer happens to drop a widget.

Recomputing size and position

Changing the details of a widget often cause the sizes to have to be recomputed. For example nne change in TextView might cause that whole hierarchy to go through re-size/re-position work. If you have container inside container which is inside another container etc., means that parents re-size/re-position their children and that can be very expensive for deep hierarchies. So

Does the ConstraintLayout have better performance then a nested Layout?

Yes, ConstraintLayout is being designed with performance in mind, trying to eliminate as many pass scenarios as possible and by trying to eliminate the need for deeply-nested view hierarchies.

Huh,

for more you can take a look in a book about android development from CommonsWare. There using ConstraintLayout is explained in more details with comparation examples with another containers like LinearLayout, RelativeLayout etc. Really anatomy of android development.

You can continue to use other layouts for simple things (if they are not deprecated), but ConstraintLayout is faster, smarter and yes, have better performance than RelativeLayout.

You can check this answer that talk about differences between ConstraintLayout and RelativeLayout