Frustrations with React Hooks - <AUTHOR> https://blog.logrocket.com/frustrations-with-react-hooks/ <comment><USER3> I absolutely love hooks and don't want to use the `React.Component` class ever again.

And yes, hooks need to be grasped, they're quite something else. But once you get the hang of hooks, they're very simple to understand.

OP seems to be a bit stuck in a hole.

If you end up in a situation where your hooks come loose and the code becomes a mess — just delete them all and rethink your code / component logic structure. Believe me, it all can be simplified. Just rinse and repeat until you are satisfied with the outcome. That's when the "aha!" moment comes.

At the moment I only use `useEffect`, `useState`, `useRef` — the rest is unneeded so far even in my large-ish application.

P.S. sorry for the puns!

<comment><USER4> I don't understand the hate against class based components. React class-based components are dead simple to understand.

<comment><USER5> Nothing is simpler than a function. Easier to write, debug, and test.

* Removed "pure" to make my main point clear.

<comment><USER6> How are your functions pure if inside them you call `useEffect`, `useState` ? Where is pureness when at first look they generate side effects, or am I missing something ?

<comment><USER5> Not all functions needs hooks, not all hooks break pureness.

But my point was functions are simpler in all those scenarios, pure or not. Edited my comment to reflect that.

<comment><USER7> > not all hooks break pureness

Sure, if you define a function called useWhatever that doesn't actually call any hooks, that might be a pure function. But the restrictions described in [https://reactjs.org/docs/hooks-rules.html](https://reactjs.org/docs/hooks- rules.html) are not restrictions that pure functions have.

</comment></comment></comment></comment></comment></comment><comment><USER8> I was extremely skeptical of hooks in the beginning after having used class- based lifecycle components for a long time. Overall, I _think_ it's been a net positive but I end up feeling that I'm writing more code at the expense of using well defined constructs (lifecycle methods).

I usually feel like I'm writing too many effects which update state(s) and the lifecycle flow becomes harder to contain mentally, however there are times where I'm like "this is definitely easier or less of a cluster then it use to be".

So I think the jury is still out. In terms of Hook's initial premise of "we're doing this so that developers unfamiliar with class-based OO paradigms can work better/faster", I don't think it added any more clarity or ease-of-use over the class based lifecycle methods tbh.

<comment><USER9> Maybe this is because I'm a "developer[] unfamiliar with class-based OO paradigms" but I find hooks components easier to read later. You start at the top, read to the bottom, and assuming you can catch crazy indirection within a hook callback during review, that's what happened. No HOCs. No having to memorize an externally documented lifecycle order. No having to cross- reference methods against the state they update 50-60 lines up the file.

I'm genuinely curious if the difference is because I was doing tons of Recompose/HOC style components before hooks came out.

Also, just FYI, it didn't click for me until this tweet[1]:

> The question is not "when does this effect run" the question is "with which > state does this effect synchronize with"

> useEffect(fn) // all state

> useEffect(fn, []) // no state

> useEffect(fn, [these, states])

