Show HN: Programming Google Flutter with Clojure(github.com)
github.com
Show HN: Programming Google Flutter with Clojure
https://github.com/kennytilton/flutter-mx/blob/main/README.md
92 comments
When working with Flutter I did dream "It would be pretty amazing to have a Lisp on top of this" - awesome work you're doing here!
Lots of interesting stuff happening in the Clojure space lately.
https://github.com/squint-cljs
It's a strange thought, but I wonder if Clojure (or rather, the clojure community) would somehow "migrate" from the jvm at this rate.
Lots of interesting stuff happening in the Clojure space lately.
https://github.com/squint-cljs
It's a strange thought, but I wonder if Clojure (or rather, the clojure community) would somehow "migrate" from the jvm at this rate.
No one is "migrating" anywhere.
Clojure has always been about being hosted on different platforms. The best Clojure development experience is probably full-stack Clojure, i.e. JVM Clojure on the backend and ClojureScript on the web—and perhaps ClojureDart for apps. People are implementing Clojure on different hosts because they love the language and want to use it in other contexts, not because they don't like the JVM.
I actually wrote about this phenomenon a few years ago and it reached the top of HN: https://news.ycombinator.com/item?id=22458827
I should probably revisit the topic again, since much has changed in the meantime.
Clojure has always been about being hosted on different platforms. The best Clojure development experience is probably full-stack Clojure, i.e. JVM Clojure on the backend and ClojureScript on the web—and perhaps ClojureDart for apps. People are implementing Clojure on different hosts because they love the language and want to use it in other contexts, not because they don't like the JVM.
I actually wrote about this phenomenon a few years ago and it reached the top of HN: https://news.ycombinator.com/item?id=22458827
I should probably revisit the topic again, since much has changed in the meantime.
[deleted]
My dream is Clojure hosted on Rust.
It's because Clojure isn't intended to "hide away" the platform underneath and you interact with the platform quite a bit. Since I prefer Rust ergonomics over Java/JVM ergonomics, it'd be awesome to have Rust as a Clojure platform.
One day it will happen - if not by me, then by someone else, I'm sure!
It's because Clojure isn't intended to "hide away" the platform underneath and you interact with the platform quite a bit. Since I prefer Rust ergonomics over Java/JVM ergonomics, it'd be awesome to have Rust as a Clojure platform.
One day it will happen - if not by me, then by someone else, I'm sure!
I'm sincerely curious about what you have in mind for "clojure hosted on rust".
Rust has a relatively thin runtime, but heavy static compilation work (types and lifetime and borrowing, etc...) , so it kinda seems like a completely different set of tradeoffs than what clojure favors (dynamicity, late bindings, runtime checks, managed memory, etc..)
Or did you mean "a clojure-like syntax for something that produces rust code to be eventually compiled natively ?"
Rust has a relatively thin runtime, but heavy static compilation work (types and lifetime and borrowing, etc...) , so it kinda seems like a completely different set of tradeoffs than what clojure favors (dynamicity, late bindings, runtime checks, managed memory, etc..)
Or did you mean "a clojure-like syntax for something that produces rust code to be eventually compiled natively ?"
I think they mean a JIT compiler for a clojure-like language written in rust, with rust interop (instead of Java interop). There would be no static compilation of rust code.
Code is easy, data is hard, the JIT would help with the former only. Rust on JSVM/.NET/JVM/Dart relies on the host platform to provide the underlying object system, reflection, interop with host code, GC etc.
Also, if everything would be ARC then it would be slow as all hell and would leak (it can’t GC circular references)
So basically https://jank-lang.org/ (assuming you don't mean literally it has to be Rust but just any LLVM clojure implementation)
I built a Clojure dialect in Rust called Calcit https://github.com/calcit-lang/calcit . It's ClojureScript at core, despite its indentation-based syntax.
Have a look at Carp for real-time applications: https://github.com/carp-lang/Carp
Carp is a statically-typed, GC-less Lisp that implements Rust’s borrow-checking. It is implemented in Haskell and compiles to C. It shares some syntax with Clojure, but I wish it was more Clojurey.
Carp is a statically-typed, GC-less Lisp that implements Rust’s borrow-checking. It is implemented in Haskell and compiles to C. It shares some syntax with Clojure, but I wish it was more Clojurey.
Carp! A user just turned me onto that, I am looking at porting Matrix to Carp. Matrix started on Common Lisp in the last century. https://github.com/kennytilton/cells
It is called Common Lisp and Scheme.
i dont understand what you mean
No need for Clojure on Rust, when there are already several mature Common Lisp and Scheme toolchains, compiling to native code for the last 40 years.
i am a big advocate for common lisp use but i still don't see your point. are you saying that the whole point of having a clojure on rust is to have native compilation? because i imagine "clojure on rust" for the parent means having a clojure-like-syntax on rust, keeping in mind that rust is a statically typed language (kind of a big point of rust)
Common Lisp supports gradual typing.
but not static mem allocation
It surely does, including stack values.
That is the thing, Lisp is not only lists unless one is stuck using Lisp 1.5.
That is the thing, Lisp is not only lists unless one is stuck using Lisp 1.5.
i dont think were talking about the same thing unless youre claiming that common lisp can be non garbage collected. otherwise stack allocation is very implementation dependent
Thx! Full marks to the folks at Tensegritics for ClojureDart.
As for migration, Mr. Hickey made a small language, and that made CLJS and CLJD possible. Nice! Now they just have to bring CLJD under the CLJC umbrella...but I suspect that would be a stretch.
As for migration, Mr. Hickey made a small language, and that made CLJS and CLJD possible. Nice! Now they just have to bring CLJD under the CLJC umbrella...but I suspect that would be a stretch.
Are you basically saying that I can build my front end using clojure?
I really want to learn clojure and use flutter for a personal project... are there are any reasons not go down this path? (E.g. the "official" implementation of flutter is more secure?, etc.)
Thank you for the cool project
I really want to learn clojure and use flutter for a personal project... are there are any reasons not go down this path? (E.g. the "official" implementation of flutter is more secure?, etc.)
Thank you for the cool project
> Are you basically saying that I can build my front end using clojure?
Unless I misunderstand your question, this has already been possible for some time: ClojureScript + React/React Native.
There are some impressive videos illustrating this. The devil is in the tooling and setup, but once that is in place the pace and ease of development looks great.
It's really amazing to make a code change in my text editor and see the UI on my mobile app update instantly.
Unless I misunderstand your question, this has already been possible for some time: ClojureScript + React/React Native.
There are some impressive videos illustrating this. The devil is in the tooling and setup, but once that is in place the pace and ease of development looks great.
It's really amazing to make a code change in my text editor and see the UI on my mobile app update instantly.
I believe Tensegritics already has an app up on the app store based on early ClojureDart. I run screaming before apps have to be deployed, so please check with them on that. They hang out on the Clojurians Slack. My reactive hack is over twenty years old so it is pretty solid, should be OK if you want to throw that into the mix. ps. You are welcome!
For sure. You could also build front-ends with Clojure using htmx. It really simplifies building dynamic front-ends by allowing you to return to the hypermedia model with server-side rendering. It has been fantastic. No ClojureScript. Just a normal Java Clojure REPL.
https://htmx.org/
https://htmx.org/
Building your frontend in Clojure has been possible for a while, see this announcement 11 years ago: https://www.clojure.org/news/2011/07/22/introducing-clojures...
ClojureScript & the user base has since steadily grown and improved and people have been shipping serious production applications with it for a long time now.
ClojureScript & the user base has since steadily grown and improved and people have been shipping serious production applications with it for a long time now.
Answering another question about Flutter variability I remembered that that variability requires a bit of custom wrapping per widget for Matrix goodness. ClojureDart is fine, but my Matrix macros try to bring in a little HTML-ish uniformity.
Matrix has many widgets yet unwrapped, but I will document the wrapping process and support any user by doing the wrapping myself. I also have in mind developing a Dart tool to generate wrappers automagically.
tl;dr: ClojureDart is in great shape, Flutter/MX is solid but needs more widgets wrappe.
Matrix has many widgets yet unwrapped, but I will document the wrapping process and support any user by doing the wrapping myself. I also have in mind developing a Dart tool to generate wrappers automagically.
tl;dr: ClojureDart is in great shape, Flutter/MX is solid but needs more widgets wrappe.
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)
I don't mind Dart, but I'm about a month into Flutter and so far, their approach to UI seems completely insane. It just feels like there's no coherent philosophy backing it.
I find the state management in flutter needlessly complicated and I don't see why they threw out decades of GUI development wisdom
I think the original MobX[0], not MobX State Tree, and perhaps binding.Scala[1], did well on state management, but not many libraries do.
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 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 think I know what you mean. I would not say it is incoherent, but it does not have the extreme uniformity of <tag> attributes> children </tag>. I actually bring some of that back in my Flutter/MX extension to CLJD. :content, :child, :body, and more all are expressed uniformly _and_ implicitly by nesting. Check out the examples.
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!
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 remember reading on the docs that Flutters ui architecture (& philosophy?) was inspired by React
Oh I should have been more explicit when I said that. I really like the reactive model - the idea that the UI is a function of application state is [chefs kiss]. I love it.
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.
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.
`Center` is a result of Flutter having a coherent philosophy (design).
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.
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.
I agree "UI = f(state)" rocks. That was the one thing React got right. But they never worked out state management, other than to kick off the Flux monstrosity that Redux ran with, and every other UI I can find.
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.
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.
I think everybody but MobX and my Matrix hack lives off setState, so to that extent yes. But React embraces the HTML API in the form of JSX. Flutter designers were in an OO world and seemed to just wing it as they got to each widget. I can tell you, wrapping HTML (and React) was much easier, and I have many widgets to go!
How come? What's so bad about dart?
The last time I used Dart, it felt like the worst parts of C# + Java put together somehow.
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).
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).
Dart is at least adding new features relatively quickly (just recently they started working on immutable record data structures with pattern matching, which even TypeScript doesn't have yet) and soon they'll have static metaprogramming meaning you can have Lisp like macros to create your own syntax, including algebraic data types as in any functional language. That is really what people are looking forward to.
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.
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.
It is easy to iterate fast on language design when you don’t care about backwards compatibility.
> 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)
> 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)
Backwards compatibility is overrated, sticking to it too hard is how we get stuff like JS or C++ that have ten different ways of doing the same thing. I'd much rather a language be improved and break sometimes than to convolve around keeping strict BC. Anyway, they have good BC support since Dart 2 released several years ago so I'm not worried.
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.
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.
> Backwards compatibility is overrated, sticking to it too hard
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.
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.
I think you have made the case for ClojureDart. Clojure does not do the Typescript strong typing thing, but it meets the "Not Dart" requirement pretty well.
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.
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.
I can confirm the experience and I've used dart on multi month projects twice now : first time when it was the JS replacement and using AngularDart back in the angular 2 beta days - it was ahead of the curve at the time with tooling (compared to JS world), but it went nowhere because of poor design choices.
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.
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.
With regards to records, you only need to wait for it: https://github.com/dart-lang/sdk/commit/99f60a5e662a7951dd5a...
I mean they basically have a single purpose programming language (AFAIK Flutter is the only relevant use case) and it is taking them years to add ergonomic improvements to the language that would make day to day dev much easier.
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.
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.
This reminds me so much of the ClojureScript "win". I love that JS is rounding into shape as a serious language, but the version turmoil! CLJS was "done" when it came out, so the CLJS developer is insulated from any churn.
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.
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.
I'd rather take sound null safety over records. To say it's taking them years is disingenuous when they've mainly been working on null safety all this time, not twiddling their thumbs.
Oh this totally reminds me of the BLoC pattern[0][1] that everyone kind of... really gritted their teeth through. It just wasn't at all an appealing way to structure data flow and I was kind of surprised that it was the architectural choice that was being pushed.
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...
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 huge thing that encouraged me to port my Matrix library to CLJD was that I saw the Flutter community did not have a consensus reactive solution.
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...
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...
Why are people using BLoC? I thought Provider and now Riverpod are what was recommended, which are the global singletons you're talking about.
It’s been a while since I looked, if that’s true then great
Off the top of my head, no access modifiers (so private variables, for example, are prefixed with `_`, by convention, not enforced by the compiler), no pattern matching (and obviously no exhaustive matching), no record types, no sum types, no json (de)serialization (requires 3rd party libary code gen, wow), mutability everywhere, everything is a statement (i.e. no implicit `return`, AKA everything is an expression), required semi-colons (which they'd like to get rid of but can't due to questionable design decisions made long ago -- for the gory details see here[1]).
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/...
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/...
As a Dart/Flutter outsider myself, I am finding all this "Dart no, Flutter yes" traffic intriguing. I am also a lisper, so no need to sell me on the difficulties of Dart, even if it were the perfect static typed OO, but it sounds like we have a great UI stuck inside an unloved language.
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.
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.
Easy, its only purpose to exist is for doing Flutter apps, there is hardly any significat use of Dart outside of Flutter.
That's in no way a bad thing, some may say that means it does one thing (an important thing) extremely well ;)
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...
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...
It does predate Flutter by five or so years but I do agree that it doesn't have much of a reason to exist outside of that now. I would love to have been a fly on the wall when the decision was made to choose Dart.
Didn't it have something to do with Dart being pushed as Google's pet language? I have heard arguments that it was chosen because TS is Microsoft's pet, while Oracle was having a picnic with Java (this was around the time of the Google-Oracle saga). Dart was seen as a way for Google to be independent of both, and Kotlin wasn't developed yet at the time, hence Flutter went with Dart.
It is a bit more convulated than that.
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/
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/
Do you know what is the relationship between Dart/Flutter and Kotlin? On paper, it seems that Dart/Flutter is a better choice in the context of mobile dev because it is cross platform. If I were to focus on Android exclusively, would Kotlin offer any advantages over Dart/Flutter?
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.
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.
Politics, go to Android SDK site, you will hardly find anything related to Flutter.
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.
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.
Very useful - thanks for answering!
Just to add on, Kotlin also does have some (limited) multi-platform features, with potential to build on for more.
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.
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.
That is impossible, because Flutter is written in Dart on top of Skia, most Dart 2.0 features have been done to improve that development experience, using any other language means basically a full rewrite.
I know that.... But apparently with all the issues Flutter has, there is a possibility that a full rewrite will be absolutely necessary to rectify them.
"a full rewrite will be absolutely necessary"
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.
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.
It does, and had AdWords not rescued Dart from being killed, it wouldn't even be an option for Flutter.
Yeah. C++/Rust, or (slightly far fetched) C# support would be so awesome!
Consider:
https://flet.dev/ + https://coconut-lang.org/
TL;RD; Functional Python on top of Flutter
From https://github.com/flet-dev/flet:
" Deliver to any device Deploy Flet app as a web app and view it in a browser. Package it as a standalone desktop app for Windows, macOS and Linux. Install it on mobile as PWA or view via Flet app for iOS and Android."
From https://coconut.readthedocs.io/en/latest/HELP.html:
"Specifically, Coconut adds to Python built-in, syntactical support for:
pattern-matching
algebraic data types
destructuring assignment
partial application
lazy lists
function composition
prettier lambdas
infix notation
pipeline-style programming
operator functions
tail call optimization
where statements"
TL;RD; Functional Python on top of Flutter
From https://github.com/flet-dev/flet:
" Deliver to any device Deploy Flet app as a web app and view it in a browser. Package it as a standalone desktop app for Windows, macOS and Linux. Install it on mobile as PWA or view via Flet app for iOS and Android."
From https://coconut.readthedocs.io/en/latest/HELP.html:
"Specifically, Coconut adds to Python built-in, syntactical support for:
pattern-matching
algebraic data types
destructuring assignment
partial application
lazy lists
function composition
prettier lambdas
infix notation
pipeline-style programming
operator functions
tail call optimization
where statements"
Wow! Coconut alone looks impressive.
Is there a state management solution in there? I looked at the Todo app and it looked like manual change propagation.
Is there a state management solution in there? I looked at the Todo app and it looked like manual change propagation.
By popular request, a video[0] of my workflow using ClojureDart and Matrix to live code Flutter. The last few minutes show me probing a new bug! I experiment, and find a partial workaround that hints at a solution.
[0]: https://www.youtube.com/watch?v=qQiTfIc7nDo
[0]: https://www.youtube.com/watch?v=qQiTfIc7nDo
Hello Kenny, that looks cool. I will try it later today.
I was very keen on Flutter a few years ago until a version bump broke my one application and I never spent the time to fix it.
Clojure is far from my favorite Lisp, but I like it well enough. What will sell your project to me is how nice the dev process is. I love Common Lisp and Scheme dev process, but I struggle to get the same level of happiness with Clojure.
Looks like a nice project!
I was very keen on Flutter a few years ago until a version bump broke my one application and I never spent the time to fix it.
Clojure is far from my favorite Lisp, but I like it well enough. What will sell your project to me is how nice the dev process is. I love Common Lisp and Scheme dev process, but I struggle to get the same level of happiness with Clojure.
Looks like a nice project!
Mark! How are you! Yes, my heart belongs to Common Lisp, but Clojure has macros and the parens are in the right place..."well enough" says it all.
I hang mostly on the Clojurians Slack if you get stuck, #clojuredart or #matrix channels.
I hang mostly on the Clojurians Slack if you get stuck, #clojuredart or #matrix channels.
In folks' opinion, what are the best resources to learn Flutter beyond the official docs? The official docs are pretty solid but I am looking for something else — maybe a book?
With full REPL support etc?
(Please say yes, please say yes, please...)
(Please say yes, please say yes, please...)
Not yet but we are working on it. Sponsor ClojureDart to make it happen sooner! https://github.com/tensegritics/ClojureDart
FWIW, I tried ClojureDart a little while back, had a good time, but thought to myself, "I'll be back when they have a REPL working." At that time you guys were saying things in the Slack like, "We already have a working prototype behind closed doors, it just needs polish. We'll be ready to release it soon." It was very exciting.
That was... six months ago. :) So... I guess I'll keep waiting.
That was... six months ago. :) So... I guess I'll keep waiting.
(a) Is six months a long time?
(b) And then they delivered successfully.
(c) Not seeing a problem.
I know, I have been beating on CLJD like I was its Daddy wrapping it in a reactive framework, despite their warning that there would be surprises. I had one problem that turned out to be a simple bug in CLJD.
I also follow their channel on the #clojurians Slack and see they are doing a profoundly deep job on the compiler. This means a robust product, not one that has developers forever looking over their shoulders at the language they are using.
Six months for that is nothing. Now send them eight dollars. jk. :)
I know, I have been beating on CLJD like I was its Daddy wrapping it in a reactive framework, despite their warning that there would be surprises. I had one problem that turned out to be a simple bug in CLJD.
I also follow their channel on the #clojurians Slack and see they are doing a profoundly deep job on the compiler. This means a robust product, not one that has developers forever looking over their shoulders at the language they are using.
Six months for that is nothing. Now send them eight dollars. jk. :)
[deleted]
It's my fault. And other active users. Tensegritics polled us on what we wanted first -- Tensegritics is neither Oracle nor Google -- and we all had a REPL in last place.
The one caveat I offered was "...but a REPL will be a selling point!" ROTFL
Seriously, when I want a REPL I hack the test code into "main" and comment out the UI launch. Then I edit and save and the output goes to my terminal nearby thanks to auto build/restart.
The one caveat I offered was "...but a REPL will be a selling point!" ROTFL
Seriously, when I want a REPL I hack the test code into "main" and comment out the UI launch. Then I edit and save and the output goes to my terminal nearby thanks to auto build/restart.
You posted this as a reply to cgrand saying they would need resources to go any faster. Yes it’s not ready yet so you’ll need to wait (or provide resources). Paraphrasing your memory of their prior time estimate on Slack seems a non sequitur - what is your intended point?
Parent comment says: REPL is a priority to me, do you have that?
cgrand's comment says: Not yet, but probably soon! Here's a link to donate
My comment says: Before you donate, here's some context for what "soon" likely means
Your comment says........?
cgrand's comment says: Not yet, but probably soon! Here's a link to donate
My comment says: Before you donate, here's some context for what "soon" likely means
Your comment says........?
No cgrand didn’t say it’s coming soon, he said they’re working on it and donate to get it “sooner.” Is it possible you are having similar accuracy issues recalling what he said on Slack months ago?
[deleted]
Yep, REPL is always great, but tbh even with ClojureScript (atop JS) I have never taken the trouble to figure out how to get a CLJS REPL going, though I am told it is possible. :)
Instead I get by with sub-second recompiles/reloads and print statements. It works great, tbh.
That said, Tensegritics is working on it.
Instead I get by with sub-second recompiles/reloads and print statements. It works great, tbh.
That said, Tensegritics is working on it.
Interesting! Would love a video including your workflow w/ emulator.
Voila! https://www.youtube.com/watch?v=qQiTfIc7nDo
Please let me know what else you might like to see.
Please let me know what else you might like to see.
Will do! Any specific things you like to see in workflow vids? Otherwise I'll just do the obvious stuff. I will reply here when I have something for y'all.
The tl;dr is, on the Mac, (1) start their Simulator app; (2) start a build with watch in the app root directory; and (3) edit code as usual (IntelliJ/Cursive).
The app rebuilds/reloads on save. Tensegritics is looking at better hot reloading; I am happy with automatic full restarts.
Flutter offers a couple of endpoints to visit for debuggers, but I just live off print debugging in the build console.
Video ASAP.
The app rebuilds/reloads on save. Tensegritics is looking at better hot reloading; I am happy with automatic full restarts.
Flutter offers a couple of endpoints to visit for debuggers, but I just live off print debugging in the build console.
Video ASAP.
This is so cool!
So, yes, we can now program Flutter with a Lisp. Yay.
Project includes dozens of working examples and a full implementation of the TodoMVC classic to help tire-kickers play around.
Support installing freely available on the #matrix channel on the Clojurians Slack.