5 ms·

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 th

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.

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.