601–610 of 780 posts
All the highly optimistic claims from the blog post and HN comments would be a bit believable if someone could just show us a web demo that doesn't suck hard. Or show us something accessible at the very least.
Earlier quoted context omitted.
If you prefer Kotlin you may find https://developer.android.com/jetpack/compose more to your tastes.
Could any Android dev veterans chime in and comment on JetPack? This is the first time I'm hearing about it and I'm not sure I like it. It looks like a weird blend of HTML, CSS and JavaScript event handlers and I'm starting to wonder: Why not use web technologies from the get-go then and make use of the lessons learnt there? This reminds me, I'm getting the impression that with every new UI framework that gets releas…
Small nit but Jetpack is the name of the entire suite of libraries that Google offers for Android. The thing formally known as "support lib", a name that stopped making sense when it had random useful stuff not just compat stuff.
You're talking about Compose here (or Jetpack Compose).
Earlier quoted context omitted.
> 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 severa…
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.
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.
Earlier quoted context omitted.
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…
> 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.
Earlier quoted context omitted.
[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…
When Chrome has become synonymous with the Web :facepalm:
Earlier quoted context omitted.
That doesn't follow. There's any number of reasons the web app would be shut down, usage statistics being the most likely.
The web version isn't shut down, but losing crucial functionality. If Flutter let's you run the same code across multiple platforms, then what reasoning is there for one platform getting less functionality after switching to a framework that, if anything, should increase cross platform feature match.
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.
Blanket statements don’t work.
Earlier quoted context omitted.
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.
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.