Hacker News Reader

Comment by soneca | Hacker News Reader

Not sure if it is counter-intuitive, but I was deciding between React Native and Flutter for a project and this announcement nudged me to decide on React Native.

I am pretty sure I just want my app to run on Android, iOS, and web. If Flutter's vision is making it possible to also design to TVs, smartwatches, thermostats, doorbells, fridges, etc it means that there will be trade-offs, added complexity, overhead, design choices to support that "ambient computing" vision.

I don't want any of that, and it is good to know that in advance. RN it is.

View on HN

This reads like someone who had already made their mind, and looked for anything to support their prior bias...

For starters, who said RN is not having work done to run on "TVs, smartwatches, thermostats" and so on? Here's a post about work done for smart TVs from the official RN blog:

https://facebook.github.io/react-native/docs/building-for-ap...

Second, who said those concerns aren't orthogonal? Given a good modular design work done for the framework to work on a TV should not impact work done for the framework to play well on the Web or mobile.

Didn't know about the RN build for TV stuff, will do some research to check if they have the same vision. If they do, back to square one.

About your second point, I imagine it could be totally orthogonal. But I am especulating that it won't be. At some point there will be design decisions to be made around trade-offs and I'm sure Google's necessity to push "ambient computing" into the world will prevail over any modularity concerns.

>But I am especulating that it won't be. At some point there will be design decisions to be made around trade-offs and I'm sure Google's necessity to push "ambient computing" into the world will prevail over any modularity concerns.

Or "ambient computing" is just marketing fluff, and in the end it will just be the same typical set of libs, and APIs and tools as in RN and other such frameworks, just with some extra UI widgets and libs for smaller devices.

This seems a little odd, like refusing to use a programming language that's too portable. There are C libraries for various embedded devices you've never heard of, but you don't have to use them.

Flutter is targeting a lot of platforms. Part of this is that Google has a lot of hardware projects that need a UI, and the duplication from building a new UI stack each time was getting tedious.

But this doesn't mean that Flutter apps are doing the same. You can just target the platforms you want. It's not going to run anywhere else if you don't deploy it there.

(Flutter TL here)

FWIW, one of our driving values is to specifically _not_ compromise in this way. We actively avoid having a "lowest common denominator" approach. I learnt about the risks of such an approach when I was the HTML spec editor. It's one of the reasons that we have been only adding new platforms very carefully, and it's why we've been focusing so much on mobile first. The vast majority of the team is focused on mobile, with a small team on Web and an even smaller team (1-4 people depending on how you count it) working on desktop.

I’m a professional plugin developer. I make plugins for Cordova, React Native and Flutter. Flutter is my favorite.

You should do a hello world at least.

Where do you sell Flutter plugins? How do you come up with ideas?

Over 5 years ago, I created a background-geolocation plugin for Cordova. I later ported it to React Native and now flutter. It’s not every plugin that could be monetized. Geolocation, especially in the terminated state, is a special case.

https://github.com/transistorsoft/flutter_background_geoloca...

Background geolocation for iOS / Android is all I do.

Is building plugins faster/easier than building apps (using Flutter)? Looking to learn flutter so wondering if I should build a plugin or app when going beyond hello world.

Build an app. There are many things in the plugin api that you don’t interact with in the app. The plugin api is the bridge between the front-end and native iOS / Android apis.

We specifically evaluated both RN and Flutter in a lot of depth. We ended up going with Flutter and could not be happier. I agree with other commenters, it seems like you had your mind made up because this is a very weak reason to use one over the other.

Reply on news.ycombinator.com