7 ms·

I feel bad for any poor soul who has to maintain a professional high-quality phonegap / cordova / ionic app. Such a buggy, unperformant, brittle ecosystem. Then

I feel bad for any poor soul who has to maintain a professional high-quality phonegap / cordova / ionic app. Such a buggy, unperformant, brittle ecosystem. Then to top it off you need tons of if / else everywhere for each platform, negating a lot of the benefits. React Native is an order of magnitude better, still has a lot of issues but at least it's maintainable.

jordache 9y ago
isn't FB's license very restrictive for many enterprise use cases?
- shamas 9y ago
  Is it?
- rosser 9y ago
  The apparently controversial part of the React license simply says that if you sue Facebook for anything patent-related, your license to the patents underlying React is automatically revoked. Otherwise, it's just BSD.
  - deleted 9y ago
    [deleted]
  - tuxracer 9y ago
    And I might add GOOD! This type of creative licensing seems like an end-around a Congress and US Patent administration that seems woefully unwilling to make desperately needed reforms when it comes to software patents. If Congress is unable or unwilling to act then why not take it upon ourselves to include these types of clauses in even more licenses?
  - ec109685 9y ago
    It's BSD, period. Additionally they added a patent grant as long as you don't sue them for patent infringement. They could have simply remained silent on the issue and it would be worse for developers. A patent grant is only a positive thing.
  - lvillani 9y ago
    Wouldn't it make more sense to revoke the patents only if you sue them over React patents specifically? IANAL Hypothetically, there _may_ be good reasons to sue Facebook over patents unrelated to React, especially if they happen to break a patent you or your company owns. However, that would mean loosing access to React if I happen to develop applications that use that. Wouldn't such a blanket statement skew the power balance excessively in Facebook's favor?
    - rosser 9y ago
      Yes it would. Deliberately so, I'd say.
- guelo 9y ago
  Personally I would not want to work for a company that wants to retain the right to start a patent war with Facebook for unknown reason.
  - aedron 9y ago
    What if Facebook legitimately broke your patent?
    - Vinnl 9y ago
      Then you should still be able to win if you're not using any Facebook patents on React. If you do (I have no idea if Facebook has relevant patents on React that would harm you), then consider your allowing Facebook to use your patents a fair deal with Facebook allowing you to use theirs.
  - Flimm 9y ago
    What if the reason is that Facebook started a patent war with them? Is it fair that Facebook disables all of their opponents' patents, whether they are related to React or not? In my mind, that's not fair. If they promised to disable all of their patents, then that would be fair, but it's very one-sided.
- abritinthebay 9y ago
  No, but there's a lot of FUD floating around from people that don't understand Patent Grants and how they provide you, as an explicit license, with more rights than an implicit now-you-have-to-hope-you-can-prove-it-in-court license.
shortstuffsushi 9y ago
I still haven't gotten around to trying React Native, but after being burdened for almost two years with Cordova development and maintenance, I'm at best "afraid" to go back to any hybrid solution, and more realistically openly opposed. I even tried to contribute back (to Cordova, I still don't know what the value add of Adobe's PhoneGap is beyond it), but it's just such a mess. To see several years later now that they're still trying to push forward surprises me. I know there are many apps that were built on this platform, and are likely still in maintenance phases, but is anyone starting down that route these days? If not, maybe it's time instead for the incredible journey announcement as they shift into deprecation and closure. At least on Adobe's side, as stated above, I don't know what value they have in continuing their support. Let it live on as only an Apache product if it must go on.
- htormey 9y ago
  React native isn't a hybrid app like Cordova. I recently gave a talk on the differences which you might find interesting: https://t.co/7A48VDRHXU?amp=1 https://t.co/7A48VDRHXU?amp=1
