Why I'm Not a React Native Developer - <AUTHOR> https://arielelkin.github.io/articles/why-im-not-a-react-native-developer <comment><USER2> 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 {
          render() {
            var isConnected = Math.floor(Math.random() * 10) > 5;
            return <ConnectivityIndicatorView isConnected={isConnected} />;
          }
        }

        function ConnectivityIndicatorView(props: {isConnected: boolean}) {
          const color = props.isConnected ? 'green' : 'red';
          return <View style={{backgroundColor: color, width: 20, height: 20}} />;
        }

The point is, much like many things in software, it's all about perceptions and familiarity. He's not familiar with JS, and I don't fault him for that - it's a quirky language. But for the many, many developers who have built up a tolerance to JS and built/use tools to tame it, moving to React Native is a breath of fresh air vs learning Android & iOS toolchains and idiosyncrasies.

<comment><USER3> > 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."

<comment><USER4> That is a __very __fair characterization of the article - 70% of the article 's content is about why JavaScript is bad.

<comment><USER5> 70% of the content is not necessarily "the most important part of the content".

2 minutes in a 5 minute animation short are the credits.

<comment><USER6> You know theres no 5 minute animation shorts with 2 minute credits in existence.

<comment><USER5> If you ever go to a short film festival, animation or not, you'd be surprised.

Here's a 2:18 animation with 1:06 credits -- way more than the ratio I gave: [https://www.youtube.com/watch?v=8ZRLlyxvr6E](https://www.youtube.com/watch?v=8ZRLlyxvr6E)

Credits --crew members, voice talent, sponsors, thanks, etc-- can rise almost linearly with the length of an animation, and even more so with increases in its production value.

A 5 minute short can have almost the same team size as a feature animation (which requires > 2 minute credits). The fact that they'll be employed for shorter time doesn't mean they don't get their names on the credits.

</comment></comment></comment></comment></comment></comment><comment><USER7> A lot of people here seem to criticize the OP's POV on javascript, but my biggest takeaway was the more abstract parts of his post, such as patents and uncertain roadmap. These are very REAL problems.

I am a javascript programmer AND an iOS programmer. I work with React to build web apps at work. And lately I have played around with react native, but I felt uneasy jumping ship to use solely react native for the very same reason.

I instead decided to learn Android programming. There's really nothing to lose going that route (after all, you're learning Java, which is arguably the #1 popular language in the world, so even if you end up giving up on Android, you still know Java), compared to spending the same time learning React Native which has very uncertain future (I would trust it much more if it was not from a corporate entity like Facebook)

<comment><USER8> > my biggest takeaway was the more abstract parts of his post, such as patents > and uncertain roadmap. These are very REAL problems.

I would say the patent issue is more FUD than a real issue; he praises Swift but Swift has a very similar patent grant and termination clause. The key difference is that the Swift grant terminates if you end up in a patent dispute with Apple over something related to Swift; the React grant terminates if you end up in any patent dispute with Facebook.

So the whole issue boils down to "what if you get into a patent dispute with Facebook over a patent that doesn't relate to their core web UI tech". Which...I dunno, is that a real concern?

> "nice quantum physics technology you have here, would be a shame if > something bad were to happen to your app"

Yeah, okay. But if my core business is making apps, then every patent I might have is likely to be covered by both patent grant termination clauses. So the issue is...?

(Also, the author is conflating the license to use React with the license to use any patents, if any, which cover React. If, as is entirely possible, no Facebook patent covers any React technology, then having the patent grant terminate would not concern you.)

<comment><USER7> My point was not about the details, but about the uncertain nature of an open source project driven by a company. The patent issue is just one of the "symptoms" of this problem. When someone open sources their technology and adds a set of detailed clauses that adds some restriction (doesn't matter if it's a "real" restriction or not), it means they couldn't go all out. It also means as a user, you do have reasons to be cautious about it, not because of what the license says in detail, but because of the reason behind the behavior.

But anyway, this patent issue is just one part of the larger issue, which is uncertainty. When Apple or Android changes the API policy in the future, you'll be struggling to adapt to the new reality with what you have. Sometimes it works, but sometimes it doesn't. Currently it does make sense for some people to build using react native, but if I were you, I would rather learn Android. Really, if you already have iOS experience, a lot of the paradigm is pretty similar and it won't be super difficult to learn.

This "cross platform" concept used to be valuable maybe in 2010 when it wasn't clear what mobile platforms would be dominant (with windows phones, blackberries, and even samsung launching their own developer platforms). But it's 2016 now, and we're pretty sure it's either iOS or Android. All you need is just those two platforms.

<comment><USER9> > pretty sure it's either iOS or Android.

it's web, android, iOS, and PC. That's 4 platforms, if you consider web and PC separate, and more if you consider windows and linux as separate.

Crossplatform is more valuable than ever. But react-native may not be the answer.

<comment><USER7> The context of this entire thread was about mobile ecosystem. The concept of "cross platform" only holds when you're comparing two similar ones

<comment><USER9> 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?

<comment><USER7> 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 want but that doesn't really mean anything since you're basically arguing about something that I'm not even talking about.

<comment><USER10> 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.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> Please what kind of programmer would ever do this?

        if (weAreConnected === true) {
          this.setState({
            isConnected: true
          })
        }
        else {
          this.setState({
            isConnected: false
          })
        }

That is just verbose unnecessarily:

        this.setState({ isConnected: weAreConnected });

And probably not so popular, but this:

        var color;
        if (this.state.isConnected) {
          color = 'green'
        }
        else {
          color = 'red'
        }

Would be simplified often to:

        var color = this.state.isConnected ? 'green' : 'red';

<comment><USER12> _" Please what kind of programmer would ever do this?"_

I've seen some coding rules/guides that explicitly forbid short form of 'if' statement usage.

