The viability of JavaScript frameworks on mobile - <AUTHOR> https://joreteg.com/blog/viability-of-js-frameworks-on-mobile <comment><USER2> This is good. Many frameworks are just too freaking huge for mobile but even when you use tiny frameworks and you dump a bunch of images into them you're going to have similar issues (at least on load).

Honestly using the DOM API isn't all that hard. Yes it awkward, verbose and sometimes cumbersome but it's still pretty straight forward. I'm actually really liking react lately but if I want something done well for a mobile I almost never use a framework.

Another thing this article didn't touch on was latency. When I was doing work for vehicles that had poor internet access via satellite every single http call just killed the load (this included fetching css, javascript, etc). I can't stress enough how much better your page can load if you combine as much stuff as possible, even images if you can display them as backgrounds.

<comment><USER3> This is heartening. How do you deal with cross-browser differences, especially considering you're supporting older mobile devices?

<comment><USER4> You deal with them one at a time. It's not like there's magic involved.

Our SPA isn't even using jQuery. Loadtimes are fast, app is very fluid.

Many people seem to not understand that when you query the dom for a node, you can store that node and reuse it throughout your app.

</comment></comment></comment><comment><USER5> This is where small frameworks like Mithril shine.

The site says 12KB, for some reason, but minimized and gizipped, the latest version is closer to 7 or 8 KB IIRC.

