React Native (created by Meta/Facebook) provides a set of React components that represent layout and UI abstractions such as a View (used for containing and arranging elements, like a `div` with `display: flex` on it) or a TextInput (like an HTML `input` or `textarea`). However, I’ll try my best to treat them fairly and acknowledge the advantages and disadvantages of each. My experience with Flutter has been much better than with React Native. I don’t expect to come across totally unbiased. I didn’t go into this planning to write about my experiences-I just wanted to prototype a simple app-but the comparison has turned out to be very interesting these are two radically different frameworks, each frustrating and delightful in its own ways, and I think it’s valuable to compare and contrast them from a web developer’s perspective. Over the course of a couple weekends, I built two proof of concept apps, one each with the latest versions of React Native and Flutter. In the end, React Native and Flutter seemed like the best choices for my skillset. I also have some relevant experience to consider: I’ve built a couple of side projects with React and have been working on a game in Flutter. NET at my day job, but my impression is that it doesn’t have the robust community or market share that the others have. Xamarin might have been a good choice since I use. Having ruled out those options, the remaining ones I was aware of were:īuilding traditional native apps would require me to maintain two or more codebases, and I’d be learning Swift from scratch, so that sounded like more trouble than I signed up for. (I would be remiss here not to mention Ionic, which really helps achieve a native look and feel but typically requires a partial or full rewrite and still doesn’t fix a lot of the problems I’ve mentioned.) So although Cordova fills an important role as the most cost-efficient way to deliver a “website in an app,” I decided it wasn’t a great choice for a new project. Additionally, the support for native smartphone APIs is patchy and sometimes unreliable even simple things like media controls can be frustrating to implement. Even a website that works perfectly in a mobile browser may need substantial work to look and feel right as a Cordova app. Both the process and the end result are full of unpleasant surprises. While this is by far the cheapest way to bring a website to both app stores, and in theory can accomplish nearly everything a native app can, in my experience this is anything but frictionless. Apache Cordova turns websites into mobile apps by putting them in a WebView (basically an iframe for native apps) and packaging that WebView as an iOS or Android app. I have high hopes for the future of PWAs, but right now I don’t see them as an effective way of reaching users. For it to show up on someone’s home screen, the user will have to visit the website and click the Install button at the bottom of the screen, which is an unfamiliar operation and goes against most users’ muscle memory of swiping away or clicking X on anything that covers site content. Typically, there’s a lot more to be done surrounding data caching, syncing, conflict resolution, and offline request handling than there is in simply making your app a PWA, and at the end of the day you still won’t have an app in either app store. Whether it will actually work is another story and really depends on how the web app was built. With the addition of a manifest file and service worker, a responsive web app can be quickly converted to something that will load without an internet connection. There are a couple of traditional ways for web developers to deliver offline experiences: By day, I’m a full-stack developer targeting desktop and mobile web, but considering the use cases for this app, we determined it needs to be fully-functional offline. We just feel like we're not yet sufficiently done with the non-static case.I recently worked on an app prototype with a friend in another industry. We can still add primitives needed to render static content efficiently. Instead, we optimize for volatile content, using tricks like lazy rendering and repaint boundaries. Flutter's current widgets and rendering primitives are biased towards dynamic content, where over-computation like this would hurt performance when you layout or paint isn't stable. This is one of the classic performance pitfalls on the web, even using "classic" frameworks, like React or Angular. When pages do invalidate HTML layout you will actually see very bad jank. Like when you know your array is sorted, you can use binary search to find an element instead of scanning. When you know your content layout is static and is highly biased towards vertical scrolling, you take different kinds of performance trade-offs, such as pre-computing and caching layout and painting output. It's mostly about algorithmic trade-offs.
0 Comments
Leave a Reply. |