Fat Protocols - <AUTHOR> https://www.usv.com/blog/fat-protocols <comment><USER2> A fun read, but to me it ultimately speaks to why blockchains are best suited to internal use by large enterprises (not consumer, small businesses, etc).

The web flourished due to its lightweight, comparatively easy-to-implement protocols. Applications could be built cheaply and easily on top of it. VCs and many entrepreneurs profited handsomely. Much of the past 20 years in tech has been pushing this concept to literally every person on earth.

Compare to the 'fat protocol': The protocols are tough to write, and tough to implement. The value is captured at the protocol level, not the app level, so there's little incentive to create inventive apps.

Few apps will be created on such systems, so few successful consumer applications will created with them. Seems like the winner here is in business-facing systems. For USV, it strikes me as peculiar to favor the 'fat protocol' and back other types of businesses (e.g. consumer).

<comment><USER3> > Compare to the 'fat protocol': The protocols are tough to write, and tough > to implement. The value is captured at the protocol level, not the app > level, so there's little incentive to create inventive apps.

I think the basic claim of this article is wrong. The false comparison comes from comparing the market cap of bitcoin and ethereum to "market cap" of existing protocols. There is no way to measure value of protocols before bitcoin. Therefore the whole basis of the article sounds like bullshit to me.

It is quite easy to write apps which use bitcoin protocol. Also many bitcoin businesses are quite profitable. Not billion-dollar businesses but very good businesses when you compare to the capital invested etc. Also they might be even better businesses longer-term, as the market develops. There is also loads of smaller brokers, gambling sites, atm operators etc who make small living out of bitcoin.

<comment><USER4> > There is no way to measure the value of protocols before Bitcoin

The point is not to compare the market cap of Bitcoin or Ethereum to the market cap of previous protocols at all. The point is precisely that the previous generation of protocols created immense value but most of it got extracted at the application layer while, as you said, there are many small but highly profitable Bitcoin businesses, but the bulk of the economic value is in Bitcoin itself, not in those.

Contrast that to the web where there is little economic value in the protocol and a lot of economic value in web applications.

</comment></comment></comment><comment><USER5> What blockchain products, in particular, tend to lack is a complete "economic engine" \- there isn't a good or service built in the equation, just a marketing promise that transacting goods and services through the protocol is somehow better, or failing that, some form of investment instrument that is a step removed from goods and services, and consequently less mission-critical for conducting business.

When there is a good or service, you usually find a situation where a centralized monopoly platform - "use our API, use our UI, feed off our database, speak with our sales and CSRs" \- is more straightforward to build and more advantageous for the stakeholders who will build and operate such a system. There are only certain niches where there's a definite and ongoing win to build and participate in a decentralized protocol. This rock and hard place has made it hard for the field to break away from purely speculative activity.

While the tech is maturing and growing an impressive set of features, I don't see big breakthroughs coming without a major initiative from a big player.

</comment><comment><USER6> Reminds me of cult religions where they promise people true purpose in life, but in reality only the ones at the top and the ones who started believing first are the ones who get the benefit. In their case, the rich of the high class always grows faster than the combined value of the group of sheep who start believing later

<comment><USER7> Sounds like the stock market, or really any investment in business or land. The world isn't perfect.

<comment><USER6> You don't win in stock market by bringing in more members. In a cult you do.

</comment></comment></comment><comment><USER8> Is this a fair comparison? How long did it take before the Internet got its first application whose market cap exceeded the cost of the protocol? Have we given blockchain technology long enough to mature?

<comment><USER4> The difference here is that you can have a stake in the protocol itself by purchasing the token whereas you couldn't do that with the web protocols.

Imagine an HTTPCoin in 1995: how would it's price be affected by the constant stream of web IPOs?

</comment></comment><comment><USER9> Yes, let's make all our technologies as "fat" as possible so other people can't "capture" and "re-aggregate" our "value". The VC-oriented approach to protocol design!

 _What's significant about this dynamic is the effect it has on how value is distributed along the stack: the market cap of the protocol always grows faster than the combined value of the applications built on top, since the success of the application layer drives further speculation at the protocol layer._

That also goes the other way: failure at the application level can bring the token value down as speculators sell, and a lowering token value affects all applications.

<comment><USER4> 100% on it also going the other way, as we've seen repeatedly whenever there is a hack at the application layer. The market cap of the protocol drops at a higher rate than the "actual loss", e.g. last week's Bitfinex hack of $70mm in BTC knocked 20% off the price of bitcoin.

</comment></comment><comment><USER3> This just doesn't make any sense. What was the market cap of protocols before bitcoin? LOL

</comment><comment><USER10> Love seeing articles like this, attempts at being objective or analyzing the hyped technology. Blockchain land is very peculiar in the way that information amongst market participants exists, where investment is largely necessary to understand the functions available but naturally creates a mental conflict for objective thought. All the while everyone self-segregated from the blockchain arena largely dismisses the mere concept of the available functions.</comment>


Show HN: Sslnotify.me, a free serverless opensource SSL cert monitoring service - <AUTHOR> https://alexanderfortin.tumblr.com/post/159003883536/sslnotifyme-yet-another-opensource-serverless <comment><AUTHOR> Hello, I've posted about my experiment here not because I think is particularly cool nor useful, but because I'd love to have some feedback from everybody interested in FaaS/Serverless, especially from who has some real experience building solutions with FaaS and willing to share his/her insights. Thanks for your time</comment>


Annotated code: Circles bouncing off lines - <AUTHOR> http://annotated-code.maryrosecook.com/circles-bouncing-off-lines/index.html <comment><USER2> In case anyone wonders about that reverse-for loop in updateCircles():

Iterating over an array in reverse allows you to remove items in the same iteration (at the very end of the loop). If you delete an item, the items which follow are downshifted by one which means that their indices also change.

However, this isn't a problem if you iterate in reverse, because you already took care of those items in previous iterations. The item you'll handle next will stay where it is.

This also works nice with unordered lists (or "bags").

</comment><comment><USER3> I don't know if the OP reads this, but one very minor note about the core of the update loop. From the POV of the circles, it is effectively:

      for each circle:
        if circle is penetrating:
          apply collision impulse
          remove penetration
        integrate forces (gravity) to update velocity
        integrate velocity to update position
      for each circle:
        render circle

Because interpenetration is resolved before integration, the integration step can cause further interpenetration before rendering.

For this case, the effect of this is probably invisible (I couldn't see it). With slower moving objects, higher gravity, or less elastic collisions, this can cause objects to 'sag' or appear springy. A simple change in order helps:

      for each circle:
        integrate forces (gravity) to update velocity
        integrate velocity to update position
        if circle is penetrating:
          apply collision impulse
          remove penetration
      for each circle:
        render circle

A very minor thing, but something to remember when doing physics animations.

<comment><USER4> I do not understand. Since this is executed in a loop, for the circle it looks like ...-penetration-integration-penetration-integration-penetration- integration-... in either version. Why does it matter between which steps the circle is rendered?

<comment><USER3> (Edit: I can be clearer, using your approach - more verbose explanation trimmed)

In the linked version we are doing

... move, draw, de-overlap, move, draw, de-overlap ...

So the move might cause an overlap, which we'd draw on screen. Having objects routinely interpenetrating a little (by a frame's worth) can appear springy, as if they aren't made of rigid material.

Better would be

... move, de-overlap, draw, move, de-overlap, draw ...

</comment></comment></comment><comment><USER5> Trying to keep the narrative of explanation in the same linear order as the code makes for a surprisingly difficult to understand item. Would be neat to see more "traditional" literate programming techniques applied here.

All of that said, really cool, and seriously thank you for sharing!!

<comment><USER6> I wonder if the weaving in literate code is one of the things that could only have been invented to deal with Pascal. It is useful to be able to rearrange the presentation even in JavaScript, but I doubt it would be enough of a pain point for people to invent weaving in an alternate history were literate programming was born on more flexible languages.

<comment><USER7> I wrote a literate-programming compiler to deal with JavaScript programming (any language works, but js is the one I use the most); it use markdown as the language in which the code is embedded.

For me, prototype setup and async stuff seemed to naturally lead me to want to differ in the ordering between how I write and how the program is laid out. I find it quite liberating to not care what order I write the code in, dashing off a substitution section to deal with later.

I know functions can be used to chunk out code in different orders, but I like the interplay of having it ordered in the writing in a sensible fashion while still getting the compiled view of it in the programmatic ordering.

Plus my version allows for a lot of finely tuned hacking on the language. That is, one can reduce a lot of boiler-plate setup with processing small chunks of code.

Having said all that, I would not use Knuth's original version for js. I think what was particularly attractive was a simple language like markdown for embedding code in a natural and simple way.

