4 ms·

Personally I’d much rather work with Flutter than RN. The tooling and general developer experience I find to be far superior. But of course the primary advanta

Personally I’d much rather work with Flutter than RN. The tooling and general developer experience I find to be far superior. But of course the primary advantage of RN is the ecosystem of developers and libraries it comes with, so if those are important to you I don’t believe Flutter will catch up any time soon. Personally I think those are a bit overrated. Any competent JS developer could pick up Dart very quickly, and all the various bits of browser knowledge a front end developer would have that are more valuable wouldn’t be applicable here, so to me “used before” only offers rather modest gains, and over the long run isn’t much to base a decision on.

sgt 4y ago
Flutter/Dart is amazing and it's OK to have fewer libraries. The JS ecosystem is varying in quality (much more so than the Dart ecosystem, in my experience). What I would not use Flutter for yet is Flutter Web. I've made that mistake, and although it was a big success in the end, we had many many hurdles, some of which are serious bugs that remain to this day (like you can't autofocus a field, flickering, extremely slow scrolling, etc).
- mhoad 4y ago
  I’m really waiting for WebGPU and WASM with garbage collection to land in the browser across the board. I think both of those technologies are going to be key to unlocking a the power of Flutter web.
  - sgt 4y ago
    Yes, I agree. Interesting times ahead, but it will likely take 2-3 years.
    - mhoad 4y ago
      Agreed, this is also my timeline for Flutter web becoming a more serious contender. There are one or two other technologies/ standards that are an important piece of the puzzle like the accessibility object model to start to decouple accessibility from the rendered DOM interface for example and allow canvas based interfaces to become better supported. But I follow a lot of that stuff pretty closely and 2-3 years seems like more than enough time, a bunch of it is probably slated to happen as early as this year (WebGPU behind a flag already on all browsers I believe, WasmGC under active development in all browsers, dart already has a functional WASM compiler and a new graphics engine ready to go and take advantage of it etc..) Some basic details here for anyone interested in this topic https://youtu.be/kCnYRhkfWHY https://youtu.be/kCnYRhkfWHY
meego 4y ago
Actually, since the RN team unbundled RN and handed maintenance of non-core libraries (e.g. filesystem, keychain, gestures...) to community maintainers, a lot of these libraries have lacked maintenance, and could really use more maintainer time. The following example comes to mind. react-native-fs is the most popular lib for filesystem I/O. From Android 10's release in Sep 2019 until Feb 2022, all file overwrite operations on Android 10 and later would result in the file getting corrupted if the new file was smaller than the pre-existing one. Related issue: https://github.com/itinance/react-native-fs/pull/890 https://github.com/itinance/react-native-fs/pull/890 That's a very long 2 year and a half. My intuition to explain this situation is that the intersection of these two is very small: - orgs using RN, and thus willing to maintain it - orgs staffed with experienced Java/Kotlin or ObjC/Swift developers with the good understanding of native Android/iOS APIs needed to maintain RN libraries

sgt 4y ago

Flutter/Dart is amazing and it's OK to have fewer libraries. The JS ecosystem is varying in quality (much more so than the Dart ecosystem, in my experience). What I would not use Flutter for yet is Flutter Web. I've made that mistake, and although it was a big success in the end, we had many many hurdles, some of which are serious bugs that remain to this day (like you can't autofocus a field, flickering, extremely slow scrolling, etc).

mhoad 4y ago
I’m really waiting for WebGPU and WASM with garbage collection to land in the browser across the board. I think both of those technologies are going to be key to unlocking a the power of Flutter web.
- sgt 4y ago
  Yes, I agree. Interesting times ahead, but it will likely take 2-3 years.
  - mhoad 4y ago
    Agreed, this is also my timeline for Flutter web becoming a more serious contender. There are one or two other technologies/ standards that are an important piece of the puzzle like the accessibility object model to start to decouple accessibility from the rendered DOM interface for example and allow canvas based interfaces to become better supported. But I follow a lot of that stuff pretty closely and 2-3 years seems like more than enough time, a bunch of it is probably slated to happen as early as this year (WebGPU behind a flag already on all browsers I believe, WasmGC under active development in all browsers, dart already has a functional WASM compiler and a new graphics engine ready to go and take advantage of it etc..) Some basic details here for anyone interested in this topic https://youtu.be/kCnYRhkfWHY https://youtu.be/kCnYRhkfWHY

meego 4y ago

Actually, since the RN team unbundled RN and handed maintenance of non-core libraries (e.g. filesystem, keychain, gestures...) to community maintainers, a lot of these libraries have lacked maintenance, and could really use more maintainer time. The following example comes to mind. react-native-fs is the most popular lib for filesystem I/O. From Android 10's release in Sep 2019 until Feb 2022, all file overwrite operations on Android 10 and later would result in the file getting corrupted if the new file was smaller than the pre-existing one. Related issue: https://github.com/itinance/react-native-fs/pull/890 https://github.com/itinance/react-native-fs/pull/890 That's a very long 2 year and a half. My intuition to explain this situation is that the intersection of these two is very small: - orgs using RN, and thus willing to maintain it - orgs staffed with experienced Java/Kotlin or ObjC/Swift developers with the good understanding of native Android/iOS APIs needed to maintain RN libraries