This article raises so much unfounded FUD it's hard to believe the author is serious.
1. Uncertain Roadmap - Does anyone seriously doubt FB's commitment to RN? When they themselves dogfood it? Or is it more likely they are just too busy making progress (since as the author points out they release every 1-2 weeks) to release a multiyear ROADMAP?
2. Patents - Is anyone here planning on suing FACEBOOK? Who amongst us has the team of lawyers to undergo that? This is for 99.999% of people not a legitimate concern. This is an RMS concern.
3. Javascript - New versions of Javascript address the vast majority of this. Type errors? Use well supported Typescript or Flow
4. Dependencies - This is a result of the Javascript communities overly enthusiastic packaging efforts. This is not an apples to apples comparison, but of all the cons mentioned, sure this is legit.
5. Alternatives - ...and Windows Phone? Seriously? I was rooting like hell for MSFT, but this is just not a thing. I'd rather cover 99.6% of users twice as fast than 99.999 of users painfully using Appcelerator
>Is anyone here planning on suing FACEBOOK? Who amongst us has the team of lawyers to undergo that? This is for 99.999% of people not a legitimate concern.
I don't think it is wise to think about this in these narrow terms. Consider the following scenario:
Avoidance of these problematic license terms becomes "a thing" in the industry that moves and shakers, but not the likes of us, are worried about.
You might have aspirations to sell your company to BigCo, or get investment from VCs.
Now we have a concern that use of problematic license code is a poison pill that these investors are not willing to swallow. You aren't considering suing Facebook, but they might think about it.
We saw exactly this with GLP'ed code in the past (I have signed a couple of deals where I had to pledge on a stack of bibles that we did not have any GPL code in our tree).
If they want to go to patent war with Facebook, they're going to have to answer to Facebook's patent portfolio counterclaims, whether they own companies which use React or not. Facebook owns thousands of patents they have bought over the years.
Your company or startup should focus on building a great product and attracting users.
The use of RN doesn't necessarily mean you are violating Facebook's patents, whatever they may be. RN is still published with a BSD license. One of your corporate affiliates better know they're starting a patent war and their code base will be analyzed for patent infringement counterclaims by Facebook's attorneys.
As a small startup, I absolutely love Facebook's React patent licensing. It gives me the advantage to use React (Native) while my bigger VC-funded competitors can't. It is like the opposite of economy of scale, haha.
> Does anyone seriously doubt FB's commitment to RN? When they themselves dogfood it?
After the shutdown of Parse, I don't see how anyone could avoid having doubt about Facebook's commitment to React Native, or to anything else outside of their core business.
To me, Parse instils confidence of Facebook's ability to handle (open source) projects. The shutdown of Parse would have to be one of the best sunsettings that I've ever seen.
They announced it in Jan 2016 and gave one years warning and shut it down in Jan 2017. Parse open sourced many of its components and provided an easy migration path for applications depending on it.
React Native, IMHO, is a fundamental part of their core business. Among many things, it lets them ship updates and more efficiently A/B test features more frequently. If Facebook gets sick of RN, at least it's a completely open source library that's able to be transitioned to fully community supported.
Parse was never used internally at Facebook I don't think. React Native is used for major parts of the main app and in parts of Instagram. I don't think it's an apples to apples comparison.
Push Notifications, Edit Profile, Photos Of view, Post Promote, Comment Moderation, Lead Gen Ads, SMS Captcha...and that was in February. They are ramping up their usage all the time.
They are gradually transitioning their code base to RN. Instagram has been in production for quite a few years now, it can't be an easy task to rewrite everything in RN. I think the above examples are significant, and they claim in the article that it's working well for them, so I expect them to continue to expand usage of it.
I'm still using Parse today, and it's still great. They shut down the Parse servers, but all the code is open source. Other hosting companies have popped up, and you can host it yourself. React Native doesn't have any servers to shut down. If Facebook stops maintaining it, the community will pick it up.
Regarding your second point -- that also includes the fact that you cannot sue any of the React contributors, not just Facebook. If I have a pull request on React, I can copy everything you ever built on React, down to the interface. It doesn't matter how much I copy because you cannot sue me without losing license to the very thing you used to build it, and thereby not having right to build it in the first place. Read the agreement in full, till point (iii).
> (iii) against any party relating to the Software.
No you do not lose the copyright license to use React in your code base. It is BSD. You only lose patent grants in the event you sue Facebook. In the event you sue Facebook, you're going to have to comb through your entire product code base and implementations for possible infringement against their portfolio of thousands of patents because you can bet your ass their legal team is going to come after you in retaliation. That is the nature of patent wars.
Yes. Dear God. It's just silly. The worst part of the whole thing is how un-silly it looks. The author must have spent at least a week (probably more) putting this together. I don't envy his manager. One of the toughest problems a manager has to deal with is an incredibly passionate engineer who is clearly wrong. How do you talk this guy down? Tough job.
if this engineer is as rational as he believes himself to be, then using rational arguments about why the risks are less than the gains is the best way to convince him.
Are there any examples of Facebook actually using React Native in a crucial way? All I've seen are parts of their native apps that could be replaced relatively easily. I don't think the "Facebook won't kill React Native because they use it" argument holds as much weight as we'd like to believe.
No. I've seen this written many many times, but where is the proof? The Facebook app has 230MB of native binary in there on iOS. It uses very little RN.
I just looked it up. They don't use it for the entire app, but they do use it for specific parts [1]. Since this was written over a year ago I wouldn't be surprised if more was converted.
As I said, they use it for some of the most esoteric screens. That's hardly "using" it. I have it on good authority that some portions of FB (such as Messenger) flat-out refuse to use it. It doesn't not instill confidence.
Esoteric might not be the right word, but I see your point. Without hearing from Facebook first hand, though, I don't want to discredit their internal use of React Native, especially since it is verifiably in products that they use, e.g. Facebook and Instagram mobile apps.
1. The world is full of framework-of-the-day made by Google, Facebook or Microsoft that was marketed as the next big thing of the century backed by unlimited commitment, and ended up abandoned without notice a couple of years later.
2. Not everyone is a small company with nothing to lose.
Oddly enough, Microsoft doesn't have its own client side ui framework, they build typescript and some other component stacks but leverage other UI frameworks in their products. React seems big in their office division - with outlook.com, office web and sharepoint using a lot of react - but pitch angular seemingly everywhere else.
I raised an eyebrow at Windows Phone being given 20% share on the "Portability" scale. And later again with 30% for MacOS.
But really, those charts at the end say it all for this particular developer - if he feels only 60% "Productivity" using React Native compared to 90% on competing platforms, his choice is obvious. I imagine for many developers the opposite (or even more so) is the case.
By your "developers", you mean JavaScript developers that only know JavaScript and are not willing to learn anything else? I am not familiar with many "native" developers who are more productive in RN.
I'm a native iOS developer, and I'm far more productive with React Native. I can't imagine how anyone wouldn't be, compared to building native iOS and Android apps in parallel.
You also don't get very far with React Native if you only know JavaScript. I've had to write a lot of Objective C and Java for native modules, and I picked up C# to integrate libraries for Windows Phone.
My experience exactly. There's an odd sneer often thrown about re 'knowing javascript'. From what I've seen of this region of the open-source javascript world (react, redux etc), much of it is at least as good and thoughtful code as I typically find in the native iOS and Android world.
Yes exactly -- and the blend of native and non native can be taken to other approaches, but many just look at things like nodejs and think solely JavaScript, even though there is an extensive c++ interaction layer through the napi that can be used to expose whatever you'd like
I'm a native iOS & Android developer, but treat native codebases as specialities now I've learned React Native. The latter is far more productive for me. If I were only building one codebase, then the differences would be marginal (perhaps Android/kotlin would be marginally faster to build). But for an iOS & Android app, there's no comparison: pure native in this case is overhead I could rarely afford.
Qt is still widely used despite lots of insane company merges (Trolltech -> Nokia -> Microsoft -> Digia -> Qt company). Probably because it's opensource.
> 2. Patents
If Facebook has patent for dynamic rebuilding of GUI from xml-like tree, then it may sue you for using XUL, XAML or your own code that does the same.
> 3. Javascript
Complains about type safety is laughable when compared to building apps directly in Java and Objective C.
Regarding (2) my team might not have plans to sue Facebook but one of other 40.000 colleagues of mine might in the future. Maybe they want to sue FB because they use some of the company's VR patents through Oculus.
Now I have to admit I don't know if their patents clause has any validity when we don't do business in the US, though.
>2. Patents - Is anyone here planning on suing FACEBOOK? Who amongst us has the team of lawyers to undergo that? This is for 99.999% of people not a legitimate concern. This is an RMS concern.
First, "RMS concerns" dismissed as silly and fantastic by "practical people" have been mostly proven totally valid. His dystopian essay "The Right to Read" [0] only becomes more relevant every year.
I've had to check my Amazon account 3-4 times to see if the book a friend and I were discussing supported "borrowing" it out for a limited time. Each time I've checked, it hasn't. Circumventing Amazon's controls puts my Amazon account at risk, which is hooked to my life in a lot of significant ways (AWS anyone?).
RMS may lack social graces but he is not a dummy. If anything, calling something an "RMS concern" should only call extra attention to its importance, by indicating that there's likely an understated risk that will go unrecognized by others for years.
-------
Second, you never know when you'll be in the 0.001%, and that's not a position you want to find yourself in if you are. Facebook is concerned about maintaining its position as the dominant social platform. When you're on a meteoric tear, they're going to bring suit against you whether it's justified or not just to try to starve you out and get you to fold, and ideally to find some reason why an injunction should be issued forbidding your site's continued operation. This license could certainly aid in that.
Things don't have to be very common to be unacceptably risky. Most unacceptable risks are in fact quite rare; you can go years riding in a car without a seatbelt or riding a motorbike without a helmet and be no worse for the wear.
The problem is that one time, years down the road, when it does matter. When failing to do that little thing will result in permanent, massive loss and/or damage. Maybe it won't happen to you, but it's so easy not to take the risk, that it's stupid to ever do so.
If you're building a product that you hope succeeds, it's stupid to use React or other software that contains a legal poison pill like this. It may not matter most of the time, but when it does matter, it really matters. The comparative cost of using Mithril or Preact or Vue is much, much more attractive than the cost of engaging in a multi-million dollar legal controversy with one of the world's most important companies, on one of the rare occasions when it really does matter.
Agreed, but you can't anticipate what another dev could write :)
Or if you pass down that `isConnected` down to a library where for some reason they assumed `null` should default to `true`
Of course it's very unlikely, but my point is you can't know all use cases of `this.state.isConnected` in advance on a large project so as you say it doesn't hurt to sanitize the input.
That's why there's PropTypes so you can define what type a given prop should be. An error is raised if a higher level component passes in a prop of an incorrect type.
>It's not any easier if you understand what !! does
which only applies if you're writing code for yourself. you can't expect everyone to know that idiom. same with using the + operator to cast to number, or an extreme case, the tadpole operator https://blogs.msdn.microsoft.com/oldnewthing/20150525-00/?p=...
I'm curious, which languages? I've never seen any of my colleagues write !!, ever, in C/C++, Java, Python, or Swift. I've also not seen it C# or Go, but my exposure is limited.
I've been paid to write code in Perl, PHP, Ruby, JS, Go, ObjC, and Java, plus a little C and Python, for going on 15 years. I'm pretty sure I've never written "!!" and I think I could count the times I've seen it used on one hand (maybe never in any codebase I've worked on, but I'm not entirely sure)
I spend chunks of every day looking at a C/C++ codebase and have never seen this. Taught Java for a year in college, I have never seen this. I would leave a note to a student for using this to be honest - too unclear, and (as this thread denotes) not well known enough to put in production worthy code.
I'm pretty surprised to hear this from someone who taught a programming course. It actually makes a ton of sense when you evaluate what is happening: it's the negative unary value and then the negative unary result of that value - there's no possible way it could be anything other than true or false. It's more of a side affect of the unary operator ! than it is a language feature, which I believe is why it sees such ubiquitous implementation.
> I would leave a note to a student for using this to be honest - too unclear, and (as this thread denotes) not well known enough to put in production worthy code.
You've done a total disservice to your students that understood negative unary operations then. Given how many upvotes my initial post on this thread has (currently 38) I don't think the thread denotes what you think it does at all.
You're basically wrong on every single point. It's a syntactic hack in JS to get a guaranteed boolean coersion, but for anything else it's an absolutely pointless abomination. (Maybe PHP has a similar thing, but I haven't programmed in PHP, so I wouldn't know.)
What? I've been coding in multiple languages for multiple platforms for almost 30 years and have never come across it. It seems rather unlikely that it's 'extremely common'
It is very common in C code, where for most of its history you hadn't any explicit boolean data type but used int, following the rule that zero is false and anything else is true.
The '!!expr' is the idiom most people use whenever the need for a canonical 0/1 representation arises.
That goes to show how much salt you should take with the rest of his opinions on JS. Yes, dependency hell is a problem, yes, no type safety (though you can choose TS), the rest? Not so much unless you're trying to hammer JS into the shape of your old favourite language.
I figure that a good rule is: if the feature existed in C, you should know and understand it. If that feature is convenient and doesn't sacrifice performance, then you should use it.
Then there's this blatant misuse of the arc4random API, which I'm pretty sure the manpage tells you about.
it depends on how you want to structure your code and give sections to code.
"if (isConnected) {} else {}" emphasizes to me that there are two branches of code which depends on `isConnected` state. It may have only one thing to do right now. But this is major branch. Future git diff will probably show that the code in the body the branch are added/removed.
Ternary expression emphasizes on modification of a single attribute.
It's funny how you can spot the junior devs, who are accustomed to one thing and refuse to learn another. There is a beauty about the JavaScript language that most people don't get, and how a lot of behavior can be added after the fact or mutated. Design time type safety is not the end all be all of languages
I couldn't agree more. I wouldn't accept that from even a junior developer and yet you can easily find "senior" devs writing this crap. It seems like some devs will never understand that less code is better or that ease of reading matters. This is either lack of skill or laziness, neither of which are acceptable.
I'm really glad to have read this article as it actually solidifies my comfort with using React Native since it seems like a well thought out list of reasons not to use React Native, and now I know that none of them really matter that much to me.
The three main disadvantages of React native brought up are:
- lack of commitment from Facebook about maintaining it for a long time. This one is the most bothering to me but it's not a dealbreaker.
- doesn't like Javascript and its related ecosystem. This doesn't bother me in the slightest, I love modern JS.
- the whole all your patents are belong to us thing that comes up every so often. I'm not a startup founder or a lawyer so I will leave such concerns to them. If my employer wants to let me develop in React, all the better for me.
> If my employer wants to let me develop in React, all the better for me.
Is your employer _aware_ of this particular razor blade in the candyfloss?
I know managers should check these things with legal but most of the time people sort of assume that since it's open source and everyone else is using it - it must be fine.
I know many languages, including Swift and Ruby, and I've actually started to prefer modern Javascript. I really enjoy writing ES7 JavaScript with Flow or TypeScript, and everything else in the ecosystem (babel, webpack, yarn, etc.)
I will admit that Swift is a much better language, but I prefer working with modern JavaScript these days.
The point was probably that someone with a good knowledge of one language and little or know knowledge of another favors the one they already know.
There are plenty of people who are quite happy with what they have, and they see no reason to change. Then there are people (thankfully) who are never satisfied and who keep progress rolling.
So, you'd rather use Xamarin than React Native, in short. Xamarin has excellent tooling and arguably works with saner languages (with better type systems), but it doesn't work on GNU/Linux. We're using RN right now, since it allows us to use ClojureScript, which means we can share code between our Clojure sever and our client. This means we're limited to the JS environment though, which means no good access to multi-threading and a really wonky target language. Performance implications aside.
If Xamarin worked on GNU/Linux, we likely would've built our app using it and F#. Until it comes to the Linux world and stops doing things the MS way (open sourcing is a good start), Xamarin is going to be missing out on a number of developers.
Xamarin and Mono are not the same thing. Also, Xamarin Studio may work through WINE or something similar, but it doesn't have any native GNU/Linux builds.
I would rather use RemObjects Elements then Xamarin :) Allows me to share code between Android, iOS, macOS, web. Quite lovely, UI can never me 100% the same for each platform so there is where the main cost will be.
Common utilities for manipulating data, which is what Clojure does best. Logging. A wrapper HTTP API for communication. Lots of specs, using clojure.spec, to describe how the data moving between the client and server should look.
I think people should be paying more attention to the core concept of React Native, which is having a view layer that is completely native and a bridge that connects to a javascript engine. People bitch about electron which is essentially a browser in an app window (React Native is NOT that), the concepts of React Native solves a lot of the performance problems of Electron, which I think the electron team should seriously consider implementing.
I think people should be paying more attention to the declarative views that React gives us. There’s no reason we couldn’t implement React in Swift and get a lot of the benefits of both approaches with few of the downsides. We wouldn’t have the fast iteration time but it could still be a great option.
> I think people should be paying more attention to the core concept of React Native, which is having a view layer that is completely native and a bridge that connects to a javascript engine.
That is indeed pretty awesome, but wouldn't it be even better were it a better language than JavaScript being bridged to? I'm thinking Lisp, or Python, or TCL, or pretty much anything other than INTERCAL or JavaScript.
TL;DR: "react native sucks because javascript". So much else I wanted to know from an experienced iOS dev, like:
- How is perf in a large app with lots of network IO?
- How does animation/ transition fit with reacts render loop and how does it perform, especially during network IO?
- How much is lost from not being able to do multithreading?
- How hard is it to achieve the last 20% fine tuning of feel and perf?
- How much flux is the community driven deps typically causing?
- Is memory management an issue? GC stutters, leaks?
- Do some UI parts simply not scale well enough, requiring native code instead? e.g. infinite scrolling, charts, complex transitions?
- How mature is the tool chain? Build time?
- Frequency of breaking changes from core? from common deps? Cost of staying up to date?
Developing in JS, with all the pros/cons of the JS language, is the very premise of the react native deal. Most issues raised would apply just as well to any web app.
The example with the Person class suggests that the author is unaware of JavaScript getters:
class Person {
get isImmortal() {
return false; // noone is immortal
}
}
p = new Person();
p.isImmortal
// >>> false
p.isImmortal = true;
p.isImmortal
// >>> false
I mean, even plain untyped JavaScript can do that!
And my linter, or flow, typescript will pick that up in the same way the compiler will. Just because tooling these days catches these things in 'type safe' languages doesn't mean it's not a pointer to a chunk of memory that's defined at runtime beneath it all.
That was a bad example indeed. If isImmortal was accepting any params though, you wouldn't be able to make it a getter.
And sure, Object.freeze exists, but almost none of the JS code I've seen uses it. And what's the point really when assignments to frozen fields don't even throw an exception, just fail silently. Same for getters. None of those tricks are gonna make JS into a good language in the eyes of people who don't for whatever reason consider it good already.
This article is definitely FUD, there are a few irritating things about React Native, but I think it's still far preferable to native development for most apps.
I'll list the annoyances:
- npm is a mess, and many libraries in the ecosystem handle sub-dependencies improperly. Facebook has contributed to yarn but has not established a very clear contract for what a properly organized package should be. Thus it is not possible to easily determine which package or sub-package, or sub-sub package (etc) is misbehaving. I estimate that this issue has eaten up easily 10% of the productivity gains that React Native has offered. Facebook generally ignores the github issues about this stuff, in spite of hundreds and hundreds of users having these issues.
- Updating to a newer version of React Native is cumbersome. There is a utility called react-native-git-upgrade which often fails to reconcile changes in the ios-specific configuration files. Much of this is due to problems with XCode (not sure how anyone tolerates using that). Compared to simple makefiles XCode's system that react-native interacts with is horribly brittle.
- Important libraries are not embraced by Facebook. Things like camera support are not included in React Native's scope, so third party libraries exist, yet often lag because the developer can't make time to keep up with pull request. Facebook should hire the top 15% of community contributors to maintain those projects in-house. Right now probably 30-50% of community libraries are not compatible with the latest stable React-Native. Facebook should realize that library maintainers do not have enough time to properly maintain these libraries and should offer more support and guidance, not to help the maintainers as much as to help people trying to use open source libraries from the community.
- Some of the React Native code is pretty ugly. A few times I've had to debug issues and some of it looks like it was written very rapidly and could use a refactor for clarity and ease of debugging. Not the core algorithms stuff, just the bundle management stuff.
But in spite of all this I'd still use React Native on a new project. Most apps that aren't strongly architecture-driven could be written in a day or two. It's pretty amazing.
Our legal team at work (an e-commerce player with 9-figure revenues that's raised 8-figure rounds over the years), are currently looking at React's PATENT clause.
There is a dependency tree here around whether you currently (or plan to in the future) have any patents. If you don't and you never do, then how can Facebook infringe it in a way whereby you'd want to sue?
And then there is the cost of suing. We seem to be reckoning it would cost around $1m to start a serious action against FB, so what does the cost of replacing React look like in that sort of scale? We've costed that, in broad strokes.
So on paper, it all looks like we're fine, right?
But...
But...
Here's where they take pause:
The license granted hereunder will terminate, automatically and without notice,
if you (or any of your subsidiaries, corporate affiliates or agents) initiate
directly or indirectly [...]
Subsidiaries? We don't have any of those.
"Corporate affiliates"? What does that mean? Oh, it's anybody who owns at least one share in us, or we own one share in them.
Wait. What? We have business angels, founders, multiple VC firms and other investors. Do any of them have patents that Facebook might infringe on? What about future investors or people who we might want to be acquired by? Could we have an acquisition blocked because the potential buyer has a war chest of patents they value?
And "agent" means external law firms too, right? So if any of the companies we use for advice on an on-going basis get involved in any patent action, what does that mean for us?
Suddenly it becomes this huge sprawling mess. Risk aversion is important when you're dealing with a company that is already carrying a 9-figure valuation.
We're trying to find a way around it. As an engineer I brought it up with Legal because I want clarity for colleagues and myself: we want a green flag.
Unfortunately, in doing that, we may have brought enough scrutiny to it that they are going to tell us to stop using it.
If/when that happens we'll talk about it and share that information.
In the meantime, we continue to use it, but we're doing so with caution, and we accept there may be a re-tooling cost.
1. They have more money too, they can afford to take risks
2. They probably already have a patent agreement in place with FB not to sue each other
3. It's perfectly possible nobody in MS has had this actually cleared with their legal team. You can't assume they have.
Is it not true that a cross platform system necessarily results in an application that is the lowest common denominator in terms of devices? How does React Native work with ARKit for example? How does React Native take full advantage of the hardware if it has to be cross-platform compatible?
The Facebook iOS app is slow, bloated and occasionally glitchy. A company like Facebook seriously doesn’t have the resources to make Android or iOS native applications? Because React isn’t “native.”
> How does React Native take full advantage of the hardware if it has to be cross-platform compatible?
It's easy enough to add a native module to address specific hardware -- so easy in fact that you can usually find one already done (ARKit for example: https://www.npmjs.com/package/react-native-arkit). As with all 3rd party library use you have to do your due diligence of course.
The more of these you use, the less 'cross-platform' your code becomes. If there's enough similarity in hardware between platforms, you might write (or find) a react-native library offering a javascript/RN API that addresses native apis under the hood. This is done with animation, for example.
> A company like Facebook seriously doesn’t have the resources to make Android or iOS native applications?
I'm can't imaging they don't have the resources, and know nothing about FB or its motives. But if I was managing a large cross-platform app, I'd definitely want the largest number of developers I possibly could have communicating via a commonly understood codebase, rather than via meetings and specs.
With reagard to Facebook app I guess the problem is that they have too many resources, i.e. gazillion of people working on different parts without even checking what others are doing so you get a bunch of duplicated, triplicated, whatever, code, a bunch of dead code and stuff like that. They also use some kind of generators and run into problems like having too many classes for Xcode to handle.
From everything I've heard of it you don't want to do things the way FB does them with their app.
I believe the majority of the main Facebook app is still "real" native code.
It's certainly possible to use any native API you like when using React Native. You can easily write a modules to bridge to native APIs, but you need to be comfortable to drop into native code when required and do that work for both android and iOS. If you don't feel able to do that, you'll be limited to the libraries that others have already written. It's not hard to do though.
>There is a const operator, which helps ensure primitives don’t get mutated. But anything that’s not a primitive is as malleable as jell-o
Making so many errors in a sentence about basic language features, when a big chunk of OP's article is argumenting that React Native is bad because JavaScript is bad... Maybe it would be less bad if OP actually learned the language?
Could be a bit off-topic here and I hope that my tone is not extremely negative, but why is there a constant "Why we/i/should are/am/should insert possible negationinsert a random action and why should you" trend in the professional blogs (not saying this author does the why should you part)? Titles are getting hideous and repetitive. I sincerely hope that this tone could be changed to something more meaningful/technical/constructive rather than listing things why you are or you are not doing something (while this author definitely goes into detail).
I definitely endorse freedom of speech and thought, but unless one is a vetted expert in the matter, one should avoid making these blog posts. I'm not the best chef in the world and I do things a certain way, but I do not go around the world telling people that they should do it my way.
I found funny to say Javascript moves slowly when a lot of people is using async/await, generators, destructuring, etc… everywhere right now. And then it dismisses Flow and even Typescript right away, yeah sure…
And the conclusions seem to favor Phonegap, really? Xamarin might not be that bad but doing really nice UI on both platforms require two separate projects (or modules at least).
This was the comment that initially made me kind of shrug the article. It's like Javascript can't win. It is either moving to fast or moving to slow. Anyone who has been working with Javascript for the past couple of years (JS exclusively, not the ecosystem) would never say that the language itself is moving slowly.
As much as these features might "bloat" the language, they provide some much needed and much desired elegance.
Xamarin is given as an example of a better alternative why exactly? You develop a single layout in React Native, while in Xamarin you just share the C# code, so separate platforms need separate UI code (unless you want to rely on their weak Xamarin.Forms API), and at that point you can just write common code in C or C++ and not rely on any third party. It's hardly comparable.
I come from a bit old school, C world, so excuse the naive question. Is it possible to build both a desktop (Linux/MacOS/Windows) and mobile (tablet and phone, android and IOS) application from same codebase (with slightly different codepaths for UI specifics) with React Native or something similar? I see Xamarin is almost there, but no Linux.
I have a need for an app that is mostly word-processing oriented in nature with some interactive graphing and drawing, some displaying, creating and drawing on top of PDFs too. I'm looking for easiest path to create something crossplatform AND performant (and possibly easy on the battery).
The project I'm currently on involves writing an app that will share most state management/business logic (we're very lightly using/abusing Redux for that part) and a web API client in Javascript (well, Typescript) across phone (iOS, Android), tablet (ditto), and TV (tvOS, Fire-whatever, maybe AndroidTV if that turns out to be easy), using React Native for the UI on everything but tvOS (TVML there).
I also thew the logic/state/HTTPclient part of the app behind a crappy Electron "desktop" UI the other day for giggles. Wasn't hard, took about half a day. No design or releasable GUI in that amount of time, but you can click buttons and fill in values and stuff happens, using the same code as all those other platforms do (or will, in some cases—it's ongoing). So you can't share the GUI, but you can share pretty much everything else.
> (and possibly easy on the battery).
React Native's not too bad, compared to other cross-platform whatevers that have come before it. Electron kind of almost flirts with being easy on the battery at its very best, but hell, no-one else seems to care about that so why should you?
> creating and drawing on top of PDFs too
Oh god. Have fun with Android and PDF. Yeesh.
[EDIT] I should add that you can always add native code to React Native projects for parts that need it. Not sure about Electron, but... maybe?
You can certainly do that for iOS and Android - I've recently launched an application myself which does just that. At least 95% of the code is shared between platforms.
There are some desktop bindings available, but they're relatively experimental:
As a freelance developer at the low end of the market (ie. where most apps and developers live), I can assure you that the logic layer is usually so small that the benefits of making only it cross-platform would be minimal. Most of the code in most of my apps is UI code. RN saves me roughly 80% compared to two entirely separate native codebases. A cross-platform business logic core saves me perhaps 20%.
Sure, I agree for a greenfield social/mobile/local mobile app, RN makes a lot of sense.
> both a desktop (Linux/MacOS/Windows) and mobile (tablet and phone, android and IOS) application from same codebase... word-processing oriented in nature with some interactive graphing and drawing, some displaying, creating and drawing on top of PDFs
... definitely doesn't fit that description. At that point, your choices are JS with RN, React and Electron or C++. For custom graphics rendering and editing, JS would be a very odd choice.
C, that is more C++ kind of is my choice (QT namely). I was wondering if there is a faster approach with JS, since I don't care about what I work with in this case, as long as it doesn't take me much time to do it. Xamarin seemed like a good direction, but no linux yet. Electron, while heavy, seemed like almost a perfect choice - but no mobile.
Honestly the only big plus for React Native is that it allows to make both iOS and Android apps at the same time. This is huge. I wrote one app and I'm writing second one and I can't say that it's something particularly better than Objective C, for example. May be for very big apps React would win, but for small and moderate apps I feel that React doesn't provide a lot of advantages, but, again, having to write 2x less code is just huge. I don't know Android at all and I released Android version.
The patent stuff doesn't seem very important to me. You might not like it in principle, but I don't think it's going to affect you.
The author mentions Flow as a typing solution to solve some of the problems with Javascript development, but didn't like it because you can still write code that crashes if you ignore the warnings. They also complained about the lack of immutability, and mentioned Immutable.js, but weren't happy with that. They went on to say that most of these problems they mentioned are already solved with libraries, but ... libraries are bad? I didn't really pay attention to the huge Javascript rant in the middle, but I've heard it all before, and I totally disagree. I've started to realize that I prefer ES7 Javascript with Flow or Typescript, jest, babel, webpack, etc. I think I actually enjoy writing it more than Ruby or Swift.
I really like react-native-web [1]. I've used it to build an app that runs on all mobile devices (iOS, Android, Windows Phone), as well as on the web. There's a lot of quirks and workarounds, but it was actually a lot easier that I expected. Even if you just use plain react on the web, it's easy to write re-usable components and code.
They also mentioned hot reloading. If I wrote an article titled "Why I'm a React Native developer", the content would just be the words "Hot reloading." I spent a year developing a native iOS app with Swift, and I never want to go back to waiting for my code to compile.
Unfortunately "I don't think it's going to affect you" is not a strong legal argument and it's hard to dismiss legal risks that so many other companies are taking seriously. I do like React, but the legal uncertainty is a significant downside.
Shorter than the React code, I'm not seeing a big win other than the need for an explicit render() in didSet, which also allows for more fine-grained control if needed.
> In JavaScript, functions don’t have a return type, you don’t know what can be returned by the function
Do engineers actually depend on the compiler to save their ass and don't bother looking up in the documentation or reading the source code to see what a function returns !? No I don't think so. There's a saying that every bug that ever existed in a static typed language actually did pass the type checks. If the compiler finds a bug it's rather luck that the two parameters passed in the wrong order was not both of the same type, and not because of better language design. If you don't know what a function returns, you can say "bad documentation", or "bad code", but don't blame it on the language.
(Disclaimer: Using RN in production) The author listed some very legit points that RN is lacking and I share the same pain or complaints. You can beat up any tech with its shortcomings and that will be a good read. But arriving at a conclusion that something unjustified is better is logically flawed.
I know the == operator drives people crazy sometimes, and you are told to use === but if you actually understands what == does it's a convenience that null==undefined so you don't have to type if(foo == null || foo == undefined).
You could argue that having two (or with false it's three) types of "nothing" is confusing, but for me they mean different things. undefined means it has not been defined, null means it explicitly "nothing" and false means it's "not true". And for convenience you can write if(foo) to check for them all.
dude lost me after pointing about IDE. Wtf, this is not an advantage. This sounds like a "microsoft" arguments. You want to compare productivity? Have you seen how many ready-to-use components there are in RN community? This is the real productivy advantage, not an IDE.
But I aggree with all the problems of javascript, they were my excuses to not learn javascript, and here I am, writting RN apps. Things happens in RN world man, you gotta move to the winning side and leave your pride. Get over it.
In JavaScript it's only the primitive objects (Number, String, Boolean, null, undefined) that are "by value". Everything else is "by reference". And when you write {foo:1} you create a new object. So it's logical that array.includes({foo:1}) is false. You can however point {foo:1} to a variable, and then use that variable as a reference, eg. var foo = {foo: 1}; array.push(foo); array.includes(foo);
The web is open, standardised, has the mindshare and the runtime (browser) is everywhere. There have been initiatives to bring e.g. Qt or GTK to web, but no success AFAIK.
We are doing both, see webassembly, it's just that web tech is simpler and there are more people who enjoy it, so it is used more often if performance requirements allow.
You can laugh at JavaScript because of all the fun and stupid things you can do with it like writing entire programs with just {[( but with meta programming and operator overloading that is common in many "serious" languages there are even more "WTF" possibilities.
tl;dr: I really don't like RN and wasted a ton of time trying to talk people out of it for mostly unfounded reasons that won't affect 99% of users in any meaningful way.
If you want immutable data structures with React/React Native learn Redux with Immutable.js, it has a learning curve but will solve some of your problems
* Many of the examples seemed really contrived. Yes, JS lets you overwrite methods for specific instances (which e.g. can be useful for testing) and assign to array indexes way outside the existing bounds, but I haven't seen either of those cause problems for people.
* The author repeatedly complains about missing features that would only make sense in a language with a type system. Many popular languages used by professionals are dynamic-typed. It's a legitimate way to do programming, and sacrifices safety in favor of flexibility. And just like how most static-typed languages compile to a dynamic-typed target language (usually assembly), JS has two good static type systems (TypeScript and Flow) that compile down to JS in the same way.
* Many of the criticisms apply to many programming languages, and I expect someone comfortable with a few programming languages wouldn't find them too surprising when learning JS. Examples: reference values, implicit exceptions, IEEE floating point edge cases, blockless `if`, switch fallthrough. And many of the examples are disallowed by the default configuration of eslint, which basically everyone uses.
* The criticism of ES2016 seemed really disingenuous, and ignored the vast majority of the progress made to the language in that year. There just happened to only be two features that year that crossed the finish line to make it into the spec. ES2015 and ES2017 were both much more significant, and the JS committee meets regularly and is actively working on about 50 different proposals simultaneously.
That said, some of the criticisms of JavaScript were certainly legitimate, like the `map(parseInt)` example and the `null`/`undefined` issue (although it still is a meaningful distinction that's occasionally useful).
Thank you so much for taking the time to write this.
It seems the points you raise are about syntax, how it is to learn and work with. But could we read the author's criticism as being about a different scale? How it stacks up as a project for huge, native-type applications? (I realize the author did not signpost this clearly, if this is what they had in mind, so I could be misreading them.)
What do you think about this reading? I found your statement that (not a direct quote) "lots of languages do this and it isn't too surprising or hard to learn" a particularly good and simple answer to the author...so perhaps their motivations are a little different? What do you think?
tl;dr: I really don't like RN and wasted a ton of time trying to talk people out of it for mostly unfounded reasons that won't affect 99% of users in any meaningful way.
This article raises so much unfounded FUD it's hard to believe the author is serious.
1. Uncertain Roadmap - Does anyone seriously doubt FB's commitment to RN? When they themselves dogfood it? Or is it more likely they are just too busy making progress (since as the author points out they release every 1-2 weeks) to release a multiyear ROADMAP?
2. Patents - Is anyone here planning on suing FACEBOOK? Who amongst us has the team of lawyers to undergo that? This is for 99.999% of people not a legitimate concern. This is an RMS concern.
3. Javascript - New versions of Javascript address the vast majority of this. Type errors? Use well supported Typescript or Flow
4. Dependencies - This is a result of the Javascript communities overly enthusiastic packaging efforts. This is not an apples to apples comparison, but of all the cons mentioned, sure this is legit.
5. Alternatives - ...and Windows Phone? Seriously? I was rooting like hell for MSFT, but this is just not a thing. I'd rather cover 99.6% of users twice as fast than 99.999 of users painfully using Appcelerator
>Is anyone here planning on suing FACEBOOK? Who amongst us has the team of lawyers to undergo that? This is for 99.999% of people not a legitimate concern.
I don't think it is wise to think about this in these narrow terms. Consider the following scenario:
Avoidance of these problematic license terms becomes "a thing" in the industry that moves and shakers, but not the likes of us, are worried about.
You might have aspirations to sell your company to BigCo, or get investment from VCs.
Now we have a concern that use of problematic license code is a poison pill that these investors are not willing to swallow. You aren't considering suing Facebook, but they might think about it.
We saw exactly this with GLP'ed code in the past (I have signed a couple of deals where I had to pledge on a stack of bibles that we did not have any GPL code in our tree).
If they want to go to patent war with Facebook, they're going to have to answer to Facebook's patent portfolio counterclaims, whether they own companies which use React or not. Facebook owns thousands of patents they have bought over the years.
Your company or startup should focus on building a great product and attracting users.
What happens if you use RN and one of your "corporate affiliates" sues Facebook?
The use of RN doesn't necessarily mean you are violating Facebook's patents, whatever they may be. RN is still published with a BSD license. One of your corporate affiliates better know they're starting a patent war and their code base will be analyzed for patent infringement counterclaims by Facebook's attorneys.
Or happen to own a few shares in a BigCorp that decides to sue Facebook over any patent?
I'm talking about big companies that have O(10x) as many patents as Facebook.
A lot of BigCos like that are already using React in their code base. Microsoft, Apple, Amazon, Salesforce, to name a few.
As a small startup, I absolutely love Facebook's React patent licensing. It gives me the advantage to use React (Native) while my bigger VC-funded competitors can't. It is like the opposite of economy of scale, haha.
> Does anyone seriously doubt FB's commitment to RN? When they themselves dogfood it?
After the shutdown of Parse, I don't see how anyone could avoid having doubt about Facebook's commitment to React Native, or to anything else outside of their core business.
To me, Parse instils confidence of Facebook's ability to handle (open source) projects. The shutdown of Parse would have to be one of the best sunsettings that I've ever seen.
They announced it in Jan 2016 and gave one years warning and shut it down in Jan 2017. Parse open sourced many of its components and provided an easy migration path for applications depending on it.
React Native, IMHO, is a fundamental part of their core business. Among many things, it lets them ship updates and more efficiently A/B test features more frequently. If Facebook gets sick of RN, at least it's a completely open source library that's able to be transitioned to fully community supported.
Parse was never used internally at Facebook I don't think. React Native is used for major parts of the main app and in parts of Instagram. I don't think it's an apples to apples comparison.
Where's your proof?
The FB app uses RN for very esoteric and small portions of the flows. It has 230MB (at least) of compiled binary.
Instagram also uses it minimally, mainly to replace what used to be webviews.
Those are not "major parts".
It's used in Marketplace.
https://facebook.github.io/react-native/blog/2017/08/07/reac...
https://engineering.instagram.com/react-native-at-instagram-...
What major parts of the main Facebook app is React Native used for? Serious question.
In the Instagram app, really only the settings screens and the bookmarks feature are written in RN - 2 of the simplest features in the entire app.
Not true, see link: https://engineering.instagram.com/react-native-at-instagram-...
Push Notifications, Edit Profile, Photos Of view, Post Promote, Comment Moderation, Lead Gen Ads, SMS Captcha...and that was in February. They are ramping up their usage all the time.
I think these examples only strengthen my larger point right?
I want to see examples of React Native usage in the feed or the main profile architecture. Something critical.
They are gradually transitioning their code base to RN. Instagram has been in production for quite a few years now, it can't be an easy task to rewrite everything in RN. I think the above examples are significant, and they claim in the article that it's working well for them, so I expect them to continue to expand usage of it.
FB app uses it for esoteric views.
Most portions of the app is rendered using Component Kit.
I'm still using Parse today, and it's still great. They shut down the Parse servers, but all the code is open source. Other hosting companies have popped up, and you can host it yourself. React Native doesn't have any servers to shut down. If Facebook stops maintaining it, the community will pick it up.
React Native is increasingly a key part of Facebook's core business as it powers their own apps. Facebook never used Parse themselves.
“Powers” is a strong word for how it’s used in practice at FB from what they’ve detailed.
Regarding your second point -- that also includes the fact that you cannot sue any of the React contributors, not just Facebook. If I have a pull request on React, I can copy everything you ever built on React, down to the interface. It doesn't matter how much I copy because you cannot sue me without losing license to the very thing you used to build it, and thereby not having right to build it in the first place. Read the agreement in full, till point (iii).
> (iii) against any party relating to the Software.
No you do not lose the copyright license to use React in your code base. It is BSD. You only lose patent grants in the event you sue Facebook. In the event you sue Facebook, you're going to have to comb through your entire product code base and implementations for possible infringement against their portfolio of thousands of patents because you can bet your ass their legal team is going to come after you in retaliation. That is the nature of patent wars.
> I can copy everything you ever built on React, down to the interface
Downvoted for FUD. That license is about patents, not copyright.
Yes. Dear God. It's just silly. The worst part of the whole thing is how un-silly it looks. The author must have spent at least a week (probably more) putting this together. I don't envy his manager. One of the toughest problems a manager has to deal with is an incredibly passionate engineer who is clearly wrong. How do you talk this guy down? Tough job.
The post seems to be from 2016
https://github.com/arielelkin/arielelkin.github.io/commits/m...
Great point! This comment provided more incite that the whole of the article.
if this engineer is as rational as he believes himself to be, then using rational arguments about why the risks are less than the gains is the best way to convince him.
Are there any examples of Facebook actually using React Native in a crucial way? All I've seen are parts of their native apps that could be replaced relatively easily. I don't think the "Facebook won't kill React Native because they use it" argument holds as much weight as we'd like to believe.
Ads Manager App is built entirely using React Native[0].
[0] https://code.facebook.com/posts/1189117404435352/react-nativ...
Isn't the Facebook mobile app made with React Native?
No. I've seen this written many many times, but where is the proof? The Facebook app has 230MB of native binary in there on iOS. It uses very little RN.
I just looked it up. They don't use it for the entire app, but they do use it for specific parts [1]. Since this was written over a year ago I wouldn't be surprised if more was converted.
1: https://code.facebook.com/posts/895897210527114/dive-into-re...
As I said, they use it for some of the most esoteric screens. That's hardly "using" it. I have it on good authority that some portions of FB (such as Messenger) flat-out refuse to use it. It doesn't not instill confidence.
Esoteric might not be the right word, but I see your point. Without hearing from Facebook first hand, though, I don't want to discredit their internal use of React Native, especially since it is verifiably in products that they use, e.g. Facebook and Instagram mobile apps.
https://engineering.instagram.com/react-native-at-instagram-...
> I have it on good authority that some portions of FB (such as Messenger) flat-out refuse to use it.
That is not true; Messenger uses React Native for some features.
1. The world is full of framework-of-the-day made by Google, Facebook or Microsoft that was marketed as the next big thing of the century backed by unlimited commitment, and ended up abandoned without notice a couple of years later.
2. Not everyone is a small company with nothing to lose.
Oddly enough, Microsoft doesn't have its own client side ui framework, they build typescript and some other component stacks but leverage other UI frameworks in their products. React seems big in their office division - with outlook.com, office web and sharepoint using a lot of react - but pitch angular seemingly everywhere else.
I raised an eyebrow at Windows Phone being given 20% share on the "Portability" scale. And later again with 30% for MacOS.
But really, those charts at the end say it all for this particular developer - if he feels only 60% "Productivity" using React Native compared to 90% on competing platforms, his choice is obvious. I imagine for many developers the opposite (or even more so) is the case.
By your "developers", you mean JavaScript developers that only know JavaScript and are not willing to learn anything else? I am not familiar with many "native" developers who are more productive in RN.
I'm a native iOS developer, and I'm far more productive with React Native. I can't imagine how anyone wouldn't be, compared to building native iOS and Android apps in parallel.
You also don't get very far with React Native if you only know JavaScript. I've had to write a lot of Objective C and Java for native modules, and I picked up C# to integrate libraries for Windows Phone.
My experience exactly. There's an odd sneer often thrown about re 'knowing javascript'. From what I've seen of this region of the open-source javascript world (react, redux etc), much of it is at least as good and thoughtful code as I typically find in the native iOS and Android world.
Yes exactly -- and the blend of native and non native can be taken to other approaches, but many just look at things like nodejs and think solely JavaScript, even though there is an extensive c++ interaction layer through the napi that can be used to expose whatever you'd like
I'm a native iOS & Android developer, but treat native codebases as specialities now I've learned React Native. The latter is far more productive for me. If I were only building one codebase, then the differences would be marginal (perhaps Android/kotlin would be marginally faster to build). But for an iOS & Android app, there's no comparison: pure native in this case is overhead I could rarely afford.
> 1. Uncertain Roadmap
Qt is still widely used despite lots of insane company merges (Trolltech -> Nokia -> Microsoft -> Digia -> Qt company). Probably because it's opensource.
> 2. Patents
If Facebook has patent for dynamic rebuilding of GUI from xml-like tree, then it may sue you for using XUL, XAML or your own code that does the same.
> 3. Javascript
Complains about type safety is laughable when compared to building apps directly in Java and Objective C.
> 5. Alternatives
> Appcelerator
Oh lol
Regarding (2) my team might not have plans to sue Facebook but one of other 40.000 colleagues of mine might in the future. Maybe they want to sue FB because they use some of the company's VR patents through Oculus.
Now I have to admit I don't know if their patents clause has any validity when we don't do business in the US, though.
>2. Patents - Is anyone here planning on suing FACEBOOK? Who amongst us has the team of lawyers to undergo that? This is for 99.999% of people not a legitimate concern. This is an RMS concern.
First, "RMS concerns" dismissed as silly and fantastic by "practical people" have been mostly proven totally valid. His dystopian essay "The Right to Read" [0] only becomes more relevant every year.
I've had to check my Amazon account 3-4 times to see if the book a friend and I were discussing supported "borrowing" it out for a limited time. Each time I've checked, it hasn't. Circumventing Amazon's controls puts my Amazon account at risk, which is hooked to my life in a lot of significant ways (AWS anyone?).
RMS may lack social graces but he is not a dummy. If anything, calling something an "RMS concern" should only call extra attention to its importance, by indicating that there's likely an understated risk that will go unrecognized by others for years.
-------
Second, you never know when you'll be in the 0.001%, and that's not a position you want to find yourself in if you are. Facebook is concerned about maintaining its position as the dominant social platform. When you're on a meteoric tear, they're going to bring suit against you whether it's justified or not just to try to starve you out and get you to fold, and ideally to find some reason why an injunction should be issued forbidding your site's continued operation. This license could certainly aid in that.
Things don't have to be very common to be unacceptably risky. Most unacceptable risks are in fact quite rare; you can go years riding in a car without a seatbelt or riding a motorbike without a helmet and be no worse for the wear.
The problem is that one time, years down the road, when it does matter. When failing to do that little thing will result in permanent, massive loss and/or damage. Maybe it won't happen to you, but it's so easy not to take the risk, that it's stupid to ever do so.
If you're building a product that you hope succeeds, it's stupid to use React or other software that contains a legal poison pill like this. It may not matter most of the time, but when it does matter, it really matters. The comparative cost of using Mithril or Preact or Vue is much, much more attractive than the cost of engaging in a multi-million dollar legal controversy with one of the world's most important companies, on one of the rare occasions when it really does matter.
[0] https://www.gnu.org/philosophy/right-to-read.en.html
> This is an RMS concern.
Stallman is on record as saying he's fine with the patent clause. :)
Maybe because he's against software patents in the first place? ;)
What should I do if I think you are spreading FUD?
Where do people get time to write posts of that length?
OK, this isn't really important for the quintessence of the article. But I'm surprised again and again how many developers write code like
instead ofWhat if `weAreConnected` is `null` or `undefined`?
WalterSear's solution solves the issue since both `null` and `undefined` would become `false`:
but in your case you could set `isConnected` to `null` or `undefined`so if later in code someone makes the mistake of writing:
they could have a bad surprise.this.setState({ isConnected: !!weAreConnected })
This^, plus, you shouldn't really have "null" or "undefined" variables which you treat as bool (if you do, then that's a bug)
Ding ding ding right answer. This is the way most senior javascript devs would right it.
They'd right it if they were fixing it or write it if they were writing it ;)
It certainly doesn't hurt to "cast" the input to boolean. But your second example is the next code smell, because it should just be
(which still works as expected even when dealing with null or undefined).Agreed, but you can't anticipate what another dev could write :)
Or if you pass down that `isConnected` down to a library where for some reason they assumed `null` should default to `true`
Of course it's very unlikely, but my point is you can't know all use cases of `this.state.isConnected` in advance on a large project so as you say it doesn't hurt to sanitize the input.
That's why there's PropTypes so you can define what type a given prop should be. An error is raised if a higher level component passes in a prop of an incorrect type.
this.setState({ isConnected: (weAreConnected === true) })
seems 100% equivalent
Another flavor of this surprise: JSON.stringify doesn't "see" undefined. JSON.stringify({foo:undefined}) returns "{}" :)
Because type (prototype) and data (Json) are two different things, if you need it -- JSON.stringify(obj, (k, v) => v === undefined ? null : v);
Or
If you want to be super obvious, and aren't using a type system.or
I prefer boolean, easier to see what's going on. And,
is only two more characters :)It's not any easier if you understand what !! does. Pretty common usage across many languages.
>It's not any easier if you understand what !! does
which only applies if you're writing code for yourself. you can't expect everyone to know that idiom. same with using the + operator to cast to number, or an extreme case, the tadpole operator https://blogs.msdn.microsoft.com/oldnewthing/20150525-00/?p=...
!! is an extremely common idiom, across multiple different programming languages.
Code should be written so that it is understandable by other professional programmers, not people who started programming two weeks ago.
As a professional programmer, I've come to prefer code written to be understood by someone who started two weeks ago.
In that case, don't write any code. Don't use function. Don't use React. Don't use lodash. Don't use third party library.
People who only start coding for two weeks can't understand any code.
People who start has enough experience to work, but only start in this project for two weeks, will understand "!!" idiom.
Then by that principle you'd want to use !! since casting via function or constructor differs more between languages.
What it looks like in other languages is only minorly relevant to its obviousness and readability.
I don't see the argument that Boolean(val) "reads easier" than !! as long as you know what !! does.
Wouldn't any programmer recognize that Boolean(val) is a cast to a True/False value that's most likely an object, given the uppercase?
Perhaps, but it's a primitive, not an object.
I'm curious, which languages? I've never seen any of my colleagues write !!, ever, in C/C++, Java, Python, or Swift. I've also not seen it C# or Go, but my exposure is limited.
I've been paid to write code in Perl, PHP, Ruby, JS, Go, ObjC, and Java, plus a little C and Python, for going on 15 years. I'm pretty sure I've never written "!!" and I think I could count the times I've seen it used on one hand (maybe never in any codebase I've worked on, but I'm not entirely sure)
I feel sorry that they paid you then
C example from the Linux kernel: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history...
It's one of the earliest things I can remember learning in my intro to programming classes in college. Those were in Java.
I spend chunks of every day looking at a C/C++ codebase and have never seen this. Taught Java for a year in college, I have never seen this. I would leave a note to a student for using this to be honest - too unclear, and (as this thread denotes) not well known enough to put in production worthy code.
I'm pretty surprised to hear this from someone who taught a programming course. It actually makes a ton of sense when you evaluate what is happening: it's the negative unary value and then the negative unary result of that value - there's no possible way it could be anything other than true or false. It's more of a side affect of the unary operator ! than it is a language feature, which I believe is why it sees such ubiquitous implementation.
> I would leave a note to a student for using this to be honest - too unclear, and (as this thread denotes) not well known enough to put in production worthy code.
You've done a total disservice to your students that understood negative unary operations then. Given how many upvotes my initial post on this thread has (currently 38) I don't think the thread denotes what you think it does at all.
You're kidding, right? "!!foo" is a complete no-op in Java. It is never needed and never correct.
You're basically wrong on every single point. It's a syntactic hack in JS to get a guaranteed boolean coersion, but for anything else it's an absolutely pointless abomination. (Maybe PHP has a similar thing, but I haven't programmed in PHP, so I wouldn't know.)
In Java? What purpose would it serve there?
What? I've been coding in multiple languages for multiple platforms for almost 30 years and have never come across it. It seems rather unlikely that it's 'extremely common'
It is very common in C code, where for most of its history you hadn't any explicit boolean data type but used int, following the rule that zero is false and anything else is true.
The '!!expr' is the idiom most people use whenever the need for a canonical 0/1 representation arises.
Oh I understand, it, and used it for years. Boolean() is just easier to spot in unfamiliar code.
That goes to show how much salt you should take with the rest of his opinions on JS. Yes, dependency hell is a problem, yes, no type safety (though you can choose TS), the rest? Not so much unless you're trying to hammer JS into the shape of your old favourite language.
There's also the
bit, which should be a ternary.I figure that a good rule is: if the feature existed in C, you should know and understand it. If that feature is convenient and doesn't sacrifice performance, then you should use it.
Then there's this blatant misuse of the arc4random API, which I'm pretty sure the manpage tells you about.
it depends on how you want to structure your code and give sections to code.
"if (isConnected) {} else {}" emphasizes to me that there are two branches of code which depends on `isConnected` state. It may have only one thing to do right now. But this is major branch. Future git diff will probably show that the code in the body the branch are added/removed.
Ternary expression emphasizes on modification of a single attribute.
The replies below show why, because JS.
Bad languages don't allow a nice life.
It's funny how you can spot the junior devs, who are accustomed to one thing and refuse to learn another. There is a beauty about the JavaScript language that most people don't get, and how a lot of behavior can be added after the fact or mutated. Design time type safety is not the end all be all of languages
But inconsistency is truly a problem. Is not that JS is just "crazy" but with a method on his madness. Is that is just not well designed.
So, how we can claim to "developer good software" in front of our customers and defend tools like this?
I couldn't agree more. I wouldn't accept that from even a junior developer and yet you can easily find "senior" devs writing this crap. It seems like some devs will never understand that less code is better or that ease of reading matters. This is either lack of skill or laziness, neither of which are acceptable.
I'm really glad to have read this article as it actually solidifies my comfort with using React Native since it seems like a well thought out list of reasons not to use React Native, and now I know that none of them really matter that much to me.
The three main disadvantages of React native brought up are:
- lack of commitment from Facebook about maintaining it for a long time. This one is the most bothering to me but it's not a dealbreaker.
- doesn't like Javascript and its related ecosystem. This doesn't bother me in the slightest, I love modern JS.
- the whole all your patents are belong to us thing that comes up every so often. I'm not a startup founder or a lawyer so I will leave such concerns to them. If my employer wants to let me develop in React, all the better for me.
> If my employer wants to let me develop in React, all the better for me.
Is your employer _aware_ of this particular razor blade in the candyfloss?
I know managers should check these things with legal but most of the time people sort of assume that since it's open source and everyone else is using it - it must be fine.
I'm curious, what do you love about JavaScript?
Probably that he knows it and doesn’t know Swift.
I know many languages, including Swift and Ruby, and I've actually started to prefer modern Javascript. I really enjoy writing ES7 JavaScript with Flow or TypeScript, and everything else in the ecosystem (babel, webpack, yarn, etc.)
I will admit that Swift is a much better language, but I prefer working with modern JavaScript these days.
What kind of a reason is this? "Ignorance is a bliss."
The point was probably that someone with a good knowledge of one language and little or know knowledge of another favors the one they already know.
There are plenty of people who are quite happy with what they have, and they see no reason to change. Then there are people (thankfully) who are never satisfied and who keep progress rolling.
> Then there are people (thankfully) who are never satisfied and who keep progress rolling.
“Here's to the crazy ones. The misfits. The rebels. The troublemakers.”
You can love JavaScript all you want but you'll ship more bugs than you would while using Swift, having the same experience with both languages.
Even TypeScript won't get you close to Swift's compile and runtime security.
Didn't swift only target iOS devices? Then you have to write an entire second application?
Seems like one would have 2x as many bugs with the same experience having to write the app twice in swift and then again in Java/kotlin
If it needs to be cross-platform C# and F# are way more reliable than JS.
So, you'd rather use Xamarin than React Native, in short. Xamarin has excellent tooling and arguably works with saner languages (with better type systems), but it doesn't work on GNU/Linux. We're using RN right now, since it allows us to use ClojureScript, which means we can share code between our Clojure sever and our client. This means we're limited to the JS environment though, which means no good access to multi-threading and a really wonky target language. Performance implications aside.
If Xamarin worked on GNU/Linux, we likely would've built our app using it and F#. Until it comes to the Linux world and stops doing things the MS way (open sourcing is a good start), Xamarin is going to be missing out on a number of developers.
There is Mono on Linux, and it works quite alright. Xamarin can be made to work with Linux, it's jut not officially exposed in the UI by default.
Xamarin and Mono are not the same thing. Also, Xamarin Studio may work through WINE or something similar, but it doesn't have any native GNU/Linux builds.
I would rather use RemObjects Elements then Xamarin :) Allows me to share code between Android, iOS, macOS, web. Quite lovely, UI can never me 100% the same for each platform so there is where the main cost will be.
> which means we can share code between our Clojure sever and our client
Im curious, what kind of code do you share between your server and app-client?
Common utilities for manipulating data, which is what Clojure does best. Logging. A wrapper HTTP API for communication. Lots of specs, using clojure.spec, to describe how the data moving between the client and server should look.
I think people should be paying more attention to the core concept of React Native, which is having a view layer that is completely native and a bridge that connects to a javascript engine. People bitch about electron which is essentially a browser in an app window (React Native is NOT that), the concepts of React Native solves a lot of the performance problems of Electron, which I think the electron team should seriously consider implementing.
I think people should be paying more attention to the declarative views that React gives us. There’s no reason we couldn’t implement React in Swift and get a lot of the benefits of both approaches with few of the downsides. We wouldn’t have the fast iteration time but it could still be a great option.
Microsoft released a library for making native Windows apps with React Native: https://github.com/Microsoft/react-native-windows
> I think people should be paying more attention to the core concept of React Native, which is having a view layer that is completely native and a bridge that connects to a javascript engine.
That is indeed pretty awesome, but wouldn't it be even better were it a better language than JavaScript being bridged to? I'm thinking Lisp, or Python, or TCL, or pretty much anything other than INTERCAL or JavaScript.
Out of the languages you mention, I'd still pick JavaScript + typescript
TL;DR: "react native sucks because javascript". So much else I wanted to know from an experienced iOS dev, like:
- How is perf in a large app with lots of network IO? - How does animation/ transition fit with reacts render loop and how does it perform, especially during network IO? - How much is lost from not being able to do multithreading? - How hard is it to achieve the last 20% fine tuning of feel and perf? - How much flux is the community driven deps typically causing? - Is memory management an issue? GC stutters, leaks? - Do some UI parts simply not scale well enough, requiring native code instead? e.g. infinite scrolling, charts, complex transitions? - How mature is the tool chain? Build time? - Frequency of breaking changes from core? from common deps? Cost of staying up to date?
Developing in JS, with all the pros/cons of the JS language, is the very premise of the react native deal. Most issues raised would apply just as well to any web app.
The example with the Person class suggests that the author is unaware of JavaScript getters:
I mean, even plain untyped JavaScript can do that!You're missing the point. The fact that the language still allows you to write `p.isImmortal = true;` is the issue.
And my linter, or flow, typescript will pick that up in the same way the compiler will. Just because tooling these days catches these things in 'type safe' languages doesn't mean it's not a pointer to a chunk of memory that's defined at runtime beneath it all.
Which won't do anything. p.isImmortal will still be the setter. So it's a non issue -- and the linter can catch the mistake anyway.
That was a bad example indeed. If isImmortal was accepting any params though, you wouldn't be able to make it a getter.
And sure, Object.freeze exists, but almost none of the JS code I've seen uses it. And what's the point really when assignments to frozen fields don't even throw an exception, just fail silently. Same for getters. None of those tricks are gonna make JS into a good language in the eyes of people who don't for whatever reason consider it good already.
NaN !== NaN is not a JavaScript thing, it's a IEEE754 standard thing.
The bulk of the gripes about JavaScript are entirely fair, but I'd think that most people who use React Native would be aware of them already?
This article is definitely FUD, there are a few irritating things about React Native, but I think it's still far preferable to native development for most apps.
I'll list the annoyances:
- npm is a mess, and many libraries in the ecosystem handle sub-dependencies improperly. Facebook has contributed to yarn but has not established a very clear contract for what a properly organized package should be. Thus it is not possible to easily determine which package or sub-package, or sub-sub package (etc) is misbehaving. I estimate that this issue has eaten up easily 10% of the productivity gains that React Native has offered. Facebook generally ignores the github issues about this stuff, in spite of hundreds and hundreds of users having these issues.
- Updating to a newer version of React Native is cumbersome. There is a utility called react-native-git-upgrade which often fails to reconcile changes in the ios-specific configuration files. Much of this is due to problems with XCode (not sure how anyone tolerates using that). Compared to simple makefiles XCode's system that react-native interacts with is horribly brittle.
- Important libraries are not embraced by Facebook. Things like camera support are not included in React Native's scope, so third party libraries exist, yet often lag because the developer can't make time to keep up with pull request. Facebook should hire the top 15% of community contributors to maintain those projects in-house. Right now probably 30-50% of community libraries are not compatible with the latest stable React-Native. Facebook should realize that library maintainers do not have enough time to properly maintain these libraries and should offer more support and guidance, not to help the maintainers as much as to help people trying to use open source libraries from the community.
- Some of the React Native code is pretty ugly. A few times I've had to debug issues and some of it looks like it was written very rapidly and could use a refactor for clarity and ease of debugging. Not the core algorithms stuff, just the bundle management stuff.
But in spite of all this I'd still use React Native on a new project. Most apps that aren't strongly architecture-driven could be written in a day or two. It's pretty amazing.
Our legal team at work (an e-commerce player with 9-figure revenues that's raised 8-figure rounds over the years), are currently looking at React's PATENT clause.
There is a dependency tree here around whether you currently (or plan to in the future) have any patents. If you don't and you never do, then how can Facebook infringe it in a way whereby you'd want to sue?
And then there is the cost of suing. We seem to be reckoning it would cost around $1m to start a serious action against FB, so what does the cost of replacing React look like in that sort of scale? We've costed that, in broad strokes.
So on paper, it all looks like we're fine, right?
But...
But...
Here's where they take pause:
Subsidiaries? We don't have any of those."Corporate affiliates"? What does that mean? Oh, it's anybody who owns at least one share in us, or we own one share in them.
Wait. What? We have business angels, founders, multiple VC firms and other investors. Do any of them have patents that Facebook might infringe on? What about future investors or people who we might want to be acquired by? Could we have an acquisition blocked because the potential buyer has a war chest of patents they value?
And "agent" means external law firms too, right? So if any of the companies we use for advice on an on-going basis get involved in any patent action, what does that mean for us?
Suddenly it becomes this huge sprawling mess. Risk aversion is important when you're dealing with a company that is already carrying a 9-figure valuation.
We're trying to find a way around it. As an engineer I brought it up with Legal because I want clarity for colleagues and myself: we want a green flag.
Unfortunately, in doing that, we may have brought enough scrutiny to it that they are going to tell us to stop using it.
If/when that happens we'll talk about it and share that information.
In the meantime, we continue to use it, but we're doing so with caution, and we accept there may be a re-tooling cost.
Microsoft uses React on office/outlook.com and they're much bigger than you
1. They have more money too, they can afford to take risks 2. They probably already have a patent agreement in place with FB not to sue each other 3. It's perfectly possible nobody in MS has had this actually cleared with their legal team. You can't assume they have.
Is it not true that a cross platform system necessarily results in an application that is the lowest common denominator in terms of devices? How does React Native work with ARKit for example? How does React Native take full advantage of the hardware if it has to be cross-platform compatible?
The Facebook iOS app is slow, bloated and occasionally glitchy. A company like Facebook seriously doesn’t have the resources to make Android or iOS native applications? Because React isn’t “native.”
> How does React Native take full advantage of the hardware if it has to be cross-platform compatible?
It's easy enough to add a native module to address specific hardware -- so easy in fact that you can usually find one already done (ARKit for example: https://www.npmjs.com/package/react-native-arkit). As with all 3rd party library use you have to do your due diligence of course.
The more of these you use, the less 'cross-platform' your code becomes. If there's enough similarity in hardware between platforms, you might write (or find) a react-native library offering a javascript/RN API that addresses native apis under the hood. This is done with animation, for example.
> A company like Facebook seriously doesn’t have the resources to make Android or iOS native applications?
I'm can't imaging they don't have the resources, and know nothing about FB or its motives. But if I was managing a large cross-platform app, I'd definitely want the largest number of developers I possibly could have communicating via a commonly understood codebase, rather than via meetings and specs.
With reagard to Facebook app I guess the problem is that they have too many resources, i.e. gazillion of people working on different parts without even checking what others are doing so you get a bunch of duplicated, triplicated, whatever, code, a bunch of dead code and stuff like that. They also use some kind of generators and run into problems like having too many classes for Xcode to handle. From everything I've heard of it you don't want to do things the way FB does them with their app.
I believe the majority of the main Facebook app is still "real" native code.
It's certainly possible to use any native API you like when using React Native. You can easily write a modules to bridge to native APIs, but you need to be comfortable to drop into native code when required and do that work for both android and iOS. If you don't feel able to do that, you'll be limited to the libraries that others have already written. It's not hard to do though.
A problem is the author doesn't seem to care that much about portability, how can you even say that Swift is an alternative to RN?
Was curious about counter arguments and came upon this : https://medium.com/@reicheltp/dev-diary-4-why-i-left-xamarin...
A little old but I think I prefer RN's disadvantages over Xamarin's
http://www.elementscompiler.com/elements/silver/
That post is from 2016 and most of the bad issues have been tackled.
>There is a const operator, which helps ensure primitives don’t get mutated. But anything that’s not a primitive is as malleable as jell-o
Making so many errors in a sentence about basic language features, when a big chunk of OP's article is argumenting that React Native is bad because JavaScript is bad... Maybe it would be less bad if OP actually learned the language?
>Mutating a primitive
Makes me picture some language where you write "1 = 2" and from then on in your code all 1's are 2's.
Could be a bit off-topic here and I hope that my tone is not extremely negative, but why is there a constant "Why we/i/should are/am/should insert possible negation insert a random action and why should you" trend in the professional blogs (not saying this author does the why should you part)? Titles are getting hideous and repetitive. I sincerely hope that this tone could be changed to something more meaningful/technical/constructive rather than listing things why you are or you are not doing something (while this author definitely goes into detail).
I definitely endorse freedom of speech and thought, but unless one is a vetted expert in the matter, one should avoid making these blog posts. I'm not the best chef in the world and I do things a certain way, but I do not go around the world telling people that they should do it my way.
Technical blog titles considered harmful? :)
I found funny to say Javascript moves slowly when a lot of people is using async/await, generators, destructuring, etc… everywhere right now. And then it dismisses Flow and even Typescript right away, yeah sure…
And the conclusions seem to favor Phonegap, really? Xamarin might not be that bad but doing really nice UI on both platforms require two separate projects (or modules at least).
My bets are still on Javascript :)
This was the comment that initially made me kind of shrug the article. It's like Javascript can't win. It is either moving to fast or moving to slow. Anyone who has been working with Javascript for the past couple of years (JS exclusively, not the ecosystem) would never say that the language itself is moving slowly.
As much as these features might "bloat" the language, they provide some much needed and much desired elegance.
Right, much better to have a terrible UI on both platforms using React Native. A great bet.
If you insist, you can use Xamarin Forms and have an equally terrible UI on both platform as RN.
idk, maybe try not building a terrible UI?
Title should have been —Why I dislike JS as a Programming Language instead of swift—
Plus the patent worries - that to me was the other big takeaway.
Xamarin is given as an example of a better alternative why exactly? You develop a single layout in React Native, while in Xamarin you just share the C# code, so separate platforms need separate UI code (unless you want to rely on their weak Xamarin.Forms API), and at that point you can just write common code in C or C++ and not rely on any third party. It's hardly comparable.
You can use Xamarin forms if you insist on sharing the layout and have a terrible lowest common denominator fisher-price UI.
I come from a bit old school, C world, so excuse the naive question. Is it possible to build both a desktop (Linux/MacOS/Windows) and mobile (tablet and phone, android and IOS) application from same codebase (with slightly different codepaths for UI specifics) with React Native or something similar? I see Xamarin is almost there, but no Linux.
I have a need for an app that is mostly word-processing oriented in nature with some interactive graphing and drawing, some displaying, creating and drawing on top of PDFs too. I'm looking for easiest path to create something crossplatform AND performant (and possibly easy on the battery).
The project I'm currently on involves writing an app that will share most state management/business logic (we're very lightly using/abusing Redux for that part) and a web API client in Javascript (well, Typescript) across phone (iOS, Android), tablet (ditto), and TV (tvOS, Fire-whatever, maybe AndroidTV if that turns out to be easy), using React Native for the UI on everything but tvOS (TVML there).
I also thew the logic/state/HTTPclient part of the app behind a crappy Electron "desktop" UI the other day for giggles. Wasn't hard, took about half a day. No design or releasable GUI in that amount of time, but you can click buttons and fill in values and stuff happens, using the same code as all those other platforms do (or will, in some cases—it's ongoing). So you can't share the GUI, but you can share pretty much everything else.
> (and possibly easy on the battery).
React Native's not too bad, compared to other cross-platform whatevers that have come before it. Electron kind of almost flirts with being easy on the battery at its very best, but hell, no-one else seems to care about that so why should you?
> creating and drawing on top of PDFs too
Oh god. Have fun with Android and PDF. Yeesh.
[EDIT] I should add that you can always add native code to React Native projects for parts that need it. Not sure about Electron, but... maybe?
You can certainly do that for iOS and Android - I've recently launched an application myself which does just that. At least 95% of the code is shared between platforms.
There are some desktop bindings available, but they're relatively experimental:
https://github.com/ptmt/react-native-macos
https://github.com/Microsoft/react-native-windows
https://github.com/jamrizzi/react-gtk (no code yet, just intent to develop)
Why not just go with C++? You'd still need UI code specific to Android, iOS and Qt, but you could keep your logic layer shared between all of them.
As a freelance developer at the low end of the market (ie. where most apps and developers live), I can assure you that the logic layer is usually so small that the benefits of making only it cross-platform would be minimal. Most of the code in most of my apps is UI code. RN saves me roughly 80% compared to two entirely separate native codebases. A cross-platform business logic core saves me perhaps 20%.
Sure, I agree for a greenfield social/mobile/local mobile app, RN makes a lot of sense.
> both a desktop (Linux/MacOS/Windows) and mobile (tablet and phone, android and IOS) application from same codebase... word-processing oriented in nature with some interactive graphing and drawing, some displaying, creating and drawing on top of PDFs
... definitely doesn't fit that description. At that point, your choices are JS with RN, React and Electron or C++. For custom graphics rendering and editing, JS would be a very odd choice.
C, that is more C++ kind of is my choice (QT namely). I was wondering if there is a faster approach with JS, since I don't care about what I work with in this case, as long as it doesn't take me much time to do it. Xamarin seemed like a good direction, but no linux yet. Electron, while heavy, seemed like almost a perfect choice - but no mobile.
You're quite right. I had misread which parent your comment was referring to. For this case RN would be an odd and probably infeasible choice.
Honestly the only big plus for React Native is that it allows to make both iOS and Android apps at the same time. This is huge. I wrote one app and I'm writing second one and I can't say that it's something particularly better than Objective C, for example. May be for very big apps React would win, but for small and moderate apps I feel that React doesn't provide a lot of advantages, but, again, having to write 2x less code is just huge. I don't know Android at all and I released Android version.
The patent stuff doesn't seem very important to me. You might not like it in principle, but I don't think it's going to affect you.
The author mentions Flow as a typing solution to solve some of the problems with Javascript development, but didn't like it because you can still write code that crashes if you ignore the warnings. They also complained about the lack of immutability, and mentioned Immutable.js, but weren't happy with that. They went on to say that most of these problems they mentioned are already solved with libraries, but ... libraries are bad? I didn't really pay attention to the huge Javascript rant in the middle, but I've heard it all before, and I totally disagree. I've started to realize that I prefer ES7 Javascript with Flow or Typescript, jest, babel, webpack, etc. I think I actually enjoy writing it more than Ruby or Swift.
I really like react-native-web [1]. I've used it to build an app that runs on all mobile devices (iOS, Android, Windows Phone), as well as on the web. There's a lot of quirks and workarounds, but it was actually a lot easier that I expected. Even if you just use plain react on the web, it's easy to write re-usable components and code.
They also mentioned hot reloading. If I wrote an article titled "Why I'm a React Native developer", the content would just be the words "Hot reloading." I spent a year developing a native iOS app with Swift, and I never want to go back to waiting for my code to compile.
[1] https://github.com/necolas/react-native-web
Unfortunately "I don't think it's going to affect you" is not a strong legal argument and it's hard to dismiss legal risks that so many other companies are taking seriously. I do like React, but the legal uncertainty is a significant downside.
Clearly, that guy despises javascript with a passion. He should get a job that doesn't require him to ever come in contact with javascript.
Shorter than the React code, I'm not seeing a big win other than the need for an explicit render() in didSet, which also allows for more fine-grained control if needed.
Here's a more canonical version of the exact same logic in react:
And here's how I would actually write it in my own app:> In JavaScript, functions don’t have a return type, you don’t know what can be returned by the function
Do engineers actually depend on the compiler to save their ass and don't bother looking up in the documentation or reading the source code to see what a function returns !? No I don't think so. There's a saying that every bug that ever existed in a static typed language actually did pass the type checks. If the compiler finds a bug it's rather luck that the two parameters passed in the wrong order was not both of the same type, and not because of better language design. If you don't know what a function returns, you can say "bad documentation", or "bad code", but don't blame it on the language.
(Disclaimer: Using RN in production) The author listed some very legit points that RN is lacking and I share the same pain or complaints. You can beat up any tech with its shortcomings and that will be a good read. But arriving at a conclusion that something unjustified is better is logically flawed.
> What’s nothing?
I know the == operator drives people crazy sometimes, and you are told to use === but if you actually understands what == does it's a convenience that null==undefined so you don't have to type if(foo == null || foo == undefined). You could argue that having two (or with false it's three) types of "nothing" is confusing, but for me they mean different things. undefined means it has not been defined, null means it explicitly "nothing" and false means it's "not true". And for convenience you can write if(foo) to check for them all.
Is it true that React Native cannot be integrated with an existing Swift/Obj-C codebase?
For example, say that you want to implement login/register on top of an existing Swift codebase. This is possible, right?
(May not have understood OP correctly.)
It depends what you mean 'on top of'. If you mean adding some RN to an existing app, that is conceptually easy but practically quite messy (https://facebook.github.io/react-native/docs/integration-wit...).
If you mean adding native modules into an essentially RN app, that's practically very simple (https://facebook.github.io/react-native/docs/native-modules-...) but still requires some conceptual care (like any API design).
Nvm! It is possible:
https://facebook.github.io/react-native/docs/integration-wit...
You can use 5 line of code to push uiviewcontroller from xib or storyboard. Easier than encapsulate native code to library rn. Xamarin cannot do that
Is truly hard. And not even thing in use it for Xamarin or something else.
I love to have a react-native-like for just the UI and do my code on swift/F# for the rest.
It's definitely possible but hard to do well; dependency management is a pain.
dude lost me after pointing about IDE. Wtf, this is not an advantage. This sounds like a "microsoft" arguments. You want to compare productivity? Have you seen how many ready-to-use components there are in RN community? This is the real productivy advantage, not an IDE.
But I aggree with all the problems of javascript, they were my excuses to not learn javascript, and here I am, writting RN apps. Things happens in RN world man, you gotta move to the winning side and leave your pride. Get over it.
In JavaScript it's only the primitive objects (Number, String, Boolean, null, undefined) that are "by value". Everything else is "by reference". And when you write {foo:1} you create a new object. So it's logical that array.includes({foo:1}) is false. You can however point {foo:1} to a variable, and then use that variable as a reference, eg. var foo = {foo: 1}; array.push(foo); array.includes(foo);
Why is it that we have to bring web technologies to the native platforms rather than using native platforms on the web?
The web is open, standardised, has the mindshare and the runtime (browser) is everywhere. There have been initiatives to bring e.g. Qt or GTK to web, but no success AFAIK.
Yeah you're right. Open standards makes sense.
It's a shame that no one takes something like the old Android codebase and makes it for web in the canvas. Is that even possible?
We are doing both, see webassembly, it's just that web tech is simpler and there are more people who enjoy it, so it is used more often if performance requirements allow.
You can laugh at JavaScript because of all the fun and stupid things you can do with it like writing entire programs with just {[( but with meta programming and operator overloading that is common in many "serious" languages there are even more "WTF" possibilities.
tl;dr: I really don't like RN and wasted a ton of time trying to talk people out of it for mostly unfounded reasons that won't affect 99% of users in any meaningful way.
If you want immutable data structures with React/React Native learn Redux with Immutable.js, it has a learning curve but will solve some of your problems
When i move to RN, Swift 3 is very slow on build time. Xamarin not support instant run. So i move to rn, although it feel not complete product
Got to the section on Javascript and could no longer take the author seriously.
It does seem that that's what the article was written to be - there were lots of examples carefully "assembled".
But I'm curious why you didn't take it seriously. Could you be a bit more specific?
Some issues I had with the JS criticisms:
* Many of the examples seemed really contrived. Yes, JS lets you overwrite methods for specific instances (which e.g. can be useful for testing) and assign to array indexes way outside the existing bounds, but I haven't seen either of those cause problems for people.
* The author repeatedly complains about missing features that would only make sense in a language with a type system. Many popular languages used by professionals are dynamic-typed. It's a legitimate way to do programming, and sacrifices safety in favor of flexibility. And just like how most static-typed languages compile to a dynamic-typed target language (usually assembly), JS has two good static type systems (TypeScript and Flow) that compile down to JS in the same way.
* Many of the criticisms apply to many programming languages, and I expect someone comfortable with a few programming languages wouldn't find them too surprising when learning JS. Examples: reference values, implicit exceptions, IEEE floating point edge cases, blockless `if`, switch fallthrough. And many of the examples are disallowed by the default configuration of eslint, which basically everyone uses.
* The criticism of ES2016 seemed really disingenuous, and ignored the vast majority of the progress made to the language in that year. There just happened to only be two features that year that crossed the finish line to make it into the spec. ES2015 and ES2017 were both much more significant, and the JS committee meets regularly and is actively working on about 50 different proposals simultaneously.
That said, some of the criticisms of JavaScript were certainly legitimate, like the `map(parseInt)` example and the `null`/`undefined` issue (although it still is a meaningful distinction that's occasionally useful).
Thank you so much for taking the time to write this.
It seems the points you raise are about syntax, how it is to learn and work with. But could we read the author's criticism as being about a different scale? How it stacks up as a project for huge, native-type applications? (I realize the author did not signpost this clearly, if this is what they had in mind, so I could be misreading them.)
What do you think about this reading? I found your statement that (not a direct quote) "lots of languages do this and it isn't too surprising or hard to learn" a particularly good and simple answer to the author...so perhaps their motivations are a little different? What do you think?
Thank you again for taking the time to write.
tl;dr: I really don't like RN and wasted a ton of time trying to talk people out of it for mostly unfounded reasons that won't affect 99% of users in any meaningful way.