Bootstrap's maintainer hates the semicolon - <AUTHOR> https://github.com/twitter/bootstrap/issues/search?q=semicolon <comment><USER3> Thanks for drawing my attention to this. Currently, I maintain a separate branch simply for adding the missing semicolons so that I can link the individual bootstrap files with my project. It's been quite annoying and I now know that the annoyance may not go away anytime soon.

I hate these ideologues. But this is the trouble with JS I guess. I actually love javascript because of the highly dynamic nature of it. But that dynamism also lends itself to these kind of problems. I don't know of any other language where people can CHOOSE to follow syntax. Part of the problem is the awkward interpreter specs I guess. But also, with JS seems like everyone has an opinion :)

<comment><USER4> > I don't know of any other language where people can CHOOSE to follow syntax.

Your argument is incorrect. :) Omitting semicolons is perfectly valid and correct syntax. The spec is explicit about it being allowed and how the code shall be interpreted: <http://es5.github.com/>

It may be a _good rule of thumb_ to use the semicolons, because you have to be careful without them, but in the end it's a choice based on team preference. If you are a very pertinent and careful type of person, and you don't have any rabid illiterates on your team, going without semicolons makes perfect sense.

<comment><USER3> The spec has provisions for automatic semicolon insertion that need to be considered carefully before deciding to completely ignore them. Now consider that <http://twitter.github.com/bootstrap/index.html> says the following:

"Bootstrap is designed to help people of all skill level—designer or developer, huge nerd or early beginner. Use it as a complete kit or use to start something more complex."

So: 1\. "illiterates" are welcome to use it. 2\. If the goals are to be met, do not assume anything that can be interpreted differently by different players.

</comment></comment></comment><comment><USER5> I wouldn't see any significant problem with a policy of omitting semi-colons when there's no risk of ambiguity, but turning the omission of semi-colons into a religion? That's enough to make me question what other nutty peculiarities exist in his coding philosophy, and therefore whether I'd dare risk my own projects using his library.

<comment><USER6> It's just embracing the ASI. Nothing wrong with it. On the contrary, the understanding necessary to use it implies good knowledge of the language.

<comment><USER7> And is therefore more expensive to maintain.

<comment><USER8> It's probably less expensive to maintain, because programmers' brain reading the code while not having to parse the extra image information - <USER2> semicolons are, and they add a lot of clutter - gets less tired and in turn is less prone to make errors in other coding areas.

I see two camps here - people who fear the unknown or come from semicolon- mandatory languages and can't get used to the semicolon-less style, and informed people who don't fear to embrace what is aesthetically more pleasing and logically more sound, despite the persecution by the members of the first camp, which I'd say also happens to be more religion-prone.

<comment><USER9> I try to assume good faith with HN comments, but this smells like a troll.

In JavaScript, semicolons reduce ambiguity. Whether you know the semicolon rules in the language or not is immaterial to reducing ambiguity, similar to how defensive parenthesization is helpful regardless of whether you know the order of operations of a given language by heart. This is why the prevailing wisdom is to always use semicolons: principle of least surprise.

The nonsense about "persecution" and "more religion-prone" is just that. "Informed people" -- "aesthetically more pleasing" -- "logically more sound" -- _ad hominem_ and begging-the-question horseshit. Do better.

<comment> loup-vaillant I happen to have a definite, knock-down argument in favour of a particular semi-column free style: mandatory indentation (which also eliminates curly braces).

