Google Glass hands-on: Not a good device for consumers - <AUTHOR> http://venturebeat.com/2013/05/09/google-glass-hands-on-review/?utm_source=feedly <comment><USER2> If she's going to write about a product, maybe she should actually use it, given that she actually has a pair.

It's bad enough when journalists write about a product without having it. She has it, but she's not using it, and then she's writing sweeping articles about it's long-term future.

<comment><USER3> Not only that, but you could replace 'Glass' with any mobile technology over the last decade (many of which are wildly successful consumer devices), and the 'review' still makes perfect sense (albeit, with the same, incorrect, conclusions). Maybe that should have been a signal to the author...

<comment><USER4> Yeah this is the same thing that happened with the iPad (it's a huge iPhone without the phone part? who would ever buy that?!) and more recently, with Windows 8 (metro is a failure! Microsoft is doomed!).

Google Glass, in its current iteration, will likely never catch on with consumers. But it's a limited availability "preview" for a reason. Something like this is eventually going to get cheap enough and usable enough that consumers will buy it.

</comment></comment></comment><comment><USER5> I love reading stories like this, especially with hyper-revolutionary products like Google Glass.

Because the more people say "it will never succeed with consumers", the fewer people will go into Gold Rush mentality (at least for now), and the more opportunity there will be for folks like me (and, I hope, other HN types).

I couldn't be more confident that some variation of this -- whether it's Google Glass or Apple Eyeball or whatever -- is going to really, seriously, emphatically, be a multi-billion-dollar market.

So keep going VentureBeat and others. Keep telling the world it's just a nerd toy or a fad or whatever. More time and more opportunity for the rest of us ;)

"No wireless. Less space than a nomad. Lame."

<comment><USER6> To be fair, the difference between this and 'some variation on this' is also the difference between the iPhone and Windows Mobile 6.

<comment><USER7> This.

Are wearable computers going to be a thing? Probably. But if it does become a thing, Apple will make it one, not Google. Here is this product segment that is, by necessity, the intersection between computers and fashion accessories. Only Apple has the mind-share to pull that off.

<comment><USER8> > Only Apple has the mind-share to pull that off.

why do you think that? Have you seen the latest market share of smartphones? Android?

<comment><USER7> Out of all the companies doing consumer electronics today, only Apple has the mind-share to fight the "I'll look like a dork using this" stigma. In the 1980's that company was Sony, but today it's Apple. It's definitely not Google or Samsung. Once Apple makes the sector "cool", like they did with smart phones and tablets, then it will be safe for lower-margin Android-powered products to come in.

</comment></comment></comment></comment></comment><comment><USER9> "It's robbing you of the joy of actually experiencing your life. You'll realize it the first time you step in dog shit or have your girlfriend get mad at you for not listening to her or lose your kid in a store."

Last two things there? Both of them of them? It's you being a terrible person. Stop blaming technology for letting you be awful and blame yourself for being awful.

<comment><USER10> I don't believe the world is filled with "terrible" people. I do believe the world is filled with people who use their smartphones in inappropriate situations all the time.

There's a discrepancy here, and it's clear new tech is being consumed faster than we can propagate the social norms around the tech.

</comment></comment><comment><USER11> It's amusing to see this back and forth of tech community where one side thinks it's the next big thing, the other thinks that because these "nerdy" tech journalists like Google Glass it won't be popular, and then the rebuttal that the critics are either jealous or just naysayers.

Honestly, it's all fun and games till the average consumer has the ability to buy it. The rest is just speculation.

<comment><USER12> I feel slightly verklempt every time I see someone say Google Glass won't work because no one wants to wear glasses.

<comment><USER13> Even worse: glasses are so difficult to wear that they make you step into dog shit :(

</comment></comment></comment><comment><USER14> I'm not sure, I felt (and feel) the same way about tablets, and about smartphones except in limited cases. But tons of people got them and now they're standard.

So I wonder if a good litmus test for this sort of review might be to find/replace Glass with iPad and see if any of the criticism __doesn't __apply. Very little in the article seems to pass the test, so even though I tend to agree with the sentiments, I'm not sure most consumers will feel the same.

<comment><USER15> Smartphones and iPads don't make you look like a dork while using them.

<comment><USER16> Any product can make you look like a dork depending on how you use it. Even if you're Spike Lee:

<http://i.imgur.com/OY5RBuo.jpg>

</comment></comment></comment><comment><USER17> I actually expected a "hands on" article. What I got instead were a couple stories, and then a bunch of vague predictions on the future of Glass.

> _"And some overzealous Emily Post type (probably at an old-timey print rag) > will write a much-mocked op-ed about the slight but growing disconnection > between people."_

A few paragraphs later...

> _"...it's not enhancing your life. It's robbing you of the joy of actually > experiencing your life. You'll realize it the first time you step in dog > shit or have your girlfriend get mad at you for not listening to her or lose > your kid in a store."_

</comment><comment><USER18> People think "HN is too negative", but can you believe the goddamn journalists fretting over this, despite 1) never having used it and 2) this was clearly presented as an early-adopter developer version?

Still mad about not having Reader available to do their work.

</comment><comment><USER19> I thought her allusion to the Star Trek:TNG's episode of "The Game" was especially adroit. In a futuristic world where you have an unimaginable array of tech toys, such as the holodeck, why would visors be appealing? Well, it wasn't the greatest TNG episode, but I guess even in a Trek future, people will value the immediacy of such eyes-only technology. Just think about how phones have revolutionized thhe way we non-interact with each other in physical space.

Last night I saw the "Great Gatsby" and thought, like the book, it captured the timelessness of the story in that it would not feel any different in a modern setting, despite being written 80 years ago. But I kept thinking..."this is just like today, except no one is checking their phones"

<comment><USER7> The thing about Great Gatsby is that, aside from the smart phones, it _was_ just like today. The 1920's and 1930's were modern times. Manhattan was a place of 2.3 million people (substantially bigger than today), and was heavily built up: [http://www.skyscrapercity.com/showthread.php?t=34300&pag...](http://www.skyscrapercity.com/showthread.php?t=34300&page=30). The electrical grid, subway systems, roads, etc, were all mostly in place by then.

We have pervasive digital technology today, and there are more cars and bigger high-rises in Manhattan, but you can picture a fancy dinner party today on Park Avenue in a building that was built in the 1920's and 1930's (like many luxury buildings in New York), with people who took a train in from Long Island on a line that was already old in 1920, etc.

</comment></comment><comment><USER20> Yet another person speaking for consumers on a device that isn't even finalized yet.

The only evidence I need that it sucks (in its current form) is that

1) Robert Scoble loves it. 2) Robert Scoble thinks he looks good wearing it.

You can't buy taste.

</comment><comment><USER21> > _If you're using it recreationally, not professionally to complete a task, > don't kid yourself — it's not enhancing your life. It's robbing you of the > joy of actually experiencing your life._

Same with cell phones. And computers. And books. And your car. And Legos. And art. And music.

Wait. But we _like_ books and creative things, right?

This is the sort of vacuous statement that irks me. "Well duh" is an obvious response, but it goes deeper. This can be applied to doing _anything_ you enjoy, but it's wielded most frequently against new things, in a "get off my lawn" / rose-tinted glasses way.

Sure. New things get used for things you don't approve of. Easy art reproduction brought about the proliferation of porn and the commoditization of art in general. The printing press brought about the end of scribes, and is used to spread Christian, Buddhist, atheist, communist, anarchist, and democratic propaganda.

But new things also get used for things you _do_ approve of. Like porn, art in every room, and spreading propaganda for your latest cause.

Can we please get an ounce of information, instead of vague new-thing-hate?

</comment><comment><USER22> How long till lawmakers prohibit using Glass while driving? Unlike hands-free ear pieces, Glass can distract the driver (like texting). Given Google's track record, I would not hesitate to think of a future where Glass will have ads pop in randomly. It is, after all, an advertising company.

<comment><USER2> Some studies found that even hands-free phone calls impair drivers significantly, as do traditional activities like changing the radio or just talking to another person in the car. Arguably anything that increases cognitive load (including a stick shift) could have this effect. Unless we're going to get into regulating _everything_ you do in car, we probably need to just leave it to drivers or have self-driving cars.

