[yagodragon]

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 disappointed with the demo at flutterfolio.com that is supposed to show how great Flutter 2.0 for the web is. It's not that good but it's gonna get there eventually, given the hype around wasm and <canvas> technologies. Not to mention that Flutter is already better and easier to use than the existing native tools for both Android and iOS. I believe Flutter is an extremely ambitious project and I appreciate that Google is really trying to give an answer to the problem of cross-platform UI development.

[jaegerpicker]

Are you a native mobile developer? I am (was I'm moving to ML/AI/Data engineering) and I don't think flutter is in any way easier or nicer than the native toolchains for mobile. Both Swift and Kotlin are better languages than Dart IMO, the IDE and tooling is far superior for both also. Flutter is faster but once to deploy a substandard quality of app for sure but matching the quality of a native app? That takes just as long in Flutter as building a native app in each tool chain. I've built apps in React Native, Flutter, Ionic, and Swift/Kotlin. I'd reach of Swift/Kotlin for developer experience, performance, and quality of app EVERY time.

[gurkendoktor]

I am a native app developer. I have only built one small app with Flutter. Here's where I disagree:

- I've used Xcode since version 2 and like it, but in my opinion it's a worse developer experience than Flutter. Refactoring and code navigation were much better in both Android Studio and VS Code.

- Flutter's hot reloading is fantastic. Meanwhile, SwiftUI previews seem to be built on the same technology as IBDesignable, that is, they're just barely stable enough for a short WWDC demo.

- I am very sensitive to non-native controls on macOS, but UIKit doesn't even have a standard button class, the first thing that everyone has to reinvent (Apple included). I wouldn't pick Flutter for business apps with loads of text editing, but it feels perfect for social game-ish apps, like QuizUp or Duolingo.

- In my experience (German freelancing market), the typical native app developer does not care about the user experience anymore. Ever since RxJava and Swift have hit the scene, the focus has moved from impressing the user, to one-upping your coworkers with exotic language features and avant-garde architecture patterns. Dart is a dumb language like Go, and I think that's exactly what's needed to bring UX back into the spotlight.

[nsainsbury]

I'm a native app developer too (iOS and Android) and I've got some experience with Flutter.

I agree with most of your comment, but the only thing I'd add is that from what I've seen if your concern is the quality of apps then Flutter definitely is not where you'll go to find that. If anything, Flutter developers seem to care even less about the end-user experience and instead simply focus on their own productivity. The end results are often horrible with a ton of jank, UI weirdness, etc.

[mwcampbell]

> but UIKit doesn't even have a standard button class

Doesn't anyone else use UIButton? Granted, the native iOS app I developed was intended primarily for blind people, so I didn't really make it visually polished.

[gurkendoktor]

Yes, the visual polish is what I mean. It's not rocket science to style UIButton, but the lack of a good default style means that mediocre native apps often have weird/inconsistent highlighted button states, and so on.

[saagarjha]

But at least they are semantically buttons and not the UI equivalent of a <div> to VoiceOver…

[EvilEy3]

> Dart is a dumb language like Go

Dart literally has reactivity build in, like RxJava or RxSwift. You have no idea what you're talking about.

[gurkendoktor]

And because it's built in, unlike the bolted-on Rx framework family, it doesn't bother me much. I found the language to be much more focused and pragmatic than Swift, but as I said that was just my experience after a single project.

[jpsoft]

I am, and I agree, native toolchains can be better but that is expected, they have a lot more resources dedicated to their development. I also am responsible for an app built using flutter, it's been on production for almost two years with a very good rating in the app stores and over a hundred thousand users, isn't that what matters? that the technology enables you to solve problems? Flutter did that for us, keep happily working on Xcode if that works for you, for our startup this announcement is great news.

[awesomepeter]

If you had to pick a multiplatform solution (for whatever reason) which one would you pick? I've been exploring this space a bit, and it's really hard to form an opinion on this.

[jaegerpicker]

I've been in that situation 3 times, I choose React Native and Flutter each once. I was forced to use Ionic. I would NEVER use Ionic again, terrible experience and very difficult to get decent quality/performance. I like Flutter's technology much more. I like that it is natively compiled. I dislike that it has it's own UI toolkit. React Native with TypeScript is a highly productive environment but I LOATHED the developer experience and any code that had performance goals was way harder to be successful with, not impossible but the threading model that RN imposes (it doesn't really thread at all) was hard to make the UI snappy and crisp as it should be. I've played with Xamarin also since I was a .net dev for 10+ years (I'm old in the industry 25 years now) and the developer experience was actually pretty good but the compile times and the UI performance were not. Though that was not a production level app and I might have been able to make it work.

tldr; If I HAD to do cross platform I'd use the following logic to choice one: If I have a team of react JS/TS devs: React Native else if I have a .net team: Xaramin else: Flutter

Then I'd apply for a job writing native apps in Swift/Kotlin and run away ;)

[yesimahuman]

Sorry to hear you had a bad experience with Ionic. The stack has improved considerably in recent years and actually Capacitor, our replacement for Cordova, was just rated the highest satisfaction mobile tool on the latest State of JS survey. Cordova was definitely a sore spot for Us but we’ve since moved beyond that and you can use any web stack to build apps with Capacitor (seeing a lot of React + Next.js apps of late)

[claytongulick]

Out of curiosity, what version of Ionic were you using?

Ionic 4+ is a complete rewrite from the ground up to use web components.

I use it in a non-traditional way, I do vanilla js + lit-html + web components and it works great.

Performance is smooth, mobile first approach makes responsive apps straightforward.

I don't do any of the native things or command line app creation or any of that.

I've been generally pleased with it.

[rubicon33]

> a job writing native apps

Sadly, a shrinking market day by day.

[neverartful]

This area is one that I've been pondering for a long time. In my view, the most sensible approach is to abstract the entire UI and write to the abstracted UI. Then you write the translation piece in whatever toolkit(s) and platform(s) you care about (and in whatever language is most appropriate). This hard separation of the platform and toolkit opens the door for some nice benefits (cross platform being the first and most obvious).

However, the benefits don't need to stop with cross-platform. By adding location independence to the non-application part of the code, you get the flexibility to decide later (even after the application is written) whether to deploy it as a "fat" app (application logic running locally) or "thin" (UI commands and events routed over network to your app running on a server).

I've been experimenting with these ideas for years and it's all doable. I've done various UI/toolkit implementations such as: Cocoa/ObjC, Gtk/C++, wxWidgets/C++, win32/C++, Delphi VCL/Pascal, HTML/JS, Java Swing, Java SWT, etc.

I look forward to being able to share publicly (once I decide which license to use).

[pjmlp]

If if a CRUD frontend for data, just go with mobile Web.

If doing games, Unity.

If I require some native access, Xamarin.

Finally, using C++ in a MVVM approach with native Views for anything else.

Those answers are for personal projects, at work we just do mobile Web, and with Chrome and Chrome Edge teams pushing the agenda of Web APIs =~ ChromeOS, we get to do most of the stuff we care about.

[JamesSwift]

If you know the native platforms then Xamarin.Native. Shared business logic, platform-specific UI. Over time create your own Xamarin.Forms like DSL to do shared UI.

[tofuahdude]

What are your thoughts on the business end of deciding to build two separate versions of the app in two languages (not to mention the web) vs the efficiencies of one code base?

We're close to needing to make this decision and I'm real hesitant to introduce two additional languages (we're already React for the web but haven't build apps yet) vs a React Native app where our team can be immediately productive.

[pianoben]

We made this choice at Rdio back in like 2012. Our mobile apps were written almost entirely in C#, shipping on iOS, Android, and even Windows Phone 7/8. About 70% of the code was identical on all platforms, even the super-hairy audio bits. Contrary to the prevailing notions at the time, our app had native levels of quality and performance. We could roll out a new feature an all platforms in only a little more time that it would have taken to do it for one.

