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.
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.
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.
There was some Dart web framework churn before they settled on AngularDart.
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.
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.
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.
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 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.
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.