[1] [https://mobile.twitter.com/ryanflorence/status/1125041041063...](https://mobile.twitter.com/ryanflorence/status/1125041041063665666)

</comment></comment><comment><USER10> Many people aren't event aware of the unnecessary renders caused by using hooks. If your app is so tiny that it doesn't matter if everything renders all the time, then you might not be aware of your `useCallback` recreating callbacks way too often ([https://github.com/facebook/react/issues/14099](https://github.com/facebook/react/issues/14099)), or that you're not even using it in the first place. Considering that front end is probably the area of software development that attracts the largest share of people like me - self taught, no computer science background - I'd also assume that many people love the perceived simplicity of hooks without realizing that it makes their code worse.

It'll only become apparent when you app is large and complex enough that it suddenly starts to matter when things re-render and then you'll be faced with tracking down those re-renders and fixing dependency arrays everywhere.

With classes, the naive solution is the right one when it comes to preserving function identities across renders.

Not saying hooks are bad, but they're not all roses and sushine.

<comment><USER11> A lot of people don't understand that React's default behavior is to re-render _everything_.

When a component is rendered, React will recursively re-render all descendants of that component. Out of the box, React doesn't do any optimizations like "skip rendering this component if the props haven't changed". Because of that, "re-creating callbacks" isn't an issue in base behavior [0], because there's nothing that cares if it's a new function reference or not.

It's only when child components are attempting to optimize perf by comparing props and avoiding re-renders that having consistent callback function references matters (ie, `React.memo()`, `PureComponent`, and React-Redux's `connect()`).

[0] [https://reactjs.org/docs/hooks-faq.html#are-hooks-slow- becau...](https://reactjs.org/docs/hooks-faq.html#are-hooks-slow-because-of- creating-functions-in-render)

<comment><USER7> Yeah, React seems to have been designed under the assumption that DOM operations are the only thing front-end code can do that takes non-zero time. Like, here's the first line of their document describing how to use to improve performance using things like PureComponent: ([https://reactjs.org/docs/optimizing- performance.html](https://reactjs.org/docs/optimizing-performance.html))

> Internally, React uses several clever techniques to minimize the number of > costly DOM operations required to update the UI. For many applications, > using React will lead to a fast user interface without doing much work to > specifically optimize for performance.

My experience with React applications (both writing them and as an end-user) hasn't really borne this out.

<comment><USER12> Could you elaborate? Rendering perf is pretty much the least of my concerns, even on my apps which support IE10. Most "perf" problems I find are related to fetching and appropriately caching data.

<comment><USER13> Not the parent, but here's one that I hit recently:

I hoisted the state of an input box up a few layers because other parts of my app are affected by the current typed content. Since I'd been careless passing closures in as props to expensive components, they were getting re-rendered on every keystroke. It was noticeably sluggish.

<comment><USER11> Just out of curiosity, is that in production mode, or just in development?

<comment><USER13> It affected production enough to get some user complaints.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> > This is yet another JavaScript paradigm to learn. For the record, I am a > 49-year-old React fanboy. I am a freelancer and use other frameworks apart > from React, and this gives me fatigue.

Amen to that. The fact that still are in "here's a 'better' idea, let's try this" landscape in JavaScript is depressing.

I no longer jump on these new frameworks when the bandwagon flies by. I ignore postings for jobs saying they are rewriting their system in "new Framework Y!". I don't care how "pure" your new design is, I care about having it work well in the trenches.

I, too, am tired.

And old.

<comment><USER15> React Hooks and Containerizing Everything are the things this old "Webmaster" is kicking down the road until all the bugs are shaken out. I also skipped gulp and grunt and jumped straight into webpack, which I've read far too much about to understand so little.

</comment></comment><comment><USER16> Overall I think React hooks are an improvement. My codebase is usually shorter and there is a lot less typing involved.

But hooks creates abstractions the developer needs to deal with that never existed before.

Hooks are not functional because they break referential transparency of functions.

You have to track dependencies manually and hooks are more difficult than they need to be for the "componentDidMount" equivalent. If you don't get the dependencies just right you end up with things not firing or in infinite loops.

You have to wrap your functions in "useCallback" or "useRef" just so the reference doesn't change and cause infinite loops.

You can't create abstractions where a hook calls another hook. So you end up having to inline a bunch more code into your function rather than outsourcing it into a helper function.

The positional order seems like it would be easy to work around if they allowed you to pass in a key. Not sure why that isn't available.

<comment><USER17> > The positional order seems like it would be easy to work around if they > allowed you to pass in a key. Not sure why that isn't available.

IIRC it's because they implemented their own method lookup table (!) to associate with the Component object (!) but as a FIFO queue, more or less. I assume either for ideological (that's how they wanted it to work) reasons or because they (probably correctly) reasoned that loading down React apps with more strings at such a basic level would risk performance/memory problems. Plus if they did that then it'd _really_ look like a method lookup table and be more obviously Rube-Goldbergian than it already is.

<comment><USER16> They can make the string part optional. Variables and symbol tables have been staples of programming languages and compilers for ages now. It's a very standard pattern. Nothing Rube-Goldberg about it.

But React has deviated so far from both the OOP, FP, and traditional programming paradigms that now it kind of feels like hacks are needed to compensate for hacks.

<comment><USER17> I mean at the point you're writing a symbol table and associating it with an object so you can figure out which method to call in its context, probably it occurs to you that you're _entirely_ re-creating a feature the language already has (but slower and worse) rather than just _mostly_ doing so, as they are now.

</comment></comment></comment></comment><comment><USER18> I never understood the need for hooks and how it's used (the example that react doc has for useState is too simplistic for any useful pedagogical reasons) until I saw divjoy's generated code and studied how it used hooks. Then everything clicked and I've been more productive using hooks than I ever had with react classes. I can attest that cognitive load is lower with hooks than with classes.

</comment><comment><USER19> I don't agree with the author's statement that there are only two (very involved) solutions to the pagination problem (re: section titled "React relies on the order in which Hooks are called").

It can easily be solved by just setting the state in the event handler, since the state is included in the dependencies array for the fetch effect:

[https://codesandbox.io/s/dependency- array-0u3sc](https://codesandbox.io/s/dependency-array-0u3sc)

The answer to this question posed by the author?

> On line 23, the useFetch Hook will be called once on the first render. On > lines 35 – 38, pagination buttons are rendered but how would we call the > useFetch Hook from the event handlers of these buttons?

We can call `useFetch` again by triggering a re-render. This hasn't changed at all with the introduction of hooks: new props or new state still triggers a re-render.

<comment><USER20> I wondered about this too, in general I think the article misses that updating state is the key to "causing" effects. Rather than latching onto the callback model to explicitly "run" effects.

Though I'll admit getting the relationship of state and effects caused by changes to that state can be more difficult to work out mentally, I think it results in a more complete understanding of what a component actually does.

<comment><USER19> I agree it's not intuitive at first. As someone pointed out on Twitter (can't find link at the moment):

A good mental model is that the second argument to useEffect defines which pieces of state that effect syncs with.

useEffect(() => {}, undefined) // Sync with all state

useEffect(() => {}, []) // Sync with no state

useEffect(() => {}, [a, b]) // Sync with `a` & `b`

<comment><USER11> Original source was Ryan Florence:

[https://twitter.com/ryanflorence/status/1125041041063665666](https://twitter.com/ryanflorence/status/1125041041063665666)

</comment></comment></comment></comment><comment><USER21> I spent maybe 1.5-2 years working on a medium size React app and after taking maybe 6 months off, I came back to it. I started reading about React Hooks and honestly I did not fully understand them. Maybe it's just JS fatigue and me feeling like I'm trying to building a house on quick sand. Everything is always changing...

Recently I built a bolierplate JSON-api web app project in vuejs and golang (previously I was using TypeScript, Apollo GraphQL and Express). I find the terminology around vuejs much more user friendly and it comes with a router and state management built in...I try to avoid using any other JS module. The golang ecosystem is much more stable than nodejs which is a relief....I have a feeling I might just settle on vuejs + golang for all future web apps

</comment><comment><USER22> Interesting to hear someone who clearly tried to use it seriously. That said I do agree with the first comment on the article itself, he is using his "useFetch" in a very far fetched (haha) way. A hooks should not be called as a callback to an event, you should "trigger an action" (whether redux, a callback from a higher component etc.) that update a state which in turns trigger the hook. I understand this can be length / annoyingly administrative but that is the cost of the react architecture, with the payoff being to better understand the flow of the application.

<comment><USER23> I use redux and react-saga for more complex flows, sagas translate into generators and make async code flows look almost like synchronous code which is nice.

<comment><USER24> Sagas are nice to read but hard to test. IMO simpler async functions are enough. Is there any benefit to sagas that I don't see?

<comment><USER11> Sagas are a great power tool... and 95% of Redux apps don't actually need them. Using them just for basic data fetching is overkill. Sagas are most useful when you need to do complex async logic, like cancellation, debouncing, and decoupled "background-thread"-like computations.

Thunks are sufficient for most use cases, but the main thing they can't do is respond to dispatched actions.

For more info, see the Redux FAQ entry on choosing an async middleware:

[https://redux.js.org/faq/actions#what-async-middleware- shoul...](https://redux.js.org/faq/actions#what-async-middleware-should-i-use- how-do-you-decide-between-thunks-sagas-observables-or-something-else)

</comment></comment></comment></comment><comment><USER25> useEffect is such a weird name. I get that it's kinda general in usecases but whenever I see the name my first thought is "what the hell is an effect and when do I use them?" and this is coming from someone who has actually heard about effect systems. Going from componentDidMount which is a nice, clear name that dictates when the function is run, to useEffect(() => console.log("Mounting!"), []) is so confusing. I'm not super thrilled that the difference between running on mount, on new props and on unmount is implicitly determined via the second argument or returning a new function. I get that useEffect has a nice coherence and is more general but that's not always a good thing.

Not to mention the docs for useEffect just mention the one usecase of running on mount and on update and neglect to even talk about running something just on mount.

That being said, the reducer hook is amazing and a great replacement for overly complicated setState or overly simple Redux stores. Definitely reminds me of ReasonReact in a good way.

</comment><comment><USER26> What's lost in all this is that classes are simple and understandable. Introducing all these new paradigms removes that simplicity. Everyone is ready to hate on classes but they have been robust structures for a long time

<comment><USER27> I think that what is lost is that Javascript is more of a functional language than an object-oriented one and a move to hooks embraces its functional roots while eliminating numerous footguns (this), simplifying reuse, and reducing redundancy.

<comment><USER28> I don't quite see how Javascript pre-ES5 was any more of a functional language than, say, Ruby at the time (a notoriously OO language).

"It uses prototypes, not classes!" simply makes it a different kind of object- oriented.

</comment></comment></comment><comment><USER29> We've writing most new code with hooks (including the Apollo GraphQL hooks like useQuery and useMutation). Generally been really pleased with them but did get bitten hard the other day.

The value returned from useState is just a plain ol' variable like any other so it also gets captured by closures like any another variable. We had an editor that updated some state and then an event handler (defined as a closure) that did something with the state variable. The state was updated as expected but when the event fired, the closure had the original value. It can be worked around via a container/useRef (and is maybe a code smell in the first place) but it made for some painful debugging.

</comment><comment><USER30> I'm done with React. They keep re-inventing the wheel, and every iteration is full of issues that need to get resolved with yet another design principle.

<comment><USER31> I'm also frustrated with the introduction of a completely new paradigm, but to be fair to the React team, hooks are really innovative and don't re-invent the wheel at all. I, for one, have never used another framework that had anything similar to hooks.

</comment></comment><comment><USER32> Coming from a ClojureScript / Reagent background, functional components and hooks look very natural, useState being largely equivalent to reagent.core/atom. useEffect and useRef look like a logical extension of the same idea.

</comment><comment><USER33> Hooks are absolutely fantastic. However, there are still a few pain points:

\- useState with an array is bad news if more than 1 component is consuming or setting the state.The clunky alternative is to keep it in a ref & call a forceUpdate whenever you would normally call your setter

\- useCallback doesn't scratch the itch for things like document event listeners since everything inside the callback will be stale. The clunky alternative is a custom useEventCallback that keeps your callback function in a ref. (and that might not work in the upcoming sync mode)

\- linter rules can be too strict & the --fix flag can actually cause a break in your app by adding things to the dependency list. Sometimes a useEffect depends on the current value of a ref, but linter says that's a no-no. 2 useCallbacks can be co-dependent, but there's no way to write that co- dependence in the dependency list. Sometimes I want to return null before a hook. The clunky alternative for all these is a bunch of eslint-ignore comments.

<comment><USER34> > useState with an array with more than 1 component setting the state...

It sounds like you might be setting state by modifying the array and then calling the setter. This won't work:

        array.push(thing)
        setArray(array)

Instead, you have to update the array immutably, like setArray([...array, thing]).

> useCallback for event listeners

useEffect is usually the right place to set up event listeners (and has a built-in way of cleaning them up, by returning a cleanup function).

> Sometimes I want to return null before a hook.

Hooks pretty much have to be at the very top of the component, and eslint- ignore'ing those errors will probably cause weird issues later. Better to think about another way to solve the problem that doesn't involve returning early.

An issue I ran into recently: I had a modal Edit dialog with some form state that was initialized with the current values of the thing I wanted to edit. If that modal was always mounted and merely shown/hidden (<Modal isOpen={itemToEdit}/>), the state would be initialized _once_ and wouldn't update when I changed the item-to-be-edited. The fix was to unmount the dialog, and only mount it when there was an item to edit, {itemToEdit && <Modal isOpen={true}/>}

</comment></comment><comment><USER35> The dependency array is the single most important improvement that hooks bring over lifecycle methods.

You're component gets rerendered when the array changes and not when you got the right mix of lifecycle methods going.

But yes, it's not always obvious what changes you really care for.

<comment><USER36> It actually reminds me of $scope.$watch from Angular 1.

</comment></comment><comment><USER37> One major point of the author is complaining that the dependency array in an effect is only compared by reference for objects and arrays.

To me this is a feature rather than a shortcomming: I use immutable data structures all the time (with array and object spread operators it is really easy to do so) and the effect will only update when it really needs to - <USER2> only triggering a re-render (or rather reconciliation) when something has actually changed. This is in contrast to .setState() which triggered reconciliation regardless if a value actually changed.

<comment><USER38> The example in the article can be fixed very easily and doesn't require immutable data structures. If you're fetching something from a url and you don't want to fetch twice from the same url, make the dependency the url itself.

<comment><USER39> More generally, one should be destructuring object properties (since he later did that anyways) at the top of the function. It's no more typing, but isolates property usage to one spot. Then pass them into the dependency array.

Seems very convoluted to do that inside the useEffect, just to show how "it doesn't work".

Especially because often a re-run of the effect will be desirable when _some_ of the props change, not always the whole bag..

</comment></comment></comment><comment><USER40> Ah yeah, hooks are strange at first..

They didn't click for me until I read this netlify blog post: [https://www.netlify.com/blog/2019/03/11/deep-dive-how-do- rea...](https://www.netlify.com/blog/2019/03/11/deep-dive-how-do-react-hooks- really-work/)

If you think of them as mostly just syntactic sugar for closure state variables wrapped up in the module pattern, it's not so bad. (This is how some of us have been writing D3.js code for years!)

</comment><comment><USER41> Long time React user here, have started experimenting with hooks. My general sense is the useState hook is a pretty neat idea, but useEffect and friends need some work. Definitely doesn't have that same "completely makes sense, this is a great API" feel that I typically associate with React.

</comment><comment><USER42> The most fascinating thing about React Hooks is the perceived false dichotomy of hooks vs old class API. The old class API was pretty bad and could have been improved without changing the paradigm. Take componentDidMount and cdUpdate: they could have been replaced by this.onMountOrUpdate(fn) : that would have both solved the ergonomic issues and allowed multiple event listeners to be set up by multiple custom 'component enhancers' (the equivalent of custom hooks).

The market is ripe for a React like framework that keeps JSX and first class components but goes away with hooks in favour of a couple of event listeners and stuff like this.getContext(ContextName). Maybe also add MobX to easily solve state management. Vue is pretty close except JSX / first class components are an afterthought.

</comment><comment><USER43> I think the part that is hard to grasp is that React essentially has it's own runtime tangled with JS. With the introduction of hooks, there are non JS things going on, which is why React relies on the quirk of having the same order and number of hooks in your component. It also has Suspense which allows you to exit from the render function and return to that spot, which is definitely not a feature of JS. So yea, it's weird. I think the interesting question is trying to figure out what this means for the next version of React. I would like to see if it takes a page or two out of Svelte's book.

<comment><USER44> There are no "non-js things" going on. I'll grant that they're doing some out of the ordinary things in order to support hooks and suspense, but it's still just JavaScript.

Edit: If you want to see how hooks are implemented without needing to understand the React codebase, Kyle Simpson has a project that provides hooks for non-React functions, the implementation is all in one file: [https://github.com/getify/TNG-Hooks/blob/master/src/tng- hook...](https://github.com/getify/TNG-Hooks/blob/master/src/tng-hooks.src.js)

</comment></comment><comment><USER45> Great post. I've also been ranty about hooks lately but am admittedly also just learning more ins/outs of things as I go.

That disclaimer aside, my biggest gripe is that I think hooks _could_ have been done in a "works from both OO and FP components" manner, so that all of these new (legitimately) "amazing to use b/c they're not HOC" APIs like the apollo hooks/etc. could be used by both types of components.

Instead, because hooks are they only non-terrible way of using libraries (again say apollo), users/codebases are basically forced to convert their OO components over to FP.

Specifically, to me the primary innovation of hooks is not "reinventing OO back into FP", it's "the ability for reusable code to attach itself to the component lifecycle".

I.e. a hook can know when componentDidMount/componentDidUpdate/etc. happened, and do the right thing. That's the primary innovation of hooks, IMO.

That would be extremely useful for OO components too, and also very doable, like just expose a component.addComponentDidMountCallback(...) type methods (or component.addEffect(...) or frankly even useEffect could do this b/c React implicitly know which component is being invoked right now).

With something like this, I think all of the "currently-FP-only" hook libraries could have "OO-based" equivalents, that are just as pleasant to use, and users could choose which paradigm they preferred on their own.

BUT, the biggest annoyance is that libraries would have to maintain both "FP hook" and "OO hook" versions, b/c current/FP-only hooks API didn't consider OO components a constituent in the design process.

(Specifically the only deal-breaker/breaking-API-change to use FP hooks from OO (if React wanted to allow this) AFAICT is that useState returns a tuple of [value, setter] instead of a State interface with getter/setter methods. If it returned a State getter/setter, then the useState could be invoked outside of the OO render() method, but then inside of render state.get() would return the current value. AFAICT all of the other hook APIs are already "OO-compatible".)

<comment><USER46> I view the draw away from OO as a feature and not a bug. Classical OO patterns should have never been introduced into JavaScript, and it had a just fine object model, that no one ever took the time to understand properly, for those small use cases it was called for. Emphasizing the functional aspects of JavaScript, it's clear strength, is the right call.

It just seemed like it was thrown in there because Java and C# developers who were increasingly being forced to use JavaScript begrudgingly just couldn't live without their "class" keywords, so they took to the forums to make JavaScript more like a "real" language.

<comment><USER17> > it had a just fine object model, that no one ever took the time to > understand properly

Plenty of the people who dislike Javascript's prototypal inheritance model and (relatedly) scoping rules do understand them.

</comment></comment></comment><comment><USER47> I generally like writing hooks. They're fairly straightforward to understand (until they aren't, but that hasn't bitten me often yet). However, reading other people's hooks is a lot more mental overhead than the same class methods, IMO. Either you have strict coding standards around them (which are pretty hard to implement with automated tools, so hopefully your code review process never lets anythign slip through) or comprehending someone else's code takes longer. For that reason, I've stuck with classes for the time being.

<comment><USER48> This seems like a fair point about other people's custom hooks. An important situation where naming helps so people can at least see what they do, without worrying about documentation

</comment></comment><comment><USER49> I love hooks. They've simplified a lot of components with state that don't "need" to be classes.

I have run into a sort of useEffect hell at times that makes me wish for the old life-cycle components as visually I find them easier to comprehend in very "active" and more complex components. But honestly I suspect that is because I don't quite understand useeffect well enough.

</comment><comment><USER50> The TypeScript boilerplate that hooks eliminate for a react redux app is just insane. I don't think I can ever go back. For the slight bit of magic that make hooks work, you end up with such a concise function that describes the important parts and not the boilerplate.

They're not perfect. To each their own opinion. But they are what ES6 did for me to the language landscape.

<comment><USER11> Glad to hear it!

I just wrote a tutorial that shows how to use Redux Starter Kit, TypeScript, thunks, and React-Redux hooks together. Should hopefully be a big help, for the reasons you described:

[https://redux-starter-kit.js.org/tutorials/advanced-tutorial](https://redux- starter-kit.js.org/tutorials/advanced-tutorial)

</comment></comment><comment><USER51> When Hooks are not properly understood, blog posts like this one make hooks look bad. However, that is just an error from the author, which results into unnecessary and overly complicated "solutions".

Yes, Hooks take a bit of getting used to and until you get them they will be ... weird. I did a few mistakes trying hooks until I actually "got" them (the fact that I tried to use hooks without actually understanding them certainly didn't help). But learning to do them right was certainly not harder than learning the quirks of classes.

In the beginning I thought they complicate the code unnecessarily.

Until I realized they can just be extracted into custom hooks.

The real power of hooks, besides the fact they are declarative!, is composition and by means of composition they can be abstracted away as custom hooks.

React is all about declarative UI composition but lacked the "primitive" for having stateful logic composition in an elegant and declarative way.

Until hooks!

</comment><comment><USER52> Hooks are great! I can sympathise with those suffering from JS fatigue, but I don't think they are merely a prettier/different syntax for doing the same thing, they are a significant conceptual simplification. This:

`const { data, loading } = useFetch("/query", {page});`

is not only shorter than the corresponding slew of lifecycle method implementations that would be required in a class component, it's also much more direct and readable. Trying to recover the intent of code by reading the implementation of various imperative methods is painful and error-prone, whereas it's hard to imagine how the above could any more effectively communicate the intent - every single token is meaningful.

</comment><comment><USER53> From your complaint of deep comparisons in hooks, you should not be doing deep comparisons though which is the point of immutability in checking refs which is the whole craze of redux but craze meaning warranted in this case. In plain classes with redux, you usually check against a simple property or ref change anyway.

</comment><comment><USER54> Since hooks introduction, I fell in love with React. I always use useState, useEffect, useContext, useReducer...

I remember the pain building an app with redux and constant mapToState.... that was nightmare! With hooks it's so easy now.

<comment><USER11> Please check out our new Redux Starter Kit package [0]. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once

The React-Redux hooks API [1] also requires less code that `connect`.

I just wrote a tutorial for RSK that shows how to use it with TypeScript, thunks for async, and React-Redux hooks [2].

[0] [https://redux-starter-kit.js.org/](https://redux-starter-kit.js.org/)

[1] [https://react-redux.js.org/api/hooks](https://react- redux.js.org/api/hooks)

[2] [https://redux-starter-kit.js.org/tutorials/advanced- tutorial](https://redux-starter-kit.js.org/tutorials/advanced-tutorial)

<comment><USER55> (note this is not directed at redux, react-redux, or the wonderful redux- starter-kit library. I'm also a huge, huge fan of how createSlice combines action constants, action creators, and reducer handlers, all in one.)

Those react-redux hooks just exemplify the issues I have with hooks.

Yeah, potentially less code, but with more (and in some instances, completely unheard of) gotchas, more that the developer has to do to keep parity with not using hooks, and certain things dropped entirely.

I'm super interested in this discussion. I've been using React for years, and it's been smooth sailing. But somethings up with hooks, and I haven't been able to put it into words.

<comment><USER11> FWIW, the "stale props/zombie child" issues described in the React-Redux hooks docs [0] really have nothing to do with the hooks themselves. It's a combination of:

\- The long-standing problem of trying to synchronize an external synchronous state container with React's async rendering cycle

\- That our existing solution for this problem requires overriding values in context for connected components

\- The fact that context usage _require_ rendering a <Context.Provider> to update a value

\- The fact that hooks themselves do not do any rendering

So, the solution we have for avoiding stale props only works with `connect`. It's not that the hooks themselves are problematic or have inherent gotchas, it's just that hooks don't offer the specific additional capability we would need to implement that same solution in both places.

A user just put together a _fantastic_ article that dives deeper into this specific problem, and recaps how each version of React-Redux tried to solve it [1]. Highly recommended reading if you have some time.

[0] [https://react-redux.js.org/api/hooks#stale-props-and- zombie-...](https://react-redux.js.org/api/hooks#stale-props-and-zombie- children)

[1] [https://kaihao.dev/posts/Stale-props-and-zombie-children- in-...](https://kaihao.dev/posts/Stale-props-and-zombie-children-in-Redux)

<comment><USER55> Thanks for the links! That blog post is great.

I've encountered the issue before, but never knew the name. After bumping into it a couple of times I just changed up how I use react-redux.

</comment></comment></comment></comment></comment><comment><USER56> interested in hearing more people experiences with React Hooks.

<comment><USER57> I've completely stopped using class components after spending some time with Hooks in a small-to-mid-sized application.

The big wins for me were:

\- passing an empty array as the last argument of useEffect makes useEffect work in a similar fashion to the old ComponentDidMount. You can have any number of useEffect invocations in a component, and for a component that is, say, loading data from two different sources, I find having two discrete useEffects loading just what they need much more clean/intentional than putting everything into a single lifecycle method.

\- using Hooks with Context almost completely fills the giant state management hole that has been (imo) hampering React since its inception. Hooks + Context is a cleaner and more comprehensible solution than React + Redux for any application that has a reasonable amount of state complexity. For data-heavy applications, Redux may still be a good choice, but for everything else, the Hooks + Context combination is hard to beat.

<comment><USER58> How do you handle the drawback that changing the context will rerender _all_ components that use the context? Putting too much state into a single context does seem like it could cause performance issues, especially with state that changes often.

<comment><USER57> I agree that if you had a large (in the dozens, if not hundreds) number of dependent components, it could be an issue. However, I've noticed no performance degradation with my usage -- I use a top-level AuthContext component to handle user data/login state, and another for access/caching of the app's main data.

In a single view (for lack of a better term), I'd guess the largest number of components that access either context is six.

</comment></comment></comment></comment><comment><USER59> Not to sound like a jerk but I cannot help but think this dude is whining about very petty issues. I read the article and found it to contain very weak arguments.

I totally can relate to the frustration when learning new stuff, especially when you have done things one way for years. Personally, the first month or so that I used hooks in react, it wasn't pleasant, mostly due to me being uncomfortable with the additional load of learning this new convention.

Suck it up buttercup ;)

<comment><USER60> > Personally, the first month or so that I used hooks in react, it wasn't > pleasant

I didn't feel that want when picking up React originally, but I do with Hooks. That's a giant red flag in my opinion.</comment></comment>


Choosing the perfect typeface - <AUTHOR> http://www.cucumbertown.com/craft/choosing-the-perfect-typeface/ <comment><USER2> Interesting read, but I still think that people spend faaaaaaaar too much time thinking about typefaces. I just don't think they make as much of an impact on the page as people think they do.

At first glance, I thought the "elite" and "subtle" were both the same face, and likewise with the "informal"/"playful". It's only because they were blown up to a large size that I actually started noticing a tiny difference. Maybe it's just me?

To me, the overall layout of the page is far more important. eg. margins, font-size, line-height, paragraph width, etc.

The exception to my rule, that I might spend more time on, is for big newspaper style headlines. Those I treat more like images/artwork than like text, so they get commensurately more attention devoted to them.

<comment><USER3> You are wrong.

Even if you cannot readily quantify the difference between, say, Roboto and Source Sans, the difference _is_ there and your perception of either is different. The difference might be slight, but it is sufficient to skew your "2 second" impression in the wrong (or the right) direction. For example, even though Roboto and SS are almost the same typeface, Roboto in regular weight renders much heavier than Source Sans, so if you are to use for a product that is meant to exude lightness and airness, it would work worse than if you were to use SS.

Things like overall feel and the "rhythm" of a typeface take an effort to notice, quantify and rationalize, but they are of an UTMOST perceptive importance. Ever noticed the quirky lowercase "a" in Proxima Nova? Ever noticed how that "a" just steals the show if it appears in a sizes larger than 16px? No? Just pay closer attention next time ;) The same goes for HF&J's Whitney - it looks like just another sans-serif font on the surface, but it just feels _friendlier_. Try and quantify that (Kotaku uses it, go check it out).

First impression is hugely important and a typeface choice plays a very big part in it. Don't make a mistake of underestimating it.

<comment><USER4> Has that actually been studied? I mean, is there a quantifiable "2 second impression" that can be measured as different between Roboto and Source Sans? I see this kind of argument made all the time by afficionados of some aesthetic or another (microbrew fans, car nuts, etc...) and invariably the science ends up showing that e.g. wine quality can't be measured objectively at all.

My point here isn't (ahem) "You are wrong.", but more that I think you need to get some perspective about the distinction between strongly held opinion and objective fact.

<comment><USER5> Yep, there is quite a problem with that. I've recently was looking for proof that Golden Ratio aesthetical qualities are indeed the global optima for at least some categories of objects. I've found nothing.

<comment><USER3> There's at least one published study with a very large sampling base. I know because I was as skeptical as you are, then I saw the study mentioned in some design book, looked it up and it did in fact exist. I'll try and find the name, but I'm not sure if I still got the book where it was mentioned.

</comment></comment></comment></comment></comment><comment><USER6> Very interesting read ! Thanks a lot.

Right now, I'm trying to learn a few things about webdesign, and I have spent some time on typography yet. However, I know a few basics now, a few things about typography history, but I have never been able to find tutorials about the "why should I use this typeface or this other one there". It's like everybody is able to speak about typography theory but not about practice and thinking.

Someone knows where I can find other articles about practice ? Thanks !

<comment><USER7> My personal favorite is Mike Butterick's Practical Typography. He's a programmer, typographer, and lawyer and the book is entirely web based. They're static pages generated by code he wrote in Racket, a language in the Lisp family.

For a quick introduction check out a small section of the book: Typography in Ten Minutes [http://practicaltypography.com/typography-in-ten- minutes.htm...](http://practicaltypography.com/typography-in-ten-minutes.html)

The book in full: [http://practicaltypography.com/](http://practicaltypography.com/)

<comment><USER8> Practical Typography is excellent. Excellent. I think he makes some hyperbolic statements at times, but Butterick as a whole is very accessible.

The only annoyance was ignoring Butterick's plugs for his personal typefaces.

I was very happy to buy a copy of his typography for lawyers book for a friend as recompense for this resource.

<comment><USER7> I was actually okay with the plugs for his own typefaces. Since the book was free, I thought it was fair that he suggest people buy his typefaces to pay for the free product especially since many will be taking his advice to create products that are intended to make money.

But yes, an absolutely accessible and excellent resource. I've been sending to links to various pages and chapters to my friends in the hopes that they'll choose better typefaces after reading.

</comment></comment></comment></comment><comment><USER9> I really wish I could learn to analyze typefaces better, like the author. When evaluating a typeface for my projects, I usually just eyeball it, never spending more than a few minutes. I hadn't really thought of thinking about the target audience instead of just a font that simply matches the design.

There are some great tips in there that I imagine would help one pick a fitting typeface for most projects.

</comment><comment><USER10> All that time, thought and work and they ended up choosing Freight Micro?

[http://www.cucumbertown.com/craft/wp- content/uploads/2013/10...](http://www.cucumbertown.com/craft/wp- content/uploads/2013/10/freigh.png)

Look at that 'a' and the 's' (among other assorted ugliness)... ugh!

</comment><comment><USER11> Nice read, but I'm left with some questions. Thisis a website where one can find recepies and read those with the instructions _while you 're cooking_ if I'm correct. If so, I'd love to hear if the author actually studied some users in their kitchen while cooking a new recipe and using these new fonts.

<comment><USER12> We did. Infact the specimen sheets were tested with random users in their cooking environment and the reading patterns were analysed. We noticed that line heights needs to be liberal and open counter letter forms fare better in such scenarios. Again, these are pure observation based conclusions and the same fonts when tested with improved type settings have been reviewed well by the users.

<comment><USER13> How big was your sampling group?

Because what you wrote is exactly what I would've written based on common typographical sense and after sticking an iPad under my wife's nose a couple of times while she was cooking. In other words what you wrote looks made up.

<comment><USER12> Ofcource i cant claim that the sampling group was big enough for us to make a generic judgement. But for the record, we had 10 users testing it in realtime cooking environments and several others we follow closely at our curated community at facebook. What you claim as common typographic sense is not common to everyone, even in the world of design. People follow patterns and those patterns may or may not work for you in your projects. Assumptions are one thing, but validation is another. In a world where everything needs a reasoning, some process is required for answering questions like why this or why not that..

</comment></comment></comment></comment><comment><USER14> Typefaces are meaningless.

Now that I have your attention I'll blow your mind: A good typeface on a bad site does nothing but polish the turd. Designers that obsess over typefaces also generally give equal care to spacing and layout that when all put together makes for a great site.

Flipboard would never have chosen Comic Sans as a font and people that pushed Helvetica Neue would never use dancing chipmunk gifs in their layout.

<comment><USER12> True, you should not think of your redesign/design thinking about type. That will be a disaster. But somewhere along the way you need to start looking into the options available and the personality you want to deliver though your designs.

Psst! I never get people's hatred for comic sans..its a typeface designed for a purpose. Now its not anyones mistake that Microsoft started packaging it with the OS and the HR departments of the corporate world thought of it as cool to use to be friendly in communication:P

<comment><USER14> It's a low hanging fruit. That and it's also immediately recognizable so you are immediately ready to critique everything else.

</comment></comment></comment><comment><USER15> Why can't you just A/B test 50 different typefaces and measure which one best produces the user behavior that you're after?

Take the subjectivity out of it.

<comment><USER16> A/B testing is great when the value you're trying to optimize can be easily measured, such as short-term conversion rate. If your goal is "users should think the site is aesthetically pleasing", that's going to be a hard one to monitor.

<comment><USER15> But if you're running a business, that's not necessarily going to be your end goal. You want users to "think the site is aesthetically pleasing" because those pleased users [convert more / are more engaged / view more ads], whatever your key metric is. And those are typically easy to measure.

<comment><USER12> There are far more variables here to measure. First of all what constitutes that fifty you are thinking of rolling out? Lets say you arrive at it and what's next? For an engaged user the AB testing can measure up as you can define clear set of tasks and desired outcomes. But as i stated above, good type often goes invisible. People engage with the content and the not the,medium to tell you anything tangible. One cannot take away the subjectivity from the process when there is not anything tangible to measure.</comment></comment></comment></comment>


Can a Person Learn While Sleeping? - <AUTHOR> https://www.wsj.com/articles/can-a-person-learn-while-sleeping-11552744800 <comment><USER2> > Half the students were allowed to go to sleep while the words were played > back to them. The other half stayed awake while listening to the words. ... > Researchers found that those who had listened to the words while sleeping > retained much more than those who didn't sleep.

Did they compare to a group who slept without listening to the words? I'm curious whether the playback actually had any effect or whether it was just sleeping right after learning that did it.

<comment><USER3> It also might not be "learning while sleeping" but "learning before sleeping".

</comment></comment><comment><USER4> I'm 33, when I was ~17 I took a discrete math course. During class teacher posed a challenge- to find algorithm for minimal number of cross beams to make an n by m lattice rigid, so it can't flex like a parallelogram because triangles are fixing angles. I was asleep, realized I was dreaming, and decided to "work" on the problem. I found a solution, woke up and wrote it down. I think it was helpful to be dreaming because usually I cannot visualize more than simple shape, but while dreaming, I could try things out without using paper and pencil.

<comment><USER5> During my maths degree I would often try to solve problems last thing at night. If I could not solve a problem. I'd Go to sleep. I would have no recollection of solving the problem but in the morning I would often be able to immediately solve the problem.

This could have been down to a fresh brain but the speed at which I would solve the problem in the morning and pretty much just know the solution I'm convinced I was solving the problem in my sleep and then basically just writing it down when I woke.

<comment><USER6> This! The subconscious mind is FAR more powerful than the conscious mind..

It's the part of the mind which is always operating.. A sure-fire tactic is to ask yourself a question right before bed, and allow it to do it's thing

<comment><USER7> You nailed it. Most of the time, we don't even know why we just did a particular action. Our subconscious expresses an urge, and we usually just do it. Afterwards, our conscious mind rationalizes the decision with some sort of logic which people will defend to the death.

It is possible to communicate with the subconscious. In fact, it is always communicating with us. Our society is so focused on the conscious mind that we tend to not notice. This is what anxiety is. The subconscious is trying to express an unmet need. The medical field tries to suppress and numb the symptoms instead of listening to your body.

Source: Nobody told me this. I discovered this while dealing with massive personal problems over many years. Operating under this assumption is how I overcame serious addiction, anxiety and depression. Meditation is a good way to calm to conscious mind so you can "hear" your subconscious and body.

</comment></comment></comment></comment><comment><USER8> Thomas Edison would sleep on a chair holding two steel balls that would drop as he was about to enter REM sleep and wake him up so that he can immediately write down ideas he learned of while sleeping.

<comment><USER9> I recall Picasso would nap with a spoon for the same purpose.

<comment><USER10> I believe it was Dali

<comment><USER9> Seems so, thanks.

</comment></comment></comment></comment><comment><USER11> When I'm studying a subject intensely, the subject matter tends to invade my dreams, often when I'm confused by some detail I need to resolve for myself before proceeding further.

<comment><USER12> I still have this happen quite frequently when I'm mentally working through a tough programming problem, especially if that problem involves a lot of moving parts. It's like my mind is organizing its understanding of the problem during a dream, so I get bits and pieces of it.

Sometimes this leads to useful insights, but much more often I think I've solved some problem in my dream, only to wake up and immediately realize that the solution makes no sense at all. Once I do wake up though, I find that if I give myself a moment to rest and then come at the problem again, I can re- contextualize much more quickly and make quick work of the issue.

</comment></comment><comment><USER13>
      exercising well before bedtime

Get good exercise close to bedtime or exercise earlier in the day?

<comment><USER14> Probably the latter; it's a common "sleep hygiene" recommendation to avoid unnecessary exertion close to bedtime.

(scare quotes because it's really a slippery self-help kind of term that people use as though it has some concrete scientific meaning)

<comment><USER15> I suggest people try it and see how they react. I can exercise before bed just fine, but I can't do anything competitive because I get too amped up.

<comment><USER16> I'm exact same way, hit the gym for half a decade 6 days a week right before bed. No issue sleeping, but put me in front of a intense video game before bed time and I'm up for hours.

<comment><USER17> Could be the adrenaline.

<comment><USER16> yeah I think so.

</comment></comment></comment></comment></comment></comment><comment><USER18> If you are learning Chinese and want to try, I created a file a while ago. I downloaded a youtube video (sorry, can't give creds, don't have the link anymore), extracted the audio and added a long silence at the beginning, so that I actually can start sleeping. Have not tried it yet but will tonight.

Good luck: [https://ufile.io/577bn](https://ufile.io/577bn)

<comment><USER19> Will give this a try, thanks. Do you use any other techniques?

<comment><USER18> I started using anki too late. Repetitive vocabulary learning is a must. Start using Anki from the beginning.

<comment><USER20> Also trying to learn. Any decks you'd recommend?

<comment><USER18> [https://blog.timo-horstschaefer.de/chinese-anki-deck/](https://blog.timo- horstschaefer.de/chinese-anki-deck/)

<comment><USER20> Thank you!

</comment></comment></comment></comment></comment></comment><comment><USER21> [https://outline.com/Z8Nq7e](https://outline.com/Z8Nq7e)

<comment><USER22> [https://www.outline.com/dmca.html](https://www.outline.com/dmca.html)

<comment><USER23> > Because all DMCA notifications must be based on a work for which the > copyright is registered with the Copyright Office (or for which registration > has been applied for), and because a high percentage of DMCA takedown > notices are not valid, it will speed our investigation of your DMCA notice > if you attach to it a copy of your copyright registration, or registration > application, for the work.

> DMCA notifications based on unregistered works are not valid.

Heh, would only be cheekier if their DMCA <form> had file upload inputs for copyright_docs and registration_docs.

Outline seems exclusively used as a paywall bypass system in the wild. Can't be good for their longterm viability.

<comment><USER24> _" Can't be good for their longterm viability"_

Any know if/how they make money?

<comment><USER23> It's surely just in its bootstrapped growth stage.

If it wasn't for its annotation system, I'd put it in the realm of rather straightforward side projects. There are really good "readability mode" transformer libraries out there. And you can imagine buying a subscription to each of the major publications to bypass their paywall.

Paywall bypassing is something I would've expected from archiving services too but I noticed this is perhaps false. For example, [http://archive.is/ycfsk](http://archive.is/ycfsk) archived the paywall.

</comment></comment></comment></comment></comment><comment><USER25> What about the opposite? I recently (past few years) have no problem thinking and solving problems while I sleep. Surely this is something a younger me strived for.

How can I turn back to fantastic dreams, adventures and generally things of pleasure?

<comment><USER6> Why don't you ask yourself that same question right before bed one night.. 'Ask and you shall receive'

</comment></comment><comment><USER26> Sometimes when I'm working on a problem I'll put my head down and relax, breath deep, and try to get myself to nap. At the same time I think about the problem. I often find a solution that way, something about the semi-conscious brain storming works well that way. And when it doesn't, at least I had a relaxing nap :)

</comment><comment><USER27> I remember listening Rogan's podcast on the subject of sleep with Matthew Walker, who is a professor of Neuroscience at Berkley. Hopefully I'm not making stuff up as it's been a while, but he talked about a study where each subject was given a task to learn while their brain activity was being recorded. The study found that the same areas of the brain that flared up during the learning and memorization processes were also very active during sleep, as if the brain was replaying the same activity over and over again.

Edit: adding link to the podcast if anyone's interested - [https://www.youtube.com/watch?v=pwaWilO_Pig](https://www.youtube.com/watch?v=pwaWilO_Pig)

</comment><comment><USER28> Often, too often, I forget to set the sleep timer and fall asleep with the TV on. Often enough to notice, what's on TV shows up in my dreams (in some form).

I'm not sure if I could learn but I bet I could prime my brain with basics (e.g., vocabulary words in my non-native language).

<comment><USER29> I remember once having a dream where I was fighting off bad guys like a ninja, with Evanescence's "Bring Me to Life" playing as soundtrack (which had been in the Daredevil movie). When I woke up, I realized I'd fallen asleep with the song playing on a loop.

Coincidentally, the words "wake me up" and "I can't wake up" are said a total of 18 times in the song; I wonder what effect that had on me.

 _considers an experiment_

</comment></comment><comment><USER30> I feel headlines like this can be answered using simple logic. Most people want to learn many things, but are lazy. Learning while you sleep would solve this. It would be an absolutely enormous industry.

 _Want to know French, but too lazy ( "busy") to learn it? Listen to this magical audio file before/during sleep and in just x weeks you can amaze your friends and neighbors with your positively paralyzing parlezing without any of the work! Order now, just $xxx!_

So the answer is going to range between a plain "no" and a "kind of sort of in a way that can, at best, work as an extremely modest supplement to conscious learning, under best conditions." And you need not worry about missing out on some cutting edge breakthrough. If and when such things happens this would be really really big news - not something restricted to a random classically clickbaited headline with the actual article hidden behind a paywall.

I just mention this because I think our inclination is to let our curiosity get the best of us, and of course - what if there's something we've missed out on? But in the process of this, we greatly incentivize this form of faux journalism. And the nice thing is is that the above logic can be applied to absolutely huge swaths of the entire media.

</comment><comment><USER31> When I was in college, I took a Psychology class called "Altered states of conscienceness". The whole class was about how we learn and function under hypnosis, under the influence of drugs, when sleeping, etc. The overall theme of the class was that your body is always processing inputs from your senses, and different states of mind help you process differently by filtering certain things out while amplifying other things. But the same state of mind would have different outcomes for different people.

So the answer to this question is: Depends on the person, but there is nothing in the way the body works that would prevent you from learning while sleeping.

</comment><comment><USER32> Without reading the article sleeping is part of learning [0]. One idea of lucid dreaming is to "learn" during sleep.

[0] [https://web.archive.org/web/20181017190008/https://www.super...](https://web.archive.org/web/20181017190008/https://www.supermemo.com/en/articles/sleep)

<comment><USER33> I've been trying this for about 18 months now and I rarely get it, but when I do, it's really magical. I am yet to be able to "learn" anything though. I try to search my mind for what I was supposed to do when I reach a lucid dreaming state, and that waakes me up.

</comment></comment><comment><USER34> A common thing that happens to me is: Stuck on a moderately complex problem, usually in a field that I'm not intimately familiar with (ie. A complex mail server config). Work on it, feeling frustrated late into evening. Go to sleep and sort of "dream about the problem" in a loosely chaotic way.

Come morning, its not that I suddenly have a solution, but more often than not I've developed a good strategy for how to test the problem. By using this new method I'm able then to trial-and-error the problem in a systemic way, leading to a solution.

TLDR: Sleeping often gives me successful 'approaches' to problems

</comment><comment><USER35> I do all the time. Many times I am working on some bug or some complex issue. I give up on the problem for the day I go home, sleep and early morning (for some reason its always early morning) I actually solve the problem with minute details. When I wake up I know what the issue is. Happens at least once a month to me.

</comment><comment><USER36> My anecdotal experience with this comes from learning musical instruments. I've come to believe that the brain does a fair bit of rewiring when you're not paying attention to something you're trying to learn. This happens when sleeping or otherwise.

</comment><comment><USER37> I remember learning riding a bicycle in a dream. Woke up the next day and suddenly I could ride a bicycle, despite months of struggle without success. So, I guess sometimes it takes one especially lucid dream to solve an initially "unsolvable" problem.

<comment><USER38> For how cool it sounds, it seems more like you have managed to overcome the struggle than learning to ride a bike, as in you jumped on the bike for the first time in your life, in your dream, and the day after you could ride a bike in real life.

<comment><USER37> That's what I basically meant - sometimes one dream is enough to move on. Not only rational problems are being solved inside the brain while asleep. I believe that dreaming of riding a bike like it was effortless made me believe that it's actually effortless and voila, it worked.

</comment></comment></comment><comment> dane-pgp Obligatory Simpsons reference:

[https://frinkiac.com/caption/S03E23/713809](https://frinkiac.com/caption/S03E23/713809)

<comment><USER39> Curse this chicanery!</comment></comment>


IOS7 Is The Right Time To Raise Prices - <AUTHOR> http://www.bitwit.ca/blog/ios7-is-the-right-time-to-raise-prices/

<comment><USER2> No. Just no. Market will regulate itself without a collusion.</comment>


Climategate - again? - <AUTHOR> http://www.abc.net.au/news/stories/2009/12/13/2770249.htm

<comment><AUTHOR> _"... The first, and most convincing, given the forensic trail, is that a gang of professional hackers in Russia (Tomsk?) was hired by someone. The second is that the emails had been assembled by a person within the CRU in response to a Freedom of Information demand that had subsequently been blocked. This person then allowed the emails to escape 'in the public interest'. ..."_

Williams is a science reporter for the ABC Science show which I listen to ~ <http://www.abc.net.au/rn/scienceshow/> The Times article referred to in the article by _"Bryan Appleyard"_ is here ~ [http://www.timesonline.co.uk/tol/news/environment/article693...](http://www.timesonline.co.uk/tol/news/environment/article6931598.ece)

<comment><USER2> denialists, troops, mob, goons...

Can we please have a climate article without all the hyperbole? (rhetorical question. The answer is obviously "no")

This is not an either/or situation. Most likely the emails were illegally stolen but they were also the part of the data that legally needed to be released to the public. (Hence the lack of emails with lots of personal details. These emails had already been filtered as part of the preparation process. Just a guess. That and 5 bucks gets you a cup of coffee)

The "crime" here, if there is one, is refusal to allow independent verification of process (a crime against science) and refusal to allow open inspection of work progress (an ethical lapse and also perhaps a real crime of fraud, depending on how seriously you take your FOIA laws) It's not the end of climate science, just an embarrassing peek at how little clothes the emperor is actually wearing under there. Attempting to prosecute somebody for stealing information that needed to be released to the public anyway would be amusing, at best, to watch.

Nothing to see here, please move along.</comment></comment>


Show HN: Ripple – Share thoughts with people near you and beyond - <AUTHOR> http://getkefi.com/ripple

<comment><USER2> Even though this is a new app, we already have some pretty cool data: [http://cdb.io/13gKWDF](http://cdb.io/13gKWDF).</comment>


Mixcloud invites for Hacker News - <AUTHOR>

We've just launched our private beta at http://www.mixcloud.com and we're looking for beta testers. If you'd like to try it out, please sign up with invite code: hackernewscloud
The idea behind Mixcloud is to connect independent radio content to listeners - a "YouTube of radio". We'd be very grateful for any constructive criticism via the feedback tab or simply feedback AT mixcloud DOT com.
You might recognise a couple YC-ers on the site (we're good friends with the guys from Songkick, Fuzzwich, Webmynd, Muxtape, Heyzap...)
On a related note, we were one of many young companies who didn't make it onto YC last year, so we'd like to take this chance to encourage everyone to keep building - whether or not you get on the program.
All the best,
Nico and Nikhil <comment><USER2> It'd be a lot more interesting to me if I could browse at least the station list without signing up - as it is, I'm very likely to look at your page and then say "huh, that might be cool" and drift back to iTunes before I bother (realizing that you may not want this to change until your private beta period or whatever you're calling it is over).

<comment><AUTHOR> Thanks for the feedback durin42. We will definitely be opening up once we launch to the public.</comment></comment>


The first 5G phone will cost $1,300 on Verizon - <AUTHOR> https://www.cnbc.com/2019/04/25/samsung-galaxy-s10-5g-price-and-release-date-on-verizon.html <comment><USER2> Are cancer concerns justified? Seems to be a lot of noise around this, and from industry/science people this time as well.

<comment><USER3> It's hard to see how.

What industry/science people are expressing concern here? I haven't seen that.</comment></comment>


I made a dating app about going out to restaurants and everyone hated it - <AUTHOR> I made an app called Dine. It's available only for iPhone for now. Dine is a dating app focused on setting up the first date and meeting over food and drinks at the best restaurants and bars near you.
When we launched 6 months ago it seemed like everyone hated it besides some people who really saw the concept. Our attempt is make first dates actually happen which is a problem on big dating apps like tinder and happn...so may matches and never a first date.
Anyways, we made a lot of changes with our UI and some other small things. People seem to really be enjoying Dine now and the reception is very good overall.
Are their any single people or app people out there that can give me feedback on Dine? Feedback is the best way for me to improve so any lines positive or negative would be great. Just please be respectful and constructive with your responses.
You can check out Dine here but you will have to cut and paste - https://goo.gl/rqLDfJ <comment><USER2> Ya in my opinion limited it to just food and drinks(?) is a horrible idea.

If its food AND drinks, then generally a rule of thumb is you don't want a first date over dinner for example. Its a terrible return on investment. Most first dates end with one person not wanting to see the other. So its just awkward.. who pays the guy or a split. If its a guy then he's paying a ton of money for the potential to see that person again which usually won't happen

I never had a first date with anyone over a meal. It was always something where one party could easily cut it short if needed or people felt a lot of money wasn't invested in a first date.

<comment><USER3> Agreed, meal for a first date can be one of the most awkward situations ever. Best to get a drink or doing an activity like bungee jumping or a music gig.

<comment><AUTHOR> There is actually logic behind why Dine is based on going out to eat or drink. The problem with dating apps is the fact that people on apps like tinder are swiping on loads of people...when a match actually happens, what was the point of the match? Did you want to meet that person IRL from the time you swiped? Or did you want to see who you could potentially match with and then make a decision from there.

Not only do we personally feel like going out for food and drinks is the ultimate ice breaker, but because of this concept, before people send out a Dine request, they are aware that this is a commitment for actually meeting for a first date. As a result, we effectively are able to increase that match to actual date ratio so something of 50% of matches will lead to dates on Dine. Tinder is less than 10% which is terrible. Just my two cents.

<comment><USER3> People want to ascertain two things before they commit to a date:

a) if someone is a weirdo b) if that is any kind of spark at all

This is usually done by exchanging chat messages.

Meeting someone for a meal can be an amazing experience if you click, but if you don't then it can be the most painful 2 hours of your life.

>before people send out a Dine request, they are aware that this is a commitment for actually meeting for a first date.<

I'm sure your intentions are good but I hate this. It makes it sound like I'm signing a contract, rather than doing something which I should enjoy. Plus what's to stop someone just not turning up?

I don't mean to put a downer on your app, maybe it's just not for me. Sure Tinder can be frustrating a lot of the time, but people use it because it works. I have multiple friends who have got married to people they've met on it, and I've got multiple friends who just use it to get laid.

<comment><AUTHOR> You are calling out all valid things that could potentially result in flaws, but you are missing a valid factor. First, let's think, why do people join dating apps in the first place? It's because there is a desire to truly meet someone - IRL is the end game. You said Tinder works, but I really just can't agree with you on that. It really doesn't work like it used to. Too many matches and no dates and it's exactly for the reason you said, there is no contract or commitment to follow through so people just go inactive or unmatch with people they shouldn't have swiped right on in the first place.

When people are using Dine, as you mentioned they realize that this is a first date app which in result leads users to send requests out more cautiously. Yes, people need to determine if they are weirdos and that is why after a match is made users can have conversations...but people are adults and they need to use their best judgement on this just like one would do one tinder. I don't agree with there having to be a spark though. As stated, people want to get out and meet. Sometimes good looks, decent job, educated and someone with similar interests who is single is enough of a reason to meet for a dinner if not food at least a cup of coffee which can all be setup through Dine. You should totally give it a try though. To me it sounds like you don't want to have dinner as a first date, but you can make it smaller like just a drink or coffee (like I mentioned). I understand your logic though.

</comment></comment></comment></comment></comment><comment><USER4> I'm a little skeptical about following this link. Why can't you just give a direct link? Who knows where that link will lead to? I certainly don't and I'm not about to try it and become a victim of drive by downloads, etc.

<comment><USER5> Pro Tip: adding a plus sign to a goo.gl shortlink will tell you where a link goes and some stats about it. [https://goo.gl/rqLDfJ+](https://goo.gl/rqLDfJ+) . Similar for other popular URL shorteners.

<comment><AUTHOR> thanks man I appreciate it.

</comment></comment></comment><comment><USER6> This would probably be more beneficial under "Show HN"

<comment><AUTHOR> SHOW HN? What does this mean?

<comment><USER6> When links are posted they can be put into categories such as "Ask HN" or "Show HN" at the top of your screen within the orange bar.

Your post currently resides within "Ask HN".

</comment></comment></comment><comment><USER7> Do you have a longer write up on the changes you had to make? It would be beneficial for other app developers to read I think.

<comment><AUTHOR> I will post something fresh soon.

Stay tuned.</comment></comment>


Sales down, Microsoft raises prices radically - <AUTHOR> http://semiaccurate.com/2012/12/03/sales-down-microsoft-raises-prices-radically/

<comment><USER2> > The company is repeating the one still working play they have [raising > prices], circling the wagons around the enterprise market, effectively > raising the barriers to exiting.

Raising prices _lowers_ the barrier to exit because the costs of switching to another platform become that much less expensive relative to staying with the Microsoft stack.

<comment><USER3> What I took from that quote was that this was the effective MS strategy before and it worked, but that it won't work this time. So I think your response is in agreement with the article, at least the way I read it. It's hard to know for sure, though, with so much sarcasm in the article.

EDIT: Changed OP to article.

</comment></comment><comment><USER4> Why is this site not perma-banned? Every article is just anti-Microsoft, hate- filled drivel.

</comment><comment><USER5> I would have taken the article seriously if not for the website name.

</comment><comment><USER6> Ugh, another ranting raving Charlie Demerjian hitpiece on Microsoft(other candidates include Nvidia and Intel) low on facts and analysis and high on hyperbole and juvenile language. I regret clicking on the link, just like always. I don't want to even bother wasting my time on debunking this crap. The only redeeming factor in his blog is that he sometimes gets a few good leaks from industry sources on graphics cards, CPUs etc. Other than that it's just a pathetic tabloid.

<comment><USER7> It may not be the best article on the subject, but, well...let's be honest: Microsoft is in trouble. Not, as in, "going out of business" trouble. But, definitely in the _Innovator's Dilemma_ sort of trouble, and a price hike is exactly the sort of thing you'd expect from a company that isn't going to figure it out in time.

The hard fact is that Windows device sales are down 21% from last year (desktops only 9% down, but desktops are not where the market is going). Devices with a shiny new Windows version are selling significantly worse than devices with several year old Windows 7 was last year. We can't blame the sluggish economy; it was sluggish last year. ([http://techcrunch.com/2012/11/29/npd-u-s-windows-device- sale...](http://techcrunch.com/2012/11/29/npd-u-s-windows-device-sales- down-21-on-last-year-windows-8-tablet-sales-almost-non-existent/))

I wouldn't necessarily want to bet against Microsoft, as they've managed to correct major trajectory errors in the past (Internet, though one could argue their early mistakes resonate through the industry today in the form of almost _no_ major website running on Windows tech), but I'm not seeing an immediate way forward for Microsoft that doesn't end in their utter irrelevancy in a few more years. No one wants their phones, or their tablets, compared to Apple and Android (both of which are outselling Windows devices by an order or magnitude or two). The desktop is in a long slow decline. Even laptops are transforming into the thin clients long ago envisaged by Sun (even running a variant of Java in many cases), via tablets and hybrids, and Windows has no foothold there and less and less value proposition for end users.

So, if you were to waste your time "debunking this crap", you'd have to put forth some kind of compelling argument for why those scary facts about Microsoft's future aren't going to be a big deal in the long run. It'd require some pretty imaginative fortune telling about what Microsoft will do over the next couple of years to turn the tide back their way.</comment></comment>


Tumblr's banning "self-harm" blogs that promote eating disorders and suicide - <AUTHOR> http://venturebeat.com/2012/02/23/tumblrs-banning-self-harm-blogs-that-promote-eating-disorders-and-suicide/ <comment><USER2> There will certainly be folks that decry this move as limiting freedom of speech, but the reality is this:

 _Freedom of speech does not apply when you participate on a private organization's platform._

For those that strongly oppose these types of policies from social networks, I'm very much in favor of you starting your own social network to cater to tastes and generes that suit what _you_ feel is appropriate for your community.

<comment><USER3> That's true. You can't talk politics in the mall. OTOH if you actively encourage loitering then get pissed off when people loiter - you're a hypocritical asshole, and i think your property rights should be diminished.

 _edit_ very first line from <http://www.tumblr.com/about>

"Tumblr lets you effortlessly share anything."

which is a bold faced lie.

<comment><USER4> I think you're being a bit too liberal in your understanding of the word 'anything'.

I am all for free speech, but there is a long list of things like child porn, state secrets, copyrighted material, etc that I think we would all agree is not in Tumblr's best interest to not be shared effortlessly.

<comment><USER5> Which are all illegal, thus (in my mind) it is implicit. In fact, bans on the things you've listed have probably been in their Terms of Use since they turned their server on. I mean, those aren't allowed _anywhere_ , they're almost completely out of the realm of this discussion which is explicitly about banning things simply because someone doesn't like them.

</comment></comment></comment></comment><comment><USER6> Now they should also ban start-up founders who brag about working without sleep continuously for days. It also promotes living disorders and there could be teens out there that would copy this and put their health in danger.

Edit - Working sleepless nights may seem normal in the HN community. But, this is also something that puts the health in danger (sometimes even more than eating disorders). Now who is going to decide what is bad and what is not bad ?

</comment><comment><USER7> There are two things here that I wish were not socially accepted: the demonization of even small amounts of body fat, and banning content you dislike "for their own good".

<comment><USER8> How do you feel about someone livecasting their own suicide, then, to take your position to an extreme?

<comment><USER7> I consider suicide extremely sad, and would not feel particularly inclined to watch the video. Why are we even thinking about censorship in this hypothetical scenario? What good would censoring the video do?

Put a warning on it saying that it's NSFL, maybe run a free banner ad next to it for a suicide prevention hotline. Those things are reasonable, productive responses. Censorship of the video would be as symbolic as waving a flag, and about as useful.

<comment><USER8> It is not just a hypothetical. See [http://news.cnet.com/report-teen-commits- suicide-on-justin-t...](http://news.cnet.com/report-teen-commits-suicide-on- justin-tv/)

Censoring the video may actually have prevented the suicide, because viewers were egging him on. It's hard to know.

</comment></comment></comment></comment><comment><USER9> Anyone see an emerging problem here?

1)Increasingly the only places to talk are privately owned.

2)Private interests can control and prevent speech if in their domain.

Also, just wondering if Tumblr is going to be removing Tumblr blogs that have their own domains?

<comment><USER10> _> 1)Increasingly the only places to talk are privately owned._

What public places did we have to talk in forty years ago that we don't have now?

 _> 2)Private interests can control and prevent speech if in their domain._

If you own an newspaper/magazine/website/whatever you have a right to exercise editorial control over it. That's always been the case.

<comment><USER9> 1) Perhaps I should have said proportionally. More importantly, online speech didn't exist 40 years ago. And it's all happening on someone else's privately owned infrastructure to some degree.

2) We live in a world where community events are now happening in malls. Formerly publicly owned halls have been sold off. Parks have been turned into condos with civil planning concessions of 'public' play areas and child care provisions. This should be increasingly apparent where population density is higher and/or the funds to maintain public spaces is harder to come by.

<comment><USER10> _> 1) Perhaps I should have said proportionally._

I don't see how that's a problem. If I had a vegetable garden and this year was a bumper year for carrots I wouldn't be complaining that there's proportionally less potatoes.

<comment><USER9> So let me get this straight, potatoes are free speech and carrots are lack of free speech?

Um, pass the potatoes?

</comment></comment></comment></comment></comment><comment><USER11> The lubricant has been applied to the slope...

<comment><USER12> I don't think this is necessarily a slippery slope.

AFAIK (I may be wrong though) this isn't due to external pressure or some PR fiasco (coughreddit), this is something Tumblr has decided did not reflect their company ethic, and wants off their platform.

The difference between this and reddit's last run-in with offensive content is that Tumblr has shown no weakness here, whereas Reddit more than proved that a sufficiently large PR catastrophe is all it takes to change site policy.

What Reddit has encouraged is more boycotts and more PR shitstorms from 3rd parties hoping to affect change on the site. Tumblr, by acting proactively, has not opened these doors (yet). They are still their own arbiters of good taste, as opposed to opening the floodgates of mob-rule.

<comment><USER13> I seriously doubt people will quit Tumblr en masse over the site falling afoul of someone's pet cause.

This is Tumblr as a company applying its morality upon the blogs it hosts. And in doing so it is completely within its rights.

<comment><USER7> Yes, of _course_ Tumblr is acting within its rights. I've checked over the thread, and I don't see anybody suggesting otherwise.

</comment></comment></comment></comment><comment><USER14> Yet Tumblr still looks like crap on Android.</comment>


OpenADK – Open-Source Appliance Development Kit - <AUTHOR> https://openadk.org <comment><USER2> this looks an awful lot like buildroot. what are the differentiators?</comment>


Material Design Lite - <AUTHOR> http://www.getmdl.io/ <comment><USER2> previous discussion on HN: [https://news.ycombinator.com/item?id=9840682](https://news.ycombinator.com/item?id=9840682)

</comment><comment><USER3> Honest question: why would you want to use this? Material design is intended for Android native apps isn't it?

It strikes me as a strange idea:

\- Material design uses lots of UI idioms that work well for an OS (user will learn them), but not so well for a website (that needs to be instantly usable on first use, or user will leave for a competitor). The overflow icon (three vertical dots) is one example.

\- Material design is the Google "branded" look and feel. No sane web business would want to give up their own look and feel. It even strikes me as a weird choice for @minimaxir's personal blog. If you're going to skin your site with another brand's look and feel, why not Uber? Amazon? etc?

\- It's never going to feel quite right. Uncanny valley between native app and website.

<comment><USER4> Actually no, material design is suppose to unify design for the web and native apps.

Many Google properties on the web are Material Design now (Play Music, Google Photos, Google Plus...

<comment><USER5> And generally have really awful experiences on both desktop and mobile.

On desktop there is tons of wasted space, key actions are generally hidden behind pointless hidden menus or silly + buttons that do multiple things even though there's loads of space to fit multiple buttons. Google Drive, Sheets, etc. are total jokes now. And I personally find Google play music is an incredibly bad user experience now for my habits. I like listening to my thumbs up playlist (unnecessarily hidden behind a slide out menu) and I like seeing my shuffle playlist (hidden behind a button that opens an idiotic floating modal).

On mobile, everything is too spaced out so you can only see 5 out of the 50 things you might need to actually see. A perfect example is the calendar which is an unusable joke compared to the old one. Another good example is the new clock app where the alarms only show 3, and the timers are bizarrely stacked with only a tiny indicator showing there are multiple timers running.

Material is a tablet design paradigm masquerading as a total solution.

<comment><USER6> I went to go add a new spreadsheet to Google Sheets and it took me at least thirty seconds to find the big + button in the bottom right. It makes sense (sort of) on my phone where my eyes can see the whole screen but on a monitor I literally had to scan the whole page before finding the button (the bottom right corner is the _last_ place I would look for something like that!)

<comment><USER5> Who knows what they were thinking when they thought that putting it down there would be a good idea.

I personally have zero respect for Material, I think it's a complete joke. Their previous redesign, as fractured as it was, was better thought out than this not-at-all-responsive 'responsive' design.

<comment><USER7> Material has nice animations and transitions, but is a catastrophe of UX. Just look at [design.google.com]([https://design.google.com/](https://design.google.com/)).

<comment><USER5> I don't actually like the animations either, quite a few are really, really bad. Fucking idiotic in fact, and I'm not saying that lightly.

The click/tap ones are the worst offenders. Why is the animation of the button dependant on _where_ I click the button? Because it's an uneven animation my mind immediately gets drawn to it and thinks "Woah, what just happened there, did something go wrong? What was that".

And so after having done a simple action I spend a second or two with my mind replaying what just happened to try and figure out if something's wrong or not. And it still happens today, even though I know about it and I use several interfaces with Material design extensively. Because it's not consistent.

It's literally the opposite of what an animation should be. It's incredibly intrusive and unsettling instead of being subtle but reassuring you that your desired action happened.

<comment><USER7> I haven't used much Material in real life, but that's what I suspected: animations are nice, not functional.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> This is such a cool move from google. Doing material design in HTML/CSS/JS is pure win.

I am working on React.js components for this. I have already did half of them. Check out [https://github.com/pksunkara/react- mdl](https://github.com/pksunkara/react-mdl). I welcome any contributions.

EDIT: Components can be seen at [https://github.com/pksunkara/react- mdl/tree/master/src](https://github.com/pksunkara/react-mdl/tree/master/src)

<comment><USER9> > I am working on React.js components for this.

Can you just use polymer though?

<comment><USER8> You can but I didn't like it and wanted to use react.js

<comment><USER9> you can use both together if you don't care about server side rendering.

</comment></comment></comment></comment><comment><USER10> We wanted to use MDL but had already committed to Stylus and weren't willing to use a prebuilt MDL, so I am maintaining a Stylus port here: [https://github.com/xdissent/material-design- lite/tree/stylus](https://github.com/xdissent/material-design- lite/tree/stylus)

</comment><comment><USER11> I think this has been around for a little while. I remember seeing it pop up on my feed.

I think it's a great idea, but a lot of the animations are still a bit clunky (slow/choppy). Polymer still has the leg up, but this is neat for projects where you know your user base won't have access to the latest and greatest browser.

<comment><USER12> Yes, it was released last month: [https://news.ycombinator.com/item?id=9840682](https://news.ycombinator.com/item?id=9840682)

I'm looking into using MDL for a redesign for my blog. Some of the layouts (e.g. the navigation and cards) seem more efficient than using Bootstrap.

> _Polymer still has the leg up, but this is neat for projects where you know > your user base won 't have access to the latest and greatest browser._

MDL only loses support for IE9, which a) has a low market share b) will drop market share further as Win7 users upgrade to Win10 and c) heavy-duty websites have been dropping support.

</comment></comment><comment><USER13> I really don't understand the hype surrounding material design.

I get the widgets as "material" metaphor, space, motion, etc., but as I understand it the redefinition of every widget's appearance and ignoring UI conventions is the opposite of good design.

The new design language (Material Design) is not made with any apparent metaphors in mind (e.g. the "tabs" are just plain nonsensical as elements), do not convey the system status or their use in any intuitive way, and is inconsistent with the widget look users are already accustomed to (as defined by their systems and by history).

As others have mentioned, it's hard to see any real value in this outside of Google's own systems.

</comment><comment><USER14> Well this was certainly better than extracting the AngularMaterial CSS, although I preferred the semantics used for the flexbox grid in the latter.

</comment><comment><USER15> Why does this have such a heavy penalty? @dang can you comment on why this seems to have dropped off the front 3 pages?

</comment><comment><USER16> Used Polymer for a part of my team's application, but it seemed too heavy. Also, Polymer doesn't seem optimized for anything other than Chrome right now. I think Polymer is great for the web components portion of it. But I feel MDL might be better if you simply want the UI/UX design.

</comment><comment><USER17> One thing I like about material vs e.g. Bootstrap is their treatment of widgets. In particular, the range slider & toggle slider (checkbox alternative) seem common but bootstrap doesn't address these.

</comment><comment><USER18> Neat. Really like the approach.

Is anyone else noticing the distracting optical illusion in the logo when reading the first paragraph on the landing page? If I am not the only one, someone should find a way to fix it.

<comment><USER19> What are you seeing?

</comment></comment><comment><USER20> The blog template[1] looks stunning!

[1] [http://www.getmdl.io/templates/blog/index.html](http://www.getmdl.io/templates/blog/index.html)

</comment><comment><USER21> Aren't the transitions between the icon states supposed to be animated? For me (using the latest Google Chrome on Linux) they just jump from one state to the next when hovering over them.

</comment><comment><USER22> Now I can Materialize your sites :D

[http://andreapaiola.name/magpie/](http://andreapaiola.name/magpie/)

</comment><comment><USER23> this feels so much faster than the angular material :/

</comment><comment><USER24> What the hell is this?

Does google pay fanbois to pretend that they want to tattoo themselves with material design, have a material design toaster, have a material design car, etc..

Material design is bad enough in Android we don't need it anyplace else.</comment>


The Apple paradox -- how a fanatically secretive company fosters open innovation - <AUTHOR> http://www.xconomy.com/national/2010/01/25/the-apple-paradox-how-a-company-thats-so-closed-can-foster-so-much-open-innovation/

<comment><USER2> The author bungles the significance of the iPhone app platform, which is an obvious example of device lock-down and control, not any kind of departure in the direction of openness. And obviously Apple planned their Tablet in their usual secretive, top-down method of hardware design.

There are different issues here, for example company culture as far as internal and external transparency, which is very low at Apple and very high at (say) Google. Then there's Jobs's intense control of product design, which I'm sure is only to the good. Then there's being controlling of users of developers through DRM and the app store (as the only distribution channel for iPhone apps) -- I'm not sure where they're going with that (hardware support for DRM? more closed development platforms?) and I'm not sure I like it.

</comment><comment><USER3> His points about Android seem random at the end.

What does he think Google should have based the OS on? Windows, where Microsoft won't let you change the interface? OSX which isn't available for non-Apple hardware? Symbian which has tons of problems? Palm OS (you'd have to buy them first)? Write an OS from scratch (which would take years + billions of dollars).

Android is based on Linux because it's the only sensible choice, the fact that Richard Stallman has some funny netbook this week has nothing to do with it.

</comment><comment><USER4> I couldn't read your article due to the enormous banner floating over it telling me that my opinion matters.

</comment><comment><USER5> i understand apple is secretive to external parties. i couldn't quite figure out how secretive they are internally, and how that effects innovation for employees.

</comment><comment><USER6> At least the trains run on time with Apple in charge.

</comment><comment><USER7> answer is simple. it doesn't.</comment>


Tail recursion is its own reward. - <AUTHOR> http://xkcd.com/1270/ <comment><USER3> xkcd is usually funny and spot on, but this time exceptionally so - <USER2> the hover.</comment>