Flutter Desktop Isn't There Yet

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • Appwrite - The Open Source Firebase alternative introduces iOS support
  • SonarQube - Static code analysis for 29 languages.
  • InfluxDB - Access the most powerful time series database as a service
  • Flutter

    Flutter makes it easy and fast to build beautiful apps for mobile and beyond

    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.

  • Appwrite

    Appwrite - The Open Source Firebase alternative introduces iOS support. Appwrite is an open source backend server that helps you build native iOS applications much faster with realtime APIs for authentication, databases, files storage, cloud functions and much more!

  • language

    Design of the Dart language

    > 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:


    I'm glad you're enjoying Dart!

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts