7 ms·

Compose for Web

135 points by farmerbb 5y ago

slimsag 5y ago
So with this, Flutter, and others it seems there is a drive to unify Web/Desktop/Mobile development (the mythical "truly-cross-platform UI") If I understand the code samples here correctly, Compose for Web enables someone to write basically standard HTML/CSS components (in the "React" sense) and the hope is that higher level components wrapping the platform-specific components will be written: > Use and build Compose widgets that work on Android, Desktop, and Web by utilizing Kotlin's expect-actual mechanisms to provide platform-specific implementations While layout will be handled in-house (not via traditional HTML layouts?) > Experiment with a set of layout primitives and APIs that mimic the features you already know from Compose for Desktop and Android This seems a much nicer approach than Flutter's default ("we render everything in a canvas") But can this really pan out? Layout being handled in-house, non-native UI elements on iOS/Android (from what I have read) are strong signals the "higher level components" approach doesn't work in practice
- ex3ndr 5y ago
  You really rarely see native components. Try to take a look at Telegram for iOS - there are zero built-in components: literally everything is rebuilt from scratch - navigation, buttons, toggles, all animations, etc. "Non-native" is not always a bad thing.
  - CharlesW 5y ago
    > "Non-native" is not always a bad thing. Setting aside the non-native look and the non-native feel, one reason it's almost always a bad thing in practice is because developers who re-invent everything rarely match the accessibility support of the native platform.
    - ex3ndr 5y ago
      Sure, if you lazy.
      - ByteJockey 5y ago
        We're all lazy. That's why we got into this profession.
    - KronisLV 5y ago
      I believe that this applies not just to the front-end development, but also the back-end frameworks and libraries. I've seen people attempt to create their own (oftentimes poorly documented and poorly tested, as well as poorly supported) web frameworks even in large projects far too often. It seems that for any project that needs to be supported and maintained for years if not decades, the argument could be extended to: "Non-native and non-standard is usually a bad thing." Of course, there's nothing wrong with using bleeding edge technology and writing your own frameworks and libraries, however that should only be done when and where it makes sense.
  - EvilEy3 5y ago
    Non-native look and non-native toolkit is two different things. You don't need to look native to support accessibility, built-in i18n and L10n, to behave like other native looking applications. But you certainly need to be native to not stick out like a sore thumb.
- pier25 5y ago
  > This seems a much nicer approach than Flutter's default ("we render everything in a canvas") IMO Flutter should have used the DOM for web. Right now it's reimplementing (and shipping) tons of stuff that the browser already solves: layouts, styles, text editing, spellchecking, etc.
  - refulgentis 5y ago
    People sort of miss the point on that imho, as a Flutter dev I don't want compatibility with the DOM, I want my app to look and work the same on the web as it does on iOS as it does on Android
    - pier25 5y ago
      My point is not about DOM compatibility, it's about unnecessarily bloating Flutter web apps.
      - refulgentis 5y ago
        I think Skia is on the order of a megabyte, it'd be nice to skip it, but it's even nicer to ship prototypes that work in the browser and look the same as the 'shipping' version. Changed the way my team works
    - matchbok 5y ago
      I guess, but most people don't care about that stuff. Which is why Flutter is dying :/
      - refulgentis 5y ago
        Flutter isn't dying, not even close, here to stay and increasing share
        shubham_sinha 5y ago
        Flutter won't survive long. The whole point of cross platform dev is to pull better apps with limited resources. An app without backend is nothing. JS is web native language, it will always be easier to code Node JS backend than to code using Dart. 1 indie developer with one skill set can pull off an end to end app. Dart seems to be competing with Javascript only that too in client side dev, totally ignoring JAVA, Kotlin and Swift.
pier25 5y ago
It loaded 2MB (443kB gzip) of JS for that single button.
- jarym 5y ago
  How many real world apps are a 'single button' though? If its a fixed overhead then I'm cool with it for anything more than a contact form.
  - cromwellian 5y ago
    It's not optimized at all, and they say so, so this is really jumping the gun for an alpha tech preview.
