-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
In the article, he mentions the need for a DOM parser dependency for his app, as Swift “does not have one.”
> AEXML was needed to parse some XHTML files as the native iOS SDK does not provide a DOM parser.
I have used Foundation XML parsers[0] for many years, but they are general-purpose; not specifically modeled on DOM or HTML, which probably limits usefulness on some Web content.
That said, if he has control of the content (don’t know the app, so I am not sure), then there should be no reason that they couldn’t render it in XHTML, so the Foundation parser could be used reliably. In the article, he mentions that the content is XHTML. I have to assume that AEXML[1] is easier to use than the built-in parser. It uses Foundation parsing (it actually seems to be a lightweight wrapper for the built-in parser(, under the hood (and seems to be a well-written dependency).
So, it could be posited that he would only need one dependency for his native version, if he wanted to handle the XHTML parsing, himself.
[0] https://developer.apple.com/documentation/foundation/archive...
[1] https://github.com/tadija/AEXML
Tim here from the Flutter team; thanks for the post. There are some good points here: in particular, that no single framework or toolkit is the "holy grail". We all live in a world of trade-offs, and anyone who claims that any single technology is the panacea for all problems is selling a mirage.
I really appreciate the constructive critique in the article: both the good (getting an app up and running quickly), and the more painful to read ("Flutter's ability to execute leads a lot to be desired, particularly on iOS"). While Google is the primary sponsor for Flutter, it's an open source project, and so as ever having reproducible bug reports and ideally pull requests is how we make it better.
The raison d'être for Flutter is simple: we don't think you should have to write the same code six times for your app to reach each major desktop, mobile and web platform. This abstraction is not free, but we think it's worth the bet, and there are some cool apps being built with Flutter, plenty of which have been awarded accolades like Apple Editor's Choice. We're not the solution for every app out there, but there are startups who don't have the developer team size to build multiple apps but can benefit from Flutter, as well as larger companies for whom Flutter lets them unify their app development team behind a single codebase.
A few quick comments I wanted to make:
- Yes, we have a large number of open issues -- over 9,000 at the last count, but not all issues are bugs. We're somewhat unique in bringing together tools, packages, framework and engine issues into a single database, also merging feature requests, bugs and even API doc requests together. Our general philosophy is that it's better to have it out in the open rather than (for example) to prematurely close issues that we don't plan to work on ourselves. We're also not unique as a large open source project in having lots of open issues (also see projects like PyTorch, Rust and VSCode). Lastly, it's important to count the number of issues _closed_, which is over 50,000, representing bugs fixed, new features implemented, and so on. We document the triage process here: https://github.com/flutter/flutter/wiki/Triage
- I'm surprised that the author considers packages an inevitable weakness. We've deliberately kept the core of Flutter relatively small, because it enables us to iterate on packages at their own pace. We could have taken the approach of building things like XML parsing, HTTP servers, geolocation and so on into the core of Flutter, but it wouldn't automatically make them more robust. With a package model, we can fix a specific issue without requiring a whole release cycle for every part of Flutter. Over the last year since the author wrote this article, our package maturity has greatly improved, and I'd be interested to know whether this is noticeable.
- Lastly, the underlying fear expressed in the article seems to be that Google will at some point just give up with Flutter. I understand this, since we don't have an immaculate reputation in terms of long-term support. I will say that this question doesn't come up internally with our stakeholders, though. There are over 400,000 apps in the Play Store that use Flutter; about 1,000 Google engineers building highly-strategic products using Flutter; and a healthy ads revenue from apps that use Flutter. The project more than pays for itself, and I can't honestly envisage any scenario in the next decade where Google would choose to squander all that.
Keep the feedback coming: we're listening.