261–270 of 780 posts
When a company releases a new technology for building desktop applications, the primary thing I look for is a really solid fleshed out implementation of a CRUD application: - sign in to some back end - create and edit data using forms - browse data in some sort of datatable/datagrid - use ajax to GET and POST data But such a demo is pretty much never there - I certainly can't see it in this case. But surely the vast…
Check out https://gallery.flutter.dev/ for a CRUD sample app.
>Moving forward, Flutter is the default choice for future desktop and mobile apps created by Canonical. This is terrible news. I thought Canonical learned from it's last decade of painful failures to converge desktop and mobile. They have different needs and it doesn't work. What this means is another dark age for the Ubuntu desktop environment.
Launchpad, Juju, Unity, Mir, Bzr, upstart, heck, I can't even remember them all.
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. […
No jank in Firefox. It does take 10 scrolls to move 6 inches, though.
Earlier quoted context omitted.
I've tested on my phone (1yr old pretty good Android one) and the whole thing is very laggy runs with like 10fps. What about a11y? The whole thing feels like Adobe Flex in 2010. It solves a great deal of problems that the web had but introduced a plethora of others.
[Flutter Eng. Dir. here] Still relatively early days for Flutter Web, so I would not be shocked if it's not buttery everywhere. However, we would certainly love to learn more. fluter.dev/support has links as to how to file an issue if you're interested. https://flutterplasma.dev/ is one demo to try. We expect to be updating flutter.dev/web and flutter.dev/showcase to update more over time.
Earlier quoted context omitted.
I've tested on my phone (1yr old pretty good Android one) and the whole thing is very laggy runs with like 10fps. What about a11y? The whole thing feels like Adobe Flex in 2010. It solves a great deal of problems that the web had but introduced a plethora of others.
[Flutter Eng. Dir. here] Still relatively early days for Flutter Web, so I would not be shocked if it's not buttery everywhere. However, we would certainly love to learn more. fluter.dev/support has links as to how to file an issue if you're interested. https://flutterplasma.dev/ is one demo to try. We expect to be updating flutter.dev/web and flutter.dev/showcase to update more over time.
Earlier quoted context omitted.
Let me try: > Flutter 2 supports web now! > We've re-written GPay in Flutter 2! > We're dropping support for using GPay on the web...
That doesn't follow. There's any number of reasons the web app would be shut down, usage statistics being the most likely.
I want to love Flutter. But once looking at it, it's a no go. It's the new flash. Really, you cannot copy the text anymore. React native is my goto solution now.
Yup. I would also like to open links in new tabs, view images, copy links, search on page, use browser extensions... I can see it being useful for games and similar where there isn't really any UI but even then I would want dialogs and similar to use regular text that I can copy. I am definitely not looking forward to flutter on the web. I foresee a lot of websites that I will need to avoid.
The only thing I do get is that you’d want open in new tab and copyable links. However, that’s hard from a developer perspective as you have to make sure you create links that store all data needed to rebuild the same UI in the same “conceptual” context but a different underlying data context (logged in user may be different, data may have changed so some saved context has become stale). You’ll likely end up spending an awful lot of time to cater for all the unexpected things that may happen when someone just clicks a link copied from the address bar or a link by another user 2 days before, that may have been the result of that second user clicking through 10 levels deep in your app with all sorts of filters and options based on the state of data at that exact time two days before the first user clicks the link. Obviously you can’t show them the data from two days ago, but what if the data is still there but the path to get there is different? Does it conceptually still make sense to show the data and perhaps some breadcrumbs showing the new path? Or should you just say sorry that data isn’t here anymore? That depends entirely on what the data is and what you’re users are trying to do, so you can’t build one-size-fits-all technical solutions for this (if that were even possible). How are you ever going to reliably rebuild the UI and context that the first user intended to share by copying the link without spending huge amounts of time? That requires actual business logic and functional design.
For a lot of apps, it may make more sense to just have a share button in some places where you actually and intentionally support this (and where it will be actually used by a substantial number of users). Less time spent on developing things that are hugely complex and very little used (on average per state for ALL your different UI states that you have links to somewhere in the app, even if it’s a typical line-of-business master-detail form with some filters for the master list and a details segment with a dialog box or expanded element showing additional details of a certain property).
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…
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…
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.
Earlier quoted context omitted.
>Dart makes Typescript look like a joke. Dart still does not even have union types, probably the best feature of TS. I would hold off on that claim for now..
What is your main use case for type unions? I don't know typescript, but I haven't felt the dart language was not feature complete for all my uses. Is this something you cannot solve with a combination of abstract classes, and or/extension? https://dart.dev/guides/language/extension-methods
> 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. from pay.google.com > Starting April 5, you won't be able to use pay.google.com to send and receive money from other people. To send and receiv…