[SpaghettiX]

As a Flutter developer, "Write in JavaScript, Render in Flutter" is vague.

"Write Flutter apps in Javascript" would make more sense. Flutter is not a "renderer", Flutter is a framework + engine. "Kraken" literally builds widgets for you when you write Javascript code, Flutter is doing a lot more than "rendering".

"Kraken" is like React Native, but instead of talking to the host platform, it uses Flutter. Flutter is already cross platform, so the only benefit here is to write in Javascript. However, you would probably inherit some costs similar to React Native: communication between a Javascript Engine/ interpreter and a AOT compiled application. This time, you don't get to use the react-native-plugin NPM packages, because you'd need kraken-flutter-plugins.

The biggest concern I have is usability. How will I use popular Flutter packages, from Javascript? The "Kraken" community is very small. Even worse, the community seems purely based in China.

It's very difficult to understand the health of the codebase with all these github issues written in Mandarin Chinese: https://github.com/openkraken/kraken/issues?q=is%3Aissue+is%...

[Kiro]

I'm confused. The first sentence on the page is "High-performance web rendering engine", which doesn't sound like "Write Flutter apps in Javascript" at all.

[SpaghettiX]

Exactly, the website is misleading. It's not a rendering engine in any way. That slogan already contradicts the title: "Render in flutter". Is it "rendering using Flutter" or is "rendering it itself"? The answer is you don't render with Flutter at all, Flutter uses Skia for Native (everything except web), and "Kraken" does that again, but purely because it builds a Flutter app.

It also seems not to be high performance either, judging by exikyut's comment.

[jdmg94]

All flutter devs I’ve come across have the mentality that RN is still using the js async bridge to communicate with the native platform, but that’s no longer the case since 2019

[SpaghettiX]

It might be because this "new" behaviour is not documented very well by React Native. Also, the bridge is still here, according to https://reactnative.dev/docs/communication-ios and https://reactnative.dev/docs/native-modules-ios#content

From the second link: > At the moment, we do not recommend using synchronous methods, since calling methods synchronously can have strong performance penalties and introduce threading-related bugs to your native modules.

So in theory they solved the async bridge problem, but in practice it's slower and not recommended by the team itself.

The main reason is javascript itself interpreting your React/ application code, not having an async vs sync bridge. That's why this will remain a problem for React Native.

[SpaghettiX]

I meant "the main problem" when I said "the main reason"