goforbg 5y ago
I'm a full time Android dev, who's also a intermediate in web dev. When I first started using compose / flutter, I assumed it was for the best, since I didn't have to learn anything new. I battled myself everyday, whether or not I had to learn React. My views are pretty clear now. React with PWA - For my internal projects. React & Android app with Kotlin - For Products I ship. Ended up learning and liking react! Like pier25 has pointed out, I don't think it's worth loading 2 mb for a single button. So as painful as it maybe to have 3 code bases for 3 platforms, IMO gives the user the best experience.
- cromwellian 5y ago
  I think it'll get optimized. We went from GWT apps needing like 250k to render a HelloWorld, to J2CL + Closure Compiler being able to do the same thing with a 1 line output. Compose has an elegant, theoretically pleasant way of modeling reactive frameworks as pure functions with memoized state, and an explicit call stack. But right now you're paying a giant tax for all this since you bring in the entire Kotlin runtime, coroutines, collections, etc plus the Compose runtime, plus the Widget library. Since Compose is only beta right now, this is clearly unoptimized. It's definitely not eliminating all the dead code or metadata it could, there's a ton of code like this: ``` function(e, t) { e.exports = function(e) { return { name: "Inform 7", aliases: ["i7"], case_insensitive: !0, keywords: { keyword: "thing room person man woman animal container supporter backdrop door scenery open closed locked inside gender is are say understand kind of rule" }, contains: [{ className: "string", begin: '"', end: '"', relevance: 0, contains: [{ className: "subst", begin: "\\[", end: "\\]" }] }, { className: "section", begin: /^(Volume|Book|Part|Chapter|Section|Table)\b/, end: "$" }, { begin: /^(Check|Carry out|Report|Instead of|To|Rule|When|Before|After)\b/, end: ":", contains: [{ begin: "\$This", end: "\$" }] }, { className: "comment", begin: "\\[", end: "\\]", contains: ["self"] }] } } } ``` Which looks like some kind of parser embedded in it.
sonograph 5y ago
I'm not sure I understand. Is this essentially a cross-platform tool, like Electron?
- nsonha 5y ago
  no it's not a target, it's an UI toolkit that enables multi targets (including Electron) app development. More like React.
- brabel 5y ago
  No, this is a cross-platform UI kit which is aiming to target mobile, desktop and web. Similar frameworks I know of include Flutter, Sciter and React Native.
benatkin 5y ago
I'm surprised Kotlin has a Slack instead of a Discord. The biggest React, Vue, Svelte, and Deno communities are on Discord.
- chimen 5y ago
  yeah, I'm also surprised they didn't rewrite everything in Rust /s
- nsonha 5y ago
  who cares, they are all places for noise, actual meaningful conversation happens on github
- IceWreck 5y ago
  Both are proprietary platforms so I'd rather they be somewhere else.
cromwellian 5y ago
Right at the top: "With its current status Technology Preview, Compose for Web is not production-ready, and should only be used in experiments. We are hard at work to bring you great learning materials, tutorials, and documentation, and optimize the performance of Compose for Web in the future!" And yet people already rushing to conclusions about code size.
- andy_ppp 5y ago
  If you start badly it’s likely to get worse over time, not better.
  - andrewingram 5y ago
    I don't think that's a foregone conclusion. It largely comes down to your decision-making principles. "Make it work, make it right, make it fast", for one.
    - andy_ppp 5y ago
      I think both things are true but you can’t expect to do that over a whole codebase; you have to do it feature by feature as you build them or you’ll literally be fixing issues forever.
c-smile 5y ago
Is there anything that describes architecture of the verb? Like https://quark.sciter.com/ https://quark.sciter.com/ or something ... My guess: it is a JavaVM combined with CEF(WebKit) to achieve actually what?
- ptx 5y ago
  The Kotlin compiler has multiple backends and can target JS and native code (the latter via LLVM) in addition to JVM bytecode.
pjmlp 5y ago
It is so ironic to see the politics from Android related teams against the Flutter uptake. Bringing Compose to every platform Flutter is targeting, just in case.
lewisjoe 5y ago
This looks a good first step. But what is the iOS story of jetpack-compose? It's non-existent. Right now, there's only one single-codebase solution to render to android, ios, mac, linux, windows and the web - and that is Flutter. But Flutter choosing Dart is more of an "easier to control the roadmap" strategy than the bs they actually put up on their FAQ I'd really like a Flutter like framework (that renders to it's own widgets) but with kotlin as the framework language and it isn't impossible to make. I don't see Google making it, as it conflicts with Flutter. Would like to see a developer oriented company like Jetpack and the open source community, make a push for a truly Flutter alternative.
- stewartmcgown 5y ago
  React Native runs on all those platforms too.
- nsonha 5y ago
  > ...only one React Native, NativeScript, Xamarin
- thecupisblue 5y ago
  Working on it right now, we're in stealth but going public in a few months, working on language support for modern editors, previews and our own editor right now! It's a unified solution that gives developers more freedom of choice, with some versions of it already battle tested in large production apps. If you're up for it, I would love to be able to email you when we release the public version or maybe even earlier.
- deergomoo 5y ago
  > that renders to it's own widgets I've always felt this to be a net negative, and it puts me off Flutter more than anything else. I know it has no bearing on the app developer or the end user, but there's something about pouring thousands of person-hours into making a facsimile of something that already exists (especially something that has already had thousands of person-hours put into usability and accessibility) that feels so wasteful. It's silly I know, but it just doesn't sit right with me.
