A NASA Engineer Became an Astronaut After Being Rejected 14 Times - <AUTHOR> http://www.popularmechanics.com/space/interviews/a16978/clayton-anderson-interview/

<comment><USER2> Amazing story but the interview is not interesting at all. Doesn't talk about his struggles. Just generic fluff.

Here is the link to reviews for his book.

[http://www.amazon.com/Ordinary-Spaceman-Boyhood-Dreams- Astro...](http://www.amazon.com/Ordinary-Spaceman-Boyhood-Dreams- Astronaut/dp/0803262825/ref=sr_1_1?ie=UTF8&qid=1440187843&sr=8-1&keywords=The+Ordinary+Spaceman&pebp=1440187903410&perid=0W89271FCJG0XNQTV01T)

</comment><comment><USER3> Reminds me of the story of Charles Walker.

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

Went on three shuttle missions with a BS in engineering and never joining NASA.

</comment><comment><USER4> Being an astronaut for NASA would be more interesting if NASA had a functioning launch system. NASA still has too many astronauts. They had something like 140 at peak; now they're down to 46 or so.

Once Space-X gets their Falcon/Dragon system man-rated, this may change.

<comment><USER5> If Space-X can get launch costs down, this number will likely explode, as will commercial astronaut programs.

<comment> david-given While I agree with the sentiment, I do think the word 'explode' in this sentence was possibly not a good choice?

<comment><USER6> I'd expect the number of astronauts to skyrocket :)

<comment> david-given Q. What's the difference between a bomb and a rocket?

A. Bombs blow things up. Rockets blow things _up_.

<comment><USER7> Err, don't rockets blow things down, to get an upward push by reaction?

<comment> david-given Everyone knows that rockets work by pushing against the atmosphere!

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> He has an awesome story. I had the good luck to interview him a little while ago for a sporadic podcast I do: [http://projectidealism.com/posts/2014/1/31/podcast- episode-1...](http://projectidealism.com/posts/2014/1/31/podcast- episode-17-that-moment-is-given-to-you-by-the-lack-of-gravity)

</comment><comment><USER9> A surprising number of "NASA engineers" from JSC became astronauts. When working at JSC, these engineers interact with the astronauts, and having a senior astronaut on your side is an advantage.

Additionally, a large proportion of astronauts apply multiple times before selection, although 14 times is probably a record.

</comment><comment><USER10> On the one hand that's some admirable persistence right there.. on the other I don't know.. how would you feel if your doctor had been rejected 14 times from med school before getting his degree?

<comment><USER11> I think the astronauts are more patients than doctors. They are test subjects. Every move in space is carefully planned by committees on the ground. No doubt it is a demanding job requiring all sorts of skills, but it isn't the same as a surgeon. Absent some worst case scenarios, responsibility and decision making is far more shared.

<comment><USER12> Astronauts are some of the most highly trained people on the planet.

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

<comment><USER11> Training and responsibility are different concepts.

</comment></comment></comment></comment><comment><USER11> Glad to see that this guy doesn't appear to be politically connected. So many astros are that I had assumed anyone taken into the program so late in their career would be related to a senator or three. It's nice to be proven wrong.

But I remain under the impression that astro selection is very political.

<comment><USER13> Which astronauts were politically connected prior to selection?

<comment><USER11> For starters ... all who want to westpoint. To go to the point you need a recommendation from either sitting congressmen/senator, or a "career" officer of note in the US armed forces. Westpoint is not open to just anyone with the grades. You very literally have to know people in high places.

[http://www.usma.edu/admissions/sitepages/apply_nominations.a...](http://www.usma.edu/admissions/sitepages/apply_nominations.aspx)

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

(That's just the easiest to research. If you dig into most astronaut's backgrounds you can find prominent people who helped them along.)

<comment><USER13> The academies are indeed open to "just anyone," but grades aren't the only consideration. Members of Congress have processes for requesting the nomination letters, and anyone can request one. There is strong competition for nominations.

I've had a few friends who attended West Point and the Air Force Academy, and they were all "normal," middle-class high school students, but with great grades, athletic achievements, and evidence of leadership ability.

Have any other examples of political influence in astronaut selection?

</comment></comment></comment></comment><comment><USER14> Good for him, chase your dreams.

</comment><comment><USER15> Persistence is so often an underrated trait</comment>


I found the hacker behind a 850k computers botnet - <AUTHOR> https://twitter.com/underthebreach/status/1227926756637782016 <comment><USER2> When they say computers do they mean windowsX or Macs or smartphones?

<comment><AUTHOR> windows

</comment></comment><comment><USER3> Tldr .he did a whois lookup and then found his Facebook</comment>


Is it a phone, is it a bank? - <AUTHOR> http://www.economist.com/news/finance-and-economics/21574520-safaricom-widens-its-banking-services-payments-savings-and-loans-it

<comment><USER2> Sending money via SMS doesn't sound very secure. Lending to a phone you can just throwaway, steal or clone doesn't sound very secure either. When do Kenyan hackers fraud this service out of existence

<comment><USER3> Maybe the market is small enough, and the transactions small enough, that the competent hackers are attacking other systems.

<comment><USER4> The market is large enough, the transactions are relatively large, too.

In Kenya, M-Pesa is by far, the #1 payments service, with nearly half the country using it. It grew acceptance as a replacement for the other way of remitting money from the cities to villages - busses. Prior to M-Pesa, bus drivers would act, for a fee, as money carriers, bringing income back from the cities to families back home.

The competent hackers were, literally, brute-forcing the old system. Bus drivers are easier to compromise than mobile handsets and infrastructure.

</comment></comment></comment><comment><USER5> So much amazing innovation is driven from the valley but in this case it's Kenya showing us the way. Why is that? Worth thinking about.

<comment><USER6> Because these are sectors not fully developed there. The existing institutions here are hard to topple. But their equivalents perhaps don't fully exist there, so there is a gap to fill.</comment></comment>


Epoh - <AUTHOR> https://epoh.me <comment><USER2> Sorry, you're too spammy:

[https://hn.algolia.com/?query=epoh&sort=byPopularity&prefix&...](https://hn.algolia.com/?query=epoh&sort=byPopularity&prefix&page=0&dateRange=all&type=story)

<comment><AUTHOR> Sorry! I won't post anymore and I would've delete the old ones if I could!

<comment><USER3> Don't delete the older post. Deleting a post and resubmitting will get you banned.

Only delete old post when it was a mistake. For example a broken URL, a wrong URL, or something you submitted by mistake.

<comment><AUTHOR> Oh okay, I will try to keep everything within the rules from now on!

</comment></comment></comment></comment><comment><USER4> The busy and creepy artwork at the bottom of the page isn't doing you any favors - do you have the rights to it?

The text on the landing page is also maddeningly vague. It could describe almost every social media startup in existence, and all of the text tends to be obscured by the background art for me. Other than that, the site seems decently well designed.

The "explore" link doesn't really flow with the look of the rest of the page and it seems too easy to ignore.

Also: _Share your thought 's with the rest of the world!_ <\-- remove the apostrophe here.

<comment><AUTHOR> Hi krapp,

Thanks for the feedback really appreciate it!

1\. No, I don't I will remove it and just leave a background color instead. Thanks for pointing it out.

2\. I will try to change text from the landing page to something more unique, you mean both images on just the one you mentioned on your first point? And thanks.

3\. Ok, I will try to make it stand out more.

4\. Ok, thanks!

I will apply those changes today and if you're kind enough again to let me know what you think of those changes would mean a lot to me.</comment></comment>


Why do we ignore 'real-time' results from Google search? - <AUTHOR> http://www.guardian.co.uk/technology/blog/2010/mar/09/google-eye-tracking-twitter-real-time-search <comment><USER2> For the fairly obvious reason that tweets and the like are virtually content- free. Anything they have to say about a subject you're searching for, you already know. It's like doing a keyword search to find keywords.</comment>


Hadoop, Analytical Software, Finds Uses Beyond Search  - <AUTHOR> http://www.nytimes.com/2009/03/17/technology/business-computing/17cloud.html <comment><USER2> One of my buddies just started working for them. Cloudera is a real braintrust.

</comment><comment><USER3> It's good to see hadoop getting some press attention, it certainly deserves it.</comment>


Fog Creek Compensation - <AUTHOR> http://joelonsoftware.com/articles/fog0000000038.html <comment><USER2> [http://www.hnsearch.com/search#request/all&q=fog+creek+c...](http://www.hnsearch.com/search#request/all&q=fog+creek+compensation)

</comment><comment><USER3> It is interesting to note that they require salary history to determine new employee's level which people on HN tend to not like.

<comment><USER4> Perhaps they dislike it because it's bullshit! How is my value to a company determined by how much I get paid historically?

</comment></comment><comment><USER5> pffh. transparency. who woulda thunk? but in seriousness, liking it. wish they'd do this at my place of employment.

</comment><comment><USER6> So. What would be the salary at level 12?</comment>


How India Pierced Facebook's Free Internet Program - <AUTHOR> https://backchannel.com/how-india-pierced-facebook-s-free-internet-program-6ae3f9ffd1b4#.zdbdcxeq7 <comment><AUTHOR> TL;DR: Facebook's been pushing for its Free Basics program in India, but due to net neutrality concerns (people would have to pay for Internet beyond the Free Basics offerings), Indian regulators are expected to ban Free Basics in a decision next week ([http://timesofindia.indiatimes.com/tech/tech-news/Trai- set-t...](http://timesofindia.indiatimes.com/tech/tech-news/Trai-set-to- reject-differential-pricing-Free-Basics-to-be-hit/articleshow/50779572.cms)).</comment>


Stopping olive oil fraud with the help of blockchain - <AUTHOR> https://cordis.europa.eu/article/id/415454-stopping-olive-oil-fraud-with-the-help-of-blockchain <comment><USER2> You're better off buying olive oil with the most minimal supply chain possible. That means, for example, if you live in the US, buying olive oil with olives made in California. Cross-border supply chains are challenging to validate.

</comment><comment><USER3> Who secures this blockchain? How much hashing power do they have? Wait... why did you even need a blockchain?</comment>


Ask HN: How do you scale your web app? - <AUTHOR>

What methods and Techniques do you guys use to scale your web applications? What languages do you find are most scalable? <comment><USER2> I recommend these two books:

\- Scalability Rules: 50 Principles for Scaling Web Sites by Martin L. Abbott & Michael T. Fisher

\- Building Scalable Web Sites: Building, Scaling, and Optimizing the Next Generation of Web Applications [Paperback] by Cal Henderson

I think they are the best resources I have found about the topic. If you are using .Net, like me this is book has good tips as well:

\- Ultra-Fast ASP.NET: Build Ultra-Fast and Ultra-Scalable web sites using ASP.NET and SQL Server by Richard Kiessig

</comment><comment><USER3> I don't think it has much to do with languadge, it is true some languages run slower than others, but these days almost all the languages have a variant that run in one of the VM's which most would agree are scalable.

To me scalability is all about architecture, and the #1 item that you can do to architect a scalable system is statelessness.

</comment><comment><USER4> I use PHP, 350KB total of PHP+HTML code, you can have a look, I dont know how to post urls <http://www.whatsthesequency.com/cookie.php>

</comment><comment><USER5> I run my ruby apps (sinatra and rails) on heroku and scale with a couple mouse clicks.

You can also run a ton of other languages on heroku now too.

</comment><comment><USER6> this website has some GREAT content: <http://highscalability.com/>

Many articles focus on bigger, high-profile companies with unique challenges but there are tons of great articles and tips on scaling normal web apps. Check the archives.</comment>


Introduction to Svelte - <AUTHOR> https://daveceddia.com/svelte-intro/ <comment><USER2> For those confused about the "29 MB": that's the size of the compiler itself.

A compiled Svelte app is _tiny_. Taking the TodoMVC demo app as an example:

React [1] : 289 KiB over the wire (decompresses to 1,255 KiB)

Svelte [2] : 28 KiB over the wire (decompresses to 41 KiB)

\---

[1] [http://todomvc.com/examples/react/](http://todomvc.com/examples/react/)

[2] [https://github.com/sveltejs/svelte- todomvc](https://github.com/sveltejs/svelte-todomvc)

<comment><USER3> FWIW, that React demo should not be used as a network perf comparison in any way:

\- It's using an ancient version of React (0.13.3)

\- It's a debug build of "React with addons", not a minified prod build

\- It appears to include `JSXTransformer.js` as a separate script to handle in-browser JSX compilation

If you were to redo this using a modern version of React and a standard CRA build, I guarantee it would be _much_ smaller.

 _edit_

Just for kicks, I did a quick search and dug up a pre-existing React "TodoMVC" app based on CRA ( [https://github.com/ChrisWiles/React- todoMVC](https://github.com/ChrisWiles/React-todoMVC) ). It's 3 years old, but it was trivial to bump the requirements up to the latest versions of React and react-scripts.

From there, running `yarn build` says that:

        File sizes after gzip:

          39.22 KB  build\static\js\2.3ec0f98b.chunk.js
          2.14 KB   build\static\js\main.4514f0a8.chunk.js
          1.73 KB   build\static\css\2.bc2ff3bb.chunk.css
          782 B     build\static\js\runtime~main.0ff4d30b.js

The actual sizes on disk are:

        2.3ec0f98b.chunk.js : 128435b
        main.4514f0a8.chunk.js: 7259b
        2.bc2ff3bb.chunk.css: 5423b
        runtime~main.0ff4d30b.js: 1577b

So yeah, Svelte is certainly going to result in much smaller bundles than a React app, but you have to use a legitimate fair production comparison.

<comment><USER4> Looks like Preact comes in at 6K (compresses to 4.7K). That's pretty interesting when you realize that Preact generally about as fast or faster than Svelte in a lot of benchmarks.

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

[https://medium.com/@ajmeyghani/javascript-frameworks- perform...](https://medium.com/@ajmeyghani/javascript-frameworks-performance- comparison-c566d19ab65b)

That said, I don't know that 6K vs 40K is particularly significant. For small apps, it disappears into the noise compared to ads, images, video, trackers, etc. For large apps, the framework starts to make less and less of a total percentage of the total app and often slides into insignificance on that side as well.

</comment></comment></comment><comment><USER5> This looks nice. I'm not a framework guy (more on that in a second) but they at least seem to be heading in the direction of letting me get work done without forcing me to do it their way.

That said; first it was Backbone which wasn't terrible but kinda clunky in my opinion. But then Angular came along and everybody rushed over to that pasture. But then React came along and everybody rushed over to that pasture. Now Vue is appearing to be greener than the others. Is Svelte where everyone will go next?

My point is this: if all these frameworks were so great, why do we keep running to the latest new one? I actually heard a contractor say the other day, "five years ago everybody wanted Ember developers and now everybody wants React developers. I even have those old Ember clients coming back asking for developers to rewrite the Ember projects in React."

Maybe it really is turtles all the way down...

<comment><USER6> tl;dr watch this fantastic intro to svelte talk by it's creator: [https://www.youtube.com/watch?v=AdNJ3fydeao](https://www.youtube.com/watch?v=AdNJ3fydeao) , it covers some of the growing pains of React that svelte addresses.

While it might _look_ like the frontend is going around in circles, there are major & minor differences between the technologies, and they have each introduced novel (to JS at least) things... Off the top of my head (this timeline might not be right but it's how I went through it at least):

\- Backbone got you away from jquery spaghetti, helped you actually manage your data & models. Often paired with Marionette to handle views (if you squint this is the precursor to components) and bring some order in that part of the app.

\- Angular bundles backbone's data handling (services), marionette's orderly view separation (views, directives), but they made a fatal mistake in the apply/digest cycle and maybe encouraging a bit too much complexity. Angular is _everything_ bundled together, with consistent usage/documentation/semantics, a familiar programming pattern (MVC), and a large corporate sponsor in Google it caught on like wildfire.

\- Knockout sees Angular's MVC, laments it's complexity and focuses on MVVM -- simple binding of a model and a relatively simple reactive-where-necessary controller

\- React comes along and suggests an even simpler world where the _only_ first class citizen is components and everything else comes separate (this isn't necessarily new, there is an article out there comparing it to COM subsystems for windows). React is almost always used with react-router and some flux- pattern supporting data management lib -- these are also departures from how angular, backbone and knockout structured in-application communication (backbone was pure event bus, angular had the usual MVC methods, knockout was just callbacks -- if you have a handle to an observable when you change it things reload).

\- Vue sees the complexity that React grew to (case in point: shouldComponentUpdate) and devises a much simpler subset along with a new way to handle reactivity -- using the `data` method of a vue component. Vue made a _lot_ of decisions that helped it stay simple and small yet very productive and this is in large part thanks to React existing before hand.

\- Svelte comes on the scene and realizes that truly optimal rendering could be achieved by just _compiling away_ the excess and eschewing the virtual dom all together in most cases. No need to track all the structure if you compile the code with the updates necessary. Don't quote me on this but I think a whole host of things influenced this project -- smarter compilers, better type systems, the ideas around zero cost abstractions & doing more work at build time.

\- Ember (formerly SproutCore) is actually an anomaly because it tries it's best to be both angular like (so large, and usable by large teams) _and_ keeping up with the tech as it evolves (see: Glimmer, Octane). Ember also has some innovations, like Glimmer's VM-based approach -- turns out you can just ship binary data representing how to draw your components to the browser and skip a bunch of JS parsing, if you bring your own virtual machine that is optimized to draw the components.

As all this moves forward, there are ecosystem pieces like typescript that have gained tons of steam and changed how people are writing JS code these days.

<comment><USER5> This is literally the first time anyone has ever put together a cogent argument for why the framework du jour exists. Thank you!

I still personally feel like I can usually get more done with pure Javascript but, as I said in my original post, at least they appear to be headed in a better direction. I did a project in Vue last year and it didn't entirely suck. Unlike the nightmare that was an Angular project I did two years ago.

<comment><USER7> In an earlier comment, you said you weren't a "framework guy".

If you were you would have heard this cogent argument dozens of times already as it's fairly common knowledge to people who are into frameworks.

Consider trying to understand why frameworks are created before using them. Understanding the motivations behind a framework will help you navigate the api easily and could change your opinion about whatever frustrates you.

<comment><USER6> I'd also consider myself not a "framework guy" \-- Spring is not my favorite, I pick flask/sinatra over rails/django, servant over yesod, vue + vue-router over ember (these days) etc.

Maybe the distinction is that it really matters _which_ framework, and how it's put together, and how much you have to commit to use any of it.

I think the commenter's question was really more about the diaspora of these tools and why they all exist -- svelte is pretty decidedly _not_ a framework (in fact I don't even think you can make it one, AFAIK there isn't like a "svelte data"). IMO the only full blown frontend frameworks are Ember, Angular and react/vue + react/vue-router + flux-y pattern data store.

</comment></comment></comment></comment></comment><comment><USER8> I've been building something with Svelte 3 for about 6 months now.

\- As should be clear in the article, it's _very_ easy to pick up. In the first couple of weeks I got compiler errors, and kept having to look at how props and binding worked in the tutorial, but now I just make components without having to really think about Svelte.

\- TS support is on the way (yaay)

\- I'd like to know more about server-side rendering on Lambda - ie, Sapper currently wants to use something persistent like Express, but that really shouldn't be necessary.

<comment><USER9> Sapper can generate static html for lambda or anything else i f you run `npm run export`.

In fact the ideal way to use Sapper is without express/polka.

<comment><USER8> Hah brill. It might just be the tutorials, which seem focused on using express or something with express-like middleware. I'll do some further investigation. Thanks.

</comment></comment></comment><comment><USER10> I loved Svelte a few years back and still think it's a nice framework with cool ideas. However, a big issue for me using it at a company is that testing (especially unit testing) seems to be an afterthought. This has made it a non- starter for using it with multiple teams working on same code base. Maybe it's changed with Svelte 3 but a library I wrote for it wasn't clear how to test.

(Edit sounds same: [https://github.com/sveltejs/svelte/wiki/FAQ#how-do-i-do- test...](https://github.com/sveltejs/svelte/wiki/FAQ#how-do-i-do-testing- svelte-apps))

JS libraries sometimes take a non-presciptive approach of "test however you want!", But roll your own testing for a UI framework really limits adoption and enthusiasm at larger companies.

<comment><USER11> Is there any UI framework where testing isn't an afterthought?

<comment><USER10> React at least had ReactTestUtils 'officially' and then recommended ReactTestingLibrary & Enzyme as the ecosystem matured: [https://reactjs.org/docs/test-utils.html](https://reactjs.org/docs/test- utils.html)

</comment></comment></comment><comment><USER12> This looks much more germane to the Web than the other frameworks du jour. Will be interesting to see how it develops, but this was a pretty interesting look at how it works.

<comment><USER8> Ins't /Svelte/ the framework du jour? :)

<comment><USER13> Doesn't du jour imply that it's the go-to framework of the day? Surely, that would be React :-)

<comment><USER8> JQuery was a completely different way of looking at things with a huge advantage. It got popular and became the go-to tool of the day.

Backbone and Angular were a completely different way of looking at things with a huge advantage. They got popular and became the go-to tool of the day.

React was a completely different way of looking at things with a huge advantage. It got popular and became the go-to tool of the day.

Svelte is a completely different way of looking at things with a huge advantage.

</comment></comment></comment></comment><comment><USER14> I like reading scientific papers and most examples sections provide rich and intricate outlines of real-life use-cases where the idea can be experimented against. These examples usually involve quite complicated scenarios that "put the idea to the test".

One that I recently read involved a solution to the "Challenge Problem" [1] (simulating the movement of a rover) which involves lots of interesting properties and allows one's idea or framework (or whatever) to really battle test the grounds with reality.

On the web however it's different... we're somehow stuck with todo-lists.

1\. [https://mdetools.github.io/mdetools18/challengeproblem.html](https://mdetools.github.io/mdetools18/challengeproblem.html)

<comment><USER15> Todo apps are used as front-end examples for the same reason the factorial function is used to explain recursion: it's simple, it's intuitive, but it exercises what you need without dragging in a lot of incidental complexity.

To demo or teach a front-end framework, you need to show:

1\. How data gets rendered to the DOM

2\. How collections are handled

3\. How events are registered and handled

4\. How the DOM is updated when data are changed

5\. How form inputs are represented

The easiest thing to do is to show an array getting rendered as a list, then add click handlers which change the list somehow, which naturally segues into showing how the DOM is changed. Adding new items or deleting items also answer important questions about how exactly collections of data are mapped to collections of elements and how updates are happened. Finally, no demo of a front-end framework can be considered complete unless it addresses how form input elements work; adding functionality to add a new item or update the text of an existing item is an obvious way to demonstrate this.

<comment><USER14> I disagree. Those things are already available in pure library-less and framework-less code. What frameworks should provide is a solution at scale (i) as complexity increases, (ii) whether code is more maintainable or not and (iii) also I guess how easy it is to "fix" as bugs are discovered.

A todo-list gives you pretty much 0 insight into almost any of these facets. Let's be honest here, it's a "hello world" cheap demo to quickly showcase: "here's how my new framework works" and you can quickly understand it.

But you have no way of understanding whether those framework decisions actually work at scale. More complex examples are a good thing, not a bad thing :)

</comment></comment></comment><comment><USER16> The article says that

        items = items.filter(i => i !== item);

is compiled to

        $$invalidate('items', items = items.filter(i => i !== item));

So this invalidates the whole array, right? Would this then re-render the whole array, i.e., remove and recreate all DOM nodes? And if so, does Svelte support more fine-grained ways to update arrays?

<comment><USER4> The TL;DR is that Svelte overpromises. They can't possibly write code for every transformation combination as code size would grow exponentially (I'm not completely sure, but I think predicting transforms would involve the halting problem).

(thanks to whoever bothered to do this writeup).

[https://github.com/gactjs/gact/blob/master/docs/long-live- th...](https://github.com/gactjs/gact/blob/master/docs/long-live-the-virtual- dom.md)

EDIT: if anyone has proof this is not true, I'd love to hear their counterargument.

<comment><USER17> Svelte author here. That post overlooks a number of important points; I've responded here [https://www.reddit.com/r/javascript/comments/ckpdxk/long_liv...](https://www.reddit.com/r/javascript/comments/ckpdxk/long_live_the_virtual_dom/evq8g2k/)

<comment><USER4> React is _very_ far from the fastest vdom. It notably suffers from needing to work with non-DOM back-ends where a particular heuristic that is good in the DOM may either be useless or (worse) actively degrade performance. Preact, Snabbdom, or Inferno would probably be better points of comparison to Svelte's approach as they are much more optimized for the web.

DOM nodes can actually be recycled relatively easily. Cache the nodes by type then by class. Most recycled nodes would be a 100% match based on those two alone. If type and class match, then you have a super-high probability of dealing with old nodes for the same object, so few modifications are required. Most nodes without classes tend to have no attributes changed (<div>, <p>, etc) so they will match as well. Store those nodes with their vdom attached and you will have a record of what has been modified so patching is fast.

This optimization exists in some vdom implementations and would make the case in question much faster. There also seems to be an implication that the diffing algorithm will bloat. If you look at React, the diffing algorithm is a very small part of the codebase.

This is hardly just an academic optimization though. It is _the_ key to reducing overhead on long lists. With long lists of complex objects, you cannot rely on patching text values because there will undoubtedly be actual DOM differences. Rather than dooming the entire list to poor performance, you can recycle those nodes and retain most of the performance of a flyweight scroller where nodes are all identical.

[https://developers.google.com/web/updates/2016/07/infinite-s...](https://developers.google.com/web/updates/2016/07/infinite- scroller)

<comment><USER18> Either I have completely misunderstood you or you are simply wrong. It looks like you are implying that vdom is magical solution to long lists and svelte should have problem here. While in real world we have this: [https://svelte.dev/repl/f78ddd84a1a540a9a40512df39ef751b?ver...](https://svelte.dev/repl/f78ddd84a1a540a9a40512df39ef751b?version=3.8.1)

<comment><USER4> Like most other scrollers, the svelte one tries to only show the elements on screen plus a couple above and below to keep up the illusion. The Google article makes it very clear that top performance requires re-using DOM nodes.

In that very simplistic example, there are only 4 nodes to each list, so creating and destroying them doesn't matter. I have a scroller in a business app where each item has a few hundred DOM nodes. Create and destroy them constantly and you'll definitely notice on a desktop and performance will crawl on a mobile device.

Instead, you want to save those DOM nodes in a cache and re-use them. In order to do this though, you must know what parts are default and what parts have been modified by their previous user. A vdom does this automatically, but the cost for Svelte to calculate which of the hundreds of properties have changed is too big, so they just throw it away and make another.

An even better optimization would be where each list item has the same node structure and only text or images change. I believe Svelte can handle this case. Unfortunately a lot of lists are slightly irregular in real-world applications. I work with these kinds of lists a lot and a vdom keeps it smoother than all the other libraries we've looked at.

<comment><USER18> I don't see what stops you adding caching in Svelte for virtual lists.

<comment><USER4> Imagine you add a few attributes, some properties, and a couple event listeners to a node. In order to reuse the node, you have to reset it to factory settings.

How would Svelte know what things had been changed when looking at a node saved in a cache?

If it has to check every property, the cost to check will exceed the cost to create new. If it saves a list of changes, it's essentially created a vdom anyway.

<comment><USER18> Thank you for explaining that to me. It is good to know what technology to use if I will meet this specific case. So far all projects I have worked on can be implemented both with React and Svelte :)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> > Another nice thing: the node_modules folder for this Hello World Svelte app > totals only 29MB and 242 packages

"Only".

<comment><USER8> That's the compiler, not the output of the compiler.

Likewise GCC/LLVM is huge, but helloworld.bin is pretty small.

<comment><USER20> How big is the source code size of GCC/LLVM? I mean node_modules often contains the full source + dist of the whole dependency chain.

<comment><USER21> The source-controlled (and somewhat out of date) folder for LLVM is about a gigabyte on my machine.

</comment></comment></comment></comment><comment><USER5> "Another nice thing: the node_modules folder for this Hello World Svelte app totals only 29MB and 242 packages."

How is it nice that you have almost 30MB of code for something that prints "Hello World"?

EDIT: For what it's worth, I don't fault Svelte for this necessarily. This is indicative of NPM bloat which is becoming rampant in my opinion.

<comment><USER22> To be fair, the Svelte bundle.js that you would actually serve to a browser is only 2.3kb. The 25mb is what the dev's computer has to store in its node_modules.

"Another nice thing: the node_modules folder for this Hello World Svelte app totals only 29MB and 242 packages. Compare that to 204MB and 1017 packages for a fresh Create React App project."

<comment><USER5> A somewhat apples-to-oranges comparison I know but; 277B:

        <!DOCTYPE html>
        <html lang="en">
        <head>
            <title>Test</title>
        </head>
        <body>
            <div id="howdy"></div>
            <script type="text/javascript">
            document.addEventListener('DOMContentLoaded', () => document.getElementById('howdy').innerHTML = 'Hello world!')
            </script>
        </body>
        </html>

<comment><USER23> Omitting html, head, and body tags is allowed by HTML specs, and the script tag's default type is "text/javascript". So it could be further simplified to:

      <title>Test</title>
      <div id="howdy"></div>
      <script>
      document.addEventListener('DOMContentLoaded',
        () => document.getElementById('howdy').innerHTML = 'Hello world!'
      )
      </script>

Edit: formatting

</comment></comment></comment></comment><comment><USER24> We need someone to take Svelte on a test drive for something more complex than a to-do list. I'm assuming the results will be favorable to svelte, but please blog _after_ said exercise. The un-ending list of blogs and tutorials on to-do lists with svelte are certainly plentiful, repetitive, and not particularly convincing

<comment><USER25> FYI I've selected Svelte for an enterprise project and after using it for some time, it seems to have some pretty big issues. I would honestly call the current release a beta version.

In particular, there is a _lot_ of flakiness with reactivity and because reactive things are magical in Svelte, it's very hard to diagnose and correct such issues. Reactive code becomes spaghetti fairly quickly once you start adding logic to prevent it breaking.

Those neat out-of-the-box transitions completely break unmounting/remounting as would be the case with, say, changing "pages" (using a router). If there's any transition still going on, the unmount will fail and yet the replacement component will be mounted, resulting in a frankenpage.

It's also maybe _too_ declarative in the sense that certain things that are easy to do imperatively require you to coerce Svelte to achieve them. You sometimes find yourself deliberately trying to fool Svelte into doing an update.

__

But do I regret choosing it? Not really. All frameworks have flaws. IMHO: Angular is a convoluted spaghetti of nonstandardness, React has its head on backwards with JSX, Vue has too many quirks... I'm partial to riot.js which has just been updated to v4, but I have yet to try the latest version.

</comment></comment><comment><USER26> Mark Volkmann gave a great talk on Svelte[0].

[0]: [https://www.youtube.com/watch?v=4_PTdJq-1rA](https://www.youtube.com/watch?v=4_PTdJq-1rA)

</comment><comment><USER27> Doesn't work with Browserify. Please someone make it work with Browserify!</comment>


Fossil Discoveries Challenge Ideas About Earth's Start - <AUTHOR> https://www.quantamagazine.org/fossil-discoveries-challenge-ideas-about-earths-start-20180122/ <comment><USER2> Even if there was heavy bombardment, it wouldn't be everywhere at once, and deep sea vents would be somewhat protected by kilometers of water. (assuming the bombardment wasn't so severe as to vapourise the ocean).

That life was present as soon as earth was hospitable fits with the intriguing theory that extrapolates the origin of life to _predate_ earth, based on the rate of increase in complexity: [http://www.davidyerle.com/where-are-the- aliens/](http://www.davidyerle.com/where-are-the-aliens/) (actual article pdf 287kb: [https://arxiv.org/pdf/1304.3381](https://arxiv.org/pdf/1304.3381))

<comment><USER3> Umm... that's a pretty remarkable finding... how is this the first time I'm hearing about this? Is their evidence considered too weak or speculative to challenge the currently accepted timeline? I thought we had this whole evolution thing (mostly) figured out...

<comment><AUTHOR> Panspermia as a theory has been around for a while, but there's no real evidence to support it yet. The weaker forms of the theory don't postulste life as being extraterrestrial, but the complex organic building blocks of life could be.

Until a rigorous model of life can be developed, until life can be created in vitro from non-living stuff, or until evidence of life or complex organics can be found beyond Earth it's hard to prove or disprove.

The same can be said of pretty much all theories concerning the origin of life on Earth though.

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

</comment></comment></comment><comment><USER4> The ending of Clarke's Light of Other Days involves a motif that's common to his work - a civilisation of small, chitinous creatures that existed prior to the accepted cooling-and-then-life-arises theory. How awesome would it be if it turned out to be right.

<comment><USER5> I'm a big fan of ACC, but the "common motif" doesn't ring a bell. Could you provide more examples where this occurs in his work?

</comment></comment><comment><USER6> Not to say that's what happened, but I wonder how far we are from being able to seed a planet with life? and what it would cost?

<comment><USER7> A better question might be "should we?" Consider that we as a species seem incapable of taking care of ourselves on our own planet. Unless that changes, it seems pretty irresponsible. We would be like the dad that skipped town.

<comment><USER8> We wouldn't have to take care of it. Could just seed and let life do its thing.

But to me the real "should we?" is because it might destroy evidence of other events. Maybe there are simple organisms hiding somewhere or some poorly understood phenomenon that would be obscured or destroyed by our introduction of life.

<comment><AUTHOR> I'd tend to agree, from a sort of "Prime Directive" direction. We're not so good at guessing really global, long term consequences in unfamiliar systems. We would have to be so sure before introducing life on a distant world. What if there was already very simple life just getting started? We could reduce universal biodiversity with the best of intentions.</comment></comment></comment></comment>


Amazon FPS out of beta - adds limited-time free payment processing (90 days) - <AUTHOR> http://aws.typepad.com/aws/2009/02/great-news-from.html

<comment><USER2> # 1.5% + $0.01 for Amazon Payments balance transfers.

# 2.0% + $0.05 for bank account debits.

# 2.9% + $0.30 for credit card for transactions above $10

# 5%+$0.05 for credit card for transactions below $10.

<comment><USER3> Note: This fee schedule is for payments by US customers only. You can allow non-US customers to pay using credit cards (not Amazon Payments balance transfers or bank account at this time) for an additional charge of 1% of the transaction amount. All transactions are in US dollars.

</comment></comment><comment><USER4> Question - is there anything _other than PayFlow Pro_ that allows checkout to happen on my site? FPS, Google Checkout, PayPal proper all have checkout on _their_ sites as far as I can tell.

<comment><USER5> As a consumer, I'd rather have the checkout complete on Amazon.com than on your site. First, Amazon.com has all my payment information already. Secondly, I trust Amazon.com more than I trust your site. I may be willing to give you a small amount of money, but I'm not willing to give you unlimited access to my credit card.

<comment><USER6> I think that's true for B2C, but if you sell to businesses, they probably don't have an Amazon account with their business CC on record. It also looks more "professional" to have the whole payment process contained in your site.

</comment></comment></comment><comment><USER7> So you're saying Amazon FPS isn't a game where you walk through the halls of a virtual bookstore fragging bad authors with your BFG?

Well, this looks kinda cool too, I guess.

<comment><USER8> "First person shooter"

</comment></comment><comment><USER9> I had to dig, but I'm pretty sure you _can't_ deposit into your Amazon Payments account with an Amazon Gift Card. This is a bummer -- I feel like Amazon could have a real advantage over Google and PayPal with essentially the ability to deposit with cash.

</comment><comment><USER3> Amazon FPS registration is available for all developers with a U.S. address.</comment>


The strange link between the human mind and quantum physics - happy-go-lucky http://www.bbc.com/earth/story/20170215-the-strange-link-between-the-human-mind-and-quantum-physics <comment><AUTHOR> I can't believe how many words BBC dedicated to a non-scientific idea which has absolutely zero experimental support.</comment>


Launch HN: Substack (YC W18): Paid email newsletters made simple - <AUTHOR> Hi HN, we're Chris Best and Hamish McKenzie, the founders of Substack (https://www.substack.com). We've built a tool that makes it simple for a writer to start a paid email newsletter. Sign up, connect to Stripe, and go. Our first publisher, Bill Bishop, writes a newsletter about China (https://nb.sinocism.com) and got to six figures of annual revenue on his first day on Substack. Bill had been publishing Sinocism as a free newsletter for five years and had 30k subscribers. Now he can make a living from it.
Hamish is a journalist who has done everything from writing about indie music in Hong Kong to being lead writer for Tesla. We bonded over our shared love of reading when he worked at Kik, where Chris was the technical co-founder. Last summer, Chris was taking time off and asked Hamish to read an essay he was trying to write about the incentive structures of social media for writers, and how growing outrage and polarization was making it hard to have reasonable conversations. At the same time, we both loved Ben Thompson's newsletter, Stratechery, which was doing really well off paid subscriptions. We wondered: what if it were easier for writers to start something like that? That felt more like a company than an essay, and so one thing led to another...
An example of a Substack newsletter you might enjoy is Versioning (https://versioning.substack.com), a daily reading list for web developers and designers. We also recommend Mallory Ortberg's The Shatner Chatner (https://www.shatnerchatner.com) and Helena Fitzgerald's Griefbacon (https://griefbacon.substack.com).
The product is still in a pretty early phase but we've just launched our self-serve beta, where anyone can create a newsletter, free or paid: https://www.substack.com/beta-signup. At this stage, it's completely free until you start charging, in which case we take a fee: 10% for people who start during the beta.
We know a lot of folks on HN care about this stuff too, so we're keen to hear your feedback. Also: if you know any writers you'd be happy to pay to read (or if that's you), we'd love to hear about that too. <comment><USER2> Very cool idea Chris & Hamish A friend of mine runs "what happened last week?" ([http://whathappenedlastweek.com/](http://whathappenedlastweek.com/)). She's got a journalism and economics background, and has a subscriber list of about 2,800 people, but has been struggling to find a way to monetize it. Would something like that be a good fit for your platform?

<comment><AUTHOR> Oh awesome! I see

> Stay well-informed about the world each week with clear and concise > summaries of important news ...

That sounds like an exactly perfect fit for Substack. We've seen that if you have a committed newsletter following (look at open rates and reader comments) that loves it, up to 10% of your list might pay pretty quickly if you just asked them. Depending how they think they could price it could be worth over $1000 month to start. Of course, this depends on the audience etc.

If they want to do it, it's a simple as signing up, connecting Stripe, and importing the existing list. They can send out a 'free' post saying that the newsletter is going paid, and it will go to that list, and come baked with calls to action to subscribe and stuff.

We've done a couple of these now and would be happy to help. Feel free to point them to 'chris' or 'hamish' at substack.com

<comment><USER3> >That sounds like an exactly perfect fit for Substack. We've seen that if you have a committed newsletter following (look at open rates and reader comments)

It would be good if you could put a list of supported features on the signup page. As of now I do not see it. Will let signuppers know what they will get.

I am going to sign up and try it anyway.

<comment><AUTHOR> Thanks, that's good feedback. And glad you're signing up!

We'll continue to make it better as quickly as we can.

</comment></comment></comment></comment><comment><USER4> You should come on Indie Hackers and do an interview in a few months. I'm constantly telling friends to start newsletters. Would love to see how this works out and learn the details behind the scenes wrt to marketing and growth.

<comment><AUTHOR> Oh we would love that!

</comment></comment><comment><USER5> > in which case we take a fee: 10% for people who start during the beta.

Why take a cut from the publisher? Why not instead open up access to the publishers via a marketplace on your site so people/companies can sponsor the mailing lists? You can take a cut from the sponsor for having given the opportunity to introduce them to publisher(s) that cater to their market. It's a win-win-win for the potential sponsors(advertisers), the publishers as well as Substack. As a sponsor, I would have immediate market access through these publishers who cater to my niche. As a publisher, I would have outsourced the task of attracting sponsors and managing sponsor timelines to Substack so I can focus more on creating content and expanding my mailing list. As Substack, you wouldn't have to annoy your publishers by taking a cut and instead carry over your fee to be paid by sponsors/advertisers. A bonus would be allowing your publishers to carry over their existing sponsors to use your system which would possibly attract a huge populace of publishers who are currently manually micro-managing their existing sponsors and timelines instead of focusing on creating content.

<comment><USER6> Hey, this is Hamish from Substack. Thanks for this! We think this is a great idea and it's certainly something we're considering for the future. But in the meantime, the point of a 10% cut is that it specifically does not annoy publishers. In fact, it aligns our incentives with theirs – we only make money when they make money. When we established Substack, we wanted to get away from an ad model in which publishers had reason to favor ad-centric content strategies over reader-centric ones. We're attempting to create an environment where writers no longer have to worry about doing things that please advertisers. They should be focused only on doing things that please their readers. To us, that's a better way forward for the media. Taking a 10% cut is a substantial ask, but it is one that writers have so far been receptive to.

<comment><USER5> Ah sorry! Yes you are right! Now that I re-read your text, I realized I misunderstood your business model. Maybe my suggestion sits well with those who are running free newsletters on Substack (who will have some form of regular income through sponsors). I notice that you are taking a fee from those who are running paid newsletters. That makes complete sense.

<comment><USER6> Thanks, much appreciated. Yes, free newsletters don't have any charges. No subscriber limits, either.

<comment><USER7> Do you have a "Powered by Substack" somewhere in your free/paid newsletters?

Our product is also exposed to our customers' customers, so this has been a huge growth driver for us. Similar story for Statuspage, Intercom, etc.

<comment><USER6> Just as a link in the footer. Substack is also in the domain name, though. Thanks for the advice!

<comment><USER8> So every newsletter is sent through the same domain? Aren't you afraid of one newsletter affecting the reputación of another one?

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> This is the future: [https://stratechery.com/2017/the-faceless- publisher/](https://stratechery.com/2017/the-faceless-publisher/)

<comment><AUTHOR> Thanks, love this. We think Ben Thompson is right about a lot of stuff, and he is definitely a big inspiration.

</comment></comment><comment><USER10> How easy is it to export your subscribers if you do choose to leave? I have a few hundred people on my list and have learned (the hard way)to not migrate without knowing this

<comment><USER11> The _actual_ hard part when switching from something like this is migrating user accounts (users will be forced to reset their passwords, which is lame), order history, and active subscriptions so that you can seamlessly continue billing your paying users.

And at 10%, you're definitely going to want to migrate at some point if you succeed, so keep this in mind.

</comment></comment><comment><USER3> Consider connecting Substack to other payment providers too, if not now, after you get to some sales and profitability, since Stripe is only available in some countries as of now. This is a common and perennial issue with many startups, whether US-based or other. I'm aware that it can be a lot of work, due to different and complex government regulations and legal paperwork needed for different countries, but it can lead to growth of the startup too.

<comment><USER12> Second this. While I love Stripe's API, Braintree/Paypal driven checkouts have higher conversions just because of Paypal.

</comment></comment><comment><USER13> Would have liked to see a "gallery" of writing that I can subscribe to. Sort of like how ecommerce platforms have a list of stores that were built on this platform.

On a side note, I like how you have written the body of this post. Not to mention a very useful product.

<comment><USER6> Thank you very much. Yes, good suggestion. We are thinking about how to do something like this. Any ideas?

</comment></comment><comment><USER14> I think subdomain user accounts are going to be an issue over the long term.

<comment><USER14> Also, you guys should make a better blacklist for account names. I was able to claim "blog.substack.com". (It's ok to delete that account).

[https://github.com/marteinn/The-Big-Username- Blacklist](https://github.com/marteinn/The-Big-Username-Blacklist)

<comment><AUTHOR> Ahh thanks. I hope you don't mind if we boot that one.

How do you foresee sub domains being a problem otherwise?

<comment><USER14> SEO will see each account as a separate domain, so your primary site ranking will be low. Further, there's too many ways for user subdomains to be mistaken or conflict with company products and promotions. It's usually best to reserve subdomains for company needs — you never know what you'll need 5-10 years from now.

<comment><USER15> It's also a potential cross-domain attack vector if you let your users insert arbitrary code. See, for example, why github pages was switched from `.com` to `.io`: [https://github.com/blog/1452-new-github-pages-domain- github-...](https://github.com/blog/1452-new-github-pages-domain-github-io)

<comment><AUTHOR> All really good points. Thanks for the feedback.

</comment></comment></comment></comment></comment></comment><comment><USER16> Looks great! I just signed up and connected my stripe account. After reading the welcome email I tried disconnecting my stripe account from the dashboard so I could start out with a free newsletter. I couldn't figure out how to do it so I ended up revoking access in my stripe dashboard. Now it just says Stripe account: <loading..> on my substack dashboard.

I'd like to start writing but I want to be sure that I can connect my stripe account again in the future. Any ideas?

<comment><AUTHOR> Ahh that's a really good point. You may be the first to disconnect Stripe. I will make sure this works.

Email me your account details if you'd like. Chris at Substack dot com

</comment></comment><comment><USER17> I really like the simplicity of this. I think it doesn't really need more "killer" features. What's the vision in the long run aside from growth?

<comment><AUTHOR> Thanks! We've had (paying, highly engaged) users report that they like there is nothing to think about.

One thing in future that's really exciting to us is the idea of building community, and using the paid barrier as a way to solve a whole bunch of the problems that normally come with that. Some writers have slacks, and people who follow a niche writer often delight to meet each other.

Need to find a way to keep it just as simple though.

</comment></comment><comment><USER18> congratulations on the launch.

I love the fact the product is so minimal at the moment, that it opens doors for real user feedback; I've been wanting to make something similar for a long time now, but was always stuck in the feature loop.

would be great, if others could comment on the MVP or Launch Early nature of Substack.

<comment><USER6> Yes, thank you, we love this feedback. We are trying to keep the product as simple as possible.

</comment></comment><comment><USER19> i'm not seeing any mention of trials for users.

let's assume i'm using this and churning out valuable content every week / day / whatever.

Someone hears about my thing and thinks "that sounds nifty. Not sure it's worth $x a month though"

I'd want some way for folks to be able to "try before you buy" let them get some specified number of newsletters before the system says "hey, you've been reading this newsletter for Y weeks now but we're at the end of your trial. <compelling message from author> To keep receiving this letter please <initiate payment process>."

<comment><AUTHOR> Thanks, that's a good idea.

The way we try to handle that now is by having an option for writers to write free posts - which are visible to anybody, and get emailed to non-paying subscribers. That way you can get a sense of the writing before committing (and regular readers are the ones who subscribe anyway...)

You're right that that doesn't let you "preview" the paid content though. We'll think about that.

<comment><USER19> yeah, free posts is ok, but with many newsletter topics they can quickly become dated and irrelevant and authors are unlikely to go back and regularly update them if they're also regularly writing a newsletter.

overall i really like the idea and i agree with one of the other commenters who says you don't really need many more features.

</comment></comment></comment><comment><USER3> Always a good idea to mention why the name of the product.

<comment><AUTHOR> We are a Stack for Subscription publishing.

<comment><USER3> Got it now, thanks.

</comment></comment></comment><comment><USER20> This is a great idea.

</comment><comment><USER21> Hey Cris, I really like your product/idea. I was thought about it year ago when I found [https://www.getrevue.co](https://www.getrevue.co). Which is a plataform for create a newsletter from curating content from Web. So, if you implement it on Substack, I'm sure it will be huge plus for the product, since multiple influencers could generate more income with their "weekly bookmarks" or something like that.

<comment><USER22> Revue is awesome! Thanks for making it.

</comment></comment><comment><USER11> Looks interesting, but 10% is _really_ steep to me.

That's just going to heavily incentivize your most successful users to bail. I run a five figure paid email service and I'm using a membership management service that charges flat fee plus 2%, and it annoys me every month. I'll be replacing them this year. Membership billing plus a synced email list on Mailchimp is really commodity at this point. Doesn't make any sense to pay a percentage of revenue.

If it was 10%, I'd replace them this week.

I may get pushback because there's a contingent of people on here who basically seem to think that ever worrying about price for software and services is the wrong move. I think that's pretty stupid when you're a small company. It's stupidly easy for a lot of small companies who are paying hundreds or thousands per month in recurring subscriptions to shave 20-30% off. If you're a solo founder, that's a huge increase in your personal bottom line.

EDIT: I'm probably coming across as too negative here, so let me add a few thoughts:

1\. You built something useful, launched it, and have paying customers. That's HUGE and puts you ahead of 99% of "startups" so congrats :)

2\. I strongly believe in the power of paid publishing and email marketing (it drives almost 100% of my income these days), and I think more cool tools and platforms in this space is excellent. This is the kind of thing that I would use.

My only real issue is just that I think what you're doing with the pricing model is shooting yourself in the foot (since it incentivizes people to switch away) AND it's unfair to users (since switching away is REALLY hard, and you probably know that and are counting on it to some extent).

Maybe charge flat + fee up to a cap? It'd be really comforting to know that I'd never pay more than $495 / month for this or something, and that would only be once I hit $10k / month in revenue or whatever.

<comment><USER23> You're also (I presume) an engineer. Most writers don't have the skills to build something like this.

One way to look at it is "I'm losing 10%". Another way is "I'm now making 90% I couldn't have otherwise made."

<comment><USER11> You don't have to build this. There are tons of membership management plugins and platforms out there, pretty much all integrate with Stripe, and most of them will keep a mailchimp list in sync so you can easily send emails to just your paying members.

EDIT: I also hate the logic of "meh, fees don't matter, my revenue would be zero otherwise!!" It's not true (you have other cheaper alternatives), but even if it was, doesn't that mean you should be fine paying 99% in fees to platforms and credit cards and whoever else? After all, 1% is better than 0%!!!"

<comment><USER24> There's actually a pretty interesting behavioral economics point to be made here. From a purely rational standpoint, you would choose to make 1% over 0%, because it's 1% more than you otherwise would have made. In practice, humans have a "fuck you" threshold above which they feel taken advantage of and refuse to cooperate. Check out the idealized economics experiment version of this which is called the Ultimatum Game: [https://en.wikipedia.org/wiki/Ultimatum_game](https://en.wikipedia.org/wiki/Ultimatum_game)

<comment><USER11> I do find this super interesting as a pure behavioral economics question, but this situation is a bit more complicated. There's actual work to be done for this revenue, other costs you have to manage, opportunity costs for any capital you have invested, and the risk that you'll actually make enough at the end of the day for it to be worth it :)

</comment></comment></comment></comment></comment><comment><USER25> Neat idea. As a reader, I would also find it useful as a discovery tool for interesting newsletter.

<comment><AUTHOR> Thanks! That's a great idea, especially now that people can create lots of these.

I wonder what would be the ideal format for that? It could give you a list of newsletters and their descriptions, with some popularity signals or something.. It might be better to surface the free content though. Maybe "here are some recent free issues by newsletters you might enjoy." Just thinking out loud...

<comment><USER26> What if you let authors tag their newsletters with topics and then let readers browse by topic?

<comment><AUTHOR> That's a great idea. Could help existing readers find things similar to stuff they already like. Thanks!

</comment></comment></comment></comment><comment><USER27> I love this. Anyway one can embed the subscription form in their website? Branding reasons.

<comment><AUTHOR> Oh that's a great idea. I will put it on our roadmap.

Currently you would need to link to the main page which has a subscribe form, but doing and embedded form would be much better.

</comment></comment><comment><USER28> Honest question: do people actually pay for reading a newsletter?

<comment><USER6> Fair question. The short answer is "hell yes." We already have writers on Substack making a lot of money with their newsletters. For instance, our first publisher, Bill Bishop, told the WSJ that he's making more money from his newsletter than he ever made from a corporate salary (he's a former exec and serial entrepreneur). Ben Thompson of Stratechery has many thousands of subscribers paying at least $100 a year. We can't share the private data of other publishers, but we have enough info to confidently state, that, yes, many people are happy to pay for newsletters.

</comment></comment><comment><USER29> The creator of browserify is gonna hate your name

<comment><USER30> I wonder if they'll have twitter hand the name over. Twitter certainly isn't above doing that.

</comment></comment><comment><USER31> Chris and Hamish,

Do you have anyone using Substack for a 'news aggregation' sort of newsletter? I am curious.

I have written software that makes it simple for me to curate ice hockey news and place links and article summaries on [http://HockeyBias.com](http://HockeyBias.com) every morning. I have been thinking of providing the data in an email newsletter as well.

Thank you.

<comment><AUTHOR> Ooh hockey!

Curation with commentary can be very valuable. That's a lot of what Bill Bishop does with Sinocism ([https://nb.sinocism.com/](https://nb.sinocism.com/))

If you can do a roundup that lets people stay up to date in a way they find valuable, it could definitely be a good idea. I'd encourage you to try it as a free newsletter on Substack and see if you can get people reading it regulary!</comment></comment>


Ted Kennedy on the Rocks (1990) - <AUTHOR> https://www.gq.com/story/kennedy-ted-senator-profile <comment><USER2> Editorializing titles like that will cause your account to lose submission privileges on HN, so please don't. The site guidelines ask you to _use the original title, unless it is misleading or linkbait; don 't editorialize_.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

(Submitted title was "Senators Ted Kennedy and Chris Dodd sexually assaulted a waitress in 1985".)

</comment><comment><USER3> [2016] and needs a title fix, please</comment>


SSS-PC: The Dependable Scalable Operating System (2003) - <AUTHOR> http://www.ssspc.org/index-e.html <comment><AUTHOR> The ISO link is buried, so I'll save you some trouble: [http://www.ssspc.org/download/ssspc-2.3-20040105.iso](http://www.ssspc.org/download/ssspc-2.3-20040105.iso)</comment>


Insights On SaaS From The $32 million HubSpot Mega-VC Round - <AUTHOR> http://onstartups.com/tabid/3339/bid/42537/Insights-On-SaaS-From-The-32-million-HubSpot-Mega-VC-Round.aspx

<comment><USER2> Anyone understood the four columns of revenues in the chart of publicly traded SaaS companies?

</comment><comment><USER3> This is super well written. Let's hope it works out for them.</comment>


The Pmarca Guide to Startups, part 4: The only thing that matters (2007) - <AUTHOR> http://blog.pmarca.com/2007/06/the-pmarca-gu-2.html

<comment><USER2> Hey quick feature request for hn, can we have a tag thing for well written pieces like these that are actually about startups as opposed to fluff pieces that I can find on digg/slashdot/reddit?

</comment><comment><USER3> Doesn't this fall down on its face as soon as you have a competitor with a team or product significantly better than yours? I wouldn't base my strategy on not having very much competition.

"In a great market -- a market with lots of real potential customers -- the market pulls product out of the startup.

The market needs to be fulfilled and the market will be fulfilled, by the first viable product that comes along.

The product doesn't need to be great; it just has to basically work. And, the market doesn't care how good the team is, as long as the team can produce that viable product.

In short, customers are knocking down your door to get the product; the main goal is to actually answer the phone and respond to all the emails from people who want to buy."

<comment><USER4> "Doesn't this fall down on its face as soon as you have a competitor with a team or product significantly better than yours?"

No. For many reasons:

\- If they're significantly better, they won't be for long.

\- If the pie is big enough, there will still be plenty of business even if your slice is relatively small

\- Imperfections in the market (friction) will give lagging competitors a chance to catch up

\- Many commercial customers will buy anything but what their competitors are buying. There _has_ to be more than one offering.

\- If the market is big enough, underdogs can still find their niche, which may be bigger than entire markets for other products.

Bottom line: Lots of customers makes up for every other problem just like a rising water level in a stream covers even the most jagged rocks.

</comment></comment><comment><USER5> Marc really needs to start writing again. Really really.

</comment><comment><USER4> This highlights one big advantage of bootstrapping over taking investment. Since you are being funded by customers, you're less likely to make a big mistake by missing your market. If you're not making what the market wants, you won't be around long enough to screw up that badly.

<comment><USER6> Not only that, but bootstrapping, and building a v1.0 that's the smallest thing that's useful, and then iterating over that while listening to your customers.

Basically, use the product development process as a way to find out about the market. Basically, use it as a way to acquire what Eric Ries calls "Validated learning about customers": [http://startuplessonslearned.blogspot.com/2009/04/validated-...](http://startuplessonslearned.blogspot.com/2009/04/validated- learning-about-customers.html)</comment></comment>


Anonymous hackers uncover ISIS plans to attack Atlanta, Italy and more - <AUTHOR> http://www.ibtimes.co.uk/anonymous-hackers-uncovers-plans-by-isis-attack-paris-indonesia-italy-lebanon-1529888 <comment><AUTHOR> There are so many problems[1-3] with this article. This is an important and scary tactic that needs to be nipped in the bud.

[1] "Anonymous" isn't a source, almost by definition

[2] Promoting "stopping terrorism through hacking" is a terrifying trend and will make surveillance easier

[3] Promoting "Anonymous bomb scare" as something to react to is begging for abuse</comment>


TSA Doesn't Care That Its Luggage Locks Have Been Hacked - <AUTHOR> https://theintercept.com/2015/09/17/tsa-doesnt-really-care-luggage-locks-hacked/ <comment><USER2> The most secure way to transport goods in checked bags is to fly with a checked firearm. You are required to lock a firearm in a hard-sided case with locks that only you have the keys to -- TSA approved locks are not allowed. You are allowed to lock whatever else you want in these cases too. They are screened more closely and if they can't determine contents with an x-ray they will ask you to open the locks in their presence. It's a tradeoff for convenience, for sure, but it's the only way to travel with securely locked baggage.

<comment><USER3> You don't even really need a firearm; a starter pistol, or probably even a flare launcher, would suffice.

<comment><USER4> Be careful with this advice - If the TSA considers an item a firearm, local law enforcement may as well. If you are traveling to a place where firearms are restricted, you could end up facing penalties for possesion that don't discrimenate between "starter pistol" and "real pistol"

<comment><USER5> Yeah, I seem to recall a few stories of people getting in trouble traveling _through_ states where this is an issue(I think the state in question was New York) via a connecting flight.

<comment><USER6> It happens in New Jersey too. What typically happens is there is an unexpected layover (say, due to weather), so the victims take possession of their luggage (with firearm) without malicious intent when they go to a hotel, and get arrested the following morning when checking in. In that situation, the proper (only?) course of action is to refuse to take possession of your checked luggage.

While traveling through a state, one is supposed to be protected by FOPA [0]. An uncharitable (technically correct but against the spirit) reading of the law is used by New Jersey and New York to harass gun owners, as in this case and in other more egregious cases.

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

<comment><USER7> Is a gun that has been permanently made inoperatible considered a firearm in NJ and NY? Could you travel with something that looked like a gun by X-ray, but in fact was harmless?

<comment><USER6> I can't speak to the ultimate legality of your idea, but I would guess that one would be arrested and it would be up to your lawyer to demonstrate that you were acting within the bounds of the law (if you were).

To your first question, I think it's fair to say that both NJ and NYC (and because of NYC, NY to a lesser extent) are generally perceived as being hostile towards firearms and general weapons ownership. If I were to predict states that restricted possession of an inoperable or antique firearm, NJ and NY would be at the top of my list, in that order.

To your second question, the appearance of the object has no bearing on it's legal status as a firearm (laws prohibiting look-alike objects notwithstanding). A pistol frame or lower receiver, incapable of being anything but a paperweight without all the other parts, is a firearm for legal purposes and would get one busted in the same manner as if it were a completely operational firearm.

Weapons laws are nuanced, pedantic, and frustrating. Frequently, they make no rational sense.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Look, I get how it's an amusing and poignant metaphor for what a bad idea key escrow is, but we all know that (unlike strong encryption) dinky luggage locks never provided any meaningful security in the first place. I pulled one apart with my hands once when I lost the key. You definitely don't need bolt cutters.

The outrage at this "spectacular failure" feels a little insincere. You want to convince me the government can't keep sensitive data secure, the OPM hack is closer to the mark.

<comment><USER9> The outrage isn't that your luggage can be stolen now. The outrage is that a) the government felt that it needed to invade the privacy of our luggage for security; so they made these master keys (yes, you can pull them apart with your hands, but provided the TSA doesn't regularly go through luggages, a broken lock is a quick way of telling someone's been through your stuff and you can take action appropriately) and b) it's been revealed that these keys can easily be obtained and the government does not care--showing the broader problem of what happens when you compromise privacy for "security".

<comment><USER10> We could have locks with seals. So the TSA could open them, but you could always tell that _someone_ had opened them. Bonus points for re-sealing with a verifiable tag of some kind.

Ultimately it's pretty pointless, since your luggage can simply be stolen, or hacked open with a knife.

I've always treated the locks as part of the security theatre. Utter nonsense that probably got someone promoted because it sounded good. If someone at TSA said, "Hey we need to do something, _anything_ , just so we look like we're doing something," then pointless toy locks are not all that damaging compared to other possible "somethings" they could have stuck us with.

The TSA truly needs to go.

</comment></comment></comment><comment><USER11> Because everyone knows it is security theater.

Plus stealing from luggage is a major source of income for TSA employees, they are caught every few months but they keep doing it - so for every one caught you know there are hundreds not caught and management knows this.

[https://google.com/search?q=tsa+stealing](https://google.com/search?q=tsa+stealing)

Remember how corrupt TSA employees are the next time you see a story on the news about how corrupt officials in another country are...

<comment><USER12> I agree with you that the TSA is a joke, but as someone who worked as a TSA agent before, I never stole anything, nor to the best of my knowledge did anyone I worked with steal anything. Stealing, in fact, would be kind of difficult, even in the baggage rooms. I think "a major source of income for TSA employees" is a pretty gross exaggeration of the truth. For the most part, TSA employees are just a bunch of regular people trying to make a living, just like everyone else.

</comment></comment><comment><USER13> Why does anyone bother with locks on luggage secured with zippers?

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

<comment><USER14> There are zippers that cannot be closed like that - the zipper keys lock is fixed on the bag[1]; you can open it with a pen, but you cannot close it again - so you can see that it was tampered with.

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

</comment></comment><comment><USER15> One thing I always wondered: why inclined people couldn't buy the four locks and mechanically reverse engineer them? Could someone not disassemble the lock and see where all the tumblers fit and iterate on a solution until they get it?

I feel that the people that would exploit the 3D key files now floating around the Internet could achieve almost the same thing anyways.

I don't think any sufficiently logical person ever thought that a TSA lock was secure.

<comment><USER16> yea you could just go shopping and buy the range the locks which you can see the lock key ID through the packaging. just purchase all variations... likely people did this in past.

i never use luggage locks, i also keep my most valuable items in my carryon rather than my checked bags.

the locks are useless. easily cut, easily opened using tools, TSA still had access, now other people have access by copying the TSA keys.

if someone wanted to break into your luggage, they would have with or without the key.

i have had hard shell luggage cracked open by just terrible handling, i once had a lock/zipper got ripped off when it snagged somewhere.

i pack my luggage in a certain way and utilize tape in certain areas to know if someone was rummaging through it at the airport.

there is no security/privacy for your luggage at the airport

</comment></comment><comment><USER17> The security theater of the TSA is indefensible.

However, I found the article dubious. The only source for Mike England's alleged response is an email to _The Intercept_. While I am not calling the author a liar, I am skeptical that the response was placed in context.

> Clarification: An earlier version of this story incorrectly reported that > hackers had broken into Travel Sentry's internal website.

This is a particularly egregious error in reporting and suggests, to me, very sloppy reporting. So, without seeing the actual content and context of the email, including perhaps, the email which prompted the response, I am reserving judgment as to whether or not what has been reported is true to what the TSA actually meant.

It certainly wouldn't surprise me to hear the TSA responded in that way, but that doesn't mean that's what's actually happened.

</comment><comment><USER18> I used to have a bit of an interest in recreational lock picking. I had a few TSA-approved locks that I liked to use as demonstrations to friends, because they were so trivially easy to open. They would pop open after just a few seconds of jiggling anything at all around in there, so they were great at building people's confidence that they could learn to pick locks, and that locks are just puzzles, not magic.

This is the only time that I've ever considered the TSA locks to be useful for anything at all.

</comment><comment><USER19> There are a few unfortunate truths here:

1\. The TSA is invasive security theater operated on the principle that the most effective placebos are those with tangible side effects, namely body scanners and palpable tension at ultra-vulnerable (targets in and of themselves) security checkpoints.

2\. The TSA is a country-scale jobs program for poor, unskilled, and unemployable people who might otherwise join disruptive political groups that promise more resource redistribution.

I think the first two points are reasonable if not explicitly provable, but my third point goes off the reservation a bit:

3\. The TSA-friendly luggage locks are one of many overt acts of submission that the members of the public undertake in order to travel with speed; there is no incentive for the locks to actually work or be secure, as their primary purpose is to symbolize obeisance. I imagine this may be the case because the TSA-friendly luggage locks are jokes to begin with, as anyone with a common file, rudimentary lockpicking skill, or bolt cutter could pop them open in mere moments... not to mention the misbegotten troglodytes who actually have the master keys and help themselves whenever it suits them.

<comment><USER15> > 2\. The TSA is a country-scale jobs program for poor, unskilled, and > unemployable people who might otherwise join disruptive political groups > that promise more resource redistribution.

This is a pretty mind blowing perspective.

<comment><USER17> From a historical perspective, it's not that mind-blowing. Most of FDR's work programs were designed not just to get people working, but to prevent open revolt.

What is mind-blowing, to me, is that the program provides no service. FDR's programs did, and we still benefit from those programs today (exhibit A: national parks).

<comment><USER20> I've often wondered if the rural location of many of these programs (the CCC, many of the WPA projects) was chosen specifically to get men out of the cities so they would be unable to participate in riots.

</comment></comment></comment></comment><comment><USER21> The article seems to me an admission that the locks were never intended to secure anything and just there to make people feel better. At least the TSA understands that not only are the locks unsecure now, they never were.

</comment><comment><USER22> > _In a spectacular failure of a "back door" designed to give law enforcement > exclusive access to private places, hackers have made the "master keys" for > Transportation Security Administration-recognized luggage locks available to > anyone with a 3D printer._

Surely this doesn't require a 3D printer. The right key blank and a set of needle files should do the trick, or should be able modify an off the shelf key.

I suppose saying it can be done with a 3D printer makes it all seem more dramatic.

</comment><comment><USER23> Most bags can be opened and closed with a ball point pen _WITHOUT A TRACE_ completely bypassing any locks.

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

</comment><comment><USER24> I think its fantastic. Now when people bring up the fact that the government needs backdoor access to encryption to fight "terrorism" I can just point to how well they manage these things in practice.

</comment><comment><USER25> The best advice I've seen is to secure your bag with a cable tie, then you tell whether anyone's been through it.

<comment><USER26> These can be quickly opened with a narrow flat screwdriver. But they probably wouldn't bother with it in practice.

<comment><USER27> The goal is not to secure the luggage; its used as tamper evidence.

<comment><USER28> The point being, once opened non-destructively (with a screwdriver), cable ties are easily re-closed, leaving no trace of tampering.

</comment></comment></comment></comment><comment><USER29> If you REALLY, REEEALLLY need the things with you, you could always do something like UPS with signature and insurance. Make the insurance level something like 3x the value of our items and you should be good.

</comment><comment><USER30> Who cares? These locks could be cut with tweezers. Manual baggage inspection notices could be faked regardless. Pure noise.

</comment><comment><USER31> I thought that the key's images were posted online by a TSA employee that didn't know any better...</comment>


Private Medical Data of Over 1.5M People Exposed Through Amazon - <AUTHOR> http://gizmodo.com/security-hell-private-medical-data-of-over-1-5-million-1731548110 <comment><USER2> wowz</comment>


CSS Selectors and Pseudo Selectors and browser support (Updated 2010-03) - <AUTHOR> http://kimblim.dk/css-tests/selectors/ <comment><AUTHOR> It includes IE9 preview, and latest betas from Chrome 5 and Opera 10.

It's kind shocking seeing that IE9 is actually ahead of Firefox in this area.</comment>


Crowd sourced techcrunch - <AUTHOR> http://crunchyideas.blogspot.com/ What's wrong/good with this thought <comment><USER2> This kind of describes a free-for-all wire service, it will need quite a few Janitor members to keep down the spam and low quality postings.

<comment><AUTHOR> Any thoughts in this direction will be cool

</comment></comment><comment><USER3> A whole lot of 'Digg' references here.

The reddit code is open source; it would be perfect for this project idea.

<comment><AUTHOR> Thanks for reference. It will be great if you can think of some features for this. May be some body will find it interesting to implement. Atleast I will get some thing to play in my mind</comment></comment>


Ask HN: know any Japan-based startups? - <AUTHOR>

I'd kill to move to Tokyo for a while, and I think working for a startup with a location there would be a cool way to do it. Any thoughts? <comment><USER2> I lived in Japan for many years until recently and had my own start-up with two other co-founders. The company is still going (and quite successfully I might proudly add).

There are many start-up companies over there across all industries. There isn't really a clique/community like there seems to be in San Fran, Sydney (my home town) etc. Founders just start up out of opportunity and need.

There are also open desk places for start-ups. A lot of that seems to be mainly occupied by creative design companies. In saying that I think you'll find most start-ups are not tech based.

If you'd like to know more shoot through some specific questions and I'll see if I can help you or even introduce you to the appropriate people.

\--

I seem to not have answered your question with the above.

If you are eligible for a work visa get it before heading over. A common way to get a work visa if your two countries don't have a working holiday visa agreement is to apply for an English teaching role in your home country and then when you enter the country use that work visa to springboard into another job (note: this normally means you have to teach English for several months which can be hell if you don't like that sort of thing).

Already having a job ready for you when you arrive is the best way but highly unlikely a start-up is going to go through the process of sponsorship for your visa.

If you have 100K to spare you can go over there establish your own company and then sponsor yourself. You can then pay yourself an annual salary of 100K and get that money back. Little bit dodgy but within the law. At least the way I did it was!

Expect to get 200,000-300,000yen/month for a real beginning of the journey start-up company. If it already has a steady and growing revenue stream then you can probably negotiate higher.

If you are open to one-step-above-a-backpacker's-hostel living arrangements I suggest you get a room with SakuraHouse (if you plan to stay in Tokyo -- also advised if you want to work in a start-up). As it is cheap and easy to cancel the contract. Once you get a feel for the place then look to set up more permanent digs. Also look through the classifieds on www.metropolis.co.jp which is a local rag for foreigners living in Tokyo (you probably want to do the whole complete Japanese immersion thing but finding a Japanese sharehouse will be more difficult than a foreign sharehouse).

Winter is feezing, Summer is humid. Be prepared!

It is an amazing place.

</comment><comment><USER3> @patio11 has <http://appointmentreminder.org> and <http://www.bingocardcreator.com/> He's based in Japan, but targets the US market.

He's got a blog at <http://www.kalzumeus.com/blog/>

\</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>---

Sacha Greif lives in Japan, too. <http://sachagreif.com/>

<comment><AUTHOR> You'd think I would have figured that out. Somehow I completely missed that part. Amazing.

Thanks for the help!

</comment></comment><comment><USER4> Working for Rakuten would be an easier way than trying to work for a startup.

</comment><comment><USER5> AnyPerk.com (YC12w) has engineering team in Tokyo as well.

</comment><comment><USER6> I've been looking for the same

</comment><comment><USER7> gengo.com

<comment><AUTHOR> PERFECT</comment></comment>