A Critique of React Hooks - <AUTHOR> https://dillonshook.com/a-critique-of-react-hooks/ <comment><USER2> I'm going to express something a lot of people are thinking and are being far too diplomatic about.

React Hooks are a _fucking stupid idea_ and always were.

They're basically just adding dynamic scoping to a language and framework which doesn't need it, in one of the most 'magical' and confusing ways possible. You have to care about execution order to understand exactly how they'll all work and that _will_ bite you eventually if you're building anything without knowledge of all the contexts in which it's called.

There's a reason that most languages stick to lexical scoping: you can _see_ the dependencies, in the same file.

And a large portion of the value of functional languages is that they avoid state, making magic-at-a-distance impossible.

Boilerplate is not the problem. Magic is the problem.

<comment><USER3> I never understood what was wrong with class components anyways. What did Hooks bring that couldn't be done in an easier to understand way with class components?

<comment><USER4> The problem wasn't the fact that components were classes. The problems were the React lifecycle methods. People did some crazy things with instance variables, shouldComponentUpdate, and componentDidUpdate, and especially the deprecated componentWillReceiveProps.

<comment><USER5> very much this. I had to refuse a lot of code because developers were using these in inconsistent, confusing, and actually incorrect (read buggy) ways.

</comment></comment></comment></comment><comment><USER6> An important point I don't see being made in the article or the comments is that hooks are meant as a more faithful (or at least less misleading) representation of what was going on under the hood in React already.

The problem with the JS class representation is that people already understand what classes and instances are, and that leads to incorrect inferences about how React is working. In addition to better-organized code, the hooks abstraction is partly aimed at preventing people from making those wrong inferences. This also explains why they are uncomfortable compared to classes and functions — the point is that was a false comfort because those representations are misleading.

Dan Abramov calls hooks a "missing primitive":

"Why are these models insufficient to describe React? "Pure function" model doesn't describe local state which is an essential React feature. "Class" model doesn't explain pure-ish render, disawoving inheritance, lack of direct instantiation, and "receiving" props.

What is a component? Why do you start writing it one way and then have to convert into another way? Why is it "like A but also like B"? Because it's neither. It's a thing of its own. A stateful function with effects. Your language just doesn't have a primitive to express it.

That's what Hooks are. Those missing primitives. They are library-level but conceptually they are part of the "React language". Hence the language-like "rules".

They _could_ be syntax. They _would_ be in Eff or Koka. But the benefits are not worth the friction it creates in JS."

