-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
We've got a guide here that covers some of these areas: https://github.com/flutter/flutter/blob/master/CONTRIBUTING....
For a lot of first-time contributors, improved documentation and added tests are a great way to dip toes into the water. We also have a 'good first contribution' tag on our issues log that might be a source of inspiration:
Attempt to combine all these definition in single language is doomed to fail. If in doubts then look at WPF.
3. Notes on language-behind-UI...
If to consider #2 then such simple thing as JavaScript language and VM are quite adequate to the task. Language-behind-UI do not need to be that performant, but it must be flexible. I may express un-popular opinion but language-behind-UI should be typeless.
Simply put: don't do ray tracing in language-behind-UI. But! Such a language shall have simple mechanism of adding high performant functions. There are good languages that are specifically designed for performance: C, C++, D, Rust, Zig, WebAssembly, etc. You just need convenient mechanism to expose those functions to runtime of language-behind-UI. Like here: https://gitlab.com/sciter-engine/sciter-js-sdk/-/blob/main/d...
You need JITs, compilation, fat VMs and runtimes, strong types only if your language is the only mean to define algorithms in whole application. But expect that your code will always be sub-optimal - neither enough performant nor super flexible.
4. Conclusion
Flutter should be something Sciter-alike :) - use [X]HTML/JSX, CSS and some already well known language-behind-UI. JavaScript is the natural choice. If needed you should be able to use native UI components - like in Sciter you can use existing HWND based and windowless native components inside your UI. It may not follow Web UI model on 100% (that's impossible) but to be conceptually close so developers can reuse their skills. Web UI model is conceptually close to Mobile one - all application UI is constrained inside single window.
> my number one change would be to add configuration options to the formatting tool you wrote. i can see why consistency is a virtue for large projects, but for me, it is strictly a hindrance.
Yeah, I get that. In personal projects, there's something to be said for just Having It Your Way. But the formatter is focused on ecosystem level improvements where configurability is an anti-feature.
> my second big change would be to allow me to implement a big dart class in two or more implementation files.
You can sometimes accomplish that by moving chunks of methods out into seperate mixins and mixing them into your class. I think mixins are generally underused in Dart. But if that doesn't work, the proposal for augmentation libraries would probably help:
https://github.com/dart-lang/language/blob/master/working/au...
I'm glad you're enjoying Dart!