That agility didn't come for free, however - we gained speed, but also traded routine bugs for exotic ones. In addition to simple null-pointer errors and the like, we got to spend two weeks digging into the Mono runtime to find a locking bug that drained users' batteries. We had our own sqlite wrapper because the built-in ones on Android and iOS had too many incompatibilities. We had our own red-black tree, for some godawful reason. We had a standing weekly call with our Xamarin reps to discuss toolchain bugs.

Ultimately, the pain ended up outweighing the savings of sharing code. At the time Rdio went bankrupt, we had substantially rewritten the apps in Java and Obj-C. RIP.

[vorpalhex]

I was with a team that went the React Native route. At first it was fine until we had to go slightly off the rails.. and I was rebuilding .so files based off random gists and updating linkage assemblies.

React Native works until it doesn't and then you are getting into very detailed platform specific territory.

A lot of the cross platform promises were untrue - we quickly learned the importance of QAing both builds and frequently had platform specific patches.

Just bite the bullet and go native upfront.

[iainmerrick]

I have had the exact same experience. I’m not a big fan of React or React Native, but I can see that it does increase code reuse; but...

As you say, platform-specific glitches will always crop up so you’ll always need a bit of native work. If you’ve thinned out native development team this can make things hard. Instead of a team of 5 or 10 native developers working on bread-and-butter UI stuff, you only have enough work for 1 or 2, but it’s all grungy stuff like talking to low-level frameworks and working around platform bugs (or React Native bugs, of which there are plenty). That’s not a recipe for clean and maintainable code.

A related issue is that React and React Native aren’t 100% compatible. You can’t just move existing React code directly over as you might elect. It is possible to write code that works on both, but it isn’t trivial.

QA definitely needs to be done separately on each platform.

[The_rationalist]

Or give Ionic react a try

[vially]

I would not recommend Ionic. I've been using it in a medium sized app for about 3 years now and I get the feeling it's good for getting started, but once your app grows past a certain size it's starting to create more issues than it solves.

Some examples from the top of my head:

- various performance issues (e.g.: memory leaks which haven't been fixed for years [1])

- their push/pop router navigation seems like a really bad idea

- worse developer experience than using Angular directly (e.g.: last time I checked this, the save/compile/reload cycle of an Ionic project was an order of magnitude slower than the same project without Ionic)

[1] - https://github.com/ionic-team/ionic-framework/issues/19242

[yesimahuman]

This heavily depends on the framework you choose to use, and modern Ionic uses the stock tooling your framework does, so build times should be on par with any other project of that framework type. Earlier versions of Ionic had custom tooling and much slower build times.

[bliteben]

-the push/pop router navigation is insane, it by default keeps all views in memory all the time for react it will reload every view with any state change by default.

[The_rationalist]

Interesting but is this still the case on recent Ionic releases?

[joe_fishfish]

I am a native mobile developer, and I am presuming GP is most definitely not, because I completely agree with you.

[ksec]

I have seen this a lot. Most of those people are Web Developers. They want their Web technology to move towards cross platform native apps. And are frustrated with people bashing or stopping this progress.

On the other hand you have Native Apps developers, while equally being excited about Cross Platform UI and toolset have been burned more than enough. And this didn't even start with Smartphone. It goes back to earlier PC history with Java or even further. None of them were good enough.

At the same time Native Apps developers dont understand why Web Dev or those who has Web Dev background now working on cross platform toolchain constantly push and produce the same thing years after years.

You cant blame them for being skeptical.

[Aduket]

why do you move to ML/AI/Data Engineering from Mobile?

[The_rationalist]

What do you think of jetpack compose? It has reached beta and there is experimental desktop support

[MrDresden]

As a native Android developer (who is also doing Flutter atm) I look at compose as a seismic shift in the Android space. Flutter wont be able to compete

[qbasic_forever]

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 will even care about flutter in 5 years, let alone 25 years. A page that Tim Berners-Lee wrote 25+ years ago renders just fine in a browser today.

[eseidelGoogle]

[Flutter Eng. Dir here]

I guess I would like to think we are betting on the web. :) All of the Flutter founders came from Web backgrounds. After years of attempting to make the Mobile web awesome, we forked Chrome and built a new thing. Now we're bringing it back to the Web.

The web is a big tent. I think there is a lot of room for innovation here. We're attempting with Flutter to push on some of the newer aspects of the Web. There are still some pieces missing from the Web to make things like Flutter really shine (e.g. a multi-line text measurement API could help get rid of a ton of code in Flutter Web). As you saw in the keyonte today, we're working with Chrome to continue to improve life for developers.

I don't think Flutter will ever be the right solution for all of the Web. Certainly not today. For example, we don't even support SEO or great indexability yet (although it's long been planned for and will be coming soon).

I just want to believe we can do better. We, developers, can all push development (including the web) to be better. Hopefully Flutter will do it's part.

[bsaul]

Read somewhere flutter canvas rendering was only a first « quick n dirty » way of rendering something on the web, but a true DOM renderer was the end goal.

Can you give more info on that ?

Another question i’ve always had about flutter : last time i explained how this tech looked promising, a friend asked me about performance. I said « they said it’s really good and smooth ». But then we tried the iOS demo app (something very basic about vegetables) from the app store, and the scrolling performance was a total disaster (on an iphone x).

Do you have an explanation for the discrepancy between the official ad one can read on google blogs, and the real-world experience of app developped with flutter ?

[didibus]

When Chrome has become synonymous with the Web :facepalm:

[ironmagma]

You have to fork something, you can’t just fork the web as it is an abstract noun.

[miohtama]

As long as you manage to recreate Flash game ecosystem you will win alone on it.

[dmitryminkovsky]

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

[muxator]

> People want native apps.

I'll take a well done web page anytime over a native app.

[EvilEy3]

> well done web page

That is an oxymoron.

[ironmagma]

People want native apps for some domains. On my phone, I typically want the opposite. Every company has to have its own app, and it’s annoying. I do want Flux, because that functionality can’t be done without an app. I don’t want a terminal in my browser because that would be ridiculous.

Blanket statements don’t work.

[alexhutcheson]

> I don’t want a terminal in my browser because that would be ridiculous.

Secure Shell[1] is actually my go-to terminal for daily use, and supports some features that are important to me (e.g. OSC 52 codes) that GNOME Terminal doesn’t.

[1] https://chrome.google.com/webstore/detail/secure-shell/iodih...

[dwaite]

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

[qbasic_forever]

The same engine of HTML + JS has powered entire businesses and industries from $0 to billions and billions of dollars over 25 years. Amazon.com would not exist without web browsers, and its entire trillion dollar+ business is an enormous bet on the web. I would say there's zero danger of the web going away when folks like that (and many, many more... Google, Facebook, etc.) depend on the web for every microsecond of their existence.

[ksec]

>Amazon.com would not exist without web browsers, and its entire trillion dollar+ business is an enormous bet on the web.

Except 70% of e-commerce, 90%+ of Social Media are now on Mobile Apps, where they were all previously 100% Web.

The problem with Tech industry is that too much thinking is about centralised, decentralised, Technology with backend front end. etc. When its users or customers dont give a fuss at all.

[clusterfish]

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.

[ksec]

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.

[dmitryminkovsky]

If today FAANG had to choose: shut down your websites or shut down your native apps: which would it be?

Which platform did Clubhouse build out first? Why?

[BorisEm]

For Facebook and Apple, mobile (native) is definitely the most important.

Advertising accounts for 99.9% of Facebook revenue, with mobile advertising accounting for 94% [1]

Not sure for the other ones.

[1]https://www.businessofapps.com/data/facebook-statistics/

[qbasic_forever]

Clubhouse is targeting the middle-class silicon valley market right now (quite literally, those are the only people who got invites early on), who of course are infatuated with apps and have the money for fancy phones, tablets, etc. It's smart marketing for them to go where their customers are right now.

The web is for everyone--I can go to an internet cafe in a slum and browse and buy from the same Amazon.com as I can from inside a $15M mansion. It's a quantum leap in access to the world using the web.

[dmitryminkovsky]

Not sure what personal income has to do with anything. Hand held touch devices have revolutionized Internet access. The deeper down the income scale you go, the less likely you are to encounter a personal computer while you’ll still likely encounter a smart phone. Amazon will work on the web or as an app on that phone, but with the app the user experience will be better. That may be because Google and Apple have intentionally prioritized native APIs while hindering PWAs, but that’s still the case.

Anyway, I do still wonder: if FAANG had to pick between native and web apps, which do you think would they pick?

[didibus]

They can collect more metrics and have more control when it's a native app. My web browser is still my most used app on my phone.

But I think betting on the web actually meant to bet on native for each respective platform. Bet on native for the web is betting on HTML/CSS/JavaScript. And then have a Java/Kotlin version for Android. And have a Swift/Objective C version for iOS

I think the learning is, write once run everywhere is what has been tried and failed time and time again for user applications. Java failed many times, Silverlight, Flash, etc.

The reason is always the same, user experience is limited when you go that route, and it eventually loses out to competitors who offer the better user experience on the user's platform of choice.

[amelius]

> People want native apps.

Only because OS vendors made them believe that.

[jaegerpicker]

Or maybe because native apps are a better experience, nearly every time. True multi-threading, native code performance, latest UI implementation, more and better hardware access/performance, etc.... I can keep going but the point is that the web really is the lowest common denominator. That isn't bad but it also isn't how you build the best experience.

[amelius]

If OS vendors wanted web-apps to succeed, they could have done a lot more than they have done so far. E.g. better integration, or improved web standards to optimize for certain cases.

[dmitriid]

No matter how "better you integrate", there's one big core issue: the DOM. You simply cannot make the DOM behave as smoothly an as reliably as a native app. And no, no amount of "improved web standards" can help with that.

[EvilEy3]

Why would they want that if they can build native SDK and won't be tied to anyone else?

[dmitryminkovsky]

That is my understanding as well.

[peterstensmyr]

I generally agree with you, but I don’t think it’s unequivocally true. Facebook bet on the web/HTML5 for their iOS app, and Zuckerberg later referred to it as the company’s biggest mistake.

[ksec]

That was because he trusted his engineers that believed in ideology rather than objective and rational evidence.

Wanting / Loving something to succeed is one thing. Whether it will actually work or succeed is an entirely different matter.

[munificent]

> History has shown us over and over again, always bet on the web.

For what it's worth, people had the exact same mantra about internal combustions engines for decades any time someone brought up electric cars.

You're absolutely right that entrenched systems are hard to change and attempts to change them mostly fail... until one succeeds.

[someguydave]

I will gladly throw away 25 years of “progress” because it is just programmer busywork and monopoly lock-in.

[tamrix]

Google does have a history of ditching tech that, to them, doesn't work out.

[mdoms]

I just visited flutterfolio.com. The very first thing I tried to do is enter a username and Tab to the password field. But Tab just catapulted my input focus to the browser address bar. I mean, come on.

[danShumway]

The accessibility is a bigger concern, but flutterfolio.com also

A) lags on my work machine when tabbing through fields