- calsy 9y ago
  They most definitely should NOT sunset this project. Your issues are in no way a reflection of the majority of the cordova development community and projects don't need to be deprecated because you had some problems. People keep mentioning they have problems with cordova but never state what they are. If your project is a big mess that it's no fault of the cordova platform. It's a wrapper with some well maintained plugins that don't drastically change. What about cordova is so hard for you, prepare, build, run.. whats steps are causing you to question 'hybrid' apps in the future and what are other wonderfully awesome cross platform alternatives are available that allow developers to jump right in.
  - shortstuffsushi 9y ago
    It shouldn't be deprecated because of my issues, no. It should be because it's not something a new project is likely to start with like I was saying. If someone was starting a new project, it's unlikely they would pick Cordova as a platform, imo or from what I've seen. PhoneGap, owned by Adobe, in particular is a big question mark on top of that to me. Now, as to my specific issues, it's really the same as any other common anti-hybrid argument. One, it's never write once run across platforms, it's write once and then debug across all platforms and insert various hacks for bits of slight inequality between all of them. Two, plugins are native and consequently require knowledge of native to implement or, again, debug. If you're writing your own plugins, you can pretty easily get to a point where the js code is indeed write once for all platforms, but then you have to write the native portion for each still. This falls apart if you want to write more complex / device feature heavy apps. Given that may not be your use case, less complex apps are indeed easier to make cross platform. This isn't because "your project is a big mess," it's because you're trying to use features that aren't exposed to the browser js engine on the device. Three, bugs in Cordova. As with any external dependency, you're at the whim of their quality and release cycle. Various bits of fun, "legacy" / backwards compat, and design decisions combine to lead to situations where things like the onload of the page in the cordova.js file is wrapped in a setTimeout intended to fix a problem on a platform a couple years ago in some way ends up taking your page nearly a second to display as it waits to gets it's turn on the js execution cycle again. Sure, one off example, but the one that I remember digging into. I logged a number of issues during my time, though. Four, and perhaps most opinion based, the apps you're making almost never feel native. You spend all your time trying to make the app feel closer to what it would be if you wrote it natively, or look closer, or whatever, but you're again at the mercy of the js engine on the device. There are cases where it just can't compete, period. So, what's so hard about Cordova for me? No one thing. Many little things. I didn't even touch the build process and what to do when that starts acting up. The amount of time I spent fighting Cordova (and to be fair, other hybrid frameworks) in my experience was as much as it would have been to write a nicer native app, and I would consequently never recommend anyone go that route for more than a trivial app. As for "allowing developers to jump right in," well, I think you're a bit misguided. It's not more user friendly than any of the native app starters, and tbh is probably less so. But that's all just my opinion, so keep writing whatever you enjoy.
codazoda 9y ago
I find React Native just as bad, if not worse. They don't try to keep backwards compatibility like PhoneGap did, which often means a few upgrades here or there. With React 15 we chose to rewrite the nearly 100 classes in our project because createClass is going away (we did choose to rewrite now rather than use a library for it and possibly rewrite later). Anyway, things are moving quickly in React and that creates similar burdens. Especially for large, slow moving applications.
- seibelj 9y ago
  Ultimately true native is the best. If you can engineer the maximum amount of logic in the backend and have the thinnest possible clients, you will be so much happier even with the "duplication".
  - aplummer 9y ago
    As a consultant this is the advice i always give clients. Put it on the server until you have just the flashy truly native UI left.
  - ntaso 9y ago
    Unless, of course, there's no backend and your app is a full-blown tool to run on the device only.
    - falcolas 9y ago
      You can still have 95% common code with shims to fit the different platforms. Oddly enough, the original Doom is one of the best examples of this process in action. It supports Windows, Linux, and a host of other OS targets, at a time the interfaces couldn't have been more different.
- abritinthebay 9y ago
  Personally I find not keeping things around just for legacy reasons a feature. As long as they signal deprecation with enough notice (which they are very good about) then it shouldn't be any real issue.
