Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flutter 2

developers.googleblog.com

Post reply on HN
Print view View original

631–640 of 780 posts

Re: Flutter 2

#631

Post by danielscrubs »

murermader wrote: post #116
randomchars wrote: post #35

The idea sounds very appealing, especially to an indie developer: being able to ship your app on multiple platforms from a single codebase is kind of the holy grail. Unfortunately, the result is.... I tested this Flutter example[1], on a 16" MBP with and i7, and it is janky as it can get, it feels like I'm using a 15 year old computer. From the code it looks like the whole thing is... rendered on canvas? I'll pass. […

I just tried it on an iPad Pro with Safari. Clicking the tiles does not work, scrolling does not work with the touchpad, and overall it feels very janky. They probably didn‘t care to optimize / make it usable with Safari.

Here is a dart benchmark:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

I don’t think it’s an issue with Safari.

Re: Flutter 2

#632

Post by pjmlp »

iainmerrick wrote: post #534
buu700 wrote: post #524

Earlier quoted context omitted.

I'm aware of things like the LLVM based C to JS compilers, but they're not really viable for anything non-trivial. emscripten/WebAssembly is pretty viable.

Well, if “viable” means “doable but really fiddly”. C/C++ is fine on iOS (at least when interoperating with Obj-C, Swift is trickier). C/C++ is “doable but really fiddly” on Android, same as web. There’s a compiler toolchain but not much IDE support, and you have to do all the JNI marshaling yourself. So C/C++ is only barely usable for common cross-platform code, and yet it’s the best option . What other language are…

> and you have to do all the JNI marshaling yourself.

After 10 years of Android, while I understand the goal is to force developers not to write unsafe native code, Android team could have already provide better tooling.

However they have always behaved as the NDK was something they had to offer, not something they actually wanted us to use.

Re: Flutter 2

#633

Post by pjmlp »

lordgroff wrote: post #183
yagodragon wrote: post #112

We're all complaining about how js is a bad language, tooling is a mess, and how the web is fundamentally built for documents and makes it hard to create app-like experiences. Now, Google comes and creates a whole new UI toolkit from scratch, couples it with a very beautiful SDK and component framework and offers a far better programming language than js could ever be but we're still nagging. I was also pretty disapp…

Maybe it's just me but I don't remotely think JS is a bad language since es6. Tooling is another story entirely.

Here is the thing, just use script tags without any kind of npm, webpack or whatever is trendy, pure vanilaJS, it is a wonderful experience.

And hey, it might even become hipster trendy eventually.

Re: Flutter 2

#634

Post by clusterfish »

ksec wrote: post #564
clusterfish wrote: post #530

Earlier quoted context omitted.

That's because the current mobile platforms were engineered from the ground up specifically to kill the web in favour of walled garden app stores. We'll have to see how long this approach will stand up for, both legally and technically. With real open source phones and antitrust developments we might see a revival of mobile web eventually.

Even in the extreme unlikely case of opening up Apps without App Store. People will still be using apps. Even if they are Web Apps or Apps with WebView. It will still be Apps. Simply because accessing a button is easier than typing in a link. Web is still great for Discovery though.

How is a home screen app icon different from a tab in your browser, if it leads to what is essentially a web app? I count such apps as a success wrt "betting on the web".

Sadly, the capabilities of PWAs are very much second class on every mobile platform right now. But I don't think it will stay that way forever.

Re: Flutter 2

#635

Post by lenkite »

avar wrote: post #478
ryandrake wrote: post #436

Earlier quoted context omitted.

I don't even fully understand why "cross-platform UI development" is such a holy grail. Is it that expensive to separate your business logic from UI and write the small UI layer in whatever the platform's "best practice" native language is? Is it that hard to find developers who know more than one programming language? With a lot of these frameworks and higher level abstractions, if you go off the toy-app happy path,…

And write your shared business logic in what language? If it's a C library perhaps you could do this on iOS and Android, but how is that going to run in a browser? I'm aware of things like the LLVM based C to JS compilers, but they're not really viable for anything non-trivial. That's why a lot of shops are writing the same logic N times in N languages and frameworks. It can actually be easier than having to target s…

If your business logic is in C - well you are in luck! Use emscripten to compile this to WASM and you can use it in the browser. This approach is very much viable. Large scale commercial web-applications like Figma are written in C++.

Re: Flutter 2

#636

Post by oblio »

Hixie wrote: post #522
oblio wrote: post #474

Earlier quoted context omitted.