B) doesn't handle HDPI screens well (the entire interface looks blurry)

C) keeps fields visually indicated as selected even when I click outside of the browser (if I start typing, is it going to go into the field or not?)

D) has a separate touch mode? Touch doesn't just work?

Looked up another of their sample apps:

A) doesn't respect my OS scroll direction

B) lags on scroll

C) mousing over any of the buttons has a 0.5 second delay before my cursor turns into a hand icon.

And all of these sample apps take about a second to fully load for me, despite the fact that most of them aren't doing anything complicated.

The "we can rebuild the browser in Canvas" idea is alive and well in GUI toolkits, but I have never seen an implementation that didn't have these kinds of basic problems. How many UI toolkits do we need to see that can't figure out how to do scrolling before we acknowledge that having one team try to independently reimplement decades of work on the web might just be a bad idea?

[eseidelGoogle]

[Flutter Eng. Dir. here]

I really appreciate the feedback. We clearly have more work to do on the Web side of Flutter. Unlike the Mobile side which has shipped 100,000s of apps, the Web side may be up to like 1000. :) So many more issues to address as we work closely with more users to get their apps into production.

If you'd like to track progress on any of these, I'd encourage you (or anyone else reading) to please file issues at flutter.dev/support. We read (and try to address) each and every one which comes in via Github.

[rektide]

The CanvasKit renderer[1] is highly concerning to the general health of the web. It's nice that it's easy for developers, but it remove all the power of the web.

To an end user, their accessibiliy tools, & user extensions, the page might as well be VNC'ed in to some system. Everything is opaque. There's no HTML elements.

I can not state strongly enough how immoral & unethical this path is. Bending the web to the developers will & breaking all the contracts of what a web page is a grevious act, is enormously harmful. This is one of the worst possible things that could happen to the web. Please for god sake don't do this to us. Don't injure the web like this.

This will be raised again and again and again until the ends of time as an incredible black mark on the name of Flutter.

Edit: constructive feedback welcome. Whether it's me or others, folks pointing out this peril often find themselves hit by downvotes as I do now. This seems like an existential challenge for the web, to keep humans able to be in the loop when browsing the internet. We would all love if you would defend or explain or have something to offer in your critiques about this crisis.

[1] https://flutter.dev/docs/development/tools/web-renderers

[jitbit]

Yes, my knee jerk reaction was just like yours.

But... think of this as new Adobe Flash. Or a new MS Silverlight. Some people use it, mostly for privately hosted local apps. Most people won't.

PS. And then Google will probably kill it anyway

[danShumway]

I appreciate that building something that works even this well targeting Canvas must have been a metric ton of work, and I'm impressed. But that's kind of the issue -- it cannot possibly be more work to maintain a separate rendering/compilation pipeline for browsers than it is to rebuild the entirety of Chrome's DOM engine in WebGL for CanvasKit.

I just don't see how Flutter is going to keep pace with "native" web apps when the team is constantly playing catch up every time a new medium, input method, or browser feature comes up.

Handling scroll is hard enough, is this going to handle WebVR? Can I control this web app with a voice assistant?

Sorry if this is something of a dismissive answer, but I'm not sure what the right way is to file an issue that boils down to, "it seems like you picked literally the hardest possible way to build a web GUI toolkit, and I'm very impressed that you have anything that's usable at all, but I also don't understand why you did this."

I don't know, I don't want to be overly negative here, but I don't have any confidence at all about the overall strategy that Flutter is pursuing. In order to get accessibility to work, you're basically going to end up building a DOM representation of these apps anyway. It's just now you have to build a DOM representation and you have to completely reimplement the rendering stack and capture all of my events? How are you going to make something like that performant across every browser?

I want to echo a few other comments I've seen here that this result isn't really surprising to me. I guessed before I clicked on the demos that they probably wouldn't handle scroll events well, because I know how you're building Flutter for the web, and I have never seen any GUI frameworks targeting pure Canvas on the web that don't have basic errors like this. If Flutter ever managed to be the exception, that would be very surprising to me. I don't know what Flutter's internal process looks like, I'm not going to tell you you're building something wrong. I only know what the end result looks like, and I know that end result is not going to radically improve any time soon.

It's not my place to tell any team what to do, and nobody is obligated to care what I think, but... I don't know, the demos online do not leave me feeling confident about Flutter's future. I don't think the experience as it exists today is the result of a bunch of isolated issues/bugs that can be fixed one at a time.

[oscargrouch]

Its nice to have absolute control of the rendering going over canvas if you are a flutter platform developer and i think even playing the catch-up game they should get there eventually.

But i don't think this is the real issue here.. Flutter is more of a Flash and GWT lineage, and that's fine if that's what you are looking for.

But i bet on the Web every time, its the most popular UI (and now much more) platform ever. So while some will go through the Flutter and React way of doing things, most will just stick with the web.

The web is the most sophisticated platform ever built. It gives you a lot of power and freedom, so i don't understand why some prefer to get stuck into a cubicle when you have so much space?

Its nice to have frameworks to make things easy and developers more productive, but the ones that do this without alienating the developer from the bigger, broad and sophisticated framework are just better.