[https://twitter.com/dan_abramov/status/1093696560280596491](https://twitter.com/dan_abramov/status/1093696560280596491)

[https://twitter.com/dan_abramov/status/1093697963350810624](https://twitter.com/dan_abramov/status/1093697963350810624)

[https://twitter.com/dan_abramov/status/1093698629708251136](https://twitter.com/dan_abramov/status/1093698629708251136)

<comment><USER7> It's interesting that the original appeal of React was that it was "just a view library", but now apparently it's more like a "language". It really shows the biases of the maintainers (the "just a library" thing being a philosophy I liked from vjeux, and the "language-likeness" being very obviously a heavy influence from sebmarkbage). The thing w/ "language-ness" (as opposed to "library-ness") is that additions and changes to a language tend to become more and more difficult to make over time because semantics deeply affect everything in the system, whereas well designed APIs in a library-oriented approach can be well encapsulated.

I've said for a while, for example, that throwing promises for Suspense is using up "escape hatches" in JS. The rule of hooks is another one of those. Eventually, the React team will run out of escape hatches to implement "React language" semantics around the real JS semantics, and I suspect at that point sebmarkbage will move on to create a new view framework (as has been the case w/ e.g. sebmack and babel/rome, Rich Harris and ractive/svelte, etc).

It'll be interesting to see if whoever steps up to maintain React at that point will be able to grok its internal complexity, and to see how the community reacts to a rift when their favorite view library team pushes for one vision but the moved-on "rockstar facebook engineer" pushes for a different vision.

EDIT: fixed name confusion (thanks, swyx!)

<comment><USER8> > and the "language-likeness" being very obviously a heavy influence from > sebmack

just a minor correction, you probably mean seb markbage, who works on React, not seb mackenzie, who made Babel and now Rome and i dont think was ever on the React team.

i agree that when seb markbage leaves, it will be a big test of React's legacy. I've called it the "Ship of Theseus" moment for React.

<comment><USER9> Got a link to Rome's docs? Babel is a little easier to google for.

<comment><USER10> [https://github.com/facebookexperimental/rome](https://github.com/facebookexperimental/rome)

It's interesting. Everything is from scratch. No depa what so ever.

</comment></comment></comment></comment></comment><comment><USER11> The reaction to react hooks has been (as far as I've seen) a little too positive, so I was looking forward to read a genuine critique.

However, I'm disappointed.

In reverse order:

> _5\. They Complicate Control Flow_

A set of contrived examples, within which the only genuinely confusing part is not related to React at all. It's Javascript's object non-equality ({ multiplier: 5 } !== { multiplier: 5 })

> _4\. The Rules of Hooks Limit Your Design_

This is an interesting section but seems to point to a pattern that would lead to serious issues given any library/paradigm. It's criticising the Rules for their inflexibility, but in this instance they're _helping_ you by pointing out the pitfalls of your approach, and encouraging you to rethink it.

An alternative way of looking at it is that it's again (like in 5) bemoaning Javascript's object inequality which is prevening the memoization here.

The other 3 bullets are pretty silly "boo new things" issues that are common to migration to any new API.

<comment><USER12> Agree, "More Stuff to Learn" isn't really a critique of hooks, it's a critique of _learning_.

<comment><USER7> TFA addresses this: it qualifies by saying learning is good as long as it's useful outside of whatever narrow scope they appear. The real criticism in that section is that hooks (and e.g. gotchas related to things like useEffect, stale closures, etc) are non-transferrable knowledge.

<comment><USER11> As others have said, I still don't really think it's applicable because learning hooks takes an hour or two, but to try and address that point: I don't really think the knowledge is non-transferable at all.

There's two aspects to learning hooks:

1\. Learning the API. This is not a "conceptual" part of learning but rather "this function name does this thing". This is the same with learning any programming API and is almost always non-transferrable (with the minor exception of some open standards, except that varying implementations of them still tend to have quirks).

2\. Learning the patterns and concepts around applying that API to problems. As far as I've seen just from TFA examples, they're very widely applicable. Memoization is widespread. Functional style is widespread. The most complex stuff handled by the quoted examples is maintaining state in nested hashtables, which is such a widespread concept that observable/immutable libraries like MobX et al & ImmutableJS et al have been written pretty much focused entirely on this problem space.

</comment></comment></comment></comment><comment><USER13> Hooks have unlocked so much power in React but still deserve critiquing. However I think the author only hinted at the major complaint I have about hooks, which is that it's no longer Javascript. It's not a function, it's sort of like type system magic. Hooks can't be nested, order matters, can't be conditionally called, and you have to understand trickier memoization to avoid bugs. It also isn't portable knowledge to other systems, like vanilla Javascript is. React is great because it's vanilla Javascript, expressions all the way down, and lifecycle methods, which everyone is used to. Hooks are a new non-vanilla-javascript paradigm with special and sometimes tricky rules. Other than, there's no reason to write React unless you're using hooks, and I wonder what the next major paradigm shift will be. I look back on all our HOCs and function as children and shudder compared to how easy it is with hooks.

<comment><USER14> > React is great because it's vanilla Javascript

What about JSX? It's very useful but it's also an absolutely huge departure from vanilla JavaScript and hides a fair amount of complexity behind what your code is actually doing.

<comment><USER15> > an absolutely huge departure from vanilla JavaScript

Doesn't it just convert to React.createElement? I wouldn't call it absolutely huge.

<comment><USER16> By this logic, what could ever be considered "huge" departure? Any new language construct "converts" to something lower level unless that language is a set of assembly instructions. I mean, Elm converts to vanilla JS but few would say it's a small departure from it.

<comment><USER17> That's just reductio ad absurdum claim.

JSX is one simple conversion while coffeescript or elm are entire turing- complete languages. It's like claiming a smiley face on the back of a receipt is no different from the Mona Lisa.

<comment><USER18> Yeah, all of the dynamic parts of JSX are Just Javascript.

You can also look at JSX and know exactly how it will compile to Javascript because it's so simple. (foo && <Component {...props} />) -> (foo && React.createElement(Component, props)).

It really is just React.createElement calls. It just isn't a huge departure.

Meanwhile, what Elm compiles to is very nontrivial. The comparison only makes sense if you never actually looked at what JSX does thus mistake it for something much more complex.

Try it out yourself: [https://babeljs.io/repl](https://babeljs.io/repl)

</comment></comment></comment></comment></comment></comment><comment><USER19> I feel that with class components I have a really good understanding of what is rendering and most importantly, when. componentDidMount, shouldComponentUpdate, PureComponent, etc. With hooks, it's much more magic. And clarity of rendering is literally the one thing I want from React.

We have two projects, one using class components and one using hooks, and working on the class components one is unexciting, straightforward, sometimes repetitious, but never confusing. When writing hooks on the other hand it's constant gotchas; can't do that here, didn't memoize this, can't call that within this, etc. fuzzing until it works as Reacts expects. And then the bloody thing still renders on every frame. Back to the drawing board to figure out the right magic incantation. Probably memoize a few more layers, ugh.

<comment><USER20> Memoization is getting me too. I end up memoizing everything, which is more verbose than I'd like. Perhaps we're missing some obvious pattern?

<comment><USER18> Though note that React.memo(Component) gives you the same behavior as React.PureComponent which is what people were tending to default to anyways.

</comment></comment></comment><comment><USER21> IMO, we've traded the complexity of `this` with the complexity of hooks. Maybe I'm weird, but I never really wrote JS that caused scoping issues, so I never found `this` to be a problem. At the very least it's a complexity that is internal to the language itself. Hooks just feel so _weird_ and alien to JS. I find them very, very difficult to reason about.

\- difficult to reason about _except for a few simple use cases_. The developer experience is nice if what you're doing is basic. But if, for example, you're aiming for 100% code coverage, unit testing hooks is an absolute nightmare.

<comment><USER22> Hooks weren't invented because of 'this' complexity though, but rather as a better way to handle reuseable code (somewhat) akin to mixins.

<comment><USER21> I'll see if I can find the link, but I recall seeing some references in the official docs, naming `this` complexity as a key inspiration for looking to hooks as an alternative to stateful classes.

<comment><USER23> It's right there in their intro to hooks in the section "Classes confuse both people and machines" [0].

[0] [https://reactjs.org/docs/hooks-intro.html#classes-confuse- bo...](https://reactjs.org/docs/hooks-intro.html#classes-confuse-both-people- and-machines)

<comment><USER24> I am far more confused by hooks than by classes and 'this'.

<comment><USER25> Also you can't really try to protect JavaScript developers from understanding _this_. It's a fundamental part of the language.

<comment><USER26> Disagree. I understand `this`, but I very, very rarely encounter situations where it doesn't mean the same thing as Java's `this`. When you work on a full-React codebase, it just doesn't really happen. We used to have weird `this` behaviour on event handlers, but arrow functions and hooks fixed this.

Not saying it's good or bad, just an observation

<comment><USER25> Right, but without understanding _this_ one doesn't really understand arrow functions either.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER27> Hooks elucidate everything I've felt wrong about React, but have not been able to put my finger on it until recently.

Hooks reveal two major things with React:

1) React developers did not understand the component paradigm that they originally went with. If they did, then they would understand how silly it is that components cannot reuse logic. This was an entire debate many years ago. Composition vs. inheritance. You don't need to throw out classes or objects to get reuse.

2) React developers do not understand functional programming. I could write an entire essay on this. But it should suffice to say, FUNCTIONS DO NOT HAVE STATE. What React hooks introduce has more in common with dynamic scoping, of older LISPs. It fundamentally breaks lexical scoping, which is _incredibly_ important for understanding code flow. You have to be constantly aware of when it's safe to use certain variables and the implications of using variables in certain scopes now. In 2020!! This is INSANE.

<comment><USER28> > But it should suffice to say, FUNCTIONS DO NOT HAVE STATE

It's funny you say that: useState is the same model functional languages use to handle mutability.

[https://docs.racket-lang.org/reference/boxes.html](https://docs.racket- lang.org/reference/boxes.html)

<comment><USER29> I think this is mostly a disagreement around terminology.

The GP is referring to _purely_ functional languages like Haskell, where functions don't have state and are referentially transparent. In Haskell, useState would have to use a monad.

Racket (and Lisp in general) has mutable state so doesn't guarantee referential transparency. You can definitely write pure functions, and that's good style in many contexts, but it's not required or enforced.

I personally agree with the GP, and assume "functional programming" to mean _pure_ functional programming. It's common to use an FP style in non-pure languages, but I think this is FP if and only if you completely avoid state.

</comment></comment></comment><comment> a-priori I've been using hooks full-time for the last year or so in a _very large_ React code base (one of the largest in the world). None of these so-called problems are real in my experience.

The first point is just whining about not wanting to learn new things -- we've on-boarded many new people onto our team in this time, and hook-based code is the easiest to understand. It's the old class-based components that are hard, and the most experienced team members work there usually to rewrite them as functional components.

The second point is only sort of true. They can interact with class-based components in a parent-child relationship. That's enough to gradually migrate your application towards hooks: any time you want to make significant changes to a component, rewrite it.

The third point is not a problem in my experience. Yes, we have rewritten some of our internal libraries as a direct result of hooks being available, not because the old ones didn't work but because we now had the tools to create a _much better API_ and took advantage of it.

The fourth point makes no sense to me. If you need to use conditions like that do something different, e.g. put the different cases ("a" vs "b") in different child components and render the appropriate one. Any programming paradigm has rules around it, and this is no different.

My response to the fifth point is "don't depend on control flow". You should be robust to evaluation order so it doesn't matter the exact order that React executes your code. If you have a execution order dependency in your code it will be highly brittle.

<comment><USER30> In my experience people abuse react components by making them too big with too much functionality. If you have a bunch of hooks tied together in a brittle way, thats not the hooks's fault. It's a good sign that you need to refactor your component into smaller sub components or move functionality out of components all together into redux or some other non UI related code. A big component with lots of logic will always be a liability whether it's hooks or classes because it will mix presentation with business logic and will rarely be well tested.

</comment></comment><comment><USER31> ClojureScript user here, with a big SaaS app using React, developed over the last 4 years or so, using the excellent Rum library, [https://github.com/tonsky/rum](https://github.com/tonsky/rum).

It seems to me that React Hooks, like so many things in the JavaScript world, solve a problem I do not have. To this day, despite being a heavy user of React, I don't even fully know what they do. I've read the "Motivation" section of the React Hooks Intro, and it seems that I have none of the problems they describe: I can (and do) easily add stateful logic via Rum mixins, and that logic is reusable across components. Also thanks to Rum mixins, complex logic is understandable and does not get all thrown into a single 'componentDidMount' function. As to "Classes confuse both people and machines", I find it hard to relate to this problem, because I don't really see any classes. I work with components that have a render function and mixins, and if you don't use any mixins, a component looks just like a function.

This tends to be a recurring theme: every once in a while I read an article about JavaScript and React, and I can't even relate to the problems, because they do not exist in my world. Another good example is hints on how to optimize apps to avoid excessive re-rendering, something I get for free with ClojureScript and immutable data structures (you can always quickly tell if two data structures are equal and avoid rendering).

<comment><USER32> You've solved the problem that hooks solve by using Rum mixins instead, and you're confused why you don't need hooks?

<comment><USER33> Have you actually used Clojurescript with React? Just any cljs library - Reagent, Rum, Re-frame, Fulcro? Maybe try it, perhaps then you'd understand why Clojure developers often get confused what problems every new hype cycle in JS/TS world is trying to solve. Because Clojure idioms often nicely turn them into something you don't have to worry about at all.

<comment><USER34> I use ClojureScript professionally, and I believe Hooks are great. Reagent, Re-frame all have tradeoffs that they've made to try and shoe-horn in a solution that Hooks cleanly provides first-class support for.

I see a lot of other Clojure users wade into discussions like these and reveal an unexamined view of the technology they use and the way that other communities are trying to solve these same problems. It's really discouraging to see people put Clojure(Script) and associated libs on a pedestal, because it removes any nuance from the discussion and makes people think that the Clojure community are a bunch of holier-than-thou zealots.

FWIW, I was (am still) super excited about Hooks and have posted a lot of things critiquing ClojureScript React wrappers in the past, but I recognize now that they are making tradeoffs that ultimately are what the authors think are in the best interest of their user base. It would really be great if you (and everyone else) would enter these discussions with the same assumption.

<comment><USER31> Ok, so, what problem do Hooks solve for me, as a ClojureScript/Rum user?

(apart from compatibility with other libraries that use them)

<comment><USER34> Here's a rundown on mixins vs. hooks: [https://reactjs.org/blog/2016/07/13/mixins-considered- harmfu...](https://reactjs.org/blog/2016/07/13/mixins-considered-harmful.html)

I haven't used Rum in anger, but I do use reagent at work, and there are compatibility tradeoffs not just with other libs but also React itself that storing lots of state outside of the component tree in a mutable ref causes.

There's potentially a lot of work to be done to support React concurrent mode, which has a measurable impact to the user experience of apps that we build. Following best practices set by the React team - including using hooks for sharing and composing behaviors - sets us up better to take advantage of that in the future.

Ultimately though you don't need to rewrite your Rum/reagent apps, but instead there's an onus on the maintainers of those libs to build scaffolding around their lib code and encourage their users to migrate in a direction that will benefit them.

</comment></comment></comment></comment></comment></comment><comment><USER35> People talk about the 'good old days' of jquery. I do think it was easier to be a web developer in those days because there weren't as many levels of abstraction. It was just your simple text editor, html and js script, that's it. And you were directly changing the DOM. But writing jQuery for complicated apps can get out of control very fast. I do not miss querying classes on an element to figure out what to do next. Nowadays I meet 'React Developers' who didn't know that you can do document.querySelector(...). They tell me without batting an eye that React makes websites faster.. and that it is faster than plain javascript. And before anyone tells me that it can make things faster through DOM diffing or what have you -- you are wrong. Situationally React could be faster than poorly written js, but in most cases it won't be and that is not its point. It doesn't magically imbue your web application with hyper speed. Quite the opposite! Its like all these layers of node, npm, React, Hooks crud built up and there are actually people junior enough that their only exposure to webdev is through this morass -- and that is sad. Not because these tools/frameworks are bad, but because web dev can be so simple and easy and they are robbed of having that in their back pocket, as a proper foundation.

</comment><comment><USER36> It's unreal that in React I have to deal with occasional infinite loops now because of hooks. Sure, React catches the loop cycle so things don't totally freeze but I don't recall ever having to deal with this before them. Weird, unexpected reference issues, missing dependency accidents requiring linters to prevent, strange programming patterns, a team member having to write a terrifying novel like [https://overreacted.io/a-complete-guide-to- useeffect/](https://overreacted.io/a-complete-guide-to-useeffect/) for something that was never really a problem before. The list goes on and on.

<comment> s-km >It's unreal that in React I have to deal with occasional infinite loops now because of hooks. Sure, React catches the loop cycle so things don't totally freeze but I don't recall ever having to deal with this before them ... missing dependency accidents requiring linters to prevent

Infinite loops and missing dependencies are/were issues with `componentDidUpdate`/`componentWillUpdate` and `componentDidMount` as well, though. On the plus side, you now have a linter which can both point out these errors and automatically fix them for you. I agree that the whole thing is a bit leaky and dumb though, but there's no way to fix that without introducing some sort of compilation/optimization step and afaik the React guys aren't really considering that at the moment.

>Weird, unexpected reference issues

Not sure I've run into this before. Do you have any examples?

>strange programming patterns, a team member having to write a terrifying novel

The first bit seems like personal preference or something, not sure what you're referring to as strange. The `useEffect` novel exists because a ton of people had built up their (incorrect) mental model of how React works with lifecycle methods and were making mistakes or running into unexpected behaviour because they assumed `useEffect` was the _exact_ same thing as `componentDidMount`.

<comment><USER36> Reference issues:

1) Needing an advanced understanding of closures. Not always, but sometimes. That "sometimes" is often unintuitive, requiring weird solutions like useRef. Good luck beginners.

2) Things like updating reducer state by using a spread object, which creates a new object which can then send a system haywire. Seems fine, and is mostly fine in most cases, but hey, oftentimes not fine, and why that's so is not always clear. So then there's memoization, and useCallback and all of these safety checks -- each with their own dependencies array that need to be checked. It's really too much tbh. There are lots of solutions out there that use proxies to check this stuff; React should have baked that into the core and completely removed that responsibility from the user unless they wanted to opt-in micromanage performance of their code.

<comment><USER28> > Things like updating reducer state by using a spread object, which creates a > new object which can then send a system haywire

This is what you should be doing and not doing this seems more likely to cause problems. Do you have an example?

</comment></comment></comment></comment><comment><USER37> I learned about Crank today:

[https://crank.js.org/blog/introducing- crank](https://crank.js.org/blog/introducing-crank)

Crank itself is interesting, but what's relevant here is the broader critique of React there.

<comment><USER38> This is really compelling - thanks for linking it. Is there a downside here? Has React responded at all? I don't hate hooks, but using async + generators like this looks so obviously better and more intuitive here; like such a clearly great, simple idea that I'm embarrassed I didn't ever think of it myself.

<comment><USER39> There was a lot of discussion in the Crank thread. Essentially, concurrent mode is the primary goal.

[https://news.ycombinator.com/item?id=22903967](https://news.ycombinator.com/item?id=22903967)

</comment></comment></comment><comment><USER40> I have some similar gripes. I find Hooks to save a bit of coding overall. I've found my functional components to be about 10-20% smaller than my class components. I'm not 100% convinced it's really worth it, though.

With class components, my state/props are clearly defined within the constructor and/or PropTypes. This makes it easy to understand the overall architecture of a component. Functional components with Hooks don't have the same sort of structure and can be difficult to understand at a glance.

One of my gripes with Hooks is that listening for async state updates requires more code/complexity than w/classes. In a traditional class component, you can add a second, optional argument as a callback which is called when the state has updated:

      setState({ myState: 'newValue' }, () => { this.doSomething(); });

With Hooks, that doesn't apply. The useState "set" function doesn't have a similar argument.

      setMyState('newState');

Instead, you need to use 'useEffect' with an optional argument:

      useEffect(() => { doSomething(); }, [myState]);

This leads to potentially having many "useEffects" scattered throughout the component.

That said, this is just my experience with Hooks after a few months of working with them. It's entirely possible that I just haven't had enough experience with them yet.

<comment><USER41> That's a misuse of useEffect.

it's much simpler to wrap the set function and just call your other function afterward like this:

``` const handleChange = (value) => { setMyState(value); doSomething(); } ```

<comment><USER40> This does not work. setMyState() is asynchronous. doSomething() would run, but not necessarily with the updated value of the state.

<comment><USER41> Then make the wrapper function async and await setMyState?

</comment></comment></comment></comment><comment><USER42> Hooks are great for simple use cases like `useState`, `useContext`, some uses of `useRef`, etc. and can make the code easier to read and reason about (while conveniently working very well with TypeScript).

The rules do start to get really tricky though with complex use cases of `useEffect` and multiple levels of nested hooks, and implementation problems are often not easy to spot or debug.

Dan Abramov has written a lot about the philosophy of hooks[0] at his site overreacted[1], I'd love to see a 'retrospective' write-up from him or another React team member about what they think the success and failures of hooks have been so far and if there are any changes planned for the future!

[0]: [https://overreacted.io/why-isnt-x-a-hook/](https://overreacted.io/why- isnt-x-a-hook/), [https://overreacted.io/algebraic-effects-for-the-rest-of- us/](https://overreacted.io/algebraic-effects-for-the-rest-of-us/), [https://overreacted.io/a-complete-guide-to- useeffect/](https://overreacted.io/a-complete-guide-to-useeffect/)

[1]: [https://overreacted.io/](https://overreacted.io/)

</comment><comment><USER43> It's a unfortunate that he doesn't include the equivalent class-based implementations of his logging quiz. Event lifecycles notoriously obscure order of execution, so I'm not sure the alternative is any clearer -- especially not with contrived examples. In my experience with both hooks and classes:

\- Hooks require substantially less boilerplate than classes.

\- Rendering optimization problems with hooks tend to take more time to identify and to fix.

There are other pros/cons, but these are the ones that affect my work most frequently.

</comment><comment><USER44> All of this reads akin to someone criticizing an apple for not being an orange. Every point is an intentional design decision. Learning new things is necessary, leaving class syntax behind was a choice, and imposing limits on (controlling) application design is the point of libraries.

The team is pushing a functional declarative pipe method of building UI applications where things are built using a straight-line series of composed functional transformations. Personally, I think supporting this method with the hooks model of handling side effects is an improvement over everything else that exists in "roll your own" UI library land. I find these style libraries more enjoyable to build with, more expressive, and better suited to building things where you need finer grain control than template style libraries like Vue, which provide a stronger degree of predictability and ease of immediate use.

That's the thing -- it's a balance. Hooks add a nicely considered and balanced degree of order to the otherwise intentionally uncontrolled-so-you-can-do-the- controlling programming model of React. React identifies as the advanced lego set with the smaller more numerous blocks that you can build the cooler stuff with, and as such will always have a certain threshold of complexity.

<comment><USER45> You didn't actually counter any of the authors' points.

This wonderful _functional declarative pipe method of building UI applications where things are built using a straight-line series of composed functional transformations_ can really suck in real world applications as he tries to demonstrate. Anyone building with hooks now can relate to hooks bringing _disorder_ to the codebase.

Has your experience been different? How did you avoid the pitfalls mentioned?

<comment><USER20> 1\. It's not more stuff to learn, it's _different_ stuff to learn, arguably less. Learning Components is not a prerequisite for learning Hooks. Or perhaps I missed the memo, as I've built an app using Hooks, and still haven't need to learn what 'componentWillMount' is supposed to do.

2\. Don't mix Components and Hooks.

3\. Agreed, change is hard. It's also the only way to avoid stagnation. In the long term, change wins. Or else we'd be programming in JS1995.

4\. Insufficient example. What is the business case for a memoized hook returning hooks? Perhaps there is a simpler design, can't comment.

5\. There is no global control flow. There is only per function component control flow, which proceeds from top to bottom. Possibly preempted by a hook/hookfn execution, if my early learning curve is to be believed. Which shouldn't matter if one is thinking in terms of 'pure functions returning jsx', as preempted functions do not return, thus have no observable effect.

Tip: Only change hook state from event handlers, never from render function code.

<comment><USER46> Unless you learnt react from non-official sources, you can't avoid learning components because they teach them first.

<comment><USER20> You'd be surprised. The only deeper dive into Components is [https://reactjs.org/docs/state-and- lifecycle.html](https://reactjs.org/docs/state-and-lifecycle.html) of the "Main Concepts" section, which I skipped in favor of [https://reactjs.org/docs/hooks-state.html](https://reactjs.org/docs/hooks- state.html) of the "Hooks" section. Haven't got to "Advanced" yet, hope to stay clear of that.

</comment></comment></comment></comment></comment><comment><USER47> I was skeptical towards hooks when it was first introduced. I was hesitant to use it. Then, I used it for a few components in my projects. I realized how much simpler my code looked, and migrated completely to hooks. No regrets.

</comment><comment><USER48> I am disappointed with the React team's decision to push functional components and hooks as the standard way of working with React. Not sure if the reason is to make React more approachable to newcomers or not, but in my experience leveraging the power of the component lifecycle through class components and decorators is the most fool-proof way to build and maintain large applications. Particularly leveraging shouldCompomentUpdate for performance and componentDidMount/componentsWillUnmount for registering and disposing of component dependencies is very easy to reason about and scale.

<comment><USER22> The reason they introduced hooks was exactly that component lifecycle and decorators/higher order components were found not to scale well in larger codebases (as experienced by the people using React at Facebook).

The useEffect pretty much provides a direct replacement for componentDidMount/componentWillUnmount.

I'm still on the fence, but so far it seems to me that using hooks makes my intent clearer than using the various lifecycle methods.

<comment><USER49> Can you provide links to articles where react devs detail the scaling issues?

I've found HOCs easy to combine and reason about if I name them carefully, and am still using them on personal projects. When people complain about HOCs not scaling well, are they primarily complaining about name collisions, or performance issues due to deeply nested components/lots of render calls?

<comment><USER50> It's primarily about naming collisions and indirection.

I covered some of the tradeoffs in this post and talk:

[https://blog.isquaredsoftware.com/2019/07/blogged-answers- th...](https://blog.isquaredsoftware.com/2019/07/blogged-answers-thoughts-on- hooks/)

[https://blog.isquaredsoftware.com/2019/09/presentation- hooks...](https://blog.isquaredsoftware.com/2019/09/presentation-hooks-hocs- tradeoffs/)

</comment></comment></comment></comment><comment><USER51> My take away from hooks is that it is pushing toward making your components simpler. One of the gotchas of hooks is that it kind of "lies" in the way it looks. Take useRef or useState for example. These things are only defined one time even though the are declared in such a way to look like they are defined over and over again each render. They are actually key lookups under the hood. This was a main point of confusion for me initially and I'm sure I'll find out more that I assumed incorrectly as I go. Auto-magic sometimes is confusing to me.

<comment><USER52> They behave like class property & method declarations. But scattered about in a function and looked up by order rather than name. This is exciting and not considered redundant and obviously a bad idea, for some reason.

</comment></comment><comment><USER53> Hooks are magic with new rules that are different from regular JavaScript. They don't follow the regular flow you'd expect it would. Requires devs to think a lot about hooks to make sure something is messing them up. Also needing eslint to make sure your code is ok, is a boy flakey.

Hooks it's like learning a new language pretty much, which is only useful for react. I'm using them because of lack of better things.

<comment> frosted-flakes Once you understand that function components aren't simple, contained functions but rather components that exist in a parent scope (React) and that React actively manages them, it's not magic at all. Also, you don't need ESLint; the rules are pretty simple.

</comment></comment><comment><USER54> Overall I think hooks are a fine addition to the React toolbox. But I think they are very easy to overuse and the complexity of hooks seems to increase exponentially. I've been involved in two code bases now where hooks are just everywhere and they were both an absolute nightmare. But I've also been involved in code bases where hooks are used more sparingly, about on par with when HoCs were used, and it's rather pleasant. In general, the more "dumb" components your app has, the more manageable it seems to be overall.

</comment><comment><USER19> My biggest worry with React is that it has restless developers with idle hands.

I have (a lot of) component code that will never be converted to hooks. Can I rely on you not to flake out and pull an Angular on me?

<comment><USER52> > My biggest worry with React is that it has restless developers with idle > hands.

That's exactly what I take hooks as a sign of. I read the papers and the code when they came out. I still don't get why they exist except to provide churn to work on. A half-reimplementation of objects with a super weird syntax in a language that already has objects seems like misguided make-work on a project that's already basically "done" except for the boring, non-flashy work of maintenance and subtler improvements.

</comment></comment><comment><USER55> I personally don't use hooks (or functional components) at all, but recently read this post from Dan Abramov about algebraic effects which makes a point (among others) the hook mechanism is a pretty simple way to implement state/effects/context in a language with algebraic effects.

[https://overreacted.io/algebraic-effects-for-the-rest-of- us/](https://overreacted.io/algebraic-effects-for-the-rest-of-us/)

<comment><USER56> Yay, just what we all needed to help us write clean, maintainable code... algebraic effects??

<comment><USER55> Honestly? Maybe it is, maybe it isn't. Imagine replacing "algebraic effects" in your question with "exceptions" \- theres no clear answer. What do you think?

</comment></comment></comment><comment><USER57> Ah, I used to be on this side of the fence. Now I've learned to love hooks, and aced the test (except for the last, extra BS, question).

Now the two issues I have with hooks still nag me in the back of my head, but are easy to get over:

\- `useCallback` still makes new function references that wouldn't happen in class-based components. as someone who starts out with `class MyComponent extends React.Purecomponent`, that bugged me.

\- easily access old props after updating. I built my components with something like `useEffect`, where mounting was considered "changing props from null to _something_", and updating was like normal:

      class MyComponent extends React.Component {
        componentDidMount = () => {
          this.handlePropsChange(null, null)
        }

        componentDidUpdate = (oldProps, oldState) => {
          this.handlePropsChange(oldProps, oldState)
        }

        handlePropsChange = (oldProps, oldState) => {
          if (didPropChange('userId', oldProps, this.props) {
            // now we know that props.userId changed, but also have access to `oldProps.userId` in case there's any cleanup that needs to happen.
          }
        }
      }

I know this is possible with functional components / hooks, but it was nice to get this stuff "for free".

</comment><comment><USER58> IMAO hooks are just a dirty hack, but sold very well. Internally in React the state of a hook is being kept and updated when you call the set function, kinda similar to vtables and context in OOP. There is no other way to do this AFAIK. It only mimics functional programming, and that's why you see the restrictions about hooks, you cannot use them outside React, cannot nest, etc..

</comment><comment><USER59> > The problem with learning about hooks is that they're not generally > applicable knowledge about computing or programming.

That's true of the hooks API specifically, but not true of the underlying abstraction. Hooks are (informally) algebraic effects - one of the coolest and most general abstractions for inspecting and manipulating a program's control flow [1, 2]. Algebraic effects are still somewhat niche and most programmers haven't encountered them in name or in practice, so in that regard, hooks are actually one of the fun cases when learning a new API is mind expanding.

[1] [https://github.com/ocamllabs/ocaml-effects- tutorial#1-algebr...](https://github.com/ocamllabs/ocaml-effects- tutorial#1-algebraic-effects-and-handlers)

[2] [https://overreacted.io/algebraic-effects-for-the-rest-of- us/](https://overreacted.io/algebraic-effects-for-the-rest-of-us/)

</comment><comment><USER60> React is great at rendering data. It should've stopped there.

<comment><USER61> After using `ember` and the wonderful `ember_data` at $PREVIOUS_FIRM, I wholeheartedly agree. React is good for what it's good for, but the community sadly did not stop there.

</comment></comment><comment><USER62> There's yet another valuable hooks critique that I recommend you to read - [https://typeofweb.com/wady-react-hooks/](https://typeofweb.com/wady-react- hooks/) (Use Google Translate to convert Polish to English)

<comment><USER63> Hahah, this is good.

> React, like socialism, perfectly solves the problems that it created.

</comment></comment><comment><USER64> I mean, I got full marks on the quiz in the article. I had to think about the code, but no more than if the same had been implemented as classes. I have been using React for a very long time though, but the areas where execution order can be confusing aren't a problem new to hooks.

One criticism of the article is that it seems to argue that you lose the ability to provide HOC (and probably render-prop) APIs if you adopt hooks in your library. But it's fairly easy to automatically turn those types of hooks into HOCs, so it actually makes sense to have the hooks API be the primary one. You can't really do it the other way around, i.e. turn a HOC into a hook.

</comment><comment><USER65> Good critique. I agree about control flow and memoization. I tend to run into issues every now and then with memoization and hook "dependencies", but I'm getting better at it.

I think 1, 2 and 3 aren't really great arguments. There's always more to learn, and it seems that class components are on the way out, and are around mostly due to backwards compatibility. But it is true that a lot of legacy code uses them. I wish they'd have started with functional components, but I can't blame the team for not figuring out all of the details in advance.

I'm curious what others think. Thanks!

</comment><comment><USER66> Feels like the author is someone who really sunk into the composed higher order component style of writing React. As someone who has coworkers who loved spreading logic into 'composable HoC' that only end up being reused 1-2x, I welcome hooks.

A single component wrapped by 3-4 HoC that each do trivial tasks always felt like mental strain rather than a helpful abstraction. My favorite was HoC's that added class component functionality to function components... just use a class.

</comment><comment><USER67> Hooks are nothing new, it's just repackaging of

[https://github.com/dominictarr/observable](https://github.com/dominictarr/observable) [https://github.com/adamhaile/S](https://github.com/adamhaile/S)

Mobx and Vue use the same technique for running computeds.

As does Solid and Sinuous, etc...

<comment><USER45> Hooks are much more a reimplementation of the component lifecycle; receiving a change stream is only one of the use cases and has very little resemblance to observables, except that they trigger a re-render "automatically".

</comment></comment><comment><USER68> A lot of times I just use a simple React class. The author's lookup map to return a lookup of other hooks, yikes. A class component would probably solve that in a more predictable way.

Don't feel dirty for doing things simply. If your functional component has entire lookup maps for hooks, it's probably too complicated as a standalone functional component to drop hooks in.

<comment><USER22> It's hard to reason about without an actual real-life use case, but the lookup thing he's doing looks extremely convoluted to me.

<comment><USER69> Right, I'd be curious to know a lot more details of the real-life use case that inspired that. My gut feeling says that there's maybe a state machine of some sort which could possibly be split into a sequence or maybe hierarchy of smaller components, but it's hard to tell specifically what the alternative might be without more details on why they thought a lookup table might be useful.

</comment></comment></comment><comment><USER70> I've read about Hooks for awhile, but they still confuse me. Maybe it's largely because I haven't experienced any of the pain points that are described as the motivation for their development, but I've used a number of state-management libraries that handle state.

Just as one example, in a lot of posts and commentary I've seen, is that hooks are replacements for both HoCs and render props.

Admittedly, I haven't yet tried to do any actual development with hooks, but I can't even figure out how to solve the problem in the example in docs for HoCs[0].

Do you pass in a hook as a prop? That doesn't seem wise. A custom hook for each data source still has the same code duplication.

The docs talk a lot about how to build individual components using hooks, but very little about tying them together.

[0]: [https://reactjs.org/docs/higher-order- components.html](https://reactjs.org/docs/higher-order-components.html)

<comment><USER50> Hooks solve a couple different problems:

\- Giving function components the ability to have internal state and trigger side effects, giving them the same capabilities as class components have had

\- Reusing logic across components

I talked about the progress from mixins to HOCs to render props to hooks in a talk at ReactBoston last year [0], which had an example of tracking mouse coordinates using all four approaches. In that sense, yes, they do replace the other techniques as a way to reuse logic.

You call them inside of your function components, like this:

        function MyComponent() {
            const [counter, setCounter] = useState(0);
            const {x, y} = useMousePosition();

            // rest of the rendering logic here
        }

[0] [https://blog.isquaredsoftware.com/2019/09/presentation- hooks...](https://blog.isquaredsoftware.com/2019/09/presentation-hooks-hocs- tradeoffs/)

</comment></comment><comment><USER71> From what I've learned using them, hooks are a tool like anything else—pushing one method as "the" way means that you make a lot of poor engineering decisions.

Hooks are like a screwdriver; great for simple stuff when you want to reduce code overhead.

Sometimes you need a power drill, though, and classes and the old-school lifecycle functions are wonderful for that.

</comment><comment><USER72> > so much to learn

it's almost like software development is a highly skilled technical profession that takes years to master?

</comment><comment><USER73> This is why I avoid hooks. I design my components to use state and I find hooks to not fit well in my applications.

</comment><comment><USER74> > The problem with learning about hooks is that they're not generally > applicable knowledge about computing or programming. They're a React- > specific thing. In 5-10 years when you're programming something completely > different your knowledge of hooks will be completely obsolete.

don't tell him about SwiftUI

</comment><comment><USER75> I really like hooks. I previously spent a lot of time in HOCs, and I find hooks much simpler. But I also have problems with #5 (control flow):

The main issue I have with hooks is that I can't easily trace why updates are being triggered in my app; this makes it hard to debug performance issues. For example, my app once got really slow, and the profiler told me that a root(ish)-level component was causing a lot of re-renders. Unfortunately, that component used multiple hooks, and the only way I was able to isolate the problem was by binary-searching, deleting hooks until the re-renders stopped.

Anyone have better ways of dealing with this?

<comment><USER4> Not sure if this helps or is relevant, but I like to think of a component as a physics function.

For example, at t = 0, the output is one thing. When t = 1, the output is another. The same way of thinking can be applied to hooks. Some hooks only execute at t = 0, and at that time, variables x, y, and z also have specific values.

Hopefully you can think this way and your values won't intertwine so much that it becomes hard to trace.

</comment></comment><comment><USER76> Interesting to finally see some criticism about hooks.

The biggest problem I have with Hooks is readability. IMO, functional components with hooks are harder to reason about since they obfuscate logic in a weird react-specific contract. Class components have a much simpler, contract and syntax. They also felt much more natural since they picked up on familiar concepts of JavaScript, albeit with a couple of drawbacks. I get the advantages of hooks, but in a way, at least to me it seems like they, at substantial cost, solve a problem which I barely ever encountered, even after building react apps for many years.

</comment><comment><USER77> I've been out of the React game for a while, and this is the first I've read about Hooks (or at least the first time I read enough to look into them). If I understand things correctly, they are automatic dependency tracking functions that will rerun as needed? Kinda like S.js [1]? Though that's different in that it's built around _only_ that functionality, not integrated into a larger system.

[1]: [https://github.com/adamhaile/S](https://github.com/adamhaile/S)

<comment><USER50> Not exactly.

I'd strongly recommend reading through the React hooks docs, as well as the other hooks resources I have linked here:

[https://github.com/markerikson/react-redux- links/blob/master...](https://github.com/markerikson/react-redux- links/blob/master/react-hooks.md)

</comment></comment><comment><USER78> Is `more stuff to learn` seriously a critique? I mean if you want to stop learning stuff then maybe, go live in your own little bubble.

The other criticisms seem a little bit like someone who doesn't understand how hooks works criticizing how hooks work because he doesn't understand how hooks work. Perhaps, he doesn't understand how hooks work because he doesn't want to learn more stuff?

</comment><comment><USER79> My only issue with Hooks has been that they are not inputs into the component. It's a step in the right direction of making React more functional I would just preferred less magic, personally.

      function Component(props, { useState, useContext }) { ... }

Of course that would break backwards compatibility with the old 2nd argument being context, so I get why they did it.

<comment> frosted-flakes That's not the only problem with your approach. It is extremely common to use the output of one hook in the input of another, and that's only possible if the hooks exist in the function body.

<comment><USER79> I don't really understand how this approach breaks what you are describing.

All I'm saying is that instead of hooks API being imported from React at global scope it could be provided as inputs into the components directly. They would still exist in the function body as you put it.

<comment> frosted-flakes Oh, I thought you meant that the hooks would be _called_ there, which was one of the many alternative proposals made after hooks were announced.

In any case, it still wouldn't work because hooks are composable. You can create your own custom hooks outside of components which can be used as if it was one of the primitive hooks. That's not possible if the primitive hooks can't be accessed outside the component scope, unless they're passed in as parameters every time the custom hook is called (and that would be a right pain in the backside).

</comment></comment></comment></comment><comment><USER80> The first three points are something that crops up in any moderately used library/framework, one way or another. Seemed a little bit like nitpicking.

The last two, now, do look like they can turn into serious problems (and a lot of confusing code) if one isn't careful.

Then again, I write this as someone who mostly uses, and vastly prefers, Vue so it's not like I'm an authority on react.

</comment><comment><USER81> I've found hooks incredibly easy to reason about, and I'll happy take the bit of magic that goes along with it. (Anyway, I don't see any of you criticizing JSX for being magic.) On the other hand, I really like functional programming, so I've seen the entire development path of react as positive.

</comment><comment><USER82> One thing that baffles me is that no one has brought up that hooks don't have an obvious context.

For instance, if I have a single app and component, and use a hook, I understand that the hook and app have some sort of implicit connection.

But what happens when I have two distinct react apps on a page - does that break the ordering that hooks require? How does a hook have any affinity to the app, or does that even matter?

I'm sure looking at the code will cause a "oh, I get it" moment, but that doesn't mean it's obvious to anyone just picking up hooks.

Honestly, I think hooks are fine, but I'd almost prefer a signature like `const MyComponent = (props, { ...hooksHere })` so there's at least a false affinity between the application and the component.

<comment><USER50> The ordering question is literally just about how you call them within a single specific component. That component can then be used as many times as you want, in as many apps as you want.

In other words, this is not legal:

        const [stateA, setStateA] = useState(false);

        if(stateA) {
            const [stateB, setStateB] = useState(42);
        }

Call as many hooks as you want, in whatever sequence you want. Just make sure all the calls are at the top level of that function component, and that you don't somehow change the sequence of those from one render pass to the next.

As for how they work, React already has metadata that describes each component in the tree. There's a specific field in those metadata objects that gets used for tracking internal component state, and for function components, that field stores an array / linked list of the hook calls you've made and their last saved results.

See these resources for more explanations on how hooks are implemented:

[https://github.com/markerikson/react-redux- links/blob/master...](https://github.com/markerikson/react-redux- links/blob/master/react-hooks.md#understanding-hooks-concepts)

</comment></comment><comment><USER83> I never got into React, but seeing it compared to Svelte I find it hilariously convoluted. Hooks make it even worse.

</comment><comment><USER56> The universe is stateful; no matter how hard FP zealots try to abstract that out of code, they will never change this fundamental fact.

<comment><USER84> Nonsense. These are all just techniques for modeling reality, not reality itself.

You could model the universe just as accurately as a stateless function of time as you could as a stateful entity that moves through time.

<comment><USER56> The further you get from the true representation of the thing you're trying to model, the more difficult reasoning about it becomes. I'm all for abstractions that result in a net positive... I simply believe that FP is less about improving computing and more about ego.

</comment></comment></comment><comment><USER85> I don't think this is a great critique, simply because the pain I've encountered using them isn't mentioned here. The incompatibility with class components is what it is, they're different programming paradigms that you have to choose between. If your library leaned heavily into HOCs, that was an unfortunate choice and I'd recommend making a new library because HOCs were always unwieldy and had problems with composition. Nothing to do with functional components or hooks really, just a very heavy pattern that can typically be done better with another approach like render props.

I guess I see a lot of this as evolutionary. It's unfortunate that there has been so much change, and the timing might not be great for some projects, but I would not prefer a world where I was still writing and using HOCs and class components.

In my day job I work on a pretty old (in React years) project, and we haven't had trouble writing new code in a functional + hooks style. Still plenty of class components abound.</comment>


Calm down Dell is not throwing Ubuntu Linux out - <AUTHOR> http://www.itworld.com/open-source/115316/calm-down-dell-not-throwing-ubuntu-linux-out <comment><USER2> When I was looking for a laptop to buy recently, it never occurred to me that Dell might offer an Ubuntu system over the phone without also offering it on their (UK) website.

</comment><comment><USER3> There is _no_ B3 bomber.</comment>


Breach at Sonic Drive-In May Have Impacted Millions of Credit, Debit Cards - <AUTHOR> https://krebsonsecurity.com/2017/09/breach-at-sonic-drive-in-may-have-impacted-millions-of-credit-debit-cards/ <comment><USER2> Maybe I'm a little ignorant on how/why companies store this sort of info. Someone at work informed me that Target storing CC numbers at least made sense when you needed to make a return. But at a Sonic Drive-In? I'm not returning my burger+shake combo.

What is possessing Sonic to keep the number any longer than the period it takes to receive money from the CC company? And why is this period any longer than the 20 or so seconds it takes to process the card at a machine? Are all of these magnetic-only or do they store CC numbers with chip cards as well?

<comment><USER3> It is a good way to track customer's buying habits. eg how many people go weekly, or to different stores, or buy same products etc. eg HomeDepot tracks credit card back to userid [https://consumerist.com/2013/01/16/home-depot- sort-of-explai...](https://consumerist.com/2013/01/16/home-depot-sort-of- explains-how-an-in-store-purchase-can-result-in-e-mails-from-its-website/)

<comment><USER4> For that it should be good enough to just store the first 6 digits and the last 4 digits of the card number. You might occasionally get two different customers whose first 6/last 4 are the same but it should not happen often enough to be a significant issue.

If even that small risk of conflating two different customers is too high, you could go with a hash of the credit card number.

If you go with the hash, then don't ALSO store first 6/last 4. A typical credit card number is 16 digits, and one of those is a check digit. If someone gets a hold of the hash, and first 6/last 4, then there are only 100 000 possible values for the missing 6 digits (10^5, not 10^6, because for any guess for 5 of the digits there is only one possible 6th digit that will make the checksum work). Unless you use a very very slow hash function, brute forcing 100 000 possibilities will be quick.

<comment><USER5> The first four digits are pretty generic. They tell you who issued the card. Many people will have the same first four digits. Maybe the second set of four and the last set of four would be better?

Usually the first four is the issuer and whatever numbers signify the specific type of card. The next set is the bank, I think. The third set is, as I recall, the account number, and the last numbers equate to your routing number.

Actually, just the last eight digits should be adequate. Hash them with a salt based on the last name and collisions are very, very unlikely. Don't store them at all, just store the hashes.

<comment><USER6> I can't tell if you are playing, but by storing the most unique part of the credit card with last name you are not reducing the desirability of the target much.

<comment><USER5> You don't store the name. You use the name to generate the salt and hash the results. You only store the hashes.

<comment><USER6> You are still doing a near lossless transformation of the unique part of the credit card and name as one of your goals is zero (minimized) hash collisions. The character set and length of the input plus reasonable assumptions about the salt and hash make it very likely "reversible" using rainbow tables or other brute force techniques.

Choose metadata that doesn't have such high financial value. Additionally, it's been years since I've been involved in e-commerce and the details are now foggy, but if I recall storing those addition credit card digits, even transformed, will prevent you from achieving the industrial certifications.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> So I'm pretty ignorant to the history of personal identity/credit breaches, but for those who aren't, is this only getting to get worse? More and more companies are holding more and more data, to the point that these breaches seem to affect so many people. I entered the credit card game pretty recently, and almost immediately I'm affected by the Equifax breach. As a young person, this doesn't make the future of privacy/security seem so promising.

<comment><USER8> The news looks bad, but reality is worse. Remember that huge trove of NSA hacking tools and exploits that dumped last year? And the numerous follow-up dumps? There are LOTS of new weapons in the hands of everyone from everyday script kiddies to organized crime to enemy nations.

It's possible Equifax was the only credit agency with enough information to require public disclosure... if Transunion doesn't have the right logs or monitors, they may never find out they've been breached, and nor will we.

At this point, I assume everything on a computer can become public.

<comment><USER9> This talk seems to always be relevant:

[https://vimeo.com/135347162](https://vimeo.com/135347162)

Abstract: In this bleak, relentlessly morbid talk, James Mickens will describe why making computers secure is an intrinsically impossible task. He will explain why no programming language makes it easy to write secure code. He will then discuss why cloud computing is a black hole for privacy, and only useful for people who want to fill your machine with ads, viruses, or viruses that masquerade as ads. At this point in the talk, an audience member may suggest that Bitcoins can make things better. Mickens will laugh at this audience member and then explain why trusting the Bitcoin infrastructure is like asking Dracula to become a vegan. Mickens will conclude by describing why true love is a joke and why we are all destined to die alone and tormented. The first ten attendees will get balloon animals, and/or an unconvincing explanation about why Mickens intended to (but did not) bring balloon animals. Mickens will then flee on horseback while shouting "The Prince of Lies escapes again!"

<comment><USER10> That is the most hilarious abstract I have ever read in my life.

<comment><USER9> The talk itself is just as funny too, please do watch it fully. It's not chock full of evidence, but it has some good points and some great entertainment.

</comment></comment></comment></comment></comment><comment><USER11> I'm surprised Krebs end up plugging chip-and-PIN instead of the current leapfrog technology exemplified by Apple Pay. I feel there is not enough awareness of just how much more secure this is.

A huge advantage of Apply Pay is that you get the security of a PIN without the hassle of entering a PIN -- or the risk of it being stolen during PIN entry. You just authenticate with your fingerprint or, soon, your face. (Please no comments speculating that this is less secure than a fingerprint. It's premature to say and unless you know something Apple doesn't, you're probably wrong.)

Another less understood advantage is that Apple Pay takes the strongest approach to tokenization, which makes it effectively immune to merchant hardware compromises. Even chip cards rely on the card readers at points of sale to handle tokenization, so a hacked reader could in theory leak PANs. On top of that, lots of merchants/processors don't even bother with tokenization, so it's a crap shoot with every merchant.

Apple Pay tokenizes when you enroll your card, so the PAN (primary account number) never passes through any merchant systems anywhere ever. This means the tokenized numbers that hackers could steal from merchants are useless outside of two-factor-secured Apple Pay.

<comment><USER12> > A huge advantage of Apply Pay is ... without the hassle of entering a PIN

You are forgetting that tools like Apple Pay are not hassle free for most people, especially those outside of IT circles. Millions of people struggle to use anything beyond basic technology (American banks have even decided that PIN's are too confusing! A four digit number that has been common in the rest of the world for decades!). Combine that with other factors like fears of being caught with a flat battery or businesses that are reluctant to spend money on new POS devices - it's unlikely that plastic cards are going away anytime soon.

Also, I'm not sure entering a PIN is really any more hassle than using a phone as a payment device (I use Android Pay whenever I can due to the added security features but the POS readers are often incredibly slow).

<comment><USER11> Not sure what you're talking about. Apple Pay is so much easier and more pleasant to use than chip-and-PIN. It is designed to be easier for the average consumer.

And in terms of speed, are we living on the same planet? Chip-and-PIN is _notoriously_ slow in the U.S. Apple Pay takes a second.

Also I'm not saying plastic will go away anytime soon. There will be legacy terminals. I'm saying Apply Pay and its ilk are superior to chip-and-PIN, a two decade old technology.

<comment><USER12> > are we living on the same planet?

Are we? I assume you have never experienced the requests for support from tech illiterate relatives since childhood for assistance with VCR's, PC's, basic cell phones, printers, anything USB related in the 90's, scanners, cable boxes, modems, endless websites/web applications, and of course, smartphones. Demographic changes are shifting the definition of "average consumer" but boomers still dominate and many of them struggle with technology.

Chip and PIN is indeed slow in the US (I grew up elsewhere and travel regularly so it drives me insane) but the experience with Android Pay isn't necessarily faster or more convenient. Like I said, I use Android Pay whenever I can but I don't recall ever seeing another person using their smartphone to pay in a store.

A quick search seems to suggest this is more than just anecdotal:

[http://fortune.com/2017/08/04/apple-pay-samsung-mobile- payme...](http://fortune.com/2017/08/04/apple-pay-samsung-mobile-payments/)

"Despite much publicity upon launch, Apple Pay, Samsung Pay, and Android Pay have struggled to gain traction," the analysts concluded. "Mobile wallet adoption has been underwhelming to date by nearly every objective standard, including initial penetration of smartphone users and repeat usage rate. While up to one-third of U.S. phone owners have enrolled in the payment plans, frequent usage is uncommon, the analysts said. Only 8%, 6%, and 3% of people use Apple Pay, Samsung Pay, and Android Pay at least once per week."

<comment><USER13> I've switched to Android Pay pretty much everywhere because it's nearly instantaneous, whereas chip transactions require 10-20 seconds of awkward waiting around. Before I had a phone with a fingerprint reader it took more effort to wake and unlock the device, but now that part is frictionless.

<comment><USER12> Android Pay is almost always as slow as chip transactions here in Minnesota. The app seems to work quickly but the POS machine is always slow to complete it's part of the transaction. It seems to vary depending upon the POS machine - for example Trader Joe's is always quick but those in the larger grocery chains or local sandwich shop are painfully slow.

From the downvotes I assume it's a regional thing!

</comment></comment></comment></comment></comment></comment><comment><USER14> Millions of people eat at Sonic?!

</comment><comment><USER15> Can we all now move to Bitcoin? We have enough evidence with all the breaches so far. This is not going to stop anytime soon.

<comment><USER16> Does that actually help all that much? I doubt most people know how to, or want to, keep their keys secure enough, so you'd likely end up with them being managed by central services anyway.

<comment><USER15> I sense an opportunity here for someone to figure out better UX when it comes to managing keys. A lot of folks do dabble and use 1password or lastpass, etc.

</comment></comment></comment><comment><USER17> Edit: it is sad that my comment that is relevant and contains nothing but facts is downvoted... What has HN become?

Say what you want about Bitcoin, but it _does_ solve credit card theft for good. If I could use my Bitcoin hardware wallet¹ to pay Sonic, I wouldn't be affected by this security breach.

¹ No Bitcoin theft has ever occurred on a hardware wallet thanks to their tamper proof isolation of private keys.

<comment><USER18> If someone else uses my cc, I'm not paying it. If someone steals my bitcoins, they're fucking GONE.

<comment><USER17> Wrong. In the US you may be liable for the full amount stolen if you fail to notice the theft in 30 days. Even if you report the theft promptly, the law allows your issuer to make you liable for the first $50.

Also you completely ignored my point about hardware wallets making theft a non-problem.

<comment><USER19> > the law allows your issuer to make you liable for the first $50

This has never happened to me, and ive had a CC compromised a few times.

If someone steals your hardware wallet, what do you consider that?

<comment><USER17> Physically stealing a hardware wallet is typically not usefull because they are PIN-protected. And you can back them up by writing the 12/24-word seed in a safe/hidden spot.</comment></comment></comment></comment></comment>


Ask HN: Selling the developed software after quitting from the company - <AUTHOR>

Hello Guys,
Need advice from the community.<p>While working for a company A, I have solely developed a product and they have started to use it. Now I have quit from company A, but they need my knowledge and support to maintain the software. Should I re-develop the product as a cloud-based service for recurring payment or just provide support and charge per hour? Whats your suggestions guys? <comment><USER2> Really depends on the contract you signed with them and the license agreement. If they own the product then you might be entering shaky ground re-developing it.

<comment><AUTHOR> Its a product which is build based on open standard (3gpp specifications). So I could develop it, even if I have signed any agreements with them, right ?

<comment><USER2> Did you sign a non-compete?

<comment><AUTHOR> No, its only a normal employee contract.

</comment></comment></comment></comment><comment><USER3> I personally think that if you have the leverage you say you do in this situation, is to do what you say (develop the service) using different code of course, and then sell yourself to them as a consultant for at least triple the amount they had you on for beforehand.

<comment><AUTHOR> Yes, this is what I was thinking. thanks.</comment></comment>


Ask HN: Shouldn't a recent CS grad know how to throw an exception? - <AUTHOR>

I'm looking to hire CS grads for an entry-level Java developer position. The general hiring process is this:
1. Apply (or get referred by a recruiter) with resume
2. Provide one- or two-sentence answers to some simple prescreen questions
3. Do a phone interview with member of dev team
4. Visit office for a face-to-face interview, and complete a code exercise while in office
5. Receive offer of employment
Now what has happened several times is that a candidate will do well enough on #1 and #2, talk a good game on #3, come in for #4 and totally bomb because they don't know how to throw a freakin' exception!
I am completely dumb-founded by this. How do you get through a complete CS program in college and expect me to hire you as a professional Java developer without knowing one of the basic principles of the language?
Are my expectations really that unreasonable, or do CS programs in general neglect exception handling when teaching OO? <comment><USER2> Your expectations are _really_ that unreasonable... if you're hiring CS grads without work experience. CS degree programs are not Java developer training, and it's unlikely any kind of classwork would require _throwing_ an exception in any language; catching one maybe. For my own anecdoctal CS program experience, I wrote more functional code than OO, and was never required to use Java in any course.

You're expecting specific professional experience from people that don't have any. Exception handling is not an academic topic. It doesn't help students learn about data structures, algorithms, language development, compiler theory, etc... it's just a control flow construct used by some languages and not others. It's something they'll learn on the job if their job requires it -- easily enough, I'm sure.

If you want that specific knowledge, then require a year of work experience with Java in the job listing. Graduates don't have that by default.

<comment><AUTHOR> Thanks for your input, Dan. Based on your college experience, it sounds like you would _not_ have been applying for a Java developer position right out of school, correct? But these candidates are. The position they are applying for is officially titled "Jr Java Developer".

<comment><USER2> What else do you expect a new graduate to apply for but a junior developer position? If you want to hire recent graduates, at the lower salary that comes with versus hiring someone with experience, you're going to have to let them do some on-the-job learning. Test their ability to problem solve and communicate in the interview. Ask for code samples and solve some algorithmic problems together. Do a "fizzbuzz" test by e-mail if you're getting applicants that have never written code at all -- but filtering for a CS degree probably already handles that.

I did a few internships in college. I interviewed with Microsoft. They looked at my resume, code samples I gave them (in C++, Python and PHP), and ran through a phone interview where I solved some problems over the phone in pseudocode. They hired me into a product team as a C#.NET software developer with no experience in C#, .NET or Windows programming. I learned the syntax and libraries on the job and was solving bugs on the second day.

I'm pretty bad at analogies, but this is the best I've got: You want to hire a mechanic. You're a Ford dealer. You're refusing to hire young, trained and certified mechanics because they can't tell you about a specific quirk of the 2009 Ford Escape brake assembly. They weren't trained with Ford-specific knowledge, and they'd figure out the brake thing within 20 minutes of seeing it, but you're balking that these mechanics applied to a Ford dealer without that Ford knowledge.

<comment><USER3> I disagree.

Exceptions are not some obscure, theoretical language construct and Java exceptions aren't an arcane, experts-only part of the language. If I'm hiring for a "Jr. Java Developer", I expect them to know Java. Not every detail, not the edge cases, the really weird stuff, the 3rd party libraries, the frameworks. But they should know the core language features and syntax. If he's told me he knows Java, and I have to give him a pass on exceptions, is it cool if he can't create a derived class? Doesn't know the type system? Operator precedence? How little competence is okay?

I have an expectation that if you are applying for a "Jr. Java Developer", no matter what you did or did not learn in school, you'd better have picked up a book or cranked up Google and gotten familiar with Java. Why? Because as a programmer, _that 's going to be the rest of your career_. Good programmers are always going to need to be learning something new, often quickly, and usually doing it on their own. If you aren't willing to do that to get the job, why would I expect you to do it once you have the job. And if you _can 't_ pick up a passing level of competence in the core language features in a couple of days of prep, then you probably don't need to be working in programming.

Unless it's Lisp. Totally cool if it takes months to wrap your brain around that.

</comment></comment></comment></comment><comment><USER4> It would be a good idea to make the phone screen more rigorous. Use some etherpad clone-du-jour and have them write code in the phone screen. This way you'll filter out the bozos more efficiently.

You shouldn't expect somebody hired for an entry-level Java position to even know Java. I mean, at least if you're trying to hire somebody who'd be good, they'll have experience in other languages, and the cost of them catching up on Java is miniscule compared to the cost of them catching up with your codebase, with being a professional programmer in general, and it's certainly less than the cost of searching for somebody who's not quite as smart and talented but has better Java-specific knowledge. If you find somebody who has weak knowledge in _everything_, they might still be okay, but if you find somebody who has fairly good knowledge of other aspects of programming (be it another language, or data structures, or HTML or web programming or some protocols and such) then it's a sign that they're not dumb and are worth considering. You should be comfortable simulating how quickly they'd pick up Java when starting.

Edit: Of course, there _are_ a lot of fresh graduates who are scrubs that can't code, signed up for the video games or the money, and thought they'd just focus on grades and they just suck in general. People with general Java background knowledge who just don't know that Java has exceptions are one thing, people who mess up the exception-throwing syntax or forget about checked exceptions are another. What kind of person are they -- did they go to film school or did they go to "films"? People who went to film school will know what their professors told them to know, people who went to films might not have looked at Java specifically but will have a bunch of other knowledge about programming that they looked at outside of class.

</comment><comment><USER5> Exceptions are not "thrown" but caused, raised at best... The way Exceptions are provided in Java are bad if you'd ask me. Anyway you should expect CS graduates with experience in Python, Ruby, C++, Java, ML, Haskell or similar languages to be able to handle exceptions. Anyway. The question remains why you even want a CS graduate to do Java? Also there are slight differences in the semantics of exceptions in aforementioned languages though i.e. C++ Exceptions are "thrown" without operator new but is syntactically quite similar.

So. Do you think throwing exceptions is a must have for _entry-level_ Java development? I don't. It is not important during most simple projects (which you'd do in your curriculum), is most often ignored or rethrown, or looked up and understood in a few minutes. Aren't patterns more important? Or general ideas? Java is just another language which will become a burden (Luke COBOL). Just my thoughts...

<comment><USER6> >> ...C++ Exceptions are "thrown" without operator new...

Reading this reminded me how dependent I am on intelisense for a lot of languages. I work in C++ and Java all day every day, and if you asked me how to throw an exception in either, without sitting at a computer (where I'd remember or grope for it), I'd give the syntax for the wrong language 50% of the time.

Maybe assessing people by putting them in front of a computer with an IDE would be useful?

<comment><AUTHOR> Good point. I failed to mention that the coding exercise is done sitting at a computer with an IDE.

</comment></comment></comment><comment><USER7> A CS program would not necessarily teach that. Some schools which use Java as an intro language might have one lecture on exceptions. Otherwise it might be covered in a "Software Engineering" elective.

</comment><comment><USER8> The list of things a new graduate won't know is endless. What matters is what they do know, and even more what they do when they don't know.

I think, "What do you know about exceptions?" is the sort of question which can indicate both. Probably makes for a more interesting interview as well.

</comment><comment><USER9> Granted, I know how to throw an exception, but the large majority of my undergrad career was about solving problems that were evaluated on 'well- formed' data. It was rare for the code to need to be able to handle exceptions. Perhaps this is the culprit.

<comment><USER10> Agree, sad reality of most CS courses taught at school, the hw problems do not resemble real world professional problems.

<comment><USER2> In a good CS program, you learn how a CPU is built up from transistors to logic gates to ALUs and other components. You learn how machine code is executed on that CPU. You learn how higher level languages are compiled to those simpler instructions the CPU can understand. You learn how to write compilers and interpreters, then develop your own programming language that's compiled or interpreted by your own program, and implement a real algorithm in your language. At this point, a homework problem of "handle this exception when the file is not found in Java" is about as enlightening as teaching a master mechanic "handle being handed the wrong size wrench while attaching this part".

Learning the specifics of a programming language some employer uses on the job is about as hard as a salesman picking up a new industry's jargon. It takes a few days, but it's nothing any capable graduate can't handle at that point. There's nothing sad about this reality.

<comment><AUTHOR> So it's a simple concept that takes no time to learn, and they haven't yet learned it before showing up for an interview. Doesn't that tell me something right there?

Should I expect them to be knowledgeable of complicated concepts if they are not knowledgeable of simple concepts?

I'm sorry, I know I'm being obtuse here. I just didn't think that being able to code `throw new Exception();` in an interview for a Java developer position was too much to ask. I guess I'm wrong.

<comment><USER11> > _So it 's a simple concept that takes no time to learn, and they haven't yet > learned it before showing up for an interview. Doesn't that tell me > something right there?_

It tells you that it's trivia. There is a world of trivia surrounding any topic, and 100% of the time you will be able to nail somebody on not knowing something that's simple to learn if you just pick the right piece of trivia.

> _Should I expect them to be knowledgeable of complicated concepts if they > are not knowledgeable of simple concepts?_

OK, so Cocoa has this OO IPC technology called Distributed Objects. It's really brain-dead simple (like four lines of code to set up), but it's pretty archaic. I have more than a decade of experience in Objective-C/Cocoa at this point and feel pretty confident saying I have a solid understanding of the language and framework — but if you asked me to write some code using Distributed Objects, I would have to go look it up. I'd have it down in a couple of minutes once I knew it was needed, but I could not produce it on the spot because you can't hold every piece of trivia in your mind all the time, and this particular bit of trivia has never been needed for the things I've done.

<comment><AUTHOR> Are you saying that exception handling is trivial and so old that it's irrelevant to know how to do it?

<comment><USER11> I'm saying _the syntax for throwing an exception in Java_ is trivial, and that there are many programs you could write where throwing your own exceptions _is_ irrelevant.

Focusing on the precise reason I don't know Distributed Objects is really a red herring. I was trying to give a personal example of where I could be criticized for not knowing something simple. The point is that it's simple to learn, just like the syntax for throwing exceptions. But I don't know it because my experience just hasn't taken me there yet.

Basically, what you're seeing here is just a lack of experience with real- world Java programming. It's like knowing all the cross-browser compatibility gotchas in JavaScript. Not knowing this doesn't indicate a deeper problem with their education, because the point of a computer science education is not to teach every piece of Java trivia. As they gain experience, they will easily pick up all the trivia that's relevant to their job, and the other trivia (like Distributed Objects) will remain unknown.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> Most of my CS assignments did something like this:

try { doSomethingBad(); } catch(Exception e){ }

Rarely did we have to think about throwing exceptions, just capturing them.

</comment><comment><USER13> A related question has been bugging me recently: why is there such a mismatch between the expectations of employers and the skills of CS graduates? There turns out to be a lot of research from the ACM SIGCSE (Computer Science Education) community. The McCracken Group paper "A multi-national, multi- institutional study of assessment of programming skills of first-year CS students" and several follow-on studies suggest that getting students to learn programming is truly difficult, a universal observation not just limited to the US. Student performance are often bimodal in intro classes. Also, our conventional assessment tools do not measure programming skill very well. I haven't encountered any data on this, but anecdotally, it seems the expectation gap is considerably different from say the expectation-skill gap in electrical and mechanical engineers. If anyone has any perspective on this, I am really interested in hearing about it.

Aside: At least in some (advanced?) compiler courses, we do teach students how to implement exception handling semantics in a compiler. This is of course very different from learning how to use exception handling facilities in a given language.

</comment><comment><USER14> I can honestly say that in my course work I can't remember ever having to throw an exception. With that being said, I would think anyone who has done any work outside of course work should at least know how to throw an exception.

I know I did.

<comment><USER11> I'm not so sure. It is not all that hard to write a moderate-sized Java program without throwing any exceptions yourself. (You'll probably need to _catch_ an exception at some point, but throwing your own tends to fall on the "optional" side of the fence.)

</comment></comment><comment><USER15> Having just graduated from a UK degree in CS i can im not surprised some people cannot do simple tasks like that. University doesn't really prepare you for a certain language or skill, its up to the individual to take that bit of knowledge and apply it further - (in there own time)

Personally i gained more in my own time / placement however university gave me the tools and direction.

I would recommend finding grads that have completed time in industry, the difference between those that did and those that didnt shocked even myself on returning for my final year.

I *would expect to grad to be able to throw and exception and catch them tbh.

</comment><comment><USER16> I'd say it depends. If they consider Java to be their primary language and they haven't spent enough time coding in it to have ever encountered exceptions, then they haven't spent enough time coding, period (I'm assuming exceptions weren't the only gap in their knowledge, and this was just an example?). If they consider something else to be their primary language, and are otherwise solid on their CS fundamentals, then by all means, cut them some slack.

</comment><comment><USER17> My CS program focused strongly on OO and our core language was Java. Exceptions were a regular subject and part of assignments. It seems insane that someone could have a CS degree and not know something so simple and fundamental.

<comment><USER18> Sadly, you seem to have spent a lot of time and money on subjects you could have taught yourself in a few weeks of light reading.

Java is not computer science. Exception handling is not computer science. "Something so simple and fundamental" yes, but again, completely unrelated to computer science.

Anyone with half a brain can learn a new language via self study. I would be royally pissed if that's what I was taught in college. I'd go back and ask for a refund.

<comment><USER19> All of CS can be learnt from books.

<comment><USER18> True, but not all of them are as easily learned as a new language is. This is coming from someone who didn't go to college and has been working in the industry for almost ten years now.

<comment><USER19> Agreed.

</comment></comment></comment></comment></comment><comment><USER20> If it's stated that the position is a Java position, then you would reasonably expect the people applying to know how to throw an exception. Computer science has nothing to do with it.

</comment><comment><USER19> I got a java job out of college and would have (and still probably) would fail your test. I can't remember the last time I used an exception in Java

</comment><comment><USER21> Seems reasonable, assuming you asked about Java experience and they say they're familiar with the language.</comment>


The Quest for Room-Temperature Superconductors - <AUTHOR> https://gizmodo.com/the-quest-for-the-most-elusive-material-in-physics-1833846121 <comment><USER2> > one of the researchers carefully sandwiches lanthanum foil and hydrogen gas > in between the diamonds' flat surfaces. Then [...] the researcher generates > pressures of at least 170 GPa—pressures similar to those in the Earth's > core—between the diamond tips. Then [...] the team heat the material with > laser pulses, producing the chemical reaction that would create the > material.

It is always humbling to read about what it takes to do cutting edge research. This article was good at conveying the efforts required.

I do wonder if studying these simple hydrogen-based compounds is a dead end though. I believe the same mechanism (phonon-electron coupling) is at work here, than in conventional superconductors, so the physics is well-understood. It's been established that this mechanism can only support superconductivity up to 30-40 K at normal pressures [1]. Unconventional superconductors, on the other hand, don't have this hard limit, so there is probably more knowledge to be gained from studying those, which could be used to propose new, better superconductors.

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

<comment><USER3> Stress on surface of tempered glass in in range of 100 MPa. It's a lot less than the 170 GMa in this case, but perhaps it could get a bit higher in a similar material and the threshold of superconductivity could be lowered.

</comment></comment><comment><USER4> "Someone else has to prove it independently, otherwise it's invalid,"

Take notes, psychology.

</comment><comment><USER5> > zero resistance in the material at temperatures higher than 8 Fahrenheit > (-13 Celsius), perhaps as high as 44 Fahrenheit (7 Celsius)

> The teams synthesized only about a dust-speck worth of [lanthanum hydride] > from expensive ingredients crushed to unfathomable pressures between hand- > cranked diamond halves

While the temperatures are amazing (when I was young, superconductivity above 0 Celsius was the stuff of science fiction), the material might not have commercial applications in the near future.

Instead, why not use active cooling and powerful insulation? Like this: [https://www.chemistryworld.com/news/world-first-as-wind- turb...](https://www.chemistryworld.com/news/world-first-as-wind-turbine- upgraded-with-high-temperature-superconductor/3009780.article)

<comment><USER6> I feel like the article is misleading insofar as to omit the material has to _also_ be under extreme pressure to remain a superconductor.

</comment></comment><comment><USER7> I remember when I was a kid in the 80s and early 90s there was all this talk about room-temperature superconductors being right around the corner. Getting to 8 degrees F is a big advance even if it is only tiny amounts.

</comment><comment><USER8> My high school physics teacher (~2006) told us once when discussing career prospects that if you could build/discover a material that was a superconductor at room temperature, you'd probably end up the richest person in the world.

I've never forgotten that, and it sounds like the challenge still stands.

<comment><USER9> I always said that one of these things would probably make you one of the richest (or powerful) persons on the planet:

      - Practical nuclear fusion (that outputs more power that it takes to run)
      - Superconductivity at room temperature
      - Artificial general intelligence
      - Practical high-density energy storage

<comment><USER10> My vote is on industrial-scaled asteroid mining. The ability to both drop near-unlimited riches into coffers of the people you like and onto the cities of the people you don't like would seem to be the be all end all combo

<comment><USER9> I highly doubt asteroid mining would ever be profitable. The cost of getting bulk goods from space down to earth are astronomical (ha!).

Also, if you were to flood the market with any material you mined, prices would go down.

</comment></comment></comment></comment><comment><USER11> What are super conductors used for? I say this as Im fairly certain we arent solely looking for a more efficient way to transfer electricity.

<comment><USER12> well you're not wrong but a room tc superconductor would indeed enable us to cut down on transmission costs of power. I'm not sure if this is obvious but the only reason national powergrids are AC and not DC is because you can step down AC current and therefore have much lower heat dissipation through the transmission lines. So at the minimum you'd get cheaper power by eliminating all the resistive losses and stepper circuits . But also superconductors are used in MRI machines where right now they're kept below Tc using liquid nitrogen, which is hard to control (search MRI quenching). So room temp superconductors would make MRIs cheaper, which would be a boon to the developing world.

<comment><USER13> A superconductor suitable for use in an electromagnet that could be cooled with liquid nitrogen alone would be practically "room temperature" as far as these things go. Liquid nitrogen is cheap and abundant, as opposed to liquid helium which is required to get down to 4 K.

As stands at the moment, some older MRIs use liquid nitrogen to help insulate liquid helium. Newer machines use liquid helium alone.

<comment><USER14> Doesn't rebco tape use liquid nitrogen?

<comment><USER13> It's been awhile since I've paid attention to the field, so apologies if I get this wrong. I was under the impression that cuprate superconductors were unsuitable for use in MRI magnets because they only superconduct across clusters of microdomains, making it impossible (at least with current technology) to generate the large, strong, and uniform field necessary for the application.

There seems to be ongoing research into producing suitable magnets with cuprates, but I don't know if the problem has been solved yet. In any case, there are no commercially available MRI machines that use cuprate superconductors.

</comment></comment></comment></comment></comment><comment><USER15> Ever read Larry Niven's "Ringworld"? Don't forget that the Puppeteers destroyed the Ringworld's technological civilization by creating a substance that destroyed their superconductors. If we ever invent them it will be fantastic, but it will also be a central vulnerability to our civilization - but I guess we have other ones already.</comment>