React Native Open Source Update(facebook.github.io)
facebook.github.io
React Native Open Source Update
https://facebook.github.io/react-native/blog/2019/03/01/react-native-open-source-update
115 comments
Glad to see the team really embrace the nitty-gritty of keeping the open-source community healthy. React Native is a project with a lot of potential that's taken a few high-profile lumps this past year. Being an OSS maintainer can be difficult and thankless sometimes, but it's good to see teams that recommit to open source instead of withdrawing and focusing solely on internal needs.
'thankless'! They are getting paid big bucks as Facebook employees. What are you talking about?
I think parent means working on open source tasks is often "thankless" in the sense that it's extra work that doesn't necessarily benefit their employer.
That makes very little sense. They have use for it because it results in new features which are contributing to their business which would otherwise be both built and QCd by employees
Some things align w internal priorities and get done, others are issues FB people have not run into and they ask for contributions from whoever is affected.
In my experience, it's a fairly common theme in projects like jest or yarn.
In my experience, it's a fairly common theme in projects like jest or yarn.
If their work didn't benefit Facebook (or at least if Facebook didn't believe their work benefited it), they would not get paid for it.
Also: What kind of person feels bad because their work merely benefits society but not Facebook?
Also: What kind of person feels bad because their work merely benefits society but not Facebook?
If that entails working on OSS tasks on your personal time at the expense of spending time w/ family/friends (because you can't justify spending company time on it to your boss), I'd say a lot of people would choose to not "benefit society" / pamper demanding freeloaders / whatever you wanna call it.
I fully understand why people would choose not to work for free. But that was not the question. Work that does not benefit your employer tends to be work that your employer does not pay you for, but they're not the same.
Well, aside from money though have you seen some of the issues created on git repos and their responses? The software is OSS and free, yet there are countless people who use it acting like they're high profile businesses deserving white-glove treatment and they'll totally take out their anger on a maintainer.
Can you share some examples?
To counter your point, you might remember the React team's about face when probably their largest benefactor in terms of free goodwill, Wordpress, threatened to drop ReactJS for its ambiguous license. I would think it matters a lot to FB right now that they don't do anything remotely annoying to the community.
I would be willing to bet that if Facebook adopted an attitude of "screw it, lets just stop responding to these idiots" that will make even fewer people want to work at Facebook right now, given all the bad press these days. I bet if you ask people why they are still continuing at Facebook these days, a fair number would say something like "Yeah, at least I can work on open source projects".
If anyone at Facebook reading this wants to go for a dare, why don't you try dropping support for a high profile open source project like ReactJS and see if that affects the candidates entering your pipeline.
I would be willing to bet that if Facebook adopted an attitude of "screw it, lets just stop responding to these idiots" that will make even fewer people want to work at Facebook right now, given all the bad press these days. I bet if you ask people why they are still continuing at Facebook these days, a fair number would say something like "Yeah, at least I can work on open source projects".
If anyone at Facebook reading this wants to go for a dare, why don't you try dropping support for a high profile open source project like ReactJS and see if that affects the candidates entering your pipeline.
> why don't you try dropping support
I hear that sort of happened w/ ReasonML. Apparently Jordan still maintains it (because he's a prolific OSS guy like that), but FB itself is not investing in it, and is instead doubling down on Flow.
Jest is another project that largely yielded governance to its community.
You gotta understand that the number one incentive for someone to interview at FB is compensation. OSS opportunities are often a minor perk, and many (most?) employees don't do high profile OSS at all.
I hear that sort of happened w/ ReasonML. Apparently Jordan still maintains it (because he's a prolific OSS guy like that), but FB itself is not investing in it, and is instead doubling down on Flow.
Jest is another project that largely yielded governance to its community.
You gotta understand that the number one incentive for someone to interview at FB is compensation. OSS opportunities are often a minor perk, and many (most?) employees don't do high profile OSS at all.
Can I have more information on the "high profile lumps this past year"? Thanks!
This is great!
I like to think that React — or more generally, component-driven user interface design — is the future of development on all platforms, not just the web. It really seems like we have “peaked” with concepts like state management, composability, and so on. Don’t get me started on how nice hooks will be in the mobile dev ecosystem.
I feel like React Native has taken a hit in the last year or so, with large companies saying they are moving away from it. I really hope that the RN community continues to flourish because I think it will inspire other platforms to move toward better developer experiences.
I like to think that React — or more generally, component-driven user interface design — is the future of development on all platforms, not just the web. It really seems like we have “peaked” with concepts like state management, composability, and so on. Don’t get me started on how nice hooks will be in the mobile dev ecosystem.
I feel like React Native has taken a hit in the last year or so, with large companies saying they are moving away from it. I really hope that the RN community continues to flourish because I think it will inspire other platforms to move toward better developer experiences.
I would hardly say we have peaked. I think there’s plenty left to discover. I think the web was vastly behind other user interface systems and just took a decent jump with Angular and React. There’s a lot left to discover though.
Well, UI has been component driven forever - although we faltered on Web UIs. For instance, the entire control library in late 90s Visual Basic were components, and people would build re-usable custom components and forms just like you would on React. It went even beyond that - need a Telephony connection or TCP Listener? Drag a TCP component on to your application surface and set some props visually (like port number). It really was that easy.
We haven't peaked. If you leave out the closed-source nature of the Microsoft dominated tech scene, the tech from the 90s is arguably better than what we have now.
We haven't peaked. If you leave out the closed-source nature of the Microsoft dominated tech scene, the tech from the 90s is arguably better than what we have now.
"Unfortunately, this is not something that we experience ourselves because we run React Native from master."
What does this mean? Does this mean they're always on the very latest RN version? If so, wouldn't this constantly break like many layers of dependencies?
I kind of like the idea though.
What does this mean? Does this mean they're always on the very latest RN version? If so, wouldn't this constantly break like many layers of dependencies?
I kind of like the idea though.
I work at google, and we run everything at head. The code is expected to be working state including all the dependencies, and there are precommit/presubmit hooks to help that.
(Nearly) all of Facebook exists in a single repository, so all dependencies are building against other dependencies at ~master. Things do break, but extensive automated testing goes a long way.
Non-facebook users are in a less fortunate position though, because while the automated testing might keep their dependencies working, yours will break. So people tend to stick to certain release and avoid upgrading at all costs, trying to find a permutation of library and RN versions where everything is mostly working and rest can hacked around. All bug reports by react-native team have traditionally been treated with 'please upgrade to latest release' which makes things problematic, because while your specific issue might be solved, you'll have bunch of new ones caused by the new release and your dependencies not playing nice. Hopefully there will be some improvement with this in the future.
That is what it means. We are also doing this! It is worth it if you ship only iOS imo.
While I like react Native, in my opinion Flutter from Google is proving to be far more superior as a cross platform app development technology. The apps are incredibly fast, feel far more native, and are actually fairly easy to build.
I went down this path of trying both and ultimately ended up building my side project with flutter. My project is a cross platform App that reads articles to you using some great sounding open source AI/ML models by converting any article to audio so you can maximize that dead time on your commute.
This is a little self promotional but if you want to see what’s possible with Flutter, you can check it out here:
https://articulu.com
Edit: while I get folks may be upset with my comment and are down voting me, I’ve geniunely worked with both technologies so I’m not just making this up.
I went down this path of trying both and ultimately ended up building my side project with flutter. My project is a cross platform App that reads articles to you using some great sounding open source AI/ML models by converting any article to audio so you can maximize that dead time on your commute.
This is a little self promotional but if you want to see what’s possible with Flutter, you can check it out here:
https://articulu.com
Edit: while I get folks may be upset with my comment and are down voting me, I’ve geniunely worked with both technologies so I’m not just making this up.
> feel far more native
I don't see how emulated native controls can feel more native than actual native controls.
I don't see how emulated native controls can feel more native than actual native controls.
Give it a shot before you knock it, Flutter uses its own Native rendering engine written in C++. It is very fast and responsive.
It might be fast and responsive, but correct it is not. Flutter's widgets don't feel "native"; they feel like someone made a somewhat poor facsmile of the real thing because that's exactly what they are.
When you want your UI to stand out you would anyway move from native look. Flutter is very good for that.
As a user, I don't want your UI to "stand out". I want it to be consistent with everything else, so I don't have to re-learn what a button looks like. For me at least, attempts to do "branding" in this manner backfire big time - I'll recognize the brand alright, but now I have a strong negative association with it.
They are already different on each platform be it iOS android or web. Consistent for me would be same in all platform which would be a browser for most cases.
Yeah, no. I don’t want your UI to stand out, and if it does it stands out for breaking my expectations of how I expect apps to work on this platform. Every platform has a couple of things that are considered “acceptable” to customize (fonts, logos, colors) and things that are sacred and inviolable (accessibility, text editing, system API). Apps that use Flutter cannot tell the difference, and use experience suffers.
Browser apps are not native and users have accepted it. What you abt users experience might be different from theirs.
Not emulated. Painted at the OS level, same as native controls. Uses https://skia.org/. I second the grandparent poster's opinion about runtime speed and developer productivity, but Flutter is still not mature enough for production.
You are correct but I obviously disagree on not mature enough for production, I’m in production with paying users. :)
I'm glad to hear that. Let me know your experiences. We've a customer base of about 0.5 million, and ours is a mission critical system. Which is why I'm currently reluctant to use Flutter, even though I'm a huge fan.
They’re “emulated” in the sense that they are custom widgets designed to mimic the appearance and behavior of widgets from the OS’s native UI framework. They’re fine from a performance perspective, AFAIK, but you run the risk of the replicas imperfectly emulating some aspect of the originals’ behavior and creating an “uncanny valley” effect.
Emulated in the sense that it's a separate rendering of the components versus using the OS's components directly.
You're right; what word would fit something that is not the real deal, but is crafted in a way to be almost indiscernible? Would it be, emu... emula... oh it's just on the tip of my tongue.
I downloaded this to see if VoiceOver support is still as broken as it used to be and its surprisingly functional. And it really is fast. I can still "feel" that it‘s not native, but it actually might be close enough.
You should put labels on your image buttons though.
You should put labels on your image buttons though.
Thanks for trying it and for the feedback.
My only problem with Flutter is that Dart is a hard sell from an organizational perspective. We'd have to justify teaching our engineers a language they'll only ever need for the purpose of using one mobile app framework.
Taking a quick look over Dart’s syntax it doesn’t look very difficult to learn. If folks know a C-like language it looks pretty familiar. I’d guess people would spend a lot more time learning the Flutter API, etc than Dart.
For a lot of people it's not only the difficulty of learning, but also people get weary their skills might not be marketable for their next job. Marketability goes the other way too-- will this programming language be points-against by future prospective employees?
There's also developer experience-- there's a ton of tools available for JavaScript, developed by people across the industry-- and long-term maintainability. JavaScript has a solid record of backwards compatibility and multi-platform support, plus lately its been getting lots of cool new features. Adopting Dart could sound like becoming too dependant on Google and the decisions they make, especially considering that forking or migrating a programming language is a harder than doing so with libraries.
I don't know how big all these concerns would are when considering Dart, but it's things organizations thinking of switching/adopting a new programming language need/tend to think about ¯\_(ツ)_/¯
There's also developer experience-- there's a ton of tools available for JavaScript, developed by people across the industry-- and long-term maintainability. JavaScript has a solid record of backwards compatibility and multi-platform support, plus lately its been getting lots of cool new features. Adopting Dart could sound like becoming too dependant on Google and the decisions they make, especially considering that forking or migrating a programming language is a harder than doing so with libraries.
I don't know how big all these concerns would are when considering Dart, but it's things organizations thinking of switching/adopting a new programming language need/tend to think about ¯\_(ツ)_/¯
I know your post appears self promotional and is slightly out of context but I'm glad you posted it. I've been looking for an app like yours for years and the audio quality is pretty good. I realize that text to speech of this quality has only been around for a year or two.
The app UI feels native on Android and performs well.
The app UI feels native on Android and performs well.
Can flutter compile to browsers?
Apparently not yet.
Addition of PWA support would be quite compelling. If you then added in the ability to swap Dart with, for example, TypeScript, then Flutter adoption would explode.
The "code once, run everywhere" landscape is filled with compromises at the moment.
Addition of PWA support would be quite compelling. If you then added in the ability to swap Dart with, for example, TypeScript, then Flutter adoption would explode.
The "code once, run everywhere" landscape is filled with compromises at the moment.
Dart already failed once on the browser, Flutter is just its last hope to stay relevant.
Why would a Flutter app “feel more native” than RN, which actually uses native widgets?
You've promoted your startup in almost every top level comment you've made in the last month, maybe give it a break?
Well, it’s a side project right now but I hear you..
I am trying hard to making sure to comment on things that are relevant and trying to add value with a little self promotion sprinkled in and I’m sorry about that but the feedback has been incredibly useful.
I am trying hard to making sure to comment on things that are relevant and trying to add value with a little self promotion sprinkled in and I’m sorry about that but the feedback has been incredibly useful.
Can you point me to these open source AI/ML models? I'd like to learn from these.
Disagree strongly.
While the build chain, documentation, marketing etc is nicer - it definitely has an uncanny valley situation going on in iOS at least. It NEARLY feels native.. but something's not quite right.
Also rendering performance really sucks on the XS Max. Even the most basic of list view examples will drop frames.
While the build chain, documentation, marketing etc is nicer - it definitely has an uncanny valley situation going on in iOS at least. It NEARLY feels native.. but something's not quite right.
Also rendering performance really sucks on the XS Max. Even the most basic of list view examples will drop frames.
This is on me :S I created a lot of those widgets on iOS. I'd really like to learn more from your experience however. What would you say are the main things that made it feel off?
Here's otherwise a list of things we're working on right now https://github.com/flutter/flutter/projects/9.
Here's otherwise a list of things we're working on right now https://github.com/flutter/flutter/projects/9.
You're being downvoted because people disagree with you.
I've researched both, and Flutter is far from superior.
They don't have a production way to target desktop platforms, and it's not a native experience, it's an emulated UI. It's noticeable on iOS.
Also noone wants to learn a language from Google just for it to be abandoned in X years.
Even if they don't abandon the language, how can you expect Flutter, which hinges on them updating the renderer for every release of iOS to match the native look and feel (which it fails at right now), to stay alive? Google can barely maintain a chat app let alone emulate a UI that isn't theirs.
And this is all for an experimental OS they haven't even put full faith in yet.
I've researched both, and Flutter is far from superior.
They don't have a production way to target desktop platforms, and it's not a native experience, it's an emulated UI. It's noticeable on iOS.
Also noone wants to learn a language from Google just for it to be abandoned in X years.
Even if they don't abandon the language, how can you expect Flutter, which hinges on them updating the renderer for every release of iOS to match the native look and feel (which it fails at right now), to stay alive? Google can barely maintain a chat app let alone emulate a UI that isn't theirs.
And this is all for an experimental OS they haven't even put full faith in yet.
Hi, I'm working on said emulated UI :) and absolutely value community input on our prioritization. There's definitely still many things that are work in progress for iOS (https://github.com/flutter/flutter/projects/9), though we'd love to get your thoughts on what are the most noticeable failures as well.
React native is pretty cool, but I do wish they would add support for desktop apps, not just ios and android. Proton native exists and seems stable-ish, but the underlying cross platform UI library (libui) still says it's only at an alpha level.
Have you seen React Native Windows (https://github.com/Microsoft/react-native-windows) and react-native-macos (https://github.com/ptmt/react-native-macos)? I haven't used either, but they both look very popular, 5k-10k stars on Github.
I was aware, but I don't recall those projects being very active. Additionally, IIRC they're both implementing their UI widgets differently rather than trying to build a common API that is desktop agnostic. There also is this project: https://github.com/status-im/react-native-desktop which seems somewhat more active, and also supports linux (which is much more important to me than windows support).
I downloaded the macOS UI Explorer, and it seems to not be using vibrancy correctly.
React is competing with web components which is a much better way of achieving what you're talking about https://www.webcomponents.org
Correct me if I'm wrong, but using webcomponents as an alternative to a hypothetical version of react native for desktop apps would require loading said web components into a webview, say via Electron; am I correct in that? If so, then I'd d strongly disagree that that is a better way of doing things. While I'm not an electron hater like many around here, react native's approach seems far superior.
ReactXP is the most mature mobile/desktop RN project and being used to develop the new Skype.
It provides common components to glue react-windows, react-macos, and react-native together.
The downside is you have to roll most of the components yourself due to a lack of UI lib, but it has all of the core components, and imo that's better.
The really cool thing about react-windows is it builds UWP apps so you can target Xbox, W10, and Windows Mixed Reality natively. MacOS support is experimental but the core is there. Linux support can be achieved with Electron (I know, not native, but maybe someone will make a react-qt project)
https://microsoft.github.io/reactxp/
It provides common components to glue react-windows, react-macos, and react-native together.
The downside is you have to roll most of the components yourself due to a lack of UI lib, but it has all of the core components, and imo that's better.
The really cool thing about react-windows is it builds UWP apps so you can target Xbox, W10, and Windows Mixed Reality natively. MacOS support is experimental but the core is there. Linux support can be achieved with Electron (I know, not native, but maybe someone will make a react-qt project)
https://microsoft.github.io/reactxp/
According to their documentation, the _only_ desktop platform they support natively (that is, without something like electron) is windows 10:
> Other platforms such as Windows 7 & 8, MacOS, and Linux can be targeted using a web wrapper solution like Electron.
That's interesting, but Macos/linux support are a hard requirement for what I work on professionally / side projects though. Windows support isn't.
> Other platforms such as Windows 7 & 8, MacOS, and Linux can be targeted using a web wrapper solution like Electron.
That's interesting, but Macos/linux support are a hard requirement for what I work on professionally / side projects though. Windows support isn't.
They support UWP which includes all modern Windows environments (Windows 10, Xbox One, Windows Mixed Reality)
There is experimental support for MacOS, but it's actually very far along, close to being usable for production if not already.
Linux support isn't very widespread for many cross-platform technologies in the first place, so Electron is the best bet there. Maybe someone will make a react-qt project.
There is experimental support for MacOS, but it's actually very far along, close to being usable for production if not already.
Linux support isn't very widespread for many cross-platform technologies in the first place, so Electron is the best bet there. Maybe someone will make a react-qt project.
> Maybe someone will make a react-qt project.
There's https://github.com/status-im/react-native-desktop
It'd be nice to have a React Native for GTK though. There's https://github.com/Place1/react-native-gtk but it's abandoned. React Native for GTK might get ReactXP natively onto Linux: https://github.com/Microsoft/reactxp/issues/41
There's https://github.com/status-im/react-native-desktop
It'd be nice to have a React Native for GTK though. There's https://github.com/Place1/react-native-gtk but it's abandoned. React Native for GTK might get ReactXP natively onto Linux: https://github.com/Microsoft/reactxp/issues/41
We used React Native back then when it first came out. Surprisingly the problems that exists back then, still exists today like red error screen, slow TableView scroll, upgrading RN problems.
It is too late for Facebook because a lot of high profile startups are moving away from it. When you release something like this and then have the OSS deal with it and not responed to PRs for several months and years, it leaves a bad taste.
It is too late for Facebook because a lot of high profile startups are moving away from it. When you release something like this and then have the OSS deal with it and not responed to PRs for several months and years, it leaves a bad taste.
To that extent, I also found that Android is usually treated as a 2nd class citizen. Which is understandable, given the marketshare, but frustrating nonetheless. It often sounds like something is easily do-able (like Accessibility) ... IF you're on iOS. We recently developed an app for a client of ours for Android, replicating their native iOS app in React Native. That was not a good experience.
> given the marketshare
FYI, Android has 75% of marketshare worldwide and 55% in the US.
FYI, Android has 75% of marketshare worldwide and 55% in the US.
I think it's more the marketshare of who will pay for apps/subscriptions, which is often quoted as tilted towards iOS users. I'm not sure how true that is, though it make some sense given how many apps cost money on iOS vs Android and that iOS devices are on average more expensive.
I'm not sure if that's true anymore. Last year I switched to Android and paid for some high quality apps, spending more than I have probably ever on Apple. I've noticed that Android free apps are usually more restrictive and pester the user to upgrade more than they do on iOS - I assume Apple ban this, but these dark patterns must work otherwise why would a company tarnish their image with them?
If you look at Android users as a whole, percentage wise of course they will pay less because they are a lot more popular in less well off countries. On the other hand Google's carrier billing support is a lot more extensive than Apple's, so actually being able to pay is less friction.
If you look at Android users as a whole, percentage wise of course they will pay less because they are a lot more popular in less well off countries. On the other hand Google's carrier billing support is a lot more extensive than Apple's, so actually being able to pay is less friction.
During the past year I’ve worked with 2 large Fortune 500 companies (they are everywhere globally and everyone knows them) whose main business is in consumer products and services.
Amount of paying mobile users for both companies is clearly dominated by the iOS. About 1:5-1:10 ratio.
Amount of paying mobile users for both companies is clearly dominated by the iOS. About 1:5-1:10 ratio.
is that globally or in the markets like US, i assume
it a lot closer in markets that have more hi end devices and disposable income.
but it is sure that apple customers are more used to pay for applications. that's something that i noticed like 8 years when i switched from windows to osx/macbook. while on windows you could find free basic utility software like rippers converters and so on, on macbook they usually where paid applications.
but it is sure that apple customers are more used to pay for applications. that's something that i noticed like 8 years when i switched from windows to osx/macbook. while on windows you could find free basic utility software like rippers converters and so on, on macbook they usually where paid applications.
I don't have any recent numbers, but high(er) end clients generally go iOS first due to their own market expectations and distribution.
I don’t think it’s meant to be, there are definite edge cases that are very hard to solve, such as when manufacturers decided to alter android behavior. I also think that the ecosystem has far more iOS engineers than it does android, which leads to an imbalance in support.
Disclaimer: am contributor to react-native & iOS dev.
Disclaimer: am contributor to react-native & iOS dev.
You called out the red error screen and that's something that they explicitly called out as fixed in this version of React Native.
And it looks like they are a lot faster about responding to PRs now.
Tt seems to me like they are doing a good job improving React Native!
And it looks like they are a lot faster about responding to PRs now.
Tt seems to me like they are doing a good job improving React Native!
Flutter seems like a great substitute today, at least for Android.
Have fun with it being abandoned by Google in X years.
Might as well develop natively if it's only good for Android.
Flutter imitates native by rendering everything from scratch, after a few major updates to iOS that's bound to be abandoned.
Might as well develop natively if it's only good for Android.
Flutter imitates native by rendering everything from scratch, after a few major updates to iOS that's bound to be abandoned.
Some applications especially heavily customized and complex ones profit from consistent UI across platforms.
I created many apps with React-Native that could also be built with web technology and would mostly look and feel the same.
But you're right with Google tech being abandoned; I prefer Revery to Flutter.
I created many apps with React-Native that could also be built with web technology and would mostly look and feel the same.
But you're right with Google tech being abandoned; I prefer Revery to Flutter.
I like Revery. It actually seems a bit more approachable than Flutter and it's goals are pretty good (Supporting the Web as a compile target is important nowadays).
But how much more certain is the support for Revery over that for Flutter? What's Outrun's history with large projects? What incentives do they have?
But how much more certain is the support for Revery over that for Flutter? What's Outrun's history with large projects? What incentives do they have?
Flutter is also aiming to target the web:
https://medium.com/flutter-io/hummingbird-building-flutter-f...
Revery looks really good, but it isn't ready yet.
It has a very similar approach to a React/RN project.
I'd eventually switch over to Revery when/if it's production ready.
It has a very similar approach to a React/RN project.
I'd eventually switch over to Revery when/if it's production ready.
>because a lot of high profile startups are moving away from it
Lucky for everyone there is a world beyond "high profile startups" whatever that means. You may even argue "high profile startups" is an irrelevant percentage in the job market.
Lucky for everyone there is a world beyond "high profile startups" whatever that means. You may even argue "high profile startups" is an irrelevant percentage in the job market.
I have started to interpret "startup" as a synonym for "company".
Startup is the hip thing all want to be, but really the point is providing something for money, which is what any boring company does.
Which high profile startups are moving away from it?
I’d say AirBnB is no longer a startup... with their pockets I’d also have native teams.
AirBnb always comes up as an example of a team abandoning RN but it seems like no one actually read the entire blog post. Migrating an existing native app to RN is going to be hard for anyone. Starting from scratch with CRNA? Not so much.
Uber: https://twitter.com/alanzeino/status/1101167947874103296
I also talked to someone from Fb recently, and he said that even some internal teams have moved away from it.
I also talked to someone from Fb recently, and he said that even some internal teams have moved away from it.
At WWDC 2017 I was in the keynote speech line with two of the Facebook client team devs. According to them the entire client team was trying to get rid of RN, so maybe they succeeded.
Great. Maybe that will mean less sluggish desktop apps executed in a browser and more native language experiences.
Unlikely, since RN isn’t executed in a browser.
Not a browser, but it is a whole lot of JavaScript (it running inside of a browser would be so much worse, try any Cordova app, even "modern" ones like Notion).
Is the colour and visual display of errors really considered a significant problem that prevents technology adoption? I must be getting old.
The red screen error isn’t about the color. It’s in reference to the uninformative error screen that often pops up when developing with React Native. The amount of information you get from the error, stacktrace, etc. is not all the dissimilar to seeing a blue screen of death on Windows. It could have been any color and the issue would have been the same.
Visual consistency is important. Users quickly become suspicious when they see visual glitches (think of your car making weird screeching noises while driving).
React and redux are nice but I'd never use it for native again personally. You update it to fix one bug only to get 2 more in its place, after you spend a day updating and fixing your app. I've spent less time coding entire Android apps than I have hunting bugs down in rn apps.
It really is unbelievably painful trying to work within the RN ecosystem. There's so much promise but ol well.
I'm really torn here between React Native and just building a PWA.
I'm building a tool for managing your reading across devices. IT basically allows you to suspend and resume your reading easily and supports caching web pages offline and reading them like you would a PDF.
https://getpolarized.io/
Right now I'm torn between a PWA and React Native.
Our PWA code is React, just not react native.
Being a PWA means I don't have to deal with React Native issues and I can keep the same code across my entire app.
The changes that Microsoft has made to their app store to support PWAs are really nice.
Additionally Google has their new 'custom web view' that allows you to compile a PWA into an Android App.
Part of the whole thing with the app store is being discoverable.
You might be a PWA but people are taught to go to the app store to find new apps to install.
However, with React Native I think you would have to do a bit more work but your app would look better on that platform.
Has anyone had to make this decision lately? Would love to hear your feedback.
I'm building a tool for managing your reading across devices. IT basically allows you to suspend and resume your reading easily and supports caching web pages offline and reading them like you would a PDF.
https://getpolarized.io/
Right now I'm torn between a PWA and React Native.
Our PWA code is React, just not react native.
Being a PWA means I don't have to deal with React Native issues and I can keep the same code across my entire app.
The changes that Microsoft has made to their app store to support PWAs are really nice.
Additionally Google has their new 'custom web view' that allows you to compile a PWA into an Android App.
Part of the whole thing with the app store is being discoverable.
You might be a PWA but people are taught to go to the app store to find new apps to install.
However, with React Native I think you would have to do a bit more work but your app would look better on that platform.
Has anyone had to make this decision lately? Would love to hear your feedback.
What’s the name of your app again?
Polar: https://getpolarized.io/
FYI I've reported that url to AdBlock
Why?
I've seen them drop the name numerous times before. I have no problem with Polar (other than it not working for me at all), but constantly seeing the link dropped makes it feel a bit Ad-y and, especially on HN, people tend to distrust /be annoyed by people doing this.
I would also like to query why? I even looked through the code to check for any malicious code and came up empty handed.
Hey, it depends on what you are building. I have found with React Native + Expo is that you can mostly avoid native code until you need something that isn't supported by React Native (eg. payment integration) - in that case you will need to eject the app. You would have to manage routing on the app, etc.
If your background is in web dev, building a PWA should be much easier.
If your background is in web dev, building a PWA should be much easier.
When did google hijack the PWA term? https://developers.google.com/web/progressive-web-apps/
It used to just mean you would build on standard html features so your app would fallback to it and still work if your crazy new JS driven input type didn't work the way you expected, and for accessibility purposes. I don't see either of those goals mentioned.
It used to just mean you would build on standard html features so your app would fallback to it and still work if your crazy new JS driven input type didn't work the way you expected, and for accessibility purposes. I don't see either of those goals mentioned.
That sounds to me like you are describing "Progressive Enhancement", PWA's are different. To answer your question, according to Wikipedia the name got coined in 2015. https://en.m.wikipedia.org/wiki/Progressive_web_applications
Sounds to me like you are right.
Have you considered Cordova/PhoneGap? Do you need native features?
I think if you're a small developer, having something that works across iOS, Android and the web with the least effort is usually worth more than native integration.
I think if you're a small developer, having something that works across iOS, Android and the web with the least effort is usually worth more than native integration.