Just let them be the new Flash, now at least open and over the web, and look for other approaches if you want to maintain real control and freedom, instead of delegating to the platform developers.

[saagarjha]

The price of infinite freedom in UI toolkits is that you get nothing for free. This has consistently been untenable: you quickly get stuck in the weeds reimplementing basic behaviors.

[themacguffinman]

Supporting new and unique APIs/inputs/etc like WebVR is a pretty classic cross-platform problem and it's usually addressed by allowing native hooks. Flutter has MethodChannels which let you call native methods in the underlying "platform host". It also supports "PlatformViews" which let you embed native widgets.

It doesn't really need to have instant parity with "native" web apps at everything. Maybe Flutter is a poor fit if you have extensive native requirements. That's okay.

[danShumway]

It's not just about building special experiences. I want to be able to browse normal websites in VR -- VR and uncommon user agents introduce a new set of user inputs that Flutter will need to handle if it doesn't want its websites to just break if someone loads them up in a headset.

Currently as a web dev, if I want my website to be usable by a voice assistant, I don't have to do anything. If I want my website to be usable in VR, I don't have to think about it -- that's Chrome's problem, not mine, I just expose the exact same controls I've always used. If someone is building a user agent that interacts with my site in a novel way, as long as I've built my site well everything just kind of works, because of how the web is architectured.

But if you're rebuilding all of the controls from scratch, suddenly you can't think that way anymore. You have to think about the controls and gestures that every medium exposes, or else you have a website that just randomly breaks depending on what OS/platform a user accesses it from.

> and it's usually addressed by allowing native hooks

Not on the web though. I mean, for obvious reasons on the web we can't just expose native OS methods for websites to call. Flutter doesn't have a choice on that front, Google, Mozilla, and Apple realistically aren't going to break browser sandboxing just so the devs have an easier time.

[oftenwrong]

It's disappointing the Flutter team members haven't addressed this justifiable concern about their big-picture strategy. I would really like to hear what they have to say on this.

[miohtama]

On mobile, you can hook to low level native input events.

On a web browser, <input> is all you have and because of the abstraction you cannot build it from the scratch using lower events. Think iPhone text selection.

Flutter on web may cater a specific category of graphical intensive apps, but not all apps because <canvas>. It will fall to the same uncanny valley where Java applets where back in 00s.

[heavyset_go]

I don't understand how breaking accessibility with Flutter wouldn't mean that companies that use it on the web are violating the ADA.

[mdoms]

I don't know what that is but I assume it's some kind of American nonsense I don't care at all about.

[vanadium]

Multiple countries around the world have legal standards around accessibility. Then you have the ethical, DE&I, and business reasons to enable disabled users equal access to the web platform and apps through screen readers and other assistive technologies, i.e., accessibility. It’s certainly not a uniquely American concern.

[danShumway]

I assume that you just haven't run into this specific term before, but if that's not the case then comments like these are why the web community overall should oppose web technologies that leave accessibility decisions solely up to end developers or that don't make accessible options the default.

The web works as well as it does because (in general) it's accessible by default. There are lots of open problems on the web regarding accessibility, but we should be moving towards being more accessible by default, not less -- because if we want a universally accessible app platform, developers and corporations can not be trusted to make these decisions on their own, and laws will only affect specific industries and countries.

That's part of why Flutter devs talking about dev decisions that can increase accessibility ring kind of hollow to me. Accessibility has to be something that's pushed at a technological and cultural level if we want the web to be a platform that leads the way forward on these issues.

[EvilEy3]

Accessibility is American nonsense?

[jessaustin]

[Flutter ... here]

Currently I'm counting four or maybe five different HN users in this thread indicating this affiliation. I appreciate this open look into the organization. We're probably getting a more honest idea about what really goes into the sausage. Still, your PM might be less happy about this thread...

[csells]

Actually, PMs love open, honest feedback. Keep it coming!

Chris Sells PM, Flutter

[masterofmisc]

Recognize the name! Interesting to hear you moved from Microsoft to Google.

[radiKal07]

My question is, if there is "more work to do on the Web", why is Flutter Web considered stable?

[radlad]

I happen to be on a 1.5 Mbps connection at the moment, and "about a second" sounds wonderful. The demo apps I opened took closer to 30-60 seconds to load.

[jug]

Strange how I don't see many of your issues on my side.

(parent issue) Tab tabs through text fields only.

A) No lag on my laptop

B) Zooming to 400% reveals pure vectors for text as well as control decorations, even the fingerprint icon. Only the logo becomes pixelated but that one could of course simply be an SVG instead and not Flutter's problem.

C) Yes, this is a common issue with web apps. One often needs to look at web browser focus. I'm unsure if an event is even sent to the page as the page itself loses focus.

D) I think it does and this is just a tech demo for adaptive interfaces if you want them.

[danShumway]

Could be the browser/platform you're using? I'm not sure. I've seen some reports here that the demos work better in Chrome, but that's not exactly a point in Flutter's favor; this is supposed to be a cross-platform toolkit after all. Regardless, odd.

A) I'm on Firefox on a Mac Book Pro. My feeling is that should be able to handle a login form, but I mildly suspect that Flutter's dev team is not testing on Firefox at all.

B) Here's what I see when zoomed to 400%. No vectors anywhere, not even for text: https://i.imgur.com/7QFC40v.png Nothing that I see on the page is being handled as an SVG. Very strange to me that you're seeing vector graphics, as that would imply that the form isn't being rendered onto a Canvas for you?

C) This shouldn't be a problem with web apps that use :focus/:active CSS selectors. I understand if a from-scratch webapp doesn't handle focus loss, but I would expect any GUI toolkit to be able to.

D) On the web touch already for the most part just works. There's nothing on this login page that should require a separate interface. I think it's a problem if Flutter only provides adaptive interfaces "if you want them"; in a good GUI framework you should be getting the stuff that the web already handles for free regardless of whether or not you "opt in" to having your site work on an iPad.

[cbolton]

I think you're missing the point of touch mode: mouse and touch actually work fine in both modes. The touch mode is just there to demonstrate how Flutter adapts the layout depending on the target modality: see how the controls get larger when you select touch mode.

The Medium post[1] about Web support explains some adaptations they made for Desktop browser, including:

  We also increased the default content density, because mouse pointers support a tighter density than touch devices.

I expect that in a "real" app the default mode is adapted automatically based on the device type.

[1] https://medium.com/flutter/flutter-web-support-hits-the-stab...

[wruza]

B.2) I bet that it doesn’t respect a wheel multiplier either. It is 3 down keys by default, but I set it to 6 (7 at summer). Even VSCode annoyingly does not, but at least it has its own setting for that, which still only affects text buffers and not everything else.

[ClawsOnPaws]

I know I do almost nothing on HN but complain about accessibility, but it's really important to me because, well, that's how I uze my tech. And so far, sadly, Flutter hasn't impressed either with its previous versions. Edit boxes in particular were a major pain point, and things like you're describing were also less than optimal. I never knew where the focus was and what it was doing. With broken markup there was at least ways around it. But I'm scared of things that render on the canvas. Most browsers actually get this right and have support for these things that don't require ugly hacks if you use the DOM. And there is no real way to interface with assistive tech from JavaScript except through it. So you have to somehow still actually represent your apps UI in the Dom in some way.

[ledak]

It strongly reminds of mid-2000s sites written in Flash

[bliteben]

To be fair there were some flash sites I’ve still never seen anything that equals. I think the way flash marketed to more designers and content creators was both what made it awesome and maybe its downfall.

[miohtama]

It is the same. But at least runtime, WebAssembly and canvas are open source and natively integrated to the browser. Less security holes, but the same UI integration problems.

Good for games.

[pmontra]

I went there. It didn't register my first attempts to tap into the email field. I tapped the password and it worked after that.

But a demo site asking to register an account to see the demos? I gave up. It almost like they are not interested to show their demos.

[SamBam]

Yup, that happened to me. Then I clicked again and tab worked correctly.

