Hello, I'm an Android developper with < 2 years...

# compose-web

[Nino]

Hello, I'm an Android developper with < 2 years of Compose experience (on Android) and ~15 years of Android Java / Kotlin. I'm familiar with "entry level ops" (I consider myself a "mobile ops", the Gradle and CI are my friends).

I want to develop a small website for a group of friends where we can upload photos, add tags / metadata to them, and browse throught them.

I'd like to code this in Compose obviously. My knowledge of JS / TS is around 1% and I'd like to keep it as low as possible to keep my sanity as high as possible.

Does it look like a plan or am I greatly overestimating my skills? If you have any usefull ressources about hosting images I'll glady read them, there's thousands of solutions but I don't have the experience to know which one fits my needs.

[jw]

You are free to do whatever you want, and I'm a firm believer in building things with what you know rather than what's perceived as more "correct" (whatever that even means)...

HOWEVER!

You can do this with just HTML and zero JS and your site will be faster and more efficient than literally any other option. If you want to leverage your Kotin skills, I would use Ktor for the backend and then producing HTML either from strings, with kotlinx.html, or some kind of template engine.

Using Compose UI for Web will absolutely work, but it will be slow, bulky, and just feel weird.

[Nino]

Thank you for your input!

I'm a huge sucker for "dry" but performant websites but I'd like the website to be at least responsible (I expect most people will upload from their phones), but I doubt I will be able to do so without some kind of JS or JS framework right?

So I was thinking "if I need a framework, at least pick the one I know". The good old saying "everything is a nail if all you have is a hammer" is so true for me. 😞

How slow & bulky will Compose UI for Web will be? What order of magnitude are we speaking about? 10ms, 100ms or seconds?

[Robert Jaros]

Instead of Compose Web, you can try other Compose based frameworks, which can generate efficient HTML instead of drawing on canvas. Check #C04RTD72RQ8 and #C06UAH52PA7 (I'm the author of the latter).

[Robert Jaros]

This could interest you as well: https://github.com/kdomskia/kdomskia

[jw]

Yes, that's a good suggestion. Although you really do not need a client-side framework for this. The original description is basically what HTML was built for 500 years ago at the dawn of the internet.

[jw]

A handful of ktor routes, some string concatenation, and a few `<form>`s and you're like 99% done. Slap on 30 lines of CSS to make it somewhat pretty and it'll scream.

[jw]

All of the actual technical problems are going to be around handling the user uploads on the backend, and those exist regardless how the frontend is built.

[Nino]

Yes that's the big question, the photo selection from the browser. It's not possible with a form, I'll need some JS here for sure?

[jw]

Nope!

[jw]

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/file

[jw]

<input type="file" accept="image/*" multiple />

[Nino]

That's an excellent start, clean and concise. I like it!

I'll build a v1 with pure HTML and try to improve later with another framework (and / or CSS). If at least I could get some Material buttons and stuff, that would be an intermediate ground between complexity (and sanity loss) and "beauty"