Ah Flutter. I burned a month making silly apps with it, but then I realized that I would probably be better off learning any other programming language than Dart (careerwise at least)
However, the idea that you need a “Center” widget just to position an item to the center of its parent…it just feels like GUI development took a major step backwards. I really can’t grasp why that decision was made. I’m open to having my mind changed but so far I’m like, thanks I hate it.
Specifically, instead of doing random mish-mash of layout (like in every other UI toolkit I know, including HTML), Flutter has a simple layout protocol that defines how a parent lays out it's children.
It's a simple, local protocol. ("local" means that the effect of layout is local to widget doing the layout, unlike in HTML where some layout properties effect more than just immediate children).
`Center` is a simple widget that lays out its child in the center of itself.
Why is it good and coherent design?
What if you need to position child 2/3rds on the X axis of the parent?
In Flutter you write (trivial) `Position23rdX` widget and you're done. An easy way to implement custom layout logic that plugs into a coherently designed layout protocol.
In HTML you can't. You can use layout properties that HTML gives or you're out of luck.
I've also worked (or dabbled) with win32 (no layout at all), WinForms, WPF, Cocoa, Gtk - none of them have anything like that.
As for what I call the "Lego model" of UI construction, while definitely off-putting, I think the "why" is prolly "simplicity thru decomposition". So we do a bit more typing but have a dead simple approach to building our UIs.
The nice thing about any Lisp with its macro capabilities is that we can wrap sth like Flutter to produce a library that remains Flutter, but hides the noise.
ClojureDart offers a so-called "widget" macro, and my Matrix library goes a different way, making every constructor such as "scaffold" into a friendlier macro.
OTOH, so far I am OK with the idea of forever adding nested widgets just to add some styling, and making children implicit makes the code look less "busy", but look for me to sneak in soon a DIV macro supporting the classic HTML attributes. That will be fun!
I see a lot of solutions in the Flutter ecosystem and none getting raves, so I decided to throw my "reactive first" Matrix[2] hat into the ring. Feedback welcome.
[0] https://github.com/mobxjs/mobx [1] https://github.com/ThoughtWorksInc/Binding.scala [2] https://github.com/kennytilton/mxtodomvc#readme
I switched from a purely TS/JS stack (React-Native-Web to cover iOS/Android/Web, Typescript on the backend, with some stuff to share types), and just got way too tired of all the tooling, the configuration, etc.
While I use Golang on the backend (compiled to WASM for serverless) I wouldn't be against using Dart on the backend if it had a WASM compiler...
....and upon doing some research to put a link in here, apparently you can as of seven days ago? https://github.com/dart-lang/sdk/blob/main/pkg/dart2wasm/dar...
Dart was being pushed as JavaScript replacement, back when everyone had one.
However Chrome team failed to push ChromiumVM and eventually the project was ramped down, by then AdWords had made a massive investment moving from GWT into AngularDart, so they rescued the project.
Eventually Flutter, initally prototyped in JavaScript, moved into Dart, and they also decided to change the language semantics from dynamic language with gradual typing (Dart 1.x), to static typing with type inference (Dart 2.0).
Somewhere alongside this timeline, many well known names from language design like Gilad Bracha and Kasper Lund, well known for favouring dynamic languages, left the project.
Kasper Lund's latest project, is not surprising also a dynamic language, https://toit.io/
I guess I am trying to understand why these two coexist, which one to learn, and how likely it is that Google will kill Dart/Flutter in the next 5-10 years.
It is all about Java, Kotlin, C, C++, Web widgets and PWAs.
I am not a big Kotlin fan, the way Android has pushed it using their Android Java as counter example instead of supporting modern Java, however as JVM language it definitely has a broader industry support than Dart.
Honestly, Flutter is an amazing framework conceptually, but Dart may prove to be its demise. I just hope there is a possibility for Flutter based on Typescript or Kotlin in the future.
cough Well, this article _is_ about a delightful Lispy alternative to Dart that compiles to Dart, yielding a superior language with Genuine Dart Inside(tm) and elegant support of Flutter.
Dart may end up living on inside ClojureDart, much like DOS living on deep inside Windows and PCs.
The type system was verbose yet relatively weak in comparison to something like Typescript, it'd already been rewritten once (which isn't a bad thing), and it was almost unusable outside the platform (I remember trying to write tests for something using sqlite.dart and then realizing that you just... couldn't).
Flutter is an amazing technical achievement, and to some extent so is Dart (there's a great talk from strangeloop about it) but I just... want to be able to use anything but Dart in there. Being able to use Typescript with Flutter would be heaven (JS compatibility was something in early versions of Dart that was removed).
And my specific contrib, Matrix, handles state management and the whole reactive thing pretty well, one area where I see a bit of thrashing in the Flutter community. Check out the examples and esp. the TodoMVC demo, they cover quite a bit of ground.
Another thing is Dart is JITed, AOT compiled as well as compiling to JS and WASM. Very few languages can do all 4. JVM ones can't, so no Kotlin (we'll see how well Kotlin Native works), and V8 isn't AOT so no JS or TS either. Only alternative I can think of is Lua.
> Very few languages can do all 4. JVM ones can't
Java can (JIT is trivial, for AOT there is among others Graal, for JS and WASM there is TeaVM (which works on class files, so now that I think about it, pretty much every JVM language can do all platforms), but also the very great Closure compiler (j2cl) which has no relation to cloJure, made and used heavily by google)
With your Java example, that's exactly what I mean, you don't need 4 different tools in Dart to achieve the 4 types of compilation, they're all included in the standard Dart compiler/SDK. Sure, if we go by your definition, probably any language has some level of support for each via various random compilers but I'm talking about something first-class, built-in.
While there is surely a very delicate balance of slowly deprecating a few things, remember that the only significant productivity booster is relying on existing code (as per Brooks).
I’m fairly sure there are orders of magnitude more Java code transpiled to JS running at Google than all of their Dart codebases combined, so not sure “random compilers” are a fair description.
Then they decided to salvage the team and made flutter with it - the technical reasons of chosing it over JS sound extremely unconvincing. And the language is as you say the worst of both worlds - verbose and weak type system (I remember getting runtime type exceptions because compiler couldn't catch a type mismatch in a ternary) and none of JS dynamism, no reflection - just boilerplate on top of boilerplate.
Worst part is the react like architecture of flutter lends itself really well to immutable state management practices but the language is so weak that any immutable library involves a ton of ugly boilerplate - and they refuse to add stuff like records to the language to ameliorate the problem.
The reason it gets me so riled up to rant is that the framework itself and the idea behind it (custom native rendering framework) has potential - but dart makes using it horrible.
90% of the time, it felt like simple IoC plus an app-wide singletons would have been enough for most apps-- trying to get everyone to aadopt BLoC was painful and kinda meh. It's probably just that I never developed a sufficiently big app at scale with lots of devs to see why BLoC was the best way.
That said, I'm also reminded of the Boring Flutter Development Show[2], quite possibly the best produced resource I've ever seen as an intro and ongoing guide to a piece of tech. It is excellent.
[0]: https://www.dbestech.com/tutorials/flutter-bloc-pattern-exam...
[1]: https://www.flutterclutter.dev/flutter/basics/what-is-the-bl...
[2]: https://www.youtube.com/watch?v=yr8F2S3Amas&list=PLOU2XLYxms...
The tersest write-up I have on Matrix is of the JS version, and all the demos are CodeSandbox if you want to play: https://tilton.medium.com/simplejx-aweb-un-framework-e9b59c1...
Meanwhile they spent colossal effort and broke half of community packages (including a bunch of first party ones) with null safety. I'd say go for low hanging fruit first.
Because the language is so limited it's impossible to solve this via library, unlike say JavaScript.
I know little about Dart/Flutter history, but it sounds like ClojureDart might do a lot for Flutter development if only for CLJD's stability.
If you like Java 8 and earlier you'll probably feel at home with Dart.
Obviously I'm biased, but I find Dart to be one of the most unpleasant languages I've had the misfortune of being exposed to; this despite Flutter and its instantaneous hot code reloading being quite amazing -- a bizarre mix of promise and despair.
[1] https://github.com/dart-lang/language/blob/master/resources/...
Happy opportunity for ClojureDart!
btw, in case anyone is wondering, I am not a part of Team CLJD at all. My hack is my own separate effort.