Live data from Hacker News

Why I'm Not a React Native Developer

arielelkin.github.io

301–310 of 318 posts

Re: Why I'm Not a React Native Developer

#301
These "JavaScript is stupid, why don't you all see that!! Why! Why! Why?!??!!" rants are really entertaining nowadays. The author has also invented a (perverse?) extension of Atwood's Law (which law predicted React Native): anything that can be blamed on JavaScript will be blamed on JavaScript. If JavaScript ran for president it would be Hillary Clinton, and every other language would occupy one thread on Trump's Toupee.

Re: Why I'm Not a React Native Developer

#302
Responses to each category...

1. uncertain roadmap

It's open-source, and given the amount of contribution and efforts to get third party targets for windows, ubuntu and mac I seriously doubt it's going anywhere any time soon.

If you look at React proper, it's not much different, and that has gone incredibly well... React has some of the best diagnostic information in terms of error/warning states of any web ui tooling I've used.

2. Patent grant

The reason for the separate patent grant is because a copyright license, particularly a permissive one like BSD (or MIT, ISC, etc) do not specify patented parts of the application. MS-PL iirc was basically an MIT-like license with a patent grant (with nuclear deterrent) attached.

Most large companies that are publishing larger open-source tools have similar clauses to their patent grants. That said, I'm against software patents as a rule, so this concerns me very little.

Hell, Apple's swift license has a similar provision...

      ... If You
      institute patent litigation against any entity (including a
      cross-claim or counterclaim in a lawsuit) alleging that the Work
      or a Contribution incorporated within the Work constitutes direct
      or contributory patent infringement, then any patent licenses
      granted to You under this License for that Work shall terminate
      as of the date such litigation is filed.
3. JavaScript

I won't argue the merits of JS over other languages... I will say that I've enjoyed working with it, it's my favorite language, warts and all, and that you can write horrible code in any language.

There's TS, flow, eslint and many other tools to help with issues there.

The cartoon illustration predates npm, es6 and a lot of other work towards making things a lot better. Also, you've already invested into React*, then you may as well invest in babel/es7+, redux and a handful of other options that do add a direction.

3. Dependencies

That's the nature of large software projects... also, with node ecosystem, it means that React doesn't have to re-create a lot of work that has already been done.

4. Alternatives

As to Xamarin and Appcelerator, what about web and desktop targets? You will have to re-create a large amount of your codebase, and even non-ui bits in order to support them.

SUMMARY:

In general, I understand your arguments... but you're missing one... You can use a single unifying platform and language for all of your front end and back-end code while being able to target pretty much every platform in wide use with minimal changes.

The JS/npm ecosystem is one of the most vibrant in developer history, while a mixed blessing sometimes, it does work incredibly well.

Re: Why I'm Not a React Native Developer

#303
post #61
post #21

This is simply a list of things the author doesn't like about JS, very much of which is practically solved by Flow/TS and ESLint. He also makes some of the React examples quite a bit more complicated than they need to be. Declarative UI is very simple! Here's the same code, using both class and functional styles (whichever you prefer), in a much more succinct style (11 LOC vs 49): class Root extends Component { rende…

> This is simply a list of things the author doesn't like about JS, very much of which is practically solved by Flow/TS and ESLint. That's definitely not a fair characterization of this article. Concerns about roadmap and patent usage show up before any concerns about JS. Edit: Though I agree, a strangely large amount of the article is dedicated to "Why I just don't like Javascript."

WRT the Patent concern, you'd be hard pressed to find ANY open-source tool from a large company that doesn't have similar provisions, including Swift's Apache license itself...

As to the roadmap, it's open-source with a vibrant community, if FB steps down, people in the community can fork, step up and continue maintaining... That's the whole reason behind open-source is that you can continue it.

Also, re: your edit.. yeah, far too much... yes JS has oddities, but the null reference issue is present in most OO languages, not to mention a lot of the other issues are well known and/or present in a lot of other languages as well.

Most JS specific oddities can be warned against with linters, and you can use TS/flow if you really want type checking at build.

Re: Why I'm Not a React Native Developer

#304

Earlier quoted context omitted.

Did you read the article? Compiling to JS is an issue that is addressed.

Only barely; he includes it as the middle of a chain of hacks that highlight, not remedy, the deficiencies of Javascript.

I will not eat green eggs and ham!

Re: Why I'm Not a React Native Developer

#305

Earlier quoted context omitted.

The author seems to express a deep enough understanding of Javascript to not warrant this dismissive critique. It's not like he's saying "Javascript sucks," he's outlining specific places where it can cause issues in development compared to the alternative.

Author seems to express a deep understanding of JS quirks and outlines specific places (often rare corner cases) that'd trip a JS beginner.

True, but he also dismisses build chain or cross-compile solutions in favor of a solution that requires a build chain and compile.

Re: Why I'm Not a React Native Developer

#306
post #29

Earlier quoted context omitted.

Even with state, his code is overly verbose and can be expressed in a much more idiomatic way. var weAreConnected = Math.floor(Math.random() * 10) > 5; if (weAreConnected === true) { this.setState({ isConnected: true }) } else { this.setState({ isConnected: false }) } } turns into var weAreConnected = Math.floor(Math.random() * 10) > 5; this.setState({ isConnected: weAreConnected }); It's almost like he wrote it in t…

