I played around with Flutter a couple years ago for a project that required a mobile app, and walked away really impressed with Flutter and Dart. It's a much, much nicer language for building UI in compared to React Native and even the native languages. But the backend story with Dart was very much neglected. I got the feeling that Flutter's main developers at Google were the driving force behind Dart development, and the lack of backend adoption for Dart at Google was causing it to wither on the vine for backend purposes.
Is the ecosystem support improving here? People end up needing libraries for all kinds of backend stuff, not just auth and SQL like you have on your roadmap. What about sending emails, hooking into payment providers / billing, queues/pubsub, observability...? Doesn't this need to exist first, to make building backends in Dart feasible, before building a framework that makes it easier?
The ecosystem support is improving, and still needs help. I think we can drive both in parallel so that the framework feeds use cases to the ecosystem which then lead to more complex backends. It's hard to put one before the other, but can be a really powerful flywheel.
Although it's not listed on my landing, it is absolutely a goal of Celest to be a funnel for these use cases and partner with the community as we go to fill the gaps.
My immediate plan for reducing lock-in is to provide the option to deploy into a cloud account you manage. This has the upside of making your deployed infrastructure independent of Celest and letting you use your cloud credits.
Self-hosting is another option I'm considering, but I don't have a good sense yet of what that could look like. Any thoughts? Is spitting out a binary/Dockerfile sufficient to alleviate risk?
If I get shut down, I'll be open-sourcing all my code. And regardless, I plan to open source more and more of the platform over time.
Committing to open-source the code (and provide detailed instructions on how to run the code) in case the company shuts down is the most important. It could be part of the service contract. I've read all parts of the Celest code which are public, and I can attest it's very well-written and easy to understand.
I just listened to a podcast episode of the Flying High with Flutter podcast [1] where Celest founder, Dillon, was on as a guest. He came across as capable, hungry to get Celest out into the world, and focussed on solving problems around running dart in the cloud. All the best, Dillon, I'm looking forward to see where Celest goes!
The alternatives of native tooling on iOS, Android and the web are not contentious choices.
Whereas suggesting to a team or decision maker that Flutter is the right choice seems like it could be an uphill battle!
As a solo dev making choices for clients that want a cross platform solution I can pitch Flutter as a somewhat rational choice against the cost of seperate builds for iOS and Android. Maybe, depending….
Then there’s the Google factor… what if they get bored and kill Flutter!?
Having seen the development of Flutter and its ecosystem over the past 7 years, I've come to really believe in the framework and its mission. There have been lots of companies which have found success building with Flutter [1] and it very often speaks to their bottom lines [2].
I'm hopeful for its continued success, but more importantly, I believe that having more companies building enterprise solutions makes the technology more attractive and practical to adopt. The founder of Flutter has started Shorebird [3] and the FlutterFlow team recently closed a $25M Series A [4]. These are great investments to have into Flutter.
Another cool stat: Dart was the fastest growing programming language among all languages last year at 33%! [5]
All that to say, I believe the business value of Flutter is becoming clear and I think having more companies building on top will reduce adoption risk and create a very rich ecosystem for further progress.
I find everything is rendered in a canvas. This means it's not accessibility friendly. It means none of my extensions work. It means no text can be selected (for example clicking the 3rd icon from the top left labeled "Typography". It also means none of the Browser/OS level features are available. I can't select a word and pick "look up" or "define" or "speak". It's shows ugly monochrome non native emoji. It takes second to show non-English characters while it downloads non-English fonts
Flutter tooling is superior to that of native iOS and Android development. It's not just about the cost savings from avoiding separate builds: Developing a Flutter app is generally easier than developing a separate app for either Android or iOS. And the developer experience is way better too.
Google is not killing Flutter. Despite Google's rep, Flutter is a highly successful project that Google uses for many of its own products, including Google Pay, Google Classroom, and Google Ads. It's also used by other major companies: https://flutter.dev/showcase.
Hey folks, I've created an open source app example using Celest, complete with tests and all. If think it demonstrates Celest use quite well. Here it is:
Neat! Looks like you are using Flutter for the web front-end, is that right?
I remember folks complaining about Flutter in the browser. Did that get fixed to an acceptable degree? And does that obviate the complexity of typical SPA framework on the frontend? With similar power?
Though, Flutter Web has come a long ways recently, especially with the WASM work that's underway [1][2]. Flutter is very well positioned, I think, for web applications requiring a lot of interactivity and complex layouts--the DX is phenomenal. For static sites, it's very hard to beat a pure HTML/CSS/JS stack in terms of speed and optimization potential.
That being said, I think there's a good chance we'll see more work on Dart web frameworks going forward. Projects like Zap[3] and Jaspr[4] and doing great work in this area already. And it's safe to say we may see a Celest Web framework one day!
Thanks, believe you answered my question, though I may not have been clear enough before.
I was asking about the demo app as shown in the video on the marketing site. The kinds of apps we'd be expected to build with this. Was not asking about the marketing site itself, though it seemed nice enough.
Ah, gotcha! The choice to use Flutter Web in the demo was just for presentational effect. Celest is built to work with all of the Flutter platforms equally.
Excelent news! Excuseme but where can i manage my free celest-cloud? i could run celest deploy with success but now i dont know how to use it and keep with the testings :D
Currently we just have the CLI to manage your account, although I'm working on a web-based dashboard for better accessibility.
The result of a deployment is just a URL, which is automatically placed in your generated client (see `celest/lib/client.dart`). To switch to this new environment, pass the production arg to your `celest.init` call like this:
When you do `celest deploy` it sends your current code to the cloud. After that if your code contains: `celest.init(environment: CelestEnvironment.production);` it will use that code you just sent to the cloud. If your code contains `celest.init(environment: CelestEnvironment.local);` it will use the code you have in your local machine.
But in practice you develop locally, so you don't need to deploy all the time.
Also, you can call `celest.init` as many times as you like, while the app is running, to change from local to cloud and vice-versa, on the fly!
Per project, per month, yes. Felt like a mouthful to write, but I'll make that more clear.
Celest's biggest strength with cloud functions is its integration with the Dart language. The CLI generates a strongly-typed API client for you which matches the declaration of your function, and handles all serialization out-of-the-box.
So, if you write a top-level Dart function like this
// In `celest/functions/my_api.dart`
Future<String> sayHello(String name) async => 'Hello, name!';
and save the file, you'll get a Flutter client which you can call as
You can pass just about any Dart class between the frontend and backend, and it will just work. We're going for an RPC-style interface which means your types/parameters can never get out of sync.
It's a problem I want to tackle correctly, so that you'd need to put as little thought into it as possible. It should "just work". Vercel's skew protection [1] stands out as a recent example of doing this well.
> It looks like you using Flutter's Dart<=>JSON serialization; do you recommend using built_value for immutable data structures?
JSON was chosen as the primary serialization format for the reasons mentioned here [2]. Primarily, familiarity to Flutter developers, availability of JSON-compatible types in the wild, and integration with non-Dart clients.
built_value types can be used in Celest currently by giving the class `fromJson`/`toJson` methods. I haven't implemented auto-serialization for them, yet, but it should be straightforward. I've used built_value heavily in the past and agree there's no better alternative for some use cases.
> Do you support protobuf/cap'n'proto?
In the future, I plan to support more serialization formats, including protobuf and binary protocols. I will check out cap'n'proto, it was not yet on my radar.
Yes, I definitely want to at some point. In the short term, I've implemented a `celest upgrade` method in the CLI, so it's just a one-time manual install.
1. Celest is fully managed and does not require any knowledge of the cloud. With Serverpod, you must have a cloud account and manage your own infrastructure.
2. In Celest, all of your backend and infrastructure logic is defined solely in Dart. This differs from Serverpod which incorporates technologies like Docker, Terraform, and YAML to define your backend.
There are similarities too. Celest will auto-generate a client library for you like Serverpod and provides a local development environment. Uniquely, though, Celest supports hot reload for your backend ;-)
I'd say the developer experience is completely different. With Celest you can almost pretend you are writing the frontend and backend code as one single codebase. And then you change a flag and the part of your code that needs to be in the cloud is moved to the cloud, seamless. I think you have to try it out to really grok how much easier it is.
Is the ecosystem support improving here? People end up needing libraries for all kinds of backend stuff, not just auth and SQL like you have on your roadmap. What about sending emails, hooking into payment providers / billing, queues/pubsub, observability...? Doesn't this need to exist first, to make building backends in Dart feasible, before building a framework that makes it easier?
Although it's not listed on my landing, it is absolutely a goal of Celest to be a funnel for these use cases and partner with the community as we go to fill the gaps.
Right now this looks fine for a hobby project, but massive lock-in/risk for production (what if you shut down, get bought up etc?).
My immediate plan for reducing lock-in is to provide the option to deploy into a cloud account you manage. This has the upside of making your deployed infrastructure independent of Celest and letting you use your cloud credits.
Self-hosting is another option I'm considering, but I don't have a good sense yet of what that could look like. Any thoughts? Is spitting out a binary/Dockerfile sufficient to alleviate risk?
If I get shut down, I'll be open-sourcing all my code. And regardless, I plan to open source more and more of the platform over time.
Agreed. I'll look into how we can add that.
[1] https://podcasts.apple.com/us/podcast/celest-the-flutter-clo...
Question: I know a few Clojure enthusiasts who really enjoy Clojure+Dart backend. Is Celest compatible for this workflow?
Obviously you are committed to Flutter and Dart.
Where do you see it going, broadly?
I’ve used Flutter a small amount and enjoyed it.
But it’s a hard sell to commit fully to it.
The alternatives of native tooling on iOS, Android and the web are not contentious choices.
Whereas suggesting to a team or decision maker that Flutter is the right choice seems like it could be an uphill battle!
As a solo dev making choices for clients that want a cross platform solution I can pitch Flutter as a somewhat rational choice against the cost of seperate builds for iOS and Android. Maybe, depending….
Then there’s the Google factor… what if they get bored and kill Flutter!?
Having seen the development of Flutter and its ecosystem over the past 7 years, I've come to really believe in the framework and its mission. There have been lots of companies which have found success building with Flutter [1] and it very often speaks to their bottom lines [2].
I'm hopeful for its continued success, but more importantly, I believe that having more companies building enterprise solutions makes the technology more attractive and practical to adopt. The founder of Flutter has started Shorebird [3] and the FlutterFlow team recently closed a $25M Series A [4]. These are great investments to have into Flutter.
Another cool stat: Dart was the fastest growing programming language among all languages last year at 33%! [5]
All that to say, I believe the business value of Flutter is becoming clear and I think having more companies building on top will reduce adoption risk and create a very rich ecosystem for further progress.
[1] https://flutter.dev/showcase
[2] https://assets-global.website-files.com/5ee12d8e99cde2e20255...
[3] https://shorebird.dev/
[4] https://techcrunch.com/2024/01/11/flutterflow-attracts-cash-...
[5] https://www.developernation.net/resources/reports/state-of-t...
https://flutter.github.io/samples/web/material_3_demo/
I find everything is rendered in a canvas. This means it's not accessibility friendly. It means none of my extensions work. It means no text can be selected (for example clicking the 3rd icon from the top left labeled "Typography". It also means none of the Browser/OS level features are available. I can't select a word and pick "look up" or "define" or "speak". It's shows ugly monochrome non native emoji. It takes second to show non-English characters while it downloads non-English fonts
How is this a win for the user?
Google is not killing Flutter. Despite Google's rep, Flutter is a highly successful project that Google uses for many of its own products, including Google Pay, Google Classroom, and Google Ads. It's also used by other major companies: https://flutter.dev/showcase.
https://github.com/marcglasberg/SameAppDifferentTech/tree/ma...
I remember folks complaining about Flutter in the browser. Did that get fixed to an acceptable degree? And does that obviate the complexity of typical SPA framework on the frontend? With similar power?
Though, Flutter Web has come a long ways recently, especially with the WASM work that's underway [1][2]. Flutter is very well positioned, I think, for web applications requiring a lot of interactivity and complex layouts--the DX is phenomenal. For static sites, it's very hard to beat a pure HTML/CSS/JS stack in terms of speed and optimization potential.
That being said, I think there's a good chance we'll see more work on Dart web frameworks going forward. Projects like Zap[3] and Jaspr[4] and doing great work in this area already. And it's safe to say we may see a Celest Web framework one day!
[1] https://flutter.dev/wasm
[2] https://flutterweb-wasm.web.app
[3] https://pub.dev/packages/zap
[4] https://pub.dev/packages/jaspr
I was asking about the demo app as shown in the video on the marketing site. The kinds of apps we'd be expected to build with this. Was not asking about the marketing site itself, though it seemed nice enough.
As you know the current setup with langpal's API is literally just next API routes from the marketing site. Bit of a strange and hacky coupling haha.
Can't wait to see and use this!
Currently we just have the CLI to manage your account, although I'm working on a web-based dashboard for better accessibility.
The result of a deployment is just a URL, which is automatically placed in your generated client (see `celest/lib/client.dart`). To switch to this new environment, pass the production arg to your `celest.init` call like this:
Let me know if you face any issues! We have a Discord (https://celest.dev/discord) server, and you're more than welcome to open a GitHub issue if you experience problems: https://github.com/celest-dev/celestWhen you do `celest deploy` it sends your current code to the cloud. After that if your code contains: `celest.init(environment: CelestEnvironment.production);` it will use that code you just sent to the cloud. If your code contains `celest.init(environment: CelestEnvironment.local);` it will use the code you have in your local machine.
But in practice you develop locally, so you don't need to deploy all the time.
Also, you can call `celest.init` as many times as you like, while the app is running, to change from local to cloud and vice-versa, on the fly!
I presume that's per month, not just 5000 free then pay up?
How does this compare to hosted AppWrite, which also lets you write backend cloud functions in Dart?
Celest's biggest strength with cloud functions is its integration with the Dart language. The CLI generates a strongly-typed API client for you which matches the declaration of your function, and handles all serialization out-of-the-box.
So, if you write a top-level Dart function like this
and save the file, you'll get a Flutter client which you can call as You can pass just about any Dart class between the frontend and backend, and it will just work. We're going for an RPC-style interface which means your types/parameters can never get out of sync.It looks like you using Flutter's Dart<=>JSON serialization; do you recommend using built_value for immutable data structures?
Do you support protobuf/cap'n'proto?
Versioning is not fully fleshed out yet, but we have an open issue for it here: https://github.com/celest-dev/celest/issues/4
It's a problem I want to tackle correctly, so that you'd need to put as little thought into it as possible. It should "just work". Vercel's skew protection [1] stands out as a recent example of doing this well.
> It looks like you using Flutter's Dart<=>JSON serialization; do you recommend using built_value for immutable data structures?
JSON was chosen as the primary serialization format for the reasons mentioned here [2]. Primarily, familiarity to Flutter developers, availability of JSON-compatible types in the wild, and integration with non-Dart clients.
The JSON structure is outlined here (working on a full spec): https://celest.dev/docs/functions/http-requests
built_value types can be used in Celest currently by giving the class `fromJson`/`toJson` methods. I haven't implemented auto-serialization for them, yet, but it should be straightforward. I've used built_value heavily in the past and agree there's no better alternative for some use cases.
> Do you support protobuf/cap'n'proto?
In the future, I plan to support more serialization formats, including protobuf and binary protocols. I will check out cap'n'proto, it was not yet on my radar.
[1] https://vercel.com/docs/deployments/skew-protection
[2] https://x.com/dillonthedev/status/1749806407510381054
1. Celest is fully managed and does not require any knowledge of the cloud. With Serverpod, you must have a cloud account and manage your own infrastructure.
2. In Celest, all of your backend and infrastructure logic is defined solely in Dart. This differs from Serverpod which incorporates technologies like Docker, Terraform, and YAML to define your backend.
There are similarities too. Celest will auto-generate a client library for you like Serverpod and provides a local development environment. Uniquely, though, Celest supports hot reload for your backend ;-)