<https://blog.karumi.com/android-jetpack-compose-r...

# feed

[sergio250]

https://blog.karumi.com/android-jetpack-compose-review/

[altavir]

We are currently having warmed up discussion in Russian chat and there are different opinions on that. Most android developers are happy. But I was not developing on android for a long time and for me syntax looks terrible. Why function calls with capital letter? Why do not use explicit receivers for composable functions? Currently it looks like a lot of classes with side-effects in constructors. There are existing frameworks like tornadofx. Why not to do something similar?

[sergio250]

Those were exactly our thoughts, I remember reading somewhere (a thread in #compose IIRC) they did it to avoid people getting confused but I think they are just doing the opposite

[sergio250]

https://kotlinlang.slack.com/archives/CJLTWPH7S/p1557694005038900?thread_ts=1557692868.034500&amp;cid=CJLTWPH7S

[altavir]

I think that they tried to clone Flutter grammar. I really hope, that there will be normal kotlin-friendly interface for that.

[gildor]

They don’t try to clone Flutter grammar, it was many rationale and insights in #compose why they decided to use this syntax, they switch just recently, before it was closed to JSX

[sergio250]

I wish they were more open to explain those before but yeah, there are some good reasons in #compose why they did it like that

[altavir]

Well, it is definitely better than JSX, but I hope, it will move further toward kotlin dsl style.

[gildor]

There is no DSL in compose, it’s not how it works

[altavir]

I understand. But in my opinion it should look like dsl.

[gildor]

Do you have any particular example what do you expect? all suggestions about other syntax that proposed in #compose actually do not work

[gildor]

Why something that is not DSL should look like DSL?

[gildor]

There is no receiver, no blocks, it’s composition of functions

[gildor]

It’s just different approach.
For example check this thread:
https://kotlinlang.slack.com/archives/CJLTWPH7S/p1558480278211900

[altavir]

Yeah, but scope does not necessary mean receiver. It could be just that - scope with functions

[gildor]

So how you add arbitrary function to this scope?

[altavir]

By extending it obviously

[gildor]

do you expect that each componetnt should be extension function explicitly?
Like fun ComponentContext.TextView()?

[altavir]

Yes. That is what I expect when I see the syntax

[gildor]

See this discussion with rationale about extensions syntax:
https://kotlinlang.slack.com/archives/CJLTWPH7S/p1558440714121300

[altavir]

Thanks, I will read it

[altavir]

This is all about lack of multi receivers then. Well, you know, where I stand about it. Starting functions with capital letter still looking terrible for me. It is habit of course, but one hard to kill.

[gildor]

I wish they were more open to explain those before

@sergio250 Isn’t they are super opened? They explain each decision to anyone who has a particular question, even if a few people see the answer in some old thread in compose channel of semi-closed slack, they working on blog posts to explain to wider list of developers their plans and decisions, evaluate every proposal and they have a lot of things to do instead of explain anyone even basic things that you can find in existing samples, and so many do not appreciate their effort (“Compose sucks”) and expect full blown documentation and explanations of 1 year of research right now and writing hype blog posts with ridiculous opinions even do not figure out how it actually works now and I feel bad about Compose Team in this situation when they so opened and ready to discuss

[gildor]

This is all about lack of multi receivers then.

@altavir Yes it would make decision different, but it’s just a proposal, they cannot hold project just because some language feature is not there and even not confirmed and do not have proper design

Starting functions with capital letter still looking terrible for me

Like many builder functions, even kotlin stdlib, but I agree, case there is different..
It’s just current convention tho, but I see reasons there, it will look like View declarations, and works well with existing views interop

[altavir]

I think the main annoying point are those capital letters. It is not critical in the grand scheme of things but I think that it just produce wrong impression for kotlin-oriented guys. It seems like either they've came from .Net or indeed put logic inside constructors. With small letters it becomes much more understandable for regular kotliner.

[gildor]

.> main annoying point are those capital letters.
Honestly looks as super minor for me, at least on this stage

[sergio250]

Don’t get me wrong, I think the library has a bright future and the people behind it sure has put a lot of work into it and as a small open source lib maintainer myself I truly value what they are achieving.

It just sounds confusing that in the IO talk, Google told devs to go and try compose and give them feedback about it to find out that the library has a lot of features and docs missing, from testing to lifecycle and holding state for components, that’s still not possible. I think the blogpost already makes it clear that we understand the effort and the potential of such tool.

I can see how it all comes from a communication issue, that’s what I was trying to say.

[gildor]

I think there is no difference between:

Row {
   Text("Title")
   WebView(url = url)
}

and

row {
  text("Title")
  WebVeiew(url = url) // this is Android Framework view, not composable
}

[gildor]

from testing to lifecycle

@sergio250 Exactly! This is available and was mentioned on the only talk about compose on IO, they had example on one of slides

> a lot of features and docs missing
This also was mentioned in talk, that many features are not there, it’s just a preview, not an alpha

[gildor]

holding state for components

It’s also possible and mentioned, but in a different way

[altavir]

It of course depends on your habits. My problem is that it looks as either non-kotlin or badly written kotlin (not that is is bad, it just looks so). In this particular case, I still think that the difference is quite important. For example, you see composable functions and their difference from non-composable object. Non-composable function looks really out of place, it also should be a function, but it is not.

[gildor]

I think there are double standards and huge level hypocrisy to apply such requirements not even to alpha version of a library, just to preview shared with other to get opions and participate in development from 99.9999% of developers who do not apply those requirements for own work even for release project

[altavir]

I think the idea to publish early preview is good. So we can have such discussions

[gildor]

But they don’t have docs!!!

[altavir]

It is OK, I do not have them as well 🙂

[gildor]

oh my god! no full docs! And annotations are there and they not needed! (obviously, because I even don’t know how compose work)

[altavir]

And a little disclaimer, I do not work on Andoroid right now, so my interest is only from language design point of view.

[altavir]

I think that the agitation right now comes from the fear of new Spring or JSX. I am sure that if google guys are reasonable, some good solution will be found in future

[gildor]

I think the blogpost already makes it clear that we understand the effort and the potential of such tool

Yes, mentions this once and also a lot of loud opinions without proper understanding or attempt to figureout some questions before publishing the article, especially when you can ask any question to any of authors of the library

[sergio250]

I also think it’s great we can have these discussions! That’s why I like the blogpost, because it brought together some really interesting insights about how compose work from the authors themselves

[gildor]

yes, publishing tech article with a lot of wrong opinions, assumptions and mistakes and complaining in #compose because everyone from compose team tells him that he’s wrong and that it’s not his fault. but fault of documentation

[gildor]

Sorry to be triggered so much

[gildor]

but I really read too many bad articles, tweets and chats about compose and people now have opinions about huge project in early stage so fast, just because of one single thing that they don’t like and usually also do not understand

[sergio250]

No prob Andrey, I get your point

[gildor]

language design point of view

@altavir I think from the language design point, the biggest thing is that it pushes compiler plugin API a lot, so we probably get it sooner now

[altavir]

Well, we definitely are waiting for this one. For multi-receivers too.

[sergio250]

I just think making questions and bringing potential pain points to the table is a good thing in the end. Saying that maybe the project is lacking some documentation, while reasonable, is also correct, and a form of feedback I personally would appreciate but I guess that’s where we disagree

[gildor]

Multi-receivers is nice, but I really think that it’s not even close a blocker for compose, you always can introduce additional explicit syntax if there are some reasons for this.

[gildor]

maybe the project is lacking some documentation

of course, they have some documentation during early stage of development, it’s already nice, also as they said, they will work on blog posts to explain how it works under the hood and to explain some decisions

[altavir]

Yes, it could be avoided. But, you yourself gave the link about the design decision. And the lack of multi-receiver is the main reason for unscoped composable functions

[gildor]

and a form of feedback

I believe that loudly publishing article without enough research is not feedback

[gildor]

It’s one of the reasons

[gildor]

but with current design it’s not clear for me how receiver would be much better

[gildor]

also using member extension functions is really clunky, even with 1 receiver and with

[gildor]

unscoped composable functions

Why do you think it’s bad? it’s really similar to suspend functions

[altavir]

Well, I did not really look at it from suspend angle. It makes some sense. Still, most suspend functions are currently launched inside the CoroutineScope, thus limiting the visibility of inner functions and enforcing correct structure.

[gildor]

most suspend functions are currently launched inside the CoroutineScope

But suspend function itself has nothing to do with CoroutineScope, it’s for background jobs, you can call suspend function from another suspend function and they share context and have context of parent suspend function, exactly the same what Compose component does

[altavir]

But you can't just run suspend function from the plain code. It does have implicit parameter, so I agree that it is similar to composable idea

[gildor]

But you can’t just run suspend function from the plain code

You can do this from another suspend function and you have primitves to create suspend lambda from the plain code, and stdlib even do not have concept of CoroutineScope, it’s an abstraction for launching coroutines in background

[gildor]

suspendCoroutine (and more high-level runBlocking) are things that can be called from the plain code and create suspend lambda

[altavir]

Yep, but in coroutines you have coroutine primitives and builder functions. You can use builders or, if you are competent, use primitives. Mostly everything works on a library level. Compiler has only basic support for suspends. Compose seems to hide everything in the compiler plugin.

[gildor]

hide everything in the compiler plugin

it hides composition in the compiler plugin (same as suspend function continuation in the compiler) and tree diffing mechanism, but all rendering code is also just library, not a part of compiler plugin

[gildor]

and it mentioned already, that MPP and other use cases will be possible (tho not necessary will be provided by composer team)

[gildor]

it needed not only for MPP, but also for testing, support of preview etc, so no, not everything is part of the compiler plugin, only necessray parts, and those parts know nothing about Android, Ui or rendering