The most accurate map for August 21's total solar eclipse - <AUTHOR> https://nasaviz.gsfc.nasa.gov/12458 <comment><USER2> Best advice I've accumulated so far:

1\. Don't plan to drive anywhere on eclipse day (90% of the US lives within an 8hr drive of totality, so traffic will be horrible)

2\. A 600-800mm lens is optimal for photography. Anything short of 200mm is useless.

3\. Don't make any solid plans until 3-4 days before. Most places only have about 40% chance of it being clear.

4\. If you're photographing the partial phases. Stop and check everything (batteries, memory card, focus, etc) about 5 min before totality.

5\. If you have any technological issues during totality, just sit back and enjoy watching it.

6\. On eclipse day, if you're in a place that has 2 min or more of totality, just stay there. There's not a lot to be gained by risking moving.

7\. All across the US, the sun will be high in the sky, good horizons aren't necessary.

<comment><USER3>
      90% of the US lives within an 8hr drive of totality, so traffic will be horrible

Oh, come on. Less than 5% of America actually cares enough about astronomical events to drive 30 minutes to see something. Much less book a hotel stay.

August 21st is a Monday afternoon, so how many employed Americans are going to ask for the day off, to drive 8 hours, with a 200mm telephoto lens or telescope?

If totality is the size of several counties, and lasts even ten minutes, how many people will be on the road within an hour of the event? Lunchtime (or even all day long) traffic is probably nothing even terrible in 40 out of 50 states. In totality states, traffic won't even compare to a sporting event.

<comment><USER4> Totality lasts ~2 minutes

<comment><USER3> You are correct, sir. And thinking about OP's statement a little more, maybe staying off the road is a good idea in the sense that a two minute eclipse can distract drivers on the road.

But in general, unless you happen to glance at the sun in your field of view during the eclipse, it's all the darkness of passing clouds for most of the country.

Are traffic accidents statistically affected by proximity to a total eclipse of the sun?

</comment></comment></comment></comment><comment><USER5> Can someone explain why the claimed shadow of the moon is vastly more bumpy than it ever appears in the night sky? Or how to square this with the fact that altitude of the highest and lowest points on the Moon differ by less than 20km, or less than 1% of the diameter? The shadow looks like it has bumps of about 5-10% of the diameter.

<comment><USER6> The diameter of the path of totality is only about 100 miles, because it's only the umbra of the shadow. This is 20x smaller than the moon diameter. But, a 1km moon bump is a 1km bump on the umbra as well, magnifying it's effect by the mentioned 20x and leading to a much different appearance.

<comment><USER5> I hadn't thought about this effect! You're absolutely right. Thanks very much.

(For others:) A diagram of the umbra makes this clear:

[https://c.tadst.com/gfx/750x500/total-solar-eclipse- com.png?...](https://c.tadst.com/gfx/750x500/total-solar-eclipse-com.png?1)

If you draw a few triangles, you can get an analytic expression.

</comment></comment></comment><comment><USER7> If you want to experience the greatest duration plan a trip to Southern Illinois (more info about duration here: [https://www.greatamericaneclipse.com/illinois/](https://www.greatamericaneclipse.com/illinois/)).

As a bonus a friend of mine's family winery has booked Ozzy to "bark at the moon" during the eclipse: [http://loudwire.com/ozzy-osbourne-headlining- moonstock-solar...](http://loudwire.com/ozzy-osbourne-headlining-moonstock- solar-eclipse-festival/)

<comment><USER8> Most of the Carbondale area was booked solid months ago. There may be some campsites open but not much else.

I'm staying in St Louis the night before and then picking a direction to drive based on weather. I don't think it's worth all the hassle to get to southern Illinois just to get 3 more seconds of totality.

This map will show you how much totality you can experience, unlike the NASA charts.

[http://xjubier.free.fr/en/site_pages/solar_eclipses/TSE_2017...](http://xjubier.free.fr/en/site_pages/solar_eclipses/TSE_2017_GoogleMapFull.html)

<comment><USER9> I'll be in St. Louis for this, too. I'm thinking about viewing it from here:

[https://mostateparks.com/event/64121/solar-eclipse- showdown](https://mostateparks.com/event/64121/solar-eclipse-showdown)

<comment><USER8> I've been trying to scout out some open areas away from civilization, mostly to avoid ambient light but also to avoid huge traffic in and out of any park or freeway interchange.

I fully anticipate traffic to be screwed up for hours afterward.

<comment><USER9> I could be totally wrong, but I just don't see it, at least not down there in Jefferson County. That's not a densely populated area. It's over an hour's drive from Downtown St. Louis. [0]

I have to say, though, I'll probably leave earlier that morning than I'd originally planned, because of the comments in this thread.

[0] [https://goo.gl/maps/bJRKJndLnQG2](https://goo.gl/maps/bJRKJndLnQG2)

</comment></comment></comment></comment></comment><comment><USER10> If you've never seen a total eclipse before and you live in the US, make every effort to see this one! It's not something that you can get the feel of by viewing photos or video. Watching the sun get eaten by a black void activates something deep inside the animal brain. Don't settle for a partial eclipse, do what it takes to get in the path of totality.

If you have seen a total eclipse before, then you don't need any convincing.

<comment><USER11> > Watching the sun get eaten by a black void activates something deep inside > the animal brain.

I was planning to have my 5 year old son see it. But now I wonder whether it will have any traumatic effect on him.

<comment><USER12> You would seriously let your son miss this because of some hypothetical traumatic event that might happen? I feel really bad for him if that's the case.

<comment><USER13> I don't think you worded this very well (which is probably why you're getting down votes), but I agree with your sentiment. This is 100% not something you should shield children from in my opinion - it's a very rare opportunity to see something quite magical - even when you know exactly what's going on.

</comment></comment></comment></comment><comment><USER14> Here are my viewing tips, based on my experience in the 1979 eclipse in Oregon.

You can photograph the eclipse, but you will have a much grander experience if you don't try. Photography is just a distraction from the awesome spectacle of the eclipse, including the phenomena that happen on the ground.

There will be plenty of other people taking great photos, so enjoy those after the eclipse. A total eclipse, viewed directly with your own eyes, is truly an experience of a lifetime. No photograph comes close.

Contrary to one or two other comments, eye protection is not necessary _during totality_ and will prevent you from seeing the full beauty of the corona. It is perfectly safe to view the _total_ eclipse with the naked eye, or even with binoculars. Only the partial phases need eye protection (and they definitely do). [1] [2] [3]

In fact, on the hillside we ended up at, something interesting happened. Most of the people wore dark sunglasses and faced _away_ from the sun during the first partial phase, in order to get their eyes a bit acclimated to the dark. The partial eclipse isn't very interesting compared to totality, and the fun stuff at that point is happening on the ground: there are ripples of light dancing on the ground like you see on the bottom of a shallow stream. And you may get to see the shadow rushing toward you at 10,000 miles an hour!

The moment it reached totality, there were shouts of "it's total!" up and down the hill. Everyone took off their sunglasses and looked directly at the total eclipse. Many of us brought binoculars and viewed the corona with them.

The danger is that it is tempting to keep looking at the end of totality, when the string of beads starts to appear at the edge of the moon (where the sun is starting to peek through the moon's valleys), and finally the "diamond ring" where a larger part of the sun appears through the deepest valley. If you bring proper eye protection, switch to it the moment the string of beads appear, and definitely before the diamond ring appears! I recommend doing this after totality and not before, so you don't interfere with your eyes' dark adaptation before totality.

[1] [https://eclipse.gsfc.nasa.gov/SEhelp/safety.html](https://eclipse.gsfc.nasa.gov/SEhelp/safety.html)

[2] [https://eclipse.aas.org/resources/telescopes- binoculars](https://eclipse.aas.org/resources/telescopes-binoculars)

[3] [http://www.eclipse2017.org/2017/what_you_see.htm](http://www.eclipse2017.org/2017/what_you_see.htm)

<comment><USER15> > Except during totality, when the Sun's bright face is completely blocked by > the Moon, it is never safe to look directly at the Sun through a telescope > or binoculars. During the partial phases of the eclipse, you must secure a > special-purpose solar filter over the front of your optics before aiming at > the Sun.

That's a quote from one of the links. Most people will not be in totality. Most people will only be seeing a partial eclipse. The shaded in line from this [1] image is where totality will happen.

Most people watching the eclipse will need some form of eye wear.

[1] - [https://nasaviz.gsfc.nasa.gov/vis/a010000/a012400/a012458/us...](https://nasaviz.gsfc.nasa.gov/vis/a010000/a012400/a012458/usa_eclipse_map_16x9_1920x1080_1024x576.jpg)

<comment><USER14> Yes, my comment was addressed specifically to those who will be viewing the total eclipse, not the partial eclipse. That's why I emphasized _total eclipse_ and _totality_.

But thank you for making it more clear that viewing any other kind of eclipse - partial or annular - requires proper eye protection!

</comment></comment></comment><comment><USER16> Smarter Every Day just posted a great video related to this:

> HOW TO WATCH THE ECLIPSE (AND SHADOW SNAKES) - Smarter Every Day 171

[https://www.youtube.com/watch?v=qc7MfcKF1-s](https://www.youtube.com/watch?v=qc7MfcKF1-s)

<comment><USER17> I'm hoping the masses take to capturing high definition footage of the shadow snakes. Someone, somewhere will be able to get decent footage hopefully.

</comment></comment><comment><USER18> What about the rest of the world!!

<comment><USER19> This eclipse will only be visible in totality within the US. Here's a broader- scale map:

[http://xjubier.free.fr/en/site_pages/solar_eclipses/TSE_2017...](http://xjubier.free.fr/en/site_pages/solar_eclipses/TSE_2017_GoogleMapFull.html)

<comment><USER8> This map is way more useful than NASA's. Highly recommended.

</comment></comment></comment><comment><USER20> Some tips for photographing it: [http://www.nikonusa.com/en/learn-and- explore/a/tips-and-tech...](http://www.nikonusa.com/en/learn-and- explore/a/tips-and-techniques/how-to-photograph-a-solar-eclipse.html)

Solar filters: [https://www.bhphotovideo.com/c/buy/solar-photography- filters...](https://www.bhphotovideo.com/c/buy/solar-photography- filters/ci/34576/N/3537148334)

<comment><USER21> Won't it just be.. black?

<comment><USER22> It will if you don't pop off the solar filter during the totality! I'm planning on practicing with the solar timer app mentioned by Smarter Every Day; I'm not moving anywhere since I'm in the path of totality (for 1:16!), so I want to make sure I have all the timing down for the little transitional bits, so I can gun off a dozen or so pictures at any of those moments.

I'll also have a timelapse camera set up on a wider angle (incorporating my yard, some trees, the sky, etc.) using pi-timelapse[1]

[1] [https://github.com/geerlingguy/pi- timelapse](https://github.com/geerlingguy/pi-timelapse)

</comment></comment></comment><comment><USER23> I heard from a co-worker who plans to travel to Oregon that some of the hotel rooms in the path of the umbra are sometimes > 2-3k USD for the night(s) prior to the eclipse.

<comment><USER24> I think Oregon is a bad spot to view it. The weather (yes, even in summer) is too unpredictable and it's too close to populated coastal areas.

Wyoming is the way to go, or western Nebraska. Don't expect to get hotels, but camping on a rancher's land is easy, and the arid climate in the summer minimizes chances of cloud cover.

<comment><USER25> _> , or western Nebraska._

I'll be in eastern Nebraska (Omaha) and will drive south on I-80 towards the eclipse path and hopefully pull off to the side and park somewhere.

What's hard to plan for is whether too many other Nebraskans will have the exact same idea which means I have to camp out a ridiculous 12 hours before the event to secure a spot -- or give up entirely.

<comment><USER26> I'm planning to drive up north from Denver, the day of. Kind of concerned about how many people will have the same idea, and how early I should start...

<comment><USER24> I'm in Denver area too. The question is this:

How much better is a 100% eclipse vs. a 90% eclipse that we'll get here?

Is it worth the trip to Wyoming? I think so, but not positive.

<comment><USER27> According to everything I've read, and all pictures I've seen, 99% is one thing, and 100% totally something else.

</comment></comment></comment></comment></comment></comment><comment><USER28> I don't want to travel to this one if I can avoid it, and there seems to be none in Europe in my life time.

Will the April 2024 one be as good as this one? I suppose one drawback of that one is that april is probably(?) much larger risk of clouds in a lot of the US, than august?

[https://www.timeanddate.com/eclipse/list-total- solar.html](https://www.timeanddate.com/eclipse/list-total-solar.html)

</comment><comment><USER29> If you want a laugh, mute the audio track of the video on that page and play the Game of Thrones Main Title instead.

</comment><comment><USER15> Hello everyone. I'm currently working with a group who plans to do some experimental sounding of the effects of the eclipse on the ionosphere. If you want to learn more about this project please check out our website [http://hamsci.org/](http://hamsci.org/). We are pushing a number of fun ways to get involved with collecting very useful data for scientific analysis.

I'd like to ask anyone who lives on the midwest or east coast to consider helping these projects:

1\. EclipseMob: [http://hamsci.org/node/148](http://hamsci.org/node/148)

This project will ship you a set of ICs and a breadboard that will make up a VLF receiver. No soldering is required. It's a great kit to put together with children.

After you build up the kit you plug it into your phone's microphone jack and run an app that agregates radio signal information (I/Q data I think) to the EclipseMob organizers. After the eclipse is over you'll still be in possession of a fully capable VLF receiver kit. You can use it to listen to VLF signals that are interesting. This may include human generated traffic or whistlers.

2\. Total Eclipse SEQP: [http://hamsci.org/seqp](http://hamsci.org/seqp)

If you have an amateur radio license and want to help participate in a contest you can hop on the air and operate during the eclipse. The more people on the air the better dataset we have.

3\. Setup a Reverse Beacon Network receiver.

The main dataset we use is the Reverse Beacon Network. It's a set of automated receivers that listen to short-wave Morse code and RTTY communications. If you have a few bucks burning a hole in your pocket and want to set up a we have a page that talks about how to do this: [http://hamsci.org/cw-reverse-beacon- network-how-guide](http://hamsci.org/cw-reverse-beacon-network-how-guide)

Using these data sources we would like to generate a very high resolution picture of the effects of a solar eclipse. As it turns out we don't exactly have the best understanding of what goes on during an eclipse.

We have a few other projects in the works that I'm not very familiar with. One idea is recording I/Q data from JT65 bands and building a data set via Zenodo so that everyone who contributes to the data set gets their name as a reference on papers that use it.

If you're interested and want to hear more about this you can reply to this post or send me an email to my "work" email. My email username is jk369 and my university's mail address is njit.edu.

</comment><comment><USER30> Regarding weather, places that have clouds due to convection have a chance of clearing up during the eclipse. I experienced this in China in 2009 - completely overcast two hours before totality, clearing up just in time due to lower solar insolation and less convection.

You shouldn't count on this, try positioning for good weather in advance regardless, but just keep it in mind so you don't crash your car heading for better weather if things look poor.

</comment><comment><USER31> My first thought: how will this affect traffic.

I've been in Atlanta too long.

<comment><USER32> Me too.

We were going to make a weekend trip out of this. But we realized the chances of bad weather are pretty high at our planned viewing site in Western North Carolina and that it would be better to stay in Atlanta closer to an Interstate Highway so we can quickly drive to an alternate site.

<comment><USER33> It might be difficult to predict a clear sky. Because of hot, summer humidity, The eastern US has a pretty good chance of afternoon thunderstorms during the time of the eclipse.

</comment></comment></comment><comment><USER34> When was the last time an eclipse like this happened in the US ?

<comment><USER35> It depends what you mean by "like this."

The last US West Coast to US East Coast eclipse was 1918.

The last time the totality was entirely within the current US borders and never over land elsewhere was 1257.

[https://en.wikipedia.org/wiki/Solar_eclipse_of_August_21,_20...](https://en.wikipedia.org/wiki/Solar_eclipse_of_August_21,_2017)

</comment></comment><comment><USER36> Question for those who know more than I do about this. According to [0] the sun will be about 97% obscured at my house. Is it worth traveling for that last 3%?

0: [http://xjubier.free.fr/en/site_pages/solar_eclipses/TSE_2017...](http://xjubier.free.fr/en/site_pages/solar_eclipses/TSE_2017_GoogleMapFull.html)

<comment><USER37> I'm no expert, but YES!! Drive the miles to get to 100%. There is absolutely no comparison between 99% and 100%. They're just totally different beasts.

</comment></comment><comment><USER21> What do the black circles mean?

</comment><comment><USER38> Just wondering, how much is this going to cost into the loss of electricity generation from the Solar plants across US.

<comment><USER39> You should find this article interesting! [https://qz.com/973684/california- will-lose-enough-solar-ener...](https://qz.com/973684/california-will-lose- enough-solar-energy-to-power-los-angeles-during-the-eclipse-on-aug-21/)

</comment></comment><comment><USER40> Do you get the full eclipse effect anywhere inside of the green line? Is there an advantage to being at the red line?

<comment><USER41> The closer to the red line the longer you'll get totality. But anywhere in the green lines you'll have some period of totality.

The interactive map: [https://eclipse2017.nasa.gov/sites/default/files/interactive...](https://eclipse2017.nasa.gov/sites/default/files/interactive_map/index.html)

will tell you exactly when and for how long you'll get totality anywhere along the route.

<comment><USER40> Thanks! That is a much better map than original article.

</comment></comment></comment><comment><USER42> So what will be the practical difference between 99.4% (at my home) and 100% about 35 miles away. Is it worth the effort to travel to the true totality zone? I do unfortunately have a commitment that day, that I cannot avoid, about 2 hours before the max obscuration passes by.

<comment><USER43> 35 miles seems small enough to not worry about it - it's just a half hour drive! It's still months away, I'd hope you could reschedule that conflict.

I have several hundred miles if I wanted to go to the totality zone. But I'm still curious what it will look like in the difference of 100% vs 82% at my home.

<comment><USER44> Well, one difference is that if you go to where there is totality you can look with the naked eye once totality is achieved. If you are in a place where it is only partial, most experts recommend only looking through filters or via pinhole projection.

</comment></comment></comment><comment><USER45> What affect is this going to have on solar power? California has a load of solar going on, and this may cause a complete collapse in solar output very suddenly (way more suddenly than the evening). Can peaker plants come up quickly enough?

<comment><USER33> On a hot August summer day, LOTS of power will be lost. It's recommended to turn off your A.C. to help prevent blackouts and the prevent use of more expensive natural gas power.

[https://qz.com/973684/california-will-lose-enough-solar- ener...](https://qz.com/973684/california-will-lose-enough-solar-energy-to- power-los-angeles-during-the-eclipse-on-aug-21/)

</comment></comment><comment><USER46> Pretty cool that it's going to pass directly over Clemson, SC. Literally almost dead center. (2:53 mark of the path video).

</comment><comment><USER21> Are these safe to view? I thought these would be black. Another link talks about "getting eye protection"?

<comment><USER47> Eye protection is essential.

There was a total eclipse in Britain when I was a child [1], and everyone bought special protective glasses to wear.

Mine were like the paper red-green "3d" glasses you used to get, but with a black film that was close to opaque. They worked fine.

[1] [http://xjubier.free.fr/en/site_pages/solar_eclipses/TSE_1999...](http://xjubier.free.fr/en/site_pages/solar_eclipses/TSE_1999_GoogleMapFull.html) ("Britain" is exaggerating, but we were in Cornwall on holiday.)

</comment></comment><comment><USER48> * The most accurate map for Aug 21, 2017's total solar eclipse _for north America_ (nasa.gov)

</comment><comment><USER40> Why would they use a tif format for the downloadable map? I haven't seen a tif format in 10 years.

<comment><USER49> lossless format (potentially) that everyone can open?

<comment><USER40> After looking at the map, I can't imagine why a lossless format is required. I just exported in as a jpg, and it would take a magnifying glass to see the difference. And the jpg was 16/7% the size (at 90%). Waste of government bandwidth.

<comment><USER50> I'd imagine NASA's more concerned with pixel perfect reproductions than your average government agency, given the sort of imagery they're often working with.

</comment></comment></comment></comment><comment><USER51> Would love to hear how they generated the shadow contours from the Moon to the Earth's surface!

<comment><USER52> it's projection geometry. You create a geometry object with the earth's surface shape. Another with the moon's surface shape. Then, a light source that emits from a sun's shape. All objects are placed at the appropriate distances, and made to rotate and translate through space according to normal orbits.

Then, you project the light from the sun onto the earth, with the moon in- between. This creates the 2D shape on the earth's surface corresponding to the shadow.

I've set up something very similar to this in Blender, although its floating point precision was too low, so I had to fudge things a bit.

<comment><USER51> Thanks dehhn. From the LRO picture in the article, you can see that they're actually taking high-precision elevation maps of both the Moon and Earth into consideration, which sounds like something rather computationally intensive. I might be wrong, but I don't think they used Blender to handle that.

I would be curious to hear what tool they actually use, their pipeline, etc.

<comment><USER53> To the best of my knowledge, it was animated in Maya and rendered with Pixar's Renderman. When I was in that group, we used IDL to do any elaborate calculations needed, and then imported the data into Maya/Renderman. This is exactly what Hollywood does when they have to render a scene that requires a lot of simulation. I can ask Ernie if he used anything special for this production.

<comment><USER51> That's amazing, thanks so much. Ernie, if you're reading this, great job :)

</comment></comment></comment></comment></comment><comment><USER54> Times in UTC would be more helpful.

<comment><USER55> Not for an event where the total eclipse will only be visible in the continental US. The map in TFA changes timezones so that local time is always used. It's the same as flight schedules where takeoff and ETA are always represented in local time.</comment></comment>


Gabriel García Márquez's Archive Freely Available Online - <AUTHOR> https://www.nytimes.com/2017/12/11/arts/gabriel-garcia-marquez-archive-online.html <comment><USER2> Two of the greatest opening lines to books:

"Many years later, as he faced the firing squad, Colonel Aureliano Buendia was to remember that distant day when his father took him to discover ice." – One Hundred Years of Solitude

"It was inevitable. The scent of bitter almonds always reminded Dr. Juvenal Urbino of the fate of unrequited love." – Love in the Time of Cholera

Each is almost a story in itself, a pleasure to read, and an even greater pleasure to unpack and understand.

<comment><USER3> It's worth it to learn Spanish just to read his books.

<comment><USER4> I have been wondering about this — how much more enjoyable is it to read a book in it's original language, as opposed to just reading someone's translation? Or is it just the thought that you're able to read the original, as author intended — possibly after spending time to learn a language just to be able to do this — that makes it count?

<comment><USER5> A currently-popular literary theory (strongly espoused by Jorge Luis Borges, whose translation of Kafka's _Metamorphosis_ was highly influential to Marques) is that the translation of a literary work is, in fact, a brand new literary work authored by the translator. The fact that languages don't line up one-to-one, and the fact that language (and literature) is deeply entwined with culture, means that the translator has to make a lot of creative decisions when translating, and that the final product can never be a 'perfect' reproduction of the original text.

It's not necessarily about enjoyment, as it is about reading what the author wrote as opposed to what the translator wrote. But this also means that sometimes, the translated work is a good work in its own right and worth reading (Borges once said "The original is not faithful to the translation"). So, it really depends on a lot of things. But for Marques in particular, his works are very tied to Spanish culture so even as an outsider, learning Spanish and reading the originals still isn't quite the same as reading them as a Spaniard.

<comment><USER6> If you're interested in translation, you may want to check out _Why Translation Matters_ by Grossman, who translated _Love in the Time of Cholera_ among other things. I hadn't thought of translation as anything other than utilitarian and found Grossman's book enlightening. [https://yalebooks.yale.edu/book/9780300171303/why- translatio...](https://yalebooks.yale.edu/book/9780300171303/why-translation- matters)

</comment></comment></comment></comment></comment><comment><USER7> Interesting! He was last night's final Jeopardy:

In a 1967 novel this Nobel Prize winner wrote, "The secret of a good old age is simply an honorable pact with solitude"

</comment><comment><USER8> The irony here is how jealously Garcia Marquez guarded his private life, only to have it posted online in its entirety. When he learned that one of his friends had sold their correspondence to an American university (much like UT), he stopped writing to his friends altogether, and started calling them on the phone. For more background, his long interview, "The Fragrance of Guava", is a great read.

</comment><comment><USER9> So why do I have to go to a paywalled site to read about free online content? OP and NYT can both take a damn hike.

<comment><AUTHOR> It reads fine for me (but I'm using NoScript and Adblockers). You can access the Gabriel García Márquez archive at [1]

[1] [https://hrc.contentdm.oclc.org/digital/collection/p15878coll...](https://hrc.contentdm.oclc.org/digital/collection/p15878coll51/)</comment></comment>


Ask HN: What is the best way to organize internal communication? - <AUTHOR>

Internal communication in startups can be tricky. What is the best way to keep a good team communication? <comment><USER2> Yammer is doing well on this area. I have never tried it.

There is also Trello for tasks.

For organizing tasks/bugs/code you can go with Redmine/Bugzilla/Gitolite/Gerrit.</comment>


How Google Retooled Android With Help From Your Brain - <AUTHOR> http://www.wired.com/wiredenterprise/2013/02/android-neural-network/ <comment><USER2> General AI may become closer as Google plays with neural networks for Android.</comment>


Inferno: A fast, React-like JavaScript library for building UIs - <AUTHOR> https://github.com/trueadm/inferno <comment><USER3> At the risk of beating a dead horse, we are only fueling the flames of javascript fatigue by churning out these "It's like X, but with more/less cowbell" libraries. We need to stop fragmenting and start doubling down on existing libraries.

<comment><USER4> > we are only fueling the flames of javascript fatigue

The majority of people I have seen complaining about Javascript fatigue do it from the peanut gallery. If you are a Javascript developer: you shouldn't have javascript fatigue unless you chase after the latest and greatest - which you shouldn't do. If you do not experience have "cereal fatigue" at the supermarket, you shouldn't get Javascript fatigue either.

It took me all of 30 seconds to skim the home page and to conclude "hmm, I don't need this now", but I've filed it at the back of my mind should I require it some day (I might not remember the name then, but I'll be able to figure out the search keywords).

> We need to stop fragmenting and start doubling down on existing libraries.

I reject this sentiment. You can't force people to contribute to projects they have no passion for. You also can't prevent people from scratching their own itch and registering a domain for their _slightly different_ flavor-of-the- week JS project. Best you can do is ignore them or support them. The undeserving will wither eventually, you do not owe any project your attention.

<comment><USER5> > _The majority of people I have seen complaining about Javascript fatigue do > it from the peanut gallery._

You'd be surprised.

In any case, my anecdotal experience has been different: both me, and other front-end developers I know, have been frustrated with the pace of change in JS libraries and tooling.

> _If you are a Javascript developer: you shouldn 't have javascript fatigue > unless you chase after the latest and greatest - which you shouldn't do._

You don't have to chase the "latest and greatest" to feel the fatigue. Merely keeping up with what's considered "best practice" and avoiding what's considered a dead-end and people abandon is enough.

Case in point, it's only 5 years since Backbone came out. Backbone! And if feels like we've had 3-5 transitions already (Angular. No wait, Ember. No React. Oh, and add Flux. Actually, go Redux.). In Python or Ruby I could still use the Rails and Django I learned in 2006 -- not so much with JS.

> _If you do not experience have "cereal fatigue" at the supermarket, you > shouldn't get Javascript fatigue either._

Only people have (cereal fatigue). Too much choice leads to fatigue and stress in itself -- and this is backed by science...

<comment><USER4> > You don't have to chase the "latest and greatest" to feel the fatigue. > Merely keeping up with what's considered "best practice" and avoiding what's > considered a dead-end and people abandon is enough

Sounds like the same thing to me - you can deal with this in 2 easy steps: 1) Ignore the hype 2) Ignore the hype. Best practices _for who?_ Facebook's "best practices" might not work for you. You can't blame external circumstances for _your_ technology churn, especially if the "dead-end" technologies are still actively maintained. "Best practices" are just design by committee writ large. I still use Grunt rather than Gulp, for me the 'improvemements' are marginal. I still support a Dojo SPA even though it's considered ancient. These technology decisions are not considered best practices, but they work for me. The buck stops with _you_ (or whoever makes tech decisions at your org) - <USER2> can't pass the blame to the larger JavaScript community.

My point is you can safely ignore the latest and greatest (or 'best practice' as you call it). Apply common sense and only use what you need.

Speaking of hype: aren't containerized Flask-based microservices the current 'best practice' rather than monstrous Django apps? Looks like your 2006-era technology won't cut it on the back end either - it's all about scalability now ;)

Edit: added text below this line

> Too much choice leads to fatigue and stress in itself -- and this is backed > by science

This is not inherently bad in any way: it's a trade-off. The paradox of Choice states that choice decreases (present) happiness. If this is what you are optimizing for, then less choice is good. Unfortunately, large and complex systems are...complex and multifaceted. I'm willing to sacrifice a little happiness in the present for ease of maintainability (when choosing a library that better fits my needs). Nature itself seems to celebrate choice when it comes to genetics in sexually reproducing organisms. Diversity has it's benefits -- and this is also backed by science.

<comment><USER5> > _Sounds like the same thing to me - you can deal with this in 2 easy steps: > 1) Ignore the hype 2) Ignore the hype._

And then you end with abandoned npm dependencies and no new development/books/blogs/tutorials after a short while.

<comment><USER6> How much does that actually matter if the libraries continue to work for you?

</comment></comment></comment></comment></comment></comment><comment><USER7> We were previously using RiotJs in our company. We are building huge single page application and recently moved to InfernoJS. Results have been amazing. RiotJs used to BE lagging a lot (It simply could not handle 3000 components in same way) It had really long (50ms) delays everywhere.

After moving to Inferno following things have improved:

-We are unit testing components -Performance!!! (No delays/lagging anymore) -es2015 syntax with JSX and inheritance -Intellisense support in IDEs (webstorm) no custom riot syntax \- Future proof syntax without worrying low level API changes

Negative things: -It took for a while to recode all our components in JSX

\--Havunen

<comment><USER8> What do you consider huge?

Maybe we're just slow, but we recently estimated that rewriting and launching our whole frontend in another js Framework would take a dedicated 3 Person Team atleast a year, how do you explain this cost to someone with financial responsibility, I mean the benefits are probably great, but THAT great?

<comment><USER9> The alternative, depending on your market segment, is your competitor do it and you don't, they fall behind for a little bit, your sales grow.

Then their version comes out, faster and better, and their dev team iterates faster, eventually catching up and leaves you in the dust. I've seen it happen...very recently, in a situation that ended up in large layoffs.

It doesn't have to be all or nothing though. These libs are easy to keep around side by side, so you can slowly rewrite stuff as you add new features until the transition is complete.

</comment></comment></comment><comment><USER10> Shameless plug, I know, but I bet Inferno doesn't come close to my latest framework when it comes to the notorious task of writing a TODO app: [https://github.com/ErikWittern/TODOit](https://github.com/ErikWittern/TODOit)

<comment><USER11> i saw this come up yesterday on reddit and asked myself if this was joke. 70 lines of code is a lot of code? i don't get it :/

I'm asking this as the author of domvm [1] and a 60 LOC todo implementation [2] that also exposes a usable API.

[1] [https://github.com/leeoniya/domvm](https://github.com/leeoniya/domvm)

[2] [https://leeoniya.github.io/domvm/demos/todo- alt.html](https://leeoniya.github.io/domvm/demos/todo-alt.html)

<comment><USER10> Everything is relative. Like 60 lines of code (especially as compared to a single one). Or humor.

</comment></comment></comment><comment><USER12> "Non-performant features have been removed or replaced where an alternative solution is easy to adopt without too many changes." Sound for me like preact ([https://github.com/developit/preact](https://github.com/developit/preact))

<comment><USER13> Same API as react? sounds nice.

What did they left out?

<comment><USER14> "but only the modern (ES6 Classes and stateless functional components) interfaces"

<comment><USER13> Seems nice. Cut down my JS size by 50%

</comment></comment></comment></comment><comment><USER15> What does isomorphic library mean in the context of Javascript ecosystem ?

<comment><USER16> Being able to run the same code both on the server side (nodejs) and the client side (browsers).

</comment></comment><comment><USER17> Events + callbacks are great for keeping with the conventions of the existing (ancient) DOM APIs, but I was hoping that a new, 'modern' framework would be a little more ambitious by making everything promise-based.

</comment><comment><USER18> I'm trying hard to figure out why someone want to use something like this or React, when vanilla HTML, CSS and JavaScript seems much easier and more performant. The only thing I can think of is that appendChild is a bit tedious, but createClass seems even more boilerplate.

<comment><USER19> The vanilla way tends to result in state spread out throughout your JS and DOM. React UIs act like predictable functions: you describe the UI you want with your current state as the input and React makes the visible UI match that.

<comment><USER18> I think this is a JQuery problem, as it makes complexing state the path of least resistance. i.e. modifying the DOM directly instead of via functions. Resulting in code that is hard to test or debug. React seems to fix this, witch makes it a good argument on why to use it. My counterargument for "vanilla" JS/HTML is that you can refactor the bad parts. But you can't get rid of React, or you would have to rewrite your whole app! Like when the next JS fashion/framework comes. _grin_

<comment><USER19> React itself is just the view. You can replace your template language without redoing everything if you want. Khan Academy, for example, still has some Backbone views that render with React. We also have some Handlebars templates that we haven't converted over yet. That's all peacefully coexisting, though we'd love it if all of our views were React and more of our data handling was just pure functions.

</comment></comment></comment></comment><comment><USER20> Quite honestly my problem with react is the gzipped size, not the performance. What's the size of the browser bundle of this library?

<comment><USER21> Look into preact + buble ES2015 compiler then, should be small enough

[https://github.com/developit/preact](https://github.com/developit/preact)

[https://gitlab.com/Rich-Harris/buble](https://gitlab.com/Rich-Harris/buble)

my app.min.js.gz is 6.2K for some basic stuff including preact-router

[https://github.com/developit/preact- router](https://github.com/developit/preact-router)

</comment></comment><comment><USER22> What is the difference comparing to vuejs?

<comment><USER23> One major difference being that Vue.js doesn't really quite support TypeScript even with d.ts files provided. It will work only to a point until things fail to typecheck due to generative aspects of Vue's API.[1]

I think a useful comparison is taking a look at t7[2], trueadm's template library. Last I knew, it wasn't ready for use with Inferno yet, but that is a peek at the direction it is heading. It's rather similar to Vue's templates minus the v-directives magic in favor of leveraging JS for things like control flow.

I'm not 100% sure I'm sold on it, myself, as I rather like beating out Vue templates in Jade rather than doing everything in JavaScript with template strings. That being said, I haven't directly tried to implement anything with Inferno or t7 yet to turn in an informed opinion on working with it.

Inferno is one of the few other library than Vue I'd even bother looking at, however, at this point in time. They both aren't horribly bloated, are rather quick and have a mostly sane model to work with. Cito.js[3] is also interesting and works with t7, if you're looking for even less frills.

It is also worth noting that if you care about licenses, Vue is MIT and Cito.js and Inferno are using a much more heavily restrictive license, MPL 2.0, which will matter if you're a commercial developer doing standalone apps. For this reason alone I have to throw Inferno and Cito.js into the trash at work.

[1]: [https://github.com/vuejs/vue/issues/478](https://github.com/vuejs/vue/issues/478)

[2]: [https://github.com/trueadm/t7](https://github.com/trueadm/t7)

[3]: [https://github.com/joelrich/citojs](https://github.com/joelrich/citojs)

<comment><USER24> ah thank you for the summary of the licences. that moves inferno off the table for me too. sadly though, cause I was really getting interested with it being written in typescript.

<comment><USER25> I dont understand. Afaict, MPL only requires you to publish the _changes_ you make to MPL'ed libraries, not all source that uses it. Why does that stop you from using Inferno?

<comment><USER23> It is the difference between amending documentation (MIT) and producing infrastructure (MPL/LGPL) to ensure that whatever is currently in-tree and covered by the license is exactly what is available for download in the event anyone ever patches it... else you are out of compliance. It isn't just changes, either, it's the files in their entirety.[1]

In a perfect world, no company would balk at having a GitHub account and having a public fork available, but many companies out there right now are still rather conservative about these things. Some barely use source control. MIT is simply one of the easiest licenses for these places to comply with. In my personal experience working at unglamorous places like these, they're fine returning patches as long as they never have to think about the legal implications or feel like there's a burden for using the code in the first place.

The MPL is a poor choice for this sort of code because it makes the assumption that distribution is a given and will happen automatically, but if you're doing application development rather than web development that simply is not true that the code will always be a 'View Source' away. There are certainly applications where this license would be more appropriate, but I do not think an isomorphic vDOM library would be one of them, since this is rather foundational glue.

It would be rather nice if trueadm would reconsider, if possible.

[1]: [https://www.mozilla.org/en-US/MPL/2.0/](https://www.mozilla.org/en- US/MPL/2.0/)

[1a]: [https://tldrlegal.com/license/mozilla-public- license-2.0-%28...](https://tldrlegal.com/license/mozilla-public- license-2.0-%28mpl-2%29)

<comment><AUTHOR> Thanks for filling me in on the details of MIT vs MPL. I'll switch over to MIT now that I know this.

<comment><USER23> Fantastic, thank you so much for the hard work!

</comment></comment></comment></comment></comment></comment></comment><comment><USER26> But does it have something similar to React Native?

<comment><USER27> This was a problem I was trying to solve as well and theres a pretty elegent solution that this project has implemented partly already. The "render to string" is also a proof of concept that the indicates "unknown" types can be fullfilled by a "renderer". So long as he allows generic "renderers". Within a more free form environment like nativescript[ 1], this library can be one of any that can be used. I was planning to implement blessed and nativescript uis but these can often be very painstaking tasks. If the developers on this project are committed, the sky is the limit!

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

<comment><USER28> I didn't know about nativescript before, thanks for bringing it to my attention! That said, it looks like nativescript promotes single code for multiple platform, which means the app won't look awesome in any of them (examples from history: phonegap, java awt). I would be much more comfortable with it if I could just use JS to access native controls and style them using the established (platform specific) methods. I am guessing css will never support each and every widget property... Is this approach possible with nativescript?

<comment><USER27> Tbh, Im very early in my nativescript experiences (though I do believe in the project). But I believe these are some examples you are looking for

[http://docs.nativescript.org/ui/placeholder](http://docs.nativescript.org/ui/placeholder)

[http://docs.nativescript.org/core-concepts/accessing- native-...](http://docs.nativescript.org/core-concepts/accessing-native-apis- with-javascript)

[http://docs.nativescript.org/runtimes/ios/marshalling/Marsha...](http://docs.nativescript.org/runtimes/ios/marshalling/Marshalling- Overview.html)

[http://docs.nativescript.org/runtimes/android/marshalling/ov...](http://docs.nativescript.org/runtimes/android/marshalling/overview.html)

[http://docs.nativescript.org/plugins/plugins](http://docs.nativescript.org/plugins/plugins)

</comment></comment></comment></comment><comment><USER29> What is this solving?

<comment><AUTHOR> It's solving performance issues that React and other virtual DOM libraries currently suffer. This is massively important for low power mobile devices. It's not an ego driven project, all research is going back into the open- source community to make better libraries and implementations inclusion React.

<comment><USER30> > It's solving performance issues that React and other virtual DOM libraries > currently suffer.

But isn't "performances" the point of React? As I understand things, people were moving from AngularJS to React because the virtual DOM was supposed to be the most performant technique to handle UI mutation and rendering.

So what is the reality behind the supposed speed of React ?

<comment><USER9> Performance was never the point of React.

The point is to be able to (from a developer's point of view) re-render "everything", with every change, top down, without having to worry about the details. Doing that normally would be horribly slow, so React makes it adequately fast.

So it's not "super mega high speed lib". It's "Gives you the ability to have a function which, given argument, renders an entire app, and can be called over and over and over" at pragmatic speed, allowing for easier code to reason about.

If your primary goal is performance above all else, it's actually not that great a library.

<comment><USER31> That whole goal was performance driven...

<comment><USER32> What makes you say that?

</comment></comment></comment></comment></comment></comment><comment><USER33> Would like to see comparison to RiotJS

</comment><comment><USER34> As a curiosity, how do we feel about changing the names of the lifecycle methods from "lifeCycleEvent" to "onLifecycleEvent"? Looks like a lot of stuff is pretty transparently portable from React code, I think it's curious this got changed.

</comment><comment><USER35> > Inferno uses intelligent techniques to separate static and dynamic content. > This allows Inferno to only "diff" renders that have dynamic values.

Can this be expanded? If/when the intelligent diffing fails, I'd like to know how to fix it.

</comment><comment><USER27> [https://github.com/formula1/tEmbO?files=1](https://github.com/formula1/tEmbO?files=1)

Was doing something similar for a while. Very cool stuff! Excited to see where you take it!

</comment><comment><USER36> It's still in progress but it gets better on each release. Even better that the new version is using TypeScript!

<comment><AUTHOR> TypeScript not only helped improve Inferno's with quality and read-ability of code. It can potentially help produce highly optimal output (bundles) with Google's Closure Compiler. In the future it may even help created optimised WebAssembly output. It's an exciting time :)

<comment><USER37> I've just opened the GitHub repo and I see no trace of TypeScript, no .ts files anywhere

<comment><USER38> Wrong branch. Check 0.8-dev: [https://github.com/trueadm/inferno/tree/0.8-dev/src](https://github.com/trueadm/inferno/tree/0.8-dev/src)

<comment><USER37> fine, thanks. TypeScript makes it even more interesting. I am going to make some tests to see if Inferno can replace React when working with react- templates.

</comment></comment></comment></comment></comment><comment><USER39> Any specific reason it is called Inferno? Somehow I can't stop thinking that after Inferno comes Purgatorio and Paradiso.

<comment><USER40> And the name is already taken: [https://en.wikipedia.org/wiki/Inferno_(operating_system)](https://en.wikipedia.org/wiki/Inferno_\(operating_system\))

<comment><AUTHOR> React was also taken before Facebook used it. It's not an issue in my eyes. Inferno was used to emphasise performance and power.

</comment></comment></comment><comment><USER41> React, so great people are already re-writing it.

</comment><comment><USER42> Interesting...

</comment><comment><USER43> I like how javascripters use `const` everywhere they can except actual constants!

[https://github.com/trueadm/inferno/blob/master/src/DOM/mount...](https://github.com/trueadm/inferno/blob/master/src/DOM/mounting.js#L65)</comment>


Videos from the Economic Manhattan Project - <AUTHOR> http://www.edge.org/documents/archive/edge285.html

<comment><USER2> So far I have made it through Weinstein's, Roubini's, and Taleb's talks. What I have seen is a good start towards understanding a subject that we have very little hold over right now. If you can find the time to watch even one of these videos, it is well worth it.</comment>