It will be hard to overlook little details like this -- and there will be a million tiny details like this -- when decades of browser development have led us to expect a DOM experience that Just Works for UX like that.

[mgkimsal]

Strange - I didn't see that behaviour, then did on a reload, then didn't again on the next reload. ??

[wott]

> flutterfolio.com

I can't experience this problem, for my browser only displays for this site a beautiful, immaculate, plain white page :)

[ainar-g]

If your situation is like mine, you have to wait for some fifteen seconds or so. And then greeted with a login input. Also, my CPUs were at around 50 % the whole time.

I'm sorry, but if that's the “future of web UIs”, I'd rather stay with the “troglodytes”, who write simple HTML forms with a bit of vanilla scripting here and there.

[lwansbrough]

Haha I just read your comment, totally forgot about it, then tried to do the same thing and it happened to me too. Firefox.

[mediaman]

On safari it doesn't do that if the contents are blank, but if you type something in the email box, tab directs to the address bar. Weird.

Works fine on Firefox and Chrome.

[perryizgr8]

Also, try to select any text on that page. This is Flash all over again IMO.

[hnuser123456]

works on firefox

[reggieband]

> couples it with a very beautiful SDK and component framework

I would not call the flutter SDK and component framework "beautiful" nor would I ever add the adjective "very". I have actually found it to be very verbose compared to alternatives I've used in the past. In some ways I suggest it is over engineered.

> offers a far better programming language than js could ever be

Dart is a bit of an odd duck language to me. I think of interesting ideas like the cascade notation (using .. to do sequences of operations on the same object).

Perhaps it is due to having worked a lot in Typescript and having my brain molded to code that fits that shape but Dart feels clunky in comparison. I can't put my finger on why, but defining and instantiating classes feels so heavy compared to the functional type code most Typescript seems to become. In Dart, I just feel like I'm creating massively indented component definitions with tons of properties and nested classes. Maybe I'm just finally accepting OOP and deep type hierarchies are things I want to leave to my past. I feel I can do 99% of what those things did with Algebraic types and functional composition. Nowadays I prefer that style and going back to heavy OOP feels bad.

With the dominance of classes, massive type hierarchies and quirky syntax - I'd just prefer to be working with a more react-ish framework in a language like Typescript. My feeling is Dart is a step in the wrong direction.

[Waterluvian]

How many times has Google done this? And then gotten bored of their own work?

JavaScript, with all its many many warts, is widely supported, incredibly popular, and not going anywhere.

I'm not about to waste my limited weekend time learning Flutter 2, knowing it's going to be in the trash bin by 2023. I'd rather suffer through some more JS warts and get better at avoiding them.

[grayrest]

> How many times has Google done this? And then gotten bored of their own work?

Google's history on this sort of thing isn't good but this will be much more stable than their other offerings. Dart is the primary language of the ads (i.e. money making) side of Google and Flutter is their best shot at making the language relevant elsewhere. I'm still not in a hurry to learn it but I'd be very surprised if it's in the trash bin within 5 years.

[EvilEy3]

> How many times has Google done this? And then gotten bored of their own work?

They're still updating GWT, so I'm not sure what you me by that.

[lordgroff]

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

[qbasic_forever]

Extremely same feeling here. Ditching IE11 support is a total game-change for the web. ES module imports just work and you don't have to go down a complex bundler rabbit-hole. Template literals make constructing HTML inside JS components a breeze. And if you do reach for a bundler the modern ones like snowpack and vite make the experience incredible with instant hot module reload on change--the feedback loop for development is like nothing I've ever experienced.

[blowski]

The problem with JS is not the tooling per se but the constant "upgrades" for the tools that exist. Sure, this week's hot new thing is Vite, but by this time next year it will be out of date with some other thing we're all supposed to use. In projects from the last 10 years, I see Gulp, Grunt, Webpack, Browserify, and now Vite - all doing mostly the same thing in different ways, with different config files.

[qbasic_forever]

You don't have to use any tools, plain old HTML, CSS and javascript still work just like they did 25 years ago.

Tools come and go, they serve a purpose like writing code in a more futuristic style and compiling it down to a broader browser support base. There will always be a treadmill like that in any language. Look at how C++ has evolved from its 90's roots to more modern C++11, 14, and 17 styles--each change also required more work for the tooling, compilers, build systems, etc. to learn. It's just in the C++ world there are far less people working on tools than in the web world.

[wishinghand]

I know someone using Gulp today for a successful web site. They don't have any worries.

[mixedCase]

What other languages have you been exposed to?

[hajile]

I’ve used quite a few. What are the popular scripting languages to compare with? Python, Ruby, PHP are probably the only real competitors (disregarding others like VB or Perl).

Functional programming is very difficult in those languages due to weird closures, bad lambdas, weird block/proc/lambda rules, etc. async from the ground up means that concurrency story is much better and allows lots of threading (with libuv or whatever low level library handling the difficult parts).

JS used to have less ergonomic syntax, but has benefited from adding it last, so it usually chooses the best version.

Stability of JS is much better. When the implementation is the spec, there are bound to be lots of little breakages. Asa result, there’s not much room for alternative implementations.

Tooling is far better than any other scripting language. Debugging and introspection tools are second to none in the category. All these other languages have broken compatibility so that old software won’t run on new versions. Webpack gets hate, but what other scripting language bundles its output? Babel gets hate, but if Python had something similar, the v2/3 switch would have been no big deal and all the “I can’t use that because REHL doesn’t support that version yet wouldn’t be an issue either. Likewise, minifiers reduce download size, improve performance by removing and simplifying parts of the code and improve parse time, but other scripting languages don’t bother.

Type support via typescript is miles ahead of the competition.

Finally, performance is one or even two orders of magnitude better compared to other scripting languages (luaJIT being a notable exception). In fact, modern JS JITs can come very close to the performance of Java or even C in many cases.

JavaScript isn’t the end all, be all of programming, but it’sa very solid choice with good reasons to like it.

[mixedCase]

Have you tried Elixir or any Scheme? If the scope is dynamic languages, both put JavaScript to shame with much more power, useful tools and far fewer non-sensical footguns.

If the scope is programming languages in general, since it was stated that JS isn't a "bad language" after all, then you can include a long, long list of type-safe languages that are much better for dealing with both its role in the browser and in the backend. Elm, Reason, F#, OCaml, Scala, Kotlin, Swift, Rust, Haskell, to name a few.

[hajile]

I necessarily confined myself to popular languages because of all the advantages that brings. If I could choose any language and magically have an awesome ecosystem, I'd definitely choose StandardML with my second choice being Scheme.

Most of the languages you mention are as fast or faster than JS. Most of them are also much more niche. Tooling for most of them is lacking. Others drag around a huge ball and chain in the form of the JVM or .NET (even the light versions are generally much bigger than v8).