[http://mysite.verizon.net/horrey/papers/Horrey_HF2006meta.pd...](http://mysite.verizon.net/horrey/papers/Horrey_HF2006meta.pdf)

</comment></comment><comment><USER23> >But give it a few months. Soon, it'll be streaming Netflix queues, taking brilliant long-form blog post dictation, and offering up a wealth of casual social games, a portal into an endless labyrinth of distraction.

No it won't. Give it a few years, maybe.

<comment><USER24> And so what if it did? Would her article be any more or less true if she dictated it as opposed to writing it? Is a movie watched on a private screen close to our eyeballs any less entertaining than one viewed on a mobile phone or television?

If the only real argument against Google Glass, as a product or as a concept, is that it offers _too much_ , then I'm not sure I see what the problem is.

<comment><USER23> The argument against Google Glass is that we don't have the technology to make it work properly yet.

<comment><USER24> Well yes, but that's what the limited prototype is for, isn't it?

I mean, this one product isn't really sink or swim for the technology, and even if it doesn't meet the loftiest of expectations there's sure to be a lot to gain from the attempt in regards to features, usability, and UX.

After all, Blackberry smart phones sold extremely well prior to iPhone coming along and doing it "properly", but I'm sure Apple learned a lot of lessons from it. Even if many of those lessons were in what not to do.

<comment><USER23> The limitations specific to this device aren't the problem. The genuine issues will not be fixed before production, simply because don't have the technology. Specifically: the battery life, the poor voice recognition and the headaches.

</comment></comment></comment></comment></comment><comment><USER25> _Imagine working on an airplane engine and having the manual right in front of you_

 _For example, you already have Google Maps to guide you around your city with turn-by-turn audio navigation. That tool doesn't get any better when it's smack-dab against your eyeball._

I don't see why a manual for an airplane mechanic is better _smack-dab_ against his eyeball but a map in one's line of sight is not better for a person navigating.

Her claims that Glass distract you from reality are counter to Google's thesis that Glass frees you from the distraction of staring at your phone. Both claims could be true, but I haven't seen much evidence regarding Glass.

<comment><USER26> > I don't see why a manual for an airplane mechanic is better smack-dab > against his eyeball but a map in one's line of sight is not better for a > person navigating.

If I'm performing a series of complicated manual tasks, I'm going to need both hands free. It's a pretty safe bet on something the size of an airplane that I'm going to be moving around a fair amount, too.

My phone, giving me turn-by-turn directions, will always be just a foot or so away from me, and clearly visible from the driver's seat. I don't benefit from having it "smack-dab against [my] eyeball."

<comment><USER25> Your phone might be 1' from your hands, but not your eyes. I always hated trying to read a 4" screen on my windshield or in my cup holder while driving. I am not sure if refocusing your eyes on Glass's display would be an improvement though.

</comment></comment></comment><comment><USER27> For the typical day to day, I just don't see the killer application for a heads up display. My phone is never more than arm's reach away, and then it's out of sight when I'm done with it.

<comment><USER28> it's way easier to just look up and talk than to pull a device out of your pocket, unlock it, pull down notifications/open an app, then interact with the device. it will save you minutes everyday with that process alone.

<comment><USER27> I guess I could see that being a demanding and time consuming task if I had no arms.

</comment></comment></comment><comment><USER29> Well that's one way to handle a big review about technology of the future: don't write a review and suggest weaning yourself off of technology.

</comment><comment><USER30> Sharp glass prism secured in front of your eyeball, just waiting for you to bump your head on something. Imagining an airbag.

</comment><comment><USER31> A counter-argument:

<http://www.entrepreneur.com/article/226604>

</comment><comment><USER32> You can't put your fingers on head all the time to control. It's the most annoying thing.

Very human eye has focus, Google just think din't about that.

I would love something as lens in the future than glass in the present. I would prefer glass for calls but not video calls.

</comment><comment><USER33> > And train yourself to rely less on your smartphone, while you're at it.

This pretty much sums up this "review" for me. It's not a hands-on article so much as a reaction to her husband's device usage habits. May as well be about cell phones.

</comment><comment><USER34> It is so professional and insightful to discuss a product that's not even finalized yet. Journalism ftw!

</comment><comment><USER35> This article seems to piggyback on the recent meme of 'technology can be useful but also asocial and isolating/Why I deactivated my Facebook/Twitter/Google+', which I agree with, but she is a bit too preachy; please tell me why exactly Glass is bad, not just some general appeals to the bad side-effects of modern consumer gadgets.

> On the other hand, for myriad kinds of workers, I can see Glass being an > extraordinarily helpful, hands-free tool. Imagine working on an airplane > engine and having the manual right in front of you or using it to photograph > and catalog new species during a deep-sea diving expedition.

Imagine being someone who has to fix his sink, so he has to bust out a manual and figure out the sink at the same time... oh wait, turns out this nugget doesn't only apply to professional contexts.

Consumer-applications ← not just playing casual games and updating social media about what you had for dinner.

I can see Glass being excellent for some things, while maybe not being ideal for most of the things that you do. Imagine that you are in a foreign country and don't speak the language and you want to talk to someone; do you bust out your smart phone and let the other person spell out the words, then have them played back to you or you read it yourself? Or do you simply talk to that person and see the subtitles pop up as you go? The latter one is clearly superior, IMO.

This is like a review of cellphones from the 80's, "Stuff like this will never be used by anyone else than really busy professionals. It doesn't even fit in your pocket!"

EDIT: A lot of the time I really only need my smart phone for special purposes. Things like finding my way around places I haven't been is much easier with google maps than with a physical map and/or asking directions. Other than that? Well, surfing the web and listening to music, the former being a way to kill time and the latter something that my iPod Nano does better. Yet, smart phones are here to stay for most people.</comment>


Easy gopher-lua bridge - <AUTHOR> https://www.tedunangst.com/flak/post/easy-gopher-lua-bridge <comment> le-mark _I have some go code that I'd like to be a little more flexible at runtime. Like a config file, but maybe with some conditional logic based on string matching. If this sounds like a proxy deciding which filtering functions to apply based on URL, that's a good guess._

Interesting use case, reminds me of redis lua integration in a way.

<comment><USER2> So it's about the go programming language? I was expecting a gopher server.

OK, thanks for the information. Now I don't need to add an exception to the security certificate.

</comment></comment><comment><USER3> Invalid TLS certificates?

<comment><USER4> Self signed cert... should've used Let's Encrypt

<comment><USER5> Ted is bound and determined to make a political point out of self-signed certs. Let's Encrypt being free makes absolutely no difference to his belief that self-signing is completely valid and should be accepted by all.

The pragmatics of people being able to access his website also seems to make absolutely no difference to him.</comment></comment></comment>


What Alexander Graham Bell Sounded Like - <AUTHOR> http://www.smithsonianmag.com/history-archaeology/We-Had-No-Idea-What-Alexander-Graham-Bell-Sounded-Like-Until-Now-204137471.html

<comment><USER2> This is fascinating. For some perspective, it's from April 15, 1885 (128 years ago).

I recommend this article on Thomas Edison's first recording (1878, 135 years ago): [http://www.theatlantic.com/technology/archive/2012/10/scient...](http://www.theatlantic.com/technology/archive/2012/10/scientists- recover-the-sounds-of-19th-century-music-and-laughter-from-the-oldest- playable-american-recording/264147/)

...And the OLDEST HUMAN VOICE RECORDING OF ALL TIME (April 9, 1860 (153 years ago)), by a guy named Édouard-Léon Scott de Martinville living in France who built a machine to produce visual representations of audio with a pencil (for the study, he didn't know you could replay it): <http://www.firstsounds.org/sounds/scott.php>

<comment><USER3> Thanks for the links. Your comments about the "OLDEST HUMAN VOICE RECORDING OF ALL TIME" reminded me about a thought experiment I once heard.

Imagine a pottery wheel spinning thousands of years ago, and people talking as it spun. Then imagine that for some reason, a stick or other object was leaning against the wheel, and engraving a pattern. Theoretically, the vibrations of the people speaking would be picked up (at some level) by this engraving.

The end result is that if you had a device that was sufficiently sensitive, and you could remove a sufficiently large amount of noise (caused by other sources of vibration), then you could reconstruct an actual recording of people speaking thousands of years ago.

Of course, it is not likely that this will happen in the near future, or even at all. In fact, a quick search will show that it has already been used as an April Fools joke by some scientists [0].

However, that is not to say that it is impossible.

The reason I love this thought experiment is because it goes to show that if you start with the presumption that at some point, our tools become better, then there are very few limits to what _can_ be found out. What would happen if you went back 150 years and told everybody that in 150 years, we would have tools that can track the trajectories of sub-atomic particles as they travel at speeds horrendously close to the speed of light?

[0] - [http://www.ohgizmo.com/2006/02/20/5000-year-old- recordings-c...](http://www.ohgizmo.com/2006/02/20/5000-year-old-recordings- caught-on-pottery/)

<comment><USER4> Mythbusters did the 'recording in pottery' thing, if you're interested in that kind of programme.

One of the problems I see is that the pottery surface is inherently noisy, and the signal is very low. That would make recovering anything terribly remote. This isn't about needing better resolution to recover the signal, it's about the signal not being there because it's been obliterated by noise.

<comment><USER3> Yup, it sure is noisy. But let me indulge in my (not so realistic, but still potentially feasible) thought experiment :)

What if it turns out there is actually a predictable pattern to the noise on a ceramic surface. Perhaps there is a way that the molecules fit together that mean there is a few rules that govern the noise, such that we can then indeed remove it from any "recordings".

Or maybe there's some mathematical properties of noise that are yet to be understood which allow us to remove it correctly.

Or perhaps there is some arm of science which doesn't even exist yet (in the same way quantum computing didn't exist so long ago).

<comment><USER5> As much as I love the idea of this happening, if we are talking about such tiny variations, it's just as likely that erosion (air, water, pottery mud) would've wiped these tiny variations out.

</comment></comment></comment></comment></comment><comment><USER6> Seeing this reminded me of a few other really old recordings by famous people I've stumbled upon in the past. I still can't get over the amazement of finding these recordings most of us thought anyone would have cared to do or preserve.

Johannes Brahms playing his Hungarian Dance #1 (1889) [http://en.wikipedia.org/wiki/File:Brahms_- _Hungarian_Dance_N...](http://en.wikipedia.org/wiki/File:Brahms_- _Hungarian_Dance_No._1_\(performed_by_the_composer\).oga)

A recording of German Chancellor Otto von Bismarck (1889) [http://en.wikipedia.org/wiki/File:1889_recording_by_Otto_von...](http://en.wikipedia.org/wiki/File:1889_recording_by_Otto_von_Bismarck.ogg)

There's also some others located at the US National Park site[1]. Although we all have our love/hate of Edison, one of the more positive things he did was record many famous people out of interest or for the sake of posterity. William Jennings Bryan, William H. Taft, Theodore Roosevelt, Edison himself and many others are on that site.

[1] [http://www.nps.gov/edis/photosmultimedia/documentary- recordi...](http://www.nps.gov/edis/photosmultimedia/documentary-recordings- and-political-speeches.htm)

</comment><comment><USER7> As a sound engineer, listening to this brought a tear to my eye.

</comment><comment><USER8> Link to mp3: [http://media.smithsonianmag.com/audio/alexander-graham- bell....](http://media.smithsonianmag.com/audio/alexander-graham-bell.mp3)

</comment><comment><USER9> I don't know why, but I really like that he pronounces his middle name "Gray- am".

<comment><USER10> How do you pronounce it? I'm from New Zealand, and "gray-am" seems to be the common pronunciation here.

<comment><USER11> It's often pronounced "gram" (one short syllable), particularly in American media.

<comment><USER12> I am American and have always pronounced it and heard it pronounced with two syllables. Maybe not as deliberately as the recording. I wonder if he is talking slowly as he is because it's so new to him, or maybe we're not hearing it at the right rate, or some combination thereof.

Also, where's the thick Scottish accent?

<comment><USER13> This is actually quite a Scottish accent, however it does not really fit with the stereotype (Groundskeeper Willy et al). To me (a Scot) it sounds very similar to George Galloway's accent: <http://www.youtube.com/watch?v=V_AOTexf6uc>

There are numerous distinct accents across Scotland despite it being a pretty tiny country.

<comment><USER12> I guess my expectation was that the older the recording, the goofier the accents would sound, due to changes over time. For example, the recordings of Edison have him sounding like no American alive today.

<comment><USER13> Haha, your average Scot might get upset by any implication that our accent is in any way "goofy" but I completely understand what you mean

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> _"the inventor of the world's most important acoustical device—the telephone"_

and... no.

Bell _stole_ the telephone invention to Meucci.

<comment><USER15> Well, the _photophone_ was actually a much cooler device anyway. Experimental wireless transfer of human speech over 200 meters from a completely passive device using optical scattering? In 1880? Sweet! The receiver was active, but transmitter was not at all. Somewhat similar to modern UHF RFID technology.

Bell was actually a pretty awesome engineer largely motivated by wanting to help the impaired.

</comment></comment><comment><USER16> We still don't. The file format in this link was also invented by Bell.

<comment><USER17> Can you explain what you mean? I don't understand.

<comment><USER18> I think he's poking fun that the mp3 file won't play. It isn't for me anyway..

<comment><USER19> It doesn't play for me either, using Chromium (the distro pacakge of Google Chrome) on Linux Mint 14. But view source, Ctrl+F mp3, and doing wget on the name of the file worked just fine.

They should really make a lossless .wav or .flac available IMHO, but that's a different gripe...

</comment></comment></comment></comment><comment><USER20> How strange is that it looks exactly like a CD?

<comment><USER21> The center hole is too small or at least its proportions don't match up with a CD.

But in any case, how would you design a recording device? The text says there were mostly cylinders and discs, which makes sense because you can put a spiral track on those. In the disc case you would have to rotate them around their Z axis which pretty much requires a hole in the center. So I guess it's not that surprising that Bell's cardboard-and-wax disc, vinyl records, laserdiscs and CDs all look pretty similar.

</comment></comment><comment><USER22> Listening to a recording made in 1885. Mind blown.</comment>


Chrome 76 prevents NYT and other news sites from detecting Incognito Mode - <AUTHOR> https://arstechnica.com/information-technology/2019/07/chrome-76-prevents-nyt-and-other-news-sites-from-detecting-incognito-mode/ <comment><USER2> It's still detectable, this protection introduces a new side-effect which can be used to detect incognito. I Wrote a blog post[1] yesterday showing how to do that.

[1][http://mishravikas.com/articles/2019-07/bypassing-anti- incog...](http://mishravikas.com/articles/2019-07/bypassing-anti-incognito- detection-google-chrome.html)

</comment><comment><USER3> Good. I hate that crap.

Come on NYT, I can clear your cookies and have the exact same effect as using incognito.

</comment><comment><USER4> \- F12 / DevTools

\- Click 'Application' tab

\- Click 'Clear storage' in the righ column

\- Click 'Clear site data' button

Now NYT or whoever, has lost all the cookies, localStorage etc. that they use to track your usage.

<comment><USER5> Not if you're on mobile... :/

</comment></comment><comment><USER6> Hopefully this means that Google is taking steps to better protect the privacy of users. I'm curious if there are other ways that a site can identify if you are in private mode.

<comment><USER7> You can see the script they currently use to detect incognito in different browsers + rules they use to allow browsers even if they haven't logged in (e.g. social browsers and their apps)

[https://gist.github.com/jeroenvisser101/9f8119cfa91371dd6e1a...](https://gist.github.com/jeroenvisser101/9f8119cfa91371dd6e1a03d56edb0863)

Source: nytimes.com's sourcemaps

</comment></comment><comment><USER8> While I absolutely agree with Google's motivation to keep the incognito mode functional, I find their response somewhat nonsensical.

> _Sites that wish to deter meter circumvention have options such as reducing > the number of free articles someone can view before logging in, requiring > free registration to view any content, or hardening their paywalls._

What use would reducing the free article count be if you cannot reliably count the articles in the first place?

And what is "hardening their paywalls" even supposed to mean? Supposedly, you'd like to make your paywall harder to circumvent. However if you allow any registrationless articles at all, that would necessarily require some kind of tracking - exactly the kind of tracking the incognito mode is supposed to prevent.

Turning into a strict registration-only site is likely also problematic because this could cause them to be downranked by - surprise! - Google, this time in their incarnation as a search engine.

<comment><USER9> > Turning into a strict registration-only site is likely also problematic > because this could cause them to be downranked by - surprise! - Google, this > time in their incarnation as a search engine.

There is steps they can take to have a registration only website while allowing Googlebot to authenticate.

<comment><USER8> Ah, I wasn't aware that Googlebot supports that by now. Thanks for the info.</comment></comment></comment>


The Performance Cost of Server Side Rendered React on Node.js - <AUTHOR> https://malloc.fi/performance-cost-of-server-side-rendered-react-node-js <comment><USER3> It would be worth verifying that NODE_ENV=production is set during these benchmarks (I see no mention in either the article or the source repository.) Running in development mode has a significant performance impact.

Edit: This PR shows that is likely to be the case. Running in production mode along with some other minor changes shows React running at 88% the speed of Pug. [https://github.com/janit/node-templating- benchmark/pull/1](https://github.com/janit/node-templating-benchmark/pull/1)

<comment><USER4> NODE_ENV=production definitely wasn't set based on some basic testing I did (that's my PR there), which accounts for the atrocious performance.

Also, the React component is created on each request instead of just being created once. Unless one's goal is to specifically colour the perception of React, I don't understand that decision alongside the code for Pug which precompiles the template a single time.

(Also declaring the map function outside the component and not creating a closure makes for a tiny extra boost.)

It's disappointing to see that the article took off to this extent given how misleading and inaccurate it is.

<comment><USER5> Hello Anatoli. Thank you for this. It was clearly an oversight on my part, not intentional to make React look bad. I have added a note on the article and will run the tests with the correct settings and your PR with further optimisation.

<comment><USER6> Then you should withdraw the article until you get real numbers. This utterly misleading data (as of now) is going to be picked up by search engines and other blogs.

Add: on a positive note, this aspect of React is worth benchmarking. Thank you for that.

</comment></comment></comment></comment><comment><USER7> Note that React doesn't do streaming HTML in the traditional sense. You can't send out initial HTML while you wait on an API response, for example. Instead only the serializer is streaming. Your app renders to a VNode synchronously and then the serializer traverses the VNode, synchronously, and streams the strings out as it goes. This is why streaming is only a little bit better in these numbers.

If/when React gets real streaming it will compete better with traditional templating engines, most of which _don 't_ do streaming. If you use Node.js and want a traditional templating engine that uses JS template literals and _does_ do streaming, check out my project: [https://github.com/matthewp/flora](https://github.com/matthewp/flora)

<comment><USER8> React 16 supports streaming! [https://reactjs.org/blog/2017/09/26/react-v16.0.html#better-...](https://reactjs.org/blog/2017/09/26/react-v16.0.html#better- server-side-rendering)

<comment><USER8> Oh sorry I should read better! Sorry

</comment></comment></comment><comment><USER9> I thought the idea was to render it server side just once, then have the client take over for all future requests? In which case it's 10x slow for the first page load, but all future requests are just hitting API endpoints and can be fairly fast?

<comment><USER10> Correct, except that initial app load time for _un-cookied users with cold browser caches_ is a critical metric, since it largely determines whether they'll keep using your app. Fortunately, those are the scenarios where server-side caching can have a decent benefit, since you're essentially rendering the same view to all such users.

<comment><USER11> If all first time users see the same thing, why not serve a precompiled static html that then gets taken over by React.

Isn't that the whole point?

<comment><USER12> > If all first time users see the same thing

That's a big, important, if.

<comment><USER10> It's good odds, though. Obviously depending on the app, these would be non- logged-in users who don't get personalized content.

<comment><USER12> There can be (though you'd be surprised- there's rarely such a thing as a non- identifiable user nowadays). Just pointing out it's a very big conditional.

For example: I work at Bleacher Report and our non-logged-in users get data _customized for them_. That can be as simple as GeoIP data or can be us knowing (and inferring) what articles or content they've seen.

The permutations are quite large.

Now some blog, or a very simple app won't do something like that (hell, they might not have the depth of content to be able to) but it's reasonbly common to have that requirement on large sites outside of v.limited pages (like login/signup etc)

</comment></comment></comment></comment></comment></comment><comment><USER13> If you're on the fence about server-side rendering being needed for your webapp don't do it! As a team of two with one engineer, I decided YAGNI and instead focused on the responsiveness of the React and Redux-based web application. It is very snappy to load and our (paying) customers are happy.

You might not need SSR. I don't. I expect there will be more work to optimize it and eventually it'll be obviously a good idea. But you don't need it right now if you're working on a SaaS product.

<comment><USER14> It's the other way around: you might not (in fact, probably do not) need React.

Start with server-side rendering, and move to React if your application's dynamism demands it. Most applications don't. It's painful to see so many websites building huge, slow, JS-rendered monsters for one or two dynamic elements per page. Unless you are Facebook (and have your JS cached within one hop of every internet POP in the world), server-side rendering is going to yield performance wins for nearly all visitors.

<comment><USER15> The difference there is that it's very hard to port a non-JS server-side- rendered site to React if it turns out you do need to. Whereas it's relatively easy to port a React application to additionally do server-side rendering.

<comment><USER16> The other difference is that I'm having a hard time imagining a scenario where someone is getting blindsided by "damn, it should've been a SPA after all!"

I'd be wary of all of the technical decisions that were made if the decision- maker knew so little about the requirements that they couldn't even call that shot correctly.

Of course, on a long enough time scale, all bets are off.

<comment><USER15> > The other difference is that I'm having a hard time imagining a scenario > where someone is getting blindsided by "damn, it should've been a SPA after > all!"

I've seen it happen more than once. Start with what looks like a straightforward form flow, seems like it should be fine in rails or whatever. Then it turns out some fields depend on other fields, so you've got to dynamically show/hide parts when other parts are set. And doing a server roundtrip, even AJAXey, is just too slow. So you put a bit of client-side Javascript to handle that. And then as the product evolves the interrelations between the form elements become more and more complex and businessey, and you have more and more logic split or duplicated between backend and frontend.

</comment></comment></comment></comment></comment><comment><USER17> OK from single core $10 VPS you will be able to serve 1,080,000 unique initial loads per hour and depending on your pattern of traffic say 15,000,000 in a day could you remind me what the issue is again?

<comment><USER18> It's a real issue, my startup's react SSR times are ~5 seconds of blocking the node thread on my $40 droplet. It's about 50% react. Our pages are way more sophisticated than your average page with like a query and a form, though. There are many ways to make faster though, one of which is to simply configure your CDN properly.

<comment><USER19> 50% on plain rendering is very unexpected. Complex apps tend to have bottlenecks on IO/data fetching more than just plain rendering.

I would love an article detailing your experience and measurements.

<comment><USER18> our renders are compute heavy because it is so dynamic (most of today's apps aren't). Think of it this way. Virtual DOM is like a spreadsheet. You only want to recompute the stuff downstream of what's changed. That's basically what React's render-tree pruning is all about. But there are a couple problems.

First, naive server rendered React isn't diffing anything at all, it recomputes the whole virtual dom from scratch every time. So there isn't any render-tree pruning since we're not doing a diff. That's what the walmart-labs patches help with, since obviously a lot of SSR'ed components aren't changing between SSRs, that can be reused, and we can be fast again.

Second, React.js views are more than just banging html together, it also has to call a bunch of functions as part of that process. For example client side sorting, or map/reduce/filter. So if those functions are expensive, your views are slow, even if the html itself isn't all that complex.

Third, since much of our "view rendering" cost is actually computation not directly related to making html, React can't reuse pieces of those computations anyway. You'd need to code your "math" in terms of React components even though there's no html associated with them.

Fourth, if your dataflows are dynamic enough, like a spreadsheet, even if React actually could optimize those computations (which it cant), it wouldn't even be helpful, because while Views are trees, many computations are not. For example, in a spreadsheet: Edit cell C7, quick what is the tree of computations you can skip? The question doesn't even make sense, because spreadsheets aren't trees. Spreadsheets do complicated graph dependency tracking, with cycle analysis and all that, in order to make this fast. React doesn't do that.

As an example of how dynamic Hyperfiddle is, go to [http://dustingetzcom2.hyperfiddle.net/](http://dustingetzcom2.hyperfiddle.net/) and in the top toolbar click "data" and then click "dev". Dustingetzcom2 is not coded in javascript, its coded in data, and you edit the data live in the dev pane, and the right things update live as you make changes. That's why the render computation is so expensive.

<comment><USER19> No need to try to explain why you think it is slow based on your understanding of React.

Facts are always better. Good news is: I suspect you have no React issue. How is your NODE_ENV? Set to production? After looking at your website, you have no perf issue caused by React itself! Remove the blinking cursor made with setInterval, and use CSS animation for that. You'll see :)

<comment><USER18> Here are the walmart labs patches I mentioned: [https://github.com/walmartlabs/react-ssr- optimization](https://github.com/walmartlabs/react-ssr-optimization)

That link has the data points you are looking for, react SSR problems are well understood and documented and have been for some time now, that repo is a year old

also see [https://www.reddit.com/r/reactssr/](https://www.reddit.com/r/reactssr/)

</comment></comment></comment></comment></comment></comment><comment><USER20> Isn't the whole point of server-side rendered React to render it just once, when building the website, and then serve it as static HTML/JS/CSS assets using a static webserver?

<comment><USER21> That's one use case.

The other is for performance/seo where the initial markup for the app is generated and served to the client as HTML, then the React app bootstraps on the client and takes over managing the DOM.

<comment><USER22> This is what I'd like to see a performance comparison for.

1\. Initial load using client-side vs server-side rendered. (Server-side should be faster.)

2\. Warm load using client-side vs server-side rendered. (Client-side should be faster.)

Comparing to static is interesting, but not really an option if you're serving dynamic content.

</comment></comment></comment><comment><USER23> The author mistakes increasing concurrent request as being some sort of proxy for concurrent users. Once you have maximized rps or maximized cpu, increasing concurrent just artificially hurts your average latency.

Max RPS equals number of users you can serve per second. Concurrency should just be tweaked until you eliminate the network latency of your test framework.

</comment><comment><USER24> So I thought the entire point of SSR was to speed up initial page load - <USER2> you pre-render all the static parts of the page, including what happens after routing, but before any API calls, so that your webserver can cache that static HTML for that route and serve it up. What this means is that the user immediately sees much more of a rendered HTML page, rather than seeing a blank page for 2 seconds and having to wait to download and run a massive JS bundle first.

<comment><USER25> No, it was to improve SEO and other clients without JS

<comment><USER26> That's part of it, but getting viewable content to the user as soon as possible is just as big. Without SSR, the user has to wait for the JS to download, parse, and execute before they see anything on the page.

</comment></comment></comment><comment><USER27> Related:

Node.js templating engine benchmarks:

[https://github.com/marko-js/templating-benchmarks](https://github.com/marko- js/templating-benchmarks)

Framework SSR benchmark (Vue, React, Preact, Rax, Marko):

[https://hackernoon.com/server-side-rendering-shootout- with-m...](https://hackernoon.com/server-side-rendering-shootout-with-marko- preact-rax-react-and-vue-25e1ae17800f)

</comment><comment><USER28> For this reason, we don't use SSR for pages that change often, and turn it off completely for authenticated users. Some performance analysis showed it was actually _slower_ in the average case than shipping the JS and having the client render it themselves, especially with a hot cache.

This still provides what we wanted anyway; the ability for pages to easily be viewable without JS and easily indexed by search engines.

</comment><comment><USER29> These results are not surprising to me but it's great that they were published because people have been very quick to jump on the hype bandwagon for these kinds of projects.

I think that the idea of the isomorphic JavaScript app never actually worked in practice. MeteorJS already had a really good go at it.

Sharing JavaScript modules between the client and the server is great but when you start to pretend that the backend and the frontend are the same environment, you're bound to run into all sorts of problems and create inefficiencies.

The kind of performance penalty incurred by server-rendered React is bound to make your system vulnerable to DoS attacks or at best make it unnecessarily expensive to operate.

When programming abstractions shift too far away from the reality of the underlying architecture, you will start paying dearly and the cost won't be worth it in the long run.

In my opinion, the client-server divide is a fundamental aspect of multiuser applications and no amount of abstraction can make it go away.

</comment><comment><USER18> [https://github.com/walmartlabs/react-ssr- optimization](https://github.com/walmartlabs/react-ssr-optimization)

React definitely needs work here and i think the right people are quite aware of the issues.

</comment><comment><USER30> Could the performance be improved if you call React.createFactory() and then stream the factory call like this[0] code?

[0]: [https://github.com/styfle/react-server-example- tsx/blob/4586...](https://github.com/styfle/react-server-example- tsx/blob/4586f3431b4bfd424179da3aad2c6adbddb0de10/src/server.tsx#L12)

</comment><comment><USER31> I'd be curious to know if this cost is similar with Ember's implementation of SSR, Fastboot.

</comment><comment><USER32> If you're looking for DOM in the front, Strings in the back, check out Bel – [https://github.com/shama/bel](https://github.com/shama/bel)

</comment><comment><USER33> Did anybody try [https://github.com/shakacode/react_on_rails](https://github.com/shakacode/react_on_rails) for this comparison?

</comment><comment><USER34> well wasn't that clear? Isn't something like a Template Engine quite CPU intensive? Things were node.js performce poorly?

<comment><USER35> They include a comparison with using ES6 Template literals (native JavaScript string interpolation), and saw 10x increase over React. The native string interpolation actually came out just behind serving straight static files. JavaScript CPU performance is actually quite high among interpreted languages.

So to answer your question more specifically, no I don't think it is clear. What this is specifically isolating as the performance problem is that using React as a template renderer on the backend is not performant, not because of NodeJS performance, but because React is realistically not really specialized for this.

<comment><USER36> Does anyone actually use vanilla JavaScript string literals for all their backend rendering?

<comment><USER37> I do this. It's surprisingly effective, both in actual performance and developer productivity. The one area where it is useless however is for mutating DOM. It's easy enough to create DOM using template strings, but if you say need to render something and then mutate it later on in you render function, it becomes terrible since you either have to do tricky string manipulation, actually create the DOM and use methods to mutate it, or use some framework at which point you may as well just give up on template strings altogether.

But for any case where you're basically going in the one direction, i.e. data -> DOM and not changing things once rendered it's great.

<comment><USER38> I have no personal experience with it, but Google's been toying with this project: [https://github.com/PolymerLabs/lit- html](https://github.com/PolymerLabs/lit-html)

Might help with some of those pain points

</comment></comment></comment></comment></comment><comment><USER39> I'd like to see the results with php through node-phpcgi to render those pages. So we'd have gone full circle at last.

</comment><comment><USER40> My clients get to render their own html - it's not really that bad if you bundle, split and cache the code.

</comment><comment><USER41> Been using template literals for basic apps instead of the usual overhead. Mostly loving it.

</comment><comment><USER42> Does React build any cached or compiled intermediates for its templates?

</comment><comment><USER43> I'd love to see a side-by-side comparison to Marko.js ([https://markojs.com/](https://markojs.com/)). It has a lot of react-like features, but was built from the ground up for SSR speed.

<comment><USER44> Marko keeps some bechmarks here: [https://github.com/marko-js/isomorphic-ui- benchmarks](https://github.com/marko-js/isomorphic-ui-benchmarks)

Not too sure how accurate or biased they are, though.

</comment></comment><comment><USER25> Render on write, not on read.</comment>


Trump to launch crackdown on violent video games after mass shootings - <AUTHOR> https://www.independent.co.uk/life-style/gadgets-and-tech/gaming/trump-video-games-toledo-shooting-8chan-el-paso-press-conference-today-a9040066.html <comment><USER2> Regulate simulations of a problem, but not the actual problem? IOW, pandering.</comment>


We Need to Talk about Intestinal Worms - <AUTHOR> https://blogs.scientificamerican.com/observations/we-need-to-talk-about-intestinal-worms/ <comment><USER2> "Hookworm then rampant in the American South" \- what's that nonsense? It is _still_ rampant in the poorer parts of the American South: [https://www.theguardian.com/us-news/2017/sep/05/hookworm- low...](https://www.theguardian.com/us-news/2017/sep/05/hookworm-lowndes- county-alabama-water-waste-treatment-poverty)</comment>


Elon Musk Learns Faster and Better Than Everyone Else - <AUTHOR> https://medium.com/accelerated-intelligence/learn-like-elon-musk-fe8f8da6137c <comment><USER2> I've found the best way to learn something is to be willing to make the attempt despite limited confidence. This sort of fearlessness makes a person seem like an idiot, but as long as you keep learning from mistakes you keep getting better.

The people who spend all their time trying to not do something stupid, end up just learning how to not look stupid and how to do it the way the person before did.

Does Elon Musk look like an idiot on Twitter? Totally! Is he learning? It's a pretty good bet. He's a human being who is willing to take the risk of looking stupid. It's a luxury afforded to most billionaires.

</comment><comment><USER3> Based on his recent Twitter activity, no, I don't think he does.</comment>


What Question Does Your Product Answer? - <AUTHOR> http://howtosplitanatom.com/questions/purpose-of-product/

<comment><USER2> There is a quote I love from the movie "city slicker" that reminds me of this article

 _You know what the secret of life is? No, what? This. Your finger? One thing. Just one thing. You stick to that and everything else don't mean shit. That's great, but what's the one thing? That's what you've got to figure out._

</comment><comment><USER3> And to answer the right question, it is vital to take the users point of view to honestly see if your product will take off.

Imagine how highly motivated you will be when after careful reflection, you know for sure fact that your product will be truly something that everyone will want and that it will be there to last.

</comment><comment><USER4> "Good products solve a single, focused problem."

We could go semantic and debate product vs. service and all, but I am going to assume that the author means both when he says "product".

What single, focused problem does Second Life solve?

I think the define-and-solve approach is limiting. You stay focused on the status quo. Innovation is a distraction.</comment>


VMWare will join OpenStack - <AUTHOR> http://gigaom.com/cloud/surprise-vmware-will-join-openstack/

<comment><USER2> This is good. OpenStack is genuinely open and having consistent ways of moving data and config in an out of any configuration is a great step forward.

The question is why VMware - the biggest player in the corporate VM space - would do this. They have great lock-in already so this is a commercially questionable decision. They don't have a strong challenger in the place where virtualization makes money so it will be interesting to see where they take it.

<comment><USER3> I'd be more inclined to recommend VMWare for our in-office needs if I can conveniently move VMs off to an OpenStack supporting public cloud. VMWare's offerings are good enough to compete with any private cloud out there but not having any interoperability with what seems like the future of the open cloud could hurt them.</comment></comment>


Putting Down Elm - <AUTHOR> http://mkndrsn.com/2016/06/06/putting-down-elm/ <comment><USER2> The title is unfortunate. At first I though...wait why are they discontinuing Elm, what did I miss.

I've never written anything in Elm but that short post makes me want to try it. Sounds like a pretty great feature of a language to have easy to follow error messages you can readily pick up. This also made me chuckle

"""I thought Elm was a pure, functional language, but this is one hell of a side effect."""

<comment><USER3> The error messages in Elm really are outstanding. I've never used a language that has such clear, concise, and human-friendly error messages. It's a high water mark, and I hope other programming languages are inspired to try to equal what Elm has accomplished.

</comment></comment><comment><USER4> You should always let something else 'drive' your coding. Lots of people like tests. I personally am not a huge fan of TDD, though it's better than a lot of alternatives.

Essentially, you set a visible goal. Passing test, compiling program, running command, visible widget on a browser. Run the test / command / browser URL and watch it fail. Let the error message you get determine your next step.

It makes a good debugging workflow too. The first step is to get a reproduction. Then you need to set up an environment where you can repeatedly and idempotently reproduce the bug at will. Then all you have to do is keep trying and learning things about the system until you know enough to devise a fix. Here you can manipulate the command itself to exercise less of the system, giving you a clearer idea of where the bug is.

Whereas if you're building a new feature, you want to keep the command static until you see what you want to see.

There's nothing magic about programming languages or paradigms that allows you to do this more easily. It's just how well you know your system. Some domains are trickier. You need special tools and expertise to reproduce network errors, and God help you if your stack isn't memory safe.

</comment><comment><USER5> This kind of comment about Elm is quite hard to understand without context. Have you ever used a typed language before? Have you ever used a pure language before? Is there something special about Elm that gives you this kind of benefit, or do other languages do the same thing?

<comment><USER6> Haskell does the same thing.

EDIT: I didn't mean to say that Haskell is as easy, or that the error messages are as good. I just mean that the error messages can give you a nice reminder of what you were working on, which I believe was the point of this post.

<comment><USER7> Haskell had poor error messages last I tried it. Have they improved?

<comment><USER8> Haskell has... precise... error messages. As I learn more about it, the errors are become more useful, and driving my development in a similar way to with Elm, however with Elm the learning curve is far shallower _and_ the compiler helps you up it, whereas with Haskell I'm always just googling types to figure out what the compiler is trying to tell me.

<comment><USER9> Many of the error messages become clearer with experience, but this is mostly due to developing an intuition for what is actually wrong with your code based on the error message you see, not due to the helpfulness of the error message. Often the actual source of the error is in a different place than what is reported. Consider what happens if you mean to concatenate two strings but forget to put `++` in there:

        Prelude> "foo" "bar"

        <interactive>:3:1:
            Couldn't match expected type '[Char] -> t'
                        with actual type '[Char]'
            Relevant bindings include it :: t (bound at <interactive>:3:1)
            The function '"foo"' is applied to one argument,
            but its type '[Char]' has none
            In the expression: "foo" "bar"
            In an equation for 'it': it = "foo" "bar"

Yikes. Even worse, consider a similar situation with numbers:

        Prelude> 1 2

        <interactive>:2:1:
            Non type-variable argument in the constraint: Num (a -> t)
            (Use FlexibleContexts to permit this)
            When checking that 'it' has the inferred type
              it :: forall a t. (Num a, Num (a -> t)) => t

Also the parser errors in Haskell are terrible. That the community has so long put up with "parse error (possibly incorrect indentation or mismatched brackets)" is a marvel to me, and is one of the most irritating errors to fix because of the (at least apparent) simplicity of improving it.

<comment><USER10> The first error message is good: it helpfully includes the exact expression that craps out, and it means, matching intuition about how Haskell should be compiled, that the expression "foo" "bar" could only make sense if "foo" were a function from [Char] (i.e. the type of "bar") to some type t, but unfortunately "foo" is a [Char]: everyone should understand it easily, even if gratuitously introducing other names (it and its type t) and details about the compiler making up type equations is highly inelegant.

The second error message, on the other hand, proves that the first one is a lucky accident.

<comment><USER11> >The second error message, on the other hand, proves that the first one is a lucky accident.

No, the second error message just shows that there's more options there so the error message is vague and not very helpful. The first one is not an accident, it is the standard type mismatch error.

<comment><USER10> My point is that 1 2 should give the same type of error message as "foo" "bar", because it is the same kind of error (1 isn't a function with one or more arguments).

The compiler exposes that when numbers are involved it attempts (and fails) some fancy and unexpected reasoning involving forall, while with plain type constructors like [Char] it attempts (and fails) straightforward and intelligible pattern matching.

Figuring out the type of 1 and 2 might be more difficult than figuring out the type of "foo" and "bar", but the special rules should be hidden: a compiler that cares about practical usage would provide unified and clear error messages, possibly listing sets of alternative types it was unable to choose from.

<comment><USER11> >My point is that 1 2 should give the same type of error message as "foo" "bar", because it is the same kind of error

And my point is that no it should not. "1 2" is more ambiguous, it could be more things, hence there is a more ambiguous error message.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> This is the perfect example of the content-free HN posts that are topping the charts lately. It contains not a single example of a "helpful error message." Nor a single line of code from the language in question. Just a 173 word free- verse poem with some feel-good handwaving.

If this were a post about soap (the salt, not the protocol) we'd downvote the post as obvious content-free shilling. But because it's some obscure language that doesn't even make the top 100 TIOBE language list, here we are, upvoting someone we've never heard of, celebrating his opinion of awesome compiler error messages that none of us has ever seen, for a language that nobody uses.

[http://www.tiobe.com/tiobe_index](http://www.tiobe.com/tiobe_index)

<comment><USER13> In the time it took you to write your content-free comment, you could've googled Elm and seen the error messages yourself.

<comment><USER14> Great, I look forward to future HN posts such as "Elm is really super. The rest of this article is left as an exercise for the reader."

</comment></comment></comment><comment><USER15> This blog post seems to be more explanatory about the error messages of Elm: [http://elm-lang.org/blog/compiler-errors-for-humans](http://elm- lang.org/blog/compiler-errors-for-humans)

</comment><comment><USER16> Elm has the best error messages of any language I have ever used.

I have dreams about it one day replacing JS as the front end language of choice.

</comment><comment><USER17> What does this mean? There is almost no detail in this other than "Wow Elm is great and the compiler gives persistent, detailed messages"

which I think most people interested in Elm already knew.

<comment><USER18> I guess the only new addition is that a side-effect of the very helpful errors is that it's easy to eventually come back to your work later on.

There's also a lot less state to keep in your head, as it's usually a lot more transparent.

</comment></comment><comment><USER19> This has always been my experience with TDD, at least if you always leave yourself a failing test when you go. A lot more labor-intensive, since you are essentially writing the "compiler" as you go, but a similar effect.

<comment><USER20> I think "gradual typing" like Flow might be a nice middle-ground.

You're still free to quickly sketch out ideas without worrying about type checking, but you can solidify things by just adding /* @flow */ to the top of a file and fixing the errors.

I haven't actually tried Elm though, so maybe a "middle-ground" isn't necessary.

<comment><USER13> This will sound counterintuitive to dynamic language people, but prototyping is actually much easier with types. I often find myself rewriting 50 to 75% of the codebase in the early stages of prototyping, and without types I'd be much less willing to do that, settling for a less than ideal design. This design will then be the base of a potentially large project, which amplifies early mistakes even more.

<comment><USER21> For me types make prototyping WAY faster, especially if "throw" or some other keyword satisfies the return type of a function. I can write out the function signatures and data types I need and get things to line up with the help of a tool that tells me exactly what I need to do (the compiler). This lets me quickly find a solution without having to actually implement any of it, and then I have a skeleton ready to fill in with details.

<comment><USER22> > For me types make prototyping WAY faster

Agreed. I can prototype an idea almost entirely in types, and if the types make sense, then the implementation often follows naturally.

</comment></comment></comment></comment></comment><comment><USER23> ok nice. We know that. I'm personally touching Elm only after they have something like ComponentDidMount from React or something which is better implementend than "wait 50msec and do something like set focus" on their (virtual) DOM rendering is solved: [https://github.com/evancz/elm- todomvc/blob/8be8914582870d599...](https://github.com/evancz/elm- todomvc/blob/8be8914582870d59989ce518e6c7d38f8081faaf/index.html#L18-L25)

<comment><USER24> I'm not sure this is a fair criticism. The nice thing about this tiny chunk of code is that there is only one aspect of this example program that needs to manipulate the already instantiated DOM, and that tiny chunk is explicitly brought up to the top level and separated and connected back to the program via the port mechanism. It would certainly be worse if this magic happen behind the scenes.

Of course it could be better, and that's probably what you are getting at. Ideally the machinery provided for building web applications would be more aware of the nature of web applications and have something in the box (still explicit and obvious, but in the box) to do something like setting focus.

<comment><USER25> It's absolutely a fair criticism. The real DOM is stateful, elm's virtual DOM is not, and elm doesn't provide any tools to manipulate the state of the real DOM. This impedance mismatch is bound to cause problems any time you are dealing with the stateful aspects of the DOM. And solutions like the one linked to by GP are error prone and fragile.

</comment></comment></comment><comment><USER26> To me, the most promising thing about elm is how much improvement it has seen. The last minor version was a huge leap forward for building real things AND for beginners. The makers of elm (seems to mostly be Evan Czaplicki) think about things the same way I do, except they are thinking about it more than I do and more carefully. Whether it's elm or anything else, I'm glad the tool- explosion has let more people use tools they vibe with. Hopefully it will help more random people (like me) do more cool stuff.

</comment><comment><USER27> Elm is a great language for web. It's evolving but there are some bits that need some rework/improvement/rethought like the canvas performance and managing random number generation. This is difficult with purely functional architecture. But there are a quite a lot of good thought gone into making the whole functional programming user friendly and a pleasant experience. Kudos to the creators/maintainers

</comment><comment><USER28> I feel like something clicked for me once I realized that all functions in Elm are curried by default. Cool feature.

</comment><comment><USER29> in my experience, when I am stuck figuring out types, I just let the compiler do it. As the error messages are so well-formed, it tells me exactly which lines are inconsistent and how to put the types back together.

most compilers tell you there's a problem but none outline how to fix it the way Elm does

</comment><comment><USER30> Fell into the bait! Clicked and disappointed at a different content than expected</comment>


Best Websites for Entrepreneurs and Startups - <AUTHOR> https://online.abdn.ac.uk/global-mba/blog/best-business-websites/ <comment><USER3> Two of the listed websites refer to a design blog and site of the day website. As a designer, the problem I've always had with those categories is a lack of data backing up claims of good design and usability. It still feels like industry writeups are based on anecdata, personal experience presented as fact.

Yes, there are some mostly accepted guidelines, such as don't choose a font that's highly distracting, don't go overboard with colors, make things that are important easily accessible to the user... though even those can be broken in certain cases.

But when we extrapolate good practices simply based on what other companies do, we can be susceptible to make assumptions that are true... until they are not. For example, hiding navigation in the hidden left menu (via the hamburger icon) is completely fine because its practiced by most Android apps and Facebook/Spotify... until Facebook/Spotify redesigns their iOS apps to navigate main sections from the bottom, and Google releases their 2016 Material Design style guide that explicitly provides specs for a bottom navigation.

Then, for websites that get showcased by dint of high ratings from design judges, it seems like it's largely based on what's visually stunning, leaning heavily towards one-off marketing sites than considering whether or not it was ultimately successful in terms of impacting the users. I've certainly seen my fair share of things that seemed to look and feel good, only to perform quite badly in a real world environment. That's not to say that inspiration and aesthetics have no merit, but instead that design is a complex discipline that includes many considerations of the experience from a user, and that only focusing on the visual reinforces the unfortunate stereotype that designers only care about what looks pretty.

<comment><AUTHOR> That's actually a very interesting point of view that I hadn't considered - that people blindly adhering to 'accepted' design guidelines might be stifling unique design approaches or perpetuating mistaken assumptions.

Given that, are there any sites that would be better recommended for startups/entrepreneurs who are inexperienced in web design as this article seems to be aiming at? Or is the whole point that people shouldn't rely on conventional design wisdom?

</comment></comment><comment><USER4> Listing their own Business Toolbox at the bottom is a pretty great submarine marketing strategy. Plus, now I've visited the University of Aberdeen's Business School site. Well done.

Not a bad list, overall for people completely outside the market but I somewhat wonder about their approach. Are they looking for tools, or for techniques? Both? (Shopify / Automattic presence indicates maybe both?) No mention of companies I would consider similar enablers / bloggers about starting up and no mention of VC-type discussions about starting up.

<comment><AUTHOR> That's something I've noticed becoming increasingly common in list articles of this kind actually - probably because it's pretty effective as you say.

The approach seems to encompass any mix of things that could be of use to people setting up either a business or a website. Which companies in particular did you have in mind? There's actually a distinct lack of explicitly finance or investment related sites, now that you mention it - <USER2> tools and techniques are almost universally related to digital/online business practice.

</comment></comment><comment><USER5> Duplicate of: [https://news.ycombinator.com/item?id=14089343](https://news.ycombinator.com/item?id=14089343)

<comment><AUTHOR> Oh, what's the procedure in the case of duplicate submissions? Should I remove and upvote previous or...?

<comment><USER5> There's a search box at the bottom of the page to check before posting duplicate links. These two URLs are the same though so it's odd they weren't automatically linked. Perhaps one was edited after being submitted - I'm not sure.

<comment><AUTHOR> Ah thanks very much!</comment></comment></comment></comment>


If you Google the letter n, Netflix is the #1 organic result, how? - <AUTHOR> https://www.google.com/search?q=n&rlz=1C1SQJL_enUS774US774&oq=n&aqs=chrome..69i57j69i60l5.1285j0j7&sourceid=chrome&ie=UTF-8 <comment><USER2> Your search results are personalized, based on all the data Google has about you. For me (not using Google; going out of my way to block trackers) the first results are all Wikipedia entries.

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

[https://en.wikipedia.org/wiki/%C5%83](https://en.wikipedia.org/wiki/%C5%83)

[https://en.wikipedia.org/wiki/%C3%91](https://en.wikipedia.org/wiki/%C3%91)

I didn't have Netflix show up in the first 15 pages and stopped looking after that.

<comment><AUTHOR> Wow! Surprised by that, didn't expect there to be such variation from person to person.

</comment></comment><comment><USER3> 1\. Broswers autofill URL's. 2\. Users type "n" and Netflix.com populates. 3\. Browser address bars double as search fields. 4\. Google's algorithm learns that when users type "n" they're more often intending Netflix than any other result.

<comment><AUTHOR> Thanks!

</comment></comment><comment><USER4> Way more people want to click on a link that takes them to netflix than to a wikipedia page about the 14th letter in the english alphabet or a random game from 2004.</comment>


Why Use Postgres - Part 2  - <AUTHOR> http://craigkerstiens.com/2012/05/07/why-postgres-part-2/ <comment><USER2> Having recently been bitten by a 20 hour schema change to a very large table in MySQL I have been looking at Postgresql more seriously.

My biggest issue with it having used it for other projects is getting the dammed thing setup and working to begin with. I could never find a decent tutorial (or rather one that fits my mindset) of how to do the following,

1\. Install 2\. Setup users, including how to set it up on a local development machine with 'root' user who can do anything (saves time in dev) 3\. Import/Export SQL/Backup files

I managed to do all 3. Once.

I'm sure its out there, and I would switch in a heartbeat were these steps much easier to work out. As it is I can just copy the table, run the alter in the background and rename the tables the next day. Slower, but doesn't cost me any time and works.

<comment><USER3> The bootstrap is not really hard when you've done it once, just jot it down somewhere.

In my experience most people stumble because the network security in postgres is pretty tight by default.

This is easily fixed and needs to be done only once.

First: Find your pg_hba.conf. It's in the database-directory, that's often linked to /etc/postgresql.

      # Backup the original
      $ cp pg_hba.conf pg_hba.conf_orig

      # Now replace it with our desired security settings
      $ cat >pg_hba.conf <<EOF
      # Require password auth from remote hosts
      # localhost and local socket are trusted
      host  all all 0.0.0.0/0 md5
      local all all trust
      host  all all 127.0.0.1/32 trust
      EOF

      # restart
      $ /etc/init.d/postgresql restart

From now on you can connect as _any_ user from localhost without a password. Thus, we can now just go about our business.

      # connect as user postgres (the super-user)
      $ psql -U postgres
      postgres=# create database dummy;
      postgres=# create user bob with password 'pony';
      postgres=# grant all on database dummy to bob;
      postgres=# ^D

      # Now you have a database that user bob can use.
      # From remote he will have to use the password 'pony'.
      # From localhost no password needed because of our pg_hba settings above.
      $ psql -U bob dummy
      bob=> create table ...

<comment><USER4> I would be wary about trusting all connections from localhost. As vulnerabilities are many, getting a local unprivileged shell isn't exactly hard and as opening a socket connection isn't exactly a privileged operation.. you could expose yourself to a nasty bootstrap attack. Probably better to trust the local unix domain socket, and make it accessible by root only... if you really need it.

<comment><USER3> _I would be wary about trusting all connections from localhost._

The only place where this is an issue would be hosts with multiple _untrusted_ users, and these are becoming very rare.

 _getting a local unprivileged shell isn't exactly hard_

Sorry, that's nonsense. The entire internet relies on the fact that this _is_ relatively hard, unless you neglect basic security precautions.

<comment><USER4> You make a good point. Conversely, a part of basic security policies is to present as little attack surface as possible. Ensuring that you're not trusting local connections with root equivalent access to your database is a good way of doing that. Modern GNU/Linux distributions have many thousands of packages installed, some of which with fairly open Internet access. Could you put up a default deny firewall to prevent that? Yes. Given that, in most systems there will always be holes punched in those firewalls which allow attacks through as those machines are typically used to serve traffic and do actual work. If you are exploited by a vulnerability in some random package you have installed then you /will/ have potentially multiple /untrusted/ and /hostile/ users on your system. Now, assuming there isn't a local privilege escalation attack to which your kernel is vulnerable, they'll be looking for services which treat local sockets as trusted and attempt to bootstrap from there. A vital concept of basic security precautions is that one doesn't just prevent attacks through secure defaults and front-line security precautions (i.e. firewalls), but one must both contain and detect successful penetrations when they do occur. You must have defence in depth, and not just a hard shell of security, because you can never really tell which one of those protective safeguards will fail due to bugs, human error, or technical incompetence.

<comment><USER3> _Now, assuming there isn't a local privilege escalation attack to which your kernel is vulnerable_

That's an invalid assumption (extremely unlikely).

 _You must have defence in depth, and not just a hard shell of security_

When you can't trust localhost anymore then your defenses have long failed.

<comment><USER4> I believe the null hypothesis should be that you assume there are vulnerabilities in those systems. Your assertion that it's extremely unlikely that local privilege escalations exist is demonstrably false. In fact a quick query of the CVE database shows a large number of /known/ vulnerabilities ( [http://web.nvd.nist.gov/view/vuln/search-results?cves=true&#...</a> ). Regarding the statement that if you can't trust localhost then your defences have failed... well, duh. The point is to limit the damage by having multiple layers of defence. If a script kiddie manages to use UltraPWN2000 to get an unprivileged shell on your box, you don't want them to be able to easily just drop all tables if they're not smart enough to use a local privilege escalation (assuming they can compile locally anyway). You won't be able to prevent all damage from a skilled attacker but you should attempt to mitigate it and give yourself time to respond to it. You don't trust your locked front door to protect your valuables, you put them in a safe.

<comment><USER3> _Your assertion that it's extremely unlikely that local privilege escalations exist_

You misread me. I meant the opposite.

Your argument was based on the premise "assuming there isn't a local privilege escalation attack to which your kernel is vulnerable". I said this premise is invalid (as you just confirmed yourself).

 _You don't trust your locked front door to protect your valuables, you put them in a safe._

The front door is your firewall. The safe is your host. When someone breaks into your host then it's game over. When you have too much spare time you can attempt to layer further at the host-level but that's usually an exercise in futility.

<comment><USER4> I can see that we don't fundamentally disagree on many issues. Attempting to protect from all on-host attacks is pointless. Though I don't disagree with you in the majority of what we've discussed, I will always stand up for simple changes to settings that make it just that much harder for unauthorised users to cause trouble. That said those changes must not add too many onerous access requirements for authorised users. Of which, I don't believe asking people to have sudo access to your machine to have super-user access to your database is one.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> One of the other nice things about Postgres is the pretty much annual release of a new version. 9.2 should apparently hit beta in the next week or so, which will bring some cool new features : [http://archives.postgresql.org/pgsql- hackers/2012-05/msg0034...](http://archives.postgresql.org/pgsql- hackers/2012-05/msg00344.php) .

<comment><USER6> Are there any reasons not to use postgres, as a replacement for mysql?

<comment><USER7> If you use multi-master replication, MySQL Cluster, or depend on properties of one of the alternative storage engines would be my big ones.

<comment><USER8> Hopefully PostgreSQL-XC might fix this lack of good multi-master replciation in a couple of years. PostgreSQL-XC 1.0 will be released soon.

</comment></comment></comment></comment><comment><USER9> I had no clue that Postgres supported LISTEN and NOTIFY. Granted, it's a new addition, but this is really slick:

<http://www.postgresql.org/docs/9.1/static/sql-listen.html> <http://www.postgresql.org/docs/9.1/static/sql-notify.html>

<comment><USER10> New addition?

listen and notify go back to at least 6.4 which came out 1998 ish <http://www.postgresql.org/docs/6.4/static/sql-listen.html> <http://www.postgresql.org/docs/6.4/static/sql-notify.html>

What might have changed is the implementation though. I seem to remember that some point in the past I was investigating listen/notify and the driver (libpq) was forcing you to handle LISTEN by polling (calling PQnotifies periodically) which doesn't really help compared to polling on your own.

This has not changed so far:

<http://www.postgresql.org/docs/9.1/static/sql-listen.htm>

states

> With the libpq library, the application issues LISTEN as an ordinary SQL > command, and then must periodically call the function PQnotifies to find out > whether any notification events have been received.

It might be possible for drivers working without libpq by talking the postgres protocol directly on the wire to get real asynchronous behavior, though I don't know anything about how this is being handled on the server right now (it might still be polling internally on the server end).

<comment><USER11> I'm not sure about long ago, but the recent version of libpq has NOTIFY working asynchronously (you can stick the connection file descriptor in a select(2) and you'll get woken up when a notify is available).

<comment><USER8> Hmm, pretty certain nothing has changed recently there either. At least as far back as 7.1 the documentation has remained the same about this.

<http://www.postgresql.org/docs/7.1/static/libpq-notify.html>

What has happened recently though is that more language bindings to libpq have started exposing the NOTIFY functionality in more convenient ways.

</comment></comment></comment></comment><comment><USER12> Can anyone point me at a HOW to use Postgres guide? I know my way around MySQL and SQL Server pretty well, but Postges is fairly new to me. I did one project where I migrated several websites from one server to another but I kind of fumbled my way through it. Would love to see a guide for getting started with Postgres for those who are already familiar with MySQL.

<comment><USER13> The official docs are fantastic. The newer PacktPub books are also pretty good <http://www.packtpub.com/postgresql-90-high-performance/book> and <http://www.packtpub.com/postgresql-9-admin-cookbook>

<comment><USER14> It should be said that the older books have never been very good. I have read probably all of them, none come close to the documentation on the website.

</comment></comment></comment><comment><USER15> Has slowness of SELECT COUNT() on large datasets been addressed in any way? Last time I checked it was responded with "it's slow because of how we do things here" and if you want to count records fast "you count them yourself" (not actual quotes from anyone, just tl;dr of some answers I've seen).

<comment><USER16> I kind of hate this "tl;dr" culture. I can explain the reason why this is never going to change (though it may get better with index scans) but I expect you'll just see a wall of text and decide not to read it. But if you never read long answers, you have no right to expect solutions to your problems or to understand anything. So I hope you'll read this, it may help.

PostgreSQL and most modern, ACID-compliant RDBMSes use MVCC instead of locks. MVCC has a lot of upsides, namely, you almost never need table-level locking for writes, but it ensures you need to look at the whole table to do COUNT. That's because MVCC is basically multiple parallel universes for data. What you see depends critically on which transaction you're in when you look.

For example, suppose you have a process that needs to know the number of users in some user table. You start your transaction, and then another process starts a transaction that goes through and deletes certain users. While this is happening, you need the count. In MVCC, deletion doesn't delete, it just marks rows with the transaction ID range in which they're visible. The rows that are being deleted by the other process are just being marked dead as of that process's transaction ID, but your transaction ID is below that one, so they're not dead to you. Later on, when the youngest transaction alive is older than the oldest transaction that can see these rows, PostgreSQL will actually expunge the data (VACUUM does this).

Because of MVCC, there is more than one legitimate answer the question of COUNT; potentially, one for each transaction in progress. The answer is changing constantly. People tend not to think in these terms; we tend to think, well the table has so many rows in it, right? Why don't you just increment the count when you write one? It's not true, because with ACID compliance, uncommitted transactions should not have visible effects until they commit and transactions in progress should not see anything vary during their operation. So there really are multiple right answers at any given moment. The expectation that SELECT COUNT(*) will be fast is built on the assumption that the database has some sort of master count of what rows are in the table it can just glance at. But it doesn't, and to have one would require removing MVCC altogether and using locks instead.

<comment><USER17> I'm not sure I buy your argument. It is certainly true that with MVCC "there is more than one legitimate answer the question of COUNT", but that's true for _any_ query, not just COUNT. Given that we can maintain transactional correctness for the data, it's not at all clear to me why the same mechanisms cannot be used to maintain transactional correctness for the _meta_ data.

<comment><USER18> I agree. Given count(star) is a common need you'd think there would be multiple count(star) results in the metadata for the table, each with a generation associated with it.

<comment><USER8> I do not see how this would be implemented without introducing extra locking which would harm concurrency, which would remove some of the performance advantage of having MVCC.

Now I see it could be worth taking that penalty on specified tables, jsut like you do for indexes. And some databases do support this in a more general form: materialized views.

<comment><USER16> I think you could fake this proposal with triggers. It might be worth seeing what the additional cost is.

<comment><USER15> Proper solution (not fake with triggers) should be at most as costly as having partial index on the table.</comment></comment></comment></comment></comment></comment></comment>


Bitter Pill - <AUTHOR> https://www.firstthings.com/article/2010/05/bitter-pill <comment><USER2> > One important strategy that allows women both to create a safer exit for > themselves and to increase their bargaining power going into a marriage is > to develop relatively more market earning power—more market-rewarded human > capital—than they would have in past decades.

This one is very interesting! Women are protecting themselves from bad marriage deals by getting work that pays more, thus increasing their value. Scandinavian countries are some of the most progressive in the world (equal pay with gender etc). Yet there is a increasing amount of divorces and children born out of wedlock in these countries.

[http://ec.europa.eu/eurostat/statistics- explained/index.php/...](http://ec.europa.eu/eurostat/statistics- explained/index.php/Marriages_and_births_in_Sweden)

</comment><comment><USER3> The argument falls flat for me due to the assumption that one only participates in the "marriage market" OR the "sex market".

Seems a false dichotomy, not backed by data,and the rest of the argument depends on it.

<comment><USER2> I would say that people mostly participate in the sex market until they find someone they're willing to settle down with.

If you were seeing someone who you considered "marriage material" you wouldn't be on the sex market. Until that time happened I can't see why you wouldn't participate in the sex market.

</comment></comment><comment><USER2> I'm only just into the introduction and I am very engaged. The intro brings up some very interesting arguments.

\- Contraception is damaging to society

\- Massive redistribution of wealth and power to men

\- Suggestions that taxing men and subsidising women and children will fix it

I'll update this as I read through the article.

> Their graph, below, shows that, for example, the percentage of Americans > married at age 30 fell from roughly 85 percent in 1960 to roughly 60 percent > in 2000. Assuming that sexual activity has not decreased over the same > period (clearly a safe assumption), this implies increased participation in > the sex market over the same period.

I think this may be a flawed statement. Millenials are having less sex than previous generations: [https://www.washingtonpost.com/local/social- issues/there-isn...](https://www.washingtonpost.com/local/social-issues/there- isnt-really-anything-magical-about-it-why-more-millennials-are-putting-off- sex/2016/08/02/e7b73d6e-37f4-11e6-8f7c-d4c723a2becb_story.html?utm_term=.bd7fc81479b0)

> It may be biologically inevitable that relatively more men will populate the > sex market and relatively more women will populate the marriage market.

It's a little crude but biologically we're built that way.

> The average age at which men exit the sex market and enter the marriage > market is higher than the average age at which women make the same decision.

I was going to make the argument that it's normally just a couple of years but...

> This, in turn, means that at each point in time, more men will inhabit the > sex market than women. Correspondingly, more women will inhabit the marriage > market than men.

So there's an imbalance between the two markets. I agree with this - take a look at Tinder or any other hook up style app. Heaps of men, comparatively less women. The result is women getting hundreds of Matches a day where most guys will be lucky to get one.

Oh and vice versa. Women trying to find a man that is marriage material is as scarce as men trying to find a casual sexual partner.

Actually the marriage market even more scarce than the sexual market. Once a man is taken off the market through marriage then the man pool becomes even smaller, making the ratio even worse!

I'll continue making more points in other posts.

</comment><comment><USER4> (2010)</comment>