Hacker News Reader

RN = ReactNative? Gentle Tech Writing reminder that it helps to spell out initialisms the first time you use them.

You're totally right, I'd go back and fix that if I could. Funny how a few months learning a new framework can make you forget how normal people talk :)

Yeah unfortunately, those are downsides that I don't think will change unless we get Go on wasm or something similar. Go brings its own advantages though. Fast, static typing, goroutines, theres no need for JSX, etc. And personally the JS ecosystem doesn't appeal to me at all.

You have kinda missed the point, Go produces fat binaries with all dependencies and the Go runtime included. Serious question: How do you propose that WASM is going to help the situation?

Well if they got the Go runtime on WASM, you could run it in a interpreter and do live reloading. Keeping state across reloads would be challenging, but I don't think it would be an impossible feat.

https://github.com/golang/go/issues/18892

Saving and reloading object state across code changes is one of those things that if you don't build it in to the language from day one, it's really hard to add it in later. I wouldn't expect Go to get it anytime soon.

Even if you do manage to hack it in to something that wasn't designed with it in mind, it's always hacky, quirky, and unreliable, and you never quite know whether you're looking at a bug in your own code or in the state management hackery.

It isn't impossible. You are technically correct. But it's certainly taking impossible out for drinks, followed by long strolls on the beach, and a lot of meaningful staring.

>And don't even get me started on the async keyword

Please do! Genuinely curious what you don't like about it.

If you’re coming from Go especially, my money would be in a similar vein to http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... .

That is, why be explicit about async when implicit style code is much easier to read. That said, the answer in this case is simply backwards compatibility - JS already had a concurrency model before async/await came around.

You can also make a explicit is better than implicit argument; it’s mostly personal preference/ideology though. That said, Python has been in a fun land of “rewrite the world” because the async model they chose (async/await) was not backwards compatible to any existing libraries. So now in Python which library you use for e.g. http varies with which concurrency model you use in the rest of your app.

NightMKoder is right on, that article ("What color is your function") sums up exactly how I felt, trying to learn JavaScript after knowing Go. Also, this interview with Node.js creator Ryan Dahl, where he himself admits that Go solves the async programming model much better than JavaScript, I can relate completely to the reasons he gives: https://www.mappingthejourney.com/single-post/2017/08/31/epi...

"You can also make a explicit is better than implicit argument;"

While I'm generally an explicit sort of guy in these contexts, there isn't much that being explicit buys you here, except the ability to write bugs. There's really only one right answer and the compiler is perfectly capable of handling it. In the exceedingly rare cases where you need to override it, you can. Given how exceedingly rare those cases are we're easily in the realm of "use another language" or "fork & hack the runtime" sorts of things.

Sorry, but I have a noob question. What do you mean in #2 by "Pushing new updates remotely, without having to resubmit your app"

You can update the javascript parts without having to deploy a new version of the app, which takes time on the store's end to approve.

Isn't that highly against the policy?

They've oked it.

At one point, I read that the rule in question, is you cannot push new features without going through the approval process again. So it really comes down to what Apple considers "new features". People have definitely pushed bug fixes, and even small features, without issue.

Perhaps ironically, when I worked on the iTunes Store (which is mostly all HTML and JavaScript) there was hardly a week went by that new code didn't get pushed (mostly bug fixes and under-the-hood updates). Yet Apple only really announced new iTunes Store features several times a year. So, one would hope they understand the need for continuously updating a complex piece of software, versus shipping major pieces of new functionality.

Per Apples policy interpreted languages are allowed to be updated over-the-air as long as they don’t change the app in any significant way (aka bug fixes and such)

Yeah, but how technically. Do you tell JS to run some code on a server, and change that code -aka backend-??? Or what else???

> ... went with RN over ObjC/Swift, is I can just Cmd+R and boom, my changes are live in a second).

As someone with experience in Delphi, C++ Builder, Smalltalk having younger developers rediscovering this looks funny.

Have a look at Flutter and Xamarin.

I actually remember Delphi and C++ Builder (though I spent most of my time in Visual C++), and React Native certainly wasn't my first exposure to hot reloading, but if your only exposure to iOS programming was via XCode, having hot reloading (whether that's React Native or Flutter or Xamarin) can seem like a revelation in how much more productive you can be, when you're not waiting for your app to rebuild and install. So from that perspective, it is kind of like rediscovering the old. (And I didn't mention it, but React Native can reload while preserving state, it's just not the default).

Flutter looks very promising btw, I probably can't use it yet though for the same reasons as Matcha, which is my current project depends on too many external libraries (for which React Native and the larger JavaScript community has been great).

Wait, Cmd+R... you don't have HMR enabled?

For me biggest disadvantage of RN is JSX. It was not bad idea originally, but at this point its very complicated thig full of edge cases.

What edge cases? JSX is basically just syntactic sugar over a function call.