ntaso 9y ago
How is writing an entirely new view layer for every platform more maintainable than a few if-else trees? React Native doesn't come with good support for both platforms out of the box. Many components are unstyled. You still need to match the platforms' native behavior. TabBar is shit on iOS, you better go with TabBarIOS, and suddenly, you have exactly the same mess like in Cordova-based apps. The benefit of Ionic 2 is that there's hardly anything you have to do yourself to target the OS / device. It's all handled by Ionic.
Kiro 9y ago
What if you have a web game (canvas) you just want to wrap as an app? Obviously I can't use React Native for that.
- fredsted 9y ago
  If you just want a webview-as-an-app, then why not do it natively?
  - ntaso 9y ago
    Not your parent poster, but in a similar boat: Because I've written the game in JavaScript and it renders to Canvas. It also works in the browser. To go native, I'd have to rewrite everything from scratch. And then I have to maintain 3 platforms. Maybe Unity is the solution, but right now, it's not written with Unity.
    - LeoNatan25 9y ago
      If it's a web app, keep it on the web. Why does it have to have a native wrapper?
      - ntaso 9y ago
        Why? App Store exposure, client-side demand for an app, offline-first – and quite frankly, because it's written for desktops in mind and the mobile experience just sucks. Wrapping it in Cordova at least gives some control over the experience, such as: You can't accidentally swipe back on the browser, full screen, no address bar etc. Check out the Twitter PWA (https://mobile.twitter.com https://mobile.twitter.com). Accidentally swiping back happens to me a couple times per day.
- jordache 9y ago
  a web app means that you don't need to leverage the native UI controls provided by react Native. In this case, just use whichever platform is easiest and slap a webview on there. I don't even think going full native + webview is even an advantage compared to phonegap + webview
calsy 9y ago
I have a phonegap app with over half a million users. As a matter of fact it's been 2 years to this day since it was released and it's still going strong. Never had any real problems with phonegap and I've used all the major plugins. 'Order of magnitude' pfff, Why not get informed before running your mouth.
calsy 9y ago
I have a phonegap app with over half a million users. As a matter of fact it's been 2 years to this day since it was released and it's still going strong. Never had any real problems with phonegap and I've used all the major plugins. 'Order of magnitude' pfff, Why not get informed before running your mouth.
rickdg 9y ago
You'd be surprised with the many advantages webview apps have for specific use cases. Often, the client doesn't know what is needed, but it has to be ready by tomorrow and it might change before next week. Also, the app has to be on both stores before any real content is ready. And it needs to match the look of their website.

jordache 9y ago

isn't FB's license very restrictive for many enterprise use cases?

shamas 9y ago
Is it?
rosser 9y ago
The apparently controversial part of the React license simply says that if you sue Facebook for anything patent-related, your license to the patents underlying React is automatically revoked. Otherwise, it's just BSD.
- deleted 9y ago
  [deleted]
- tuxracer 9y ago
  And I might add GOOD! This type of creative licensing seems like an end-around a Congress and US Patent administration that seems woefully unwilling to make desperately needed reforms when it comes to software patents. If Congress is unable or unwilling to act then why not take it upon ourselves to include these types of clauses in even more licenses?
- ec109685 9y ago
  It's BSD, period. Additionally they added a patent grant as long as you don't sue them for patent infringement. They could have simply remained silent on the issue and it would be worse for developers. A patent grant is only a positive thing.
- lvillani 9y ago
  Wouldn't it make more sense to revoke the patents only if you sue them over React patents specifically? IANAL Hypothetically, there _may_ be good reasons to sue Facebook over patents unrelated to React, especially if they happen to break a patent you or your company owns. However, that would mean loosing access to React if I happen to develop applications that use that. Wouldn't such a blanket statement skew the power balance excessively in Facebook's favor?
  - rosser 9y ago
    Yes it would. Deliberately so, I'd say.
guelo 9y ago
Personally I would not want to work for a company that wants to retain the right to start a patent war with Facebook for unknown reason.
- aedron 9y ago
  What if Facebook legitimately broke your patent?
  - Vinnl 9y ago
    Then you should still be able to win if you're not using any Facebook patents on React. If you do (I have no idea if Facebook has relevant patents on React that would harm you), then consider your allowing Facebook to use your patents a fair deal with Facebook allowing you to use theirs.
- Flimm 9y ago
  What if the reason is that Facebook started a patent war with them? Is it fair that Facebook disables all of their opponents' patents, whether they are related to React or not? In my mind, that's not fair. If they promised to disable all of their patents, then that would be fair, but it's very one-sided.
abritinthebay 9y ago
No, but there's a lot of FUD floating around from people that don't understand Patent Grants and how they provide you, as an explicit license, with more rights than an implicit now-you-have-to-hope-you-can-prove-it-in-court license.

shortstuffsushi 9y ago

I still haven't gotten around to trying React Native, but after being burdened for almost two years with Cordova development and maintenance, I'm at best "afraid" to go back to any hybrid solution, and more realistically openly opposed. I even tried to contribute back (to Cordova, I still don't know what the value add of Adobe's PhoneGap is beyond it), but it's just such a mess. To see several years later now that they're still trying to push forward surprises me. I know there are many apps that were built on this platform, and are likely still in maintenance phases, but is anyone starting down that route these days? If not, maybe it's time instead for the incredible journey announcement as they shift into deprecation and closure. At least on Adobe's side, as stated above, I don't know what value they have in continuing their support. Let it live on as only an Apache product if it must go on.

htormey 9y ago
React native isn't a hybrid app like Cordova. I recently gave a talk on the differences which you might find interesting: https://t.co/7A48VDRHXU?amp=1 https://t.co/7A48VDRHXU?amp=1
calsy 9y ago
They most definitely should NOT sunset this project. Your issues are in no way a reflection of the majority of the cordova development community and projects don't need to be deprecated because you had some problems. People keep mentioning they have problems with cordova but never state what they are. If your project is a big mess that it's no fault of the cordova platform. It's a wrapper with some well maintained plugins that don't drastically change. What about cordova is so hard for you, prepare, build, run.. whats steps are causing you to question 'hybrid' apps in the future and what are other wonderfully awesome cross platform alternatives are available that allow developers to jump right in.
- shortstuffsushi 9y ago
  It shouldn't be deprecated because of my issues, no. It should be because it's not something a new project is likely to start with like I was saying. If someone was starting a new project, it's unlikely they would pick Cordova as a platform, imo or from what I've seen. PhoneGap, owned by Adobe, in particular is a big question mark on top of that to me. Now, as to my specific issues, it's really the same as any other common anti-hybrid argument. One, it's never write once run across platforms, it's write once and then debug across all platforms and insert various hacks for bits of slight inequality between all of them. Two, plugins are native and consequently require knowledge of native to implement or, again, debug. If you're writing your own plugins, you can pretty easily get to a point where the js code is indeed write once for all platforms, but then you have to write the native portion for each still. This falls apart if you want to write more complex / device feature heavy apps. Given that may not be your use case, less complex apps are indeed easier to make cross platform. This isn't because "your project is a big mess," it's because you're trying to use features that aren't exposed to the browser js engine on the device. Three, bugs in Cordova. As with any external dependency, you're at the whim of their quality and release cycle. Various bits of fun, "legacy" / backwards compat, and design decisions combine to lead to situations where things like the onload of the page in the cordova.js file is wrapped in a setTimeout intended to fix a problem on a platform a couple years ago in some way ends up taking your page nearly a second to display as it waits to gets it's turn on the js execution cycle again. Sure, one off example, but the one that I remember digging into. I logged a number of issues during my time, though. Four, and perhaps most opinion based, the apps you're making almost never feel native. You spend all your time trying to make the app feel closer to what it would be if you wrote it natively, or look closer, or whatever, but you're again at the mercy of the js engine on the device. There are cases where it just can't compete, period. So, what's so hard about Cordova for me? No one thing. Many little things. I didn't even touch the build process and what to do when that starts acting up. The amount of time I spent fighting Cordova (and to be fair, other hybrid frameworks) in my experience was as much as it would have been to write a nicer native app, and I would consequently never recommend anyone go that route for more than a trivial app. As for "allowing developers to jump right in," well, I think you're a bit misguided. It's not more user friendly than any of the native app starters, and tbh is probably less so. But that's all just my opinion, so keep writing whatever you enjoy.

codazoda 9y ago

I find React Native just as bad, if not worse. They don't try to keep backwards compatibility like PhoneGap did, which often means a few upgrades here or there. With React 15 we chose to rewrite the nearly 100 classes in our project because createClass is going away (we did choose to rewrite now rather than use a library for it and possibly rewrite later). Anyway, things are moving quickly in React and that creates similar burdens. Especially for large, slow moving applications.

seibelj 9y ago
Ultimately true native is the best. If you can engineer the maximum amount of logic in the backend and have the thinnest possible clients, you will be so much happier even with the "duplication".
- aplummer 9y ago
  As a consultant this is the advice i always give clients. Put it on the server until you have just the flashy truly native UI left.
- ntaso 9y ago
  Unless, of course, there's no backend and your app is a full-blown tool to run on the device only.
  - falcolas 9y ago
    You can still have 95% common code with shims to fit the different platforms. Oddly enough, the original Doom is one of the best examples of this process in action. It supports Windows, Linux, and a host of other OS targets, at a time the interfaces couldn't have been more different.
abritinthebay 9y ago
Personally I find not keeping things around just for legacy reasons a feature. As long as they signal deprecation with enough notice (which they are very good about) then it shouldn't be any real issue.

ntaso 9y ago

How is writing an entirely new view layer for every platform more maintainable than a few if-else trees? React Native doesn't come with good support for both platforms out of the box. Many components are unstyled. You still need to match the platforms' native behavior. TabBar is shit on iOS, you better go with TabBarIOS, and suddenly, you have exactly the same mess like in Cordova-based apps. The benefit of Ionic 2 is that there's hardly anything you have to do yourself to target the OS / device. It's all handled by Ionic.

Kiro 9y ago

What if you have a web game (canvas) you just want to wrap as an app? Obviously I can't use React Native for that.

fredsted 9y ago
If you just want a webview-as-an-app, then why not do it natively?
- ntaso 9y ago
  Not your parent poster, but in a similar boat: Because I've written the game in JavaScript and it renders to Canvas. It also works in the browser. To go native, I'd have to rewrite everything from scratch. And then I have to maintain 3 platforms. Maybe Unity is the solution, but right now, it's not written with Unity.
  - LeoNatan25 9y ago
    If it's a web app, keep it on the web. Why does it have to have a native wrapper?
    - ntaso 9y ago
      Why? App Store exposure, client-side demand for an app, offline-first – and quite frankly, because it's written for desktops in mind and the mobile experience just sucks. Wrapping it in Cordova at least gives some control over the experience, such as: You can't accidentally swipe back on the browser, full screen, no address bar etc. Check out the Twitter PWA (https://mobile.twitter.com https://mobile.twitter.com). Accidentally swiping back happens to me a couple times per day.
jordache 9y ago
a web app means that you don't need to leverage the native UI controls provided by react Native. In this case, just use whichever platform is easiest and slap a webview on there. I don't even think going full native + webview is even an advantage compared to phonegap + webview

calsy 9y ago

I have a phonegap app with over half a million users. As a matter of fact it's been 2 years to this day since it was released and it's still going strong. Never had any real problems with phonegap and I've used all the major plugins. 'Order of magnitude' pfff, Why not get informed before running your mouth.

calsy 9y ago

rickdg 9y ago

You'd be surprised with the many advantages webview apps have for specific use cases. Often, the client doesn't know what is needed, but it has to be ready by tomorrow and it might change before next week. Also, the app has to be on both stores before any real content is ready. And it needs to match the look of their website.