Reason/ReScript seems mostly abandoned by Facebook at this point. Elm is very deliberately a one-man show (I don't like that bus factor). Ocaml compatibility and tooling seem easy then drop off a cliff in practice. Haskell is way too worried about math and the illusion of purity (and finding people willing to deal with it is very hard). Swift is Apple-only and doesn't actually bring much to the table (honestly, it seems like a rip-off of Dart with tuples and ref counting instead of a GC). Rust is much lower level and writing something in rust will take far longer than in JS.

[ASalazarMX]

JavaScript is 26 years old, people were calling COBOL old in the 90s, when it was 30+ years old.

COBOL is still being updated, it even supports OOP now, yet it shows its age and its joints creak a little, just like JavaScript.

[mesaframe]

It has become from terrible to less terrible.

[pjmlp]

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.

[stephenhuey]

Exactly - too often we see developers spending vast amounts of time on stuff that's "better" but by what metric? Often, it's better only by standards that matter to the developers, not the business paying the bills. In my experience, Flutter makes it very fast to ship a decent solution.

[capableweb]

> Now, Google comes and creates a whole new UI toolkit from scratch

Worth remembering that this is not the first or even second attempt at this from Google. So I think people are fair when they are not just jumping along all happily as people have been burned before.

[lostmsu]

Flutter does not offer enough to justify learning new programming language.

[pier25]

Dart is extremely easy to pick up if you've written in any C style language.

Someone in our team had a small Android TV app working in 2-3 days with WebSockets, web views, some animations, etc.

[oblio]

Syntax, semantics, code organization and best practices, libraries, frameworks, debugging and debuggers, IDE support (preferably multiple IDEs for multiple platforms), LSP support, linters, profilers, disassemblers, dependency license checkers, dependency vulnerability scanners, package managers, package repository with support for private repos and proxying/mirroring, should I go on and on and on?

Your toy app takes 2 days to create and then you (or worse, someone else) have to support the crummy Visual Basic/PHP/Javascript/Mongo/ColdFusion/insert easy to use crappy tech here, forever.

[Dylan16807]

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

[oblio]

My main point is that developers chase shiny things and "easy to use" is one of the shiniest things out there.

Past a certain point, being usable in 2 clicks is a negative signal for overall tech quality. Most of the really solid techs need some extra configuration. The classic example of crappy tech is the DB tech that listens on 0.0.0.0 after installation, with no user + pass or admin/admin.

[Dylan16807]

> Past a certain point, being usable in 2 clicks is a negative signal for overall tech quality. Most of the really solid techs need some extra configuration. The classic example of crappy tech is the DB tech that listens on 0.0.0.0 after installation, with no user + pass or admin/admin.

Yeah, but the post up there said 2-3 days. That's plenty of time to handle those important details that make a project non-instant.

[danielscrubs]

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?

[mda]

To give context, the implementations for the same problem are completely different, e.g. javascript versions uses worker thrreads on 4 cores for most of the examples. To compare actual performance first similar approaches should be used.

[mda]

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

[igouy]

> … some benchmarks … seems much slower …

nbody dart 8.44s nodejs 8.37s

regexredux dart 4.89s nodejs 4.79s

Those don't seem much slower.

[mathgladiator]

I think in the framework of choosing boring things, you are spot on. However, all innovation tends to be ten steps forward and eight steps back, so the way that I look at it is simple. For a given effort, are those two steps forward worth the total long term cost? Maybe, maybe not. Usually not, but... people are going to do silly things.

I look at flutter as a quick way to bootstrap a simple CRUD app, but... for what? How does it improve on the web? Not 100% sure, but I do like the down chain investments that flutter supports like Skia.

I'm a huge fan of canvas, but I recognize its limits for building apps. It's great for many things like games, and it is a 2D escape hatch. I'll admit that I get suckered into the lure of building a 2D canvas empire that is cross platform because it would be nice.

[pier25]

The fact is that even considering all those points, Flutter+Dart is still much easier to learn than Swift+iOS and Kotlin+Android (even separately). And I'm not even considering Desktop.

[EvilEy3]

Sure, but you also get really powerful ecosystems with those languages. Which can't be said about Dart + Flutter, where most of those packages are amateur quality.

> Desktop

JetBrains Compose.

[fizdoonk]

have you actually tried it? its ecosystem provides all of that

[blacktriangle]

It's never about the language, most any language is easy to pick up. However picking up a whole new ecosystem with its associated dev tools, build tools, packaging, and different libraries is where the time consuming portion of new languages come in.

[H1Supreme]

Exactly. When I scanned Dart's language spec, it looked just like any other C derived language. In terms of complexity, Flutter/Dart is no different than Android/Java. When I started writing Android apps, learning Java was the absolute easiest part of that process.

[jamil7]

Yeah but it’s usefulness is really limited and just feels shoehorned into the project. Why couldn’t it have been Kotlin or TS? Something that mobile developers or web developers could jump into and keep a bunch of their existing tooling.

[distances]

Then you would've needed to package a JVM or a JavaScript engine, making the app distribution a whole lotta different deal.

[MongooseMan]

Kotlin doesn't just run on the JVM - it can compile to native binaries with Kotlin Native. It compiles to WASM and JS too.

[EvilEy3]

At the time of Flutter development it couldn't do any of those things.

[EvilEy3]

JetBrains Compose.

[AlchemistCamp]

There's not much new in Dart. It's basically another AS3/ES4/"Java lite" from what I've seen.

I suspect you could learn it very quickly.

[mixedCase]

Flutter does not offer enough to justify tolerating such a terrible programming language*

Going from Kotlin, Swift or TypeScript (let alone more powerful languages) to Dart is like going back to the dark ages without something as basic as algebraic data types.

[lhorie]

> It's not that good but it's gonna get there eventually, given the hype around wasm and <canvas> technologies

Is it though? Canvas is basically invisible for anything that doesn't have functioning eyeballs (which include not only screen readers, but also mundane things like your browser's ctrl+f functionality, google's crawler and siri). You know how people complain about some SPAs' back buttons and scrolling being terrible? I feel like this "next gen" tech is just gonna be more of the same excellent-in-some-aspect-but-completely-subpar-in-others stuff.

[wruza]

Can’t speak for others, but I still want a proper set of primitives and not yet another rightest-way-to-do-it sdk whose examples stutter on top hardware and will be great tomorrow. Time to go sleep I guess, will check it in 8 hours. All I want is untangling of the mess a css boxing model is, not just some buttons on canvas. I wrote gtk-flavoured widget drawing libs for few times in Lua+cairo ten years ago and these ran smoothly on a hardware than couldn’t even boot an OS today, except some rare stop the world gc issues Lua had back then. It was no big deal, and strange (not really) that Google Itself couldn’t beat that score.

[golergka]

FWIW, modern Typescript is the best mainstream-ish language I've used in production. Dart is decent, but I don't think it's that good.

[hi_mom]

The only thing I really dislike about it is the fact that in the end, it’s still just a layer on top of JavaScript, so you lose all types at runtime and stuff like object literals and classes are still not “complete” in my eyes. Otherwise it’s pretty good. I’d also like beter arrow syntax, something where you can properly write shorthand like in Scala for example.

[tmpz22]

Because Google is focused on language and tooling development, but forgot to create a killer app example with publicly available source code. Show us a minor Google property re-done in Flutter with code examples and people would flock to it.

But. They. Won't.

[munificent]

> forgot to create a killer app example with publicly available source code. Show us a minor Google property re-done in Flutter with code examples and people would flock to it.

Can you think of a "minor Google property" that is open source?

[tmpz22]

Its a hard resource-intensive problem to dogfood your own OSS at a company as large and diverse as Google. But hard problems haven't stopped Google in the past.

What you're trying to create is the same spark in your users as PHP and React did to the web. The "oh wow I could do...." that while technically possible before the product existed, is completely re-framed by relatively minor improvements to the DX. You want to inspire an entire generation that may have passed on mobile and cross platform app development due to the verbosity and pitfalls of the iOS and Android ecosystems.

I think a killer app example is the ticket to do this. It may not be the only way, you could blow a huge marketing budget, you could convince another large tech company to do it, but doing it yourself is probably the quickest (or only way) to get it done.

[higerordermap]

Maybe some android utility that doesn't need Google integration.. Let's say calculator app from next android version?

[munificent]

I mean... if we ported Android Calculator to Flutter, would that really impress or convert anyone?

[Razengan]

> Not to mention that Flutter is already better and easier to use than the existing native tools for both Android and iOS.

Flutter is not better or easier than SwiftUI. Especially in accessibility or native performance.

[NOGDP]

> 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

All of these things, more or less, already exist in great variety in the JS ecosystem (angular, react, vue, redux, webpack, etc.). Many people have also already adopted other languages such as TypeScript, which is easier to learn for someone coming from JS, and superior to Dart imo.

[blacktriangle]

We're nagging because the apps suck and stick out like a sore thumb. Maybe Flutter will be the one to get there and be the holy grail of cross platform UI development, but the developer community has been burned by this promise so many times, we're going to have to see the final product before getting excited.

Just because a project is ambitious doesn't mean we should all jump on board, particularly when similar projects have crashed and burned, and there's really nothing stand-out about Flutter that separates it from prior efforts.

[hanniabu]

I don't understand why more resources aren't being put into Qt and making that easier to use or building a more "web-developer-friendly" abstraction layer on top.

[danShumway]

I don't know if they've changed their approach over the past year, but the last time I looked at Qt demos for the web, I was solidly unimpressed.

At the time, they were making almost all of the same mistakes that Flutter is, and the devs I talked to seemed to be of the opinion that those problems wouldn't be fixed until browsers started adding brand new capabilities specifically for them.

Looking now at the demos at https://www.qt.io/qt-examples-for-webassembly, a lot of the same problems are jumping out at me. A complete lack of accessibility features, poor handling of scroll events, large load times, unfocusable fields, lack of keyboard controls, etc...

Halfway through playing with their pizza app, the page just froze and stopped responding to any clicks at all. Maybe those demos are outdated?

Blazor and Rust are showing a lot of promise here, but from what I know about Qt I'm much less optimistic, because Qt is used to handling everything about rendering itself -- and as Flutter is showing that's just not a good approach to building web GUI frameworks. But (again, purely from what I've seen) trying to layer on a system where Qt is actually interacting with the DOM seems like it would require a somewhat difficult shift in its architecture. Maybe I'm misunderstanding the problem though.

[0xFluegel]

> Looking now at the demos at https://www.qt.io/qt-examples-for-webassembly, a lot of the same problems are jumping out at me. A complete lack of accessibility features, poor handling of scroll events, large load times, unfocusable fields, lack of keyboard controls, etc...

I found that hard to believe. But, clicking that link and trying the pizza demo... Yikes. It's not exaggerated at all.

[hnedeotes]

Qt for WebAssembly: Pizza Shop Application exit (TypeError: undefined is not an object (evaluating 'handle[name]'))

[sombersonder]

May I ask what browser and version you ran this in? It does look dated but ran okay for me on Firefox 86 and Chrome 89.

[barbarbar]

When I try that link I get: RangeError: WebAssembly.Memory(): could not allocate memory

So no pizza demo for me.

[gagege]

Whoa, yeah, none of those Qt demos are good or even seem to work properly. Yikes.

[sgerenser]

At least you got the pizza demo to work at all. All I got was a large Qt logo with the message: Application exit (TypeError: undefined is not an object (evaluating 'handle[name]'))

[ognarb]

For the moment the only useful usecase of qt for webassembly I found is: https://qmlonline.kde.org/ It's really useful to share some bits of QML but otherwise I wouldn't recommend using Qt for the web as much as I wouldn't recommend to use Flutter for the web.

[eska]

The pizza demo didn't even let me input text into the credit card input boxes..

[cachvico]

These demos remind me of Flash..

[ryandrake]

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, you end up fighting the framework and tools more than you're writing your app anyway.

[hamandcheese]

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

I mean... yes? There is a ton of incidental complexity (i.e. unrelated to the business domain) involved in creating nice user experiences. If dev salaries weren’t so high then sure, more companies would probably spend the money to repeat the same work across several platforms, but right now? No way.

That said, I still think I agree that you give up more than you gain by going cross platform, at least for now, but I totally get how companies look at how much it’s costs to hire and says “you know what? I’ll take a cross-platform compromise”

[kbd]

Not to mention the LARGE realm of internal tools where you need something functional as conveniently as possible and aren't trying to drive a consumer-product-level market-differentiated experience.

[prathiks]

It also takes time to ensure the feature is developed for all platforms. Due to low usage you may not bother developing for that platform. Thus feature in one platform lag other.

I worked for a company where we did iOS release after very 3 android release coz android was 80% users and iOS 20%. Mind you this was a cross platform Iconic/Cordova app. Now think if we did native. iOS users would have to wait even longer

[hackerfromthefu]

Companies are too efficient for that, even if dev salaries were cheaper they would still want to fund just one version and pocket the difference, and eventually market competition will make that the norm.

[ironmagma]

Not only that, but corporations are not everything. What about one and two person shops? It would really be nice to be able to develop a product without first having to invent the universe.

[signal11]

Counterexample: banks started with shitty cross-platform UI type apps, but those received low customer satisfaction figures so most of them have now switched over to native apps. A similar thing happened with Facebook.

[tiborsaas]

+1

Furthermore users don't care about the technology used to build the application if it works, that's the unfortunate reality.

[signal11]

Users are not knowledgable enough to know what technology was used to build a product, but many have repeatedly complained about non-native UIs.

Heck, Lotus Notes went from being a market leader to an also-ran and user complaints about UX to corporate IT departments definitely played a role in convincing those departments in switching away.

More recently, this also happened with many mobile apps made with cross platform/HTML5 toolkits. They got low review scores and low user engagement across many firms, prompting a switch to native.

[bradgessler]

It’s not just a “small UI layer” — there’s an entire stack that goes with it. Want to build iOS apps? Can’t do it on Windows or Linux; you have to buy a Mac, run macOS, learn that whole stack, install Xcode, figure that whole thing out, learn how the App Store works, including all of its rules and regulations. But that’s not all—you also have to figure a CI pipeline for that whole thing too.

Rinse and repeat for every platform.

That’s what makes the web beautiful: you write the app once and it mostly runs everywhere. You have to figure out the infrastructure I described above once and you’re done.

Or at least that’s how it use to be before the major platform players realized how lucrative it is to charge developers App Store fees.

[tiborsaas]

> Is it that expensive to separate your business logic from UI and write the small UI layer

Not sure what apps you've built, but usually that business logic is the minority of the codebase. The rest of the stuff is boilerplate, like drawing boxes, describing layouts, handling events, managing state. All this has nothing to do with business logic.

Ideally, I want to write it once that I want a row of buttons what colors they have and what function should be called when the user clicks on it.

I did what you describe and extracted all the logic in a small component I manage and the result was very banal, extremely straight forward code with was essentially "business logic". The 90% rest was building the UI based on it.

[ryandrake]

Last major one I worked on that needed to be cross platform was a GPS navigator, which had massive functionality in C and C++ under the hood, called from the platform-specific UI/event handling code through Objective-C-to-C++ on iOS, through JNI on Android, and directly on PC native platforms. It worked pretty well. The ratio of platform-specific to platform-independent code was very small, so it was not like writing the app N separate times. Major engineering savings AND each platform's build had its own UI idioms that users of those platforms were accustomed to. Guess I never realized this was a controversial approach to take!

[WoodenChair]

> Guess I never realized this was a controversial approach to take!

It’s not about controversy. It’s just that in most apps, the UI is far more than 10% of the code base.

[coldtea]

>Guess I never realized this was a controversial approach to take!

No, just non-represenative of most apps, who are closer to CRUD than "GPS Navigator".

[avar]

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 something these wildly different platforms share.

[lenkite]

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

[buu700]

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.

[iainmerrick]

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 you going to use?

It’s kind of ridiculous, but that’s the way it is. Programming languages are all the same in principle, but in practice they don’t interoperate well and they can’t easily be used everywhere.

[rtpg]

you release feature X. The first person writes it for the web. The web version was easy, because the feature relied on URL deeplinking, which is nice and easy with browsers.

You then realize that Windows doesn't really offer such a concept as easily. You think about application URLs. That mostly works, but it takes a couple weeks for the Windows team to get it working.

You implement the feature over on Macs as well copying the Win strategy. But a recent Mac OS update causes a bunch of permission popups that mess with another thing. Now you're messing around with that, and your internal users are pissed (cuz they're all on Macbooks).

There is no Linux version, luckily.

I mean... OK, yeah, you still have to deal with platform differences even when using Electron. But you are in the same boat with like.... Slack, Discord, etc etc. You get _all_ that shared knowledge, a unified code base. And in theory you throw any of your engineers at the problem and they can try very hard googling "Electron [issue] windows".

I also bemoan the fact that _even Slack_, with its billions of dollars, didn't feel the need to have a native application. But I do get it, especially when there's a lot of pressure to ship.

[signal11]

While I realise you’re just providing an example, Windows has supported deep linking in one form or another since Windows 3.1 (DDE, specifically topics), but also HTTP-style application URLs (eg app://command?options=opts) ever since ActiveDesktop and WebView.

[achow]

The blog exactly answers this.

------------------------

Google Pay switched to Flutter a few months ago for their flagship mobile app, and they already achieved major gains in productivity and quality.

By unifying the codebase, the team removed feature disparity between platforms and eliminated over half a million lines of code.

Google Pay also reports that their engineers are far more efficient, with a huge reduction in technical debt and unified release processes such as security reviews and experimentation across both iOS and Android.

[boring_twenties]

That's very interesting in light of the facts that

1) This announcement seems to claim that Flutter 2 apps can be deployed as web apps as well as mobile apps, yet

2) This very morning I received an email from Google stating that pay.google.com is going away and the service can only be used via the mobile app going forward.

