Idiomatic Redux: Implementation and Intent - <AUTHOR> http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ <comment><USER3> Whenever a Redux thread pops up, there's inevitably complaints about "boilerplate". I'd like to pre-empt those complaints a bit by pointing out that, per part 2 of my post, it's entirely up to you how much abstraction you use in your own Redux app. If you want use Redux for a particular use case, someone has probably already written an addon or utility to help solve that problem, and I've got them listed in my Redux addons catalog [0].

If you don't want to edit multiple files, use the "ducks" pattern to put actions and reducers in a single file [1]. If you don't like writing action constants by hand, use one of the dozens of action/reducer generation utilities out there [2] [3]. If you don't want to manage normalized data by hand, there's many addon libraries to help with that [4]. I specifically show off one of them, Redux-ORM [5], in my "Practical Redux" tutorial series [6].

I love all the tools and addons that people are building on top of Redux. One of my favorite quotes is from a Redux issue thread:

> Redux is a generic framework that provides a balance of just enough > structure and just enough flexibility. As such, it provides a platform for > developers to build customized state management for their use-cases, while > being able to reuse things like the graphical debugger or middleware.

A few months ago I opened up a Redux issue thread to discuss further ways that we could help make it easier for people to use Redux, and solve complaints about "boilerplate". The discussion kind of trailed off, but I would love to have more discussion and ideas for building useful new tools on top of and around Redux to help people solve problems and build useful applications. Please join the discussion here: [https://github.com/reactjs/redux/issues/2295](https://github.com/reactjs/redux/issues/2295)

[0] [https://github.com/markerikson/redux-ecosystem- links](https://github.com/markerikson/redux-ecosystem-links)

[1] [https://github.com/erikras/ducks-modular- redux](https://github.com/erikras/ducks-modular-redux)

[2] [https://github.com/markerikson/redux-ecosystem- links/blob/ma...](https://github.com/markerikson/redux-ecosystem- links/blob/master/action-reducer-generators.md)

[3] [https://github.com/markerikson/redux-ecosystem- links/blob/ma...](https://github.com/markerikson/redux-ecosystem- links/blob/master/reducers.md)

[4] [https://github.com/markerikson/redux-ecosystem- links/blob/ma...](https://github.com/markerikson/redux-ecosystem- links/blob/master/entity-collection-management.md)

[5] [https://github.com/tommikaikkonen/redux- orm](https://github.com/tommikaikkonen/redux-orm)

[6] [http://blog.isquaredsoftware.com/series/practical- redux](http://blog.isquaredsoftware.com/series/practical-redux)

<comment><USER4> Mobx is an alternative. Simple and less boilerplate.

<comment><USER5> This comment is always the first, every time, but they're both very different. Mobx is mutable binding, redux is one way, functional data flow. They have their tradeoffs, but when I look at mobx I get reminded of managing crazy state trees in ember and why I went to react/redux in the first place. YMMV.

<comment><USER4> The crazy state tree in redux is what made me go to mobx. I had events firing off updating multiple redux functions. It was very difficult to understand the flow. Mobx has simplified my changes to one place. To me they both the same managing client side state.

<comment><USER6> Mobx vs redux is probably not the right comparison here though. Mobx comes bundled with 'computed' and encourages most state to be handled there.

Redux doesn't have this, instead libs like reselect fills space.

My experience with redux was frustrating in the way you explained, but once I "got" how to defer all state to reselect instead of trying to do things with reducers it got significantly simpler.

<comment><USER4> My frustration wrt redux was organising the file structure where to place actions reducers. Otherwise it was a joy to work with. I considered it very simple and easy to work until I found mobx.

<comment><USER3> The two typical approaches are "file-type-first" (separate folders for "actions", "reducers", "containers", etc), and "feature-first". I've got articles discussing various React/Redux project structure approaches at [https://github.com/markerikson/react-redux- links/blob/master...](https://github.com/markerikson/react-redux- links/blob/master/project-structure.md) .

<comment><USER4> I have done both approaches, ducks, slight variation on ducks all running on production apps. Still not satisfied.

I have referred your links. Thank you btw.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER3> Hey, that's my post! :) Actually submitted this to HN previously, but didn't get any traction. Ah, the fickleness of upvotes :)

Spent a lot of time researching for this post. What I really _wanted_ to write was the second half of Part 2 [0], where I gave my opinions on why certain usages are good ideas or bad ideas, but I realized I needed to cover a lot of background before I got there :) Was really cool reading through the original discussions and seeing the vision Dan and Andrew had for Redux from the beginning.

Hopefully this pair of posts helps clarify a lot of the discussion around Redux and its common usage patterns. Also, I'm always happy to answer questions about Redux (and React) usage, and encourage people to come by the Reactiflux chat channels on Discord [1]. Always a great place to learn and ask questions about React, Redux, and related technologies. Finally, if anyone is interested in learning React or Redux, I keep a big list of links to high- quality tutorials and articles on React, Redux, and related topics, at [2]. Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics.

[0] [http://blog.isquaredsoftware.com/2017/05/idiomatic-redux- tao...](http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux- part-2/)

[1] [https://www.reactiflux.com](https://www.reactiflux.com)

[2] [https://github.com/markerikson/react-redux- links](https://github.com/markerikson/react-redux-links)

<comment><USER7> Congrats Mark! :)

</comment></comment><comment><USER8> This article serves only to reinforce that the beautiful simplicity of react is spoilt by the confusion of Redux.

I feel that every Redux blog post should start by pointing out that despite react/Redux almost being discusssed synonymously, as the author of Redux points out, "you might not need Redux".

I would go further and say "avoid Redux until you know you need it", and point people to more simple ways of reaching the same goals.

Redux is a power tool for experts that is disheartening beginners and sending them down the wrong path.

I was speaking to someone recently who had tried Reactjs. I wanted to enthuse with him about how awesome it is. He said it was too hard and he went with vuejs instead. When I questioned him further it became apparent that he had started to learn react/Redux and gave up in confusion.

<comment><USER9> >Redux is a power tool for experts that is disheartening beginners and sending them down the wrong path.

I've seen this expressed many, many times, and it is something that I've honestly never quite understood. I started with React less than a year ago, and it wasn't until I added Redux to my stack that I began to feel perfectly comfortable with,

To me, the fact that actions dispatched in whatever component would cause the global state to be recomputed which then got handed to react to render it just a no-brainer. This truly makes data in React flow just one direction. The tooling around it -- Redux DevTools -- also made seeing my app in action and debugging it so incredibly clear.

Without it, for me initially it was a struggle about where exactly to store certain state, and passing props and callbacks up and down all over the place. It wasn't clean or easy to reason about at all.

As someone who had very limited experience in the framework, Redux felt like a tool which made the pit of success for me pretty darn large. I do know that even Dan himself has suggested that people not learn them in conjunction, but to me, the coupling of them is so perfect that React only became a joy to use WHEN I introduced it.

<comment> hacker-gene > I've seen this expressed many, many times, and it is something that I've > honestly never quite understood.

Well, if you're coming in from a non-FP background, learning Redux is intimidating. I'm a aspiring web developer (I'm coming from tech support role and my programming skill is mostly bash and bit of Python) and started looking into Redux, and yay struggled with getting started.

      const store = createStore(reducer)

Took me hundreds of console.log ('entering func blah blah') before I realize out that those reducers become properties of the object store. So yes, Redux is power tool for expert and not as nearly accessible to your average neighborhood web developer.

<comment><USER3> I'd be very happy to discuss any pain points or particular problems you've run into trying to learn Redux, and any suggestions you might have for improving the docs to make it easier for others in the future. Please feel free to ping me on Twitter, or in the Reactiflux chat channels.

</comment></comment></comment></comment><comment><USER10> The article does a great job of presenting Redux and stripping the "magic" out of it. But the section about dependencies between reducers bugs me A LOT.

"If a CommentsStore needed data from a PostsStore to properly update itself, it could call PostsStore.waitFor() to ensure that it would run after the PostsStore updated. [...] with Redux, that sequencing can simply be accomplished by explicitly calling specific reducer functions in sequence."

And it introduces a specific call order of slice reducers, and 'hasCommentReallyBeenAdded' variable, inside the root reducer to implement that dependency.

But it looks to me like such a dependency will usually be specific to a certain action, and in a modestly complex application, different actions will have dependencies in different orders, with different ordering and information needs, and moving those into the root reducer doesn't scale beyond one (i.e. the shown example). Thus, as is, the section doesn't really provide a useful pattern for building real apps. Those will need a different approach - represented by the catch-all but not so useful "it's all about how you want to write it."

Am I missing something about that section and topic?

<comment><USER3> Missing a bit, yeah.

It's entirely possible that the `commentsReducer` does know how to handle all relevant actions. It's also possible that it only needs that extra data for one specific action.

One of the biggest advantages of the "reducer" concept is that _they're just functions_, and you can mix, match, and combine them in any way that works for you. I show several examples of additional custom reducer structures in the "Structuring Reducers - beyond `combineReducers`" [0] section of the Redux docs, and also in my blog post "Practical Redux, Part 7: Feature Reducers" [1].

As a quick summary, instead of having the `combineReducers`-generated function as your root reducer, you can further wrap that up in other functions, such as one that takes an array of reducers and runs them in sequence, or one that only does that special handling for a specific action case and otherwise delegates all handling to the normal `combineReducers` approach.

[0] [http://redux.js.org/docs/recipes/reducers/BeyondCombineReduc...](http://redux.js.org/docs/recipes/reducers/BeyondCombineReducers.html)

[1] [http://blog.isquaredsoftware.com/2017/01/practical-redux- par...](http://blog.isquaredsoftware.com/2017/01/practical-redux-part-7-forms- editing-reducers/)

</comment></comment><comment><USER11> When I first came to React my understanding was that React/Flux were all but a package deal, and that I better use Redux because it seemed so popular. Redux quickly became a pain point in terms of boilerplate and added cognitive load. Now a top level stateful component works for 90% of my use cases.I feel the same way about React Router. Maybe if you're building something quite large or complex these prepackaged tools make sense, but I personally have gone the way of Golang and started to prefer a little copying over adding an extra dependency and I've found that React is wonderful by itself. I encourage anyone who will listen to try ditching Redux in favor of a single top level stateful component.

<comment><USER12> I wouldn't recommend this at all. Sure if you have a tiny site with very limited functionality or you're learning react, you don't need redux.

But if you're using components they way they're intended, (not cramming everything into a few overloaded components), you're quickly going to be passing down props down through layers and layers. It will quickly become a maintenance nightmare.

Just imagine that you have a button component that is 5 or layers down from you're stateful component. It's getting props to control it's state passed down through all 5 levels, and it's getting functions to change the stateful component's state passed down through all 5 levels. Now what happens when you want to move the button from your side bar to your footer?

Redux solves a very real problem, there are other solutions to this same problem, but eventually any non-trivial app is going to need something for state management beyond a single top level stateful component.

<comment><USER13> I actually find it easier to reason about my components when I can trace data sharing in my hierarchy rather than allowing components to cheat and circumvent sharing state in their common ancestor. I think it's idiomatic React to construct hierarchies of functional components topped by very few stateful components. Using connect() to turns components deep in the hierarchy into stateful components can only lead to a less declarative dataflow that tightly couples those components to Redux for very little gain.

If you're having difficulty moving components around because of state consider that you may be thinking too statefully and should try to find a less stateful way to describe your UI, or that the UI you have constructed does not adequately group related pieces of data and functionality together, which will lead to a confusing UX.

<comment><USER14> I get what you're saying but for large react applications using Redux helps to dramatically reduce state complexity and increase maintainability.

Having one function 5 levels deep that receives its props from a top level function means everytime you add a prop you have to modify 5 function signatures to get that new data. That quickly becomes unsustainable when you have 10+ layers.

What happens when you want to modify the prop that is set in the parent? You have to pass through a callback function that will modify that parent props and then trigger a re-render.

Very quickly you end up with problems that flux/redux/mobx try to solve.

</comment></comment></comment></comment><comment><USER14> I use react/redux for a very large application and overall it has been a powerful, robust, and scalable solution that handles 99% of our use-cases.

The biggest problem I struggle with is knowing when components rerender. Libraries like reselect that memoize state-composed functions really help with performance, but make it less clear when things are being rerendered and why they are being rerendered.

I also agree with some of the posts here that handling async actions, or side effects, can be rather difficult in the redux model. Redux-thunk is still being recommended even though Dan created it more as a bandaid solution rather than something more robust. We solved it with redux-saga, but my colleagues -- experienced developers -- struggled initially to grasp generators. I also think sagas run into the same problem that one action triggering multiple reducers has which is you could inadvertently trigger an action that hits one or more sagas and not realize you are causing side effects that you did not intent. I know there have been countless discussions on what to do about this problem, but I fear the solution will always be outside of the scope of the core library because of backwards-compat.

<comment><USER3> I have links to a number of useful utilities for visualizing when and why components re-rendered in the "DevTools#Component Update Monitoring" section of my Redux addons catalog [0]. Hopefully those help.

I'm a bit curious why you say that "reselect makes it less clear when things are being re-rendered". The overall reasons shouldn't change - <USER2> components will re-render when values from `mapState` or props from the parent component have changed by reference.

Thunks are definitely the "minimum viable approach" for handling async logic in Redux, or at least the minimum _suggested_ approach (as opposed to doing async handling purely inside of a component). I agree that sagas (and observables) are a pretty big jump for most devs to make, but then again, async logic in general is more difficult to reason about. Personally, I still think most devs should use thunks until they see a need for something else (per my post "Idiomatic Redux: Thoughts on Thunks" [1]).

Redux does deliberately push the question of "how do I handle async logic?" outside of its core, and leave it up to you. That's both because Redux focuses on structuring synchronous state updates, and because (per my post) Dan and Andrew wanted to give devs flexibility in what specific technique they use for handling async.

[0] [https://github.com/markerikson/redux-ecosystem- links/blob/ma...](https://github.com/markerikson/redux-ecosystem- links/blob/master/devtools.md#component-update-monitoring)

[1] [http://blog.isquaredsoftware.com/2017/01/idiomatic-redux- tho...](http://blog.isquaredsoftware.com/2017/01/idiomatic-redux-thoughts-on- thunks-sagas-abstraction-and-reusability/)

</comment></comment><comment><USER15> I'm infinitely more comfortable with functional composition over object composition, but Mobx is still far more intuitive to me. It's because functional composition over a constantly changing global state tree is a huge fucking mess. There's a reasonably objective explanation as to why it is a mess, and more specifically, why Redux suffers from so much boilerplate and painful refactorings.

In UI programming you are managing state, full stop. Almost any UI can be described as a state machine. Not just GUIs, but any UI: digital, analog, mechanical, whatever. And since you are basically managing state machines, any refactoring of the _functionality_ of your UI is fundamentally a refactoring of your state. Rendering is a functional refactoring (state doesn't change), but if you are building a UI and not just a simple landing page, you are far more likely to refactor functionality over rendering...meaning your data is more likely to change than your functions. In other words, _UI programming via functional composition over a frequently changing global state tree falls on the wrong side of the Expression Problem_ [0].

Every time you change your data, you have to modify every functional pipeline, from beginning to end, that touches that changed section of your state tree. That is where all the boilerplate comes from, and that is why Redux is consistently criticized as a system that becomes more and more unwieldy as your UI complexity grows. It is a bad abstraction for the problem at hand.

Mobx is a far better pattern IMO, and I feel entirely comfortable saying that is an objective position to take as long as your functionality is more likely to change than your rendering. It isn't that Mobx is a superior idea, it's just the fact that it embraced object composition for a use case that is perfect for it.

[0] [http://wiki.c2.com/?ExpressionProblem](http://wiki.c2.com/?ExpressionProblem)

</comment><comment><USER16> I've just started another side project using React with redux. One of my goals is to keep my code as simple as possible while still being able to build a large application.

To keep it simple, I'm not using react-redux (I often try to avoid this), and I generally pass the entire store down through all child components, again to keep it simple. My top level app with its simple navigation code subscribes to the redux store and sets its state from it. My router is just a bunch of statements like {pageName === 'connnections' && <ConnectionsPage {...props}}.

To avoid too much boilerplate, I find most of the time all you need are some helper functions. I have a helper function called 'action' that I call like action('LOAD_SOME_DATA') that dispatches on the store with type: 'LOAD_SOME_DATA'. I use a simple 'getIn' function to access nested data, and I mutate data in my reducers with object-path-immutable. Everything is clean and easy to read.

I believe one of the biggest problems with the React community is the constant bleed of 'performance' into app design and development. Premature optimization is everywhere.

Guess what, most apps won't need immutable data and free componentShouldUpdate checks, memoized selectors, or subscribing to subsections of the store using complicated 'connect'/high order component plumbing.

The one time I actually had a perf issue with React was when I had a GIGANTIC list of data (showing all the active salespeople in our company -- we have a lot), which due to me storing form state in redux was being completely re- rendered every keystroke.

The solution wasn't to add react-redux or start using immutable data - it was to add paging and filtering. I improved performance, but more importantly, the UX of the app with this.

If your React app really is so huge and complex that it needs reselect, react- redux, react-router, great stuff -- you are obviously building software for a successful product with lots of feature requirements. Most apps I've worked on never got to this level of complexity.

<comment><USER3> I'm _very_ curious: why do you feel you need to "avoid" React-Redux?

There was a similar thread on Reddit a few days ago, asking why the OP should bother using React-Redux [0]. I'll paste the main part of my reply:

> First, while you can manually write the code to subscribe to the Redux store > in your React components, there's absolutely no reason to write that code > yourself. The wrapper components generated by React-Redux's connect function > already have that store subscription logic taken care of for you.

> Second, connect does a lot of work to ensure that your actual components > only re-render when they actually need to. That includes lots of memoization > work, and comparisons against the props from the parent component and the > values returned by your mapStateToProps function for that component. By not > using connect, you're giving up all those performance improvements, and your > components will be unnecessarily re-rendering all the time.

> Third, by only connecting your top-level component, you are also causing the > rest of your app to re-render unnecessarily. The best performance pattern is > to connect lots of components in your app, with each connected component > only extracting the pieces of data it actually needs via mapStateToProps. > That way, if any other data changes, that component won't re-render.

> Fourth, you're manually importing the store into your components, and > directly coupling them together, thus making it harder to test the > components. I personally try to keep my components "unaware" of Redux. They > never reference props.dispatch, but rather call pre-bound action creators > like this.props.someFunction(). The component doesn't "know" that it's a > Redux action creator - that function could be a callback from a parent > component, a bound-up Redux action creator, or a mock function in a test, > thus making the component more reusable and testable.

> And finally, the vast majority of apps built using React and Redux use the > React-Redux library. It's the official way to bind the two together, and > doing anything else will just confuse other developers looking at your > project.

> So, part of the issue is you're not using React-Redux and connect, and part > of the issue is you're using an inefficient pattern for pulling data from > the Redux store into your React components.

So no, many apps don't need to spend tons of time optimizing performance, but at least part of that is because `connect` already handles a lot of that for them. There's also other reasons for immutability, per my original post for this thread: time travel debugging, testability, and ability to reason about state updates.

Also, in regards to the "re-rendering on every keystroke" issue, my post "Practical Redux Part 7: Form Change Handling" [1] shows off a React component I made that specifically helps buffer those for fast form updates, while debouncing the number of Redux actions dispatched.

[0] [https://www.reddit.com/r/javascript/comments/6hperk/i_use_re...](https://www.reddit.com/r/javascript/comments/6hperk/i_use_react_and_redux_but_never_reactredux_what/)

[1] [http://blog.isquaredsoftware.com/2017/01/practical-redux- par...](http://blog.isquaredsoftware.com/2017/01/practical-redux-part-7-forms- editing-reducers/)

<comment><USER16> Because of the extra complexity and cognitive overhead introduced by connect. It obscures the one-way dataflow in React in a similar way using 'context' does, making it less explicit. There are benefits, but I like being able to trace the flow of state through my app in the code.

Second and third points both concern performance. See my OP: it's a premature optimization. How many people honestly run into rendering performance issues when building a single page app? Why introduce extra complexity for performance you don't need?

Fourth point: no, I don't manually import the store into my components. My top level app component subscribes to the store (3-4 lines of code), and passes the data in the store down into its child components, including my routing component and all the rest. Most of them are dumb stateless functions that just render from their props and call the occasional action function.

Action functions themselves aren't on props and don't do any binding of any kind. They are just functions that provide a simple abstraction on top of store.dispatch. Again, simplicity.

Regarding confusing developers: I disagree with this statement 100%. We have two React apps at work, one that uses the simple approach without react-redux, and another that pulls in most of the usual ecosystem: react-redux, react- router, redux-form, and so on. The cognitive overhead is larger; reasoning about the code is harder; the greater number of libraries means we've had bugs in those libraries that cause difficult to solve problems.

It's just an opinion of mine, but in my experience, React and redux by themselves can get you a very long way before you _need_ to pull in other libraries.

</comment></comment></comment><comment><USER17> Just want to put down my flag in the sand and say I love Redux. It is my tool of choice whenever dealing with anything that contains state and (with it's partner in crime, Redux Saga) anything that has to do with the real world (dreaded side-effects).

Thumbs up on Redux, your boilerplates are my sanctuaries.

</comment><comment><USER18> Hihi, I catch myself scanning through react posts just to find something about vuejs :) - it seems to be kind of a 'natural social law' that 'the mainstream' never is the real thing.

</comment><comment><USER19> I don't event want to open the article that has both of "idiomatic" and "tao" words in the title.

<comment><USER3> For what it's worth, "Practical Redux" is my blog series that demonstrates Redux techniques by building a sample app. "Idiomatic Redux" is my series for my own thoughts on why I think certain Redux usage patterns are good or bad. The phrase "Tao of Redux" was just something that popped into my head and sounded catchy, and seemed to go along with the idea of "explaining the Redux philosophy".

<comment><USER19> It sounds like the author is some kind of guru who became enlightened and willing to share the "tao" of "idiomatic" way of JS library. Can't you see how pretentious it it?

<comment><USER3> Well, _I_ am the author, _and_ a Redux maintainer, _and_ I've spent a ton of time discussing and using Redux :) I can legitimately say I'm _an_ expert on Redux, its implementation, and its use.

The original point of writing it is that I see many people complaining about things like "having to use action creators" and "having to edit many files", when Redux itself doesn't actually require you to do those things.

So yes, I guess you could say that I _am_ trying to enlighten people, because many of the complaints about Redux are being made out of an incomplete understanding of why it exists and what its intended use is. If people still don't like Redux after that, that's fine - I just want people to better understand why Redux usage patterns exist and clear up the misunderstandings.

<comment><USER20> The problem with redux is actually the dev-tools (and the ecosystem that spawned from the middleware). the newbies get wowed by "time travel debugging" and want to copy/paste there way to the $$$profit.

Redux takes a simple concept, and turned it into something thats really hard to apply to the projects these people are writing; by reinventing words into a propriety language.... No one talks about about there state as a function of "reducers". And when they think they have their head around "actions" they realise that no, its not a 1-to-1 relationship with what the user is doing.

If redux didnt try and re-invent event-sourcing with its own "idomatic TAO way", it could of leveraged off the plethora of well written documentation on the subject.

Instead, Dan, thought he could improve event sourcing and make it palatable for the masses by -replacing "events" with "actions" [1] -making the state an anemic domain model[0] -persisting snapshots instead of an event log then adding on congnitive load by implementing a diffing algorithm for UI updates which requires specialised knowledge. [1]

[0] [https://martinfowler.com/bliki/AnemicDomainModel.html](https://martinfowler.com/bliki/AnemicDomainModel.html)

[1] [https://martinfowler.com/eaaDev/EventSourcing.html](https://martinfowler.com/eaaDev/EventSourcing.html)

<comment><USER21> Another red flag on redux: recommended practice--query JSON over HTTP (likely backed by an RDBMS), renormalize the hierarchical data, and then reshape the renormalized data before passing to components.

<comment><USER19> Right?! and redux is a baby-monster comparing to Relay that demands developer to actually modify the server's graphQL API in order to comply with the odd requirements.

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> The React ecosystem is growing out of control! JavaScript was a revolt against the overcomplicated Java ecosystem, but it is now worse than its original enemy with favors, opinions, and best tools for the job changing daily! Remember when JSON came out as an alternative to XML? Now all XML technologies have JSON equivalents - schema, pointer, etc. What was the point of the switch then - keep spinning wheels and not moving forward? With Babel being the centerpiece of JavaScript development today, can we at least apologize to GWT?</comment>


Get Firefox Home on Your iPhone: The Mozilla Blog - <AUTHOR> http://blog.mozilla.com/blog/2010/07/15/get-firefox-home-on-your-iphone/ <comment><USER2> No custom server support that I can see, alas.</comment>


iOS 7 only is the only sane thing to do - <AUTHOR> http://berzniz.com/post/72083083450/ios7-only-is-the-only-sane-thing-to-do

<comment><USER3> I still target 5.1 because it does 90% of what 7 does but still works on first gen iPads. Apple has a tendency to only implement software features on their newest OS instead of back porting to earlier versions, because it sells more devices. It's unleet for developers to encourage this.

I think a reasonable prime directive for API developers is that if hardware can do something then software shouldn't be prevented from running on it. Sure there are arguments for speed/responsiveness but most of these are straw men because the real bottlenecks are somewhere else (reading from flash memory, internet lag etc). The only real hardware constraints I hit daily are limitations in OpenGL or limited ram (which wouldn't be an issue if proper virtual memory had been in place from the beginning so we didn't have to use mmap).

This kind of software "truthiness" is taking us further and further from computer science.

<comment><USER4> I saw somewhere that Apple doesn't allow new apps to target less than iOS 7. Is that correct?

<comment><USER5> Depends what you mean by "target". You can specify the whatever minimum OS version you want for an app.

You have probably heard something like "[After Feb 1] new apps [...] must be built with the latest version of Xcode 5 and must be optimized for iOS 7."

That only means you must use the latest dev kit and satisfy some other requirements. It does not mean that you need to disable support for older OSes.

<comment><USER6> It is not trivial to support ios7 with the latest gui elements (ios7 sdk) and also support prior versions. Practically speaking you will need to support only ios7+ after feb1, which for me is a lot of development work which is not worth doing with the income my apps give. I am therefore no longer supporting my apps.

</comment></comment></comment></comment><comment><USER7> Great points, except for "@2x only." If your app supports iPads, then the iPad 2 and iPad Mini (first generation) are both non-Retina screens and are still available for sale directly from Apple. Given Apple's 3 year support cycles, iOS 10 will be the first iOS that can fully drop support for non-retina displays _if_ the iPad 2 and original iPad mini are discontinued by the end of this year.

<comment><AUTHOR> Our app is iPhone only, but this is a great point to remember for anyone thinking about dropping the non-retina image.

<comment><USER8> Unfortunately, an app cannot be made `-568h` only. And -[UIImage imageWithName:] does not support `-568h` infix.

<comment><USER9> Which is pretty lame considering xcassets supports an image 'subtype' called R4 that's designed for 4" screens.

</comment></comment></comment></comment><comment><USER10> Seems more like iOS 7 is the only _convenient_ thing to do. That's fine, but the current title makes it read more like a weak attempt to justify not wanting to support older versions.

</comment><comment><USER11> Pull To Refresh - available in iOS 6.

UIViewController Containment APIs. iOS 5.

Custom Tab Bar. iOS 5

Custom Navigation bar. iOS 5

HTML Strings. iOS 7

@2x only. iOS 7

Flat out. iOS 7

viewDidUnload. iOS 6

AutoLayout. iOS 6

UIDynamics. iOS 7

Receding keyboard like the messages app. iOS 7

</comment><comment><USER12> Note that Apple now keeps the previous version of the app around for users on older OSes. Of course they won't get any of the upgraded features, but at least there's still something there for them - and you won't have to worry about all that messy code for supporting multiple versions.

My next app updates will also be iOS7 only, since I know the iOS6 version will still be around. Makes it much easier to decide to use newer features.

<comment><AUTHOR> Yeah, that's a great feature.

One open issue is that from time to time a breaking change to our API is needed and a force-upgrade is forced on the app users. We try to avoid it, but it happens.

The next time this happens, it's really goodbye iOS 6 users.

<comment><USER13> This year, Apple's "12 Days of Gifts" app only runs on iOS7. I don't know if that was intentional, but it seems likely.

<comment><USER14> Slightly off topic here. I'm a bit baffled by that app. It's a fugly - <USER2> seems like a pre ios 7 app that was resurrected in a few days and isn't very Appley at all. I wouldn't call is skeuomorphic, but it isn't the new(ish) flat look. The main screen's background just looks like someone forgot to include the artwork. Its a flat grey though, so must have been chosen. The clunky FAQ page isn't nice either, and a straight link to a web page would have been nicer IMHO.

</comment></comment></comment></comment><comment><USER15> There isn't anything in this article that explains why you can't support both. The only sentence about this is "We can't leverage what iOS 7 has to offer and a lot of the UI is compromise.", which doesn't cite any difficulties they've run into. The only iOS 7 features they mention are UIDynamics and the receding keyboard—the rest are iOS 5/6 features.

<comment><USER7> I agree that the article could've gone into more depth about the difficulties they faced, but most developers will agree "a lot of the UI is compromise" is the key point. Supporting iOS 6 and 7 visuals at the same time just means your app looks out of place in both versions.

<comment><USER16> > Supporting iOS 6 and 7 visuals at the same time just means your app looks > out of place in both versions.

It's just a little more work. Facebook looks the same on iOS 6 even now that it supports iOS 7.

If you are mostly using native UI with only a few customisations, I don't see the problem.

<comment><USER7> The problem is a lot of iOS 6 apps don't use mostly native UI. The article touches on this when talking about all their custom code because previous iOS components were not as easily customizable. My next update will be iOS 7 only, at which point I plan to drop a lot of custom code and switch back to mostly native UI.

<comment><USER16> Yes, UIKit only became easily customisable in iOS 5 and the OP's app was written for iOS 3.

But even then you can port it to native UIKit (which is a good idea either way), and then make iOS 7 frameworks optional, and add a few UIAppearance calls for iOS 6. The last two pieces are extra effort that might not worth it for < 30% of your users, but it's still completely possible.

</comment></comment></comment></comment></comment><comment><USER6> You're fortunate you can afford to expend development effort/money on an update that won't bring in any more users. Im still licking my wounds from the app store change that came with ios6, sales are way way down to the extent that significant development work to these apps cannot be justified. With the pre ios6 app store I could make a case for it but not today.

</comment><comment><USER17> Sheesh. Am I the only one still using a first-gen iPad stuck with iOS 5? Just a couple weeks ago my sister wanted to install an app that turned out to be iOS 7 only. Grr.

<comment><USER18> No. And I hope there are a _lot_ of first-gen iPads still in use, since the alternative would mean millions of abandoned pieces of hardware, rather than just millions of us abandoned users. If only I'd had the hindsight to stick with iOS 4 - at least my tablet would then be usable without inducing stress, fury, and bitter regret.

</comment></comment><comment><USER19> Interesting - I did not know about the new receding keyboard functionality.

For those curious, you can simply set a boolean on any UIScrollView or subclass to make the keyboard recede like in the Messages app.

<comment><USER20> What is a receding keyboard? Your comment is like

        /**
         * Recedes keyboard.
         */
        void recedeKeyboard() {

<comment><USER21> Except he explains that it works like it does in the Messages app. If you're not familiar, the keyboard in Messages slides down/recedes when you start scrolling through past messages so that it's not in the way and you can see more content. Give it a try if you have an iOS device, it's a very useful interaction.

</comment></comment></comment><comment><USER22> Actually, that doesn't seem very sane to me. Why are we doing additional work for functionality that we already created, and losing support for people on older versions? Sure if you are a making a new app it makes sense to use great new features. It doesn't make sense to delete code that is working and redo it just because the new way is easier. 0 effort >>>> small effort times 10.

<comment><USER23> "It doesn't make sense to delete code that is working and redo it just because the new way is easier."

Less code to maintain >>> custom written code that might be prone to break on newer versions of the OS. It's definitely what I would do.

<comment><USER22> While I agree that less code is better, is it the highest ROI on your time compared to actually improving the app, or maybe making a new one? It might break in the future, it might not. What you change it to might break in the future too. Why not wait until it breaks to rip out and rewrite working code?

</comment></comment></comment><comment><USER24> The sweet point for me has been iOS 6-7 support. There's little that iOS 7 has that I need to use, so a few conditionals here or there haven't been a huge deal (tintColor has been the only significant one). This contrasts immensely with trying to support back to iOS 5 where so many new things were added after (e.g., autolayout) that you end up with huge chunks of redundant code that differ only in the approach taken to get the end result.

My apps' interfaces are entirely customized, so everything looks roughly the same across the major versions. I've shifted to a flatter appearance since iOS 7, but I've held onto certain things from older ones that I like better such as borders on buttons where the button status is not clear from the context, filled toolbar icons (I hate the stenciled ones), and a shadowing level somewhere between iOS 6 and 7.

</comment><comment><USER25> I was a bit on the fence about iOS versions before because I still have a first-generation iPad (iOS 5.1 maximum) and I wanted to make games for it. I have a new iPhone 5S as well.

I originally wrote game code with OpenGL ES, and then tried very hard to make the same code work on a Mac with regular OpenGL. It took more time than it should have to see results and it wasn't that fun. About all I can say is that I learned a lot and OpenGL clearly runs efficiently.

After seeing Sprite Kit (Mac OS X Mavericks and iOS 7 only) and working with it, I am now _completely_ devoted to these latest OSes. That framework has solved virtually all of my Mac/iOS parity issues, while allowing code to be almost identical in ways that really impressed me. Sprite Kit requires far less effort and it produces far greater results. About the only downside I see is that there would be no hope of porting my code to something like an Android phone (and I don't happen to care about that).

It doesn't hurt that Mavericks is free so about the _only_ device left out in the cold is my old iPad. I decided that I was probably holding myself back by trying to support it anyway; the device is quite slow compared to almost any other iPad. I will likely just buy a new iPad.

</comment><comment><USER26> I've done the same for the app that I work on, but not because I needed an if- else for the UI code. The biggest problem for me was that every now and then, I'd get a bug that shows up on a device, but not the simulator. If this happens even once, it is one time too many for a small team without a lot of leftover devices to sport old iOS versions on.

</comment><comment><USER27> "This was one feature we really wanted and implementing this was painful as hell. I can't believe it's now just a boolean value away." \- So awesome yet so frustrating! haha

</comment><comment><USER28> Right to the point information. GREAT.

I've been programming on a daily basis for iOS even before the SDK came out (ohhh those reverse engineering days...!). Two years ago I left the job and since then I've always wondered what were the relevant changes in the SDK, just in case I get back to programming iOS again. And here we have it!

</comment><comment><USER29> > When we added pull to refresh to our app there weren't many apps using this > technique and it added a premium feel to our app.

This makes me want to vomit. I can't wait until implementing flashy UI is so trivial and common that shallow things like this don't actually affect an application's perceived value. I don't remember the transition to GUI in the 80s as being as shallow as the mobile app market is.

<comment><USER30> Its not shallow, it makes the app easier to use and therefore better designed.

Also, perception is reality.

<comment><USER29> I contest the idea that any two apps are so similar that something as trivial as list-refresh mechanism could push one over the top.

<comment><USER31> I look forward to competing with you one day!

Seriously though, you contest the idea that an interface with interactions which hide complexity and have been shown to be pretty intuitive could be decisive in how users value a product?

<comment><USER29> No, I agree that in the current mobile app world UI flourishes really do make a difference in how users perceive an application. I'm hopeful for the day when such flourishes are so common that they are no longer perceived as valuable and we can get back to working on things that matter.

<comment><USER32> This isn't just a cosmetic thing; it makes it substantially easier to perform an operation (in this case refreshing) and to see the status of that operation.

Don't bet on UX enhancements ever going away, by the way; people come up with new things all the time. Pull-to-refresh didn't come from any platform vendor; it came from a third party Twitter client.

</comment></comment></comment></comment></comment></comment><comment><USER33> I think that not writing iOS/ObjectiveC/AppStore/Apple-specific code, period, is even saner.

</comment><comment><USER34> Are the multiplatform techno like flex, cordova/phonegap, haxe... already out of question ?

<comment><USER32> Well, it depends on your needs, but really I have yet to see an app made with any of them which isn't an unpleasant user experience.

<comment><USER23> [http://theweathertron.com/](http://theweathertron.com/)

Done with (IIRC) PhoneGap, AngularJS and ClojureScript. The actual utility as a weather app is debatable (I like it), but the UI is beautiful and responsive, especially considering it's PhoneGap!

<comment><USER18> "Requires iOS 6.0 or later" \- ARGH!

</comment></comment></comment></comment><comment><USER35> There's really nothing sane about iOS/the iPhone when the government has full control over it.

The only sane thing to do is have it recycled.</comment>


Re-targeting is broken - <AUTHOR> http://asifali.me/post/41268898082/re-targeting-fail

<comment><USER2> Agree, broken Re-targeting really annoys and it happens even with Facebook, personally have experienced repeated ads coming up even after the product was bought, mostly this happens when we use Facebook as the login option to get into these online Mega Stores.

</comment><comment><USER3> Yes, exactly. Is it because the platform provider not put much focus on it?</comment>


Video Gamers Can Control Dreams, Study Suggests - <AUTHOR> http://www.livescience.com/culture/video-games-control-dreams-100525.html

<comment><USER2> huh. I thought it was just me, that I was a bit bizarre being able to control my dreams - I've talked about this with lots of friends and family, and no-one else seemed to be able to do it. But no, they even have a term for it, 'lucid dreams'. Who'd a thunk it?

I don't know about the whole 'go hyper aggressive' thing though - I generally just do something like make the bad guy break his leg when he is chasing me...

</comment><comment><USER3> For as long as I can remember I've always been able to control my dreams. Whenever I've told people this they've looked at me as if I'm making it all up.

Nice to know I might not have been imagining it.</comment>


Show HN: Jeff Atwood's "Effective Programming" on Hyperink's new Crowd Reader - <AUTHOR> http://www.hyperink.com/cloud/read/1559 Hey everyone, I'm Michael, a product engineer at Hyperink. Over the past month or so, I've been developing a rich, social reading experience for our content, freeing us from the stranglehold of MOBI and EPUB file formats. Today, Jeff Atwood generously granted us permission to release half of his book completely free on this Crowd Reader (paid customers get to see all of it there).
The problem: paperback/print always wins over digital and arguably e-ink.
Our solution: make reading a unique and asynchronously social experience.
I've love to get some beta feedback and hopefully some suggestions for how to improve the UI/UX. Thanks, and happy reading! <comment><AUTHOR> Hey everyone, I'm Michael, a product engineer at Hyperink. Over the past month or so, I've been developing a rich, social reading experience for our content, freeing us from the stranglehold of MOBI and EPUB file formats. Today, Jeff Atwood generously granted us permission to release half of his book completely free on this Crowd Reader (paid customers get to see all of it there).

The problem: paperback/print always wins over digital and arguably e-ink. Our solution: make reading a unique and asynchronously social experience.

I've love to get some beta feedback and hopefully some suggestions for how to improve the UI/UX. Thanks, and happy reading!

UPDATE: forgot to mention. This app is 100% JavaScript with Node and my own JS makeshift library on the front. MongoDB for database. Madness.

<comment><USER2> Scrolling is severely buggy in Chrome (20.0.1132.57 on OS X) and partially buggy in Firefox (13.0). I did some screen captures.

#1 (<https://www.dropbox.com/s/bczmu8kjfhn6ymr/bug1.mov>): Scrolling is actually faster in the upward direction than the downward direction. In this video, I continuously move my fingers on my trackpad up 1cm and down 2cm. You would expect the same movement to scroll equivalent distances, but it does not. In fact, you will see that sometimes it stutters or will not scroll at all. (There is nothing wrong with my trackpad, and the problem only affects your site.) This problem affects both Chrome and Firefox.

#2 (<https://www.dropbox.com/s/x9zzd298v85atf9/bug2.mov>): The viewport is often mysteriously constrained and refuses to scroll any further, even though there is more text. In this video, I opened a fresh window, immediately clicked on one of the chapters, and tried to scroll downards. You'll see me struggle for a bit, then scroll to the previous chapter and then back to the original chapter. Only after doing this am I able to scroll downwards. Seems to affect Chrome only.

Looks promising aside from these rather severe issues.

<comment><USER3> I can confirm this. My scroll wheel is very easy to move one increment at a time, and repeatedly moving down one then up one increment results in text moving upwards about 4 lines per cycle. When testing on this site: <http://www.javascriptkit.com/javatutors/onmousewheel.shtml> I can confirm that scrolling up and down provide a delta of 1200 and -1200 respectively, the way it's being handled on your app must not be even.

</comment></comment></comment><comment><USER4> I have grown used to being able to click in the scrollbar background area to page up or down, which I tried to do when I determined the mouse wheel scroll down was going too slow.

And when the scroll indicator widget is over the dark part of the first graphic in the introduction, it is lost. Since there are no up and down arrow keys at the ends of the vertical scrollbar, if I did not know where the position indicator was, I am not sure I would be able to find it.

If it helps, the differential in the scrolling direction to click of the scroll wheel is two to one. Scrolling up one click covers the same territory as scrolling down two clicks.

<comment><USER4> And when I toggle the left pane open and closed, the text apparently reformats for the difference in widths, leaving me to have to scroll back up or further down to find where I was last reading. Any way to track current line and scroll to that point when the left pane is toggled on or off?

<comment><AUTHOR> That's a very good point. I've long considered tracking last-loaded position and using local storage to reload the last-unloaded scrollTop position. I could simply track that on the sidebar collapse to maintain it. Good feedback! Thank you!

</comment></comment></comment><comment><USER5> The most overrated writer in the history computing. It always made me scratch my head why Joel Spolsky, who, say what you want, but I think is a very legitimate writer said so many praises for Atwood's writing. But Spolsky also said Yegge wrote beautifully, which I cannot fathom; it is definitely a different standard for writing than the rest of the world. There's more to writing than using correct grammar, but in the standard of programming blog writing I guess that's amazing. :) Really, I'd rather have wonky grammar and good content on programming blogs than just a series of pictures and backlinks with ideas that make no sense.

That being said, I was not familiar with hyperink at all but it is actually a very pleasant reading experience (it was just the actual words that upset/annoyed me :) )

<comment><USER6> I find that the best way to handle things I don't enjoy is to avoid them. Perhaps try that in the future as a strategy?

</comment></comment><comment><USER7> The title of the book appears to be "Effective Programming" and not "Efficient Programming."

<comment><AUTHOR> Good catch! Thanks a lot.

</comment></comment><comment><USER8> Solid Inkling ripoff. Well done!

<comment><AUTHOR> Thanks, I tried soooooo hard!

</comment></comment><comment><USER9> The reading experience is a bit cumbersome on the iPad, in portrait mode. I'd kill the social sidebar if in iPad mode...I'm not likely to use the social bar when at my iPad, but I do judge the overall reading experience based on how effortless it is on the iPad, or any other tablet

</comment><comment><USER10> A book by a VB programmer? Nah ... thanks ... I'll pass on this one.

<comment><USER11> Franzus, isn't this statement a little arbitrary? While I wouldn't claim to be a huge visual basic fan, I think (at least from my experience reading Jeff's book) there's a lot more one can get out of this resource than insight into programming languages.

For instance, Jeff has a great section on protecting users' data, writing test cases, and building community (like that of stackexchange).

I wouldn't be so arrogant as to presume I know what information you're interested in learning, I just wonder if not reading a resource by a smart programmer due to a programming language bias might actually work to your disadvantage?

Cheers either way!</comment></comment>


What's the best wifi hotsppot? - <AUTHOR>

I'm looking for a small portable wifi hotspot, that's really cheap. I know a lot of the cheap ones are crappy, but what's the least crappy one you know of? <comment><USER2> No answer for you, but I've been looking at the Karma. I have a friend who ordered one before Christmas 2014 - and still hasn't received it. Thought that might be helpful to anyone else considering a hotspot</comment>


_why: "Goodbye until I can shake this." - <AUTHOR> http://mislav.uniqpath.com/poignant-guide/book/chapter-6.html#section7 <comment><USER2> I also noticed that if you rearranged the letters in 'why' you get 'hwy', which, if pronounced a specific way, sounds very similar to the Pacific island of Hawaii, leading me to believe that he made his escape there on the 19th, which you get by fully curving the bottom right part of the 'h' around to make a '9', flipping it over both horizontally and vertically, and placing it to the right of the underscore when propped up to give us the '1'. It was under our noses the entire time.

<comment><USER3> Your comment has 19 points! That -has- to confirm it!

</comment></comment><comment><USER4> I don't know how to say this politely but we really need a bunch of Erlang articles on HN right now. _this _is _getting _out _of _hand.

<comment><USER5> It may not be the right place to discuss these matters, but it's the only place I have (with the programming reddit, but the userbase is different).

<comment><USER2> What matters exactly?

<comment><USER6> Those of _why's disappearing, presumably, and of the work he left behind.

</comment></comment></comment></comment><comment><USER5> [http://mislav.uniqpath.com/poignant- guide/images/the.foxes-6...](http://mislav.uniqpath.com/poignant- guide/images/the.foxes-6.png) :-(

Tall Fox: -Have you noticed that this book is basically written by a _lunatic_?

Short Fox: -Yup

Tall Fox: -Seriously, he's way too hyperactive. If he keeps at this frantic pace he's gonna burn out quick.

Short Fox: -Burn out? He's gonna shoot himself in the head by the time he hits 30.

\--

From that kind of comment and the pace of his work (bouts of rabid coding interspersed with AWOL periods), I'm afraid he's bipolar. His only output (code, writing, mailing list contributions) in june was a single tweet saying that he was trapped in a labyrinth of his own design.

I sincerely hope he's alright.

<comment><USER7> And here:

[http://mislav.uniqpath.com/poignant- guide/images/departure.p...](http://mislav.uniqpath.com/poignant- guide/images/departure.png)

"Ha! I was right! He flipped his lid! He's all burned out and he's going to shoot himself in the head!"

On the bright side, from the little psychology and the little about _why's author that I know, he doesn't seem to fit a psychological profile of someone who would kill himself. I'm sure he works a lot, and his work is curiously personal and I'd imagine exhausting, but his work is also well recognized and celebrated. Many artists don't have that luxury in their lifetimes.

<comment><USER5> I read his original blog on advogado today. There's a mention of his father undergoing a mental breakdown, and of his sister having drugs and alcohol problems. It ends like this:

-

"and i go home and draw cats and doctors in space. without the medication. i'm a stiff. an upright. i'll never pass a joint. maybe mj works, maybe mj's death. i have too much mental illness in my blood to find out. narco+alco have turned kooky people i love into obliterated people i love. god, god, god, please keep her alive. (if i'm lucky maybe god will let a horse run by.)

families are a network of lost packets and bad routing. cause you got spouses on the vpn. it's not all that bad, but it's fun to moan, ya know."

-

While there are some errements, these themes are far too recurrent to just be whimsical.

</comment></comment></comment><comment><USER8> I'm confused. When did _why add this section? Recently? Did _he_ even add it at all? It begins: August 19th shall be known as _why Fawkes day.

<comment><USER5> It was there when he wrote the chapter, with the comic section attached next to it.

There are other allusions to him leaving the scene/dying in other writings.

<comment><USER9> It's strange that no one mentions those sections when they mention the book.

</comment></comment></comment><comment><USER10> I didn't know who _why is. Here's a link for non-ruby folks: <http://en.wikipedia.org/wiki/Why_the_lucky_stiff>

</comment><comment><USER11> i'm in no point a ruby guy or involved with the ruby community, but i couldn't have missed this guys legacy. kinda reminds me of RAW.

</comment><comment><USER12> It's official. News.ycombinator is now news._whycombinator. And I can't stand it.

</comment><comment><USER13> _gasp_ he was planning this all along! and he left clues!

<comment><USER14> and his name is _why? What we are all asking right now!

</comment></comment><comment><USER15> The Ian Curtis effect.

</comment><comment><USER16> this is effing lame.

</comment><comment><USER9> Can we stop discussing this? The more you say, the more it diminishes the effect and the aura of his leaving.</comment>


College or not? - <AUTHOR> http://sahillavingia.com/blog/college-or-not/

<comment><USER2> Sometimes I regret going to College. I hardly learned anything. The bigger thing I got out was how to organize myself and socialize.

In hindsight if I had momentum around an idea I'd have preferred to go work on that directly. Personally I learn way more through doing than reading.

</comment><comment><USER3> Congrats Sahil, on your decision to take some time. I trust that you'll quickly fall in love with the energy and meritocratic environment that is the startup world. Also know that you always can go back, even if USC doesn't normally allow it, the lessons you'll likely learn in the "real world" will make you a better student, if you chose to return (looking back I'm sure many of us wish we could do it "all over again").

I have a good friend who was offered the opportunity to work for a startup out of high school in 1999 after he finished an internship. Long story short, the company sold to Netscape and he always speaks highly of his experiences and the people he met. When he returned to school, rather than graduating "into" a decimated Silicon Valley job market, he rode the bubble until the 101 felt like a ghost town during rush hour. And he made his way back to school, where he was able to get exactly the education he knew he needed, based on experience. Now, just for the purposes of the case of one example, he is a YC W10 founder.

Obviously, dropping out of school to work as broad-stroked advice probably doesn't make sense, but in the case of a talented, driven entrepreneur like yourself, I say go for it.

</comment><comment><USER4> I went to an engineering school that is ranked high in that department.

Many will disagree with me on this point, but I truly believe that "college education" is a scam.

College was sold to me on the premises that 1) I would be taught my job related skills there and 2) this experience would provide me with a job / or at least prepare me for a job.

Neither of these things turned out to be true. Not even 20% true. But rather 0% true.

Nothing usable was taught and by the time I was a junior in my computer engineering curriculum I doubt 50% of the class would be able to hook up a couple of batteries to produce the correct voltage needed.

Huge classes, 60 point curves, theory and mathematics without practical application, no hands on works that deals with real world use/cases.

Get them in, get them out, take their money.

I'm not saying college is useless, just that what is sold to you is not what is delivered.

I run my own business now.

</comment><comment><USER5> I studied electrical engineering at WPI for 4 years. They were going to push me into a 5th to complete the degree, so I said "heck with this" and dropped out. It was the best decision of my life, and after having paid down $60k of my over $100k in debt, I consider my biggest mistake in life thusfar to be 'going to college' in the first place. I learned lots of cool theoretical stuff with respect to dinking around with electricity and circuits, but absolutely none of my classes prepared me for my 'real world' job of being a sysadmin (for now). I have maybe _three_ people currently in my life that I consider good close personal friends that I met in college, but they're 'friends'. Not 'business colleagues'. My advice? If you're a fairly well- performing autodidact, don't bother with college and the staggering debt that ensues.

</comment><comment><USER6> As a mechanical engineer, I felt that most of my classes were pretty useless. Tons of theoretical analysis, etc etc. I then got my first job, and while they were bringing me up to speed, I noticed that I was sure glad a knew a few things from two or three of my classes.

I went back and talked to some of my friends, and they had the same reaction, but with totally different classes for different companies.

So at least in MechE, a college degree gives you a light framework for the employers to build on, and really is more-so just a certification that you're not an idiot and can learn things.

</comment><comment><USER7> There are, of course, exceptions but most people are better off if they finish college. Yeah, I know... "Bill Gates", "Mark Zuckerberg", "<insert-any-one-in- a-million-tycoon>", so what?

Without that degree, it still is the case that many doors are closed and you have to work much harder and longer to get to the same places than those with a degree.

And anyway, whatever happened to education for its own sake? Not everything has to be vocationally/income centered.

</comment><comment><USER8> I went to college for 2 years, then dropped out to peruse the startup world. I can say that I've made many valuable connections being in the industry (more so than in college), and I definitely don't regret my decision dropping out.

</comment><comment><USER9> Depends, do you like in depth and depending on the college/university cutting edge knowledge? Education isn't about money it's about learning about what you drive for.</comment>


Mastering Elixir Book - <AUTHOR> https://www.packtpub.com/application-development/mastering-elixir <comment><AUTHOR> After a lot of work, here's my new book on Elixir! Also written by my friend and colleague Daniel Caixinha, it takes the reader on a journey to develop a Dropbox-like web application and deploy it on the cloud.</comment>


The Dark Side of Customer Development and Lean Startups - <AUTHOR> http://coconutheadsets.com/2009/11/28/the-dark-side-of-customer-development-and-lean-startups/

<comment><USER2> Customer development is kind of faddy at the moment, and you are right that you can't get too extreme with things, but frankly in this case I think you're just doing it wrong.

The customer development model is a _tool_ to help you find a market (actual paying customers) for your idea. It is not a growth strategy.

It helps with the early part of the TALC (Technology Adoption Life Cycle). It is a tool to help you find early adopters and early customer segments that allow you to Cross the Chasm.

One of the hardest things about managing TALC is knowing where you are in it. I think maybe you managed to find an early market but didn't shift your operational strategy & tactics to reflect your progress.

I would suggest you read Geoffrey Moore's Crossing the Chasm and Inside the Tornado. They are very, very good books. I read them over 10 years ago and haven't found them to be wrong yet.

</comment><comment><USER3> I think post author missed the point of "lean". The point is to iterate through a few adjacent market positions with the lowest cost possible until you find one which resonates with users the most. Once you found one, by all means get out of lean and start building out like mad.

This is an alternative to building out like mad something that you have no idea if anyone wants to pay money for, and then doing it again and again at great expense of time, money and morale. Think ".com" mania.

I agree that Steve Blank needs to talk more about lean success/failure criteria and an exit strategy. If you've used lean to build a smallish business you need to leave it behind and go look for something else. This is challenging logically (how do you know if it's _too_ small?), psychologically (given the sweat put into it) and financially (revenue is revenue after all and you get attached to it especially if you don't have _other_ revenue to fall back on).

</comment><comment><USER4> He is bashing two strawmen:

1\. Lean Startups aren't cheap startups

[http://steveblank.com/2009/11/02/lean-startups- aren't-cheap-...](http://steveblank.com/2009/11/02/lean-startups-aren't-cheap- startups/)

2\. Lean Startups aren't small startups.

Steve Blank based much of his methodology on his experiences running E.Piphany. E.Piphany IPO'd before reaching a 4 Billion dollar market cap:

[http://news.cnet.com/IPO-Update-Kana- Communications,-E.pipha...](http://news.cnet.com/IPO-Update-Kana- Communications,-E.piphany-soar-in-debuts/2100-12_3-266199.html)

<comment><USER5> Rich. I tried to distinguish between the ideas behind lean startups and the common perceptions of lean startups as portrayed in most startup blogs. It is the latter I was attacking, which is why I qualified the post at the end.

</comment></comment><comment><USER6> The author is completely missing the point of lean and minimal viable product. His assertion that Google would only be a "small search player" if they'd gone the lean startup route is way off, because Google already had their MVP built by the time they took their VC money. There's nothing wrong with taking money to accelerate business growth; it's just dangerous to have unlimited resources up front when you're still trying to figure out what the market wants.

<comment><USER5> According to the lean startup presentation given by Eric Ries at Web2.0 expo, ([http://www.web2expo.com/webexsf2009/public/schedule/detail/7...](http://www.web2expo.com/webexsf2009/public/schedule/detail/7789)) one key point is to "1. Identify a profitable business model faster and cheaper than your competitors." Google took VC money without having a clear revenue model at the time. So I would argue that they weren't a lean startup.

And anyway, I would say MVP and lean startup are different but related concepts.

<comment><USER6> I would argue Google had identified the profitable business model, but needed VC money in order to implement it effectively. Their minimum viable product (their search technology) was already developed at that point.

I agree that MVP and lean startup are different but (very closely) related. (Specifically, you can't have the latter without the former.) But what's your point?

</comment></comment></comment><comment><USER7> As someone who is very close to both of the topics he's discussing (bootstrapping and customer development), I'd like to point out something obvious that the author has apparently missed: they're not the same thing. You can raise money and do customer development, and you can bootstrap with your head in the sand and never talk to your potential customers.

The value of customer development is that it's a model for being more efficient with whatever resources you have as you search for a fit between your product and the market.

<comment><USER5> Hi Ryan, I actually did point that out towards the end of the post. My problem is not with the ideas per se, but with the way people treat them in general. Most people equate lean startups with bootstrapping in the startup blogging world.

<comment><USER7> As far as I can tell, you do that yourself. You seamlessly switch from talking about Customer Development to lean startups to bootstrapping, as if you don't see the difference between them.

For example:

 _Since no one ever talks about the down side of the customer development approach...

...Capital is required to grow. I'm not aware of any $100 million companies built with a lean startup mindset...

...So if you can't attract a lot of capital to your idea, one possible reason is that your idea sucks._

Sorry, but I really don't see the point you're trying to make.

<comment><USER5> Hi Ryan, If we are going to just play the game of pulling random sentences and saying they are all tied together and show some kind of logical connection to what we each are trying to argue, here are my two:

...The broader idea behind customer development is that you should get close to customers early...

...The broader idea behind a lean startup is that you should be capital efficient...

Your turn.

</comment></comment></comment></comment><comment><USER8> Steve gave a good talk on the "Past, Present, and Future" of the Customer Development model at the San Francisco Lean-Startup-Circle meetup this month.

Video here: <http://www.justin.tv/s/XMP0tQg/clip/8cb0037e984e6a1f>

Slides here: [http://www.slideshare.net/sblank/customer-development- past-p...](http://www.slideshare.net/sblank/customer-development-past-present- future-steve-blank-111909)

It certainly is not a set-in-stone one-size fits all approach as many seem to believe but is very much in development itself.

<comment><USER4> Better video here:

[http://steveblank.com/2009/11/23/customer-development- past-p...](http://steveblank.com/2009/11/23/customer-development-past-present- future/)

</comment></comment><comment><USER9> I originally posted this comment on the blog post, but since it isn't going through, I'll add it here:

Sorry, but I don't have any juicy arguments for you. I agree with most of the concerns you raised here. It would be foolish for any startup to build their business in the way you described in the hotel example. In my understanding of the suggestions put forward by those exploring the lean startup methodology, the point is to be lean, not starving.

If you have a repeatable sales model, based on actual customer activity, hell yeah… go for broke. It doesn't make any sense to just grow a little bit. On the other end of the equation, it doesn't make much sense to front load your sales and marketing team with a budget of $100million based on assumptions which don't have customer actions to back it up.

All that to say, I don't understand the point of leanstartup methodology as being cheap for the sake of being cheap. But rather, not dumping money and resources into aspects of the business which haven't been verified by actual paying customers.

</comment><comment><USER10> Customer Development's unspoken premise is that web startups are in a world where market risk, not technology risk, dominates. Its usefulness is that it focuses techies like me on mitigating those market risks.

The question on my mind is whether it's too much of a greedy algorithm that moves you towards a local maximum but discourages real audacity?

<comment><USER5> Excellent point. What we found is that the risk with Backupify is technology risk.

<comment><USER11> I don't mean any offense, but how is there any technology risk?

Unless there's something non-obvious about the way the site works, I believe I could duplicate the product in two weeks with less than $10,000.

That means it's almost all market risk, i.e., the risk is in whether there is demand for it, not whether you can build it.

Something that is 100% technology risk would be, say, a cure for cancer, a new type of filesystem that improves MySQL performance by 100%, or a solar cell that is 1000x more efficient than current solar cells.

There's no question that if you created any of those there'd be demand for them -- the challenge is in the creation.

</comment></comment></comment><comment><USER12> > "We punted on tons of key issues because we wanted to wait until we proved > there was a market for our product. Once we realized there was much more of > a market than we thought, we suddenly had to allocate a bunch of resources > to customer support and bug fixes… things that we wouldn't have needed at > the same level if we had built a more robust and full featured product out > of the gate."

flat out: you're doing something wrong. coding right is faster than hacking around. i guess that's what you are saying: at some point you have to redo all the previous buggy work you've done, and adding features is a nightmare, so all the "progress" you thought you were making was totally backwards.

i'm just surprised that "point" came to late in development. once you start having real customers, as opposed to testing an idea with gradually more tech- based mockups, how can you afford _not_ to be doing things right? how you can make progress if every feature is introducing bugs? do you just ignore the bugs and keep pounding against the wall, brute force adding <crap> and trying to trick people into thinking everything is ok, keep the payments coming?

don't build your own grave. customers who expect to use your project for the long-view after you've built it require a REAL product. i sooooo wouldn't want to clean up after that mess.

</comment><comment><USER13> The typical startup that's struggling to find some sort of product/market fit would happily inherit the problems mentioned here. I don't think the lean startup model is supposed to be a smooth sail to success. It's just an efficient method for finding traction; there is no guarantee what happens (good or bad) from there on.

</comment><comment><USER14> I agree, like the commenters, that lean vs. raising money is a false dichotomy. However, there are some valid points in this post:

\- You have to be careful with product quality. In a lean startup, because you prioritize market discovery over all else, you build a culture of people used to saying "Oh, that bug only affects 1% of customers, so we can ignore it.", even after you have found your market.

\- It's hard to give up steady growth to make the kind of long-investments you know you'll have to do. IMVU had a culture of running quick A/B experiments and throwing away the loser without any deep analysis. We had gotten stuck in a local maxima with stalled business growth, and it took replacement of most of the management team to fund a six-month project to rebuild our client UI from scratch. In our case, this was absolutely the right decision. Funding anything for six months straight would have been impossible with our previous "lean startup" culture.

I, too, would like to see more discussion of lean startup edge cases. There is definitely a point where you transition out of the lean startup approach and into full-scale production.

I suspect it's very similar to the game industry's preproduction vs. production distinction: [http://www.gamasutra.com/view/feature/3847/beyond_scrum_lean...](http://www.gamasutra.com/view/feature/3847/beyond_scrum_lean_and_kanban_for_.php)

</comment><comment><USER15> Good analysis and I agree with you on using custdev as a tool in your tool kit rather than follow it like a religion. Another point, Steve always talks about shortcutting the custdev process if you happen to be the SME on the subject. If you know lot about what customers want in a area because you have experience in then you can skip portions of it.

</comment><comment><USER16> We're building a start-up based on the lean principles. The reason is simple: none of us are ready to quit our jobs until we're sure we have a winner. Call us cowards perhaps, but we have families to feed.

The problem will bulking up at the beginning is that no one will invest in your product if it doesn't exist and you'll never get started on anything. The lean approach encourages you to get off your butt and just do it.

For our situation the lean startup approach is working very well. We got a working product out the door very quickly and we're learning a lot from our first customers. Plus we're having a ball! [<http://twegather.com>]

</comment><comment><USER17> It seems to me that a central part of this argument is having "...suddenly had to allocate a bunch of resources to customer support and bug fixes...".

Building the smallest possible marketable product doesn't mean building a low quality product.

<comment><USER18> _Building the smallest possible marketable product doesn't mean building a low quality product._

This strikes me as more than a little unfair. Anyone who's actually built and deployed software knows that customer support, bug fixes, and maintenance are practically guaranteed parts of the product lifecycle.

<comment><USER19> That is true. I think the core benefit of the lean startup thing is that you'll be debugging something that people actually want and are paying for rather than debugging something which may be released to an uncaring world 18 months from now, if it gets released at all.

With regards to his point about building a hotel whose core infrastructure doesn't support 100 rooms: I think, based on the dissatisfaction with having to support customers and the price point, that he is probably talking more about scaling per-customer interaction rather than scaling in a technical sense. Scaling in a technical sense is a) a nice problem to have, kind of like having to hold your pants up because the number of Benjamins in your pockets keeps threatening to tear them off of you (hint: buy a belt) and b) is largely a solved problem for sites with less users than most nation states.

So can the lean startup help you scale out of that CS issue? I think so. First, if you treat CS incidents/bugs/etc as things to be optimized away, constant small improvements will mean you get less and less CS incidents per customer as time goes on. (Find what gives people trouble. Fix it. Repeat. I get less than 1/6th as many tech support requests per sale now as I did when I started out.)

Second, if you find your current pricing isn't attracting quite the sort of customers you want, you can always change pricing for new customers. Grandfather in the existing folks at $4 a month, and then carefully consider whether you want to be serving the market that values their data less than they do a frothy Starbucks drink. "Charge more" fixes more CS issues than any other single solution. It also has some nice side effects, such as getting you more money.

<comment><USER5> Hi Patio, As an example problem (I wrote the original post), we strongly suspected users wanted encryption of their backed up data. But when we talked with initial customers, there were certain things they wanted more that, when built, made encryption a slower, more difficult process to implement. We punted on encryption because, for the first 3 months we were in the market, there was a little demand, but not much. Then as we hit more mainstream blogs and publications and got a wider user base, encryption shot to the top of our list. So what we learned is that our first 500 customers weren't very representative of who would ultimately use the product and we shouldn't have catered to them so much. We really should have paid less attention to early customers, and more attention to related markets like PC backup, and assumed they had already figured out what the market wanted.

<comment><USER20> What about the customer development methodology urged you to make poor architectural decisions?

</comment></comment></comment></comment></comment><comment><USER5> Why is no one addressing the key issue that "customer development puts you in constant short-term thinking mode."?

<comment><USER20> Because short term thinking mode is the mode you SHOULD be in until you have something people want? That cycle is not long - get out there and see if people are interested. Dying for it? Proceed to next step. Not dying for it? Iterate.

So many years of productive lives are wasted building things nobody wants by bypassing that short term period.

</comment></comment><comment><USER21> I think this is a good point:

 _Imagine you have an idea for a new type of hotel. Would you build just two rooms and see if people liked the general idea then, if they did build 15 rooms and if those sold build 40 rooms and then eventually 100? If so, you would end up with a building whose core infrastructure was not designed to make it efficient to service and run a 100 room hotel. That is what can happen with a lean startup. You could argue that once you prove a market then you can always go back and rebuild the thing from scratch when you have more resources, but that too isn't really true._

It seems to me he is, in part, talking about the idea of "right sizing". But it also seems to me that part of the point of starting lean and using customer development is to develop the founders -- their skills in dealing with the customer, their understanding of the product and market, etc. This piece talks like it is about "the product" but towards the end makes this comment:

 _Lean startups can be attractive because they minimize your chances of failure. They allow you to string along a mediocre business for years while keeping your day job and justifying the whole thing by saying you are lean._

The above comment brings it back to development of the founder as an entrepreneur. Perhaps the author is struggling to understand what went wrong and doesn't quite know how to frame it -- which would make perfect sense because if he already understood it well enough to frame it well, the odds are good he wouldn't have made the mistakes he is frustrated by. He would have done something else (and made some other set of mistakes/discovered some other set of pitfalls).

<comment><USER5> Mz, actually, Backupify is still going strong. This wasn't a "where we went wrong" post. It was a "we built too short-sighted" post and now scaling is painful.

<comment><USER21> Sorry it made you feel defensive. Maybe you missed the fact that most of the posts before mine were quite harsh and critical. Compared to the remarks I was seeing before mine, I think my post was quite kind and evenhanded.

As for "short sighted", sometimes the best way to get to tomorrow is by making it through today. Growing pains are inevitable. It is not a question of "if" it hurts. It is a question of when and how. The things which smart tend to be somewhat personal and unique. What bothers you might not bother me and vice versa.

Peace.</comment></comment></comment>


E Ink bought for $215M - <AUTHOR> http://www.boston.com/business/ticker/2009/06/pvi_agrees_to_b.html

<comment><USER2> PVI was/is essentially the only company that actually manufactures E-Ink screens. E-Ink was basically all-IP, and PVI was basically the only significant manufacturer to license the tech to manufacture the actual screens.

I'm inserting "basically" b/c it's been awhile since I looked at things in earnest and I don't want to make absolute statements I'm not 100% sure of, but I'd be 95%+ sure that "PVI was the only mass-manufacturer of screens based on E-Ink's technology."

What I was never clear on was which way the arrangement originated: did E-Ink specifically pick PVI and contract out the manufacture of the screens, or was it the other way around?

Either way this is basically the manufacturer and sole direct licensee buying out the licensor to:

\- (1) get a long-term "discount" on licensing fees

\- (2) firm-up the exclusivity of the PVI/E-Ink arrangement: now that PVI owns E-Ink it's _very_ unlikely that E-Ink will license the tech to any other manufacturer, no?

The amount involved is probably a bargain: the demand for e-ink screens is probably going to go through the roof soon, so "locking-in" the license cost now is smart; it's also excellent timing, b/c given how much investment has been pumped into E-Ink for how long, and given the current state of the financial world, there's plenty of investors who'd probably be very happy with a relatively modest cash payout right this second (but who might have wanted more if the deal had been extended a few years back, and who might want more if the deal were extended a few years from now).

Hopefully someone better-informed on this than I am will step in and correct any errors in my summary and provide any additional background information they have.

 _NB_ : E-Ink is not the only company with "epaper" screen technology; I'm talking about E-Ink, not the general epaper market.

</comment><comment><USER3> Note to poster: It's in bad practice to change the article name. In this case it was totally unnecessary as the one point of reading this article for me was to find out _who_ bought out E Ink, which incidentally was the thing you excluded when you decided not to use the original articles title.

<comment><AUTHOR> do you know who PVI is?

i don't and think most people don't either. so using that as the first word does a worse job at conveying the point. you'd have to click it anyway to find out who PVI is.

BUT, i do agree, i should have made it "e ink acquired by __", but I think it is okay to change the article name if the new name better conveys the importance(the important thing here is e ink).

<comment><USER4> Just out of curiosity, why is E Ink the important thing here? I'm located outside of the US and I don't know who either company is, so they both hold equal importance to me. Actually if I was from Taiwan, PVI would be the important thing to me.

<comment><AUTHOR> good point. i've known about them for a decade(just by being from boston).

they make the screens in the kindle and sony ebook.

<comment><USER3> I was from the UK so Sker helped with the point I, apparently ineloquently, tried to make. I've only ever heard of E Ink in passing mention when discussions are made to the uses of ePaper in articles, if I wasn't into tech news as much as I am then I wouldn't have known that E Ink was a corporation at all.

Personally I knew who PVI was, but only because my dad's friend contracted in Singapore and then Taiwan. The thing that attracted me to the article was actually the dollar amount.

</comment></comment></comment></comment></comment><comment><USER5> "Prime View International, or PVI, of Taiwan describes itself as display provider and the world's highest volume supplier of ePaper display modules."

The deeper story seems to be that PVI parts also go into Amazon's Kindle. So this deal should cut some markup out of their manufacturing costs. Of course, they'll have to balance that against the purchase price.

</comment><comment><USER6> E Ink seems more valuable than $215M. It's a great idea, they own the patents and they are already manufacturing components. They are growing in a new sector. Or expanding into netbooks and laptops depending on who you talk to. I have to imagine that this sale is as much about getting a hold of infrastructure for faster growth as it is about making money.

<comment><USER7> I agree -- the number seemed low to me too.

That said, how much of our idea of valuations come from web apps? I was thinking about the number $215M and realized the only reason that it seems small is because Facebook is valued at $6B, or YouTube was bought for $1.6B. Outside of software, I can't think of companies that are really valued at these amounts, unless they make power plants or airplanes or some other giant necessity.

Is this how much companies are actually worth and we're all just in such a ridiculous bubble that we can't see it, or did these guys get desperate and cash out?

<comment><USER3> I'd say it's probably a mix of the two. The economy is currently rather crappy and we have no clue of the current situation of the company, perhaps they care more about getting the technology out there than making insane profits. However, the deal probably included shares in PVI and we're just not privy to that information either.

Facebook has a user base of ~200 million active users. They have an income of $300 million and only 700 employees. When you consider companies that have a fraction of their customer base, selling for $6B is pathetic. Ford, despite losing money like an alcoholic loses body fluids, has a revenue of ~$150 billion with only 5.5 million customers. Ford gets an average of $27,000 per customer 'per year' (this is based off their revenue divided by their customers, I'm trusting that with a company so old these numbers average out the money you'll give to Ford later in your vehicles life through parts, etc; so essentially the average person pays $27,000 through a vehicles lifetime), Facebook gets a total of $1.50 per customer per year. Compare Facebook to Google, who get roughly $58 per customer per year. So even by internet standards, Facebook is worthless for its user base, it hasn't capitalized at all on its potential market like Google has.

Companies like E Ink only have a handful of 'customers' and deal with large shipments. They're probably more comparable to a regional meat distributor than an online industry. They ship their product to only a handful of companies and then it's out of their hands.

The only reason so many of us know who E Ink is, is because it's used in products we care about. I believe the type of ePaper that will get a company worth into the billions will be manufacturers of color ePaper like used in the FLEPia. This offers instant conversion into low cost computers, cell phones and mp3 players.

<comment><USER8> # of customers is a horrible metric to determine the value of something. It's a holdover from the as the first metric a company could use in the bubble to get value when it's not making money and says nothing about how much that customer interacts with the company or how much value they derive from it. I might go to dmv.org every year vs. several times a day, but I am just one "customer" of both sites.</comment></comment></comment></comment>