<comment><USER11> That statement is about the first code block; the second one as I commented is totally optional and I agree that it might not follow some code rules (;

</comment></comment></comment><comment><USER13> Reasons why I am a React-Native developer:

\- It works, really well.

\- Iteration speed alone has helped us retain at an extremely high DAU/MAU ratio compared to years past.

\- Both my apps have near 5 star rating across the board, probably the highest rated in the Sports category since we released, and none of our users notice that it is a RN app, which is really surprising b/c RN on Android is not up to par with iOS.

React-Native is not for every scenario, but I disagree with the author's final conclusion, that "the pros do not outweigh the cons". It's really quite the opposite in our case. The pros (OTA and productivity) heavily outweigh the cons.

Would love to see something better come out, but the recommended alternatives by the author wouldn't make the cut for us.

<comment><USER14> >React-Native is not for every scenario

What scenario isn't it for?

<comment><USER15> Anything where you need to stay alive in the background and periodically do something.

<comment><USER16> Utterly false. Staying alive has nothing to do with React Native or Cordova or any particular framework. It's about implementing the native APIs that allow that behaviour.

I'm the author of a couple of modules that allow your RN app to operate in the background:

[https://github.com/transistorsoft/react-native-background- fe...](https://github.com/transistorsoft/react-native-background-fetch)

[https://github.com/transistorsoft/react-native-background- ge...](https://github.com/transistorsoft/react-native-background-geolocation)

Both of these modules were ported from Cordova and have since been ported to NativeScript.

<comment><USER15> Thank you for linking those modules. I'm in the early stages of an app that will benefit from that functionality and admittedly my knowledge is based off of the first google result of a search for "react native background worker/task" ([http://stackoverflow.com/questions/35376690/how-can-i-run- ba...](http://stackoverflow.com/questions/35376690/how-can-i-run-background- tasks-in-react-native)). Which of course makes me an expert on the subject in this day and age.

</comment></comment></comment></comment></comment><comment><USER17> 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 would not have the sort of widespread use today if it wasn't for the fact that we use it for website scripting.

So I guess that developers familiarity with the language is what makes it so popular (as in often-used) and is also why we suddenly start using it for arbitrary scripting and mobile app development. The obligatory use of JavaScript in web development led to a whole range of developers growing accustomed to it and now, in spite of its limitations, trying to transfer their ideas to other fields of development.

React Native is just a neat way for JavaScript (React) developers to be able to script UIs for mobile OS's without changing their toolset. And I think for that it's perfectly fine. Obviously if you've never been big into JavaScript I can totally see how cannot make much sense of it all and yeah a lot of the things pointed out are perfectly legitimate. Yet I still think the question whether it makes the language unusable for one scenario or the other is very very opinionated.

<comment><USER18> Besides, while JS's problems are very real, they're quite exaggerated. It's still a perfectly usable language, even without TS and whatnot.

And unlike _some_ languages used for app programming, an error doesn't have the potential to hand you a segfault.

<comment><USER19> > ...an error doesn't have the potential to hand you a segfault.

And that is a good thing why? So you don't realise there was an error and your app runs on in a corrupted state?

<comment><USER20> For starters, a huge set of security vulnerabilities are not possible. Ex: buffer overflow, double free, reading uninitialized memory.

<comment><USER18> Precisely. Don't write Application code in a systems language.

</comment></comment></comment></comment></comment><comment><USER21> The author's rant on JS and npm deps has a point but his rant on typescript, flow, and other transpilers completely misses the mark. If JavaScript is an unsafe language and therefore anything that compiles on top of it is unsafe the same is true of Swift as it compiles to assembly/machine language which is unsafe. If you consider JavaScript some cross platform assembly language then there is no difference between the two ideas.

He also rants about using the best language that catches the most errors but then picks Swift as his solution. I have a feeling there's lots of other devs that would not rank Swift at the top of languages that catch the most errors and therefore the author is being hypocritical in ranting that you should always use the best since they're arguably not using the best.

The article did make some other interesting points

<comment><USER22> > If you consider JavaScript some cross platform assembly language

I am so sad right now

<comment><USER23> Why? Some of the transpilers like Typescript are quite light touch.

</comment></comment></comment><comment><USER24> Aside from the discussion of JS and React Native, I want to highlight this:

> Perhaps more importantly, your software development platforms also shape you > as a software engineer. A software development platform encourages (or > forces) the use of one language over another, prioritises certain > architectures over others, requires using specific tools and workflows, and > marries you to an entire ecosystem and its developer community.

People talk about the "right tool for the job" and "good developers are polyglots." This is true to an extent, but there are still communities with different priorities, and they often form around languages and tools.

<comment><USER25> Hmm, communities become less important as languages become more widely used. When was the last time you referred to the Java community, singular?

Likewise, there's not a single JavaScript community, but there's a bunch of communities around specific tools and frameworks. As you'd expect.

But I, when interviewing, expect good developers to be capable of learning new paradigms - the fact that they know nothing but node.js and node.js's ways is irrelevant, if they are capable of learning.

The author has very low expectations compared to me. And I don't feel I've been proven wrong yet by any of the hires I said yes to.

</comment></comment><comment><USER26> tldr; Author doesn't like writing in javascript and fears that Facebook may some day decide to stop supporting React Native.

<comment><USER27> Ariel also doesn't like this clause in the React license:

 _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, or take a direct financial interest in, any Patent Assertion: (i) against Facebook or any of its subsidiaries or corporate affiliates, (ii) against any party if such Patent Assertion arises in whole or in part from any software, technology, product or service of Facebook or any of its subsidiaries or corporate affiliates, or (iii) against any party relating to the Software._

<comment><USER28> To my reading, there are two separate items: a copyright license and a patent grant. \- The former allows you to make copies of the software \- The latter protects you from Facebook claiming patent infringement arising from the use of React Native (aka, Necessary Claims). It doesn't necessarily mean they have such patents but if they do, you are protected.

So if the reciprocity clause in Facebook's patent grant is a problem, all recent MIT licensed software out there without a patent grant would also be off limits.

<comment><USER8> Yep. And depending on the details of the concern, so would an Apache or Mozilla licensed project, since they have explicit grants with termination clauses only slightly narrower than React's.

</comment></comment></comment></comment><comment><USER29> I'm the author of [http://programmingreactnative.com](http://programmingreactnative.com), maintain the [https://github.com/jondot/awesome-react- native](https://github.com/jondot/awesome-react-native) list and built some other tools and libraries for React Native, along with a few apps.

Obviously the conclusion that follows is that I think React Native is going to be a revolution for mobile development. Not only will it succeed, it will get copied, and you'll have many variants of the same like-minded platform (open source, developer-oriented, low-barrier language).

Regarding the article, my point of view is that some points in this article are valid, but are trivially obvious:

\- Javascript is Javascript, take it or leave it. Flow and Typescript is an evolution that to me looks good. It is one language that was adopted to be user-facing in React Native. According to Apple's Developer terms 3.3.2 and 3.3.3 only interpreted languages that run on JavascriptCore are allowed to be pushed to market.

\- You can't know what the future holds. I was part of the Ruby community at the start, then Node, then Go. I was hard core into .NET, and before that Java. I saw platforms and technologies rise and fall, and was surprised over and over. I was much into Silverlight, a technology that Microsoft wanted to take over native development on the Web. Guess what happened to Silverlight? THAT was very nasty. We all know how that feels, but that's nothing to attribute just to React Native.

\- Regarding patents: I believe we will have alternatives to React Native long-term, with the same properties but we'll still choose React Native :). However I also believe Facebook doesn't use patents in a bad way that the author hints at, as far as we know and as far as we've seen. I also met with core React Native developers, and they're awesome.

Practical advise: I'd suggest for the author to meet with the React Native core team.

<comment><USER30> So we will have many variants? Does sound like a classic JavaScript thing to have many frameworks that do the same thing. Reminds me of this: [https://xkcd.com/927/](https://xkcd.com/927/)

</comment></comment><comment><USER31> Ughhh. It's fine if you prefer statically-typed languages to dynamically-typed ones, but that's a preference, not a reason to try and say that JS is objectively terrible.

Same with switch fallthrough, same with error handling, same with half his issues with JS.

There are some legitimate grievances tucked in there, but the author lost me by pretending that his preferences were universal.

<comment><USER32> TypeScript is a JavaScript best practice at this point. It's a type safety net on top of dynamic types, so you get the best of both worlds.

TypeScript has a flag that prohibits switch fallthrough, for instance, though that's an easy one to set up a linter to catch.

One reason I prefer NativeScript to React Native; they are embracing TypeScript and Angular vs. React. I find Angular 2 to be more flexible, but that I freely admit is a preference.

<comment><USER18> TS over JS isn't best practice yet: Some of us _like_ dynamic typing.

<comment><USER33> For what purpose is dynamic typing ever useful except "it's faster to develop"?

With a proper type system (see: Haskell, Scala) and parametrized types, you can do everything that's reasonable in a dynamically typed language, too.

<comment><USER34> You can do them, as you noted, at a much slower pace. Type systems catch one class of bugs, and if in your experience these are not the bugs you worry about or the bugs that cause you the most pain then slowing down development is a high cost to pay.

<comment><USER35> Honestly I think the bug catching aspect of static typing is its least useful property. (Useful, but not like, amazing -- you can write assertions on a type in a dynamic language). I think the good thing about static typing is it makes a code-base much easier to navigate and much more self documenting. I spend most my time navigating other peoples code. I know you can get most of the reliability of static typing with extensive test suites etc., but that doesn't help my IDE and it doesn't let me look up parameters at a glance. I used to be firmly in the dynamic camp, but having to maintain other people's javascript definitely made me do a 180.

<comment><USER36> Writing assertions has a runtime cost that isn't present when using something like TypeScript.

Granted, that benefit is probably minor, but it is a benefit in TypeScript's favor.

<comment><USER37> It does have a compile time cost and that's not negligible... although with all the heavy transpilation going on these days, a bit of type checking might drown that out.

At a previous job we tried TypeScript but it took around 20 seconds to build our front end. Since then I hear speed has improved.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER38> You could have just said "I don't like Javascript" and ended the post there.

<comment><USER39> I feel like this is some sort of signaling, a la 'no true programmer uses javascript, because types!'.

<comment><USER40> We all use it, but 'no true programmer _likes_ javascript.' :)

<comment><USER41> I know plenty of intelligent and accomplished programmers who use and like JavaScript. I like poking fun at it every now and then, but come on.

</comment></comment></comment></comment><comment><USER42> This article can probably be renamed to "why Javascript is bad"..only patents and dependencies issues were related to react native..the rest of the article was about how Javascript sucks..and I think developers are already equipped to take the call if they want to use js on a large project or not..

</comment><comment><USER43> As someone who loves React, the hardest thing about it for me is debugging. I'll get some error about how renderComponent doesn't accept null values or whatever, and when even the outermost error is so cryptic, the stack trace is even less helpful. Is there a conventional solution to this I'm not aware of?

<comment><USER44> As someone who uses a different component-based js framework, can you not just put a breakpoint in the chrome dev tools on the renderComponent method for that component?

<comment><USER45> renderComponent is not part of any of your components. I think the React equivalent of what you mean is the render method of a component.

The problem I think the OP is talking about is when there is an error thrown somewhere in the react library code (e.g. in renderComponent) and the stack trace doesn't even touch any of your code. That makes it really hard to find the fault behind the error.

This is a lot more common with libraries like RxJS, but I've seen it with React as well.

The only way I know of to deal with these situations is to put console.log calls everywhere in my code until I've narrowed down the source of the bug.

<comment><USER44> gotcha, thanks!

</comment></comment></comment></comment><comment><USER46> React Native Core Contributors responding and agreeing with some of the points.

[https://www.facebook.com/groups/reactnativeoss/permalink/159...](https://www.facebook.com/groups/reactnativeoss/permalink/1593579080938720/)

</comment><comment><USER47> React "componentization" is nice. For me there are two things that makes it a non-starter: 1. That legal clause mentioned in the article and 2. The complexity of learning this platform is the same as learning the native without the same benefits on the control over the hardware (actually with added complexity potential lack of control)

</comment><comment><USER48> This is a good post up until the rehash of JavaScript's sins.

<comment><USER49> It picks up later on. I too had issues with some of the JS stuff, but it's worth continuing reading. Also worth to take a look at the references.

</comment></comment><comment><USER50> For all the hate of JS, I'm developing a RN app in ClojureScript, so I rarely touch JS and instead use what I percieve to be a nicer language: [https://youtu.be/6IYm34nDL64](https://youtu.be/6IYm34nDL64)

</comment><comment><USER51> The most part of cons is criticising JavaScript and NOT React Native. I know how JS works, and I LOVE IT. The only part of the post that I liked is when he talks about the license, all the rest is just bullshit from a person who don't like JS.

<comment><USER52> It's not bullshit if it's a valid consideration when you are trying to build an app on say iOS and weighting it against say Swift. How many times does this need to be said? It depends on what you are trying to do and what you want.

<comment><USER51> Ok, this is a good point. But, the author just point out the quirks of JS language, and not things about the RN itself. Would be more fair if he pointed out the quirks in python or had focused on the RN. All he says about JS is very well known and is there since 90s. Also, he is saying that its not safe because he can't understand and workaround with the pitfalls, JS has a lot of problems, but also has a LOT of great solutions for them, and by that this not means that the language is not safe, just means that its harder to work with.

</comment></comment></comment><comment><USER53> This article is beautiful.

I am not a React Native developer, but I am a React Web developer (not by choice). The author summed up my feelings about React and JS in general so eloquently. The Swamp Castle and Freedom from Digging bits were so on point.

I am betting that my comment will get buried in the bottom of the comment avalanche, but if the author is reading, thank you for making my day!

</comment><comment><USER54> I evaluated React Native for a project and decided to go with NativeScript instead for a number of reasons:

1\. RN releases a new version every 2 weeks breaking my app every time. NS is a lot more conservative between releases.

2\. I don't like mixing presentation and logic, RN encourages doing so, NS does not.

3\. TypeScript is a first-class citizen in the NS environment, it is not in RN.

4\. Angular 2 > React

5\. NS created a smaller executable with better performance than RN for my test app.

6\. I couldn't get RN to work with one of my older devices (KitKat), and even though dozens of developers had already reported the issue, they don't care. NS worked in the same device just fine.

7\. All the tooling around the RN ecosystem is very confusing.

<comment><USER55> Another vote for 7): I tried a little project in React Native and was intimidated by all the tooling and build steps needed to get my project running on iOS. To be good with React Native you will have to be proficient with all the tooling and all that seems to be a shaky foundation. There are lots of parts that can be updated and can break your project (I say in a vague way).

</comment></comment><comment><USER56> Unless I'm wrong, the only listed alternatives are both paid and closed source. Xamarin (requires VS Pro) or Appcelerate (requires $480-$1200/year/developer).

<comment><USER40> I believe Xamarin is now free post the MS acquisition with various parts and pieces even becoming open source:

[https://blog.xamarin.com/xamarin-for-all/](https://blog.xamarin.com/xamarin- for-all/)

<comment><USER56> I was actually looking here: [https://store.xamarin.com/](https://store.xamarin.com/)

Apparently the free version has usage restrictions? I do consider free w/ Visual Studio Pro license not _really_ free.

EDIT: The licensing pages are confusing but you're right, my mistake.

<comment><USER57> No, it's completely free with VS Community (which is also free). And you don't have to pay if your company has 5 or less people working on it. You also have to pay if you have 250+ computers/people employed or your revenue is 1m+/year.

Sounds pretty reasonable to me.

</comment></comment></comment></comment><comment><USER58> I use React Native and he's mostly right. Coming from the perspective of a native platform, this ecosystem is bat shit insane. It's harder, full of pitfalls, rife with complications, and rickety as all hell.

However, there are also some pretty excellent benefits that come with all the Bad of React Native and JS so for the moment, it can be very much worth the trade offs. I've been working with it for over a year, and for now I'll be sticking with it.

</comment><comment><USER59> Could FB plug the cord on React once it does no longer align with its core strategy? Sure, it did it with parse.com without the least concern for the community of users/clients. The apology was to leave behind a half-cooked open source version of parse server.

The exact same thing could happen to the React community. I'd say stick to true open source projects and descentralized communities.

<comment><USER37> What's not true about the open source of React?

<comment><USER60> Developed by a company, if they stop it's still open source but who will maintain it? Linux is "truer" open source since it's all volunteers from day 1.

</comment></comment></comment><comment><USER61> var a = 0; var b = -0;

console.log(a === b) // true

console.log(1/a === 1/b) // false

That's perfect math you mean, of course -Infinity != Infinity, what did you expect?

I think you should rather think harder, learn math possibly, and your 'safety' problems with arrays are not problems at all, it's the opposite for other people

<comment><USER62> > I think you should rather think harder, learn math possibly

Oh the irony, when stating that 1/0 = infinity. If you'd learn maths yourself, you'd know that 1/0 is undefined.

<comment><USER61> yea 1/x is not strictly defined for x=0, but you can extend it in ℜ ∪ {+∞,-∞}, I don't know your math background, but 1/-0 could make you think of limits:

1/0 is like 1/0⁺ (limit of 1/x in ]0,+∞[ when x->0) == Infinity.

1/-0 is like 1/0⁻ (limit of 1/x in ]-∞,0[ when x->0) == -Infinity.

1/Infinity is 0 ....

0/0 is however an indefinite form, so it's NaN

so the behavior of JS makes sense

And even if 1/0 and 1/-0 returned NaN, they wouldn't be equal to each other too

</comment></comment></comment><comment><USER63> > JavaScript allows for objects to be left in an inconsistent state right > after being created, as their properties don't need to be initialised.

No, you just forgot to put `this` in front of `width` and `height`. (Arguments do default to `undefined`, though.)

</comment><comment><USER64> I'm a skeptical native mobile developer.

What are some examples of good apps currently in the store, written in React Native?

<comment><USER57> There are none, really. Maybe Discord? Other than that there are no widely known apps that uses React Native.

<comment><USER65> Who said "widely known"? There are tons of "good" apps.

</comment></comment></comment><comment><USER66> This is a nit pick, but isn't his "Ambiguous curly braces" example actually breaking due to automatic semicolon insertion?

return {{a: 4}}

Isn't valid anyways. ESLint easily flags it as an error.

<comment><USER32> Exactly: Linting rules requiring semicolons should be considered a best practice.

But I think TypeScript should also be considered a best practice, and between the two that would solve pretty much all of his complaints.

Well, that and using "==" to compare to null, vs. "===" to compare to everything else. But the linters all can make that distinction as well.

But he explicitly hates on linters in the article as well. And dismisses TypeScript and Flow ... because his coworkers aren't being forced to use it? _THAT_ is the real problem, I think...

<comment><USER66> For anyone else reading this in the future, I should mention that the ESLint 'no-unreachable' rule will catch this even if you don't require semicolons.

<comment><USER32> Good point!

Didn't say this explicitly, but TypeScript will, by default, prohibit unreachable code as well. [1]

[1] "allowUnreachableCode" defaults to false: [https://www.typescriptlang.org/docs/handbook/compiler- option...](https://www.typescriptlang.org/docs/handbook/compiler-options.html)

</comment></comment></comment></comment><comment><USER67> Like JavaScript? Use JavaScript. Don't like JavaScript? Use ClojureScript. Problem solved :)

</comment><comment><USER68> 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.

</comment><comment><USER69> I love this quote from the article:

"The fact that millions of drivers productively drive cars without wearing a seatbelt isn't a good argument for cars with no seat belt. Similarly, the fact that millions of JavaScript developers productively use an inherently unsafe language isn't a good argument for the use of unsafe languages."

</comment><comment><USER70> This is very ominous. In other words, don't build a RN app because, if it takes off, Facebook can copy the business model independently and claim it as their own. And, if you try to do anything about it, your license to use RN is revoked, rendering your app as nothing more than a petty copyright infringement.

If you're going to RN, go Pure Native at the same damn time ;) It's awfully ironic since they market RN to rid us of the need for Pure Native. Or, is it ironic? It seems this clause and their marketing efforts are truly shield and sword. I'm not really surprised; it's a very cunning way to hijack ideas from other people.

I have used RN, though, and it's a blast to develop with it. Thankfully, none of my kooky ideas are going to be important enough for this fine print to apply to me.

</comment><comment><USER71> Is anyone using TypeScript with React Native? I'd be interested to see how easy that is to integrate.

<comment><USER72> In that case it would probably make more sense to just use NativeScript instead of React Native.

[https://www.nativescript.org/](https://www.nativescript.org/)

<comment><USER71> NativeScript doesn't have tight integration with React, and I don't really want to build that layer myself.

<comment><USER32> Angular 2 is pretty awesome and faster than React.

<comment><USER73> Source on that speed claim, please.

<comment><USER32> I can't find the benchmarks that I'd based my comments on to be honest, and I have to get back to work. :|

From what I remember, the final version of Angular 2 added a lot of performance, which pushed it ahead of the latest React in performance.

I did find this:

[http://webscripts.softpedia.com/blog/recent-benchmark- shows-...](http://webscripts.softpedia.com/blog/recent-benchmark-shows-the- speed-of-angularjs-2-499638.shtml)

But the Auth0 benchmarks disagree and show React is faster:

[https://auth0.com/blog/more-benchmarks-virtual-dom-vs- angula...](https://auth0.com/blog/more-benchmarks-virtual-dom-vs- angular-12-vs-mithril-js-vs-the-rest/)

Angular 1 is terrible performance-wise; that much is certain.

</comment></comment></comment></comment></comment></comment><comment><USER74> There is a bug in his code in the `Unsafe initialisation` section. He tries to access variables that are not defined in that scope. A linter would have caught that.

Javascript is like democracy. It works best when:

\- lots of people participate

\- we understand its warts

\- it's allowed to evolve

\- the powerful aren't allowed to write the rules

</comment><comment><USER75> Ok, so to 'fix it' we need React in Swift(instead of JS) without the facebook license clause. It sounds like the next UI framework. Unfortunately you can't have it all because Swift doesn't work on browser(yet, wasm will make it possible)

</comment><comment><USER76> The alternatives mentioned here are not really of the same type. A better example of an alternative would be something like [https://www.nativescript.org/](https://www.nativescript.org/)

</comment><comment><USER77> I was hoping to read more about performance. React is a resource hog for complex state and no 'componentShouldUpdate' method defined.

I will be very happy to see an app in React Native, just to check if it is as responsive as Objective C or Swift.

</comment><comment><USER78> Article feels clickbaity with some points that have been addressed and discussed thoroughly already. These are known cons of using a javascript framework that compiles to native.

If you just want something easily replaceable, use something like cordova.

If you want perfectly native and guaranteed support, use the native SDKs.

If you want simplicity with a javascript framework that compiles to native with the concerns of it being made by facebook then use react native.

React native solves a lot of peoples problems especially if they are starting an app from scratch.

</comment><comment><USER18> The legal concerns are legitimate, but frankly, I am unconvinced by the criticisms of JavaScript: There are well-known, well-designed tools like ESLint, and if you like types, Flow and TypeScript, which can mitigate the issues. That's more than you can say about Java (COBOL 2.0, now with a bevy of cargo-cult OO that makes things more overly complex), or Objective-C (All the safety of C, with similar OO problems, and a weird syntax that very few people like, and of course, no GC).

<comment><USER79> This comment is flaming on Java and Objective-C, seemingly without having the experience to back it up.

For instance, nobody uses Objective-C for iOS development any more (see: Swift). And modern Java is a decent language to develop in (with Rx and the like). You can even develop for Android in kotlin, which gives many of the advantages of JavaScript, but with a static type system and deep IDE integration.

<comment><USER18> I was exaggerating, but the point was that the other app development languages aren't without their flaws.

I won't argue with you on how good the languages are. It's a matter of opinion, and I'll never change your mind.

Besides, establishing one langauge as better than another was never my point.

</comment></comment></comment><comment><USER80> From the article:

> Compared to React Native, both Xamarin and Appcelerator have better > prospects at longevity. Appcelerator (the maker of Titanium) (runs on apps > installed on 350 million devices) was acquired in January 2016

Last time I tried (circa 2013) Appcelerator seemed a bit unpolished and the tooling was sub-par (I vaguely remember of some hacks needed to get their custom IDE runnning on Windows), I would like to know how are they doing now. Could anyone familiar with it summarise their recent developments?

</comment><comment><USER81> It would be good to have when the article was written/updated on the page. I found Sep 22, 2016 in the changelog (link at the bottom) for first commit.

</comment><comment><USER82> To add to the list of javascript gripes, performance is terrible. For the web we can sort of excuse it because ok, it's running in a browser and has to be cross platform and interpreted and etc. But for a native app? No excuse to burden the user with a slow, sluggish, resource and battery draining app when a compiled native app can be snappy, quick to load, and light on the CPU.

<comment><USER83> Have you tried it? Unless you're handling custom animations in the main thread, the UI feels exactly the same as native.

</comment></comment><comment><USER84> Ability to update your app over the wire with React Native is a massive advantage overlooked in the article. (via Codepush or something similar)

In big companies app releases are a huge problem when 100+ committers and tens of features are released to the same app sometimes within the same app update. React Native has the potential to enable feature teams independently update the app.

</comment><comment><USER85> > There is no mechanism for you to mark a function as potentially crashing > your teammate's code or for specifying how to process an exception.

Maybe I'm misinterpreting this, but is the author actually advocating for Java-style checked exceptions? I can't even remember the last time I heard somebody say something positive about them (other than just now, possibly).

</comment><comment><USER86> Maybe nitpicking, but the author states that "Your codebase can now create an app that can run on millions of additional devices, and you've increased your outreach by several orders of magnitude."

Yeah, Android is growing, but iOS still has substantial market share. Switching to React Native will definitely not give a > 100x increase in outreach.

<comment><USER87> The Android market share is >60% and rising, though. Not sure what you're talking about. [https://bgr.com/2016/06/02/apples-mobile-market-share- sees-b...](https://bgr.com/2016/06/02/apples-mobile-market-share-sees-big- drop-in-may-as-android-skyrockets/)

You're right about the last part, though. You won't _literally_ get a _100x_ increase in reach from _just switching_ to React Native. Being able to develop on two platforms at once might help a little bit there, though, which is what I think the author was trying to say.

<comment><USER86> The nitpick being that usually, one order of magnitude = 10x, two orders of magnitude = 100x, and so on. So it's a very exaggerated statement if taken at face value.

</comment></comment></comment><comment><USER88> This post is completely false, you can absolutely build a safe language on unsafe foundations. Swift is compiled to assembly, which is unsafe, yet it provides a 'safe' interface (not as safe as Rust, but still).

Similarly, Flow/Purescript/Elm have every ability to provide a safe interface to javascript.

</comment><comment><USER89> I wrote a counterargument to it. [http://wokalski.com/Why-Im-not-afraid-to- develop-in-React-Na...](http://wokalski.com/Why-Im-not-afraid-to-develop-in- React-Native/)

</comment><comment><USER90> Granted Swift is a nice language TS or JS + transpiler + flow is decent and unlike Swift you can actually utilise multiple threads :) The patent stuff is moot point Apple has about the same language in their license.

</comment><comment><USER91> > This allows over-the-air code updates. Any changes in your JavaScript code > can be instantly pushed to your users while the app is in production

Is this really true? Or is the author referring to the dev. edit/view loop?

</comment><comment><USER92> You probably shouldn't ever use the phrase [random-technology] developer. It puts you in a box that associates you with all the shortcomings of the given technology.

</comment><comment><USER93> We have PureScript which is statically typed, pure functional language compiling to JS, can't it be adopted for React Native development somehow?

<comment><USER23> You really need to check out Elm.

It's an ML-like language with built in functional reactive framework similar to React, but built to work naturally with the language rather than requiring the FFI binding you'd need if you use Purescript.

<comment><USER94> Elm's type systems is really constrained compared to PureScript's. It's great for people coming from JavaScript, but not so much for those coming from Haskell.

Also, you still need FFI in Elm. elm-lang/virtual-dom is basically just a wrapper around the native virtual-dom library. Also, afaik there's nothing like react native for virtual-dom.

<comment><USER23> I was under the impression that Elm rolls it's own virtual-dom?

<comment><USER94> iirc they scrapped that in favor of virtual-dom a long time ago.

</comment></comment></comment></comment></comment><comment><USER95> Alibaba's Weex is better than React Native.

</comment><comment><USER96> After reading this and other comments here, I sort of just wish there were Haxe bindings for to the React Native stuff.

<comment><USER65> That would be cool. What I really want for Christmas this year is React Native but with Elm instead of JS!

</comment></comment><comment><USER97> Probably the best dev article I've read this year to date. Have youz a newsletter? :)

</comment><comment><USER98> I think it's a really nice way to make an app :)

</comment><comment><USER99> We haven't moved much from MVC apps, have we?

<comment><USER57> Nothing wrong with MVC.

</comment></comment><comment><USER100> Idiomatic React looks like a horrendous mix of PHP3 and VBA.

</comment><comment><USER10> 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.

</comment><comment><USER101> JavaScript has its share of bad things but that's mostly solved by good tooling. I think Java or ObjectiveC feel too "heavy" for UI development. React makes it simple and even with its downsides in my opinion it makes other technologies no longer relevant in this domain .

<comment><USER57> >it makes other technologies no longer relevant in this domain

Are you really trying to say that React Native makes Java not relevant for Android and ObjectiveC/Swift not relevant on iOS. Maybe you are correct if you want to build Hello World application, when you will be needing something more optimized sooner or later you'll have to rewrite it in Java/Swift.

<comment><USER101> Do you have any specific example where Java or ObjectiveC/Swift would be of better use?

<comment><USER57> Anything that requires some kind of processing like, for example facebooks own Instagram.

<comment><USER101> That's fair, but why would you do Instagram like processing in the UI? I'd rather do native library and call it to do the work...

</comment></comment></comment></comment></comment><comment><USER102> tldr; javascript and facebook

</comment><comment><USER103> Author says the bad outweigh the good, but we haven't fully evaluated the good.

So, question for people who use React Native - how long does it take to go from [100% front end developer familiar with React] ...to [writing solid native apps] with React Native? And how much platform-specific knowledge outside of RN do you need to absorb in order to do this well?</comment>


Ask HN: Good monitor for programming? - <AUTHOR>

What monitors you guys use/recommend for programming 8 hours a day? <comment><USER2> I tend to go for Samsung, yet to have a problem with them in the PC space. My Samsung phone otoh has developed a few blue pixels which I'm not enjoying.

</comment><comment><USER3> i love 2x24 inch vertical or horizontal

vertical you can get like 200 lines of code per screen and horizontal you can 4-6 window and its amazing</comment>


Ask HN: Did you ever do any academic/hobby research? - <AUTHOR> Hi. I'd be curious to know what academic and hobby research people have done. I've met a lot of people who were researchers at one point and I'd be curious to know what the netizens of this board did. <comment><USER2> I once bought every kind of microwave popcorn at my local grocery store. It was about 8 brands, if I remember. This was 10 years ago. Then I popped them all for the same time in the same microwave. I weighed them before and after. Did a blind taste test. Measured value and did a (label) blind ranking of aesthetics. Put it all in some nice graphs and tables and threw the whole thing on a micro site called thepopcornexperiment.com or something with a handful of affiliate links. (It hasn't been live for years.) I think it made a couple hundred bucks over the course of like 3 years before I finally took it down.

I'm not sure that's what you're asking about, but it's the first thing that came to mind :)

</comment><comment> design-of-homes I used to write a blog about housing design. I had no connection with the housing industry or the field of architecture, merely a strong interest in high-density housing. As such, I read books, papers, went to the library to dig up archived publications full of insights (but unavailable online). My research was for filling my blog with topics and for using them as a discussion or talking point.

The research never felt like a chore, quite the opposite. Because I was writing down what I was learning, I felt I could fairly confidently speak at length on some aspects of housing design. As is often said: if you write down what you learn, you remember it better and it deepens your understanding.

</comment><comment><USER3> I tried to learn as much about thermionic converters in hopes of building one but the fabrication problem was too difficult.

</comment><comment><USER4> About forty years ago I was a research assistant for a university physics department. I supported two researchers, one a tectonophysicist who was studying the geometry of shearing in viscous flows, and the other a theoretical physicist who was studying practical applications of optics in measurements at atomic scale.

Another assistant devised a clever solution to a problem in making practical measurements of shearing. The physicist wanted a way to fit nearly-spherical balls of clay into the middle of blocks of clay of a different color, so that he could pop in the sphere, shear the block, and then compare measurements of the resulting distortion with mathematical predictions. One problem was how to get mostly-spherical balls into a smoother, more-nearly-spherical shape, and the other assistant rigged up a clever device made out of some photographic development equipment that rolled a near-spherical ball of clay around in a bin for hours, resulting in a very-nearly-spherical ball.

More relevant to computing, about six or seven years ago I worked for about a year and a half on a subproject of Peter Neumann's Clean-Slate computing research project. The overall project was funded by DARPA, and pretty large. (I don't know its current status). Its mandate was to examine a group of proposed ways to address rampant security and reliability problems in computing.

I worked on maintaining and extending an implementation of a novel programming language intended to be the main system and application language of a new computing platform. I didn't design the language, or any substantial part of it; I just fixed bugs and proposed and added conveniences for programmers.

The language used both static and dynamic type disciplines, simultaneously, in order to address the areas that each discipline handled best.

The language, called "Breeze," was meant to represent some security and data- integrity invariants in the type system that are not normally handled that way. For example, Breeze made it a type error to transmit privileged data to a recipient or a process with the wrong privileges.

It was a terrifically interesting project. I enjoyed it a lot. I did notice at least one problem with approaching it as an academic research project. It sometimes seemed like the incentives to publish novel work made the researchers less curious than I expected about related work that had previously been done--I'm guessing because nobody wants to publish a paper that basically just says, "these guys tried this thing and it worked pretty well."

I can't be sure, but it seems like maybe this preference might have slowed practical progress in some areas. On the other hand, it could also be that the researchers had more substantial reasons for their lack of interest in some older work, and I just didn't know about them.</comment>


Show HN: DeepSwarm – Optimising CNNs Using Swarm Intelligence - <AUTHOR> https://github.com/Pattio/DeepSwarm <comment><USER2> I'm old enough to have started doing machine learning before the deep learning revolution. When it happened, I predicted we'd see a resurgence in metaheuristics (of which ACO, used here, is an example), which just like neural networks in the pre-deep learning era, have a poor reputation among researchers. And it pretty much happened, though at first disguised as "bayesian optimization" [1].

I took an undergrad course in evolutionary optimization, and became briefly excited about it, so I'm fairly familiar with the ideas in that area. I think that similarly to neural networks, they don't really have a great mathematical basis to say what will work and what won't -- it's a lot of empirical experimentation. Do they work? Yeah, kinda. There's really few other options when you have to deal with large, combinatorial spaces such as neural network architectures. I do think a lot of research in the metaheuristics area, at least a few years ago (I haven't really kept up with it) is pretty bogus -- I lampooned it in a couple of "papers" ([http://oneweirdkerneltrick.com/spectral.pdf](http://oneweirdkerneltrick.com/spectral.pdf) and [http://oneweirdkerneltrick.com/catbasis.pdf](http://oneweirdkerneltrick.com/catbasis.pdf)). Yes, all the citations are real.

[1] Bayesian optimization is great, though I find it amusing that people who wouldn't touch a genetic or swarm algorithm are totally fine with BO when it's really not that different.

<comment><USER3> There are some people fighting the good fight for more disciplined metaheuristics research. Metaheurstics - the Metaphor Exposed is a nice read ([https://www.cs.ubc.ca/~hutter/EARG.shtml/stack/2013_Sorensen...](https://www.cs.ubc.ca/~hutter/EARG.shtml/stack/2013_Sorensen_MetaheuristicsTheMetaphorExposed.pdf)). The author is spot on that a lot of the nature-inspired algorithms don't even make sense as metaphors and they're just obfuscating the descriptions of algorithms unnecessarily.

<comment><USER2> Looks like an interesting paper - I agree with your single-sentence summary, at least. I'll check it out.

</comment></comment></comment><comment><USER4> Link to paper with results on Imagenet and comparison with related work?

<comment><AUTHOR> The paper is not published yet, as this work was done for my dissertation, however we should publish the paper in coming few weeks. As for the results they are not as good as state-of-the-art methods, but they seem to be pretty competitive when compared to other open source libraries. The current problem is that complex nodes like add and skip nodes are not implemented yet, so it can only generated sequential structures. Once the paper is published I will update GitHub readme file.

<comment><USER4> What about compute resources needed?

<comment><AUTHOR> Runtime on CIFAR-10 dataset for different ant counts: [https://edvinasbyla.com/assets/images/deepswarm- runtime.pdf](https://edvinasbyla.com/assets/images/deepswarm-runtime.pdf))

Runtime compared to genetic architecture search (using similar settings): [https://edvinasbyla.com/assets/images/devol-deepswarm- runtim...](https://edvinasbyla.com/assets/images/devol-deepswarm-runtime.pdf)

The error rate on CIFAR-10, before the final training (meaning that topologies weren't fully trained and no augmentation was used): [https://edvinasbyla.com/assets/images/ant-before- train.pdf](https://edvinasbyla.com/assets/images/ant-before-train.pdf)

The error rate on CIFAR-10, before the final training compared to genetic architecture search (using similar settings): [https://edvinasbyla.com/assets/images/devol-deepswarm- cifar....](https://edvinasbyla.com/assets/images/devol-deepswarm-cifar.pdf)

The 2 main factors that contribute to faster search are (1) ants search for architectures progressively (meaning that early architectures can be evaluated really fast), (2) ants can reuse the weights as they are associated with the graph.

All test were done using Google Colab. Even though results might not seem that impressive, I am still really excited to see what will happen when ants will be allowed to search for more complex architectures which use multi-branching.

<comment><USER4> I just looked up the ant colony algorithm, and intuitively the idea of pheromones and path reinforcement makes a lot of sense. Are you the first one to try it for NN search?

<comment><AUTHOR> To best of my knowledge there are no published papers that use ACO for CNNs neural architecture search. However, I found three published papers that used ACO for different NAS, but they used static graphs and no heuristics.

</comment></comment></comment></comment></comment></comment><comment><USER5> This is an interesting project. Is there a way to save the produced model, because I didn't see anything in the examples?

<comment><AUTHOR> Yes, once you start the search a directory corresponding to the date of your run will be created inside the saves directory. Inside this directory all your models and progress will be saved automatically (you can later resume the search by changing save_folder value inside configuration file). Once the search is done you will find best_topology file which will containt the topology with its weights. Furthermore, inside the deepswarm.log file you will see all the previously evaluated models with their loss/accuracy values.

</comment></comment><comment><USER6> I usually just optimize CNN architectures using Google's intelligence, i.e. let the big companies with infinite compute find good architectures for me.

<comment><AUTHOR> That's fair, but I think it is nice to have some alternatives that are free and open. Furthermore, some people might have sensitive data which they wouldn't feel comfortable uploading to the cloud.

Also, I wanted to ask: were you using Gooogle Vision, as when I was doing the research it seemed that they do not allow you to export the model.</comment></comment>


Connect with people who share your taste, interests and passions - <AUTHOR> CoTaste is a great interest network that helps you connect with like-minded people to share your passions. You can create many interest lists to organize everything you love in one place and share with pattionate people. Moreover, you can also follow other lists to get updates in news feed, and make a lot of fun things you could ever imagine. CoTaste allows users collect books, tracks, links, photos, videos to list and share everything you love with pattionate people. CoTaste learns your interests, tastes, activities to make recommendations. http://cotaste.com helps you create a network where people actually have the same passions. Why we're here? There's nothing new in current social networks other than a few UI changes. The people are the same. The posts are the same. We will continue to use social networks but we don't expect to see anything other than the life stream of our friends and family. CoTaste give you a chance to switch to the next stage of social networking. <comment><USER2> On Chrome if you try to display goodreads books, they don't show because of some cross-origin policy.

</comment><comment><USER3> I love it ;)

</comment><comment><USER4> great startup</comment>


Ask HN: If you could build anything, what would you build? - <AUTHOR> You're already wealthy beyond compare. Profitability doesn't concern you. All the standard startup stuff has fallen by the wayside.<p>What do you build? Do you hire a team, or are you building it to learn? <comment><USER2> This doesn't answer the spirit of your question, but regardless of the product/service, I would build a company with an emphasis on employee happiness (which also doubles as a recruiting tool):

\- Full-remote

\- 4 days/week instead of 5

\- 2-3 months mandatory PTO

\- Bootstrapped

This isn't lofty or anything, it's really what I aspire to do some day soon. To me there are few sane reasons to build a company predicated on the 40 hour work week in an era where work is intellectual and not based on quantifiable throughput (like working in an assembly line). Today, I would gladly take a 20% paycut to work 20% less per week (e.g. get Fridays off), and so I'd want to build a company in the same way.

I personally think the world is already headed in this direction (with remote work being the first big change).

<comment><USER3> This is really interesting. I would love to hear more about how you would go about doing this. Mind if I email you?

<comment><USER2> Sure, my email is in my profile.

I want to clarify that I don't think this will necessarily work for every company, especially high-growth, high-competition companies like Uber. Probably moreso for companies that acknowledge, due to market cap, that they will never be a billion dollar unicorn.

</comment></comment></comment><comment><USER4> Moon colony. Sex robots. Sex robot moon colony.

Open a chain of small 100-bed hospitals throughout the US, give them doctors working normal hours and software to handle all the management stuff. Accept cash and credit only--no medicare, no insurance, no bullshit. Just cheap healthcare that people can rely on, payable on exit.

Start a scholarship for hackers at colleges--must have less than a 2.8 GPA to apply, and must have cool hacks submitted every semester. Hacks that aren't some stupid fucking sociomoboloco sharing economy coupon thing. Hacks that have teeth.

Oh, and two gigantic hands, two thousand feet tall, flipping the bird to NY and SV.

<comment><USER5> I like #2.

</comment></comment><comment><USER6> Fixing drug resistant bacteria.

Here's the plan: You go into the doctor's office. You give a small blood sample to a machine. It finds the bacteria in it, and DNA sequences them. It then looks them up in a library of known antibiotics, and prescribes for you an antibiotic that will kill exactly what you have.

If it can't find an antibiotic that will do the job, it sends the DNA sequence to the US CDC. They hand it to a supercomputer, which solves the protein folding problem, and therefore can determine what the surface of that bacteria exposes. They then derive an antibiotic that will kill it, and add it to the library in all the doctors' offices.

Taking the blood sample is a solved problem. Scanning the DNA is close. The protein folding problem is harder, and deriving an antibiotic from the surface geometry is really hard. So those are the problems that need solved to do this.

I think it could be done in 30 years, but I can't guarantee it...

</comment><comment><USER7> If I could work on _anything_? If I was already wealthy and really, really didn't have to think about making money from it? Then I'd work on fusion reactors. I'd have to hire a team, but I'd also want to dig in and learn as much as I can myself.

</comment><comment><USER8> Not sure I should really just give you all of my best ideas, but people will probably ignore this anyway.

Distributed artificial general intelligence app, probably something like using deep learning with a virtually embodied agent.

A digital circuit IP or maybe separate USB dongle that does path tracing in hardware, maybe based on procedural generation from a built-in Forth.

Various business and government ideas built on Ethereum, promoted with the intention of displacing existing more centralized institutions with decentralized ones.

A backyard exchange website where people can rent out or share their backyards for tiny house 'parking' and/or high-tech gardening like aeroponics or aquaponics, or whatever they want besides being a big waste of space collecting dog crap.

A deep underwater research living facility for testing closed eco-systems for space/the moon/mars.

Mesh and optogenetic BCIs explicitly for human enhancement.

Robots based on mulitlayered-multibraided electroactive-polymer muscles with anatomical mimicry.

A unification of computer science, programming, and math. Or, a metalanguage and representation tying together classical programming and mathematical notation with interactive and/or visual programming, with the common part reused in all types of informations systems.

Simple, low-priced home aeroponics systems sold in grocery stores, with plastic supports enabling sweet potatoes to grow.

A new operating system for virtual reality.

A small, lightweight hot-rod electric skid-steer with heads-up-display using ultracapacitors and high friction to enable very high-speed cornering and acceleration.

A house, fully paid for, for every person or family I could afford.

<comment><AUTHOR> >A new operating system for virtual reality.

Elaborate.

</comment></comment><comment><USER9> I'd want to start an infrastructure company, internet (fiber) and cellular.

But unlike traditional ones I'd build or buy the physical infrastructure and then resell access to any party which wanted to buy it, from big to small. I'd then use all of the profits to expand, then resell, repeat.

Essentially I'd want to become an "invisible" company that sits behind public facing ones, and let's them take all the credit/blame, while I just continue to expand and resell. Kind of like "Level 3 Communications" but in the "last mile" segment (all the way to consumer's front doors/businesses).

Then if I grow big enough, I'd start buying up companies like AT&T, take their infrastructure into my pool, and then resell the consumer/business arm off to someone else (and have them rent back space on the network from us).

The eventual goal would be a complete monopoly over all US infrastructure assets, but a completely fair one, big and small companies would pay the same dollar price for raw access and could resell at profit margins they felt suited their business model.

The hardest part aside from the billions of dollars it might cost, is setting up a pricing scheme which is rational, but also encourages continued growth. Most of the ways companies currently split up a fixed bandwidth network is kind of clunky and doesn't scale very well.

</comment><comment><USER10> I'd create a music generation software. You pick your base sounds and the mood you want to create, and the software will take it from there. There's already tons of research out there on what make a song happy, sad, etc. - all that would essentially be needed are base sounds as a reference point and the software would create various versions of an instrumental by cycling through example or custom melody patterns whcih alter the pitch of those base sounds. With all the info that's out there, I'm really surprised this hasn't been done before. Would definitely need a team for this, but I'd love to get my hands dirty in between managing.

</comment><comment> T-A Maybe non-rocket space technology [1]. Totally worth it even if all it does is help Musk reminisce some more about Charlie and the Chocolate Factory [2].

[1] [https://en.wikipedia.org/wiki/Non- rocket_spacelaunch](https://en.wikipedia.org/wiki/Non-rocket_spacelaunch) [2] [http://shitelonsays.com/transcript/elon-musk-lecture-at- the-...](http://shitelonsays.com/transcript/elon-musk-lecture-at-the-royal- aeronautical-society-2012-11-16)

</comment><comment><USER11> If I had unlimited amount of money, I would buy all the advertisement channels of the world and fill them with classical music. I would by all the billboards spaces and burn them to ground or if that is not possible, I will paint them sky blue with white fluffy clouds or camouflage them.

Just kidding (not really).

A bit more realistically, I would build an open source car company. I mean, a car which is 100% documented and documentation publicly available. with all the diagnostic tools and information how to use them available publicly.

</comment><comment><USER12> A free service where I can connect with doctors, medical professionals to talk about health issues. Nothing formal but more casual information discussions.

<comment><USER13> Quora for doctors

<comment><USER14> figure1.com

</comment></comment></comment><comment><USER15> Since I am unskilled I wonder how I became so wealthy. Then I hire a team to build the things I want.

The things I want to build: Firefox with the 3.6 or older interface and uses libavcodec for video decoding; a clone of Windows Explorer for Linux; a perfect clone of Winamp; media library software that links together all the best features of existing programs.

ITT: things that will never happen.

<comment><AUTHOR> >ITT: things that will never happen.

That's the idea

</comment></comment><comment><USER16> A system that's as good (no, better!) at teaching as an individual teacher, at worldwide scale. (Not sure if it's doable.)

</comment><comment><AUTHOR> I think the GUI application paradigm completely broke the unix way. You used to be able to pipe programs into eachother. This means that if you used programs enough you'd eventually pick up programming skills.

I'd like to make modern GUI stuff work a bit more like that. I'm imagining a state synchronized pseudo filesystem. Instead of storing files, it stores hierarchical C data types. A folder, with an array of vertexes and faces, inside another folder that contains textures and metadata. They're not folders, just nodes, but hopefully you get the idea.

You can use your image editor to edit those textures, and the changes would show up in real time in your 3D scene editor. Small applications that do one thing well, because the "file types"(data structures) are standardized enough.

Programs subscribe to changes in a file, sometimes over a network, using a state synchronization protocol. Think rethinkDB, but optimized for very fast read/write, not querying data. If you wanted to query the data like that, you'd have a daemon watch the folder, and index the data. The point is to focus on speed above all else, so you can watch real movies or stream real content in it, and then build your indexing a layer above that.

Of course there are a whole lot of problems with that approach, and it's well beyond me. But I'd hire some C tutors, and the guys who make btrfs, and see what could happen.

In my heart of hearts, I know this is probably just because I want to live in a world with a real metaverse, and I think this will get us one step closer to the kind of collaboration you'd need to get real work done in a virtual environment. But I still think it's a pretty good approach.

I do find there's an advantage to hanging out and working with people in a real space, and I'd like to break that down a bit more.

See:

#Problems in unix design, the art of unix programming, Eric S Raymond

[http://www.catb.org/esr/writings/taoup/html/ch20s03.html](http://www.catb.org/esr/writings/taoup/html/ch20s03.html)

>#A Unix File Is Just a Big Bag of Bytes

>A Unix file is just a big bag of bytes, with no other attributes. In particular, there is no capability to store information about the file type or a pointer to an associated application program outside the file's actual data.

>#File Systems Might Be Considered Harmful

>Was having a file system at all the wrong thing? Since the late 1970s there has been an intriguing history of research into persistent object stores and operating systems that don't have a shared global file system at all, but rather treat disk storage as a huge swap area and do everything through virtualized object pointers.

#The Verse 2 Protocol

[http://verse.github.io/](http://verse.github.io/)

</comment><comment><USER5> A better communication paradigm.

</comment><comment><USER17> Teleportation

<comment><USER18> I am curious how are you going to go about it?

<comment><USER17> Ensure my financial stability and I'll work on an answer...works for you? :-)</comment></comment></comment>


New Nokia 3310 will be practically unusable in many countries, including US - <AUTHOR> http://gadgets.ndtv.com/mobiles/news/nokia-3310-2017-supports-old-gsm-frequencies-will-be-useless-in-the-us-and-canada-1664424 <comment><USER2> Nokia 3310 is going to fail in the markets it's being launched at, i.e. India. The biggest reason for it's (possible) failure is that the people have simply moved on to Android/4G.

Nokia's were a rage when the mobile market was nascent (2004-2010), and carriers flooded the market with cheap SMS rates. With loads of cheap Android phones available, and no WhatsApp on Nokia devices, it's a DoA device. And it doesn't even look as durable as the original classic.

<comment><USER3> I guess not!

There is still a huge population which wants basic phones as a backup atleast. There are places in india where electricity is not so easy to get and the monthly salary is still under 100$ The senior citizens even though have migrated to smartphones stil are in the dire need of a durable small phone.

I feel apple may also jump in with a luxury feature phone,Just a matter of time

<comment><USER4> This! Low-end Nokia phones are not meant to replace Android phones, but as a backup(supplementary) phone.

Might not be apparent in Silicon valley but in third-world countries its:

* Snatcher deterrence. It would be less likely targeted than say an iPhone when used in risky public areas.

* Ideal for people who'd only use a phone for texting and calling (eg. older people, farmers, laborers).

* A phone that does not need baby sitting: long batt life, doesn't care if it falls on the floor, when it rains just wrap it in plastic.

* And the one thing that I miss the most in smartphones: Texting without ever looking at the screen.

<comment><USER5> Our teen could hold her iPhone under the dinner table and 2-thumb touch-type texts while keeping eye contact with us, hoping we wouldn't notice. When caught, she demoed that she could be almost 100% accurate even with the phone completely out of her sight. Dead-reckoning with no feedback! Necessity is the mother of invention, I suppose.

<comment><USER6> I don't think I would have been able to do that as a teen.

</comment></comment></comment></comment></comment><comment><USER7> I'm in the UK and I've already scratched this itch by replacig my iPhone with a Nokia 105 ([https://www.nokia.com/en_int/phones/nokia-105](https://www.nokia.com/en_int/phones/nokia-105))

All the features of this new 3310, but even more authentic, and they're selling for 10-20GBP

Edit: did I mention that it only needs charging once a week?

<comment><USER8> Had one like it in China in 2008. It was a decent phone. Crappy camera though.

<comment><USER7> No camera on the 105

</comment></comment></comment><comment><USER8> I never really considered that they would simply make a clone of a Nokia 3310 with an updated display. Why no modern radio? I think people would buy this if it weren't crippled by obsolete hardware.

</comment><comment><USER9> Anyone saying this phone is destined to fail miserably - don't look at it from your viewpoint, but from your (grand)parents'. My mum can't stand touchscreens from an UX perspective, plus she hates the constant charging. All she ever does is call her friends and family and send the occasional text to check on us.

There are currently phones that serve her well (e.g. Nokia 230). This is another one.

<comment><USER10> I still see quite a few of them even among the 30-50 years-old range. Here in the lowest rungs of the developed world, the choice is often between a featurephone or a very cheap Android, and the latter are often unusable crap. Personally, I use a 20€ Wiko Lubi4 and a tablet instead. Smartphones are jack of all trades, but not really satisfying for any.

That said, even my Wiko does support four networks. Seems shortsighted to be selling these nowadays, even in the markets they're targeting.

</comment></comment><comment><USER11> This is exactly what a retro-phone should do. Originally a standard GSM-phone worked everywhere else except in USA and some clueless South American countries, like Chile.

<comment><USER12> I remember my European cell phone also didn't work in South Korea in 2006, because they used CDMA.

</comment></comment><comment><USER13> My mother is not able to use a modern Android or other phone, she really does need the phone numbers and some small address book facility, 1: daugher 2: brother 3: son 4: her best friend 5??? After that then it is paper phone book and typing digits. The turn of the century never happened!!!

We have tried getting special phones for my mother but the UX is always worse than worse. They are unusable to people! So maybe if this Nokia actually worked on 3G it would be perfectly suited for her, a landline style phone that worked without the landline. There is definitely a market for such a phone that has a good brand, e.g. 'Nokia' is nice and shiny with lots of colours and just works.

The other feature I think is needed is mobile wifi hotspot. Ideally you just press a button and the display shows the SSID and access code, again that being some easy code.

Again, my mother can use a computer perfectly fine for online shopping, if she just had to press a button on the phone and that meant her computer was online then that would be something she could do herself. Her hands are too arthritic to do web surfing on a handheld device, she needs a keyboard and trackpad. The right Nokia could have enabled this.

</comment><comment><USER14> I love the idea of a stripped down "basic" well designed phone. I was just talking to my friend who is much older, about it. We were romanticizing the days of the Motorola StarTAC. I don't want a browser, email, apps, social, or a big screen, just a phone and contact list. The StarTAC was simple sleek, had a dial pad and contact list, and the battery lasted 5 days.

In todays terms, for me that is like StarTrek technology.

</comment><comment><USER15> Interesting question, is 2G dead because people don't want 2G or is 2G dead because phone companies don't want to support it? Or something else.

<comment><USER16> The phone companies don't want to support it, or more specifically, they want to reuse the 2G spectrum to build out their LTE network.

<comment><USER17> LTE is more spectral efficient, but it's expected that GSM will outlive 3G technology (WCDMA, ie. UMTS/HSPA) due to the low cost of deploying and ability to run on very small spectrum slices (200khz, can be done with only about 1Mhz of spectrum so long as the network is planned carefully due to channel reuse)

Carriers that can get away with running GSM in their guard bands often do to support legacy M2M devices and international roaming customers.

<comment><USER18> There's a load of coke vending machines etc using 2g, and the networks hate it.

</comment></comment></comment></comment><comment><USER19> How expensive would it be to manufacture a feature phone that is compatible with 2G, 3G and 4G LTE with VoLTE support? I think there is a good market for such a product.

<comment><USER17> Getting cheaper but those radios are still comparatively power hungry, costs of certification are high, and it's really up to the carrier if they want to allow it on their voLTE network. 3G/2G featurephones do exist.

Try buying an international phone with the correct band support and put it onto a US network, it'll kick down to 3G or 2G to make the call. No point really in having the extra data speeds a featurephone won't need (for most people). I personally would like to have a small, durable, and low powered featurephone I could also use as a usb modem.

</comment></comment><comment><USER20> Is anyone aware of an alternative (with a similar budget price, maybe something marketed in the developing world?) that can be used on a modern phone network?

<comment><USER7> Nokia 105. Works for me.

<comment><USER21> The 105 is also 2G only and won't work in the US, Canada or Australia.

</comment></comment></comment><comment><USER17> Woulda been nice if they could have put GSM1900 in it. It would have worked on T-Mobile.

I'm in the DIGITS beta and have a sim that's basically a clone of my main smartphone line, I use the clone on a 2G featurephone cause the battery lasts a week. It's also funny to have the old ringtones go off.

</comment><comment><USER22> 3310 market is poor people in developing countries.

That said, it's just marketing trick.

I have Nokia 108 (dual sim) phone I use in weekends. It's smaller and the battery lasts 31 days in standby mode.

[http://imgur.com/a/HOlOk](http://imgur.com/a/HOlOk)

</comment><comment><USER23> Well DUH its well known the USA went there own way and ignored GSM either for NIH or NTB

<comment><USER24> AT&T was using GSM back when it was Cingular, before the 3G rollout.

So did the progenitor to T-Mobile.

I think on different frequency bands, limiting the usefulness of international phones.

<comment><USER17> >AT&T was using GSM back when it was Cingular, before the 3G rollout.

They were using it up until the end of 2016. [https://www.att.com/esupport/article.html#!/wireless/KM10848...](https://www.att.com/esupport/article.html#!/wireless/KM1084805)

> So did the progenitor to T-Mobile.

T-Mobile still uses GSM1900 nationwide and GSM850 (not well known that they do) in Myrtle Beach, SC.

>I think on different frequency bands, limiting the usefulness of international phones.

You don't know what you're talking about, stop spreading misinformation. There are small rural/regional carriers that still use GSM1900 or GSM850 in areas, I can think of Indigo Wireless out in west PA as one of the companies.

<comment><USER24> > They were using it up until the end of 2016.

>T-Mobile still uses GSM1900 nationwide and GSM850 (not well known that they do) in Myrtle Beach, SC.

I wasn't trying to establish that they had stopped, I was pointing out that they adopted it quite some time ago.

Perhaps "international phone" was the wrong term, my intent was to say that phones sold in Europe often wouldn't work in the US. Was that not the case? Oh, I see in [https://news.ycombinator.com/item?id=13792767](https://news.ycombinator.com/item?id=13792767) that you agree with that. Sorry if I used the wrong words.

Hasty interpretation of [https://en.wikipedia.org/wiki/GSM_frequency_bands](https://en.wikipedia.org/wiki/GSM_frequency_bands) at least indicates that different frequencies were used in different areas.

<comment><USER17> > I wasn't trying to establish that they had stopped, I was pointing out that > they adopted it quite some time ago.

My apologies, I wrongly assumed we were talking about the current network landscape. You would be correct.

> Hasty interpretation of > [https://en.wikipedia.org/wiki/GSM_frequency_bands](https://en.wikipedia.org/wiki/GSM_frequency_bands) > at least indicates that different frequencies were used in different areas.

If memory serves. In the US it was GSM1900 up until the late 90's/early 2000's, AT&T Wireless decommissioned their legacy TDMA network at the time on 850mhz and shifted to using 850mhz for GSM due to better rural signal propagation.

Worldwide outside north america's 850/1900, there is 900/1800, and to a much lesser extent maybe 450 for siberia, and in other places likely better served by satellite.

</comment></comment></comment></comment></comment><comment><USER25> Url changed from [https://thenextweb.com/mobile/2017/03/03/nokia-3310-unusable...](https://thenextweb.com/mobile/2017/03/03/nokia-3310-unusable-2g-us/), which points to this.</comment>


More than 150,000 links to http://127.0.0.1/ according to Google Search - <AUTHOR> https://www.google.com/search?ie=utf-8&q=link:http://127.0.0.1/&tbm=blg&tbs=sbd:1

<comment><USER2> Interesting. So what does this mean? People are running on localhost?

<comment><AUTHOR> I once (many years ago when I was still learning HTML), coded a website locally and it had a few links to <http://localhost/>. My apache was set to auto run at system boot and hence the local site was always available to me. I hosted it to internet but for many weeks didn't realize the broken links. It was all good and fast for me. Guess I was not alone

<comment><USER3> I see a lot of people who try and hyperlink to files on their local machine, like: <img src="C:\website\myface.jpg" />.

</comment></comment></comment><comment><USER4> These are just the sites that haven't updated to IPv6 yet.</comment>


Ask HN: Which laptop do you use?  - <AUTHOR>

I'm looking for a laptop that is lightweight and has a good processor for about 400-500 euro. I will be mainly programming on it. What does HN use? I am wondering if my budget is too low. Ideally I'd get a macbook but it's out of my price range right now. <comment><USER2> [https://www.thinkpenguin.com/gnu-linux/emperor-penguin- gnu-l...](https://www.thinkpenguin.com/gnu-linux/emperor-penguin-gnu-linux- notebook)

<comment><USER3> [http://zareason.com/shop/Verix-545.html](http://zareason.com/shop/Verix-545.html)

Debian 7 (non-free, blobbed out) on ZaReason Verix 545 :) Cheap it is not, though....

</comment></comment><comment><USER4> If you want cheap, get an X201. It has a reasonable CPU, will take 16GB RAM and an SSD. You can change the battery and you can get a nice 9 cell one for lots of battery life.

</comment><comment><USER5> A Lenovo S-series Ultrabook fits your requirements (cheap, light and with OK processor).</comment>


From laboratory in far west, China's surveillance state spreads quietly - <AUTHOR> https://www.reuters.com/article/us-china-monitoring-insight/from-laboratory-in-far-west-chinas-surveillance-state-spreads-quietly-idUSKBN1KZ0R3 <comment><USER2> I have first hand experience in Xinjiang a decade ago. Based on this report, it's gotten even worse. What I remember most was:

1) nearly hourly MMS messages to my flip phone from unknown numbers with an unknown attachment. Since my phone was bought outside China, the MMS attachment didn't automatically open the likely spyware.

2) Being followed and monitored by plainclothes policemen

3) Having my hotel room searched while I was away. Having police come to my hotel room to interrogate me but lacking access because I had the only key to the room (very very cheap hotel).

4) Armed convoys of Chinese army soldiers constantly going up and down major streets.

The originally intention ten years ago was massive surveillance and intelligence gathering. AI and facial recognition are just making this easier and far less costly for their government.

It's clear now that China is moving towards dictatorship, not democracy.

<comment><USER3> "Moving towards dictatorship" is an understatement imho. They're already there.

<comment><USER4> Eh. I dunno. There should be a word for it that isn't dictatorship. There is an order-ness and a certain degree of pragmatism and restraint that the Chinese state has that most dictatorships do not. They sort of bend with the wind at times and it vents the outrage. They allow the intelligent to get access to the real internet without letting the bulk of their population talk unhindered. The way they do the Communist party is really smart too. They take the top high school students and successful academics / business people. So it naturally turns into the area that smart people solve problems, instead of turning them against the state.

I agree that AI-powered surveillance is worrying, but it's not going to look like Stalin. It's going to look like something completely different.

<comment><AUTHOR> > I agree that AI-powered surveillance is worrying, but it's not going to look > like Stalin. It's going to look like something completely different.

China is in the hands of Xi now. So that entirely depends on what he's willing to do to try to retain power, and what he regards as necessary to pursue his vision. Dictators get increasingly paranoid and erratic with time, with few exceptions in the last several hundred years. Erdogan is the latest example of a dictator losing his mind and running a country into the ground to preserve his power and pursue his vision. That's in part because the people get tired of a leader over time, even in the best of circumstances. The only choice to maintain the position Xi has is to crack down more and more on the population, restrict them further and further. Eventually every squeak is perceived as a threat.

The real question is whether Xi leads them back to more Mao-like hyper authoritarian policies, to ensure his dictatorship and his vision for China. I'm skeptical it can end any other way, the path seems to have already been decided. The people that say China is different, are ignoring that this is no longer Deng's China, there has been a fundamental recent change in where they're going. China had to either continue liberalizing, or had to turn back, you can only float inbetween for so long. They chose (both Xi and the party that has handed him the reins).

<comment><USER5> It's difficult to tell, given that China is a dictatorship, but there are some in the party and state that are perhaps opposed to Xi seizing so much power.

Good article on this: [https://www.economist.com/china/2018/08/11/how-to-read- summe...](https://www.economist.com/china/2018/08/11/how-to-read-summer- grumbles-about-chinas-swaggering-leader)

<comment><USER6> China is more of an authoritarian aristocracy at this point ruled by a few really powerful red families. Xi's is only one such family, the others have power and will often duke it out in various factions.

I still don't think Xi is as powerful as even Jiang Zemin was, he definitely isn't at Deng's level yet.

<comment><USER7> If Xi is not very powerful, then how was he able to do away with the two-term limit?

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> This tech will be sold to every country in the world, completed with language files. Plug and play. That's the even sadder part.

<comment><USER9> I have a friend that worked developing Internet in Equatorial Guinea around 2014. He told me that in a couple of occasions, Chinese teams came there to install surveillance systems.

So this is already happening.

<comment><USER8> Countries that started from zero have an advantage over western countries: no legacy systems to interact with. Just brand new apps

</comment></comment></comment><comment><USER10> Curious if the phone scanning devices require the user to provide their pin or if they have the ability to bypass phone access security (I suspect not).

</comment><comment><USER11> I'm really tired of people fawning over China. This is a country with a horrible human rights record, over a million people presently in camps based on _racial profiling_ , and an active program to build the most comprehensive surveillance state in the world.

It's doubly hypocritical when the people doing the fawning are American liberals that would go completely bonkers if anything like that were happening here. (The same logic applies to Saudi Arabia, our other even more brutal "ally.") Money talks I guess. China's GDP growth has been phenomenal and that's all that matters.

Getting tough on trade with China is one of the very few things I agree with Trump about. The Chinese don't play fair in the trade realm either. They vertically integrate their industries with the government, subsidize them to dump, manipulate their currency, ignore the environment and pollute to a degree unprecedented in human history, and deploy "soft" plausibly-deniable mechanisms for trade protectionism so they can pretend to open their markets without actually doing so. The most significant part of the latter is the "great firewall," which is as much about keeping foreign Internet companies out of China as it is about censorship or surveillance. Another mechanism is a maze of regulations around currency, banking, incorporation, and payment systems that makes actually taking payments from Chinese customers painful. It's very easy to send money into China but hard to take any money out.

<comment><USER12> > I'm really tired of people fawning over China.

Where are you seeing this? Any thread even remotely involving China is 95% filled with anti-Chinese posts, such as your own. There were a few this week. Heck, look in this very same comment thread -where are the 'fawners' you speak of?

<comment><USER13> It's strange, isn't it?

It's a ritual at this point: an anti-China post is submitted by adventured, rapidly voted up, and then filled with comments that are a competition to see who can denounce China the most.

What do you suppose the point is?

Is it a Trump thing?

It certainly wasn't always the case. There was a time when I happily shared HN with Chinese colleagues. Was that point, I wonder.

<comment><USER12> The only demographic I can think of that would dedicate so much time denigrating a country with such force and vitriol are the ex-pats. SV types, though very left leaning, are far too busy.

A common pattern to look for is large blocks of hand-wavy, conjecture-fuelled text with little in the way of facts and substance.

<comment><USER14> Do you mean ex-pats from China living in other countries, or ex-pats from other countries now living in China?

<comment><USER6> I think they means the latter. We (well, I used to be one) have a reputation for being salty, though we are just very critical having lived the life and seen things for real.

</comment></comment></comment></comment></comment></comment><comment><USER15> They're just copying what the CIA/NSA has been doing for decades.

<comment><USER16> There's not an equivalency, though. In the US, at least in theory, we have a system that is founded on the idea that a human being has inalienable rights that come from their creator, and therefore are not arbitrary concessions of the state. China has no such concept.

China views a human being as merely material, and human rights as essentially arbitrary. This is not just a theoretical difference. It's as practical as it gets.

If the US does keep going down the road towards tyranny, it is in spite of it's foundation, not because of it, and its actions will be inconsistent with its own guiding principle. This foundational guiding principle of the US gives me some hope that we are _not_ on in the middle of an inevitable collapse into tyranny.

<comment><USER17> > the US, at least in theory, we have a system that is founded on the idea > that a human being has inalienable rights

As long as you're a US citizen.

<comment><USER18> You might be thinking of the border. Within the US, the constitution applies generally to foreigners, IIRC

<comment><USER16> Yep. This is right, and many of our actions at the border are in direct violation of human rights as recognized by the "unalienable rights" clause.</comment></comment></comment></comment></comment>