No one has (yet) mentioned the main reason I ignored Flutter when it initially came out and why I continue to have reluctance - It's google. They have a terrible track record with products AND with libraries. GWT? Dart (pre flutter)? NaCl? How about all those initial Angular devs?
That's not a statement on the quality of the result (though some of those examples do indicate concerns), but if I'm not alone in avoiding a product that tackles a real industry need because of the source, that's a bad sign.
GWT lived for over a decade (how many web libraries do you know that have survived for for that long?), AngularJS is still in maintenance mode, Dart died when it didn't get browser support and Typescript was obviously the better alternative.
At the end of day though, I look at if Google itself is using it extensively, because that's when a library will have the best support/longevity.
It hasn't seen a release in a while because the developers contributing to it have been working on making it work with Google's recently open sourced J2CL compiler. From what I've read, builds of though are available but no official release yet.
I use React and Angular these days, but even back in 2010-2011 GWT felt pretty "done". At least for the things I needed to use it for.
Starting a new project with it now probably wouldn't be a career-enhancing move, but it was a pretty decent way to build really complex web apps at a time when the JS ecosystem was a lot less mature than it is now.
What source would you prefer an open source UI library come from, that would avoid this concern?
Open source software lives and dies with adoption. Starting off with a (paid) development team, marketing team, and large initial user base (google internal) puts a piece of software in a good starting position, but doesn’t guarantee success.
Disclaimer: I work at Google, though not in a Flutter-related role.
Not the OP but I've quite a lot of trust in Microsoft when it comes to long term support and stability of their frameworks. They have their problems, but when they commit to something it's usually supported and stays around.
> What source would you prefer an open source UI library come from, that would avoid this concern
Note: "this concern" is not "the library may go away or be unsupported". That's true of any open or closed source library.
The concern specifically is "this may get hyped to the point where it feels reasonable to depend on, then go unsupported". And that's never a surety, but frankly Google makes it MORE likely than, say, some random internet package that it will build enough of a groundswell to be seem safe, then suffer a sudden Nest-API-like strangulation. (Convenient for my argument that that announcement came out between my original post above and this one, but it's convenience that is directly my point).
Some rando package is unlikely to be broadly adopted unless it's actually good stuff...and the good stuff tends to get well supported, even if that means the occasional fork. Google has name cachet that can build support quickly, but the track record doesn't support that.
There's never a guarantee...but there are performers that are above average risk, and that's where I put Google when it comes to APIs and libraries.
I am excited by the Quasar framework, getting ready to launch their version 1.0. The vision is to simplify the Vue stack and automates and simplifies the onerous elements of webpack, linters, tree shaking, etc. It uses Material for UI and lets you push the same code to IOS/Android (via Cordova), desktop (via Electron), PWA and SSR.
What sold me on the framework is the focus on good documentation and sensible defaults. I could use more example code, but for its youth the framework is very exciting and has really made picking up Vue much more straightforward.
You didn't even mention the Closure library which was released and then practically abandoned. We invested so much into Closure where I worked, with the promise that this is what Google used internally, when suddenly Angular dropped out of Google and that sucked up all the oxygen in the room.
Looking at the changes and fixes in recent releases of the Closure library, it sure doesn't look abandoned or even practically abandoned. I think I understand what you mean though. The Closure library looks good at what it does, but doesn't have a big ecosystem around it like React or Angular.
I remember looking at the Closure library back in 2010 and decided against using it, but from what I can see it still looks pretty decent. It doesn't look as nice to use as Angular or React, but it's been around a lot longer than either of them and probably has to remain backward-compatible with some pretty old code.
Closure user here! 2019 and I still love it! Yes, it's verbose but easy to understand what's it's doing... My project compiles ~1000 js files down to ~300kb. Works great with bazel. No better type system for javascript IMHO. :)
I mean, okay, but which other things that you would have selected would still be a good choice today? Would you be happy if you'd gone with Ember or Backbone?
Yes we looked at all of those as well as Sproutcore. There weren't a lot of good options. Lots of people were using ext.js and yahoo ui library and dojo. Closure was among the better options at that time.
Not to mention the maintenance required for a project of this size. You have to maintain emulation of the UI for multiple environments. When those update, you have to update. Imagine a new iOS release coming out and all other native apps on the market look new and everyone sees your outdated app trying to look native. Now imagine Google putting that on the backlog, never updating the iOS controls in favor of Material. The team has to maintain this emulation for iOS, Android, Windows, and MacOS. This is unreasonable for any company, let alone one with a track record of abandoning projects.
For the record I believe Flutter is here to stay, but I don't believe for a second they'll keep the "native look" around for anything other than Material design. It's a marketing gimmick to get their foot in the door and then transition everyone over to their own design.
That's not a statement on the quality of the result (though some of those examples do indicate concerns), but if I'm not alone in avoiding a product that tackles a real industry need because of the source, that's a bad sign.