- 5y ago
grodes 5y ago
shit

135 points by farmerbb 5y ago

So with this, Flutter, and others it seems there is a drive to unify Web/Desktop/Mobile development (the mythical "truly-cross-platform UI") If I understand the code samples here correctly, Compose for Web enables someone to write basically standard HTML/CSS components (in the "React" sense) and the hope is that higher level components wrapping the platform-specific components will be written: > Use and build Compose widgets that work on Android, Desktop, and Web by utilizing Kotlin's expect-actual mechanisms to provide platform-specific implementations While layout will be handled in-house (not via traditional HTML layouts?) > Experiment with a set of layout primitives and APIs that mimic the features you already know from Compose for Desktop and Android This seems a much nicer approach than Flutter's default ("we render everything in a canvas") But can this really pan out? Layout being handled in-house, non-native UI elements on iOS/Android (from what I have read) are strong signals the "higher level components" approach doesn't work in practice

ex3ndr 5y ago
You really rarely see native components. Try to take a look at Telegram for iOS - there are zero built-in components: literally everything is rebuilt from scratch - navigation, buttons, toggles, all animations, etc. "Non-native" is not always a bad thing.
- CharlesW 5y ago
  > "Non-native" is not always a bad thing. Setting aside the non-native look and the non-native feel, one reason it's almost always a bad thing in practice is because developers who re-invent everything rarely match the accessibility support of the native platform.
  - ex3ndr 5y ago
    Sure, if you lazy.
    - ByteJockey 5y ago
      We're all lazy. That's why we got into this profession.
  - KronisLV 5y ago
    I believe that this applies not just to the front-end development, but also the back-end frameworks and libraries. I've seen people attempt to create their own (oftentimes poorly documented and poorly tested, as well as poorly supported) web frameworks even in large projects far too often. It seems that for any project that needs to be supported and maintained for years if not decades, the argument could be extended to: "Non-native and non-standard is usually a bad thing." Of course, there's nothing wrong with using bleeding edge technology and writing your own frameworks and libraries, however that should only be done when and where it makes sense.
- EvilEy3 5y ago
  Non-native look and non-native toolkit is two different things. You don't need to look native to support accessibility, built-in i18n and L10n, to behave like other native looking applications. But you certainly need to be native to not stick out like a sore thumb.
pier25 5y ago
> This seems a much nicer approach than Flutter's default ("we render everything in a canvas") IMO Flutter should have used the DOM for web. Right now it's reimplementing (and shipping) tons of stuff that the browser already solves: layouts, styles, text editing, spellchecking, etc.
- refulgentis 5y ago
  People sort of miss the point on that imho, as a Flutter dev I don't want compatibility with the DOM, I want my app to look and work the same on the web as it does on iOS as it does on Android
  - pier25 5y ago
    My point is not about DOM compatibility, it's about unnecessarily bloating Flutter web apps.
    - refulgentis 5y ago
      I think Skia is on the order of a megabyte, it'd be nice to skip it, but it's even nicer to ship prototypes that work in the browser and look the same as the 'shipping' version. Changed the way my team works
  - matchbok 5y ago
    I guess, but most people don't care about that stuff. Which is why Flutter is dying :/
    - refulgentis 5y ago
      Flutter isn't dying, not even close, here to stay and increasing share
      - shubham_sinha 5y ago
        Flutter won't survive long. The whole point of cross platform dev is to pull better apps with limited resources. An app without backend is nothing. JS is web native language, it will always be easier to code Node JS backend than to code using Dart. 1 indie developer with one skill set can pull off an end to end app. Dart seems to be competing with Javascript only that too in client side dev, totally ignoring JAVA, Kotlin and Swift.

pier25 5y ago

It loaded 2MB (443kB gzip) of JS for that single button.

jarym 5y ago
How many real world apps are a 'single button' though? If its a fixed overhead then I'm cool with it for anything more than a contact form.
- cromwellian 5y ago
  It's not optimized at all, and they say so, so this is really jumping the gun for an alpha tech preview.

goforbg 5y ago

I'm a full time Android dev, who's also a intermediate in web dev. When I first started using compose / flutter, I assumed it was for the best, since I didn't have to learn anything new. I battled myself everyday, whether or not I had to learn React. My views are pretty clear now. React with PWA - For my internal projects. React & Android app with Kotlin - For Products I ship. Ended up learning and liking react! Like pier25 has pointed out, I don't think it's worth loading 2 mb for a single button. So as painful as it maybe to have 3 code bases for 3 platforms, IMO gives the user the best experience.