It's painting stuff in a canvas and not using the standard web controls. It's the web in the sense that almost every UI toolkit also offers a canvas (for example Tk does this) and you can reimplement every control using it. That doesn't make your new toolkit in a toolkit Tk.

But why would an app that writes to a WebGL canvas be any harder to maintain than an app that uses HTML controls? If anything, it'd be likely to be easier to maintain -- we (the web standards community) are much more likely to change how a particular element is supposed to work than to change WebGL in an incompatible way.

The app? It won't be harder to maintain, yes.

But the framework? That will have to be updated when each OS the framework runs on changes.

The HTML controls are used by a ton of stuff, so they're quite likely to be updated. Your framework? I have to really, really trust you that you'll update them.

Look at how Motif or GTK or AWT or Swing or Tk widgets look on modern OSes. There's an entire graveyard of cross platform UI libraries out there.

Re: Flutter 2

#637

Post by dwaite »

dmitryminkovsky wrote: post #268
qbasic_forever wrote: post #246

Earlier quoted context omitted.

History has shown us over and over again, always bet on the web. Sure you might not like JS as a language, you might find CSS confusing and full of warts, etc. but it's here and will be here 20, 50, and 100 years from now. We're not going to just sit up and throw away 25+ years of progress and history on the web overnight. Tech like java applets, flash, silverlight, etc. come and go like fads. Who knows if Google wil…

> History has shown us over and over again, always bet on the web. This is a mantra on HN. But is it true? I don’t think it is if you’re trying to build a big product mainstream people will use. People want native apps. No one needs the apps to work in 25 years. The web is just part of the picture, an important part, but still just a part.

> People want native apps.

I would argue that people want a certain quality experience. They don't care about whether the developer used Swift or Javascript or OCaml to deliver it.

The Web does usually deliver a certain baseline experience, and most platforms actually deliver a browser which mostly matches platform experience.

For native apps, there is a wide variety of things which you may or may not be able to do based on what the developers implemented and whatever their chosen toolkit supports - including toolkits which reimplement their own drawing, widget and event systems and does not support accessibility or even consistent copy/paste.

For web apps, you do have to somewhat actively have to break this stuff as a developer.

Re: Flutter 2

#638

Post by raze4daze »

xvilka wrote: post #400
reader_mode wrote: post #316

I'm currently 5 months into developing a mobile app for a startup with flutter and my experience so far is very underwhelming. Flutter as a framework is not the worst but far from best, it's very OO while trying to use reacts vdom model which just wants to be functional. The biggest limitation of the platform is Dart - it's a horrible language that should have died once TS and ES6 became mature enough. And I've used…

Would have been be nice if they provided a way to use Kotlin Native as a language for Flutter instead. Not a JVM Kotlin of course, because it's too slow for the native mobile apps. Or, even better, Rust. That would be very impressive.

JVM Kotlin (or Java) is more than fine. Rust sounds absolutely dreadful for front end. Let’s not go down that path.

Re: Flutter 2

#639

Post by c-cube »

munificent wrote: post #571
oblio wrote: post #269

Earlier quoted context omitted.

Let's say you get a JSON API that sometimes returns a list, sometimes returns an object. How do you model that in Dart?

Yes, union types are really nice for data like that. But, in practice, a language's type system tends to optimize for the data structures that are idiomatic in the language. TypeScript is a heavily structural type system because idiomatic JavaScript often throws together unrelated types in this way (which makes sense when you're coming from dynamic types). In a language that is built more strongly on objects and stat…

People build less unions because these languages fail them. Just add sum types or something similar, it's a disgrace to not have them in 2021. Static typing goes wonderfully well with them, allowing for exhaustiveness checks and all that.

The "people use fewer unions in Java" argument is like saying people used fewer lambdas in Java 1.6. Build it, and they will use it.

Re: Flutter 2

#640

Post by mda »

danielscrubs wrote: post #625
Dylan16807 wrote: post #294

Earlier quoted context omitted.

> crappy tech What kind of an argument is this? Not wanting to learn all those things for multiple languages is valid. But "it would take a while" doesn't tell you anything about whether a language is crappy. The odds are pretty close to 50:50 that the language you already know is the crappier one.

Here are some benchmarks: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... The Dart implementation seems much slower than the NodeJs implementation and it doesn’t bring anything new to the table? It added null safety today. Anyone that knows if it has any feature beyond for example what Ocaml has?

Uuh the benchmarks in this site is very misleading (for all languages). Do your own tests otherwise the numbers there are practically meaningless.
Post reply on HN