[themolecularman]

> Google Pay switched to Flutter a few months ago for their flagship mobile app, and they already achieved major gains in productivity and quality.

I'm not sure about the quality. I'm bullish on Flutter but the iOS reviews for the app are awful.

[coldtea]

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

Yes.

>Is it that hard to find developers who know more than one programming language?

Who said everybody has a team or this luxury?

[comeonseriously]

Because developers only want to work with their favorite language/frameworks and managers don't want 7 different teams.

[groby_b]

Working on an app that's running on... 6 different OSs/UI toolkits on last count, yeah, that "small UI layer" is costly. And yes, finding devs that know more than one language/one UI toolkit is hard. (Heck, for some UI toolkits, finding developers is hard period)

[birthday]

Just imagine trying to build a mobile startup company and having to write 2-3 copies of your app (Android, iOS, Desktop). No thanks!

Nobody needs native UI. It's time we get passed that!

[saagarjha]

People with disabilities frequently do.

[qbasic_forever]

Isn't the licensing for Qt a very curious and weird quagmire? Maybe it's better these days but I remember about 10 years ago there was a weird divide and unanswered questions about if you could really take a bet on using Qt and not be violating GPL.

[lmm]

No. 10 years ago it was 100% fine. About 25 years ago there was a licensing issue, and the Gnome project talks about it as their reason to exist to this day (which amounts to spreading FUD at this point, IMO).

