Write in JavaScript, Render in Flutter(openkraken.com) |
Write in JavaScript, Render in Flutter(openkraken.com) |
I spent a year looking for a new language in the pandemic and went from Ruby to Typescript, JavaScript, Java, and even a little C# but by such a long margin Dart was my favourite.
More specifically: 1. The Flutter library as a widget toolkit is very intuitive for me. 2. The idiomatic way of extended UI classes through encapsulation is very productive and readable for me. 3. The declarative way in which you configure classes makes other people's code easy to understand. 4. The various methods of doing async lead to many fewer bugs (for me, an average at best coder) than other libraries. 5. It's pretty easy to build an apk and get it on your phone.
All that said, I have never succeeded in getting an iOS build into the store. The build system seems like a house of cards built on top of a house of cards. I know it's possible, but I have never had the patience to power through.
Basically Google hired a bunch of PhD types to design something from the ground up that would run anywhere, compile to native, compile to JavaScript and soon to WASM. It’s fully object oriented but also has first class support for functions and everything that enables.
It has fully sound null safety, the tooling they have around it is also amazing for example code can rewrite itself to update to latest APIs and patterns just by running ‘dart fix’. But it’s a very boring and predictable language that’s easy to use and never really surprises me with quirks.
Also looks like they're going to include static meta-programming, so you can metaprogram at compile time rather than runtime like many languages [0]. With this, many language features can be implemented yourself rather than needing the language maintainers to do so, such as adding dataclasses or (React-like) hooks. And if the state of the art changes, the language won't need to be redesigned or more stuff bolted on, you can just swap out the old language feature (as a package) and swap in the new one.
Are you joking? I don't have any biases for or against dart and understand why they created a new language instead of picking an existing one. But honestly, dart is not a very good language to program in.
Why do you think dart is better than these other languages "by a long margin"?
Take 1: Galaxy Note 3 with Android 5
E/AndroidRuntime(25964): java.lang.RuntimeException: Unable to start activity ComponentInfo{com.example.kraken_gallery/com.example.kraken_gallery.MainActivity}: android.content.res.Resources$NotFoundException: File res/drawable-v21/launch_background.xml from drawable resource ID #0x7f040000
Take 2: Galaxy Note 4 with Android 6
...Yep this is definitely running at about 19-20fps, maybe 23fps. It's not smooth. It's... responsive... I guess? But NOT smooth.
I experience the same effect when in websites that have long scrollable areas inside position:fixed divs or position:absolute divs anchored to the viewport edges.
Chrome seems to be able to special-case "scroll the root/body of the page" in such a way that it can run at like ~45fps on the Note 3 and pretty much the same on the '4. Random divs don't get that special-casing, and scroll rather choppily... exactly like this app.
I tried a Flutter API demo a while back and experienced identical behavior.
My reference case for rendering speed is the Drive PDF viewer (!), which on my Note 3 runs at easily 55-60fps and has just about the lowest latency I can recall of any app I've tried on that device. So I know the hardware can actually update very quickly... if you aren't reconstructing Mt Everest on every frame in the fast path ;)
"BuT DeVeLoPeR PrOdUcTiViTy"
Well, hot take: industrial/brutalist design can be a great fit for the "look" parts of apps... but not the "feel" parts. That always needs to be the result of a feat of integration engineering, for the UX to, well, feel good. All these toolkits break the "look" down into nice little manageable components... by applying isolation principles that also break down the cohesion of the "feel" as well in the process. In the name of progress. Or something.
"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%...
Honestly just curious.
Looking at Kraken contributors, they work for Alibaba, so it seems they host that website in China.
Huh, ok.
Is there an example - I'm not able to find one.
That could be killer!
Flutter uses Skia as the rendering engine - albeit with a different layout engine. JS on Chromium uses Skia.
If you are using JS to talk to Flutter to then talk to Skia, what's the value add? Is it the multithreaded layout engine?
If you are using flutter directly, then you write code in dart (which react and vue do not support). But you can target native app platforms like Mac, windows, iOS, andi etc
If you use kraken, you write code in JavaScript, and can leverage react & Vue and target all flutter supported platforms like iOS, android, windows and Mac OS
"It's a frontend in JS with a rendering engine in Dart/Flutter."
So in goes JS/TS code, writing the familiar frameworks you know, and what does the interpretation/rendering of that code is Flutter and Dart.
This is similar to how React Native works. It consumes a dialect of React and HTML-esque elements, and the renderer turns them into native UI widgets.
---
As far as "Why would I use this?"
If you think that Flutter is a better platform for cross-device UI development than React Native or NativeScript, but you don't actually want to write Flutter/Dart itself. (IE you want to stay in JS-land).
Or you want to build the rest of your codebase in Flutter and Dart code/use it's FFI and interop facilities.
Those are a few reasons I can think of. It's good to have a choice like this available IMO, I won't complain of it.
Seems the docs need a little bit of attention
I'm aware we have plenty of mediocre mainstream languages existing right now, but they all exist for historical reason and have rather useful ecosystems. However, to go out of the way to just make a new lame ass syntax, with zero ecosystem, and no distinguishable characteristic (which is why Flutter is always involved in selling it) why would you do that?
I'm all for new new paradigms, languages that are different like haskell or scala to flourish and teach us new ways of thinking, this is not it.
Perhaps the Drive PDF viewer is fast, but I never liked how it uses RGB subpixel antialiasing on a phone with no fixed pixel layout, to and the GUI felt bare bones to me.
Flutter on iOS has had animation hitches since the switch from OpenGL to Metal. Animations drop frames on their first run, during shader compilation [1].
0. https://gallery.flutter.dev/#/ 1. https://github.com/flutter/flutter/issues/61450
Seriously dude...
Not all consumers live in a place where salaries are high and electronics are cheap.
They were actually given to me by a friend who wasn't using them, who learned I didn't have a phone.
I probably used Android for a cumulative total of 20 minutes from 2006-2020 before this. EXTREMELY interested in the platform, absolutely (and came up with some ideas for apps), but yeah, wasn't really viable to pursue.
Here, have two LifeProTips:
1. Rewrite your DNA during conception to edit out all the weird obscure medical issues you might otherwise get lumped with
2. Ensure you quantum phase-shift when selecting the reality you're born into so you ensure you skip the world(s) with a broken medical systems that doesn't have fundamental interest in research and discovery
Alternatively, spend nearly 30 years trying to get anyone at all to listen, without the resources to pay people to listen to you cuz you can't work.
</rant>
(In all seriousness, the Note 3 takes 10 seconds to open a new tab. I'm absolutely looking forward to upgrading. But it'll be sad to stop using it.)
It also seems not to be high performance either, judging by exikyut's comment.
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.
If you want to do heavy computation, you can easily call `compute()`. Dart VM manages a thread pool for that. A thread can execute multiple isolates though, its not a 1-1 mapping between threads and isolates.
IMHO, it was designed for developer productivity (not just speed of writing code), but JIT + AOT compilation to provide quick development but still fast apps for users, and as you can tell, many developers love it. An existing problem for Flutter is shader compilation jank, but this is being worked on by the Flutter team.
Read "Why did Flutter choose to use Dart?": https://flutter.dev/docs/resources/faq#why-did-flutter-choos...
https://phonedb.net/index.php?m=device&id=6573&c=samsung_sm-...
Can't deny I boggle at current-day budget-level devices with 2GB RAM tho. Like, wat.
Anyway I installed Element and the scrolling feels a lot smoother, at a stable 60? fps without constant hitches like in Flutter apps.
I noticed in Flutter apps there's a process named usap64 that burns CPU on startup and when I scroll through a list.
(I wouldn't stretch to calling nim 'major' but I will say I've found it fascinating so far)
Right now it's less functional than Java, about as much as JavaScript (though in JS classes are less idiomatic so maybe it's a bit more functional in practice).
Considering what people are asking to add to the language (https://github.com/dart-lang/language/blob/master/working/05...), I wish people would start with a minimal functional language (Caml/SML without the modules, so functions, pattern matching and ADTs mostly) and then add things from there. It's a strong basis for a language, and people are going to ask for that stuff later anyways.
During the same time frame of Dart's existence, other languages that actually have innovative ideas were able to carve out their niches (go, rust, ts, kotlin, swift... list goes on), while Dart still has to rely on some UI toolkit to sell.
> Adding web support to Flutter involved implementing Flutter’s core drawing layer on top of standard browser APIs, in addition to compiling Dart to JavaScript, instead of the ARM machine code that is used for mobile applications. Using a combination of DOM, Canvas, and WebAssembly, Flutter can provide a portable, high-quality, and performant user experience across modern browsers.
[0] https://github.com/flutter/flutter/issues/41062#issuecomment...
[1] https://flutter.dev/docs/development/tools/web-renderers