[http://okasaki.blogspot.com/2008/02/in-praise-of- mandatory-i...](http://okasaki.blogspot.com/2008/02/in-praise-of-mandatory- indentation-for.html)

I'll grant you that's not a large scale experiment on a peer reviewed paper. But I trust Chris Okasaki on this one, and to me, his experiment counts as strong evidence against semicolons and brackets. (Specifically, semicolons and brackets are error-prone, especially for beginners.)

Now for Javascript, I'd probably write the semicolons. Because there _is_ some ambiguity in the way we humans would parse Javascript without semicolons. But really, the root of the problem is that Javascript's syntax is suboptimal. Sure, Dennis Ritchie didn't know better at the time he wrote C, but this is no longer an excuse.

If I had a say, I'd simply write an alternative syntax with mandatory indentation. It's not hard[1]. If Bootsrap's maintainer dislike semicolons so much, he probably should do so as well. He will likely lose contributors, but someone who cannot get past a Python-like syntax is probably not someone he would want to work with anyway.

[1]: <http://www.tinlizzie.org/ometa/> (Quite the tool for the job. Plus, it already features a Javascript parser you can modify.)

<comment> loup-vaillant Downvote? What could possibly warrant that? Not that I'm offended, but I _am_ confused. I thought I was accurate and relevant. Did I get some fact wrong? Or did I say something offensive?

Re-reading my post, I find 2 potentially offensive excerpts:

 _"Dennis Ritchie didn't know better"_ Assuming mandatory indentation is superior, this one is flatly true (and there are other things to be said about the syntax of types). But I'm not saying he _could_ have known better. As far as I know, _no one_ knew better at the time.

 _"someone who cannot get past a Python-like syntax is probably not someone he would want to work with anyway"_ I apologize for this one, but I am personally fed up with people who won't use provably superior technology just because it would break their habits. Enforcing indentation in Javascript would be a minor syntax change, that can be learned in minutes and mastered in a day. I'd be wary of someone who refuses to make the leap despite the evidence for it. I must admit however that I'd understand if they just didn't believe in the evidence. (but then we can talk).

<comment><USER6> That's a score for coffeescript, but you don't want to start _that_ discussion here...

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> He wrote a blog post about this a while ago, I don't really get his reasoning but I guess he's happy with his decisions:

<http://www.wordsbyf.at/2011/10/31/i-dont-write-javascript/>

<comment><USER11> This blog post accurately states the broken idea:

> Each is perfectly valid. Each behaves the same. It's just a matter of > _preference_ and finding the style that makes most sense to you.

Part of being a good steward to a successful project is realizing that writing code for yourself is a Bad Idea™. If thousands of people are using your code, then write your code for maximum clarity, not your personal preference of how to get clever within the spec.

Code is harder to read than to write. To borrow a line from Jacob Kaplan-Moss, if I write the cleverest code that I am able to, then by definition I won't be able to understand it later.

This semicolon approach isn't invalid, but it is clearly a source of confusion, and it requires that users comprehend the choice and the tradeoffs. This seems like a poor choice for a framework whose audience is largely people who _don't_ grok this stuff and are bolting it on wholesale.

<3 bootstrap, just my $0.02.

<comment><USER6> Leaving semi-colons out is not clever, it's just understanding where you need them instead of shooting blindly.

<comment> scooty-puff Does it hurt to have extra semi-colons? Maybe you have some empty statements. Does it hurt to have too few? Well, if you either do not know what you're doing, or someone maintaining doesn't understand what you did, etc., then yes.

<comment><USER12> Extra semicolons can cause problems. If "someone who doesn't know what they're doing" starts putting semicolons after randomly chosen tokens, it will absolutely break your program. You need to understand statement boundaries whether or not you explicitly mark them with semicolons.

</comment></comment></comment></comment></comment><comment><USER13> Idealism is like sex: everyone can enjoy it in private, but you shouldn't do it in public unless it's your whole reason for existing.

From this we deduce that Richard Stallman is really Ron Jeremy.

</comment><comment><USER14> If you're going to use JS, you're not allowed to change things like this. It just causes problems for people.

Easy solution, use CoffeeScript and have it compile down to JS. My favorite feature of CoffeeScript is the ruby/python line conventions spacing (2 spaces, no tabs), and no semicolons.

They're already compiling the CSS from Less. Seems natural to add CoffeeScript to the chain.

<comment><USER15> alternatively, use JSLint

<comment><USER16> I much prefer JSHint. JSLint is draconian, and has some borderline insane decisions (it complains if you don't declare your vars at the top of a block—is this 1980?).

And yes, I realise that some of these options can be turned _off_ —but JSHint has better defaults.

<comment><USER17> There is a reason for the insanity you are complaining about. The vars are effectively hoisted there by the interpreter anyway, by pulling them to the top of the block you remove a possible point of confusion, and more importantly a possible point of bugs.

</comment></comment></comment></comment><comment><USER18> I don't get what the issue is. I run bootstrap js through the closure compiler (with minification and optimization) and it works just fine. I don't agree with the policy myself, I prefer semicolon, but I also prefer CoffeeScript. That said, if Fat wants to remove it, that is his choice, leave him alone. Update: Just read his blog posting. If Fat _really_ wanted the minimalist approach, he'd use coffeescript and then people would bug him over that choice instead. ;-)

<comment><USER19> Did you just say using CS is minimalist?

<comment><USER20> I believe he was referring to terse code.

</comment></comment></comment><comment><USER21> I want top point out that this shows how it is very very tricky to build a good team. Just imagine that one of your co-workers (very smart, the best, but refuses to understand 'principle of least surprise') is refusing to add semicolons and claiming we now need to change mimifier and change a way how we use 3rd party js dynamic loaders. And that can cause quite unpleased dynamic in the team.

This is one of reasons why companies have strict coding-style guides but that is overhead for a very small company (you don't need coding-style you just need developers which know that code needs to be written with understanding it will also used and maintained by other people in your team).

<comment><USER22> And if your good programming team can't figure out that they might need to edit a coworker's Javascript library to add in missing semicolons in order to cleanly minify their scripts, you have a different (bigger) problem.

</comment></comment><comment><USER23> Not having to use semicolons sounds nice, but in practice it can have terrible effects. E.g.:

      var x = function() {
        // something
      }

      // avoid polluting global scope:
      (function() {
        // Some initialization.
      })()

This will call the function x with the anonymous function as its argument, and then call the result of that.

There are more examples to that point, and many of them really aren't all that straightforward. So don't rely on automatic semicolons.

<comment><USER6> First commandment of semi-colon-free: any line that starts with [,(,+,- should be prefixed with a semi-colon.

      var x = function() {
        // something
      }

      // avoid polluting global scope:
      ;(function() {
        // Some initialization.
      })()

      ;[1,2,3].forEach(...)

In practice those are the only places you'll see (and need) them. It has the extra benefit of disencouraging starting a line with a pre-increment, hacks or weird constructs (not talking of IIFEs of course), and making sure you're never calling a function or accessing properties _by accident_.

<comment><USER24> Good advice, and interesting because languages and syntax are interesting to me. But I would never introduce this in my team as a replacement for semicolons at the end of each statement. It seems too random a rule to just follow, hence you'd need to understand the specific problem that it solves. At that point your mental model has become slightly more complex, which doesn't seem worth it.

<comment><USER6> It's absolutely not random. You only put semi-colons where needed. There is no _optional_ use.

'semicolons at the end of each statement' is much more random. They are unnecessary after function declarations or conditionals, and you might end up forgetting them somewhere that actually matters, just because you're not paying attention. The mental effort for this change is severely overestimated.

</comment></comment></comment></comment><comment><USER25> Check out the following issue, not just the matter of style..

<https://github.com/twitter/bootstrap/issues/401>

<comment><USER26> The reply seems immature from the perspective of project maintenance.

<comment><USER27> That seemed to be a trend in this project, that we briefly overcame: <https://github.com/twitter/bootstrap/pull/266>

</comment></comment></comment><comment><USER3> I have created a repo at git://github.com/rajivnavada/bootstrap.git that addresses this issue in the Makefile.

Basically, I added a 'proper' target that 'bootstrap' depends on. This target simply adds the semicolon to the end of the file. Hope it helps those of you having problems.

</comment><comment><USER28> This is extremely frustrating. I have to create a special code path for Bootstrap JavaScript because it can't be minimized using the standard tooling that works on everything else.

<comment><USER15> one could argue that the toolchain sucks if it can't process valid JS

<comment><USER28> That would also be extremely frustrating if one argued that.

</comment></comment></comment><comment><USER29> huh, isn't the bug rather in the software that can't deal with the "missing" semicolons? (I hate semicolons, too)

<comment><USER30> I agree with this, any minifier worth using handles semicolons just fine. Try uglify.

</comment></comment><comment><USER31> I avoid using the semicolon in JS because doing so forces me to be aware of the semicolon insertion rules. Forgetting them can lead you to believe that statements like

        return
        { foo: 3 };

do what you expect :)

<comment><USER32> Why would you ever write that

</comment></comment><comment><USER33> This has bothered me so many times when using Bootstrap. The compressor I mainly use (UglifyJS) handles the compressing alright, but the concat process fails. At least just have a semicolon at the end of all JS files and that's enough for most people.

</comment><comment><USER34> I think this is one of those stylistic preference issues that basically doesn't matter, which is why people will probably go on about it for weeks with no resolution in sight.

Personal anecdote time: I've been writing Javascript for my job for about 16 months now. When I started, I read all the same material as the readers of this site probably did, mostly written by Crockford, advocating a certain brace/semicolon heavy style. But after dutifully following this for about 6 months, I started to notice that I had made many 'mistakes' in the code, to do with missing semis particularly, and so had a lot of other people in the company. Of course, all the code ran fine everywhere and nobody had noticed in 6 months.

So, when writing code for personal exploration at home, I stopped using semis. It's surprising how much time you spend making sure they are there when the interpreter won't check for their presence (and doesn't care either way). Issues can crop up to do with missing semis, but so far I haven't had a single issue, probably because i'm aware of avoiding certain things, like starting a line with a bracket.

So, in my personal experience, it hasn't mattered to have them or not. If you absolutely need them for minification or similar, you should be using a compiler like yui. You are going to make a mistake if your code base is large enough to matter, irrespective of how vigilant you are, so you might as well leave minutiae like this to a computer.

<comment><USER9> _I think this is one of those stylistic preference issues that basically doesn't matter, which is why people will probably go on about it for weeks with no resolution in sight._

In theory, yes, it doesn't matter. In practice, it does (and YUI, etc. do not fix the problem):

<https://github.com/twitter/bootstrap/issues/401>

<comment><USER34> I don't see how this is the original authors problem actually, regardless of the cause. Someones incorrectly written code injected into your own runtime environment could cause all sorts of weird problems.

IMO this is a reasonably serious browser security issue along the same lines as CORS, but thats another argument.

</comment></comment></comment><comment><USER35> Has anyone on this thread RTFS?

Semicolons are not optional. They are inserted for you as a convenience when the parser can figure out what you meant.

This situation wasn't a big deal in the early days. But the patterns of coding that have emerged to deal with Javascript's scoping problems have brought this from a curiosity to something profoundly crazy.

Using an operator (i.e. !) to fool the parser is hilarious but really not OK.

Writing code is an exercise in communication. You are communicating with other programmers (including your future self) and the parser. The zero semicolon style espoused by @fat is problematic for both other programmers and the parser. Perhaps one day @fat will win and his style of communication will be sufficiently accepted to be valid but this is not that day.

The relevant section of the ECMAScript spec is included for your convenience:

7.9 Automatic Semicolon Insertion Certain ECMAScript statements (empty statement, variable statement, expression statement, do-while statement, continue statement, break statement, return statement, and throw statement) must be terminated with semicolons. Such semicolons may always appear explicitly in the source text. For convenience, however, such semicolons may be omitted from the source text in certain situations. These situations are described by saying that semicolons are automatically inserted into the source code token stream in those situations.

[http://www.ecma- international.org/publications/standards/Ecm...](http://www.ecma- international.org/publications/standards/Ecma-262.htm)

</comment><comment><USER36> I don't see it as really a problem. Its just a matter of personal coding preference.

As far as minification and optimization is concerned it works fine using yui, google closure, uglify.js .

(also mentioned by fat in [https://github.com/twitter/bootstrap/issues/401#issuecomment...](https://github.com/twitter/bootstrap/issues/401#issuecomment-2348795))

</comment><comment><USER6> [http://blog.izs.me/post/2353458699/an-open-letter-to- javascr...](http://blog.izs.me/post/2353458699/an-open-letter-to-javascript- leaders-regarding)

A proper minifier/concatenator will add the necessary shielding semi-colons. Don't use anything that messes with your code without parsing it.

</comment><comment><USER37> How can ideologies on such futile things as a semi-colon get in the way of playing nice with others? Just put that in perspective with RMS' intransigence in his conviction and fight for freedom. Freedom and semi-colon, which is the more fundamental and worth fighting for?

</comment><comment><USER38> This whole thread is probably going nowhere, imo. The maintainer has valid reasons - and it's part of the spec. The issue raisers have their reasons - minifiers don't work for them. Here's the beauty of git and github, one can always run a fork :)

</comment><comment><USER39> Really formatting wars are _really_ stupid. ASI is like indentation, it is trivial to write a program that converts between the two representations. The last time we had an issue about this at work, someone just wrote a pre-commit hook that sets the indentation to be standard without changing the parse tree (it actually asserts the parse tree is the same).

Now you can code any way you want, but no more white-space changes cluttering up the history of files. This is the worst type of holy war because it not only doesn't matter much (which is true of any) but there is a technological solution that the engineers involved are all ignoring.

</comment><comment><USER6> It's amazing (and funny) how this whole semi-colon thing is based on fear.

People _should understand_ the role of semi-colons and ASI, just like they should understand the comma operator. It's not hard, takes 10 minutes (read Isaac's post).

Everyone saying that they don't need to understand it is doing a disservice to the community, there's no harm in wanting knowledge of the language to evolve. A few years back people seldomly used IIFEs, and I remember hearing the same argument (wtf is that, don't use it, I don't understand). Change is good.

<comment><USER40> There's no _should_ about it. I know ASI exists, and I also know I need never concern myself with it, because I prefer the simplicity and consistency of finishing each line with a semi-colon.

</comment></comment><comment><USER41> Is this really about semicolons, or is it just that with _so many fucking people_ watching, using, and messing around with the bootstrap repo that you're bound to find a bunch of bizarre little edge-case problems? You know what I mean?

My repos don't have a lot of semicolon-related problems, because they don't have almost 20,000 watchers and tons of people using my code.

</comment><comment><USER42> Thanks for drawing my attention to this.

Am I the only one who now won't consider using Bootstrap for a project (based on this semicolon issue)?

<comment><USER43> Yes.

Or at least, _I_ would still use bootstrap even if I had to throw out all of the js.

</comment></comment><comment><USER22> One cold dark night in Javascript-land...

A: Hey, remember when coding was fun? When it was an extension of yourself and you got to create things with it? Create things!

B: No. We're not allowed to do anything except what the Good Book deems acceptable.

A: But, but, you get to take this blank slate and carve out of it whatever you can imagine! Pure expression! And remember when you prioritized your coding style for enjoyment?

B: No. Coding is not fun. Coding is about maximum compliance.

A: ... I remember, but sometimes I think the web has forgotten.

A: I mean think about it. We're banished from the 'new' keyword. We can hardly use polyfills or even extend the native prototypes. How I used to love statements like [[1,2],2,3].flatten(), but lo they are forbidden! Having even one prototype extension in your library is a death sentence. No having fun in Javascript-land!

B: True, fun is not allowed.

A: Hey, what's that over there? That gleaming light coming from the back of that house? Is that a party? Hey it's that house that @fat and @mdo built. They're having fun? We should join them!

B: You don't want to go there man. They don't use semicolons.

A: Is that all they're doing? So what, they're not following the Good Book? They're not afraid to do things a bit out of the ordinary? I'm out of here. See you later Javascript-land. B, I'm going to have some fun with those guys.

B: ... prototype extensions?

(Thanks @fat, @mdo & Twitter for Bootstrap, and for giving it away nonetheless. If I ever have a problem minifying your code, I'll fork it and just add the semicolons myself.)

</comment><comment><USER44> Stupid question maybe but what's wrong with the included bootstrap.min.js? What am I missing?

<comment><USER45> Basically, people don't want the minified versions of files while they're developing, and there will always be people coming to the project with whatever minification tools in their build that can't handle the missing semicolons. Currently, the answer is "change your build tools".

<https://github.com/twitter/bootstrap/issues/1795>

</comment></comment><comment><USER46> I don't think this is a matter of taste. I think this is showing off for the sake of it.

</comment><comment><USER47> This sounds a lot like the spaces vs tabs holy war. The C way vs the Ruby/Python way.

</comment><comment><USER48> I also hate it. And the colon, for that matter.

</comment><comment><USER49> That's a reasonable thing to hate.

</comment><comment><USER50> problem here is ruby.ruby developers hate semicolons. They ignore the decades old history opf the semicolon, and assert that the ruby/python/haskell way of indentation and semicolon-less code is the better way. They COULD be right, but im too deep seated in C/C++/Java/JS. One of the problems with javascript is the fact that it gives the choice.

<comment><USER51> Actually, Haskell lets you do it either way. It's the best of both worlds :)

This code:

        do a <- [1,2,3]
           b <- [4,5,6]
           return $ a + b

can also be written as:

         do {
           a <- [1,2,3];
           b <- [4,5,6];
           return $ a + b
         }

or:

         do { a <- [1,2,3]; b <- [4,5,6]; return $ a + b; }

I've even seen it like this:

         do { a <- [1,2,3]
            ; b <- [4,5,6]
            ; return $ a + b }

<comment><USER52> JavaScript also permits you do it either way. That's what this whole argument is about!

<comment><USER51> I'm merely responding to the parent's "ruby/python/haskell way of indentation" phrase.</comment></comment></comment></comment>


Who Was the Falling Man from 9/11? (2016) - <AUTHOR> https://www.esquire.com/news-politics/a48031/the-falling-man-tom-junod/ <comment><USER2> I'm always surprised that people chose to chastise and berate someone for trying to find facts and truth. The article talks about how trying to simply find out how many people jumped from the towers is met with disgust and condemnation, both in-person and online - with webpages dedicated to baiting people searching for it on google, and offering an offensive statement telling those people to get lost and that they should be ashamed of themselves for looking.

I don't know, maybe something in my brain doesn't work quite right, but I never understood it - knowledge is knowledge. When we search for something, the desire to find the answer should never be shamed, even if the answer is shameful in itself.

<comment><USER3> The disgusting part isn't wanting to know who he is. It's tracking down the family, and when they refuse to talk, crashing the dead man's funeral to show his widow and daughters the picture of him moments before his death.

> All that remained was for Peter Cheney to confirm the identification with > Norberto's wife and his three daughters. They did not want to talk to him, > especially after Norberto's remains were found and identified by the stamp > of his DNA—a torso, an arm. So he went to the funeral. He brought his print > of Drew's photograph with him and showed it to Jacqueline Hernandez, the > oldest of Norberto's three daughters. She looked briefly at the picture, > then at Cheney, and ordered him to leave.

<comment><USER4> yeah, there's nothing inherently wrong about trying to figure out some fact. the problem arises in how you go about doing it. once you start asking questions that bring up painful memories, you have to consider whether the fact finding is actually worth bringing up all that pain. seems like this particular fact wasn't really worth it.

related but different: something can be an ironclad matter of fact and at the same time be entirely inappropriate to mention, depending on the venue.

</comment></comment></comment><comment><USER5> I read this article when it first came out four years ago. I'm not generally someone who needs/heeds trigger warnings (though I'm cool with having them for people who do) but this is probably one of the few pieces of journalism I've read that really viscerally fucked me up. I think it's the way the first few paragraphs vacuum away the politics and history and just isolate these moments of true existential horror, then make you imagine them over and over again from different angles... Yeah, it's a lot.

I definitely recommend people read it. Read it because thinking about death is important. Read it because the questions about history and how we document it are important. Read it because it's just damn good writing. But read it on a sunny afternoon with plans to do something fun later, because the headspace it puts you into isn't somewhere you may want to stay too long. Your mileage may vary.

<comment><USER6> Honestly, for me it's been enough years that reading the article did not have the effect on me it might have had years ago.

</comment></comment><comment><USER7> Unless there is some deep insight in the article, I feel like the person's identity is not something we need to know.

It was a terrible situation. What benefit comes from knowing? Are we supposed to judge that person for not wanting to suffer slowly instead of taking a faster route? Or are we supposed to commend his bravery or sacrifice?

<comment><USER8> > Are we supposed to judge that person for not wanting to suffer slowly > instead of taking a faster route?

Speak for yourself there.

As for me, identity makes him a person, a possessor of human qualities, something more than an increment operation on a counter.

<comment><USER9> > Speak for yourself there.

What do you mean by this? OP's implication seems reasonably obvious. Are you saying it made more sense not to jump?

<comment><USER8> That the call to be judgmental is OP's personal construction that he/she is trying to ascribe to others who likely do not share that trait.

</comment></comment></comment></comment><comment><USER10> I don't mean this to be insensitive, but when I first saw that image I was struck by the resemblance to the Tarot card The Hanged Man.

</comment><comment><USER6> American — unaware there were so many photos, so much footage of falling people from September 11, 2001.</comment>


The Indie Bubble Is Popping - <AUTHOR> http://jeff-vogel.blogspot.com/2014/05/the-indie-bubble-is-popping.html <comment><USER2> Much of what Jeff has to say in this article is true. Especially the part about how the cold, hard-hearted hand of Adam Smith will ensure that when X dollars are divided among Y game developers and Y increases, that the developer income will decrease.

That is why the only real hope of the developers is to change X. And that is possible. There are hundreds of thousands of 12-year-olds who are obsessed with Minecraft. (Seriously: last week when my son visited a new school wearing a Minecraft shirt, something like 60% of the male middleschoolers go out of their way to say something about it to him, and several teachers mentioned how obsessed they were.) That market didn't exist before Minecraft.

In a similar vein, I spend a certain number of hours per week watching shows on Netflix, and I am certain that I could be persuaded to spend a big chunk of that time playing a game (for which I would gladly pay money). But it isn't one of my habits -- someone would need to find the sort of game I would enjoy and manage to let me know about it.

Here are some hints: since I am not your normal market I don't own the latest console nor do I own a fancy controller (but I CAN run Steam). I am not that excited about first-person-shoot-em-ups (if I were then I would already have gotten involved), but I might be interested in something more strategic. I am not willing to pay much up-front (since I don't know for sure if I'll really be into doing this) but I would be willing to spend money once I know that I like it, so long as I don't feel like I am being cheated (mandatory in-game payments or play-to-win often leaves me feeling that way). And most important of all, I do not read the indy gaming press or attend indy gaming conferences (since I am a NOT the existing demographic), so you need to reach me some other way -- probably through my friends, using some form of viral marketing.

The market for independent video games is small, but the market for entertainment is astonishingly large. (Plus, maybe your game can be something ELSE... educational perhaps?) The route to profit is to find a new (bigger) niche.

<comment><USER3> "The market for independent video games is small..."

Says who? You?

When I look at how many bands are out there slaving away to write new music, then touring, and/or making albums it doesn't seem nearly as out of proportion. How many bands with finished albums have you _never_ heard of? Compare with how many finished, polished games you've never even seen on Steam.

There might be a lot of games on Steam now compared to historical norms, but it's a tiny fraction of what you'd see with new books, new albums, or even new independent films.

The market for game-type entertainment is huge, and if people have an astonishing level of choice when it comes to how to spend their time, so much the better. We don't need indie games to hit the $100MM mark to be considered successful. Many developers would be happy if their game pulled down $10K.

We're used to games where you'd have to invest $50 and want dozens of hours of gameplay for it to be worthwhile. Now things are to the point where a $1 game only has to amuse you for a few hours and it's paid for itself.

The biggest problem in the indie game space is not the number of developers, but discoverability. The structure of stores, the methods used to promote them, they're all relics of when there was a handful of games that would get released any given month. These need to change to support a broader, more rich environment where you might have hundreds of them.

<comment><USER4> > Many developers would be happy if their game pulled down $10K.

That seems unlikely.

<comment><USER3> Not every developer is trying to make a million dollar hit. Many have jobs that make pursuing games as a full-time thing impractical.

Game jams like Ludum Dare ([http://www.ludumdare.com/compo/](http://www.ludumdare.com/compo/)) show that there are a _lot_ of people making games.

What I mean is there are some developers where if they make any money at all, it's a bonus. They're not in it for the money, and they're not doing it as a business.

For every developer that's serious and financially committed to making games there has to be at least a hundred that are far more casual.

</comment></comment></comment></comment><comment> guard-of-terra Discoverability is a huge problem. I would at any time want more turn based strategies in the triangle HoMM-Disciples-MoM, but it seems there aren't any? Even if there are, I can't discover them! Only thing that still can do is word of mouth.

I've scraped Play store for wargames and the best I got was a crappy game I did not run for the second time. I believe I paid for that.

Word of mouth is very irregular and app stores' charts are always full with "safe choices", i.e. either you know about this title already or it is a knockoff crap.

I would like to spend more on good games but I don't see much supply.

<comment><USER5> This seems like a good place to plug an ios game relased last week that I've been a long-time tester for, and which could do with some more word-of-mouth (or keyboard as it may be). It would be even more appropriate if was actually a turn-based strategy game like HoMM, but it might scratch your needs anyway.

Dream Quest ([https://itunes.apple.com/us/app/id870227884?mt=8](https://itunes.apple.com/us/app/id870227884?mt=8)) is a roguelike-dungeon crawler/deckbuilder. (Think of a cross between Dominion or Ascension and the dungeons in Shandalar, if you've ever played the old microprose game.) The game is really deep, very challenging, and produced by one guy working in his spare time. You have to be willing to accept the graphics as what they are, but the game can be addicting.

It's starting to get a little bit of notice (see [http://forums.toucharcade.com/showthread.php?t=228935](http://forums.toucharcade.com/showthread.php?t=228935) or [http://www.pockettactics.com/news/ios-news/actually-dream- qu...](http://www.pockettactics.com/news/ios-news/actually-dream-quest-looks- like/)) but it's all without any marketing budget, let alone art budget.

<comment><USER6> So close. Better:

"I know the itch you're trying to scratch. Do you mind if I email you a link to the game I've been testing?"

<comment><USER7> I don't think there's anything wrong with showing off projects on HN. We're all here to find interesting content. If the content is interesting and relevant, then creators should feel comfortable posting direct links for all to see.

</comment></comment></comment></comment><comment><USER8> I was doing some background research for another essay and this is as good a time as any to produce an actual journal article on point.

There's a common talking point I've seen both in this comment thread and elsewhere that the number of entrants isn't the problem at all and the _real_ problem is game developers aren't innovating, and if they just innovated more things would be fine.

Kevin Boudreau [1] is one of the earliest researches on this scene, who concludes that "incremental increases in the number of application producers in this context led to a decrease in innovation incentives, on average, as measured by the rate at which new versions of existing titles were generated" and further that "the strength of descriptive patterns alone suggests that marginal entrants curtailed overall innovation".

Kevin's research, while it has many limitations, suggests that innovation decline is actually a symptom of an overcrowded market, not an independent factor in its own right. If true, this could mean that the practical way to address an innovation crisis is to first solve the problem of the overcrowded market.

The idea that market crowding depresses the innovation of individual independent developers is sort of a surprising result, but once accepted there are many possible feedback mechanisms that may explain the effect. For example, market crowding may drive innovators to go innovate somewhere else. Crowding may also limit available funding which may be disproportionately required by innovative titles rather than non-innovative titles which can be more cheaply manufactured.

[1] preprint: [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=%20182670...](http://papers.ssrn.com/sol3/papers.cfm?abstract_id=%201826702)

jstor: [http://www.jstor.org/discover/10.2307/23252315?searchUri=%2F...](http://www.jstor.org/discover/10.2307/23252315?searchUri=%2Faction%2FdoBasicSearch%3FQuery%3Diphone%2Bsoftware%2Bengineering%26amp%3Bprq%3Diphone%26amp%3Bhp%3D25%26amp%3Bacc%3Doff%26amp%3Bwc%3Don%26amp%3Bfc%3Doff%26amp%3Bso%3Drel%26amp%3Bracc%3Doff&resultItemClick=true)

</comment><comment><USER9> I have been playing Jeff Vogel's games since Exile 1 in 1995, and I'm still playing them today with the Avadon series. He's a fantastic author and fantasy world architect, however I strongly disagree with his opinions on the game industry.

This is a guy who was selling a 20+ yearold game as a downloadable installer from his ancient website for $30 while new indie authors were pumping out new games on sale for $10, $5, or less. Who was making more sales, and ultimately more profit from this? Evidence it wasn't him: [http://www.shacknews.com/article/57308/valve-left-4-dead- hal...](http://www.shacknews.com/article/57308/valve-left-4-dead-half)

I think Jeff is a dinosaur, stuck in the 90s shareware era, and bitter that people can make more money by selling games for $3 than he can by selling games for $30.

<comment><USER10> In Jeff's case, I suspect that the low audio/visual quality of the games that he's been releasing since 2000 has been a significant factor in the weak reception he's seen them receive. Reviewers have been consistently dinging his games since _Geneforge_ in 2001, and he's still using the same game engine (and a lot of the same graphical assets!) in his current releases. Plainly put, his games look and feel dated.

Is graphical polish a make-or-break factor for games? Of course not. But that isn't a license to ignore it, either. "Lo-fi" graphics can be attractive as an intentional design choice, but that isn't what he's got, and I suspect it's turning off a lot of potential players.

</comment></comment><comment><USER11> Frankly, I've yet to see a truly stunning game pass me by, either in the indie space or on the App Store (where this problem has existed for a little while now). Market saturation causes mediocre games to become buried. The obvious solution is to not make mediocre games. I'm still convinced the cream will rise to the top.

<comment><USER12> I don't mean this snarkily: how would you know if a truly stunning game _had_ passed you by? If it'd been out for a long time before you heard about it? That wouldn't seem to account for the possibility of really great stuff passing _everybody_ by and never achieving critical mass.

<comment><USER13> Because we tried to look for them? I bought a gift card for my ipad and I have no idea how to spend it. Most games on it are _bad_ (I'm tempted to say all of them, but I liked The Room). Same thing for PC indie games (which is why Jeff's point is absurd, more games doesn't mean more sale, and if Humble Bundles are of any indication, indie's quality are _declining_ ).

But I'd love to be proven wrong.

<comment><USER14> On the iPad in particular, you might try [https://itunes.apple.com/us/app/10000000/id544385071?mt=8](https://itunes.apple.com/us/app/10000000/id544385071?mt=8). It's a mission-based real-time puzzle game. The gameplay is pretty enjoyable and you can clear stuff while dramatically under-leveled so it doesn't become too easy when you get good at it.

You could also pick up a CAVE game, but it would be by no means indie...

On the PC front I am familiar with more options, but it really depends on what you like. I play mostly shmups, puzzle games, and platformers, which happen to be really easy genres to make indie games in. Over the last few years I've enjoyed Jamestown, Thomas Was Alone, Electronic Super Joy, Antichamber, Super Hexagon, and a lot of games that are distributed for free in places like [http://www21.atwiki.jp/iwannabethewiki/pages/283.html](http://www21.atwiki.jp/iwannabethewiki/pages/283.html)

<comment><USER11> For anyone into CAVE-like games, please give Danmaku Unlimited 2 a try. One of the best shmups on the platform, beautiful, made by one dude.

</comment></comment></comment></comment></comment><comment><USER15> But still there are more new indie games than AAA titles out there I care about, it's not a tragedy if there only 2 to 6 outstanding games per year that reach me through the noise, mostly by direct recommendation.

The best thing about Greenlight is that pre-2005 games get some new exposure and even patches, like in the case of _Jets 'n'Guns_. So if you want to stretch the music industry analogy as others did, you currently not only competing with the ever increasing amount of new releases but also with back catalogs on the same platform.

Another problem with an awful lot of indie games (especially those 40% unplayed fillers games from bundles, which are not even always strictly speaking Indie) is that you can see that there was little to no user testing, so they are just not fun or even impossible to play on specific not too exotic configurations.

Just to name a few (each of these happened in at least two games):

      - no way to remap keys
      - no way to remap mouse buttons or game ignores windows swapped buttons
      - fixed resolutions
      - optimized for small resolution,
        resulting in insane mouse travel on today's native screen resolutions
        (just drop that retro stick if you just cant effort a proper artist please.)
      - no way to run a game windowed
      - touch optimized ports from Android don't even register windows touch events.
      - Content is cropped off screen
        with wider aspect radios with no way to change resolution.

<comment><USER16> All those quality issues are a big deal. Sadly, the industry (and customers) as a whole reject quality checks and validation.

Valve does less QA of steam releases than they used to (because this was a part of the reviled 'curation'), Microsoft and Sony have been forced to incrementally phase out certification checks (because developers complained constantly about the cost of those checks), etc.

The end result is utterly broken games go up on Steam and have to get pulled, and patches roll out on consoles that corrupt saves and do other nasty stuff like that. It's a mess.

On the bright side, this does increase access to storefronts, so the one or two marvelous games by people who can't afford cert or get the attention of Valve's curators are able to sell to their customers now. (Assuming they actually reach them, which hasn't actually gotten any better... that's gotten worse.)

<comment><USER15> Thanks again, if you did that _Escape Goat_ port for Steam, is a stellar example of a properly tested release.

Had much fun with it and works like a charm with the Xbox 360 Controller.

</comment></comment></comment><comment><USER17> I've been thinking recently about what makes a good video game experience for me, and it's slightly relevant.

I can place the games I've highly enjoyed into two basic categories:

-Short and sweet, having one or more of 1. interesting play mechanics 2. great story/theme 3. interesting art direction.

-Solid all around, with addictive elements (e.g. leveling, collecting things) that make repetitive tasks seem fun and extend the time I play the game to beyond a few evenings.

Many indie games I've played fit into the former category, and most non-indie games fit into the latter.

I've been realizing that these "short and sweet" games that I've been getting more and more of a chance to play have provided more lasting and fulfilling experiences than longer games. The feeling I get from sinking an evening into a short and sweet game is kind of similar to reading a good book or playing a good chess match. Likewise, the feeling I get from sinking an evening into a longer game is some artificial feeling of making progress.

I'm overgeneralizing a little, but the point is I've started skipping AAA titles in favor of trying out lots of indie games. Most aren't great, but the cost of a few dollars or less and a half hour to find out isn't bad. For me, it's worth it to find the gems. And not having several-week-long addictions to games with low quality:time ratios is great too.

I really hope there's no indie bubble.

<comment><USER18> There's a third category that I would put most of the games I enjoy into:

-Long and Deep: Games you can play for huge amounts of time but don't depend on an artificial sense of progress to do it. Strategy games, roguelikes, competitive games, etc. Games where you level up yourself by getting better, instead of the character in the game.

<comment><USER17> That's a great point. I play Nethack now and then, and I like how I can play it for an evening and then walk away, satisfied that I'll never beat it.

</comment></comment></comment><comment><USER19> The indie bubble isn't popping. It's an amazing time to be an indie developer, with massive audiences sitting around just itching to create millionaires.

The developers who are suffering are the ones who can't figure out how to get on top of markets, and especially the ones armed with obsolete "strategies" like being the only new game on Steam this month.

</comment><comment><USER20> Odd article.

It feels to me like the author is trying hard not to offend his community and ending up a ways off the point.

There can't be 'too many' games any more than there can be 'too many' websites or whatever else.

Too many is only relevant here because the indie segment has effectively been propped up on the good will of the community, not the quality of those games - with obvious exceptions.

This is a charity pie being sliced thin, not one made of value.

High-value products will always have a place in any market.

Second rate games have been skating by with issues or omissions that would see any major label release crucified simply because they were sporting the indie armband of immunity. Expecting to turn a profit, much less get rich with anything less than _" an utterly flawless, ground-breaking title and utterly blow everyone's minds."_ is the problem.

Forget the indie label and there's absolutely nothing new to see here.

<comment><USER21> I disagree, on multiple levels:

First, you can have too many. It's just like going to the grocery store to get tooth paste: the frustration of trying to decide the right one with 5000 choices is real, and it increases the likelihood of buyers remorse. That reduces real dollars spent.

Second, indie developers have not been charity cases. Over the past 30 years, there have been a lot of amazing indie games. There have also been a lot of crap games. Good games have made money because they were discoverable.

It is likely that amazing games will continue to thrive. The ones that will face difficulties are the good-to-really-good games. Those won't have the inertia to break out above the fog of the developer masses.

In other words, indie games are going exactly the same place App Store games did.

<comment><USER22> So if you're going to the store to buy toothpaste, and there's too many brands on offer, you're going to stop buying toothpaste and let your teeth rot? I'd file that under "unlikely". The paradox of choice means that you may be _less happy_ about your eventual choice, but you're still going to make it.

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

<comment><USER23> > The paradox of choice means that you may be less happy about your eventual > choice, but you're still going to make it.

I don't think this is true. Faced with a wall of indie games I will throw up my hands and go play Mario instead.

</comment></comment></comment></comment><comment><USER24> I disagree with the general sentiment.

 _> The problem is too many games._

That's not the problem. It's like saying that music industry is in crisis because there are tons of junk records around. Good music is always a minority and one has to sift through noise to get to it. Gaming isn't any different. Good games are a form of art, and they are always a minority, whether we are talking about indie and low budget or big budget / publisher funded games. That's why Steam may be a bad example, because filtering games there isn't easy. Services like GOG concentrate on _good_ games. That's of course subjective (according to the distributor), but they do a lot of pre-filtering for you.

 _> It's not sustainable._

It is, like any other art. Make something unique, make something good and you'll find your audience. Crowdfunding also helps to increase visibility.

<comment><USER25> There is absolutely no guarantee that you'll find your audience, and indeed the odds against doing so are increasing. For example: [http://lefsetz.com/wordpress/index.php/archives/2013/10/16/t...](http://lefsetz.com/wordpress/index.php/archives/2013/10/16/the- most-important-thing-you-will-read-all-day/)

 _Services like GOG concentrate on good games. That 's of course subjective (according to the distributor), but they do a lot of pre-filtering for you._

Which Steam did, a role which they have since abandoned. Why do you assume GOG will be any different? The day GOG's accountant proves irrefutably that it's more profitable to offer 20,000 shitty games than 200 good ones is the day they'll start doing that. That might not be for a while; as long as GOG's sales growth depends on differentiating it from other brands like Steam by being more selective. But eventually that growth will hit a plateau, and economics change.

 _It is, like any other art. Make something unique, make something good and you 'll find your audience._

You might, but there's no guarantee that you won't get lost in the shuffle. As Vogel points out, the problem is not so much for micro-producers with very low overhead, for whom even small sales are profitable, as for mid-sized ventures that have to invest $1 million+ to meet audience expectations and who will go broke if they can't recoup their production budget.

I really find your advice a bit facile. What branch of the arts do you work in?

<comment><USER24> _> There is absolutely no guarantee that you'll find your audience,_

Well, of course, there is always risk. What I meant is that if the game is not unique and not standing out, then the chances of success are way lower.

 _> Which Steam did, a role which they have since abandoned. Why do you assume GOG will be any different?_

Because GOG insists they will be. So far they were honest: [http://www.eurogamer.net/articles/2014-05-15-gog-on-early- ac...](http://www.eurogamer.net/articles/2014-05-15-gog-on-early-access- definitely-not-every-game-should-be-permitted)

 _> I really find your advice a bit facile._

My advice is based on viewing art as art, and not something that has to be specifically commercialized really. Indie developers are actually in the better situation here, because they can resort to crowdfunding which allows them making artistic choices based on interests, rather than on demands from the publisher. And it makes it easier because they don't have huge agreements to spend millions on marketing which they need to recover.

<comment><USER25> I have to tell you that things are very different when you're on the production side. It's easy to be idealistic about his sort of thing as a consumer, but if you do as a producer then you will go broke. And while one shouldn't be too cynical (otherwise you might just as well take up accountancy or some other line of work), it's a fact that consumers are a fickle bunch - they like novelty but not always originality.

I came across some good advice last week (aimed at designers, but relevant here): being 20 years ahead of your audience is not a recipe for success - people will just think you are strange. Being 20 minutes ahead, however, can pay off big.

For all their faults, this is something publishers understand well, and historically they have done a fairly good job of curating the authors they publish so as to support the ones that are a little too far ahead of the curve. They also look after a great deal of stuff that artists are either not good at or don't like, like marketing, accountancy and so on - so artists get to focus on what they do well rather than having to deal with the business stuff.

It's nice to think about art as being above commercial considerations, but being an artist doesn't get you out of paying rent or buying food or whatever family obligations you may have (which is why a lot of artists have precarious domestic arrangements). Even determinedly un-commercial firms like ThatGameCompany struggle with this; _Journey_ was supposed to take one year but took three, and they ran out of money and couldn't make payroll in the third year so they had to let some people go and make others wait months to get paid. You often can't ignore commercial considerations becuas if what you want to do needs money then either you raise it or the work doesn't get made. As I've pointed out in relation to film, the costs of making even a simple one are pretty substantial.

<comment><USER24> I agree that planning any project financially is important if it doesn't want to go bust in the middle, especially if it's big enough and isn't a "one man production". Still, more than often publishers simply reject something that doesn't fit the mass market mentality. Not because it's necessarily years ahead of time, and not because it can't be profitable. They just don't want to go to bigger length to achieve more, if they can profit with less.

A current example - inXile Entertainment (an independent gaming studio now) are still working on their major project Wasteland 2. It's already in beta access for a while, and they plan the release in the end of this summer. They said that what beta has now is only around 50% of the game (i.e. they'll add a lot more still). They took their time developing it and getting feedback and improving things (and they work in parallel on Torment - Tides of Numenera by the way). They said many times, that if their work would be managed by publishers, they'd never be able to develop Wasteland 2 so thoroughly and with their own pace as they do now. I.e. perfection is not something that publishers often appreciate (since it requires more resources). They prefer more projects in less time, than more _better_ projects with more time.

</comment></comment></comment></comment></comment><comment><USER26> tl;dr the indie space is more competitive than it was a few years ago and it's hard to get noticed

Well maybe that's not fair, but that's the impression I got from this.

That is very different from a "bubble" popping. The problem of discoverability will be solved by _someone_ \- there's just too much money on the table for that to not happen. Whether it's Valve or not no-one knows (obviously they're the front runners now), but someone will get it done.

Sure. It's probably a lot harder for the indie devs out there in a lot of ways (in terms of trying to stand out - or only getting a smaller and smaller slice of the market). On the other hand, there are tools like Kickstarter, Unity and now Unreal which make it much, much easier to make games - often for a wider array of platforms.

Harder to stand out, but lower barrier to entry - that makes sense and does not mean that any bubble is about to burst. In fact, it probably means that games will just continue to get better!

<comment><USER16> I'd like to agree with you that 'the problem of discoverability will be solved', but history doesn't bear that out. Discoverability has been _utter horseshit_ for PC games, iOS games and Android games... forever. And it's not improved at all, and no new players are improving it, because Steam, the iOS App Store, and Play Store all have customers 99% locked in. You can't force those big players to innovate unless they find a good reason to do it, because there's no way you're ever going to steal those customers away from them just by offering a better search tool. They want the convenience and safety and integration they get from the big player's storefront app.

The low barrier to entry for game development is actually not a new thing. The barrier has been low since the introduction of XBox Live Indie Games, perhaps even a couple years before then - that was just the visible point where a bunch of new developers started building and shipping games on a small budget.

The huge glut of samey titles releasing and squeezing each other out of the market is a relatively new occurrence. The stats he provided for Steam releases are a _very_ new trend and concerning to anyone who wants to find good games to play, or build good games to sell. I can say for a fact that the clickthrough rates and conversion rates for Steam front page placement are _much worse_ than they have ever been, even for high-scoring, well-reviewed titles with PR buzz.

</comment></comment><comment><USER27> You know, what really got me into indie games was that most of them had something unique and interesting to offer. They weren't all auteur works (although a lot of them were), but they generally felt like they weren't just made "to make a game", they were made because they had a reason to exist. There were definitely a lot of rough edges, but they were interesting. There wasn't the hegemony you'd see in AAA titles.

But... you don't see that so much in the indie scene now. Many of those games feel like they just exist because someone thought "I should make a game". There's nothing inherently wrong with that, but it's somewhat counter to the spirit that made the scene interesting in the first place.

I feel like a lot of indie games now capture the form but not the function. They look indie, but they don't really feel indie. I don't think there's an indie "bubble", I feel like the scene that had those values has moved somewhere else. Or if it hasn't, it will. We've always had a glut of mediocre games that didn't really make anyone much money (see: flash games in the mid oughts.) Same thing, its just the platform has expanded and the branding has changed.

<comment><USER28> Yeah. And as a guy with tastes that run awry from the "mainstream FPS" genres, I've been getting a lot of my gaming enjoyment from indies over the past few years. And the games with sticking power have always been the ones that are pushing the boundaries or trying something different.

Braid: Platformer where you can (and must) rewind time.

FTL: A roguelike where you command a ship instead of an RPG hero.

Monaco: A heist movie, as a top-down game.

Fez: Side-scrolling 2d platformer... in 3D! (where perspective changes are actually part of the platforming)

On the other hand, the ones I've enjoyed the least have wound up being less innovation, and more derivation. At least, according to my Steam library.

</comment></comment><comment><USER29> One of the assumed axioms of this argument is the the game industry is a zero- sum game, which it isn't at all in anyway. Now maybe it's not the flexibilist market and the low hanging fruit and easy stuff is much more saturated then it was a few years ago so it's certainly harder, but a bit the argument has some more give in it than it might be admitting.

</comment><comment><USER30> I think the model of X dollars / Y developers is wrong.

When I see a good game being sold by a good price I buy it. I only stop myself if I've spent a large amount recently, which so far only happened during some Steam sales.

This means my "gaming money pool" is not a pool at all because I may spend no money for months at a time, or spend a significant fraction of my salary in a week. If my behavior is as common as I believe it is, this completely invalidates the model of X dollars / Y developers and paints a much less bleaker picture of the future.

</comment><comment><USER31> I think others have mentioned this already, but this is a problem that faces almost every industry these days. How do you get your product noticed? Why is advertising the fuel of the web? Competition. There are 10 versions of exactly the thing the buyer is looking for and 10,000 other things that are almost what they are looking for. Those 10,010 different sellers are all trying to capture that sale.

There are many different information channels that companies can try to use to get the word out. Without having done an actual study myself (though I'm sure someone has) I would guess that if you can trigger a word of mouth or viral campaign they end up being extremely effective. Furthermore if I had to guess if you can get the attention of one of the 'hubs' (a respected member of a community) in a social network to endorse or mention you, there is also a huge payoff.

Search and algorithms is one way to approach the problem, probably 'the new way.' Maybe some day we will have AI agents that know us so well that they can search through the morass of content and products and find things that will actually enrich our lives, but for now we're still monkeys that respond strongly to social cues and our algorithms suck and are easily gamed (star ratings) or are extremely time consuming (reading tons of reviews). So we go find an expert or someone we trust.

</comment><comment><USER32> > How many times last year did we see the article, "Another 100 Greenlight > games OK'ed for publishing!"?

Why are console games still being "OK'ed for publishing"? Why haven't any of the big names (Steam/Xbox/PlayStation/Nintendo/Apple) released a true "app store" where _anyone_ can get a game into the store for maybe $100 and after going through a light content review process?

<comment><USER33> > _Why haven 't any of the big names released a true "app store" where_ anyone > _can get a game into the store for maybe $100...?_

This seems like an interesting model. Charge developers a flat fee (FEE) up front. Take a cut of each sale (PER) as well, but only after (FEE/(COST*PER)) sales have been made. For example, using a fee of $100 and a percentage of 20%, the first 500 sales of a $1 game would see all of the money going to the developer. Thereafter, the store would take 20 cents for each sale.

This model seems like it would encourage developers to only submit games that they deem to be high quality. Players would have less shit to wade through, giving them more incentive to try out new games.

Perhaps $100 is not high enough to achieve this goal, but I bet there's an ideal number that discourages low quality submissions while leaving the door open for small-time developers.

<comment><USER34> I'll go with $1000. If you want to _waste the time_ of millions of steam users, putting something in front of them and taking up precious space in the "new" queue, then you should have some minimal level of confidence in what you've built.

Same thing goes for the App Store. I don't bother browsing Steam or the App Store any more. It's all just crap. The first ten, the first hundred, the first _thousand_ retro games might have been interesting, but no longer.

If Valve wants to turn Steam into the Dollar Store, I guess that's their business. Apple's App Store is already there.

</comment></comment></comment><comment><USER35> Video games are joining the same ranks as books and music. The barrier to entry for creating a video game is dropping. Libraries are getting better and programming is getting more ubiquitous.

Video games are on track to be as difficult to publish successfully as books and music (and perhaps movies). If you aren't a big budget, it's very rare that you'll enter mainstream. The expectation is going to stop being that video games are a vehicle for profit (just like being an author is not typically considered a vehicle for profit).

</comment><comment><USER36> > X dollars, Y developers. That's all that matters.

That assumes the indie market is a only feeding on its existing audience. Minecraft's money didn't come at the expense of indie developers; it came from EA and Sony and the other big publishers.

I don't dispute the rest of his thesis, but that "X" is big enough for all "Y" of the indies to pay their rents for a long time if divided evenly.

I think the quality problem, the discovery problem, and "alpha fatigue" from games that are never finished are bigger issues.

</comment><comment><USER37> Totally unrelated, but how does this post rank so low on the HN front page? 84 points in 2 hours is huge ... but its at number 22 right now. Has something happened to the HN rank algorithm?

</comment><comment><USER38> I don't think the problem is money vs games (the X and Y) the problem is time vs games. I have enough money to buy all the games I want and don't want to play, most of them are very cheap in bundles and promotions, I just don't have time to play all of them (I'm talking more about pc/console games, not mobile ones). There's only so much games you can buy and not play before you start thinking about not buying anymore and focus on the ones you really want to play.

</comment><comment><USER39> Steam is currently being flooded with "Casual" mobile app ports it remains to be seen if they actually sell, I have yet to see one on the top sellers list after release. I would hardly call that a bubble. Good indie games will continue to make money.

</comment><comment><USER40> The state of gaming blows. Today's platforms pigeonhole the consumer and developer to being unhappy. Casual gaming is flooded, but there is always money for core gamers to spend on a quality product especially original and innovative indie games.

</comment><comment><USER41> The good news is that these things always go in cycles. The ones that can weather the downturn will be the big winners on the other side.

</comment><comment><USER16> This comment thread is filled to the brim with arguments that either demonstrate a lack of familiarity with video games (excusable, but...) or regular old weak thinking.

A few variations on this core theme:

"The cream will rise to the top"

"Good games will find an audience"

"Create something truly special and you will be successful"

These lines of thinking are all COMPLETE AND UTTER NONSENSE. I would love to live in a world where those statements were true, but they are not. They have _never_ been true in video games, even if they are perhaps true in other industries. Anyone with any experience observing games development, sales and marketing knows that these statements are false.

The vast majority of successful game titles are successful as a result of a finely-tuned marketing and sales pipeline.

The big studios have their own pipeline for this: Paying staff to contact the news outlets and YouTubers, paying to run television advertisements or put up billboards, doing co-promotional deals (like bundling the Battlefield 4 beta in with another game, etc), advertising their new games via popups in older games, buying installs to climb the app store rankings, etc.

Smaller developers can't use the big studios' bag of tricks, so they use their own: Forming industry connections, so that developers and other people with big audiences promote the game to their audiences. Building name recognition and dedicated fanbases by shipping lots of games (Jeff Vogel is a textbook example of this - decades of releases!). Building dozens of cheap games and releasing them to try and find something that fans like. Cashing in on the latest trends and buzzwords in order to get good returns. Slaving away for no pay for months or years, killing yourself to make a 'masterpiece'.

Note that many of the above tricks are _not_ guaranteed to work. Some of the highest-profile 'indie successes' in the past few years have actually had poor sales or poor revenues, when you examine their budget. In some cases this is due to actively being undermined by the storefront. Microsoft has a track record of undermining big releases on XBLA by scheduling them at poor times, dropping them from the front page, and otherwise leaving them to die. Some of the other big publishers do this too - Electronic Arts sank a ton of money into Starbreeze's new Syndicate reboot, then spent nearly nothing marketing it and it languished in a pit along with all the other FPSes - even though it's actually a quite solid game from a studio with a great pedigree (reviewers agree).

Here's the reality of building and selling video games:

Building video games is expensive. It probably costs more time & money than you realistically have.

Selling video games is difficult... and expensive. You often have to sink as much time/money into selling your game as you do in building it - lots of contract reviews/negotiation, along with lawyers' fees, time spent prepping builds for each storefront and building storefront/platform-exclusive content (steam workshop, achievements, etc).

Making it possible for players to find your video game is difficult... and expensive. You sink tons of time/money (often over the whole duration of development) reaching out to journalists, youtubers, genre fans, previous customers, and random strangers. You spend money on booths at conventions like PAX, buy banner ads on game-focused websites, build a mailing list, etc.

Even after all this, factors entirely outside your control _will_ fuck you. Your game will get pirated, Steam's checkout flow will break during your launch week, a crippling bug found on launch day will undermine your sales, or market forces will simply shift and leave your game stranded in a market players aren't interested in anymore. Sometimes another developer literally swoops in under you, clones your game outright (based on all that marketing and outreach you've been doing), and steals a huge chunk of your market. This has happened to Vlambeer _multiple times_ and has happened to other big-name indies (Spry Fox, for example).

People interested in dropping some lazy truisms like 'just work hard and build something awesome' are doing themselves a disservice and lowering the level of discourse. There are hard problems here, and many of them are not actively being solved. Some of the problems are _within_ the industry, and mean developers need to make better choices. Some of them are the industry's machinery, with storefronts providing inadequate discovery and unreliable sales pipelines. Some of them are playerbase issues, where players tend to chase after novelty and hot trends (I want a minecraft clone! I want a zombie game!) and don't have discerning tastes.

Many of these problems aren't any one person's fault, they're just problems we have to fix. But nobody is going to fix anything if we keep plugging our ears and yelling "EVERYTHING IS FINE!"

<comment><USER24> Counterexample: [http://papersplea.se](http://papersplea.se)

Quite a successful game in my view, developed by one person without some insane marketing or anything the like. Very original and creative, which helped it to find its audience.

Trailer: [https://youtube.com/watch?v=_QP5X6fcukM](https://youtube.com/watch?v=_QP5X6fcukM)</comment></comment>


Git from the inside out - <AUTHOR> https://codewords.recurse.com/issues/two/git-from-the-inside-out <comment><USER2> > from inside out

As a physicist it always surprises me how thinking between physicist and programmers most of the time is kind of reversed. Most git tutorials seem like this to me (Mechanics analogy):

       1. Slopes
       2. Springs and gears
       3. Horrendous contraptions
       4. Ropes and pulleys
       ...
       9. Newton I., II. and III.

These kind of "inside out" tutorials are natural for me and recently I taught git basics to my SO in a similar way. It worked out well (she is a physicist too). I don't want to generalize though, it's maybe rooted in the common ways of teaching programming and physics.

<comment><USER3> Imagine if everyone learning physics came in with an attitude of "I need to learn and use the rocket equation as quickly as possible" (or substitute some other high-level problem for "the rocket equation"). You'd end up with strange backwards tutorials for physics that start out with that specific model, then a handful of related models, then how to abuse that model to handle things it doesn't really apply to, and much later the underlying physics and mathematics to solve arbitrary generalized problems.

Many people start out trying to figure out either "how do I use git exactly like (svn, cvs, vss, ...)" or "how do I commit and push my changes", so tutorials start there. Most people don't approach git by learning its underlying data model. Arguably people should, because it's a rather simple data model, and then all the commands become simple applications of that model.

<comment><USER4> Most people don't start learning Word by understanding the data structures used to store the text and modifications either.

For 95% of developers, git is a tool that is incidental to their primary task (developing software). Having to have a deep understanding of the underlying data structures in order to use it effectively is the antithesis of how most "utility" software is designed.

When I am in the flow of coding some part of my project, my head is full of the data structures, object models, databases, algorithms, requirements, etc. that are immediately relevant to that task. If I have to do a context switch and pull the git data model front and center into my thinking to know what to do to get my work into the repository, that is a serious break in flow and has always been a problem for me whenever I've had to use git.

<comment><USER5> > Most people don't start learning Word by understanding the data structures > used to store the text and modifications either.

And, there should be a warning when your document gets above 5 pages long that you should learn the structural sides of the program at hand. Unless you like spending your weekend crafting a TOC line by line.

<comment><USER6> The world would be a much sadder place if that was the case. I do not understand how the infrastructure that powers world trade, banking, public construction etc works. I am grateful that they are packaged into easily understandable interfaces so I can still benefit from them.

The power of technology is compounded when it can empower even non- technologists to use it. The more sophisticated tasks they can accomplish with it, the better.

<comment><USER5> It's a double edged sword. By crafting interfaces so simple anyone can use it, we forbid them to understand what's really happening. That's how people end up thinking the blue 'e' icon on the screen is Internet.

<comment><USER7> But is 'forbid' really the right word here? I certainly agree that such interfaces _encourage_ people to "accept without questioning", but it seems that there is no necessary obstacle to making something that's easy to use but also permits you to dive under the hood and see the details. (I think particularly of Mac OS before it started becoming all iOS'd. Even now, when Apple's 'just work'ing settings don't just work for you, you can often fix it by diving into the command line.)

<comment><USER5> You're right forbid isn't appropriate.

IMO, no actual mainstream OS gives ability to understand anything, even UNIX based. And I don't believe command lines are a way to understand either, or a very low efficiency one (gotta read a lot, understand complex context, try mistakeful commands).

You need virtual, mockable, undo-able environments to understand. You need ways to decode the data and metaphors used by computers.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> Regular pitch for [http://www.sbf5.com/~cduan/technical/git/](http://www.sbf5.com/~cduan/technical/git/)

> you can only really use Git if you understand how Git works. Merely > memorizing which commands you should run at what times will work in the > short run, but it's only a matter of time before you get stuck or, worse, > break something.

It's concise (the linked article is gigantic) and allows for an understanding of this overhyped user hostile DVCS. I know that git won but don't expect me to be happy about it.

<comment><USER9> What alternative do you prefer?

<comment><USER8> bzr. The CLI interface is much nicer and consistent. It has bound branches which is really useful useful when you are doing something small (see bsder comment above). You are not forced to use a staging area. There is no need to squash commits just to have a clean history instead you commit what you have and limit the depth of the log on view. Also, bzr is really easy to extend in Python. And so on and so on.

The git command line interface is the exact opposite of user friendly: some commands have options that fundamentally change the operation so much so it should be a different command: git reset removes changes from the index leaving your files intact and if you do not have anything staged then does nothing. Now, git reset --hard simply throws away your changes. This does not end here: git reset 'HEAD^' will remove a commit. How mad is that, git reset operates on the staging area but git reset something operates on commits??

git checkout filename is almost completely unpredictable as it might get the file from the index if it exists there or from HEAD if not. There is no indication at all what happened. And so forth.

<comment><USER9> Interesting, I've not ever seen a recommendation for bazaar over git or mercurial. I have heard that mercurial's CLI is a bit more sane than git, and I've also read that it's easier to extend in Python. How would you compare bazaar to mercurial?

I've actually only ever used git for professional and personal development, but I think I'll want to play around with both mercurial and bazaar now. Git's CLI is definitely a bit of a PITA.

I find this video summarises git's frustrations pretty well :) [https://vimeo.com/60788996](https://vimeo.com/60788996).

<comment><USER10> Bazaar is basically unmaintained at this point. If you look on Launchpad, the trunk branch hasn't seen a commit since December 2014 [0]. There hasn't been a release since August 2013 [1].

Mercurial is very actively developed, with dozens of patches a month [2]. They also keep to a planned rolling release cycle [3] along with deep commitments about backward and forward compatibility [4].

New features like the experimental evolve extension [5] are also really cool. I use it for day-to-day work and find it incredibly useful for editing work- in-progress commits into nice self-contained patches.

[0] [https://code.launchpad.net/bzr/trunk](https://code.launchpad.net/bzr/trunk)

[1] [https://launchpad.net/bzr/](https://launchpad.net/bzr/)

[2] [http://selenic.com/pipermail/mercurial- devel/2015-March/thre...](http://selenic.com/pipermail/mercurial- devel/2015-March/thread.html)

[3] [http://mercurial.selenic.com/wiki/WhatsNew](http://mercurial.selenic.com/wiki/WhatsNew)

[4] [http://mercurial.selenic.com/wiki/CompatibilityRules](http://mercurial.selenic.com/wiki/CompatibilityRules)

[5] [http://mercurial.selenic.com/wiki/ChangesetEvolution](http://mercurial.selenic.com/wiki/ChangesetEvolution)

<comment><USER8> Yes. git won, bzr is dead. As I said: I am aware and I switched to git because everyone else did. Just don't expect me to be happy about it.

<comment><USER10> I'm trying to say if you want a git alternative that's not dying and isn't infuriating, check out mercurial.

<comment><USER8> I can't, the world (open source projects and work both) is using git.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> See also "Git from the Bottom Up": [https://jwiegley.github.io/git-from-the- bottom-up/](https://jwiegley.github.io/git-from-the-bottom-up/)

(originally a PDF in 2008)

<comment><USER12> Much better article IMO. Introducing the low level commands that the higher level ones wrap around is a much more fun and interactive way to understand the .git schema to me.

</comment></comment><comment><USER13> Wish `git` didn't have annoying special cases in it. For instance

       git rebase -i HEAD~2

won't work if there are only two commits, because HEAD~2 refers to a nonexistent commit after the first two.

There should be some friggin' NIL terminator there which takes the HEAD~2 reference.

Imagine having a function to, say, delete characters from a string which takes an open-ended range [from, to). Then imagine that the index to has to exist in the string; it must not point one element past the end! Oops, you cannot delete from a position to the end of the string.

The garbage-collected object graph is nice and "Lisp-like" in some ways, but silly in others.

Oh, and in case you're thinking "just make an empty initial commit, and it will effectively be your NIL terminator". No can do; git doesn't allow empty commits. Of course, you can make a file called ".nil" and add it and commit. Use "()" as the commit comment. :)

<comment><USER14> I feel like the lack of an initial empty commit is really a failure to match the intuitive graph model. Clearly there should be an arrow corresponding to "adding the first files". And that arrow needs somewhere to go _from_ and _to_. Hence, `git init` should always start by creating an initial commit object referring to an empty tree.

A side bonus of this would be that since the initial commit is empty it has a fixed id. Suddenly, all git repositories have a common ancestor, and you can merge any two random projects together without losing history!

<comment><USER13> I echoed this exact idea in another comment in the thread, right down to that commit having a fixed ID. (I proposed the all-zero SHA (which is not really a SHA)).

</comment></comment></comment><comment><USER15> For grokking git, indispensable resource is git early dev mailing list and corresponding code base (first couple of months after project started). Linus explained it in very clear and precise way in the mailing list and related code. The initial code base is surprisingly small (around 1200 LOC of clear and precise C code). Used data structures are simple and self-explanatory. Although most of the original code is not in the git code base anymore, the data structures and main design ideas have stayed there intact so far.

<comment><USER16> I'm going to have to go through the archives later (anyone got an mbox?) but it's tricky to follow the early development. The archives seem to start at [http://marc.info/?l=git&r=20&b=200504&w=2](http://marc.info/?l=git&r=20&b=200504&w=2) and I don't see many design messages from Linus.

</comment></comment><comment><USER17> Interesting article.

Also wasn't aware that Hacker School changed their name.

[https://www.recurse.com/blog/77-hacker-school-is-now-the- rec...](https://www.recurse.com/blog/77-hacker-school-is-now-the-recurse- center)

<comment><USER18> Don't worry you aren't very far behind the times. It was announced yesterday.

</comment></comment><comment><USER19> Huh, another git explanation.

Either the thing is so easy to understand that everyone can do it and is then compelled to write about it, or it's so difficult to understand that everyone feels the compulsion to explain it to everyone else.

<comment><USER20> Maybe a quip, but that dichotomy is so false it's not even funny. Git is tough to wrap one's head around at first. It's not intuitive unless one already has a deep background in this space. Hence, there are lots of attempts to explain it in order to bring more into the fold of intuition. It seems perfectly natural and good, and your contemptuous tone puzzles me.

<comment><USER21> Right. It's _simple_ but it's _unfamiliar_.

Confusing command parameters aside.

</comment></comment></comment><comment><USER22> >"This essay explains how Git works. It assumes you understand Git well enough to use it to version control your projects."

so...the opposite of Bjarne Stroustrup's maligned "The C++ Programming Language", which fails to explain how C++ works, after assuming you don't know it. :)

seriously though no need for the second sentence. this article is a great intro!

</comment><comment><USER23> Footnote 3: git prune deletes all objects that cannot be reached from a ref. If the user runs this command, they may lose content.

In what cases would a user lose content? When something is added but not committed only?

<comment><USER24> When you've committed something, but then rebased or reset the branch position so the commit is not longer in the history of any branch or tag. This usually isn't a problem, because when you rebase work you are making a copy of the commit so references to the data should be the same.

I also think it's worth noting, `git gc`, which is triggered automatically occasionally, actually runs `git prune`.

</comment></comment><comment><USER25> What tool did the poster use to create the diagrams?

<comment><USER26> OmniGraffle. I really enjoy using it.

</comment></comment><comment><USER27> A great title would have been: The Guts of Git.

<comment><USER28> Already taken: [https://lwn.net/Articles/131657/](https://lwn.net/Articles/131657/)

</comment></comment><comment><USER29> I regular read articles about Git's inner workings and I always seem to forget it. :-(

</comment><comment><USER4> Yet another attempt to explain the incomprehensible.

Why does such a popular version control systems find itself in need of so many explanatations.

Any startup attempting to market something that required a user to understand concepts such as this...

[https://codewords.recurse.com/images/two/git-from-the- inside...](https://codewords.recurse.com/images/two/git-from-the-inside- out/24-13.png)

...would be laughed out of the room in any other context.

<comment><USER30> Git isn't exactly a startup (or a company, or even a product), nor did it ever intend to be.

Lots of great software happens to be difficult for a lot of people to intuitively understand.

<comment><USER31> > _" Lots of great software happens to be difficult for a lot of people to > intuitively understand."_

For real. Maybe it is just me, but I find programs like Photoshop and nearly every CAD program I've ever encountered to be bewilderingly complicated. I don't use any of those sorts of software professionally, but have found myself needing them numerous times for hobby reasons. Every time I try to learn them I become frustrated with just how steep _and tall_ the learning curves are.

Git though? I felt pretty confident with how it worked and basic command line operation after just a weekend.

Maybe git's command line is more inconsistent than hg's or subversions', but in the grand scheme of software difficulty? I just don't get the complaints. _" Incomprehensible"_? Give me a break. It does not hold a candle to most _commercial_ professional software.</comment></comment></comment>


Hackpad source code - <AUTHOR> https://github.com/dropbox/hackpad <comment><USER2> There's a good thread on Hackpad's waaaay premature announcement that they were open sourcing their code on the original hackpad/hackpad repo: [https://github.com/hackpad/hackpad/issues/1](https://github.com/hackpad/hackpad/issues/1). Wonder what the story is and why the actual release was so delayed.

EDIT: Spelling and grammar

<comment><USER3> They fired the guy who made them open source and held the release until their Notes product was ready.

<comment><USER4> I can only confirm this via a throwaway for lots of reasons, but this is correct.

Note: I am not Alex.

<comment><USER5> > Note: I am not Alex.

Likely story. :)

</comment></comment></comment></comment><comment><USER6> Nice of them to put it there. Two points.

1\. My confidence in the continued existence of Hackpad is falling by the day and it saddens me as it is where I keep all my stuff.

2\. I really would like to get access to the Dropbox Notes beta to see if it is a direct continuation of Hackpad. Seems it is almost impossible to get access to it though.

<comment><USER7> Notes is really good. It just saddens me that Dropbox does not base those systems on top of Dropbox but somewhere separately. I wish I could just get .md files or something similar in my Dropbox from what's on notes.

<comment><USER8> What about using something like Notational Velocity / nvAlt (which will keep your notes on Dropbox, and has mobile clients available too)?

<comment><USER9> Writeily Pro is an awesome Android app, and open source. It can save its files to any directory on your SD card, so as long as you get that directory syncing, you're good to go. ie. it's sync service agnostic

[http://writeily.me/](http://writeily.me/)

</comment></comment></comment></comment><comment><USER10> Signing in with Google requests to view your contacts. Come on, really?

<comment><USER11> Hmm. Not only do they make unnecessary, irrelevant, and generally overreaching demands on your privacy, but you get modded down for objecting to it. Sounds like a great product. Where do I sign up?

Absolutely nothing makes me reach for the back button faster than a "X requests access to Y" notification that doesn't explain _exactly_ why X needs access to Y, and what X will do with its newly-granted access.

<comment> bmir-alum-007 For ephemeral collaboration, just use an semi-anonymous EtherPad fork like PiratePad.

[http://piratepad.net/](http://piratepad.net/)

<comment><USER12> Or if you want an anonymous pad with video chat, [http://snapmeet.io](http://snapmeet.io)

<comment><USER13> That's not anonymous. It talks to cloudflare.com, bootstrapcdn.com, fonts.googleapis.com, mxpnl.com and cloudfront.net in addition to snapmeet.io. None of the connections are over https and there's probably quite some cookie sending and fingerprinting involved.

</comment></comment></comment></comment></comment><comment><USER13> Similar projects exist that use OpenDocument Format as the underlying file format.

[https://github.com/adityab/Manticore](https://github.com/adityab/Manticore) [https://github.com/kogmbh/kotype](https://github.com/kogmbh/kotype)

</comment><comment> bmir-alum-007 Another cool, live EtherPad fork which has existed for a long time (anonymous pads, w/o source): [http://piratepad.net/front- page/](http://piratepad.net/front-page/)

<comment><USER14> another one is [http://meetingwords.com/](http://meetingwords.com/)

</comment></comment><comment><USER15> Wonder if there are any improvements here that could be pulled back into the open source Etherpad-light?

</comment><comment><USER16> Hackpad is wonderful. We use it as a quick tool to discuss our ideas. It's more readable, gives a proper track of changes, and is effective. Having known that it has gone open source makes feel even better.

However, didn't Dropbox bought Hackpad earlier ?

</comment><comment><USER17> clicking "Take a test drive" link on hackpad main site results in "Refused to execute inline event handler because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-inline' " in Chrome

</comment><comment><USER18> Interesting still based on the original Etherpad rather than Etherpad-lite which is actually based on Node.js and works much better.

Etherpad-lite has a lot of interesting plugins.

</comment><comment><USER19> This was open-sourced a while back. Looks like they hollowed out the repo though. Is that bad etiquette?

[https://github.com/hackpad/hackpad](https://github.com/hackpad/hackpad)

<comment><AUTHOR> That repo never had code in it.

<comment><USER19> That's what it looks like

</comment></comment></comment><comment><USER20> I want to turn this into a mac app. Was not expecting java.

<comment><USER21> So Dockerize it and have the data backed up to an S3 bucket. Then you'd just docker pull, start the container, and surf to it locally.

<comment><USER20> Ya, i'll definitely be exploring. I always loved hackpad, but didn't use as much as I would if it was a native note taking app (like JustNotes which I use)</comment></comment></comment>


Why Apple has stopped making small phones–and why it should start again - <AUTHOR> https://arstechnica.com/gadgets/2020/04/why-apple-has-stopped-making-small-phones-and-why-it-should-start-again/ <comment><USER2> A small phone with a battery that lasts for several days would be a nice option.

<comment><USER3> That once was a thing.

[https://cdn.store-assets.com/s/217969/i/11059050.jpeg](https://cdn.store- assets.com/s/217969/i/11059050.jpeg)

Light enough for your shirt pocket.</comment></comment>