Write in JavaScript, Render in Flutter(openkraken.com)
openkraken.com
Write in JavaScript, Render in Flutter
https://openkraken.com/en-US
82 comments
Any particular reason you like Dart so much? I tried it briefly, and it felt like a watered-down mashup of Java and C# with somewhat worse performance.
A few things stood out to me and I think it really came out of the fact that Dart was as I originally understood it designed to be a replacement for both Java and JavaScript which probably feels instantly obvious to anyone who has spent much time with it in terms of style and patterns. To me it’s like all the good parts of each and none or few of the bad.
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.
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.
Exactly. I can't tell you how refreshing that is after 5 years on of Kotlin and Swift. One way to do everything, terse syntax that assumes memory managements, and functional. Amazing stuff.
In practice how is Dart functional? All I see in Flutter is classes all over the place. It's like no-one learned anything from the evolution of React and the decline of Angular.
Mostly because it has first-class functions and that's about it. Future might be used as a monad, but I'm not sure. Currently it has no ADTs, no pattern matching, Java-like immutability, null safety seems to be a special compiler feature rather than an option type or monad.
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.
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.
[deleted]
Sound null safety is one that most languages don't have.
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.
[0] https://github.com/dart-lang/language/issues/1482
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.
[0] https://github.com/dart-lang/language/issues/1482
Very cool! I'd love to see proper macros in a major language like Dart. And the proposal looks good, like a mix of Scala and Nemerle.
I'm rather impressed by nim's macro system - basically the build system contains a nim interpreter that handles the macros while still giving you compiled output.
(I wouldn't stretch to calling nim 'major' but I will say I've found it fascinating so far)
(I wouldn't stretch to calling nim 'major' but I will say I've found it fascinating so far)
I have to agree with you. For the domain of writing mobile applications with async communication with various services, Dart (in combination with Flutter) seems to allow my to crank more production quality code faster.
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.
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.
> ...but by such a long margin Dart was my favourite.
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"?
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"?
May be you should write why dart is bad instead
I didn't say dart is bad, it's way better than perl for example. The parent is the one making an outrage claim (dart is better than every other language they have tried "by a long shot"), so I think the burden of proof in on them.
Call me crazy but I am pretty sure this comment is written by paid lobbyists
My acid test for all things "super-modern" is to try firing them up on older devices. Y'know, to combat the old "fast enough to reach production but quadratic once it gets there" thing.
Take 1: Galaxy Note 3 with Android 5
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.
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.
I was trying Matrix clients on an older Android phone, and both FluffyChat and Syphon (both Flutter, without a JS layer) were unable to scroll a user list or message list at 60fps on a Moto G5 plus (a 2017 phone) with LineageOS Android 11 installed.
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.
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.
How was Element Android (native android) out of interest?
I uninstalled it after seeing the whopping 100 megabyte download size (what is even in the app?). I should try it again though.
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.
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.
My iPhone 12 Pro drops frames when scrolling the Flutter Web gallery [0]. Flutter Web also doesn’t support iOS’ ubiquitous tap status bar to scroll to top and has different scrolling acceleration, deceleration and springiness.
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
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
Galaxy Note 5 - released 2013
Galaxy Note 4 - released 2014
Seriously dude...
Seriously dude...
Seriously dude yourself.
Not all consumers live in a place where salaries are high and electronics are cheap.
Not all consumers live in a place where salaries are high and electronics are cheap.
3GB RAM, 2.7GHz quad core cpu/1.9GHzX4 + 1.3GHzX4 (oct core). This device is more powerful than my current phone.
Yep, 3GB RAM, but Chrome eats most of that and it swaps pretty much the entire time (yup, it has a 1GB swap partition, the poor flash)... and the CPU is a 32-bit Snapdragon 800 with 4 (symmetrical) cores at 2.2GHz. FWIW, I feel it.
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.
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.
I did say old :D.
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.)
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.)
Are you compiling in --release?
No, I went I'm-Feeling-Lucky APK Fishing™ on the releases tab and fed my phone whatever that was.
Which suggests the build process is a bit broken.
Which suggests the build process is a bit broken.
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%...
"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%...
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.
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.
It also seems not to be high performance either, judging by exikyut's comment.
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
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.
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.
I meant "the main problem" when I said "the main reason"
The link to the Chinese government website in the footer is a little weird. What is that? Is this project affiliated with beian.gov.cn?
Honestly just curious.
Honestly just curious.
Yeah. All public websites need to be registered with the the government and are assigned a BeiAn code. It's a link to the registry where you can find who owns and operate the website with the code listed.
Wow, so a bit like the Impressum thing Germany requires where you provide your address?
Huh, ok.
Huh, ok.
I worked for a company where we hosted some stuff in China (on Alibaba Cloud) and we had to register there and get an ICP number (it stands for Internet Content Provider). It's obligatory to display it somewhere on the page.
Looking at Kraken contributors, they work for Alibaba, so it seems they host that website in China.
Looking at Kraken contributors, they work for Alibaba, so it seems they host that website in China.
Theres a lot of good info on this on the aws-cn faq: https://www.amazonaws.cn/en/support/icp/
[deleted]
Can I write an entire iOS app using Javascript and compile via flutter?
Is there an example - I'm not able to find one.
That could be killer!
Is there an example - I'm not able to find one.
That could be killer!
Not sure I follow this.
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?
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 write js (without kraken), you are limited to web browsers.
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
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
Guess it's time for me to finly try out kraken.
I think the easiest way to explain this is:
"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.
"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.
https://hydro-sdk.io/ enables this approach as well.
[deleted]
The value you get is using JS instead of that abomination called Dart
If you build a Flutter app through Javascript, how can the AOT Dart compiler work its magic? Won't "Kraken" forever have the performance of JIT, even for production releases?
Is this a joke? It's 100 <div> tags with inline styles!
Yeah. Modern web dev. Or old web dev. Everything old is new.
Not to be confused with Kraken JS https://krakenjs.com .
I can't tell if this is a joke or we've actually done a full circle
The idea seems neat. If you don't want to rely on react native but still write react this might be a good option to have
The point is that Flutter compiles back to Javascript.
It doesn't. To clarify, you can compile dart to javascript, albeit more commonly to machine code.
https://flutter.dev/web
> 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.
> 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.
It does if you target browsers with your flutter app.
I believe it actually targets WASM and renders as a canvas element.
No. Where did you get that from? Compiling dart into WASM is a highly requested, but unimplemented feature (it's not really necessary for most cases you'd think). https://github.com/dart-lang/sdk/issues/32894
The CanvasKit renderer, which at the time of this GitHub comment [0] was experimental but is now the default one (the other being a HTML renderer rather than a canvas renderer, but that had some problems and was not as fast as the canvas implementation, so it was overridden by canvas), uses WASM and WebGL.
[0] https://github.com/flutter/flutter/issues/41062#issuecomment...
[1] https://flutter.dev/docs/development/tools/web-renderers
[0] https://github.com/flutter/flutter/issues/41062#issuecomment...
[1] https://flutter.dev/docs/development/tools/web-renderers
[deleted]
[deleted]
This is how I would be interested in using Flutter. Honestly the thing that has been stopping me from doing it is Dart. It's not that it's a terrible language, it's just a very mediocre one. At this point in my career, I detest that and will not learn anything that simply exists for the sake of being difference instead of offering any actual merit.
[deleted]
It would be helpful if you would explain/teach us why Dart is a mediocre language. With examples if you can. What would you suggest instead?
A modern language without ADTs + pattern matching, gets a big nope from me.
It started out as a compile to js language (think coffeescript), then they created a vm for it. Google made dart so that they wouldn't have to directly compete with react native/cordova.
That's actually the exact opposite of reality: Dart was a retention project for Lars Bak, and it was designed specifically with a focus on being able to make a fast VM implementation. The goal from the beginning was to have native support in browsers (they even got an ECMA standard for it!), and support compile-to-js as a polyfill until browsers had native support, but they couldn't convince any of the other vendors and so not even Chrome supported it. Some time after that, Lars Bak left Google.
I could explain it as Dart not having any features other than what any of the mainstream language has but that would not be much of an explanation would it? What is special about Dart?
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.
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.
When Dart was launched Javascript (Typescript) was not really a enjoyable language to use. For me at least it filled that void as a strongly typed language I could use on the web and server side that was easy to pick up. I thjnk that was the niche it was trying to fill and wasnt just made for the sake of it.
The original mission of replacing JS in the browser failed. At that point they could've called it off. Instead they doubled down with Dart 2.0, which, could've been great if there is actually anything 2.0 about it. It's still just some language with curly braces.
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.
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.
Although Dart's creators have pedigree it's identity is somewhat confused. It started out as an alternative to Javascript for the Chrome browser then Google abandoned that goal and adapted it to be more JS-compatible. That may be why Dart is single-threaded. Why on earth would any language creator settle for single-threaded when we live in a multi-core world. That's what I find so disappointing about Dart. That and it's desire to be just some kind of average of other mainstream languages.
Dart is not single threaded. Dart isolates are the equivalent of threads, but they cannot share memory like threads. As anyone who works in UI knows the UI/ main thread is 1 thread (not a thread pool), because concurrent UI development hasn't been done well. https://stackoverflow.com/a/5544714/7365866
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...
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...
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.