cromwellian 5y ago
I think it'll get optimized. We went from GWT apps needing like 250k to render a HelloWorld, to J2CL + Closure Compiler being able to do the same thing with a 1 line output. Compose has an elegant, theoretically pleasant way of modeling reactive frameworks as pure functions with memoized state, and an explicit call stack. But right now you're paying a giant tax for all this since you bring in the entire Kotlin runtime, coroutines, collections, etc plus the Compose runtime, plus the Widget library. Since Compose is only beta right now, this is clearly unoptimized. It's definitely not eliminating all the dead code or metadata it could, there's a ton of code like this: ``` function(e, t) { e.exports = function(e) { return { name: "Inform 7", aliases: ["i7"], case_insensitive: !0, keywords: { keyword: "thing room person man woman animal container supporter backdrop door scenery open closed locked inside gender is are say understand kind of rule" }, contains: [{ className: "string", begin: '"', end: '"', relevance: 0, contains: [{ className: "subst", begin: "\\[", end: "\\]" }] }, { className: "section", begin: /^(Volume|Book|Part|Chapter|Section|Table)\b/, end: "$" }, { begin: /^(Check|Carry out|Report|Instead of|To|Rule|When|Before|After)\b/, end: ":", contains: [{ begin: "\$This", end: "\$" }] }, { className: "comment", begin: "\\[", end: "\\]", contains: ["self"] }] } } } ``` Which looks like some kind of parser embedded in it.

sonograph 5y ago

I'm not sure I understand. Is this essentially a cross-platform tool, like Electron?

nsonha 5y ago
no it's not a target, it's an UI toolkit that enables multi targets (including Electron) app development. More like React.
brabel 5y ago
No, this is a cross-platform UI kit which is aiming to target mobile, desktop and web. Similar frameworks I know of include Flutter, Sciter and React Native.

benatkin 5y ago

I'm surprised Kotlin has a Slack instead of a Discord. The biggest React, Vue, Svelte, and Deno communities are on Discord.

chimen 5y ago
yeah, I'm also surprised they didn't rewrite everything in Rust /s
nsonha 5y ago
who cares, they are all places for noise, actual meaningful conversation happens on github
IceWreck 5y ago
Both are proprietary platforms so I'd rather they be somewhere else.

cromwellian 5y ago

Right at the top: "With its current status Technology Preview, Compose for Web is not production-ready, and should only be used in experiments. We are hard at work to bring you great learning materials, tutorials, and documentation, and optimize the performance of Compose for Web in the future!" And yet people already rushing to conclusions about code size.

andy_ppp 5y ago
If you start badly it’s likely to get worse over time, not better.
- andrewingram 5y ago
  I don't think that's a foregone conclusion. It largely comes down to your decision-making principles. "Make it work, make it right, make it fast", for one.
  - andy_ppp 5y ago
    I think both things are true but you can’t expect to do that over a whole codebase; you have to do it feature by feature as you build them or you’ll literally be fixing issues forever.

c-smile 5y ago

Is there anything that describes architecture of the verb? Like https://quark.sciter.com/ https://quark.sciter.com/ or something ... My guess: it is a JavaVM combined with CEF(WebKit) to achieve actually what?

ptx 5y ago
The Kotlin compiler has multiple backends and can target JS and native code (the latter via LLVM) in addition to JVM bytecode.

pjmlp 5y ago

It is so ironic to see the politics from Android related teams against the Flutter uptake. Bringing Compose to every platform Flutter is targeting, just in case.

lewisjoe 5y ago

This looks a good first step. But what is the iOS story of jetpack-compose? It's non-existent. Right now, there's only one single-codebase solution to render to android, ios, mac, linux, windows and the web - and that is Flutter. But Flutter choosing Dart is more of an "easier to control the roadmap" strategy than the bs they actually put up on their FAQ I'd really like a Flutter like framework (that renders to it's own widgets) but with kotlin as the framework language and it isn't impossible to make. I don't see Google making it, as it conflicts with Flutter. Would like to see a developer oriented company like Jetpack and the open source community, make a push for a truly Flutter alternative.

stewartmcgown 5y ago
React Native runs on all those platforms too.
nsonha 5y ago
> ...only one React Native, NativeScript, Xamarin
thecupisblue 5y ago
Working on it right now, we're in stealth but going public in a few months, working on language support for modern editors, previews and our own editor right now! It's a unified solution that gives developers more freedom of choice, with some versions of it already battle tested in large production apps. If you're up for it, I would love to be able to email you when we release the public version or maybe even earlier.
deergomoo 5y ago
> that renders to it's own widgets I've always felt this to be a net negative, and it puts me off Flutter more than anything else. I know it has no bearing on the app developer or the end user, but there's something about pouring thousands of person-hours into making a facsimile of something that already exists (especially something that has already had thousands of person-hours put into usability and accessibility) that feels so wasteful. It's silly I know, but it just doesn't sit right with me.
5y ago

grodes 5y ago

shit