Update on Voyager 2 status - <AUTHOR> http://www.planetary.org/blog/article/00002485/ <comment><USER2> It's interesting to note that although the Voyager probes are sometimes depicted as small (compared to satellites like the Hubble, where images of it next to shuttle astronauts are common place), they're not. The diameter of the main dish, 3.7m, is nearly twice the height of an average adult, and height of the magnometer boom is comparable to that of a 3-storey house.

Even despite this size, the article mentions the current transmission rate, a measly 1.2kbs, despite what is probably the most ideal antenna size & placement feasible, both on Earth and on the probe. Doesn't this suggest there are pragmatic limits to the operational range of 2-way radio transmission throughout the solar system?

I am curious if future such deep-space science missions would be more effective if they instead launched swarms of micro-probes, where the probes arranged themselves radially around a center-point to effect a very large antenna, possibly up to 1km in diameter.

Also, having so many micro-satellite could allow for a substantial degree of redundancy to tolerate more rad damage, and ideally have less of the mission control acrobatics described in this article. (Which is not to discount the scientists' effort in any way, for it is amazing.)

<comment><USER3> Voyager 2 uses X-band radio for communications, more modern systems use Ka- band radio, so with the same size antenna that would increase received power by about a factor of 10. Also, more modern communications technologies such as turbo-codes, which are significantly more efficient than the Reed-Solomon codes used by Voyager 2, further increase throughput for modern systems.

Overall though, yes, there are some pretty harsh limits to radio communication across the outer solar system (Voyager 2 is nearly 3 times as far away as Neptune, and well over twice as far away as Pluto's maximum distance from us). But this is fairly easily remedied by switching to yet higher frequencies or using optical communication.

<comment><USER4> > But this is fairly easily remedied by switching to yet higher frequencies or > using optical communication.

Isn't this the same?

<comment><USER3> Yes and now. Switching to higher radio frequencies uses a lot of the same systems, switching to optical communication would use entirely different systems (some of which have not even been built yet).

</comment></comment></comment></comment><comment><USER5> Some other relevant details from [http://voyager.jpl.nasa.gov/Proposal-2008/Voyager_SR_2008.pd...](http://voyager.jpl.nasa.gov/Proposal-2008/Voyager_SR_2008.pdf):

"Voyager 1 is escaping the solar system at a speed of about 3.6 AU/year while Voyager 2 is leaving at about 3.3 AU/year. Power is the limiting lifetime consumable. The two spacecraft have power to continue returning science data beyond the year 2020. It is likely that at least one of the spacecraft could enter interstellar space while adequate power is still available. All other consumables are adequate for continued operations well past 2020."

"Electrical power is supplied by three Radioisotope Thermoelectric Generators (RTGs) which are performing nominally. The current power levels are about 286 watts, with power margins of about 34 watts and an average degradation rate of about 4.3 watts per year."

"Real-time telemetry data capture is accomplished using 34- and 70-meter tracking antennas of the DSN. Capture of the recorded high rate plasma wave data from Voyager 1 requires the use of an array of 70- and 34-meter antennas."

"Uplink communication is via S-band (16-bits/sec command rate) while an X-band transmitter provides downlink telemetry at 160 bits/sec normally and 1.4 kbps for playback of high-rate plasma wave data."

</comment><comment><USER6> Just wondering, is voyager going at the maximum speed we could we realistically go today or would a newer craft be able to exit the solar system faster? would that even be useful to science?

<comment><USER7> Well, rocket technology hasn't really advanced all that much since Voyager was launched. We could certainly send a faster probe out by spending more money to build a bigger rocket. On the other hand, they could have done so back then, as well.

On the other hand, Voyager picked up an awful lot of its speed not from its initial launch but from slingshotting around the various planets it visited -- essentially picking up some free energy at the cost of infinitesimally perturbing the planet's orbit. If our goal was to send a probe out of the solar system as quickly as possible, we might be able to do a better slingshot than was done back then.

On a third hand, Voyager 2 benefited from a rather fortuitous arrangement of planets which enabled it to visit all four giant planets and presumably pick up some momentum from each. This kind of configuration only comes around once every few centuries so if we launched it now then it would have to miss some planets. I don't know how much of an effect this would have; did the Uranus/Neptune visits "pay for themselves" momentum-wise? (Edit: I looked it up and apparently not, because Voyager 1 which skipped the last two planets is further out and travelling faster than Voyager 2).

One thing we can do now which we couldn't do back then is build a good ion drive. A probe with an ion drive and a nuclear fuel cell could keep accelerating for many years, so it would probably be able to outpace Voyager eventually.

So in conclusion, if we wanted to build something faster than Voyager I think we probably could. But in answer to your second question, no, I don't think it would be very useful to do so. There's not much that's particularly interesting beyond the solar system. We're still keeping Voyager alive because we might as well, but sending another probe out there with it would be a fairly low priority for missions.

<comment><USER8> With your three hands you clearly support the "Aliens messed with it" theory.

<comment><USER9> That will be Voyager 6, after it falls into a black hole and ends up being rescued by machines.

</comment></comment></comment></comment><comment><USER10> Doesn't it seem like, as part of the engineering part of this project, that they would have a system in place that would sweep through and do a comparison for "flipped bits" and, if found, would keep a clone of what the memory should look like and reset those bad bits? What happens when the flipped bit causes the machine to rotate out of communications view? You would basically be dead in the water without a failsafe system like this. What am I missing?

<comment><USER8> What if the system to guard against this itself got a flipped bit? What if the malfunction caused it to think bits in "normal" memory were flipped when they weren't, really?

<comment><USER5> Quite true. One standard solution is TMR:

<http://en.wikipedia.org/wiki/Triple_modular_redundancy>

I doubt that Voyager used TMR, they probably used the best rad-hardened hardware they could build at the time (within power and weight constraints).

</comment></comment></comment><comment><USER11> "Ed told me that that software dump has been completed, and it's 'just a matter of time to determine which bit is flipped.'"

Can they not just diff it?

<comment><USER5> They've got to be simplifying this a lot for the sake of making a press report understandable. They don't even know there's only one bit flipped. If there is one, they will have to do some analysis to figure out that it would really cause the problem.

<comment><USER12> I wonder if they have a Voyager VM.

<comment><USER3> Even if they did, it might prove challenging to feed it exactly the same input as Voyager 2 itself in order to ensure it's in the same state.

</comment></comment></comment></comment><comment><USER13> Does somebody know how long it takes to send a message to Voyager 2? I calculated roughly 12 hours...

<comment><USER14> From <http://en.wikipedia.org/wiki/Voyager_2>, _There are regularly posts of the current distance of Voyager 2 to earth in light-travel time to twitter_. And _Information on the current location of Voyager 2 can be found at HeavensAbove._ at <http://www.heavens-above.com/solar-escape.asp> which looks like a seriously interesting page in its own right.</comment></comment>


Ask HN: Is "Transcendent Man" worth watching ? - <AUTHOR>

Has anyone watched the "Transcendent Man" movie ? Would you recommend it or is it nothing special (as in "the trailer was more interesting") ?<p>Thanks <comment><USER2> I'd like to see it. Is it showing somewhere?

<comment><AUTHOR> "Early 2010" as per their Twitter feed, but there was a private screening at Google yesterday and that's why I asked.

</comment></comment><comment><USER3> The movie hasn't been released yet. I created some of the Second Life video that is supposed to appear in the final cut of the film. From the pre-release footage I've seen so far it is worth watching. Some of it is a reiteration of Kurzweil's last book, but there is some new material as well. If your intimately familiar with Kurzweil it won't all be that new but it is worth watching.</comment>


Ask HN: How to build a 3d ipad game - <AUTHOR>

Hey guys!
We are a UI and a 3D designer and we want to create a cool (3D) ipad game but we have no technical skills nor we have never created an ipad game before.
We will probably hire a developer for this project.
But what are some basic things we need to know about creating a 3d ipad game? Rendering stuff, mapping, multiplayer interaction, connecting to a database to record the scores, etc.
Thanks! <comment><USER2> Unity3D would probably a great place to start.

Very tough hiring a dev for this kind of work; very expensive and hard to find good quality.

</comment><comment><USER3> you might want to check this one out: [http://www.yogurt3d.com/news/yogurt3d-running-on-the- iphone....](http://www.yogurt3d.com/news/yogurt3d-running-on-the-iphone.html)</comment>


Show HN: Browser Extension for Finance on Twitter - <AUTHOR> https://chrome.google.com/webstore/detail/likefolio-stock-in-sites/dofbkdnbdibaadbkmoigipaapbgfoalk Would like your feedback, etc.  This is our first browser extension... we built it because as investors/traders and twitterers we wanted it to exist.
Does 4 things on twitter.com
1. Automatically inserts real-time, streaming quotes after cashtags (ticker symbols) on Twitter.com
2. Highlights tweets with cashtags for easy scanning
3. "Cashtags ONLY" button filters out all tweets that don't contain cashtags!  Find the financial signal among social media noise.
4. Stock Info Dock is there to give you more info about the cashtag you click on.  Expand to see real-time quotes, charts and company info.  Why leave the page you're on for basic info? <comment><USER2> I've used this...it's way cool. Turns your web browser into an investing powerhouse. Nice job LikeFolio!

<comment><AUTHOR> Thanks. Yes that was the goal...just built something we wanted to use.

</comment></comment><comment><USER3> why it need access to all websites instead of just *.twitter.com?

<comment><AUTHOR> It doesn't. I need to upload the new version that has the proper permissions there. Good question.</comment></comment>


130K lost in phishing attack on Bittrex user - <AUTHOR> https://medium.com/@junaidlive/2fa-wont-save-you-from-phishing-5fe426c34c5b <comment><USER2> How many times do we have to people not to store ridiculous amounts of money on exchanges? It happens over and over again.</comment>


Google Confirms 'Buy Button' Is Coming - <AUTHOR> http://recode.net/2015/05/27/google-confirms-buy-button-is-coming/ <comment><USER2> hopefully abp will successfully block it</comment>


Ask HN: Is 30 too old to be a digital native? - <AUTHOR> <comment><USER2> I am 37 and I consider myself a digital native. I did start out on super slow modems, but I have been hacking away at things since I was a young kid.

<comment><USER3> Am 39, have same intuition. In 2nd grade we got Appl IIs. Was BBSing at 13, etc... Certainly not social-network version of the digitalrati though.

WTF is snapchat for? Get off my lawn.

<comment><USER4> I'm a decade older. I've been into computers since I was probably 12 (Burroughs mainframe). I know what Snapchat is for, but I'm happily married and am happy to stay that way, so I don't much care. It's not that we're unaware, it's that the current crop of entrepreneurs are unaware of the market we represent.

<comment><USER3> Ok, so what's the psychological/cultural anchor that keeps Snapchat alive and floating? I mean, I understand what's happening mechanically, but I don't get why it would be engaging, entertaining, or lead to compulsive use.

Maybe because I'm introverted and don't care what my friends are eating? I have no insight into the minds and motivations of young women, so maybe that's part of it too. Dunno.

<comment><USER2> It has some form of hook and reward like instagram, sort of how things are outlined in "Hooked: How to Build Habit-Forming Products" by author Nir Eyal. I have a niece that just turned 16, and she uses SnapChat all the time. My 19 year old nephew told me my recently launched food site bestfoodnearme.com would not appeal to the younger crowd because it was not an app. I countered and said there are people out there that do not want to fill their phone with endless apps. I can remember how open and different the internet crowd was in the mid 90's. Things seem so walled off in their own gardens in this modern app world the younger crowd lives in.

<comment><USER4> _I countered and said there are people out there that do not want to fill their phone with endless apps._

Yup...things are in fact different now.

</comment></comment></comment></comment></comment></comment><comment><USER5> In its original context, it probably applies to anyone that was in school (possibly including college) at a time such that their learning methods could have been substantially affected by the changes in media in the last decade of the 20th century; since then, its usually (fairly arbitrarily) been used to describe those born of 1980.

Insofar as its a substantive experience description and not just another term for Gen Y/Millenials, I'd say if you engaged in substantial online interaction and that it substantially affected the way you approach information, learning, and social interaction, during -- or, _a fortiori_ , before -- high school, then you count.

</comment><comment><USER6> If I understand correctly, I believe a "digital native" to be the equivalent of a "millennial" or a "gen y" person. If so, no, 30 is not too late to be a "digital native".

This would typically be people born 1983 or after. If you are 30, you are more than likely a "digital native".

</comment><comment><USER7> Those who ran BBS systems wax nostalgic about being early adopters of new communication methods and systems. It's the same with the digi-native set; waxing nostalgic about Geocities and Angelfire homepages when they could be building something to replace them (Like what the Neocities and Snapchat crowd are doing). It's the wrong question. 'Too' in a question puts the onus to answer with an extreme viewpoint</comment>


The Oversimplified AWS (Amazon Web Services) Guide - <AUTHOR> http://www.configapp.com/post/2018/05/29/the-oversimplified-aws-amazon-web-services-guide/ <comment><AUTHOR> This is a different and refreshing take on the services set that is AWS</comment>


Show HN: Lunchspire, lunch dating for hackers, made in 6h - <AUTHOR> http://lunchspire.com/

<comment><USER2> Gah. Yet another site that wants access to a social media account without explaining _why_.

OK, you had a "cool" idea. Took you a few hours to implement it. Now that you've implemented, please write some documentation (in the form of introductory information on your web site) explaining that you'll be requesting access to my Twitter/Facebook/WTFE account and why. And, no, typical marketing bullshit is not acceptable (e.g. "So that we can offer you the best possible experience" is not a good reason to want permission to post as me)

<comment><AUTHOR> We found it way too difficult to find new and interesting people who wanted to discuss the same topics as we did. So we created this during a quick hack at <http://startuplocation.com/hack> just to get the discussion started. However, if you are curious as to how and what this does with credentials here you go: <https://github.com/siavashg/lunchspire>

<comment><USER2> Pointing me to the source as documentation is just lazy. Entice me to use your project. Excite me about your goals. Interest me in looking at your code.

Besides, from a security standpoint, I have no idea whether the code in that repository is actually the code running on the site.

<comment><USER3> Ligthen up. It's a project done in 6 hours. Judge it at that. Why do you need to be so hostile? Don't use it if you don't want to.

And no I have no affiliation with the guys and think it's totally fine to be critical, but give the guy a break you speak to them as if they are immature brats.

</comment></comment></comment></comment><comment><USER2> So I suppose these "I implemented this in less than a day" headlines do not imply any kind of quality control. I'll adjust my mental model to incorporate that.

Attempt to enter an "incorrect" time like "2012-05-14 1:00PM" and see the code dump a 'native' error into your browser.

<comment><AUTHOR> Our intention with the project was to initiate a discussion among the hackers at the hack and hopefully inspire them to keep in touch. Sorry about the lack of quality, but feel free to contribute: <https://github.com/siavashg/lunchspire>

</comment></comment><comment><USER4> I applaud people who are self starters and love to create. I'm one of them.

But why the importance on the short amount of time the project was made in? (I assume you're trying to communicate it as important because of your headline.)

Does the fact that you created this site in 6 hours change our entire perception of the site? I'm genuinely wondering.

<comment><USER5> I'm guessing that it shows that you know your tools, and can put together a proof of concept quickly.

There is no telling how much of the code was copied from other projects the developer has worked on. It's clear that Bootstrap UI was copy/pasted from a sample because the Lunchspire contains lots of libraries that it's not even using. Nevertheless, putting this together in 6 hours is impressive.

</comment></comment><comment><USER6> Would love to check it, but:

Traceback (most recent call last): File "/usr/local/lib/python2.7/dist- packages/tornado/web.py", line 988, in _execute getattr(self, self.request.method.lower())( _args,_ _kwargs) File "/home/webadmin/lunchspire/handlers/lunchhandler.py", line 23, in get File "/home/webadmin/lunchspire/handlers/__init__.py", line 24, in render File "/usr/local/lib/python2.7/dist-packages/tornado/web.py", line 474, in render html = self.render_string(template_name,_ *kwargs) File "/usr/local/lib/python2.7/dist-packages/tornado/web.py", line 573, in render_string t = loader.load(template_name) File "/usr/local/lib/python2.7/dist-packages/tornado/template.py", line 323, in load File "/usr/local/lib/python2.7/dist-packages/tornado/template.py", line 353, in _create_template IOError: [Errno 24] Too many open files: '/home/webadmin/lunchspire/templates/lunch_list.html'

</comment><comment><USER7> I think that coding an app is the less important part, if you want your app succeed you have to know how to promote it, how to make it grow, how to make it easy to use, etc ( maybe is boring, but must to be done)

</comment><comment><USER8> Can't view people's icons, which is a bit of a hindrance (Twitter is banned at work)

Perhaps mirror the images? Or use Gravatar? Or ignore people working at BigCorps, they may not be your target demo?

</comment><comment><USER9> I like the idea (as someone who knows few other techies/entrepreneurs in his small town). But, the 'Update your profile' and 'Post tweets for you' requirements are huge red alerts. If you are going to require such an invasive twitter feature, you need to first explain exactly what tweets and under what conditions it would auto-post. Facebook login at least has the advantage of making permissions optional and you get a little box so you can explain. I'd say drop these requirement for new users. You can always request them later right?

</comment><comment><USER10> Trying to host a lunch:

Traceback (most recent call last): File "/usr/local/lib/python2.7/dist- packages/tornado/web.py", line 931, in wrapper return callback( _args,_ *kwargs) File "/usr/local/lib/python2.7/dist-packages/tornado/auth.py", line 296, in _on_request_token Exception: Could not get request token

</comment><comment><USER11> Maybe add the city to each lunch? I think all of them are in Stockholm right now, but not sure.

</comment><comment><USER12> This could be awesome. How about a filter for not showing past lunches or lunches today.

</comment><comment><USER13> Thanks for sending out a tweet as my Twitter account without asking or telling me. I really wanted that.

Who knows what this site will do with your credentials on other sites.

</comment><comment><USER14> I haven't tried it out yet (it seems pretty early-on) but it is a pretty cool idea. Lunchspire is to Meetup.com what Twitter is to Blogging.

</comment><comment><USER15> Maybe a way to cancel a join?

</comment><comment><USER16> Great idea. Get G+ hangout integrated maybe?

</comment><comment><USER17> Awesome, may I ask why you did decide to hack that together in 6hours. Were 5hours ot 7 hours options also on the table?</comment>


Mancala - <AUTHOR> https://en.wikipedia.org/wiki/Mancala <comment><USER2> One of my favorite moments when thru-hiking the Appalachian Trail a few years ago was coming up to a shelter and finding two young girls camping with their parents who had made a mancala board by outlining the pits with sticks and using pine cone scales for the seeds. I love how simple the game is, and how easy it is to create a board anywhere!

</comment><comment><USER3> Ayoayo is a game in the Mancala family in West Africa. I grew up playing it and always thought it was a local game (Nigerian). It is kind of amazing how this game or style of gaming spread all over the world and is part of many cultures. Its funny because many Nigerians think nothing of the game, it is just an old game you pick up when you are a child, kinda like hop scotch or checkers. I actually never knew it was this ancient of a game.

[https://en.wikipedia.org/wiki/Ayoayo](https://en.wikipedia.org/wiki/Ayoayo)

</comment><comment><USER4> One of my early contributions to Debian was packaging an X11 version of mancala, it is still available today. I think there is also an implementation in KDE.

</comment><comment><USER5> I really love mancala. It's one of my favorite games. However, I hate that most sets I've seen come with 3 stones or 4 stones per slot — for competitive play to be effective I've found starting with 7 stones per slot to make the game more "fair" between the person who goes 1st and the person who moves second.

</comment><comment><USER6> Weird, the same picture is used for another game (bao) [https://en.m.wikipedia.org/wiki/Bao_(game)](https://en.m.wikipedia.org/wiki/Bao_\(game\))

<comment> john-radio Bao is a mancala.

</comment></comment><comment><USER7> There's a version of Mancala included in the Clubhouse Games collection for the Nintendo Switch. At first I didn't get it, but now it's one of the more popular games in my home.

<comment><USER8> Used to play it on my Nokia 3310.

</comment></comment><comment><USER9> Highly recommend this talk on the (truncated) history of board games, including Mancala! I got lost down the rabbit hole of [https://en.wikipedia.org/wiki/Taikyoku_shogi](https://en.wikipedia.org/wiki/Taikyoku_shogi) for quite awhile.

<comment><USER10> Sorry, could I ask which talk you are referring to?

</comment></comment><comment><USER11> Surprised that the Wikipedia page doesn't mention how Club Penguin (Flash social meetup game for young kids and teens) re-popularised mancala in the Western world. It was a _big_ deal, not sure if the HN crowd's young enough to remember.

<comment><USER12> Club Penguin released in 2005 and I recall playing Mancala games at least as early as 2000 on PC. Are you sure Club Penguin was actually a cause?

<comment><USER13> In the mid 90s I got a Mancala board, it seemed pretty popular even then.

</comment></comment></comment><comment><USER14> One of my first programming projects in college was implementing a reasonably simple A/B tree solver for Mancala, and then parallelizing it to search with multiple threads. Fond memories!

</comment><comment><USER15> Just bought my 7 yo daughter a mancala set for her birthday. She's absolutely obsessed (fortunately I love it too so she always has someone to play against!)

<comment><USER16> Yes it's strangely addictive. There are some nice apps out there

</comment></comment><comment><USER17> It is still unclear to me how this game is played.

<comment><USER18> You won't learn it from that page as each variant has its own rules (board size, capture rules, etc.).

Here's a specific version and the rules for it [0]. I believe this is the version I learned many years ago. I have a recollection of a Mancala-type game from my childhood, but nothing strong enough to identify the specific version, probably this one though. Then a friend in college was very into it and we'd play this one.

[0] [https://en.wikipedia.org/wiki/Kalah](https://en.wikipedia.org/wiki/Kalah)</comment></comment>


The Oldest Beer Recipe in History from Ancient Sumeria, 1800 B.C - <AUTHOR> http://www.openculture.com/2015/03/the-oldest-beer-recipe-in-history.html <comment><USER2> I believe this is actually the first written recipe, period.

</comment><comment><USER3> Interesting. I'm gonna read this at our poetry gathering in Kunming, China this evening maybe along with some translations from original texts on theistic views of intoxicants. Should make for some fun discussion.

</comment><comment><USER4> "sumeria"? think it's called "sumer"

I translated this recipe back while I was in school! Lots of fun.

</comment><comment><USER5> Pity historians will look back at this period and ask themselves "seriously, what's with all the darn IPAs??"

<comment><USER6> Obligatory xkcd:

[https://xkcd.com/1534/](https://xkcd.com/1534/)

<comment><USER7> I have the most mixed feeling about that XKCD.... it's funny, but really misses the mark for people who _enjoy_ craft beer.

I think that the explosion in choices, availability, and quality have been great for consumers, American manufacturing, and the community that these breweries build around themselves.

[full disclosure: I work in the beer industry)

<comment><USER6> I could be wrong but I don't think the point of the comic is that all beer objectively tastes bad since there are two people in the comic and one of the two clearly enjoys beer/craft beer.

<comment><USER8> I interpreted that differently: one of them has bought into the game of pretending to like beer; the other is breaking the 4th wall and makes the first one uncomfortable.

<comment><USER6> Could be. I file this one alongside other comics about (presumably the author) not liking wine, lobster and sports.

<comment><USER8> I didn't know that. Wow, I've found my soul mate!</comment></comment></comment></comment></comment></comment></comment>


Ask HN: Online presence: pseudonym or real name? - <AUTHOR>

I'm really interested in building up a decent online presence. Putting my code on github, writing articles on things that interest me (and hopefully others), etc.
Problem is, I've mostly used the web as a read-only media, and am a little cautious of putting my name all over it. I kinda like the idea of having a pseudo name to hide behind online, probably due to the fear of doing something really crap and it forever being attributed to me. But I also have a feeling that it's a bit lame, and alot of the people that I respect online are open about who they are (whether that was a conscious decision or not).
My name is fairly unique, in that if you type it into your favourite search engine, you would get results relating to only me.
I've been trying to decide on this for a few months now, and in the mean time doing neither, so I have given myself one week from today to decide either way, then just stick with it and get some stuff out there.
I would be interested to hear if anyone else has thought through this sort of thing for themselves, or has any pointers/thoughts on the pros and cons of either side. Or am I just over-thinking the whole "online privacy" issue? <comment><USER2> I'm somewhere in-between. I use a nickname (HedgeMage) because it is easy for people to remember, and more commonly available than my very common real name (Susan Stewart). Additionally, since some of my work is under my maiden name, and some under my married name, it simplifies things to tell people "just google for 'HedgeMage'".

Anyone who can operate a search engine will quickly link my nickname to at least one of my names (maiden/married). That's a good thing. However, there _are_ situations where it's worked in my favor that it took a few minutes for $random_irc_person to realize that I'm female.

I happen to work in a field where eccentricity seems expected (web development), so it's never been a negative as far as I know.

</comment><comment><USER3> Two anecdotes in favour of using a nom de plume:

1) Some time ago, I decided to use my real name on the web, to build my professional presence. I wasn't quite unique, but any results that came up for a search on my name were pretty inconsequential. Since I made that decision, two more prominent people with the same name have come to the fore. One of whom operates in a fairly close field to my own, and the other is a film actor. This makes it very difficult to build a personal brand. If you search for my real name online, you get pages and pages of the actor. If you add a bit more context, you get the other guy first, and eventually you might find me, but you'd have to know quite a bit about us to be able to differentiate, and I know I've. If I had a sensible nom de plume, I would not have had this problem. Another mitigation would have been to try to build my personal brand a bit more aggressively at the start.

2) Before I signed up here, I started working for an organisation that requires me to explicitly dissociate my personal web activity from any activity I might undertake in the name of my employer (i.e. my opinions are my own, and do not represent...). If I'd had the account here before then, linked to my profiles elsewhere, then I'd have to add that kind of guff to my profile here. Personally, I think that making it unlikely that anyone would link what I say here to my employer is better than explicitly highlighting that I don't speak for my employer.

</comment><comment><USER4> I like both, it depends what your purpose is. Think about it think way: TRUMP & Apple & Microsoft & George Bush.

I call Microsoft for help. I call Apple for help. I call Bush for help. I call Trump for help. None of these seem out of the ordinary.

The good thing about using a fictional name is you don't have to be the only one behind the name. You can create a brand or a group around it.

</comment><comment><USER5> a pesudonym is somewhat unprofessional. I mean, certainly, if you are good enough, nobody cares, but for technical stuff? it's probably in your interest to publish cool stuff under your real name.

Now, at least for me, the times I embarrass myself I am talking about personal stuff or about politics. Using a pseudonym for that sort of thing is completely reasonable. I think "would I want this on my long-form resume?" is a good question to ask before posting something under your real name.

Generally, I think, technical mistakes are forgiven, especially if you admit or point out your mistake. There isn't much danger, I think, to coding using your real name.

<comment><USER6> embarrass myself how?

<comment><USER5> I mean writing things I'd rather not have on my permanent record. E.g. an overly emotional and poorly thought out political manifesto, or giving personal details that people I work with might consider 'too much information' or "overshare"

Especially for the latter, a pseudonym seems polite. I mean, you need to be aware that if someone /really/ wants to find out, they will. But using a pseudonym, I think, is a polite way to separate your personal life from your professional life.

<comment><USER6> Yea, I know. Here is one article on it: [http://www.channelvmedia.com/blog/office-oversharing- social-...](http://www.channelvmedia.com/blog/office-oversharing-social- media%E2%80%99s-role-in-defining-the-corporate-culture-of-the-future/)

<comment><USER5> eh, I dono. I've heard people complaining, e.g. that they didn't really want to know of the sexual proclivities of their co-workers.

I think it's completely reasonable that this isn't the first thing you find out about your co-workers.

<comment><USER6> Sex, yea you have to be careful.

</comment></comment></comment></comment></comment></comment><comment><USER7> I mostly go by Michele online, which is my legal middle name and the name I use socially ("Michele" was taken when I tried to sign up for HN or that would be my handle here). I used to go by my first name and last name online, both of which are uncommon so I am in the same situation you are in. I stopped doing that in part because no one could ever spell or pronounce my name and I thought my more common middle name would make things easier in that regard. It really hasn't. For now, I persist in part because I currently have a job with BigCo and if you google my first name and last name, you find zilch about me in spite of how much personal info is plastered all over the web about me. So it does provide some separation between my IRL life and my online life. At some point, I imagine that separation will disappear, whether I want it to or not. I'm okay with that.</comment>


Ask HN: Thesis writing – LaTeX vs. word - <AUTHOR> I am in the process of writing my thesis, which has moderate mathematical content. I am most comfortable writing these kind of documents in LaTeX. However, my supervisor (who is less technical) is in favour of word. The ability to track changes, plus his familiarity with the program, are the important factors.<p>Does anyone know of any way to reliably convert latex documents into word? Or some other solution? <comment><USER2> Have a look at pandoc.

And you should definitively go for LaTeX</comment>


First Impressions Using React Native - <AUTHOR> http://jlongster.com/First-Impressions-using-React-Native <comment><USER2> I think it's a very strong point that moving script code off the main thread can help achieve smooth UIs. No more GC pauses, no more slowdowns if the JS engine hits a snag, etc.

I think this is actually possible on the web as well. Someone could write a UI framework which runs JS in a Worker, and sends messages to the main thread, on which there is HTML and minimal JS to receive the messages and handle them.

I'm surprised this hasn't been done, or has it and I just haven't heard about it?

If you're worried about the overhead of transferring lots of messages from the Worker to the main thread, I think it can be pretty fast actually. I did an experiment with proxying WebGL that way, which is a fairly high-traffic API, with nice results,

[https://blog.mozilla.org/research/2014/07/22/webgl-in-web- wo...](https://blog.mozilla.org/research/2014/07/22/webgl-in-web-workers- today-and-faster-than-expected/)

For something rendering a UI, message passing overhead should be reasonable, especially if the framework is smart enough to only send over what changes (like React Native does).

<comment><AUTHOR> You are speaking my language! I would _love_ to see a prototype of this. I've been thinking about it since I saw React Native.

I wonder if there's even value in something like an asm.js-compiled layout system, which absolutely positions elements. One of the insights of React Native is that to build apps, we really only need a small subset of the web's layout algorithms. Only flexbox, really. So if we recognize this subset, and remove everything else, there main thread can focus on really smooth performance.

React Native even performs the flexbox layout on a 3rd thread, and tells the main thread where to absolutely position stuff.

Obviously we want to re-use as much of HTML as we can, but there might be some crazy ways to remove stuff from the main thread.

EDIT: It should be noted that Mercury, a React-inspired library ([https://github.com/Raynos/mercury](https://github.com/Raynos/mercury)), has examples of running in a web worker. It is pretty cool, but I think it needs to be fleshed out more.

<comment><USER3> We explored this at a previous company I worked at. The conclusion at the time was that the message passing model was not yet efficient enough at the time because of serialization/deserialization which nullified any performance gains. Transferrable objects at the time were really new. If the support for shared memory has improved, it might now make sense.

The biggest problems with performance are:

\- GC pauses

\- triggering reflow

\- marshalling data across interfaces (serialization/deserialization of native types into strings and back again).

That last one is an absolute killer when it comes to applying 3D matrix transforms. Basically, you're taking an array of floats, serializing them into a string to do an element.style property assignment, so that the browser can then take that stringified representation and convert it back into an array of floats that it can apply. Huge perf hit here.

<comment><USER4> I haven't found serialization to be _anywhere near_ the bottleneck. How long does it take to serialize/deserialize a 16 element array? I could see how this would be an issue if you had hundreds of them per frame. But for most purposes an entire 16 element array is overkill and you could probably come up with a more compressed description of the transforms (scale, rotate, translate) and consider adding a pooling layer.

People attribute pauses to GC, when it's sometimes just the browser container environment acting up and there's nothing we can do about it - so it's easy to write it off as GC. Not sure about today, but 1.5 years ago (i = new Image(), i.src="http...") could block the JS thread for as much as 19ms. In a larger app, it's easy to write that off as GC, but (at least on iOS) the performance tooling is really lacking and it's tough to find the culprit.

Reflowing is a big deal, I agree.

<comment><USER3> Basically if you want to prevent reflowing you end up making everything a texture and that leads you to making many many CSS transform changes on every frame. 60fps is easy to hit on a modern desktop, but mobile performance requires more effort to achieve an effect that feels natural. The problem with the marshalling is that it is comparatively expensive and a blocking operation, which is not conducive to buttery smooth graphics performance on all platforms.

</comment></comment></comment></comment></comment><comment><USER5> > "This is _solid engineering_. And it completely reinforces the fact that > _React.js is the right way_ to build apps."

This just comes off as really weird to me. Why would any sane developer make a statement like this? It sounds preachy and brainwash-y and weird. If there's anything we learn as developers it's that there never is and never will be a single "right way" to do everything. Reading stuff like this makes me doubt the entire article.

There's a difference between writing objectively about something that's interesting that you enjoyed, and trying to lay down a dogma. TBH, the more of this article I read, the more my view of it's goals swayed towards the latter.

<comment><USER6> I like having opinions. People can disagree with them, of course, as has always been the case.

<comment><USER5> Look up the definition of the word "opinion" on google or a dictionary. Then look up the word "dogma". Then re-read my comment. Fair? It's not the opinion I'm objected to, it's the way of stating it.

<comment><USER6> You're really just complaining about the phrasing of it and saying that it should have been worded in a mealy-mouthed way. That's silly, it's just an expression of an opinion.

<comment><USER5> This is absurd. Are you serious? The way you express your opinions is enormously important. It could easily be the difference between getting a raise and getting fired. Expressing your opinions in a way makes sense to other people and they take well to is the farthest thing from silly ever, it's like a #1 essential skill for life. On top of that, phrasing informs the message, and in this case I was not just complaining about the phrasing, I was also complaining about the outrageous statement being made.

For example, saying "React is the best way to build all apps no matter what" vs. saying "Compared to building native UIs with objective C, react-native made for a much smoother experience for me because of X Y and Z" are not only phrased differently, they are communicating different things. The first one is an absurd overarching dogma declaring every other app-building technology to be inferior to react with no backing whatsoever, and the second one is a useful and specific analysis of react in one situation compared to an alternative.

I can't figure out if you're trolling or not, honestly.

<comment><USER7> > React is the best way to build all apps _no matter what_

When you alter a quote, you're only illustrating your own bias, not that of the author.

</comment></comment></comment></comment></comment></comment><comment><USER8> Declarative UI is boss.

I know Andy (former UIKit team) was quoted in the intro thread but I'll do it again:

 _> I say with confidence as a former UIKit author: React's model for the UI layer is vastly better than UIKit's. React Native is a huge deal._

[https://twitter.com/andy_matuschak/status/560511204867575808](https://twitter.com/andy_matuschak/status/560511204867575808)

If you're averse to React because of JSX, "mixing templates and views" and similar superficial "best practices", you're missing out. Engineers embracing React are not dumb. You should consider a possibility that they think it's good for a reason, and that reason is something you should learn about instead of armchair-rejecting it.

Try tuning out your inner rule-of-thumb linter for a weekend and really give it a try.

<comment><USER9> It's too bad that you can't separate virtual dom, the innovative part of React, from the rest of React which has its warts. They should receive credit for coming up with the idea, but there are better, more reactive frameworks using virtual doms now. React shouldn't win simply because they were first and have a big company behind them.

<comment><USER10> You can: [https://www.npmjs.com/package/virtual- dom](https://www.npmjs.com/package/virtual-dom)

You should also check out Mithril: [https://www.npmjs.com/package/mithril](https://www.npmjs.com/package/mithril)

<comment><USER9> I'm aware of these. But React gets all of the attention despite its warts like local component state or encouraging singletons for Flux.

<comment><USER3> And those singletons will bite you hard the moment you try to do server-side rendering because you will now have state shared across sessions.

The approach that raynos/mercury takes where state is fully decoupled from layout/rendering is the way to go. In mercury, all the render functions are composed together to make one large pure function. You give it the current state and it deterministically will always render the same layout. So much better than the react approach. Furthermore, the complete decoupling from the rendering functions and the reliance on using bijective lenses with shallow copying means you get time travel debugging for free (i.e. undo redo is available right out of the box)

[https://github.com/Raynos/mercury](https://github.com/Raynos/mercury)

<comment><USER11> I discovered React after using Om, and I believe that Mercury comes with a lot of good practices enabled by default. But it's technically possible to achieve the exact same 'decoupled-state-pure-shallow-etc' using React. It's just not turned on by default and some additional boilerplate is needed, so it's harder to achieve this in React. The only reason I use React instead of Mercury is that React is battle-tested. No amount of testing can replace the real-world situations.I choose a path of higher resistance because I trust React most (due to it's popularity and usage), even though Mercury is better in theory. Ultimately it's a pattern, and that pattern is associated with a level of abstraction over the DOM as well as the way we write code. Mercury and React are two examples of this. I would like to see more competition and libraries to choose from, modular DOM abstractions, with declarative UI's and alternative API's and jsx-esc transforms. That'd be awesome IMO.

</comment></comment></comment></comment></comment></comment><comment><USER12> Seriously please stop making assumptions on Titanium without knowing a thing about it.

> With the latter, you're also interfacing directly with native objects all > the time, which is doomed to fail performance-wise. React Native actually > performs the layout on a separate thread [...]

Wrong. With Titanium you work with proxies. And JS is in a separate thread. The only actual difference between ReactNative and Titanium on this side is the functional/fully-declarative/almost-stateless vs imperative DOM-like philosophy.

Let me slip this through: «if you don't know something then don't make it look like you do».

Sorry for the rant. I'm just very upset from yet another post like this.

<comment><AUTHOR> I have a friend that uses Titanium a lot, so yes, I only know of it second hand.

The lack of a function/reactive componentized UI paradigm forces you to work with native objects (the views) a lot. React can optimize how much it touches the bridge because you don't interface directly with the UI. From what I've seen, Titanium can't do nearly as good of a job as that because it's like the DOM. You touch the UI in several places and it needs to always talk across the bridge.

I never said it doesn't run JS on a separate thread. React performs _layout_ on a separate thread, providing the flexbox layout algorithm.

EDIT: It's all of these little details that can make or break something like this.

<comment><USER12> For sure there's this «don't cross the bridge» paradigm in the community, yet I've never actually experienced this issue. In our biggest app, an SFA that grew other time in a big fat ass app (project that I'm quitely waiting to chop in different pieces/apps) the kind of performance issues we found we're related to managing tableviews of… 20'000 rows! And then we switched to dynamically loaded listviews and boom. No perf issues at all.

</comment></comment></comment><comment><USER13> I'm looking forward to desktop UIs also being supported by something like this -- e.g. native Windows, GTK+, and Cocoa widgets. Then we'd have a true framework for writing GUI apps that can share most of their code across the whole range of platforms, which would make me literally stand up and start singing right now. Lalalalalalala!

If you coupled this with conditional stuff around what kind of form factor you're on (screen size, etc.) you could design mobile first UIs that gracefully _enriched_ on a larger form factor. Lalalalalala!

I don't know of Facebook cares, but I WILL PAY FOR THIS! For a well-engineered modern platform that did all of the above I would pay thousands of dollars. So if the choice comes down to staying free and abandoning this effort vs. making it a profit center, please for the love of all that is holy take my money.

Really when you look at the labor costs of developing parallel UI efforts on many platforms, a cross-platform dev system that delivered a _high quality_ native-feeling experience across every major platform could be worth at least tens of thousands of dollars to millions of people.

<comment><USER14> yep agree 100%. i have been thinking a lot about high quality responsive hardware accelerated layouts myself and have actually been thinking and experimenting on how to make something like that on a primitive level with the technology at hand for making responsive apps.

I honestly believe you will be able to see something like that in the near future as device gapping technologies gain more momentum.

</comment></comment><comment><USER15> I love the concepts behind React, and I agree this is a huge deal...I just wish it weren't javascript. It is a terrible language, and the languages that compile to javascript are a poor substitute (bloated code sizes, interop issues, poor runtime performance, etc). For a framework that is all about state machines (a good thing! All UIs are state machines), I hate that there aren't better ways to model them in the language. I would kill to be able to do React in F# or OCaml.

<comment><USER16> > It is a terrible language

As Douglass Crockford says, JS is a great language with some terrible parts. I don't understand why some people can't get past that.

<comment><USER17> Well, then. What about the language should make me think "wow, this actually _is_ a great language"? And I mean the actual language itself, not the ecosystem around it.

<comment><USER18> With the exception of the bad parts that you have to remember to stay away from, it is a very simple language.

<comment><USER17> By definition, if I have to remember to stay away from the bad parts, it can't possibly be that simple.

</comment></comment></comment></comment></comment><comment><USER19> Sounds amazing... What are the challenges, limitations, and tradeoffs for using React Native? There have been similar initial reviews of Titanium, Phonegap, and Xamarin, but in my experience they all have serious issues that make native development a better option in most cases.

<comment><AUTHOR> There's always going to be the big drawback of working in a separate VM (JavaScript) rather than directly accessing native APIs. But React is taking advantage of that as much as possible, making it easy to refresh everything and allowing you bring everything you knew about React.js over.

But if you want to access an API, you still need to wrap it. Depending on the API, you need to be careful performance-wise. Native React avoids a ton of problems that other frameworks have though because they provide a solid mechanism for dynamically working with UIs, and it's very efficient because they only send minimal diffs across the bridge.

</comment></comment><comment><USER20> Probably the most useful way to get a read on this is to compare it to Titanium, also a JS-to-native framework that runs JS on a separate thread. The biggest problems with Titanium were not performance. A couple of the most common complaints:

1) You don't have full access to native SDK functionality (e.g. all the latest cool things in iOS8). You're going through a cross-platform API wrapper and limited to the choices of the framework architect. So it can be frustrating to go down this path only to find you still can't quite get the native experience you want.

2) Debugging is harder because the native toolchain (e.g. Xcode) doesn't understand the framework. You have to rely on tools provided by the framework.

AFAICS the author doesn't address these issues. He seems to focus largely on the (theoretical?) performance optimization of not crossing the JS-to-native bridge as much in React... by being even more isolated from the native APIs and doing more work in JS. But even if true, performance was not the chief complaint with the closest predecessor to this.

<comment><AUTHOR> They are working on web-like APIs so you don't have to necessarily deal with the native platform for basic stuff like file/network access, etc. For more advanced stuff it's super simple to make your own wrapper. But yes, this is a constant downside to anything like this (only thing to compare is how difficult it is to wrap, and they aren't done with that part yet).

For #2, there's actually a great story. You can literally run the JavaScript inside an existing engine, like Chrome or Firefox, and serve it from there. You can use the normal devtools and set breakpoints on the JS.

</comment></comment><comment><USER21> > the mess of HTML and CSS get in the way of frameworks instead of helping > them

I totally understand where the author is coming from, and do agree... BUT there is a flip side to this, which is that HTML and CSS enable us to come up with and implement totally unique designs and interfaces. The lack of standard layout and complex "widgets" is definitely a pain in the ass, but it also enables a lot of unique-looking websites and designs. It's kind of a pet peeve of mine when platforms/CMS's try to output markup instead of just providing data to the view layer... they are always outputting the "best practice" (if lucky) at the time they were built, and then a year or two later you want to do things a different way and you're stuck.

So I'm super excited about React.js and love the simple mental model with flux etc., but another part of me also worries that one can't dictate the markup exactly the way one wants because it has to be recognizable to the virtual dom as well (or the iOS view in native, or whatever other front-end React will output to). Maybe someone with more React.js experience can enlighten me about this though? (I've only dabbled).

<comment><USER8> >one can't dictate the markup exactly the way one wants because it has to be recognizable to the virtual dom as well

I'm not sure what you mean. On the opposite, with React, you specify _exactly_ the DOM (or UIView) tree you want to get.

You will build different components for React web and React Native, there's no common ground between them. The platforms are too different.

<comment><USER21> I can't seem to find it now, but I remember seeing something a few months back about support for some HTML tag being added to react. I could be wrong about that, though (which would be great). I guess my question is this: can React/JSX render _any_ kind of well-formed arbitrary markup? Like if next week there is a <doohickey> html tag I want to use, will it work? Or would react have to be updated to "support it" somehow?

<comment><USER8> _> I remember seeing something a few months back about support for some HTML tag being added to react._

It's just due to React <=0.12 using an HTML tag whitelist to tell native tags from custom components. It's not an issue anymore in 0.13, where any HTML tag (including custom Web Components) will work: [https://github.com/facebook/react/pull/2830](https://github.com/facebook/react/pull/2830)

There's still an attribute whitelist, and that's a trickier problem to solve: [https://github.com/facebook/react/issues/140](https://github.com/facebook/react/issues/140)

<comment><USER21> Ah, that makes sense. Thanks!

</comment></comment></comment></comment></comment><comment><USER22> I get this weird feeling that React Native has been created as a stand-in until webview is truly ready to take over mobile. I can't imagine a scenario where by end of 2015 (or early 2016) mobile webview technology won't be sufficient for 99% of mobile apps.

</comment><comment><USER23> So if this is native widgets etc., the main point is being able to write this in JavaScript, right? Anything in it for those who don't consider this inherently beneficial?

Souns a lot like GWT, s/Enterprise "architects"/Web "ninja"/ to me.

<comment><USER24> It's not about "Write once, run everywhere" but rather about "Learn once, write everywhere". React-Native encourages better design patterns for UI, especially on iOS.

This blog post summed it up perfectly for me: [https://joshaber.github.io/2015/01/30/why-react-native- matte...](https://joshaber.github.io/2015/01/30/why-react-native-matters/)

<comment><USER23> I don't get the "better design pattern" from that. And even worse, adding yet another piece on top of the stack (a "better language" transpiling to JS) instead of just doing "react" in the native environment?

<comment><USER24> Doing "react" in the native environment is hard, you have to fight UIKit really hard to get to a good place.

[ReactiveCocoaLayout]([https://github.com/ReactiveCocoa/ReactiveCocoaLayout](https://github.com/ReactiveCocoa/ReactiveCocoaLayout)) is a good example of how much work it takes to get close to this pattern, but the view lifecycle as a whole (adding and removing subviews, layout passes, etc.) makes it hard.

From what I understand React-Native does this for you natively under-the-hood, but using JS as an implementation detail.

I really don't think that anyone is advocating for JS being the "better language", but rather one that has a framework (read: React.js) being used in practice which will work with native view as well.

</comment></comment></comment></comment><comment><USER25> OK, so how long before we backport the Android UI toolkit to WebGL using GWT and get rid of HTML and CSS altogether? Or even just write a sane new one?

Very interesting that this stuff comes from Facebook, who have very little concern about being indexable by search engines.

<comment><USER26> And yet React for Web browsers is the first framework in its class to do server-side rendering out of the box... a feature Facebook doesn't even use. Pretty funny.

</comment></comment><comment><USER27> The code style really reminds me of ExtJS circa 2.x (not sure what it's like now), which was pretty good at what it set out to do. However, React Native requires compiling down to various different platforms which means having to maintain multiple compatibility layers to continually shift to keep up with the native vendors. You're also pretty much stuck with proprietary distributors as well. Fun. Fun.

This does look interesting, but honestly, I think this can either already, or very soon, be replicated on the web, a platform which holds tremendous advantages that native will likely never be able to catch up to. Perhaps there's an argument that these apps can also be translated to the web when their time comes, but I wonder what sacrifices are being made in the name of going Native?

React Native seems to be an attempt to fight in the opposite direction (Web -> native) while the real momentum is going the other way (native -> Web), and the best part is, you don't even have to do anything to get it, the major players are building that open ecosystem for us.

<comment><USER28> I agree with the "swimming the wrong way" sentiment, in my own very biased opinion. I'm working on reapp.io to solve just that. What's funny is react actually makes it possible to make hybrid a real option.

<comment><USER27> That looks pretty interesting. Are there any plans to support responsive designs? What I really need (don't we all?) is a unified desktop & mobile code base.

</comment></comment></comment><comment><USER29> As someone who has developed many apps using Appcelerator Titanium, I am looking forward to getting my hands on this to see where the differences lie.

I know that it has taken Titanium years to mature, so I wonder if it will take a similar amount for React to iron out the bugs - I'll be surprised / pleased if they hit the ground running.

Hopefully they'll hurry up and make it public!

</comment><comment><USER30> I'm assuming React Native can load external JS files over the network? If that's the case, then I understand why Facebook is building this.

They could have control of their application and behavior and make even more changes than before without re-submitting to the App Store.

<comment><USER31> Except, you know, the App Store rules explicitly forbid downloading new code over the network.

<comment><USER26> _Unless it 's JavaScript._

...running in a WebView. So yes, RN apps will not enable this.

</comment></comment></comment><comment><USER32>
        "React Native actually performs the layout on
         a separate thread, so the main thread is as free
         as it can possibly be to focus on smooth animations
         (it also provides flexbox for layout,
         which something that no other framework provides)"

Interestingly - though perhaps increasingly less relevant - this is how BlackBerry 10 platform native QML-based applications work as well.

</comment><comment><USER33> I can't help but feel that all this energy would be better spent on improving webkit itself (such as running JS in a separate thread to the UI)

</comment><comment><USER34> For me the best of the web has always been HTML & CSS which I miss so often when dealing with native widgets or creating my own. The only thing that used to scare me off the web was JavaScript. Give me a HTML & CSS frontend, please. But let me keep my beloved Scala or Swift ;)

</comment><comment><USER6> I'm still very excited to try it. I agree that this is the way forward for writing apps. I have attempted to write iOS apps before, and the problem is not objc, I actually kinda like objc. The problem is the damn view layer.

</comment><comment><USER35> Didn't we do this already with Qt? Or Java? Or wxWidgets? Or OpenGL? Seems like cross-platform UIs have been a reality for quite some time.

What does React bring to the table that these do not?

<comment><USER36> Isn't it just the specific platforms you can target? I think the point is that there's nothing that can target the browser and the phone this successfully.

</comment></comment><comment><USER37> Wonder if the ability to easily refresh the view will make a difference to ios dev used to the wysiwyg approach by xcode for building views.

</comment><comment><USER3> This is yet another reason why you shouldn't use animations in CSS3 and should do them in JavaScript. I honestly don't understand how behavior (which is what animations are) got baked into a declarative style language.

Layout (which is also behavior if the layout changes with the dimensions of the viewport) and animations are two things that need to be removed from CSS and implemented in JavaScript.

<comment><USER38> Well, "should" isn't a great word in this context.

Yes, animations probably _should_ be in JavaScript, but you probably _shouldn 't_ do them in JavaScript right now as they won't be hardware accelerated. The reason it works well in CSS is that you're setting a property and letting native code do the rest, whereas in JS you need to set a property in each requestAnimationFrame() call. Not good.

</comment></comment><comment><USER14> sounds interesting. not a fan on reacts workflow because i use jade templates w/ backbone that get compiled to html for me and its much less code, but separating javascript and native components into different threads is a great idea.

i believe we should be able to see javascript being used as a responsive language portable across all devices and being used to control native components as a separate layer.

im actually working with a flexbox xml/html wrapper framework for iscroll that i might use to build a responsive app that not only does pc animations but performs alot of nice mobile slider animations that seem to go at 60 fps on modern handhelds, but its up to emerging gapping technologies like cordova and this to make the use of future "responsive ui kits" which i believe should be emerging soon.

</comment><comment><USER39> Soooo... Strap a code editor component on the front and call it Hypercard 9000?

</comment><comment><USER40> Do a Ctrl + F, then type "android". How many matches have you seen amongst 122+ comments? 2, including this one!

</comment><comment><USER41> This made me think differently => JS can be used as a control layer and the native components are the data layer.

</comment><comment><USER42> Why not Titanium?

</comment><comment><USER43> Will React's concepts every make it as truly native code I wonder?

</comment><comment><USER44> OK this DOM stuff is great but what about the other HTML5 interfaces, like sending requests to the server, localStorage, etc. ?

<comment><USER45> There is an API-compatible XMLHTTPRequest so all libs that have those deps (Backbone) work.

There is also localStorage (not in this release though), but it's not 100% compatible because it has an async API.

<comment><USER46> Is the localStorage going to be something similar to IndexedDB (or localForage perhaps?)

<comment><USER45> When I was at FB it was just getItem() and setItem() with a callback. The Relay stuff announced at React.js Conf is closer to what you're talking about (they run a local GraphQL engine which reconciles with the remote one iirc)</comment></comment></comment></comment>