[heavyset_go]

It's better these days. For desktop application development, Qt is available under the LGPL and the Qt commercial license.

Qt for WebAssembly is available under the GPL3 and the Qt commercial license, though.

[heavyset_go]

Qt's QML + QtQuick follow the declarative and reactive programming paradigms and use JavaScript, and were released before React existed.

[ognarb]

And it has a very nice developer experience :)

[smoldesu]

QT isn't neccesarily a crowd pleaser, and in 2020 it's starting to look a little long in the tooth. Don't get me wrong though, I love QT on the desktop, and it powers some of my favorite software out there. Ultimately though, I don't think QT's fate is on the web.

[throwaway123x2]

Oof remember when PhoneGap was the next big thing? RIP

[The_rationalist]

Pure nonsense, phonegap has been renamed Cordova and is widely used. The Electron of smartphones is Ionic which is a sexy and performant superset of Cordova. PhoneGap (Cordova + Ionic marketshare) has a bigger marketshare than flutter and react native! Source: https://www.appbrain.com/stats/libraries/tag/app-framework/a... Ionic is a gift and it will only get more widespread, the myth that chromium is slow is increasingly dying. Also, did you notice the irony/hypocrisy that flutter is using the rendering engine made by chrome developers for Chrome developers ?

[raihansaputra]

Ionic has released Capacitor as the successor for Cordova. And it's still compatible with Cordova plugins so all the work from Cordova days is not wasted. Ionic is definitely a gift.

[TheGuyWhoCodes]

I remember big corps betting on phonegap and sencha for mobile 7 years ago. I also remember big corps betting on GWT.

Those were painful days...

[dmitriid]

Funnily enough, Sencha still can't be reliably recreated by any lib/framework/browser built-ins du jour (without sinking as much effort as Sencha did): https://examples.sencha.com/extjs/7.3.0/examples/kitchensink...

[cztomsik]

true, just like wysiwyg we have for react/vue/angular is still joke when compared to delphi/visual studio

[auganov]

Time is on webview apps' side. IMO cordova/phonegap got too big too early and the industry still has a revulsion that may not be justified anymore. I don't think they will ever come to dominate, but I do think hybrids will eventually go back to using webviews.

If groundbreaking UX is your core competency you need native. Hybrids get you neither the best feel nor the best dev leverage. Hybrids are selling the exact same dream phonegap has. But they let developers distance themselves from the bad rep and claim they're doing something different. Alternatively, at the other end, they get developers to build essentially native apps while pretending to save a lot of time.

[drewda]

On this note, I have 60% fond memories of Appcelerator Titanium and 40% frustrating memories :)

[mattschmulen]

Yup, really they had the right idea in that it was native components that were hoisted by JavaScript binding... it really lost steam because it became easier to just build native Swift (and later kotlin android). It was a solid play at the problem in it’s time. Note: I worked at Appcelerator in the “gogo” years and it was great, and they/we almost made it happen in a real way.

[JamesSwift]

Man those are some rosy glasses you got. I've got 20% fond memories, 80% frustrating memories : )

[EvilEy3]

> Not to mention that Flutter is already better and easier to use than the existing native tools for both Android and iOS.

No, it's not. It's easier to start with, which is infinitely different from "easier to use". Once you get of beginners phase you see that native toolkits are equipped with battle tested solutions unlike Flutter.

With SwiftUI and Compose there's literally no upsides to Flutter except portability and even that Compose has potential to snatch.

[ttt0]

So now every website will require enabled WebAssembly to run god knows what code and I will have to install an anti-virus for my browser? No thanks. JS might be a bad language, but it's even worse in how it's abused with frameworks, tracking, etc for no good reason.

edit: funny how I can discuss extremely controversial political topics here and never have any of my comments killed, but having a negative opinion about wasm and JS frameworks is just a step too far lol.

[ec109685]

WASM is still stuck within a highly protected sandbox, so you don't need to run anti-virus software for your browser.

[ttt0]

Bitcoin miners?

[leppr]

...that run only when the tab is loaded. Non-issue.

[hnuser123456]

better than rootkits

[dagmx]

Wasm can't do anything JS couldn't do already.

[yjbanov]

There are a few things that WASM can do that JS can't (at least not now):

- Memory management without GC - Unboxed data structures - SIMD - Shared-memory multi-threading - Precompiled snapshots (does not need to be recompiled on page reload)

[hajile]

Bytecode caching has been a browser feature for years[0]

JS has atomics and shared memory arrays which also basically bypass garbage collection [1]

JS had working simd.js implementations in both Firefox and Chrome until they were pulled in favor of WASM

[0] https://v8.dev/blog/code-caching-for-devs

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[2] https://github.com/tc39/ecmascript_simd

https://blog.mozilla.org/javascript/2015/03/10/state-of-simd...

https://01.org/blogs/2014/bringing-simd-javascript

[dagmx]

I should clarify, in the context of the reply I was referring to security. Wasm is inherently as secure as JavaScript.

[AlchemistCamp]

It can do integers.

[hajile]

BigInt landed in ES2020 and has been supported in something like the last 10-20 versions of Chrome and Firefox, so no huge worries about using it (the "current" browser without support is IE11).

The `123|0` type hint is also recognized and implemented by most browsers too. It forces a 31-bit integer on most platforms (and can offer a significant performance boosts if you're running a tight algorithm).

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[ttt0]

What JS can do is already bad enough.

[anoncake]

> edit: funny how I can discuss extremely controversial political topics here and never have any of my comments killed, but having a negative opinion about wasm and JS frameworks is just a step too far lol.

I'm not surprised. You probably happen to agree with the majority of HN on these topics so the upvotes outweigh the downvotes.

[nwienert]

Flutters model really fundamentally isn’t there “right one”. It truly is the successor to Flash, but with Google behind it.

But if you want to make apps that feel actually native on their platforms, React has it handily beat. It’s a better fundamental model, that even with a slower language and runtime feels better in the end by far.