[http://mithril.js.org/](http://mithril.js.org/)

<comment><USER6> Just came back to mention that two of the most well-known Mithril-based projects, Flarum.org[1] and Lichess.org[2] are open source and have mobile UIs that you can try out, so if anyone's interested in seeing non-trivial codebases that use a "lighter approach" alluded to in this article, there you go.

[1]([https://github.com/flarum/flarum](https://github.com/flarum/flarum))

[2]([https://github.com/veloce/lichobile](https://github.com/veloce/lichobile))

<comment><USER5> [http://flarum.org/](http://flarum.org/) is especially relevant since it is a competitor to Atwood's Discourse which sparked the current discussion.

[http://lichess.org/](http://lichess.org/) is an [f|F]ree online chess platform.

</comment></comment></comment><comment><USER7> With Microcosm we consciously chose to go the other direction: Do the work server-side and serve HTML.

Basically... the old way of doing things.

An example site [https://www.lfgss.com/](https://www.lfgss.com/) is 280KB on first load (and most of that is Mozilla Persona) and subsequent requests are usually around 10KB.

Even though that company is now dead, I'm still working on it and aim to strip out Persona (it's deprecated) and to set a first load goal of 100KB (which should be easy to achieve).

People should feel the power of their devices, and the only way to do that is to have those devices do less, not more.

<comment><USER8> Persona is not deprecated. It was moved to "community ownership", which is not "deprecated" just as much as the average open source project is not deprecated. It's a bit like saying that if Red Hat stopped paying it's developers to work on the Linux kernel then Linux itself must be deprecated.

I wish more sites would use Persona and so I'm heartily disappointed to hear someone expecting to strip it out of an existing usage.

(Aside, I gave a presentation on the subject, for what that is worth. [http://blog.worldmaker.net/2015/05/13/mozilla-persona- talk/](http://blog.worldmaker.net/2015/05/13/mozilla-persona-talk/))

<comment><USER7> I'd love to continue using it... but I don't want to run an instance as I want to point at someone else's instance. If I have to run my own instance then I need to know I can maintain it and keep it secure, and I am not a Node guy and I find the code and all of it's dependencies to be too much for me to say that I am the man to keep an instance secure and maintained.

The thing is that I want it to perform as well as my application. Just look at Persona's portion of blame for the time, transferred bytes, transfer waterfall, connections: [http://www.webpagetest.org/result/151020_X5_17EP/](http://www.webpagetest.org/result/151020_X5_17EP/) (and that's with connection preconnects working... older browsers have it worse).

Persona is the biggest performance hit on my web app, and it's holding me back and I do not wish to run my own instance (just to put it behind CloudFlare and make the whole thing fly).

Whilst performance hurts, and it does hurt, and whilst I live under the shadow of "Mozilla aren't owning this and pushing it forward"... I'm very seriously thinking of using [https://github.com/go- authboss/authboss](https://github.com/go-authboss/authboss) and making a centralised front-end for it so that I can achieve a very similar thing in a simplified way that I can support and maintain.

The key thing though... I need performance from it. I don't have that today. I have a web account... but it needs to perform and I've seen no improvements on that front in the entire time I've used it.

PS: I even checked Auth0 and others, but I'm doing so many logins per month that it would cost 100x the costs to run my entire platform to use any of the paid services.

<comment><USER8> I had some success in loading Mozilla's JS library asynchronously (using RequireJS in that particular application) after initial render/dom-load. That certainly mitigates some of the performance issues. (You'd notice even more of a bit of a slowness in the UI picking up if you were already logged in on page load, but that is more and more common on the internet these days, for many of the "SSO" authentication systems, so I don't consider that much of a problem.)

Also, from your waterfall you've posted here, most of the Persona stuff is happening in background/parallel anyway: the big slowness in getting to render start certainly appears to me to be your fonts more so than Persona, which is what I would expect to see. That is, I'm wondering if you are scapegoating a bit here as the impression that I get looking at your waterfall is that you won't gain as many milliseconds as you might think by removing Persona.

</comment></comment></comment></comment><comment><USER9> Rule #1 for optimisation: "You can't make code run faster. You can only make it do less." It's true for mobile devices as much as everything else.

<comment><USER10> Fortunately a lot of what these libraries do is spin bloated wheels so there is a lot of opportunity to do less without losing features. This is why I write mobile web apps with vanilla JS only. It takes a little more time up front, but the result is vastly superior to what any library can offer.

<comment><USER11> Have you tried using server-side rendering as a viable alternative that lets you use frameworks like React?

</comment></comment></comment><comment><USER12> The article is interesting but the Atwood article was mainly about how badly _Android_ javascript performs vs iOS. If you have a 5x difference in performance between platforms it will be impossible to maintain feature parity.

<comment><USER13> It's relevant; iOS may be faster but the user experience still sucks when web devs rely on heavy JS frameworks. Rather than bemoan how much JS sucks on Android, devs should realize that JS sucks everywhere and use it as sparingly as possible.

This is especially relevant since the fragmentation on Android means this problem won't be going away soon. Even if Google fixed its JS performance tomorrow, so many phone manufacturers bundle their own browser that it will be a long time before those users with "old, slow" JS on Android go away. I don't know how the JS engine is bundled on Android, but if it's bundled with the core OS then the vast majority of phones would just never get updated. Developers have to deal with that, so unless you're ok with excluding a large percentage of mobile devices on the street, dealing with slow JS performance is simply a fact of life on mobile.

<comment><USER14> It's not JS that sucks; V8 performance is actually pretty competitive with Dalvik, if not faster. It's two other things:

1\. There is a cost to download frameworks, and most webdevs ignore that cost. A native app has the Android class libraries already on the device, oftentimes already loaded into memory. A webapp that pulls in 600K of JS code + framework has to read that all over the network, parse it, and JIT it before execution can even begin.

2\. The native Android GUI frameworks render views on the GPU. Chromium will only render views on the GPU if you have a CSS transform or opacity property set. If you're not very careful, you can easily trigger an expensive layout + repaint calculation on every frame.

It's possible to write webapps that perform just as well as native, with fancy animations and fluid user experiences. I had some existence prototypes when I was still at Google, and some of the research for that went into the current Google Search app experience on Lollipop. But it was a huge pain as far as the developer experience went, and a lot gets lost in translation when productionizing. It basically involved treating the browser as an OpenGL canvas, where certain combinations of CSS + HTML would render text and boxes into a texture and then other combinations would let you move textures around and fade them together in the window.

<comment><USER13> JS does indeed suck on mobile; since it's single-threaded by design, all those blocking operations (you already mentioned some examples) add up. Hence where you get both issues you mentioned - those refreshes are only necessary because the single-threaded nature of JS causes a few dozen event handlers in your framework to fire on every change you make. It also doesn't help that most mobile devices aren't exactly pushing the envelope on single-threaded performance.

And let me be clear: JS being single-threaded isn't a bad thing in itself (the thought of a multi-threaded language in the browser gives me nightmares). It just makes the user experience of JS suck on mobile. And that's not going to change any time soon given the glacial pace of patch/update deployment on Android.

> It basically involved treating the browser as an OpenGL canvas, where > certain combinations of CSS + HTML would render text and boxes into a > texture and then other combinations would let you move textures around and > fade them together in the window.

That approach -- while interesting from a technical standpoint -- kind of defeats the purpose of a browser :) I mean, you're basically building another browser inside the OpenGL window...

<comment><USER14> Native apps are _also_ effectively single-threaded: all of your code, by default, runs on the UI thread, and you need to use AsyncTask or explicitly spawn a Thread to do work in the background. If you need this functionality on the web, there's Web Workers, so it's functionally the same story.

CSS transitions/animations, BTW, run on a separate thread in Chromium. This is the primary difference between them and requestAnimationFrame, which always runs on the main thread.

</comment></comment></comment></comment></comment><comment><USER15> Most of the performance issues people see on mobile (and desktop!) with javascript isn't with javascript performance itself anymore (unless you're doing some crazy stuff), but with the relatively expensive repaint/reflow browser operations.

<comment><USER16> This point is often missed. It isn't javascript that's slow, it's the DOM and all its overhead and cruft that's slow. Or it's the connection that's slow. An important distinction.

</comment></comment><comment><USER17> I think a lot of developers wanted mobile web performance to catch up with desktop and mobile native that we believed it would happen, and much faster than was ever really likely. We're used to things getting better quickly when it comes to technology.

Flagship phones improve things a little each year, but to quote William Gibson, the future is here, but unevenly distributed.

<comment><USER18> > We're used to things getting better quickly when it comes to technology.

It doesn't help that some influential people in the software industry, like Joel Spolsky, told us to bet on the hardware improving fast. See for example:

[http://www.joelonsoftware.com/items/2007/09/18.html](http://www.joelonsoftware.com/items/2007/09/18.html)

Particularly this part:

> a couple of companies, including Microsoft and Apple, noticed (just a little > bit sooner than anyone else) that Moore's Law meant that they shouldn't > think too hard about performance and memory usage… just build cool stuff, > and wait for the hardware to catch up. Microsoft first shipped Excel for > Windows when 80386s were too expensive to buy, but they were patient. Within > a couple of years, the 80386SX came out, and anybody who could afford a > $1500 clone could run Excel.

By contrast, he describes Lotus optimizing 1-2-3 so it could run in 640K of memory. Who would want to be today's equivalent of Lotus? So just pump out features and wait for the hardware to catch up, right?

</comment></comment><comment><USER19> Blame the language and not the platform is what you're essentially saying. Ok so initial payload can be what 600kb per your argument. But at least once I have delivered that my actual interactions on the server side can be somewhat a minimum instead of re-rendering more HTML and sending across the wire to the handset.

That being said yes you must develop on a crappy computer if you want to be known as dev that's known for making apps snappy. Is there a lot of fat one can cut from these frameworks yes... but I think Atwood's initial argument is that android just sucks with Javascript. The many cores, single thread per tab just makes the experience anemic with rich web applications.

<comment><USER13> > Blame the language and not the platform is what you're essentially saying. > Ok so initial payload can be what 600kb per your argument. But at least once > I have delivered that my actual interactions on the server side can be > somewhat a minimum instead of re-rendering more HTML and sending across the > wire to the handset.

Unless your mobile browser aggressively purges its cache due to the limited memory on most mobile devices. Then you're going to have to reload the payload every time you bring the page to the foreground; or at a minimum reload the framework (which usually takes a noticeable amount of time as the framework creates a bunch of temporary data structures).

</comment></comment><comment><USER20> I think this post on mobile performance is relevant: [http://sealedabstract.com/rants/why-mobile-web-apps-are- slow...](http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/)

</comment><comment><USER21> or you could just write regular Javascript. Browsers seem to be pretty good at handling Javascript, CSS, and HTML. The default size of vanilla js is actually 0 KB and that's not even gzipped.

<comment><USER22> And after reaching a certain level of complexity what you have is an ad-hoc framework of about the same size but is a slow, bug ridden implementation of half of one of the ones in the OP.

<comment><USER23> That really depends on the work. There is a lot of APIs in the browser these days that people are not using. For example, there are people adding jQuery to a project just to have the selectors when querySelector and querySelectorAll have been available for some time.

With good care, you can create libraries suited for your problem and keep code size and complexity down. Don't forget that when adding frameworks you're also adding their complexity to your project. Imagine having to debug the internals of angular... I shiver just too think of that.

The thing is that using frameworks is cool up to the moment when you reach a framework quirk or bug and need to dive into it as well, then you're no longer working in your problems domain but on generic framework land and that can be much trickier than building your own, specially if it is a solution made for a single problem.

But yes, I agree with you that if complexity grows enough you start requiring a special type of developer with high skills to keep this bespoke code running well.

</comment></comment></comment><comment><USER24> I know GWT isn't the most popular framework (it isn't really a framework, is it?), but I've been a fan of it for a while. It solves three critical problems that have plagued web development:

1\. Cross-browser compatibility.

2\. Code performance.

3\. Code organization (there are many JavaScript frameworks whose selling point have been making JavaScript more organized).

But in regards to this article, one often overlooked feature of GWT is that dead-code is automatically removed from the compiled JavaScript:

[https://www.quora.com/How-fast-is-GWT-compared-to- JavaScript...](https://www.quora.com/How-fast-is-GWT-compared-to-JavaScript- and-other-languages-that-compile-to-JavaScript)

Thus you don't have to include the entire Angular/React/Ember/JQuery whatever library just to get a few features for your site.

<comment><USER25> Sure but GWT == writing Java, downloading an heavy an complex SDK , and writing imperative UIs. Sure it comes with widgets but you can find the same widgets in JS.

Compare with React,AngularJS and co : way more popular,declarative UIs , if you need static typing you can use Typescript which needs no heavy runtime.

GWT might make sense for some LOB app for desktop but not for a mobile webpage.

<comment><USER26> Google Closure Compiler [1] can also perform dead code removal, but it requires extra work annotating all public APIs and naturally it can't cope with dynamic/indirect calls.

[1]: [https://developers.google.com/closure/compiler/](https://developers.google.com/closure/compiler/)

<comment><USER15> So does UglifyJS. At least, obviously dead code (e.g., if(false) {} )

</comment></comment></comment></comment><comment><USER27> I think Ember is ahead of the curve on this one. Ember 2.0 introduced no new features, and instead only focused on stripping out deprecations, dead code, or platform specific stuff for browsers they don't support any more.

(Disclaimer: I'm heavily invested in Ember.)

<comment><USER28> The article showed Ember 1.9 coming in dead last because of code size. 2.0 is supposed to be a little better but do you really think it's going to be ahead of the curve? It seems pretty unlikely... I hope you'll say more.

<comment><USER29> > The article showed Ember 1.9 coming in dead last because of code size. 2.0 > is supposed to be a little better but do you really think it's going to be > ahead of the curve? It seems pretty unlikely... I hope you'll say more.

To be fair to Ember here - Ember includes Ember itself, Ember Data and jQuery in that payload. React is just React - you'll probably want to include Redux (2KB) or Alt (33KB) and then potentially a whatwg-fetch polyfill or superagent, normalize and other libs to (possibly) fill out some jQuery features (Zepto @ 9.1KB), if not jQuery itself.

</comment></comment></comment><comment><USER30> Web and Mobile has many frameworks(JS/native) that can be used to solve similar problems. I am wondering how we can write code that can be re-written quickly on other frameworks as a metrics of performance tests. I definitely think that developers should test there code/app on slower/older phones. A performance mindset creates better scalable tech and can save the company a lot of money in the long run and at the same time can be a core of user experience

</comment><comment><USER31> Even the Facebook mobile web part that has been developed in React, the people search, feels rather slow on all my mobile devices (incl high end iOS amd Android devices).

<comment><USER25> IMHO It's still faster than most webapps on mobile. I use an old Alcatel with Android 2.3 to benchmark performances on low end handsets and Facebook performances are ok compared to Gmail or even Google search which takes 3+ seconds to load just to display a search box. I think Facebook has managed to do an acceptable job if you compare their app to other web apps.

The truth is, the mobile web space is not a good as developers expected it to be in 2015 unless users visit websites with expensive devices, which most of them do not. Making a website responsive , while being an improvement, doesn't make it automatically mobile friendly.

</comment></comment><comment><USER32> I am curious about how Discourse works. I have several call to "[https://github.com/discourse/discourse/commit/1061a9ed06c500...](https://github.com/discourse/discourse/commit/1061a9ed06c50083ee6d05c7bac72c86f54433a9") when scrolling the comment of this article. Any one have an idea why they are repeating calls to GitHub?

</comment><comment><USER33> I have been using T3 [http://t3js.org/](http://t3js.org/) very small and very easy.

</comment><comment><USER34> Would be interesting to see Meteor stats there too

<comment><USER35> How about Sencha Touch? I'm guessing it's a beast.

<comment><USER25> Sencha Touch is pretty fast. When I was doing to Cordova development it was still the fastest js framework when it comes to UI responsiveness. Does it makes sense when it comes to developing mobile websites ? I don't know. I think sticky headers , footers , transitions and stuff like that make very little sense for a website. What kind of mobile website would you develop with a mobile UI framework ?

<comment><USER35> Maybe logging in to the admin side of one of my applications to check analytics, approve new memberships, and the like? I shouldn't need to package and distribute that as an app, but some of the mobile-friendly widgets are handy.

</comment></comment></comment></comment><comment><USER36> Honestly, as an android-user, I just run my browser with JS disabled by default. My phone is much faster, and I don't really want 90% of the "features" the JS is trying to give me. Too many sites do it poorly, and it just ruins the experience.

</comment><comment><USER37> JS frameworks don't have to be huge performance killers. I use Chaplin.js, and it's crazy lightweight and awesome even on my old iPhone 4. The user interactions are basically the speed of a native app, or even faster.

</comment><comment><USER38> What's the status of asm.js in mobile? It would be nice if there was a front- end framework in some other language that could compile to asm.js.

</comment><comment><USER39> very interesting</comment>


What will happen when Clock Speeds stop increasing? - <AUTHOR> http://glomek.blogspot.com/2008/09/when-clock-speeds-stop-increasing.html

<comment><USER3> I agree with the sentiment (wouldn't it be nice to not treat computers, particularly full of nasty chemicals, as items meant to be thrown away every other year).

Unfortunately you will find that this isn't the way it works. Manufacturers will keep rebundling the same general parts in slightly different arrangements, with fresh design, and sell it to the disposable-product loving public. Even beyond the core processor, a PC is made up of a ton of little accessories that require drivers, and these are going to keep shifting around for the next couple decades. Linux is arguably better than Windows at supporting old outdated hardware, but good luck finding current OS support for anything but the most popular 1993 (now() - interval 15 year) products in the latest kernels.

In my opinion the precedent was set by the auto industry. Sure there are a few people who collect any given type of car and daily drive it 40 years later, but for every one of those there are hundreds of people who keep their old car only as a curiosity (i.e. show car), and for every one of _those_ there are probably hundreds of cars that are trashed and sitting in junkyards or have been recycled into new ones.

<comment><USER4> A more positive way of expressing the sentiment might be "manufacturers will find a way of improving performance, though the gains might be harder to capitalize on than clock speeds or core count". Either way, given that the industry can't survive selling old products, they will find a way of selling us more stuff. We can only hope that we actually get some benefit out of the new products.

On the plus side, notice that today, with a computer that is 5 or so years old, you can get on the internet, watch flash video, play music, etc. etc. Compare that to using a 5 year old PC in 2000, or even worse, a 5 year old PC in 1995.

<comment><USER5> _"manufacturers will find a way of improving performance, though the gains might be harder to capitalize on than clock speeds or core count"._

Don't count cores out. Intel isn't.

[http://www.ciol.com/Intel/CP-Intel-CIO-Update/Future- Intel-d...](http://www.ciol.com/Intel/CP-Intel-CIO-Update/Future-Intel-design- codenamed-Larrabee/8908110053/0/)

 _Larrabee is expected to kick start an industry-wide effort to create and optimize software for the dozens, hundreds and thousands of cores expected to power future computers._

</comment></comment></comment><comment><USER6> We haven't had a significant clock speed increase in a while; it's pretty much already happened.

<comment><USER7> Will I ever be able to buy a 10Ghz CPU?

Someone please comfort me.

<comment><USER8> No, i don't think so. there are 10ghz transistors, but the're gallium arsenide rather than silicon. I'm going to pretend that i know (i don't), if you try to go much faster than 5ghz with silicon you have to use smaller electron bundles -- lower votage -- because the chips will melt if the voltage is upped to much. because the signal is less clear, undetected/uncorrected errors start happening all the time. remember, at 10ghz 1 in a billion mistakes is terrifying.

 _hugs_

<comment><USER9> I thought some of the ALU's where double pumped in p4 and newer cpu's. If that's the case we are already running some part's of the CPU at 3.7 * 2 = 7.2Ghz.

Edit: Yea, the integer ALU's operate at twice clock speed. I think the move to 64bit CPU's slowed down the clock speed race as did adding more cores and insane amounts of L2 cache due to heat issues. As a side note when I picked up my quad core CPU at 2.4 GHz it crushed my old 1.8Ghz 32bit cpu so I think they are making some wise tadeoffs due to system buss limitations. Plus the old P4's seemed to trade off a lot of effective for pure clock speed. So after we get back on track we might see a new clock speed race when we have 8 - <USER2> cores.

<comment><USER6> You put the carriage in front of the horse: we're moving to multiple cores _because_ we can't increase the clock speed. The number of transistors we can fit on a chip is still following Moore's Law, we're just using them in a different way.

We were squeezing more and more performance out of single cores by lengthening the instruction pipeline, which increased the amount of instruction parallelism processor's could exploit at runtime. The difficulty is that as this pipeline is increased, it takes longer to send information across it. As we decrease cycle time (same as increasing the clock speed), it becomes harder and harder to communicate from one end of the pipeline to the other in a single clock cycle.

</comment></comment></comment></comment></comment><comment><USER10> Parallelization + horizontal scaling is my guess. If you can't scale up, scale out.

</comment><comment><USER11> The author definitely makes a mistake in equating slow programs with poorly- written programs. Yes, it's true that people who write horrible code often also write horribly non-performant code, and that rushing a product to market without performance testing is far too common in our industry. But in my experience (and I've done a lot of performance tuning), making something perform generally requires selectively damaging the code by making it less understandable and by breaking rules about encapsulation and separation between layers. There's a reason why that whole "premature optimization is the root of all evil" saying is so popular. Performance tuning is also incredibly time-consuming and labor intensive. It might make you feel more hardcore to do it, and it certainly be a useful intellectual exercise, but it's still time that could well be spent on other types of product improvement.

The increase in clock speeds has been a primary driver behind the ability of people to use higher-level languages, as well as the ability for people to write larger and more complicated applications. So assuming that a stop to the increase in clockspeeds will lead to better software is flat-out wrong; if anything it'll help to essentially halt certain kinds of progress in language and framework development by preventing people from using higher-level abstractions that don't perform as well.

</comment><comment><USER12> There will always be new uses for more power, ones that we can't see today. It's silly to say you'd be happy to see that go away.

And, yes, I think a lot of the gains in future computing power will be in parallelization, but that wasn't the point of this article.

</comment><comment><USER13> No more singularity is the most obvious effect.

I don't see people talking about this, but the exponential curve broke.

Sure you can add cores, but you could do that 5 years ago (or earlier) too - and you don't see AI made even by well funded organizations.

It's over - don't wait for it.

<comment><USER14> Relax. Even if we had the hardware today we'd still have no idea how to write passable AI software. By the time somebody figures that out, maybe the hardware will have caught up.

<comment><USER15> We do know how to write AI, problem is it stops being AI just as soon as we've written it.

</comment></comment></comment><comment><USER16> Asynchronous processors will be here soon!

<comment><USER8> nope. coders have to figure out threads first. once there's a nice model you can teach a good EE student, we get to use fewer transistors on clocks.

</comment></comment><comment><USER17> I wrote software that finds textual graphics in a bitmap. I parallelised it by running, say, 4 (or any number of) threads, each handling 1/4 of the bitmap. It works really well, and there's no overlap.

<comment><USER18> That's called an 'embarrassingly parallel' problem, it's not the general case. I guess, just like 'big O', people have to take a class to appreciate the space of what it's possible to parallelize and how much it buys you.

<comment><USER17> At University we used to refer to big O as Roy Orbison. Just an example of our kind of smalltown humour.</comment></comment></comment>


Ask HN: What is the best tool to create a good looking resume? - <AUTHOR> I am applying for a job soon, where a CV is required. Meanwhile, I only have my LinkedIn-profile that exports to a terrible looking PDF.
Do you know any modern tools that allow you to create good-looking resumes and CV's?
Resume-now is flash-based and quite terrible, and Kickresume doesn't let you try anything if you don't want to pay right of the bet. <comment><USER2> Learned this from a friend of mine. Build it in HTML, and have a nice looking display stylesheet that you can email to people who might appreciate such a thing, and also have a print stylesheet which you then print to PDF from your browser of choice.

Looking forward to getting rid of my latex version soon.

</comment><comment><USER3> Well I was just checking this post about markdown-based resume tool... played with it a little and looked nice for me, may help [https://github.com/awalGarg/cv-maker/](https://github.com/awalGarg/cv-maker/)

</comment><comment><USER4> What's wrong with MS Word/OpenOffice/LibreOffice? You might need an updated CV every couple of years and who knows if other web-based tools still exist then.

<comment><AUTHOR> I've never enjoyed making my CVs in a text-processor. Maybe I have the wrong idea of a CV, but I'd like it to be somewhat pretty and also maintainable. I really wish that jsonresume.org takes off and to finally have one standard that works everywhere. Whether a web app dies or not.</comment></comment>


Changes To VODs On Twitch - <AUTHOR> http://blog.twitch.tv/2014/08/update-changes-to-vods-on-twitch/

<comment><USER3> If I understand this correctly, videos stored forever are being limited more now. Someone correct me if I missed something there.

If an acquisition is in the works I wonder why it would prompt this - <USER2> Google can handle the storage requirements. A way to cover themselves legally possibly?

<comment><USER4> If Google is influencing this decision, might it prefer to have recorded video stored on YouTube? The blog post mentioned that Twitch removed the 2-hour limit for exporting VODs to YouTube.</comment></comment>


1k minecraft - <AUTHOR> http://js1k.com/2014-dragons/demo/1854 <comment><USER2> The creator wrote up a blog post on his entry:

[http://birdgames.nl/2014/04/js1k-post-mortem- minecraft/](http://birdgames.nl/2014/04/js1k-post-mortem-minecraft/)

Lots of very interesting details, but surprised to see setInterval instead of requestAnimationFrame

<comment><USER3> maybe because it saves a few bytes? I don't think performance advantages were the reason.

</comment></comment><comment><USER4> Very nice! The texturing and lighting are what really makes this demo. Unfortunately, it only displays correctly for me in Firefox Developer Edition, not FF 33.0, in which the picture is skewed: [http://i.imgur.com/7i74m36.jpg](http://i.imgur.com/7i74m36.jpg).

If you're into tiny cube-based 3D engines also have a look at this demo for the Lobster programming language ([http://strlen.com/lobster](http://strlen.com/lobster)): [http://i.imgur.com/ZZWFkXn.jpg](http://i.imgur.com/ZZWFkXn.jpg). Its entire source code fits in the screenshot.

<comment><USER5> _" tiny cube-based"_ \-- is that the same as "voxel based"?

<comment><USER6> I'd say it depends on context. Historically, voxels have been analogous to pixels. This has been somewhat blurred by Minecraft, and the widespread reporting on and discussion of it.

At first, the cubes in Minecraft are analogous to tiles (as in the tiled backgrounds or maps of 2D games), but when you use them to build models and things, then they become like large voxels.

</comment></comment></comment><comment><USER7> Nice - though I must say this kind of graphics (with music..) was done in similarly sized 1k/4k assembly demos -- [https://www.youtube.com/watch?v=G1Q9LtnnE4w](https://www.youtube.com/watch?v=G1Q9LtnnE4w)

<comment><USER8> Formally speaking, both Descent and Minecraft (inspirations for each respective intro) are based on cubes, but I don't think there are many more similarities. In any case, thanks for that blast from the past!

</comment></comment><comment><USER9> Impressive!

I can't help but love things like this, if for no reason other than that it makes programmers look like bona fide magicians (and thus justifies exorbitant day-rates).

<comment><USER10> Sort of. Every field has its wizards and it's usually easy to tell them apart from the apprentices.

</comment></comment><comment><USER11> I wonder if a few bytes could be saved by encoding the source in 7bit ascii, decoding and running through eval. Not sure if that makes sense.

<comment><USER12> I don't think 7-bit ASCII behaves the way you think. It's typically the same 8-bit bytes but with the most significant bit clear. So, there's no saving to be had, it doesn't "contract" the bits across neighboring bytes.

<comment><USER11> Yes but that's exactly what I meant. ASCII wastes 1 bit by character (the 8th bit isn't used). What if the source was encoded in such a way that it is "contracted" (the unused bit of the first character is the first bit of the second character, etc). Sorry for the 3 days late reply. The decoding function would have to be very small to make it worth it though.

</comment></comment></comment><comment><USER13> Doesn't work in FF 33.1.1 on windows 8 -- each line of the image/video is shifted so the result looks \\\\\\\\\\\\\

<comment><USER14> It's working for me in FF 33.1.1 on Windows 7.

<comment><USER15> it also works for in in FF 3.1.1 in Arch Linux

</comment></comment></comment><comment><USER16> This one in Lobster, roughly the same amount of code, no textures, but is interactive (you can actually mine & build): [http://i.imgur.com/ZZWFkXn.jpg](http://i.imgur.com/ZZWFkXn.jpg)

<comment><USER17> What are the sizes of `vec.lobster` and `3dhelpers.lobster` though...

</comment></comment><comment><USER18> Many other are sweet, this one uses WebGL and is very nice [http://js1k.com/2014-dragons/demo/1868](http://js1k.com/2014-dragons/demo/1868) (tested on Chrome)...

</comment><comment><USER19> If I remember correctly the lava is the hardest thing to efficiently render, correct? Cool regardless.

<comment><USER20> Why would it be any more difficult than rendering the water?

<comment><USER19> Light comes off of it. So it moves, flows and such like the water but it also has to render the lighting effects relative to all that. I could be wrong though, I know the water is difficult to render as well.

<comment><USER21> I haven't looked at the code of this demo but it seems there's no dynamic lighting at all, the "lighting" of the face of each cube depends only on which side it's facing as far as I can tell.

You can see that the underside of trees is pretty luminous for instance.

</comment></comment></comment></comment><comment><USER22> I don't think I've ever seen this site before. It's fantastic

</comment><comment><USER23> Incredible!!</comment>


Anyone used appcelerator (titanium) framework to buld android app? - <AUTHOR>

Hi All,
Just wondering if anyone used appcelerator titanium framwork to convert the web app into native android app? How did the project go and would you recommend going this route verus android sdk?
Thanks, <comment><USER2> Yes. I use it everyday to build apps for clients, including Android. I recommend it.

<comment><AUTHOR> Thanks Tzm. Can you do push notifications using Titanium framwork? Also wondering how does the updates to app work? Do we only update the server side HTML or do we need to update the app in the app store?</comment></comment>


Opsware Closes HP Merger: Marc Andreessen collects $98,279,186.25 - <AUTHOR> http://blogs.mercurynews.com/docudrama/2007/09/20/that-loud-cheering-you-just-heard-was-opsware-execs-closing-the-hp-merger/

<comment><USER2> Congratulations, Marc! You've made your money, now do something important.

<comment><AUTHOR> What, like create the web as we know it...again? :-)

<comment><USER2> God, no! Something good this time. :-)</comment></comment></comment>


What can doctors learn from pilots and cyclists? - <AUTHOR> http://www.bbc.co.uk/news/health-35929557 <comment><USER3> > [Aviation] professionals are given every reason to cooperate, because they > know that investigations are not about finding scapegoats, but learning > lessons. Indeed, professionals are given a legal safe space so they speak up > honestly(...)

This is probably the single most important thing that aviation got right and I don't think people understand that well enough, in general.

The attitude in the air industry, when something goes wrong, is 1) understand what happened; 2) figure out what needs to be changed so it doesn't happen again. There is no step 3. There _especially_ isn't a step of "punish those responsible" or some such nonsense.

Only the final goal of improving outcomes matters, and indulging the emotional human demand for punishment does not necessarily help that goal, it can even seriously hinder it. If only we could apply the same rationality to, say, the penal system.

<comment><USER4> I agree completely that we tend to focus too much on punishment rather than preventing future harm. That said, one thing that makes the airline industry unique is the binary nature of problems. If something goes wrong and the plane doesn't crash, then there's no harm to passengers so it's easier to forgo punishment. If something goes wrong and the plane crashes, there's no one left alive to punish. Add to that the fact that there is no possible nefarious reason for a pilot to accidentally crash a plane. A pilot can crash a plane on purpose, but if they do something stupid and the plane doesn't crash, they're likely to be believed when they say it was just a stupid mistake. Compare to a doctor who doesn't suffer when a patient suffers (at least not physically) and in fact may even save money from certain oversights. It's much easier to assume bad intent where mistakes are profitable rather than fatal.

<comment><USER5> Pilots aren't the only ones who can make a deadly mistake in aviation. If a traffic controller or maintenance personnel makes a mistake, are they punished?

<comment><USER6> Sometimes, it depends on who notices the mistake and why.

Consider, a safety first culture can easily penalize someone for showing up to work drunk _IF_ someone notices before a problem shows up. But, if nobody notices till after the fact then they should be free to admit it without problems. Because there where two issues, they where drunk _AND_ nobody noticed. You can't fix the second issue if you don't know it's a problem.

</comment></comment></comment></comment><comment><USER7> A very good, in-depth look at this is here:

[http://www.newstatesman.com/2014/05/how-mistakes-can-save- li...](http://www.newstatesman.com/2014/05/how-mistakes-can-save-lives)

A story of how a pilot's wife died in surgery and how he campaigns to have doctors follow the example of airline crash investigation.

Particularly interesting/infuriating is the bits about how often someone in the room knew that someone was going to die, or get the wrong leg amputated, but status games prevented them from intervening.

</comment><comment><USER8> > Only through proper investigation was it discovered that a key factor was > clinicians failing to put sterile dressings over the catheter site; the > medical equivalent of not using antibacterial hand gel.

> The introduction of a five-point checklist - a marginal change - saved 1,500 > lives over 18 months in the state of Michigan alone.

If you find this kind of thing interesting I can recommend The Checklist Manifesto. The book describes many other situations where the use of checklists has had similar benefits (particularly in health and aviation).

<comment><USER9> > The book describes many other situations where the use of checklists has had > similar benefits (particularly in health and aviation).

However, and I feel that this is a point often missed about this book: a large part of the improvements in process had little to do with checklists. "Wha- wha-wha-whaaaat? 'Checklist' is in the title!" Checklists don't do you any good if you're dealing with doctor's who are way to full of themselves and don't feel the need to listen to the little people like nurses.

No, the key element to that book was that nurses were empowered to knock doctor's off their high horses if the checklists weren't followed. The book isn't about checklists. The book is about:

1\. Develop a framework of practices for your tasks at hand. Checklists are often used for this. For software, think release management. Tests pass, UA signed off, etc.

2\. #1 won't make a damned bit of difference until, from top to bottom, anyone can call out anyone else if short cuts are taken. You're the director of the hospital? I don't care, you still need to wash your hands before touching that patient. VP of marketing is wanting us to skip those manual tests to save a day? Screw you, it's on the list and we're doing it.

The book isn't about checklists, it's about empowerment to make improvements.

<comment><USER10> I haven't read the book but what you're describing is what's called Crew Resource Management[1] in aviation. It's especially valuable in cultures where second guessing your superior is career suicide. CRM stresses that the captain and first officers are a team and how they should communicate.

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

<comment><USER9> It's been a few years since I've read the book, but if the book didn't specifically mention this in relation to aviation, I recall that aviation was at least was mentioned as an example.

</comment></comment></comment></comment><comment><USER11> Here is an article about medical checklists that is really eye opening:

[http://www.newyorker.com/magazine/2007/12/10/the- checklist](http://www.newyorker.com/magazine/2007/12/10/the-checklist)

<comment><USER12> The most eye opening part about that piece was a letter to the editor, from some bigwig doctor-administrator at a major hospital, that appeared an issue or two later. He thought that the whole idea of checklists was ridiculous, because all that is needed is for everyone to just do what they're supposed to do.

Seriously.

I'll try to find the letter. (I'm a subscriber and can access back issues online.) To me, his attitude illustrates the biggest problem of the medical profession. How could someone, who we have to suppose is an intelligent human being, miss the entire point of the article! In my opinion, only arrogance explains it.

<comment><USER12> Okay, the letter to the editor is from the January 21 issue, a few weeks later. Here's the part I take issue with:

"While a retrospective checklist has great value […] a prospective system of protocols, memorized by all the staff and made part of ongoing care, is more likely to influence patient outcomes."

You see that part about "memorized by all the staff"? One of the major points of the checklist piece was that simply going by memorized protocols, whether you're going to pilot a plane or perform surgery, just does not cut it. The human animal is prone to failing to follow complicated, extensive protocols from memory.

The doctor who wrote the letter is a professor emeritus at a medical school. A screen shot of the letter is here:

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

<comment><USER13> The phenomenom you're talking about is called "interrupted checklist" in aviation. Humans are actually quite good at following memorized lists _unless_ they get interrupted mid-task. When this happens, the risk of a mistake goes up significantly, because your mind has already "checked off" the task that you were in the progress of completing when you got interrupted.

See for example: [http://flighttraining.aopa.org/magazine/2002/October/200210_...](http://flighttraining.aopa.org/magazine/2002/October/200210_Instructor_Report_Interrupted_Checklist_.html)

The psychology behind this is also the reason for the "sterile cockpit" procedures during critical phases of flight. [https://en.wikipedia.org/wiki/Sterile_Cockpit_Rule](https://en.wikipedia.org/wiki/Sterile_Cockpit_Rule)

<comment><USER14> They have implemented a form "sterile cockpit" in some places when nurses prepare medications - by having them wear special vests that signal nobody should interrupt them, and (i think) doing it in a special quiet room.

</comment></comment></comment></comment></comment><comment><USER15> In a similar vein, Andrew Godwin gave an excellent talk at PyCon last year called "What can programmers learn from pilots?" [https://www.youtube.com/watch?v=we4G_X91e5w](https://www.youtube.com/watch?v=we4G_X91e5w)

</comment><comment><AUTHOR> I suspect a lot of software developers would benefit from a similar approach when it comes to improving quality and, in particular, improving security practices. There seems to be a striking dichotomy in our industry today between those who welcome responsible disclosure or even actively encourage it with things like bounty programs, and those who consider anyone knowing a potential vulnerability in their systems a danger and will treat even a genuine attempt to help through responsible disclosure as some sort of threat to be handled by lawyers or police. I'm fairly sure about which group generally makes more secure software. However, it would be a welcome cultural shift if not only support for responsible disclosure but also publicly acknowledging and discussing security issues were more common in our industry, so others could learn from the same mistakes.

</comment><comment><USER16> Somewhat off topic, but as someone with an interest in aviation I enjoy reading the aviation safety reports, like the aaib reports [0], airprox reports [1] or the CHIRP newsletters [2]. (All UK based)

I try to find a similar 'tone of voice' when conducting or participating in RCA's for incidents during my day job

[0] [https://www.gov.uk/aaib-reports](https://www.gov.uk/aaib-reports)

[1] [https://www.airproxboard.org.uk/Reports-and- analysis/Monthly...](https://www.airproxboard.org.uk/Reports-and- analysis/Monthly-summaries/Monthly-Airprox-reviews/)

[2] [https://www.chirp.co.uk/](https://www.chirp.co.uk/)

<comment><USER17> > I try to find a similar 'tone of voice' when conducting or participating in > RCA's for incidents during my day job

Me as well though, as a pilot, I find that the NTSB is a little too free in about 10% of cases in assigning blame to the flight crew as the primary cause. Yes, most crashes are crew-caused, but I've read many where the crew gets the blame as primary rather than as secondary.

In my day job, I've also brought in the concepts of FAR 91.3 and have explicitly given that level of authority to the team responsible for running our production systems.

FAR 91.3 reads:

Responsibility and authority of the pilot in command.

(a) The pilot in command of an aircraft is directly responsible for, and is the final authority as to, the operation of that aircraft.

(b) In an in-flight emergency requiring immediate action, the pilot in command may deviate from any rule of this part to the extent required to meet that emergency.

(c) Each pilot in command who deviates from a rule under paragraph (b) of this section shall, upon the request of the Administrator, send a written report of that deviation to the Administrator.

The intent is to make clear to the team that they have the final say and that, while I may make inquiries later as to why they made a certain deviation from our norms, SOPs, or policies, that they do have the right to do so, and that all I'm able to ask for is a report. Couple this with demonstrated blameless treatment of post-mortems and you get a pretty good outcome out of good people. We do want to know exactly WHO did WHAT, WHEN, HOW, and WHY, but we use to introspect and make the future better, not to punish.

</comment></comment><comment><USER18> There's a book "The Checklist Manifesto" which describes this practice - <USER2> great, fast read. [http://amzn.to/1SsqgLu](http://amzn.to/1SsqgLu)

</comment><comment><USER19> From the article:

> Today, aviation is arguably the safest form of transportation. Last year the > accident rate had dropped to a low of only four fatal crashes from a total > of 37.6 million flights.

I'm curious, does anyone know how/from where that was derived? That sounds pretty incredible.

<comment><USER20> Presumably the FAA would have records of all flights as you have to submit flight plans to ATC. Then they just see how many crashes there were that resulted in loss of life.

I mean, I don't know where I would personally pull those numbers from, myself, but it seems trivial for an Agency to report on.

<comment><USER17> Those aren't the "aviation" numbers, but rather more likely the "scheduled airlines" numbers.

The fatal rate for all of aviation is well over 4 accidents last year, and there are not flight plans for even half of the general aviation flights.

There were 5 aviation fatals last month in the US: [http://www.ntsb.gov/_layouts/ntsb.aviation/month.aspx](http://www.ntsb.gov/_layouts/ntsb.aviation/month.aspx)

For scheduled service, I only see one fatal accident last year in the US, and that was a Cessna 207 (single engine, piston aircraft) that crashed in Alaska, hardly relevant to scheduled airline service in transport category twin-jets.

[http://www.ntsb.gov/_layouts/ntsb.aviation/brief.aspx?ev_id=...](http://www.ntsb.gov/_layouts/ntsb.aviation/brief.aspx?ev_id=20150718X04523&key=1) I suspect that most people would not consider this airline service, though it was operating as scheduled service.

Non-US in 2015 had 4 fatal accidents on scheduled airline service, which is presumably the numerator the article is citing:

GermanWings 9525 (suicidal pilot): [https://en.wikipedia.org/wiki/Germanwings_Flight_9525](https://en.wikipedia.org/wiki/Germanwings_Flight_9525)

TransAsia 245 (pilot error subsequent to mechanical failure): [https://en.wikipedia.org/wiki/TransAsia_Airways_Flight_235](https://en.wikipedia.org/wiki/TransAsia_Airways_Flight_235)

Triguana 257 (poor weather, unclear pilot contribution): [https://en.wikipedia.org/wiki/Trigana_Air_Service_Flight_257](https://en.wikipedia.org/wiki/Trigana_Air_Service_Flight_257)

Metrojet 9268 (bomb): [https://en.wikipedia.org/wiki/Metrojet_Flight_9268](https://en.wikipedia.org/wiki/Metrojet_Flight_9268)

</comment></comment></comment><comment><USER21> A checklist is a useful form of technology assistance, although ancient. Maybe some sort of AI technique will make it easier in the future. Sort of an assistant to guarantee conformance.

</comment><comment><USER22> This is directly applicable to production outage processes in our industry, as well.

</comment><comment><USER23> That red is the safest light.</comment>


Taiwan's presidential race tempts Foxconn tycoon Terry Gou - <AUTHOR> https://www.scmp.com/news/china/politics/article/3006384/taiwans-presidential-race-tempts-foxconn-tycoon-terry-gou <comment><USER2> To call the KMT "pro-Beijing" is ignorant to the point of being laughable, frankly.</comment>


Ask HN: DefCON 18? - <AUTHOR>

Is anyone going to DefCON this year? This is my first time - a bit nervous - but really getting excited from all the information I learn. Have you ever gone / are going? <comment><USER2> Sweet, that looks interesting.

I have some friends in Vegas I haven't seen a while. Could be fun.</comment>


Why London Has More Crime Than New York - <AUTHOR> https://www.bloomberg.com/view/articles/2018-06-19/why-london-has-more-crime-than-new-york <comment><USER2> "But since the financial crisis, the national government has cut police funding by 25 percent"

I think this is the key point, government spending has been under severe pressure since 2010. The excuse is the financial crisis although I suspect it has more to do with political ideology.</comment>


NYC Pension Earns $40M Over 10 Years, Pays Fund Managers $2B - <AUTHOR> http://thereformedbroker.com/2015/04/09/nyc-pension-earns-40-million-over-10-years-pays-fund-managers-2-billion/ <comment><USER2> It's what has become of capitalism. First there were producers, they sold what they created themselves and made a profit. Then there were merchants who bought and sold and made a profit on the difference. Then investors who invested in merchants and made a profit by collecting interest on lended money. Nowadays, it's the fourth level of capitalists, the fund owners, who takes peoples money and invest it into investors who then invests it into merchants.

A common scam is to email 10000 people betting picks. To half of them you predict that team A will win and to the other half that instead team B will win. Repeat the process with the ones who got the right picks and after a few iterations you have a small group of gullible people who think you have supernatural sport prediction abilities.

Fund managers do the same thing all the time. They have a portfolio of funds, some of which purely due to chance will not beat their market line and will then be folded into those who did. Then new funds are started to fill the void. This way, almost every fund can appear to beat the market average.

That's just one of the many tricks available to fund managers. Another is choosing the right index to compare your fund against and selecting which time period puts it in the most favorable light. Maybe the performance over the last three years were extra strong or maybe it had a dip so let's compare over the last seven years instead?

The worst thing is that you can't abstain from playing the game. Your retirement money is on the stock market and fund managers will take a big slice of it in fees whether you like it or not.

<comment><USER3> > The worst thing is that you can't abstain from playing the game. Your > retirement money is on the stock market and fund managers will take a big > slice of it in fees whether you like it or not.

What are you talking about? There has never been a time where investing was cheaper and there were more options to invest without a fund manager getting a slice.

If you want to discount your pension benefit because you don't control the asset allocation (and I think you should, but that is an opinion) that is fine, but it isn't some sort of "rigged game" that you don't have options in.

<comment><USER2> Most of us doesn't have any disposable income to directly invest. Instead we have indirectly become investors thanks to the part of the salary set aside for us in the form of taxes and payments to pension plans. I don't have the numbers, and it differs from country to country, but it's a huge chunk of your salary. Like ~20% of your gross income is used to finance your retirement because you might live several decades after you retire.

The Swedish system (totally simplifying here) works so that once a year you get to allocate about half your tax collected savings to a list of funds selected by some government officials. Another part of your pension if paid by your employer through a pension broker and again you can select among a list of approved funds. All of the funds you can choose from charges a hefty fee to manage your capital.

Had I had the choice I would have withdrawn all my money and paid of my home loans which would have given me a completely risk free return of 3%/year. Instead I can only choose among these funds whose fund managers managed to grease some government official enough to put them on their approved list.

<comment><USER3> In that specific case, you do seem to be trapped, and I too would be frustrated about that, but it seems like you have the trapper wrong. The financial markets are providing the cheapest investment options ever, but your representative government is taking that away from you.

I'm not even willing to say that is a net bad thing (there may be all manner of benefits that come along with it), but place the blame where it belongs.

</comment></comment></comment></comment><comment><USER4> I'll be honest and admit this is one area where hedge funds do get gready.

Most funds work on a model of 2 and 20, meaning they take 2% of assets they manage to run the fund and then take 20% of the profits as their compensation.

This works when you manage 100 million as the 2% can cover most costs, but gets absurd when you manage 100 billion. In cases like this the 2% gets absurdly big and you just can't hire enough people or buy enough tech to eat up this money. It becomes free profit, and that is borderline abuse.

The idea with hedge funds originally was, we think we can beat the market and we only get paid when we do, out of the 20% of profits that we take. Essentially we are betting on ourselves and we eat only when we do well,

With 2% of 100 billion, it turns out you get paid no matter how well you do. Venture capital funds are equally bad in this regard:(

Pension funds need to be better about negotiation fees.

 __EDIT __Someone asked me what to look for when investing in a hedge fund.

There are really only 3 things:

1) fees, 2 and 20 is standard and if you are investing a "small" amount, less than 20 million, you should expect to pay this.

2) lock up time. Generally you should be able to redeem at the end of any month with 20 days notice, ie if you want to redeem for May 1st, you need to inform them by April 10th. No fund should be able to lock your money up for more than a month, though some will try.

There is an exception for this in funds that by definition invest in illiquid assets, such as venture capital or real estate that can take a year or more to mature, but even then 90 days is absolute max you should tolerate. ie if a VC tells you you are locked up for 5 years, and some will, you should tell them thank you and move on.

3) track record. Don't invest in any hedge fund less than 5 years old, unless you have special knowledge or a healthy risk appetite. Its just not worth giving someone else the chance on your dime. Most new funds are started by people leaving a fund and if they are good they get seeded by their previous fund, friends and family. Make them prove themselves before you put yoru money into them.

<comment><USER5> 4) If you're investing any "small" amount, don't invest it in a hedge fund. Invest it in a passively managed (index) fund. I pay .3% a year on my assets and get market returns.

<comment><USER6> Move over to Vanguard. I pay 0.05% for American stock index funds. In fact, all of their various stock index funds are less than 0.3%.

<comment><USER7> Put you still end up paying around 0.2%-0.4% in platform costs. Or is this different in the US?

<comment><USER8> The most expensive ETF I use in vanguard is %0.15. Past the expense ratio for the ETFs I pay no fees.

</comment></comment></comment></comment></comment><comment><USER9> Can someone clarify this? Because the article explains:

> "Over the last 10 years, the return on those "public asset classes" has > surpassed expectations by more than $2 billion, according to the > comptroller's analysis. But nearly all of that extra gain — about 97 percent > — has been eaten up by management fees, leaving just $40 million for the > retirees, it found."

Note "surpassed expectations" in there. That makes it sound not like the _total_ return was $2B but that the return was $2B above projections, and after fees this was functionally erased leaving return at projected level. Am I misunderstanding the language here?

<comment><USER10> My read is that the fund managers created an additional $2B in exceeded expectation/value, then billed 97% of that created value. In other words, stay home, don't use these guys, don't pay them $2B, get the same returns. That's how I understand the point.

<comment><USER9> Yeah that's how I'm reading it but then I guess the question then becomes whether the projections were made specifically with a hedge fund strategy in mind or if they would have been the same for a more conventional investment approach.

I'm not trying to discount the take-away that the fees are very high regardless of the projection basis, but I think it's important to understand the difference. If these criticisms are not clearly reasoned or communicated, I think that fuels the perception in the financial community that these complaints are hysterical and unfounded and should be dismissed.

</comment></comment></comment><comment><USER11> Primary source: [https://comptroller.nyc.gov/newsroom/comptroller-stringer- bi...](https://comptroller.nyc.gov/newsroom/comptroller-stringer-billions-in- pension-fund-fees-paid-to-wall-street-have-failed-to-provide-value-to- taxpayers/)

The wording of both primary and secondary sources doesn't make the facts uncovered by the analysis particularly clear, IMO. Based on my reading, these are the facts:

* Managers of public investments (public stocks, bonds, etc) outperformed their benchmarks by at least $2.1 billion before fees, and charged at least $2 billion in fees. Fees were at least 95% of excess returns, but less than 100%.

* Managers of hedge funds, private equity funds, and real estate investments underperformed their benchmarks after fees by $2.6 billion. Amount of fees is not stated.

<comment><USER12> That's the way I read it, heaven forbid they provide the actual report.

Also, if we assume 80% of the $160 billion is in public investments that achieved their benchmarks net of fees over the past 10 years $2b in fees seems pretty reasonable at 0.16% ((2 billion /10 years)/(160*.8))

</comment></comment><comment><USER13> The question which isn't answered in the article is: how would the fund have done if passively invested in the market? If the market lost money over the same time period, then although extremely high, the fees are a relatively "good deal" (since the fund was up $40M, and the alternative would be losing money). If they're talking about the last 10 years however, it looks like the market should have returned about 70%, which makes the fund manager's performance look even worse.

<comment><USER14> S&P 500 returned about 92.09% from 2004 - 2014.

They referenced it being a 160 billion dollar fund so they really should have been looking at returns of closer to 100 billion...

[http://ycharts.com/indicators/sandp_500_total_return_annual](http://ycharts.com/indicators/sandp_500_total_return_annual)

*although if all large pensions/trusts/endowments were passively invested in the market, some of these financial companies on the s&p list would not have been able to steal so much from pensions so i'm wondering what type of effect that would have had on total market returns

<comment><USER15> Nice try. $SPX is not where you want $160bn of _pension money_. 10% maybe, with similar investments in treasuries, commodities, cash, etc.

<comment><USER16> I somehow got downvoted for pointing this out yesterday, but with target return rates of 7-8%, pensions can't invest in what most of us would consider a prudent portfolio. At least not in a low inflation environment (since targets seem to all be nominal rather than real).

While I would agree that a pension fund shouldn't be in all equities (or investment with similar risk profiles) if the fund managers are mandated to target 7.5% returns its hard to see how they can include a sizable cash or treasury component and expect to hit that.

<comment><USER15> Leverage

</comment></comment></comment></comment></comment><comment><USER17> Here's the original story: [http://mobile.nytimes.com/2015/04/09/nyregion/wall-street- fe...](http://mobile.nytimes.com/2015/04/09/nyregion/wall-street-fees-wipe- out-2-5-billion-in-new-york-city-pension- gains.html?ref=nyregion&_r=1&referrer=)

<comment><USER18> Non mobile version : [http://www.nytimes.com/2015/04/09/nyregion/wall-street- fees-...](http://www.nytimes.com/2015/04/09/nyregion/wall-street-fees-wipe- out-2-5-billion-in-new-york-city-pension-gains.html)

</comment></comment><comment><USER19> Related: The best study I'm aware of that attempts to estimate the distribution of fund manager skills is this one by Fama and French (of 3 factor model fame) from 2009: [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1356021](http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1356021)

<comment><USER20> You are missing the wood for the trees.

The real skill is collecting 2.5 billion in fees, for essentially no value added.

</comment></comment><comment><USER21> My county recently changed to using a passive investment strategy for pensions and there is a push for the whole state of PA to change to a similar model.

[http://www.philly.com/philly/opinion/inquirer/20150301_Follo...](http://www.philly.com/philly/opinion/inquirer/20150301_Follow_the_Montco_model_on_pension_reform_and_save_billions.html)

</comment><comment><USER22> These results actually make sense. The 10 year period covered a tumultuous time in our economy. When the market drops 20%, no fees are paid, but no breaks on future fees are offered either. So let's say they start with $100 billion. The fund loses 20% one year, then rebounds exactly 20% the next. If charging 20% of profits, $4 billion in fees are paid on the $20 billion "gain," even though investors made nothing. They've actually had a net loss of $4 billion after paying fees on their "gains".

That is primarily why these numbers seems so ridiculous - the market had a few bad years, and then came back around. The people in charge of deploying this money should negotiate better terms, like paying fees only on _net_ returns over longer periods of time (5 years instead of one year, for example). At the end of the day, it's their own fault for cutting lousy deals. $160 billion gives you a pretty big bargaining chip on fees.

<comment><USER23> > At the end of the day, it's their own fault for cutting lousy deals.

Victim blaming. Well done.

<comment><USER22> Oh please. If you're in charge of $160 billion, you better be one of the most sophisticated investors on the planet, and wield your extraordinary power to achieve the greatest returns for your stakeholders. Those fee agreements are clear as day. They should know precisely what can happen if they choose to pay fees on yearly gains instead of on net gains from inception.

Stupid people aren't victims; they're just stupid. The bankers had a responsibility to their shareholders to ask for the highest fees possible, and the managers of the $160 billion had a responsibility to say no. Looks like the bankers did their job.

<comment><USER23> Well said. Honestly.

So, let's play out the theories:

1) The pension managers WERE some of the most sophisticated investors on the planet.

So what the hell happened? You originally called them "irresponsible." Now you've edited to call them "stupid." What's your theory about what happened to these world-class investors? My point being, they can't simultaneously be in the "most sophisticated" class, and also in the "irresponsible" / "stupid" class.

Kickbacks? Got overly greedy and mis-fired? It could happen to literally anyone? Bad luck?

2) The pension managers WERE NOT some of the most sophisticated investors on the planet.

I agree with your assessment that they SHOULD HAVE BEEN. So what the hell happened? Did they lie when they were hired? Did they have a great track record (luck?), but flubbed this? Or did the person who hired them and put them in charge (the mayor?) trust someone they shouldn't have?

The real victims are the pensioners, and this story should be investigated. If not on their behalf, then as a lesson for other pensioners, pension managers, and the people who manage pension managers.

<comment><USER22> I edited it because "irresponsible" wasn't strong enough in this case. What they did was idiotic. I think they were on the stupid side...with this kind of money floating around, any hint of kickbacks or corruption would quickly float to the surface. I'm sure that the funds they invested in were run by world class investors, but the pension manager(s) simply didn't understand the implications of the fee agreement.

<comment><USER23> Again, they can't simultaneously be in the "most sophisticated" class, and "idiotic."

Unless your assertion is "even the most sophisticated investors can be idiotic."

I'd say "idiotic" should be upgraded to "colossally idiotic." $40M earnings on $160B in 10 years?

So, what do you think?

<comment><USER22> I don't think that the pension managers were sophisticated, but rather were idiots. They went to world class bankers to deal with the money, who did a world class job of creating an awesome fee structure for themselves.

<comment><USER23> So then who put idiots in charge of a $160B pension? And why did they do it?

Not expecting an answer from you - I'm saying these become the questions I want answers to.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER24> This is why pension funds should not be treated as "sophisticated investors", allowed to invest with unregulated hedge funds. The overall performance of the hedge fund industry is on a par with the results here. Most of the returns go to the fund managers. Why anybody invests with those clowns is unclear.

Pension funds, as a class, cannot beat the market. They _are_ the market. They should be in index funds and bond funds with very low management fees.

</comment><comment><USER25> They should've used Vanguard. ;)

</comment><comment><USER26> Sooner or later, investors will wisen up to the fact that hedge funds are not an asset class; they are a compensation scheme.

Who makes the decision to put pension funds into hedge funds anyway? This is just filtering away money from poor people, who would have seen better returns from an index fund. Disgusting and obscene.

<comment><USER3> > Who makes the decision to put pension funds into hedge funds anyway?

Pension fund managers. They are often also well compensated for this decision making process. Many, many hedge funds and ibanks spend as much time/energy courting pension fund managers as they do generating returns.

This is because the customers of the pension (the people that will want the benefit) are largely a captive market and are frequently unsophisticated financially. Its one of the many reasons I will not take a job that uses pensions as a benefit (and am baffled when unions fight so hard to keep them).

<comment><USER27> Public unions like pensions because they are defined benefit plans and are guaranteed a specific monthly benefit. The risk is passed to the tax payers because they need to cover any poor investments.

<comment><USER3> Let me rephrase. I don't understand why union members feel comfortable trusting a large portion of their employment benefits to the whims of the legislatures or much more rarely now, private companies, that "garauntee" them, nor to the capabilities of the pension manager. The downside of lack of mobility, lack of choice, and poor performance all seem like they would be deal breakers to me, but again, I've never worked in a pension system.

Defined benefit plans can of course be had without using a pension so that seems a red herring.

</comment></comment></comment></comment><comment><USER28> This article is pretty garbled. Matt Levine is, as usual, excellent: [http://www.bloombergview.com/articles/2015-04-09/new-york- di...](http://www.bloombergview.com/articles/2015-04-09/new-york-discovers- wall-street-charges-fees)

</comment><comment><USER29> The New York Times article seems to be talking about the _extra_ gain, which I presume means gain in addition to beating the benchmark. Here's the quote:

"Over the last 10 years, the return on those "public asset classes" has surpassed expectations by more than $2 billion, according to the comptroller's analysis. But nearly all of that extra gain — about 97 percent — has been eaten up by management fees".

I read this as meaning that the _extra gain_ meaning gain minus benchmark gain was $2B and most of it was eaten by fees (which is still bad, but not as bad as the article and its title seem to suggest).

<comment><USER30> I don't think that's correct. For example, the article says

Until now, Mr. Stringer said, the pension funds have reported the performance of many of their investments before taking the fees paid to money managers into account. After factoring in those fees, his staff found that they had dragged the overall returns $2.5 billion below expectations over the last 10 years.

<comment><USER31> There appear to be two uses for the word "expectations" here, for two different things. There was the original expectation that the fund manager promised, that was exceeded. Then there's the expectation of what NYC would be able to withdraw, which failed to account for fees.

Expectation A: Fund value will be X. Reality: Fund value is X + 2b.

Expectation B: NYC can cash a check for X + 2b. Reality: NYC only gets X + 40m.

The reporting isn't very clear, IMO.

<comment><USER30> Agree. Reporter did a poor job. I would think the expectation should be the relevant benchmark, meaning, passive portfolio like Vanguard invested in similar proportions of stocks and bonds.

</comment></comment></comment></comment><comment><USER32> Isn't this true of most actively managed funds?

</comment><comment><USER15> This is why I believe people who think you can just sock money into a "low cost index fund" and never think twice about it are misguided. Even if you end up with _most_ of your money in said low-cost index fund, it's important to be engaged, informed and educated.

<comment><USER33> How so? The article shows how NOT using an index fund hurts.

<comment><USER15> Rather, I think the article is showing us how not being informed hurts. It took them 10 years to understand what was happening with their money? Unacceptable.

Learning how investing works, breaking out of the pie-chart bs sent to you in your nice quarterly statements and really understanding how your money is invested.... Like i said, I don't have an opinion on where you put your money but I think the idea that you can hand it over and never think twice because you're in a low-cost fund is misguided.

</comment></comment></comment><comment><USER34> This translates to net annual return of 0.0025% :)

</comment><comment><USER35> If they had simply used a dart board or other randomized device, I bet they would have made the same $40M but saved the $2B.</comment>


Meet the major Silk Road dope dealer who only got 10 years in prison - <AUTHOR> http://arstechnica.com/tech-policy/2015/05/meet-the-major-silk-road-dope-dealer-who-only-got-10-years-in-prison/ <comment><USER2> This is another example of the arbitrariness of the justice system. 10 years for 104 kg of MDMA? That's at least 300,000 doses. So many people have gotten so much more time for so much less.</comment>


Your brain can fix bugs while you sleep - <AUTHOR> https://medium.com/@santhoshsundar/your-brain-can-fix-bugs-in-your-sleep-2db6f2baf178 <comment><USER2> Not enough programmers/founders/workers exercise this principal.

Our mind pushes us to believe that hours worked = productivity. But time after time this has been disproved when work is to be sustained over long periods of time[0]

Once you learn this; it will help you so much as a programmer.

TLDR If your having trouble with bug/feature - have a nap or go for a bike ride.

[0]: [http://www.cnbc.com/2015/01/26/working-more-than-50-hours- ma...](http://www.cnbc.com/2015/01/26/working-more-than-50-hours-makes-you- less-productive.html)</comment>