Live data from Hacker News

Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

developers.googleblog.com

401–410 of 467 posts

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#401

This is the example flutter app for the web - https://www.nytimes.com/games/prototype/kenken#/ This is flash. You can't do anything in it that fills like the web - no copy paste, right clicking causes things to happen. I don't expect games like this to have links and proper bookmarkable urls, but I doubt it'll work as expected if it did. This is the epitome of the problem with flutter - it re-implements the UI, creat…

Also slow.

and unusable on firefox (on my up-to-date pixel c) with it being a bit better on chrome... ipad pro though, actually not too bad in safari (though it makes me wonder about how much of a hit in battery it would cause)

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#402

It feels wrong architecturally for Google to be pushing this right now: 1) Dart was intended as a Java like language and is inferior to Kotlin, a language they just endorsed on Android yesterday. Dart feels like a step back, not forward. The message is confusing from Google on this front. They have a huge Kotlin developer community already. Why push Dart at all? 2) World + dog is moving towards compiling Kotlin and m…

Dart was originally meant to be a superior alternative to JavaScript. They originally wanted native Dart support in the browser (dartium) just like there is native JavaScript support.

Kotlin was/is meant to be a superior alternative to Java.

Java != JavaScript

Flutter I'd say is more like a successor to Flash. Dart is now relegated primarily to being Flutter's ActionScript.

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#403

Earlier quoted context omitted.

You don't download the entire app every time you change directories like you do navigating between sites in a browser.

If you're sending JavaScript down the line with every request, you're doing it wrong and should give up your career.

When you go to a new website, it doesn't download anything?

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#404
post #261

Earlier quoted context omitted.

If you want to do android development, Kotlin. If you want to do multi platform development, flutter. I think flutter will be an amazing tool for smaller teams, especially in non-tech-primary organisations. I work in the public sector of Denmark, we do in-house development, our main focus is the public services we provide though. So there is just no way we can do mobile, desktop and web without something like Flutter…

Why not React / React Native?

When I made the decision in December:

Preference for Dart over JS (lots of reasons, involving language, package manager, compiled performance)

Predictable UI behaviour across devices, OS versions, platforms. As long as you handle presence/absence of device features, and build your UI to scale properly, it behaves as you would expect, everywhere. The value of this cannot be overstated enough.

Future opportunity for code sharing with non mobile platforms. Even without Flutter-web, I could still compile the business logic part of my code to JS and use it with another UI (similar things can be done with React).

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#405

Earlier quoted context omitted.

> This is flash. You can't do anything in it that fills like the web - no copy paste Whereas you would have that in a Canvas or OpenGL equivalent web game? > right clicking causes things to happen. That's already the case for tons of websites, there's support for that in web standards. > There's a reason why flash died out, and it's not only apple. Yes. It was controlled by a single company, IDEs were paid for, it wa…

> It was controlled by a single company, IDEs were paid for, it was more marketed to designer types, and it was frequently slow and used for apps and annoying stuff. So aside from the IDE cost and marketing, there's no difference.

It was also a massive vector for security vulnerabilities.

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#406

It feels wrong architecturally for Google to be pushing this right now: 1) Dart was intended as a Java like language and is inferior to Kotlin, a language they just endorsed on Android yesterday. Dart feels like a step back, not forward. The message is confusing from Google on this front. They have a huge Kotlin developer community already. Why push Dart at all? 2) World + dog is moving towards compiling Kotlin and m…

Dart was originally meant to be a superior alternative to JavaScript. They originally wanted native Dart support in the browser (dartium) just like there is native JavaScript support. Kotlin was/is meant to be a superior alternative to Java. Java != JavaScript Flutter I'd say is more like a successor to Flash. Dart is now relegated primarily to being Flutter's ActionScript.

Either way, it feels like step back. Kotlin compiles quite nicely to javascript as well.

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#407
post #144

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…

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.

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

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#408

This is the example flutter app for the web - https://www.nytimes.com/games/prototype/kenken#/ This is flash. You can't do anything in it that fills like the web - no copy paste, right clicking causes things to happen. I don't expect games like this to have links and proper bookmarkable urls, but I doubt it'll work as expected if it did. This is the epitome of the problem with flutter - it re-implements the UI, creat…

There's almost certainly no middle ground between "use the DOM for everything" and "deploy any possible app on the web". As soon as we decided the web was more than just documents, this was inevitable. Smearing tech that's advancing this pretty obvious idea as "Flash" isn't super useful, and rings hollow when applied to Google tech but not Emscripten, WebAssembly, Canvas/WebGL, or other tech that is just transpiled to JavaScript and can only possibly use web APIs.

If this bothers you, your argument is with Web 2.0, not Google.

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#409

Can someone from the Google team comment on what's going on - https://techcrunch.com/2019/05/07/kotlin-is-now-googles-pref... > Android development will become increasingly Kotlin-first,” Google writes in today’s announcement https://techcrunch.com/2019/05/07/google-launches-jetpack-co... > Google today announced the first preview of Jetpack Compose, a new open-source UI toolkit for Kotlin developers who want to use…

I asked this exact question at the Android Dev summit this last year, and was laughed at

https://youtu.be/FV3iN4PIB5U?t=902

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#410

Earlier quoted context omitted.

Flash was fast. Much faster than JavaScript+DOM at the time. In fact, it was only within the last few years that browser JavaScript and rendering engines became more performant.

Which bit was fast? My wife's MacBook sounded like a jet engine whenever she would play the Facebook flash-based Scrabble. Eventually the machine died of fan failure and I had to spend an entire afternoon doing brain surgery on it. I wasn't surprised when Jobs subsequently banned it from the iPhone!

>Which bit was fast?

Code execution and 2D rendering. What else could I mean?

But there's more. You know how people are excited to see native applications running in the browser? Flash did it in 2008[1].

You think you could run Quake2 with 2008-era JS engines?

You think you could run all those 2D games in 2002-era JS engines (even if had access to a Canvas element - which you didn't)?

>My wife's MacBook sounded like a jet engine whenever she would play the Facebook flash-based Scrabble.

Care to guess why it was a flash-based game and not an HTML5 based game?

[1] https://www.youtube.com/watch?v=vH4p8wzqtuA

Post reply on HN