It didn't need to happen in componentDidMount with multiple calls to setState. If it's not getting info that it would only know after mounting, it could have happened in the same line that isConnected is initially defined within the constructor!

For that matter, FB encourages the use of unidirectional workflows and simpler components... which means it could have been a pure function receiving props.

Re: Why I'm Not a React Native Developer

#307
post #21

This is simply a list of things the author doesn't like about JS, very much of which is practically solved by Flow/TS and ESLint. He also makes some of the React examples quite a bit more complicated than they need to be. Declarative UI is very simple! Here's the same code, using both class and functional styles (whichever you prefer), in a much more succinct style (11 LOC vs 49): class Root extends Component { rende…

> This is simply a list of things the author doesn't like about JS, very much of which is practically solved by Flow/TS and ESLint. One of shortcomings of language listed by author is precisely this: shortcomings in language are not fixed by fixing the language but by adding new community-supported library.

Is that really worse than a language you can't change?

Re: Why I'm Not a React Native Developer

#308
post #21

This is simply a list of things the author doesn't like about JS, very much of which is practically solved by Flow/TS and ESLint. He also makes some of the React examples quite a bit more complicated than they need to be. Declarative UI is very simple! Here's the same code, using both class and functional styles (whichever you prefer), in a much more succinct style (11 LOC vs 49): class Root extends Component { rende…

I for one enjoyed spending 70% of the time reading about how JS sucks. It's good to be reminded now and then. If I'm chopping wood for years with a dull axe, I get really strong, and good at swinging a dull axe, and at performing superhuman feats of adaptation - adjusting myself and my attitude to using a shitty tool. Maybe even, like Stockholm Syndrome, I come to enjoy it. Do I resent the guy who comes by once a yea…

Fair enough... I find it ironic I left the world of .Net and C# behind for node, and am MUCH more productive in node. And he's recommending the reverse.

That said, some of the more recent changes from MS have me interested in .Net again... I've even played around with some of the core/mono onbuild docker containers, which wasn't a bad experience at all.

Re: Why I'm Not a React Native Developer

#309
post #175

Earlier quoted context omitted.

the whole premise (that i m sold on react-native) is that it lets you use code from your react app and run it natively. And the concept of cross-platform is not only for "similar" platforms like mobile, but across disparate platforms, like mobile AND PC. Otherwise, what's the point of cross-platform?

As I said, that's not what people mean when they talk about "cross platform" in this context. Go to phonegap and see if they support PC. Cross platform means you should write once and it works everywhere without modifying anything, just like the web. But you can't be cross platform AND native on completely different types of platforms, since each has its own distinct feature sets. You are free to believe whatever you…

And that means that ReactNative is better than phonegap! ;-)

I'm not completely sold on ReactNative compared to Phonegap and Electron as targets with React web... however, I can indeed see the appeal.

Re: Why I'm Not a React Native Developer

#310

I believe in the end it all boils down to the fact that JavaScript is a language that wasn't made for the needs of modern day (web) applications, but since it is still a standard, we need to force it into a form where we can have best control over its shortcomings. That's why things like Typescript, Flow and React exist in the first place. I know this article is about mobile app development, but I think JavaScript wo…

It's worth noting, that given the early days of the web... It's just as likely we could have perl in the browsers, and I'm certain people would bemoan that as much or more.
Post reply on HN