Flutter could be a fantastic solution if it supported native controls and used JavaScript. I don't understand why Flutter's creators are so seemingly religious about Dart and reimplementing OS UI capabilities.
Flutter could be a fantastic solution if it supported native controls and used JavaScript. I don't understand why Flutter's creators are so seemingly religious about Dart and reimplementing OS UI capabilities.
For me -- I am using Flutter to build internal productivity tools available on multiple platforms (web, desktop, mobile). Users do not necessarily care if the application looks pixel perfect (but, still, Flutter is definitively an improvement from Oracle Forms :)
What users and the management does care, on the other hand, is that the features can be delivered quickly and on multiple platforms.
They do care. They just don't know the words "pixel perfect".
However, everything is an improvement over the standard state of corporate UIs
Have you measured it, or did you stop after the Form A Hypothesis step?
Flutter just recognises that.
It's a bit more messy to do that with Android Framework, and because of that I see more of an argument for using Flutter there than on iOS. Jetpack Compose seems to be a lot better in that regard though.
I personally dislike the whole JS ecosystem with a passion, and feel I'm not alone in this, so having an alternative is warmly welcome
The only real way to escape this at all is to settle on the browser as your runtime, so there's a certain irony to what you're saying.
1. Installing Flutter 2. flutter create 3. flutter run
Instead of installing/configuring/setting-up npm, typescript, eslint + rules, react + rules + types, prettier, react-native-web + rules + types, a rendering framework + rules + types, webpack, jest, and whatever else.
You do, basically, get it for free.
Again, it's definitely not free (or "basically" free, either). Step 1 negates that statement. You have to set up a development environment. It takes some non-zero amount of effort.
In contrast, the browser is already there. It already runs JS. You don't have to do anything to make that happen[1]. And in saying it takes nothing, that's not merely "basically" nothing; it's literally nothing.
> Instead of installing/configuring/setting-up npm [and a bunch of other crap]
What if I told you that while you're free to opt for doing any/all of those things, none of it is actually necessary, let alone a good idea? (Or point out that TypeScript is not even JS, for that matter?) That you're totally allowed to ignore the GitHub busyworkers and write actual (i.e. straightforward, standards-compliant) JS—in contrast to much of what's available for NPM/NodeJS, where you are most often encouraged to write "JS" that's incompatible with what's in the standard (and what the browser makers actually implement)?
1. <https://www.colbyrussell.com/2019/03/06/how-to-displace-java...>
There is a reason people made these countless frameworks and solutions, but the benefit Flutter provides is it's an out-of-the-box fix, and yeah, installing some software and running two commands is an out-of-the-box fix.
In addition, the entirety of your argument just flat-out ignores the cross-platform aspect of it, targeting only the browser instead of mobile and desktop platforms as well.
> You have now transitioned from saying that you don't have to spend as much time to set up a development environment to saying that it is pretty much free, which is even odder still.
I truly don't understand this odd exercise in linguistic gymnastics, as these are both simultaneously and entirely true. You can resolve this yourself.
And yes, it's still (basically) free.
Nope.
> This is the oddest argument of all (I can use that word too)
Oh, boy. That sounds bad. I guess it's a good thing that's an argument I'm not making it, then! (Also: I didn't use that word, FYI.)
Are you sure? The "whole JS ecosystem" you're aware of is likely to be the trendy (e.g. NodeJS+NPM) one*, which bears indicators at just about every turn that many/most of the folks working in it don't actually like the language themselves which results in lots of their energy being spent trying to fight with it which in turn produces the sorts of things that I'm guessing you like least. (For example: `package.json` is a tastemakers' invention and didn't appear anywhere in the spec.) This gives a skewed impression of what JS really even is; the dominant culture you see on GitHub is not the inevitable outcome of settling on a decision to standardize on JS.
(This isn't to say that the suggestion from the original comment you're replying to was a realistic/reasonable one in context.)
* in other words, not the "whole" JS ecosystem—you probably aren't looking at use of JS in, say, Gnome for example
I think Dart's history might be relevant here. Flutter was unveiled at a 2015 Dart programmer conference (https://www.youtube.com/watch?v=PnIWl33YMwA) and it was originally called Sky. Dart doesn't exist because of Flutter, it's the other way around.
Dart was originally intended to be a replacement for Javascript back in 2011, but it utterly failed to gain any adoption because about a year later in 2012, Typescript came out. Typescript being a superset of JavaScript I think completely destroyed any chance Dart could catch on for its original web development goals, since you didn't have to dump JS entirely, just rename .js to .ts and gradually start type-hinting code. Even within Google, they abandoned Dart for Angular and went all in with Typescript.
In a way it's refreshing to see Google re-tool an existing language, rather than invent a whole new langauge for cross platform app development, seeing how often as a company, they kill off projects quickly and start whole new ones.
This rarely happens though, and I wonder if it may have to do with the limitations of the technologies often chosen to do the implementing with, or if it's more of a philosophical thing with the projects in question not holding themselves to high enough of a bar.
Me too, and I’m surprised how okay with it people seem to be. What are the odds that Google to continue to support the latest platform UI changes? What about five years from now? How much effort is it to get good accessibility support vs native controls, and how likely are developers to do that?
The whole approach seems wholly dependent on Google continuing to give a shit, and as we’re all aware they don’t have the best track record there.
This attempt to draw every single control is too much effort with apparent inconsistencies.