My main repo is [https://github.com/jostylr/literate- programming](https://github.com/jostylr/literate-programming) though I am currently rewriting the engine behind it to allow for more asynchronous compiling [https://github.com/jostylr/literate-programming- lib](https://github.com/jostylr/literate-programming-lib)

<comment><USER4> The weaving steps seems especially useful for web programming, because of the different languages. For the narrative, you could show HTML, Javascript, CSS, and Python backend code mixed together. The weaving puts them all into separate files for execution.

</comment></comment></comment></comment><comment><USER8> Just have to say, it gets more amusing with more balls and lines: [https://zifnab.net/circles-bouncing-off-lines/](https://zifnab.net/circles- bouncing-off-lines/)

<comment><USER9> This looks glitchier than the original for some reason, probably just sheer numbers. Balls bouncing off the bottom of lines that are moving away appear to jump.

</comment></comment><comment><USER10> Really useful if you want to play around with their code and share it with your kids, etc.

[http://jsfiddle.net/yr64fy2o/1/](http://jsfiddle.net/yr64fy2o/1/)

It is nice to be able to show someone directly how changing the various parameters affects the simulation.

</comment><comment><USER11> That's pretty educational.

OT: I'm not a game developer. What are the other patterns - besides the global state and mutation functions - that one can use for a game loop?

<comment><USER3> Mostly modern game engines use an entity system[1], which is a form of database (global data, I guess, in as much as any database is).

The main loop then steps through each component (of which physics would be one) and lets it update the entity data for all entities.

This pattern took over from class/inheritance based architectures about 10 years ago.

There have been some suggestions that Functional Reactive Programming is a better approach. I've used it in some prototypes, but I couldn't scale it to engine-size, and I'm not aware of it having been used successfully for a full game engine.

So, this approach is pretty much it. You keep a database of state, then you run a system (the physics system, say) to update that database.

[1] [http://t-machine.org/index.php/2007/09/03/entity-systems- are...](http://t-machine.org/index.php/2007/09/03/entity-systems-are-the- future-of-mmog-development-part-1/)

</comment></comment><comment><USER12> Reminds me of a simple physics system I wrote a couple of years ago [0]. After writing a cloth simulation [1] I figured that all I needed to make them into collidable boxes was to have each dot collide with each line. I went in very very small steps, iterating each thing to ensure I understood it. The code was super verbose and I learned a lot from this about linear algebra, cross products, vector projection etc. I always planned to straighten the code out and do a proper writeup.

[0] [https://www.youtube.com/watch?v=ud8NirjyLAA](https://www.youtube.com/watch?v=ud8NirjyLAA)

[1] [https://www.youtube.com/watch?v=G05M_Y6NQVM](https://www.youtube.com/watch?v=G05M_Y6NQVM)

<comment><USER13> The tearing is awesome, haven't seen that before in cloth simulations.

<comment><USER12> Thanks. If you find it enjoyable to watch I'd recommend you to do a youtube search because there's actually a lot of it.

As for the implementation, it is extremely simple. For anyone interested just do a search for "verlet cloth".

EDIT: I'd specifically recommend this one [0]. It looks quite simpler than many on youtube but it feels more real.

[0] [http://web.media.mit.edu/~bandy/cloth/](http://web.media.mit.edu/~bandy/cloth/)

</comment></comment></comment><comment><USER14> I think this is awesome but I think it's a little too spaced out. I like the side-by-side display (gives the code an approachable narrative) but I wish I had to scroll up and down (to remind myself of what's going on) less.

<comment><USER15> On mobile it combines the sides together in a way that I find an appealing option. Screenshot: [http://imgur.com/xRvDubc](http://imgur.com/xRvDubc)

Anybody know if there's an easy way to get something like the mobile view on desktop (without spoofing user agents, etc)?

<comment><USER16> The view will switch to this layout if you make the display window narrow enough (320px)

doco.css:202

> /* </comment></comment></comment><comment></comment><comment></comment><comment>---- Low resolutions (> 320px) </comment><comment></comment><comment></comment><comment>--- */

> @media only screen and (min-width: 320px) {

</comment><comment><USER17> +1 vote for a "raw raw code" link, all comments stripped.

</comment><comment><USER18> Here's a similar effect, from a 1994 C64 demo.

[https://www.youtube.com/watch?v=SUQb_Oepa6o](https://www.youtube.com/watch?v=SUQb_Oepa6o)

</comment><comment><USER19> Nice code. Thank you. Are those ball-to-line collisions energy preserving? I believe they are... However it seems there might be an edge case, where moving a colliding circle until it no longer intersects the line, might cause it to skip past another line. Because of this, the lines should not intersect each other. Sorry to ramble but I love this sort of stuff. Collision detection is covered well in many game development texts.

<comment><USER20> Yeah he should be getting the starting & ending position of the ball during the tick, and determining whether that line intersects the other line. If it does, the intersection point should be found and the segment that goes past the line should be reflected over the normal, and the ball placed at the new endpoint of the reflected segment. And, of course, the velocity vector needs to be changed as well.

But... I guess this won't be the first time someone posts bad physics code on the internet and poses it as a good example.

<comment><USER3> Hmmm, you appear to have a high opinion of your ability to determne 'good physics code'. Unfortunately, just a high opinion, not a high ability.

The OPs code is fine. And was written by a she, not a he.

Your suggestion is what is sometimes called 'continuous' collision detection. It is needed in some cases, particular when the OP approach might miss collisions (less often for when knock-on-collisions are missed, since those are rarer). But that approach is not 'better' \- it is far more time consuming (vastly more for 3d rigid bodies with angular velocity), and has a visual benefit in some cases (not in the OPs case - or at least you wouldn't see the difference).

But, of course, both approaches are very approximate and only intended to give the right feel. If you wanted to be even more accurate you would process your collisions by subdividing updates around the collision (a good pool-ball simulation does this, to model proper breaks). And you'd have to use different integrators than the 1st degree Newton update.

This process can keep going as far as you like. For physics systems I've worked on for modelling the behavior of rigid components in MotoGP bikes, the kinds of approximations you allow are very different to the physics engines I've built for commercial games. Neither are 'better' or 'worse' \- a good programmer understands the requirements of their domain . To that extent, the OP's approach is fine, and powers the vast majority of the physics in current generation video games (most engines do support continuous collision detection, but it will be switched off for most rigid bodies in a scene, for performance).

<comment><USER20> You're right, there's a gradation of compromise, and I wasn't fully polite in my comment (nor did I think to attempt to determine OPs sex... then again, I'm a guy with a "girl's name", so who's to say "Mary" is necessarily a girl? aaaanyway...). I'm not suggesting that all software must compute integrals in order to have convincing physics. However, when I see code like this I involuntarily get itchy:

          while (trig.isLineIntersectingCircle(circle, line)) {
            physics.moveCircle(circle);
          }

<comment><USER3> Thanks for that, sorry for my impoliteness in response. HN is sometimes frustrating in its density of people with Dunning Kruger problems. I am sometimes one of them.

You bring up a slightly different issue now, which I'm not sure if you are suggesting the problem is with the unbounded loop or with the serial strategy for resolution.

On the former, I agree with in the narrow (interpenetration resolution isn't usually guaranteed to converge), but taking

      while (has_interpenetration()) {
        resolve_interpenetration();
      }

and adding a limit

      for (int i = relaxation_steps; i > 0 && has_interpenetration(); --i) {
        resolve_interpenetration();
      }

gives you code that is in most game physics engines, in some form.

On the latter, modern game engines do some steps globally, rather than just running through each rigid body (often collision detection, interpenetration resolution, resting contact resolution, but not normally collision resolution or integration). But the OP approach of running everything in series wasn't unusual 15 years ago when game physics systems started to become ubiquitous. Before companies like Mathengine and Havok perfected LCP approaches, folks like Ipion and FastCar were doing impulse-based calculations that were heavily serial. So for a very simple JS experiment, it didn't strike me as a problem. I'd have written it that way too, if it were me.

</comment></comment></comment></comment></comment><comment> adam-f I did the same thing a few years ago (scroll down past the tutorial/examples for the annotated code) [http://sparecycles.github.io/litijs?template](http://sparecycles.github.io/litijs?template)

(but litijs itself is an undocumented hack) [http://sparecycles.github.io/litijs?litijs](http://sparecycles.github.io/litijs?litijs)

</comment><comment><USER21> I could have really done with this a few months ago. I was trying to make animations of electrons flowing through wires of variable thickness, and really struggled trying to find examples online. I ended up having a three hour maths lesson with my brother over irc, to get my head around vector maths.

</comment><comment><USER22> One of the "not good" explanations of this was probably mine (and I agree!) written many years ago [1]. I wish I could remember why my code ended up so much more complex.

[1] [http://ericleong.me/research/circle- line](http://ericleong.me/research/circle-line)

</comment><comment><USER23> Same person that wrote gitlet[1], as seen on HN a few weeks ago. Personally I'm extremely happy to see HN so supportive of well commented and documented code.

[1] [https://github.com/maryrosecook/gitlet](https://github.com/maryrosecook/gitlet)

</comment><comment><USER24> I hate this left/right code documentation fad with passion.

Making my eyes jump horizontally across the page every few lines is about the worst you can possibly do for readability.

Just keep the damn comments inline and use colors/font-faces/fold markers to make it readable.

<comment><USER25> Do you also prefer footnotes and sidebars inline when reading articles?

These are standard typographical practices. I do set my comment color to super light so comments don't distract me too much when reading code, but I wish there was a better way.

<comment><USER26> Not the parent, but I prefer footnotes/sidenotes when reading physical texts, but prefer inline commentary when reading on the computer screen. Jumping up and down to read a footnote (either manually scrolling or with a hyperlink) or having the sidenotes take up a large percentage of the screen is disorienting for me.

It helps if the inline commentary is differently colored or in a separate box.

I also use light colors for comments when reading source code, but I personally prefer this over having them as footnotes or sidenotes.

<comment><USER25> That is why side notes are so nice: you don't have to scroll down, you just look at the side bar. And if you just want to read code...hide the side bar! Horizontal real estate is not a big deal with 80 column code widths (you could even have two or three screens of code on one monitor still). Heck, you could render the comments with a proportional font to save even more H-space (fixed- width fonts are extremely archaic).

Programming should move out the typographical stone age into something a bit more modern.

<comment><USER26> I see where you're coming from regarding ease of hiding/unhiding comments, but I think it'd be quite hard to do correctly in user configurable environments.

In the article, I'm assuming the left column takes up a bit less space on the author's browser viewport, but it takes up about 45% of mine, while a bit of the code trails off the page.

The reason I think it works so well with physical books is that the dimensions are known and not user-configurable, so it's easier to guarantee that the sidenotes look appropriate. With free-form comments that could range from a one-line comment to large paragraphs to explain one line of code, I don't think there's a way to make sure they would look reasonable in all cases. (I could be wrong)

A good example of easy-to-read in-text notes (in my opinion) are those in Fred Hebert's LYSE [1]. They could be sidenotes or footnotes, but instead they're in-text, which makes them easier for me to read in a browser, regardless of screen size, but also pretty easy to skip over since they're color-coded and in their own box.

I think it's more of a medium difference than a book-typography-is-more-modern one. When scrolling through a web page or code, I mostly find the single- column in-text notes/comments easier to use, though I see why some people might prefer sidenotes.

[1] [http://learnyousomeerlang.com/starting-out-for-real#bool- and...](http://learnyousomeerlang.com/starting-out-for-real#bool-and-compare)

</comment></comment></comment></comment></comment><comment><USER27> I love the look of the annotated code. I think it would be particularly useful for documentation.

Are there any tools that can generate this from comments, or perhaps an Eclipse or Visual Studio plugin that shows this type of documentation along with the code?

<comment><USER28> This page was generated from comments using Docco: [http://jashkenas.github.io/docco/](http://jashkenas.github.io/docco/)

</comment></comment><comment><USER29> Very cool. Interesting bit: The outcomes of the falling balls seem to differ every time, which corroborates the fact that any minor change in initial state results in vastly different outcomes.

Edit: Or am I just imagining it?

<comment><USER17> ~~The simulation clock is based on the actual frame rate achieved via requestAnimationFrame().~~

Edit: Actually, it looks like the physics portion takes constant (but implicit) time steps each frame, but the time that a circle enters the simulation is based on the actual frame rate, which means when a given circle appears, the lines could be in a different location from previous runs.

<comment><USER29> Thank you.

</comment></comment></comment><comment><USER30> I assume the side-by-side view is rendered from the raw file with comments inline? Is this using some kind of comment markup language?

Where can I find out more about cool ways to render comments like this?

<comment><USER31> It's generated using [http://jashkenas.github.io/docco/](http://jashkenas.github.io/docco/). I think it's possible to use comments, but often it's "literate" source code, e.g. markup & code blocks.

</comment></comment><comment><USER32> Wow great learning resource. I wish docco let you click functions to jump to their definition.

</comment><comment><USER33> so tick calls requestAnimationFrame that calls tick that... Doesn't it create an ever growing stack? Isn't there a way to do it with a while loop?

<comment><USER34> requestAnimationFrame just queues up the callback for later, it doesn't actually call into it. There's no stack growth.

</comment></comment><comment><USER35> Neat!

Is the code annotation page a library?

<comment><AUTHOR> I believe the OP is using Docco.js (which has been ported to many languages, e.g. Rocco for Ruby, Shocco for Shell, Pycco for Python, Gocco for Go, etc.)

[http://jashkenas.github.io/docco/](http://jashkenas.github.io/docco/)

There's different ways to configure the output and layout...the Docco homepage uses a single-column format, whereas the OP uses the double-column format.

</comment></comment><comment><USER32> Uncle Bob would be proud!

</comment><comment><USER36> Mostly useful, however a lot of the comments are unnecessary noise. And some could be eliminated with better naming, intermediate variables and refactoring.</comment>


Facebook admits huge scale of fake news and election interference - <AUTHOR> https://www.theguardian.com/technology/2019/may/05/facebook-admits-huge-scale-of-fake-news-and-election-interference <comment><USER2> Banning people like Alex Jones and Paul Joseph Watson IS election interference.

It's really strange to me that it's supposed to be about banning hate speech, yet only right-leaning people are banned.

Logic dictates that there is hate speech on the left, but I don't see it getting banned at the same rate.</comment>


Ask HN: Other than cash, how do you compensate employees in your startup? - <AUTHOR>

Our company (bootstrapped) has grown very quickly in the past few months. As we contemplate our next moves, we need to decide between investing in hard assets (machinery, IP) and paying employees for project-based work related to the development of these assets. These assets will provide us with a protected competitive position in our industry. We aren't really looking for outside investors, and an exit down the road is highly unlikely, so equity compensation for employees isn't ideal. What other forms of employee compensation have founders on here used? Ideally, some sort of rolling-debt instrument would fit our needs, but everything I've read online says that's a bad idea (and possibly illegal). Does anyone have any other suggestions? <comment><USER2> Stock options and warrants can be useful, though if done poorly they can muddy up your prospects for later rounds of financing in case you change your mind about investors. Not ideal, but cheap.

Perks like telecommuting, flexible schedules, and PTO are often very underused by companies, and they have no direct costs to your bottom line (indirect costs can be massive if done wrong). Offering better-than-industry perks like these go a long way to decrease turnover, and can be as or more effective as pay increases.

Sometimes you can defer salaries, but outright bonuses give you some wiggle room in case of a future downturn.

Depending on the nature of your startup (is most of it software?) you'll also get far more motivated and loyal employees per dollar spent by locating your offices outside of the startup capitals.</comment>


Ask HN: Can we save the entire Gmail data offline? - <AUTHOR>

As most of you know by now, Gmail is down. Before today, I had never thought it could go down. This has made me think that I should save all my Gmail data on my PC. Does Google offer that functionality? If not, what is the best way to do that ? <comment><USER2> You can use Google Takeout: [https://www.google.com/settings/takeout](https://www.google.com/settings/takeout)

<comment><AUTHOR> That was easy. Thanks. :)</comment></comment>


Top journals retract DNA-repair studies after misconduct probe - <AUTHOR> https://www.nature.com/articles/d41586-019-00406-4 <comment><USER2> Sirtuins have been a hot topic. In light of this I'd like to see a paper that tells us what about SIRT6 is and isn't supported by evidence.

<comment><USER3> I agree, and it's a bit too early on the timescale of publications to see a paper that re-analyzes all that has previously been published on the topic in light of this information.

That said, we've found around 2,500 articles which discuss SIRT6 [1], which is about 10 times more than the 267 articles that cite the retracted study according to the article. Based on this, I would assume most of what we do know about SIRT6 would still hold up.

[1] [https://mastermind.genomenon.com/detail?disease=all%20diseas...](https://mastermind.genomenon.com/detail?disease=all%20diseases&gene=sirt6)</comment></comment>


IE6 is dead - <AUTHOR> http://www.ie6death.com/ <comment><USER3> I do mostly contract work in the U.S. for state and local governments. The RFP's (Request for Proposals) always say something about using HTML5, responsiveness and the latest web standards.

And sometime shortly after (and sometimes before) project kickoff we always see that a large percentage of their employees are using IE8 and we have to support it.

I make a point of describing in detail what kind of resources will be required to do both a modern website/app using the latest standards and one that will support IE8. I mention that, for the most part, they are mutually exclusive and I will effectively have to build the site (at least the "modern" parts of it) twice and this will cut back on the features I'm able to implement within the project budget and timeframe.

This usually makes the customer take a closer look at their actually IE8/XP install base and I've had several customers decide they would speed up migration from IE8/XP and remove the support requirement for that browser.

Just doing my small part to help kill IE8 - one small government agency at a time.

<comment><USER4> While I commend you for finding a way to communicate to your clients in a way that allows you to not develop for IE8, you're not really being truthful. You can use "HTML5" with IE8 as part of html5shiv.js of course and IE8 doesn't need to be responsive - its a desktop browser. In most cases you can almost certainly deliver an IE8 solution without a lot of extra work.

<comment><USER3> I admit that I may overemphasize but it's never as simple as just using a shiv. I always run into additional debugging and support issues when building for IE8.

There is most definitely additional work required to support IE8.

</comment></comment></comment><comment><USER5> Reports of its death are, from my experience, greatly exaggerated. It's still fairly widely used in businesses; as they say "if it's not broke, don't fix it." (Despite the fact that it is broken on many sites.)

For anyone that wants to use a modern CSS framework that supports IE5.5+, check out Min ([http://minfwk.com](http://minfwk.com)). Disclaimer: I made it.

<comment><USER6> I know this is a bit pedantic but it's definitely not 'fairly widely' or 'quite a lot' or 'some', there's a tiny, tiny percentage of businesses using it.

Our UK website, not aimed at tech savvy, had 0.13% IE6 over the last 2 months compared to 0.32% the year before and when I last looked a significant proportion of that is bots and scrapers pretending to be browsers anyway.

Half our traffic comes during the business day (we actually see a significant switch from desktop to tablet/mobile at around 6).

For all intents and purposes, certainly for consumer websites, it's dead.

For those interested, our IE7 is at 1.72% (we stopped testing IE7 a couple of months ago as we don't have the resource and it was already converting badly any way).

<comment><USER7> _there 's a tiny, tiny percentage of businesses using it._

Not really. Probably many fortune 500 companies (I know several) continue to use IE6 and pay for virtualizing IE6. That's a significant amount of money in licenses and support. That's why companies such as VMware or Symantec have this feature in ThinApp and SWV.

<comment><USER8> If you're virtualizing then you're probably using it for one specific purpose and not general use, so imo it might as well be dead if it's not being used for general tasks.

</comment></comment></comment></comment><comment><USER9> At my employer, they finally pushed a full blown enterprise wide upgrade to IE10 with IE11 just around the corner (August).

Unfortunately in parallel, they could not get enough people to submit sites that needed compatibility mode, so to prevent massive help desk problems they decided to push USE COMPATIBILITY MODE FOR ALL SITES. This basically downgraded everyone to IE7 mode permanently. So much for progress...

<comment><USER10> My Employer does this also, all sites are our intranet switch IE into IE7 compatibility mode. Does matter if the need compatibility mode or not. We recently released a version of the web app I am building and I wish you couldve seen the horror on our faces when we saw the app in IE 7 mode.

<comment><USER11> Well, unless they actually change it in group policy, this is the default action for IE when it connects to anything on what it considers to be Intranet.

You can override this by setting X-UA-Compatible to IE=edge as a HTTP header on your server. The equivalent meta tag is ignored in this situation.

Or you could ask IT to change group policy, but I have no idea where that setting might live.

<comment><USER10> >X-UA-Compatible to IE=edge

I believe we added this as a meta tag on the HTML pages, we didnt think of changing the HTTP header on the server.

I doubt they will be willing to change the IT group policy because the app we built has a smaller userbase than other apps. That and they are still supporting web apps from the late 90s - early 00s designed for IE 5/6.

</comment></comment></comment></comment><comment><USER12> Actually, XP has a shorter life-span time here in Belgium (online banking activities are blocked for Windows XP), so people actually buy a newer PC or upgrade their PC for a newer Windows.

<comment><USER13> > in Beligium ... online banking activities are blocked for Windows XP

Do all the banks agree to shut out XP on their sites? Legal requirement?

<comment><USER12> They say it's because the updates make the OS less secure. So they are all going to disable Win XP because of vulnerabilities.

PS. They also don't support linux

</comment></comment></comment><comment><USER14> Just checked the analytics on a non-IT website:

IE represents 10.45%

Out of that:

        IE6      .28%
        IE7     2.03%
        IE8    19.81%
        IE9    16.57%
        IE10   16.15%
        IE11   45.13%

<comment><USER15> Here's bloomberg.com:

IE represents 25.00%

        IE6    0.11%
        IE7    3.20%
        IE8   34.39%
        IE9   32.94%
        IE10  16.48%
        IE11  12.87%

<comment><USER16> That's really interesting, how did you get these statistics (do you work for Bloomberg, or do they have this publicly available somewhere)?

<comment><USER15> I work for Bloomberg. (And yes, I verified that web guys didn't mind sharing the numbers :))

</comment></comment></comment></comment><comment><USER17> As others have pointed out, IE6 isn't dead yet. Any person or business that is stubborn enough to use IE6 nowadays is probably also stubborn enough to keep using Windows XP for another year or ten.

And I'm afraid a lot of us have been complicit in the unusually long life of this dreadful monster, as well as of its just-as-dreadful offspring, IE8.

By "us" I mean everyone who has ever developed a website in the last few years and consciously tweaked the code to make it work in an old version of IE. Or anyone who claimed to discontinue support for IE[6-8] but quietly kept fixing IE[6-8]-related bugs in their spare time.

Because every time a website tweaks its code for compatibility with an old version of IE[6-8], IE[6-8] gets another drop of unicorn blood to sustain its life. Since the majority of websites even today work relatively well in IE[6-8], the inconvenience of occasional breakage does not outweigh the inertia of IE[6-8] users. Even among people who call themselves programmers, I know of plenty who just don't bother to install updates. They won't act until their pants are on fire.

If we really want to kill IE[6-8], we need to set fire to their pants. We can't just sit back and count the days until somebody else (Microsoft) mercifully kills IE[6-8] for us. How about we all agree upon a certain date on which we _intentionally_ break our websites and services for IE6 users? We should bring as many websites on board as possible, just like what happened with the SOPA blackout. Any IE6 user who tries to visit any marginally popular website on or after that date will be refused service and told to 1) upgrade to Windows 7+ and IE 10+, 2) install another browser, or 3) nag their bosses to let them do so. That's right, no Google, no Facebook, no Twitter, no Wikipedia, no reddit, no webmail, no lolcats, no porn (!) anymore for you. Within a month, IE6 will be wiped off the face of the planet forever, and whatever remains will be safely confined to intranets. Just like smallpox. Three months later, we repeat the blackout for IE7. Six months later, we boycott IE8 as well.

Don't we, the HN crowd, have the power to pull off a boycott like that?

Will it be an ethical thing to do? Will it even be legal?

I don't know. It does sound rather perverse to refuse service to IE6 while keeping the website fully accessible for Lynx.

But I do look forward to the day when website developers collectively decide to stop being a slave to browser market shares and take the business into our own hands once and for all. Because IE[6-8] deserves it. It has hurt us all a thousand times more than the outgoing CEO of Mozilla has ever hurt gay couples. We can't just sit and wait for it to die. We need to point our keyboards at it and shout _Avada Kedavra_ with extreme prejudice.

/daydreaming

<comment><USER18> > If we really want to kill IE[6-8], we need to do something more drastic, and > do so with extreme prejudice. How about we all agree upon a certain date on > which we intentionally break our websites and services for IE6 users?

Maybe for a blog, but I'm not telling 10%+ of my customers to piss off. If the cost of supporting them outweighs the value of their business then I won't support them any more. But I would never intentionally break a site for them.

<comment><USER19> Just curious, any idea why you have so many users (10%) still on IE8 or under?

I just checked my usage, and I only have 8% using IE period -- all versions. Of those, only 8% are on IE8 or under -- which is only 0.6% of all users.

<comment><USER18> We have a network of B2B news and information sites for various industries. I think this is probably pretty standard for sites targeting enterprise users at non-IT companies.

It's actually kinda interesting to see the variations between industries like Healthcare vs Construction vs Utilities. If I get time maybe I'll write up a blog post.

<comment><USER20> Please do. It does sounds interesting.

</comment></comment></comment></comment></comment><comment><USER21> meanwhile IE 5 is alive in Wichita Kansas. Error message received today: HTTP_USER_AGENT': 'Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt)

because the old thing doesn't like URLs without a protocol:

//ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js

<WSGIRequest path:/ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js/

<comment><USER22> what's the benefit of excluding the http:? I'd never seen that prior to a few years ago when the jQuery links started doing it.

<comment><USER23> It's a protocol relative link. So if the page is served over http, it'll be an http link, and if the page is served over https, it'll be an https link. See [http://en.wikipedia.org/wiki/Protocol_relative_URL#Protocol-...](http://en.wikipedia.org/wiki/Protocol_relative_URL#Protocol- relative_URLs)

<comment><USER24> And it breaks unexpectedly (and sometimes hilariously) when people use it in html email, it turns into a file:// "link".

<comment><USER25> You can't have external css or js in an html email. [1] Are you talking about links? Or image tags?

[1] Well you can, but no one will fetch them.

</comment></comment></comment></comment></comment><comment><USER26> If you're maintaining sites that are difficult to upgrade, I'd recommend looking at IE11 Enterprise Mode. It lets you run with pretty good IE8 compatibility (e.g. ActiveX) in IE11, taking advantage of improved speed, security, and base OS improvements.

20 slide deck: [http://view.officeapps.live.com/op/view.aspx?src=http%3a%2f%...](http://view.officeapps.live.com/op/view.aspx?src=http%3a%2f%2fvideo.ch9.ms%2fsessions%2fbuild%2f2014%2f2-559.pptx)

docs: [http://technet.microsoft.com/library/dn640687.aspx](http://technet.microsoft.com/library/dn640687.aspx)

good blog post: [http://love2dev.com/#!article/The-New-Internet-Explorer- Ente...](http://love2dev.com/#!article/The-New-Internet-Explorer-Enterprise- Mode-or-Why-You-Should-Never-Use-IE-8-Anymore)

</comment><comment><USER27> Reports of IE6's death are greatly exaggerated.

<comment><USER28> We run a SAAS app. We recently saw _IE4_ in our logs. Not a single one of our customers has upgraded past IE8.

IE6 is alive and well in many large companies.

<comment><USER29> Consider the possibility that someone was playing with old browsers.

<comment><USER30> I joined a new project where IE 8 is the lowest required supported browser.

<comment><USER31> This is nothing unusual when you do SaaS aimed at business customers.

We have to support IE7 on some of our software, only dropping IE6 a year ago or so ... Other software minimum requirements is IE8, hoping to drop it by the end of this year.

</comment></comment></comment></comment></comment><comment><USER32> The zombie certainly still continues to live on shitton of computers across the globe running unauthorized copies of Windows XP for customers who couldn't care less about official support from Microsoft as they never had it in the first place. Yeah, unfortunately.

<comment> sotiris-k As a Web Developer I do not count those people as a potential target group. Or even a subgroup for that matter.

</comment></comment><comment><USER30> It was replaced by IE 8.0, long live the king! :(

<comment><USER33> With the death of XP I would expect to see a usage drop, not only in IE6 but in IE7 and IE8 too.

IE8 is the latest version of IE that can be installed on XP, I would assume that most people using IE8 would be XP users.

If anyone has data on IE8 OS versions I would be interested.

<comment><USER34> For our app I've been monitoring IE8 usage for the last month. It is almost exactly one-for-one with XP users (YES!) and dropping a little at a time every day. When I first started looking the rolling 30 day average was roughly 15%. It has since dropped below 12%. I would imagine by the end of the year and a wonderful rash of XP viruses and worms, a lot of our customers will have had to drop both of them.

</comment></comment></comment><comment><USER35> As a dev I have been trying to convince the project managers of the following theory of people who use IE6/7/8.

They must fall into one the following categories

1\. Windows XP, which does not allow them to upgrade to IE9 _AND_ do not know that other non-sucky browsers exist

2\. They work for a company that requires IE8

3\. They are masochists who love pain)

4\. They are sadists who enjoy dealing out pain to Web developers.

Proposed solutions were:

1\. Tell them that other browsers have better experiences.

2\. Point out that they can usually get around this by using a Chrome frame. Also point out that IE8 is riddled with insecurities and give them a form letter for their IT department asking for an update.

3\. They love pain, there is nothing we can do about this. They probably enjoy having incomprehensible boxes instead of icon fonts on half of the sites they visit. Grids be dammed, they love misaligned columns.

4\. They probably don't even use IE8, they (or their botnet) just use a User Agent String that mimics it. These people are asshats, should be ignored at all costs.

I felt this was a quite pragmatic approach, needless to say we still support these users and their shoddy experience.

<comment><USER22> In regards to your first solution, I keep going back and forth on whether or not it's professional to add a conditional warning that detects an old browser and explains the upgrade process. I know there are some scripts you can throw on your sites that automatically do this, but I'm not sure if that's a good idea.

<comment><USER35> googleapps, facebook, youtube, nike, among many other gigantic brands seem to think it is just fine to encourage their users to have a better experience.

</comment></comment></comment><comment><USER36> the second badge at the bottom (the small one) has its own countdown timer. seems there's an off-by-one-month bug.

(i always wondered why some libraries treat jan as 0 but the first day of the month as 1)

<comment><USER37> Total guess, maybe _1_ is thought of subconsciously in the implementers minds as a name, while number for months are so unlike the month name that they're thought of more like an index.

</comment></comment><comment><USER38> Having to support IE8 Compatibility mode for a bank is worse than IE6 - <USER2> least IE6 issues and fixes are documented. IE8 Compatibility mode is a world of pain, add in some proxy servers and latency sensitive JS and you have a fun fronted time.

</comment><comment><USER39> Huh, I just went to the acid3 test in Firefox 28 and it _failed_. (Animation wasn't smooth, final rendering did not match expected image at all.) Is this surprising? I thought acid3 was a fairly old test.

<comment><USER40> I just went to acid3 with Firefox 28 and got 100%...?

<comment><USER39> I got "100%" too, but there's multiple criteria for passing:

       - 100%
       - Animation is smooth, no stuttering
       - The final rendering matches the provided image

<comment><USER40> It was smooth for me and matches the reference rendering. Maybe your machine is under powered (Netbook or something?)?

<comment><USER39> Xeon E3 1240 v3 (Haswell) ;-).

<comment><USER40> Intel i7 950 @ 3.07GHz, discrete nVida graphics, Ubuntu

Maybe you are using integrated graphics or your graphics driver in on the FF blacklist? Platform?

There has to be some reason why--

</comment></comment></comment></comment></comment></comment><comment><USER41> I didn't realize there was actually an end-of-support date for IE6.

Is there one for IE7?

<comment><USER42> Today is the end of _paid_ support for IE6.

Today is also the end of unpaid support for XP (which I assume includes IE7 - IE8).

</comment></comment><comment><USER43> It's not dead. I work for a large health organization (100,000+ employees) and IE6 is still the default browser. Users can manually update.

Needless to say, but I'm still using XP.

</comment><comment><USER44> Is it 2010 already?

[http://www.cnn.com/2010/TECH/03/04/ie6.funeral/](http://www.cnn.com/2010/TECH/03/04/ie6.funeral/)

</comment><comment><USER45> I'm currently working in a very heavy enterprise space, most fortune 100 banking/insurance, etc. companies use our software. Our requirements are only IE9+. I'd be scared of the legacy companies that need older support

</comment><comment><USER46> I really can't say I'll be in mourning over this. I've lost count of how many times I've had to convince clients to upgrade even to IE7 because IE6 isn't compatible with some aspects of WordPress.

</comment><comment><USER47> Tell that to the 23% of people still using XP.

Quite a few of those are likely to be IE6 users, primarily due to governments and bureaucratic corporations.

</comment><comment><USER48> Time to start [http://www.ie7death.com/](http://www.ie7death.com/)

</comment><comment><USER49> The browser we love to hate. The version we love to hate.

Interesting (see footer) how many of those site were out there.

</comment><comment><USER50> We have a large client with over 2,000 'zombie' XP/IE6 machines out there. Ugh.

</comment><comment><USER51> "Never passed the ACID test" :) Made my day!

<comment><USER52> That is actually unclear to me though. ACID1 was even included as an easter egg in IE5 for the Mac [0][1]

[0] [http://en.wikipedia.org/wiki/Acid1](http://en.wikipedia.org/wiki/Acid1) [1] [http://en.wikipedia.org/wiki/File:About_Tasman_IE5_Mac_OS_X....](http://en.wikipedia.org/wiki/File:About_Tasman_IE5_Mac_OS_X.png)

</comment></comment><comment><USER53> I have only two words to say: if only.

On a positive note, now that Microsoft has officially withdrawn support for Windows XP, IE6 may meet its long overdue death faster.

</comment><comment><USER54> There are at list other 3 version over the 6 that should be erased from the Earth surface. Just assuming someone would keep the last 2. Not me.

</comment><comment><USER55> [http://www.youtube.com/watch?v=xRvAAYjmqkE](http://www.youtube.com/watch?v=xRvAAYjmqkE)

</comment><comment><USER56> Great, now we just need to kill IE7... and 8, 9, 10, 11, ad infinitum. :-)

<comment><USER22> I'd be happy with just 7 and 8 for now. 9+ has usable support of CSS3 at least.

<comment><USER57> 10+ has WebSocket and strict mode. I'm happy!

</comment></comment></comment><comment><USER58> it was unconscious for quite a while, so why did it die today?

<comment><USER59> Because it is off XP life support now.

<comment><USER60> XP has life support turned off, however, it'll still survive for a few years despite that.

The end of MS support doesn't seem to have caused any mass migrations off of windows XP, and it will be a _long_ time until it's less popular than windows 8.

<comment><USER59> Yes, I'm afraid reports of IE's death have been greatly exaggerated.

<comment><USER61> Third time's the charm?

<comment><USER62> The exaggeration of IE6's death has been greatly exaggerated.

<comment><USER61> Well, now this thread got bigger. At the time of my posting perhaps quarter of the comments said this.

</comment></comment></comment></comment></comment></comment></comment><comment><USER63> Is it though?

</comment><comment><USER64> It would be better if IE, period, was dead. Otherwise we're just switching one terribly obsolete IE for another terribly obsolete IE.

<comment><USER65> We are writing enterprise web application that uses WebGL for displaying complex 3D models and we think that IE11 is damn good. Thus, I've no idea why are you calling it terribly obsolete.

<comment><USER62> Give it a year.

<comment><USER65> We'll have IE12 by that time.</comment></comment></comment></comment>


Show HN: Tabli – A Tab Manager for Google Chrome - <AUTHOR> http://antonycourtney.github.io/tabli/ <comment><AUTHOR> OP here: I developed this to meet my own needs as a developer to help keep me from getting lost in the sea of tabs that inevitably accumulated when using Chrome. Includes some hacker friendly features like keyboard shortcuts and ability to easily save and restore sets of tabs. Would welcome feedback from the HN crowd.</comment>


Simple mathematical computations underlie brain circuits - <AUTHOR> http://web.mit.edu/newsoffice/2012/simple-mathematical-computations-underlie-brain-circuits-0809.html <comment><USER2> I'm lazy/stupid, can someone find the link to the paper if there is one?

<comment><USER3> In the interest of fostering discussion, the full paper is available at <https://www.dropbox.com/s/pf1fohxj9r3ua6b/nature11347.pdf></comment></comment>


The Scroll Up Bar - <AUTHOR> http://usabilitypost.com/2014/05/24/the-scroll-up-bar/ <comment><USER3> Dear website developers,

I'm sorry your feelings were hurt when I declined to install your wonderful app that offers access to your website. Perhaps I just wasn't open to the awesome possibilities your app was offering me, but I already have a web browser that works just fine and couldn't be arsed to install more stuff. It's not you, it's me. I'm a bad, bad person. I get it. Now, about your "Scroll Up Bar"... It is indeed a very fine looking user interface, but my web browser already has one. I just can't seem to stop doing things that hurt your feelings, but could you please give me the option to turn that thing off?

If you're really having trouble justifying your job, perhaps I can help you out with a small suggestion. You may have noticed a trend towards wider aspect ratio screens over the last few years. Screens have gotten so bloody wide that practically nobody wants to read a column of text that is fully as wide as their screen! People were designing websites with UI elements on the sides even back when screens were slender 1.33:1 twigs instead of the McDonald's super-sized behemoths we have on our desks today. Perhaps you should take your bar, rotate it 90 degrees, and stick it on the side where there's space for it!

Sincerely,

An ungrateful, lazy, bad person who just can't be pleased.

</comment><comment><USER4> Am I the only one who prefers to read websites in "desktop" mode?

I always feel totally alienated by the mobile page, there is information left out, annoying badly-implemented JS scrollers, etc...

The "desktop" site looks always more nice and familiar, and you can zoom and scroll around as you wish to read everything.

<comment><USER5> No, you're not alone. I almost always choose desktop mode where available, primarily because mobile sites disable zoom and choose settings for margins and font sizes that make their text almost unreadably large - frequently only two or three words per line, with masses of whitespace all around.

Reading such articles feels claustrophobic, because you're stuck in this long tunnel of text, with little visual indicator of how long it lasts, inducing anxiety about wasted time. If you're somewhere in the middle, it's a long trip back up to the top.

The close to optimal mobile browser for me was the original (AOSP) Android browser around 2.3. It rewrapped text on double-tap to fit in the visible page area, meaning you could choose what effective font size worked well for you. And zoom still worked, so you had a good handle on where you were on the page, and an easy way out of it.

Neither Firefox nor Chrome on Android are as good a browser for me. Unfortunately, getting the AOSP browser back is awkward, unless you want to use Dolphin or similar, and besides, it no longer has the rewrap functionality.

PS: Google are the evil people here. They deliberately removed this feature from Chrome and AOSP browser, and are punishing sites that don't serve mobile- specific content - i.e. content that is less usable for people who prefer zoom-based navigation.

<comment><USER6> The feature is still in Firefox for Android. "Text Reflow" in settings.

<comment><USER7> It's not there any more. See Bug 900564[1]. Basically, they removed the pref from beta and release builds last fall because they don't believe it works nearly well enough.

[1]: [https://bugzilla.mozilla.org/show_bug.cgi?id=900564](https://bugzilla.mozilla.org/show_bug.cgi?id=900564)

</comment></comment></comment></comment><comment><USER8> I used to call these type of things, short-lived fads really: User Interface (UI) element of the week. Fortunately, UI isn't changing that often anymore. However, Javascript and the "mobile" platform are bringing "User Interface element of the week" back.

I am seeing lots of weird scrolly things these days. And, pages that blink out and then reappear, as they get rendered and rerendered and rerendered again by Javascript. Lots of other annoying Web 2.0 thingies that do little more than annoy. If I was a better writer, I could probably write a weekly WTF about "User Interface element of the week."

Yes, "fixed bars" are annoying. We've had "fixed bars" on non-mobile for as long as I remember: Main Menu Bar, Title Bar, ooh and now a "Tab Bar" which is just the modern version of Windows MDI, maybe Windows MDI, Navigation bar(s) which sometimes takes up a quarter of the screen height I kid you not, the Bookmarks Bar which gets hidden the first time I open the browser and all corporate links get deleted what a pain.

Including your "bar" in the contents and letting it scroll away might be easiest, and the author noted medium's clever idea.

</comment><comment><USER9> Fixed bars are annoying and should rarely be used. But what's even worse is when the mobile version helpfully removes the content or feature that you'd like to see.

Please just have one site, make it efficient, and be done with it.

<comment><USER10> It's so much easier to fuck up mobile than it is to do it right. And if you're not doing it exactly right, don't do it at all.

Here's what the EC2 console looks like on mobile:

[http://i.imgur.com/MfbCdhU.png](http://i.imgur.com/MfbCdhU.png)

It appears that Amazon is doing this on purpose...

<meta name="viewport" content="width=device-width, initial-scale=1, maximum- scale=1, user-scalable=no">

Yes... _user-scalable=no_

<comment><USER11> > Disabling user-scalable (namely, the ability to double tap to zoom) allows > the browser to reduce the click delay. In touch-enable browsers, when the > user expects the double tap to zoom, the browser generally waits 300ms > before firing the click event, waiting to see if the user will double tap. > Disabling user-scalable allows for the Chrome browser to fire the click > event immediately, allowing for a better user experience.

> From Google IO 2013 session > [https://www.youtube.com/watch?feature=player_embedded&v=Dujf...](https://www.youtube.com/watch?feature=player_embedded&v=DujfpXOKUp8#t=1435s)

Source: [http://stackoverflow.com/a/16910559](http://stackoverflow.com/a/16910559)

<comment><USER12> I doubt that's why. In this case, as the site doesn't appear to render well at all on mobile in the first place, that meta tag was probably just blindly copy pasted from somewhere else that did have a responsive page.

</comment></comment></comment></comment><comment><USER13> They're a problem on non-mobile, as well. If the bar is over content, but the scrollbar isn't adjusted for it, pressing space or pagedown doesn't move down one page worth of visible content. I don't get why breaking pagedown is acceptable. It's my preferred way to read long text.

<comment><USER14> Thank you! It is a huge peeve of mine as well. There needs to be a good post somewhere to publicize this issue. Something you can point to when you find a broken site that lays out the solution so it can be fixed.

But I'm not sure exactly what the mechanism is that causes this; I thought it was simple a case of forgetting to add top padding to the page body, but that doesn't always seem to be the case. Last time I saw a site that did this, it already had the padding but still misbehaved in Chrome. Yet the paging worked correctly in Firefox! Further testing showed Safari worked, so (in this case, at least) it seemed to be webkit-related.

But that's just one scenario. I suspect there's a number of ways people get this wrong, and it's unfortunately not just a single simple fix for all cases.

<comment><USER15> Adding top padding would push the beginning of the content down nice and clear of the fixed header, but that's not enough to avoid the page down problem because for paging purposes it's normally the height of the box from border to border that is used - which seems right and consistent with (vertical) scrollbars normally being drawn from border to border. And top padding's only at the top of the first page of content anyway, not every page.

Anyway Firefox did make some effort to work around this common web design error (that being what I'd call it) which is probably why it behaves differently to Chrome: [https://bugzilla.mozilla.org/show_bug.cgi?id=780345](https://bugzilla.mozilla.org/show_bug.cgi?id=780345) but I still find it hit and miss between from one page to the next. As you mention there are many scenarios - what if the fixed header only goes across say half the width of the page? What if it's less than 100% opacity? What if it varies in height? The browser makers have to resort to "heuristics" and now we're off into the land of deep unpredictability.

While writing this I've also just noticed that - fixed header or no - <USER2> space / page down doesn't go exactly the same distance (in Firefox) as paging down by clicking on the scroll bar. Which is also a bit disconcerting.

</comment></comment></comment><comment><USER16> Firefox Browser for Android's default settings requires you to scroll up somewhat rapidly on the page you're currently reading to reveal the browser's auto-hidden URL bar and menu. I tend to loathe this functionality because it means slightly losing my place every time I want to multitask when reading something.

I suppose it wouldn't be so bad as part of a website when viewed from a desktop environment, because you can easily highlight where you left off on the page much easier than you can on a tablet, for example.

<comment><USER17> You can disable this behavior by unchecking the checkbox in Settings -> Display -> Scroll title bar.

<comment><USER16> Good point, thanks!

</comment></comment></comment><comment><USER18> I don't get why these bars are being used everywhere, personally I find them annoying. Scrolling up takes like half a second...

<comment> vertex-four The sole reason is branding. Websites don't want you just reading content; they want you reading content _on their site_. The most obvious way to remind you that you're reading it on their site, and thus convince you to come back, is a fixed header bar.

<comment><USER19> Funny thing that they make a site that looks exactly the same as every other site, and then they discover that they have a branding problem.

I never have any problem remembering that I'm readding HN.

<comment><USER20> Branding problem, or a content problem?

</comment></comment></comment></comment><comment><USER21> Worse than taking up screen space, these bars often exhibit laggy scrolling behavior and cause other UI bugs. There are very few well working implementations of such fixed bars, partly due to difficulties like the position:fixed implementation in Mobile Safari[0] - unless that has been changed in iOS7.

I highly recommend to refrain from using position:fixed on mobile devices.

[0] [http://remysharp.com/2012/05/24/issues-with-position- fixed-s...](http://remysharp.com/2012/05/24/issues-with-position-fixed- scrolling-on-ios/)

<comment><USER22> Mobile web moves too quickly to care about what was true 2 entire years ago :) iOS got position: fixed a couple versions back, and iOS users upgrade rapidly.

So, the advice not to use position: fixed on mobile may still be good, but iOS isn't the reason why.

</comment></comment><comment><USER23> What's worse is some sites that do this can't seem to differentiate between iPads and iPhones and seem to use percentages everywhere in their CSS. As a result, you get a _huge_ header (which feels larger in landscape orientation).

<comment><USER24> Another big annoyance is when the mobile mode is solely based on the user agent string and there is no way to deactivate it other than changing the user agent (for example Google Search). It's almost as if no Google employee has a tablet device. I would be genuinely interested in seeing behind the curtains of decisions like this one.

<comment><USER25> Google believes tablets are mobile. Heck, with the new maps, Google thinks desktops are mobile!

</comment></comment></comment><comment><USER26> The problem is that he's assuming the primary goal of the site's UI is to make reading the content as enjoyable and efficient an experience as possible.

Sadly, that's rarely the case.

A site like Forbes gets paid every time you click through to another article. Once you've landed on an article and you're reading it, your value to them has been expended. Thus they have almost a diametrically-opposed interest to yours- you want to read the content uninterrupted, and they want you to click another link.

<comment><USER27> One of the many insidious ways in which advertising (and the business practices resulting from it) is overtly harmful.

</comment></comment><comment><USER28> After being into this field for quite a while now, I feel like there are no better web design than no web design.

Plain html works great on any device, is very readable, accessible and _lightweight_. There's nothing to lose in having 0 loc css.

<comment><USER29> I wouldn't say 0 loc CSS is nothing to lose, I've been using Markdown to format some really basic notes, and here's my stylesheet for styling markdown documents: [http://staticresource.com/styledown.css](http://staticresource.com/styledown.css)

It's still a work-in-progress, but it's great for documenting my code as I work on websites. Here's a demo page with some tests of the markdown output I generated on the command-line using pandoc: [http://staticresource.com/misc/demo.html](http://staticresource.com/misc/demo.html) I'm grabbing web fonts from Google. It's responsive and reads well on desktop, tablet, and phone. The styles still work offline (with no web fonts)

There isn't a whole ton of CSS there (I work with files 500 loc CSS up to 5k or 7k a a time. I whipped this up in one morning because I was tired of my IDE's markdown live preview, so now I have folders on my server that are watched, and any time I save a markdown file it automatically regenerates the HTML in the same folder.

Anyway, you can't say there's NOTHING to lose having 0 loc CSS. Here's what that same markdown demo that looks like with no CSS: [http://staticresource.com/misc/demohtml.html](http://staticresource.com/misc/demohtml.html)

Think they are equivalent?

</comment></comment><comment><USER30> I was all ready to complain that I want some sort of nav/menu thing always stuck at the top, but I'm actually OK with the solution presented where it just shows as soon as you scroll up without having to scroll all the way.

<comment><USER31> This is exactly how Chrome for Android works with its toolbar and I think it works very nicely.

</comment></comment><comment><USER32> FIxed bars and JS pop-ups are the window pop-ups of the 90's and really I'm just waiting for someone to make a chrome extension that takes care of 'em in the same way.

The only real issue is that mobile browsers don't allow extensions of any kind (at least the ones I've used don't). So there is no real way to add such customizations to mobile browsers, and we're left hoping they go mainstream enough that someone either creates a browser around that feature (ie useragent switch, which is kind of annoying to use because it means copying the url and switching apps), or a dev in a mainstream browser makes it their weekend project. Neither one of these options is ideal, in the first you're left with a bunch of browsers that do one thing, in the latter you're going to end up with a feature that will slowly stop working as the dev's main work builds and his manager tells him to drop it.

</comment><comment><USER33>
      An interesting way to solve the issue is to hide the bar when scrolling down, and show it when scrolling up.

This pattern is one of the many irritating things about the mobile Chrome and iOS 7 browsers that prevents me from using devices implementing either.

I typically stick to reading around the top of my device, and occasionally I want to re-read something I just read. Instead of just getting to re-read the hidden lines, I have to continue scrolling while stupid chrome or a fixed bar appears, and then finally lets me scroll the content.

It's probably the case that a lot of people love this, but I hate it. If I want to see the browser chrome or navigational elements, I'm happy to tap the top of the window to scroll me there. I don't want the browser trying to figure out what I want to do based purely on scrolling.

</comment><comment><USER34> I was hoping to read about a usability study done when I clicked the link. I do agree for blogs and articles but for web apps I'm not sold.

<comment> dj-wonk Right. Breadcrumbs and/or nav bars on apps are nice.

<comment><USER35> Indeed:

[http://ux.stackexchange.com/questions/33071/are- breadcrumbs-...](http://ux.stackexchange.com/questions/33071/are-breadcrumbs- still-in)

</comment></comment></comment><comment><USER14> I suspect this was influenced by the browser behavior in iOS 7. Almost all the browser chrome (full address bar and status bar) disappears when you start scrolling but reappears if you scroll back up quickly.

In fact, the iOS behavior is rather more nuanced:

      * Scrolling down hides chrome
      * Swiping up quickly reveals chrome
      * Scrolling up slowly does not reveal chrome
      * Scrolling to the top of the page reveals chrome
      * Over-scrolling past the bottom reveals chrome

It's often interesting to see how much consideration Apple puts into small details like this.

<comment><USER36> This is also the best implementation. I think there's some stuff lost in translation when done on the web. Dollars to doughnuts these UI patterns don't have a speed function in them to adjust for intent.

</comment></comment><comment><USER37> The thing about this is that there is, as far as I can tell, no good solution for the fact that it can take a long, long time to return to the top of a page with a lot of text on a mobile device. If I read 3/4 of a lengthy story on my phone and I want to navigate somewhere else on the same website my only practical option is to revisit the main page of the site and start navigating from there.

Do any mobile browsers have a "return to top of page" function? My keyboard has a "Home" key, my phone does not.

<comment><USER38> I don't know what mobile phone you use, but on iOS tapping the status bar scrolls back to the top of the page (or anything else that scrolls in the system).

<comment><USER39> Aside: Is there a way to detect that happening in JavaScript? Just thinking that detecting the user doing that and then showing the site's nav bar again would be groovy...

<comment><USER38> I don't know, but I don't think it's wise to override a system behavior in ways the user doesn't expect. Better just put a button on the page.

</comment></comment></comment></comment><comment><USER40> Dear website users,

We feel your pain. It may not seem like it since we develop ever more complicated UI schemes to overcome the W3C's frankenstandards (seriously, who comes up with a coordinate system based on a 'nominal arms length away' from the screen and then creates another set of units for mobile. I know there's a lot of smart people who contribute great data standards from the W3C, but when it came to presentation standards they either 1) completely forgot their linear algebra or 2) didn't bother to look at Postcript's coordinate system or both).

Some of us are reinventing the browser as it should have been written (with polyfills and shims), but this will take a while to get right. (For those that remember, Alan Kay originally said there should be no browser, just a code container, we are once again getting close to something he said decades before).

We understand that the W3C has set the expectation that everything bad on the web happens because of us devs not following their "standards" (even when alt changes to title changes to picture caption in as many years), but at some point it might be worth asking them "why are your presentation standards so inconsistent and hard to follow?"

Sincerely,

A webdev who is tired of cajoling CSS and JS to reinvent the same god-damned three column layout that should have worked in the 90's (oh wait, you didn't realize that Postscript predates the web? Yes, yes it did. So the W3C could have sought presentation layer experts of its time in drafting presentation standards, but didn't).

</comment><comment><USER41> Someone has already mentioned my JS lib to handle this below, but as the author I feel compelled to mention it myself with some additional explanation.

I built headroom.js [0] to handle exactly this. It simply adds classes at scroll up or down so you can be as fancy as you want (or not!) with the show hide effect. You can set a custom offset (eg. Don't invoke the hide/show mechanism until 100px down the page), you can set a tolerance (eg. Must have scrolled more than 10px before hide/show) and a few other features for more advanced usage.

And for fun I built a little playground so you can explore the various features and find a configuration you like [1]

[0] [http://wicky.nillia.ms/headroom.js/](http://wicky.nillia.ms/headroom.js/)

[1] [http://wicky.nillia.ms/headroom.js/playroom/](http://wicky.nillia.ms/headroom.js/playroom/)

(meta: I submitted it here, but it never gained traction, someone else submitted it to designer news and it absolutely blew up, can't believe it almost has 4000 stars!)

<comment><USER35> Keep it up!! Honestly you deserve more stars..

</comment></comment><comment><USER42> I honestly loathe the "scroll up bar" feature in Chrome browser because it throws off my instincts about how to interact with the UI. If something auto- hides into the top of the screen, my instinct is to pull it down from the top if I want to see it again. That just brings up the Android notification system.

</comment><comment><USER43> For me, the ideal solution is just get rid of the fixed bar, and have a clickable menu drop down.

I don't want a page to analyze every of my behaviors and try to predict what I want to do. Sometimes I just like to scroll up and down to look for stuff, and I don't want some bar flashing in and out.

<comment><USER44> Well, you must have missed the discussion a few days ago about the evilness of the hamburger button. [https://news.ycombinator.com/item?id=7794505](https://news.ycombinator.com/item?id=7794505)

The main argument against using a menu-button is that it hides the contents behind it, which makes them hard to discover and interact with.

</comment></comment><comment><USER45> I don't know if Android has the feature where you just tap the status bar to scroll to top but iOS does. With that feature I'd rather nav bars just stay at the top of the page, I'll just tap the status bar if I need to get back up there, which is almost never anyway.

<comment><USER31> Android doesn't have that by default, you need an app for it, and I'm pretty sure you also need to be rooted. Definitely not something you can depend on users having.

</comment></comment><comment><USER46> > An interesting way to solve the issue is to hide the bar when scrolling > down, and show it when scrolling up.

No. When I scroll up, that's what I usually want to do: scroll up, see some content that is currently out of view. If that bar appears first, I have to swipe an inch more, which doesn't sound that horrible, but it results in an inconsistency between mental model (swipe down 1 inch, see what is 1 inch above) and technological reality (sorry, you need to scroll 2 inches!).

In the eBay Android app, where I want to quickly compare search results, this annoys the hell out of me.

One of the best things about touch interfaces is the natural mapping between mental model and technology. Let's not break this.

</comment><comment><USER47> I see no problems at all with fixed top bars. They take what? 20pixels? 50 pixels at most. It's really not a huge loss. I'm more annoyed by lateral bars since I already use the horizontal space with tree style tab.

<comment><USER48> 40-50 pixels is generally what you want (for decently sized touch targets)

</comment></comment><comment><USER49> I loathe what The Verge has done when browsing the site on an iPad. That awful little black box stays stuck in the middle of my screen, and even selecting close just makes it a smaller black box in the middle of my screen.

</comment><comment><USER50> We reverted the title. The submitted title was "Fixed bars are becoming a new nightmare on mobile".

The HN guidelines ask you not to rewrite titles. Especially please do not rewrite them to make them more controversial.

</comment><comment><USER51> The solution presented there is the same used by Google Chrome on Android, it might surprise a totally new user, but one gets used to it pretty fast. Seems like it's the best solution all around.

</comment><comment><USER52> The worst implementation I've seen was for a desktop only web application. The navigation bar was only expanded when the scrollbar was at the very top. For very long pages they implemented a button that scrolls the user back to the top of the page so the navigation bar expands and the user can navigate. In the meantime, the horizontal space went mainly unused. The boss saw the IBM page and wanted the menus like this.

</comment><comment><USER53> FYI one plugin that does that is [http://wicky.nillia.ms/headroom.js/](http://wicky.nillia.ms/headroom.js/)

<comment><USER41> Thanks for the shout out :) I built this after enjoying the pattern in the Android browser on honeycomb (3.0). They eventually added it to chrome after I suggested it to Paul Irish!

</comment></comment><comment><USER54> Fun pattern, but is it more _useful_? I think its hyperbolic to call losing 160px of reading space on top of a desktop browser a "nightmare". Something a user can see all the time has greater affordances than something that is hidden. Especially if that something is as essential as navigation. Honestly, I think this is more style than usability.

<comment><USER55> Yes, losing 25% of the already-scarce vertical space is a nightmare, to the extent that UX can be a nightmare. Plus, I've seen sites where the nav bar locks the URL bar in position and keeps me unable to scroll away from it, making it more like 50%. It's like I'm looking at the site through blinds!

And it's all for functionality I'm not even going to use!

</comment></comment><comment><USER56> I'm quite surprised to see anybody suggesting this pattern be used, because it's exactly why I had to stop using Firefox for Android. It makes no sense to need to scroll up and lose your place in a page to access the menu. Whichever designer suggested those two actions be bound together doesn't have any business designing.

<comment><USER36> Scrolling has long been established as a transient action. It makes total sense to submerge the menu until such time as it's needed. This pattern is prevalent in plenty of mobile apps. Google Chrome on iOS is a shining example. Safari, as well.

You can make a reasonable assumption that users scrolling down are reading content, and thusly have no need for the menu bar. What I'm seeing from your perspective is that you're failing to recognize that "losing your place" in order to reveal the menu is a complete change of task. By bringing back the menu, or even using it if it were in place statically, your task and intent has shifted. If you've decided to abort your menu task and revert to reading content, it provides less cognitive friction to let the user scroll themselves back to their original place.

My question to you is - what logical sense does it make to stop reading an article midway through and begin interacting with the menu, unless your intent is to navigate away from the content itself? And if it makes sense to you to do this, why do you find yourself changing and aborting tasks so swiftly? Are there other interactions that you've failed to discover that might be beneficial (tap and hold to get a menu, for example)?

TL;DR - you're bitching about an edge case.

</comment></comment><comment><USER57> Vimeo has an odd top-bar that hardly shows up at all when you first load the page, but if you scroll _up_ (when you're already at the top of the page) it unfolds and shows you more videos. e.g. [http://vimeo.com/28408829](http://vimeo.com/28408829)

</comment><comment><USER58> i agree with the post. but i just noticed on my desktop chrome browser that medium also applies the same behavior on here. i believe this is not necessary, as on a desktop i have plenty of reading space and this way im actually experiencing a less usable version of a website....

</comment><comment><USER59> Am I the only one hating Twitter's Android app behavior in terms of fixed bars?

I tend to read tweets from oldest to newest, and the "Home/Discover/Activity" bar always gets on my way. Moreover, I don't even need the top blue bar. Just gimme the content!

</comment><comment> dj-wonk "Creeper" nav bars (an appropriate term, I think) are partly a consequence of mobile devices not letting you instantly jump to the top of a page. Mobile devices should offer a snappy, intuitive way to jump to the top or bottom of a page.

<comment><USER60> Opera on mobile had an awesome implementation of "jump to top": You scroll upwards twice or just quickly enough, and if you still have a long way to go, a button pops up for scrolling automatically to the top. I wish this was implemented universally in Android. [http://lifehacker.com/5784500/opera- mobile-11-is-a-zippy-bro...](http://lifehacker.com/5784500/opera-mobile-11-is- a-zippy-browser-for-android-and-symbian-phones)

</comment></comment><comment><USER61> Is it weird that the title of TFA is "The Scroll Up Bar" and the title of this post is "Fixed bars are becoming a new _nightmare_ on mobile"?

</comment><comment><USER62> Simpler solution: every keyboard has a 'Home' button -> MAGIC. ;)</comment>


Benchmark of Golang slice initialization (Always use known capacity) - <AUTHOR> https://blog.simon-frey.eu/known-length-slice-initialization-speed-golang-benchmark-wednesday <comment><USER2> I think this part "Step 1) is not needed with the append approach, as we just reserve a memory location but the previous values stay there until we write them in step 2. " is not what the Go gc implementation currently actually does.

Copied from reddit: [https://www.reddit.com/r/golang/comments/cn2jdh/benchmark_of...](https://www.reddit.com/r/golang/comments/cn2jdh/benchmark_of_golang_slice_initialization_always/)

Currently make (runtime.makeslice or runtime.mallocgc or duffzero as part of stack allocation) always zeroes the backing array of slice regardless if the element is written to directly or append to the slice. Not requiring the memclr/zeroing would need a prove pass that proves that before the loop finishes noone can observe the uninitialized value by e.g. re-slicing. Which in general when e.g. interfaces and plugins are involved wont be possible to prove. In the case of pointers the memclr is also not avoidable since the garbage collector might scan that part of the memory (if its heap allocated) any time even while the loop is running. [https://github.com/golang/go/blob/e37a1b1ca6afcbe3b02d2dfd59...](https://github.com/golang/go/blob/e37a1b1ca6afcbe3b02d2dfd599ad1d3d926ec34/src/runtime/slice.go#L49)

There could be effects observed due to the difference of having small slices allocated on the stack vs on the heap and differing zero techniques. E.g. for size = 100 there is a jump to duffzero that clears the stack space for the backing array of the slice: [https://godbolt.org/z/wRuF5z](https://godbolt.org/z/wRuF5z) while for size = 100000 the backing array is heap allocated and zeroed as part of the runtime.makeslice call.

There is a optimization fusing make+copy (to avoid the memclr) in the pipeline for go1.14 but this would not trigger here either.[https://go- review.googlesource.com/c/go/+/146719](https://go- review.googlesource.com/c/go/+/146719)

<comment><AUTHOR> Awesome! Will give all the resources a look and see how to improve the article</comment></comment>


The Mathematics Of Murder: Should A Robot Sacrifice Your Life To Save Two? 🔢🔪 - <AUTHOR> http://www.popsci.com/blog-network/zero-moment/mathematics-murder-should-robot-sacrifice-your-life-save-two

<comment><USER2> The needs of the many outweigh the needs of the few. Or the one.</comment>


Podio – A podcast player using React and twin.macro and Howler - <AUTHOR> https://github.com/22mahmoud/podio <comment><AUTHOR> Hey Guys,

Podio is a Podcast client application, using:

iTunes public API.

Fetch each podcast data by creating the Netlify Lambda function.

and parsing the RSS XML feed with the cheerio package and return the result as a JSON. (the lambda function).

After finished this project, I believe all my future projects will be written with Typescript + twin.macro both make me more productive.

Howler.js for handling audio, so I made a React context wrapper for the state and functions so I can access it from any component.</comment>