Please don't commit the genetic fallacy here of all places.

Dismissing the complaint that the author might be inaccurate or not as trustworthy as otherwise as simply the genetic fallacy is an instance of the fallacy fallacy, isn't it? Consider a poor news source such as the Daily Mail - I'd say it's justified to at least be more skeptical of the claims presented in any given Daily Mail article based on their history.

I think it was a joke. I dismiss the author by the choice of URLs. I don't mind lacking the talent to find more elaborate reasons.

> I expected a deeper dive into the complexities of these arguments.

Public intellectuals are attempting to appeal to the public at large, the majority of which don't change their minds based on new information. They change their minds based on how that information makes them feel. Trying to convince most people to change their minds with a complex argument is a lot like trying to convince most people to change their minds by talking in Italian instead of English.

> am simply using redux to manage all state

This only works in small apps. I work on a medium sized app at work and we started that way too. It becomes a huge, sloppy mess in short order. Putting everything in Redux is akin to a desktop application that uses nothing but global state. Hooks are great because it keeps the state local, but it can be re-used across components if we need to.

I would disagree with you and say that from my own experience (not saying your experience is wrong obviously) it's quite the opposite; in small applications, using local states is fine, but as soon as your application grows, having everything inside a central store makes everything cleaner and much simpler, as multiple independent components might want to share state or listen to shared events, etc.

> as multiple independent components might want to share state or listen to shared events, etc.

If you recall, I said...

> Hooks are great because it keeps the state local, but it can be re-used across components if we need to.

The use case you just defined is exactly why hooks were created.

Are you implying the use of context when you say that hooks allow you to re-use state between components?

Legit question because I don't know hooks very well. To my understanding, hooks are just syntactic sugar to use and update local state in a function component. How does that help you share state between components?

I think he must be implying the use of Context as well.

That's where the real power is. Combining the 2. The pattern of use is DI even with a global store like Redux, making it not necessarily truly global. What Context does at a base is potentially use React Components as widely accessed stores. The simplest example usually involves abstracting a Parent Component's state/setState into state, and action functions wrapping a Context Provider.

To what degrees the stores should be laid out hierarchically mimicking the render tree is debatable. But often there is clear hierarchical ownership on large portions of the data. And often the question is what needs to be topmost and what belongs only within nested context. I think the opinion is still out on that. As you have suggested you could manage everything topmost.

Hooks make this really interesting in that they expose this idea of simple change management primitives to any Function component. So while it is still the Context API that allows the data to be shared, Hooks allow for re-usable patterns that can be used out of the box or compositionally built upon. So the Component that contains the provider has the ability through Hooks to do a really good impersonation of Redux(useReducer) or even MobX(useState + useMemo + useEffect). Does this replace those libraries? Probably not. But it is interesting how it gives a built in solution to choose to scale these solution with how you see fit. You have these tools at your disposal without much investment.

I do not imply the use of Context. useState() hooks into the local state of whatever component runs it. For example, if you have the following hook:

    function useMagicNumber(default) {
      const [magicNumber, setMagicNumber] = useState(default)

      return [magicNumber, setMagicNumber]
    }

And the following two components that use said hook:

    function ExampleA({}) => {
      const [magicNumber, setMagicNumber] = useMagicNumber(1)
      console.log(magicNumber) // 1
    }

    function ExampleB({}) => {
      const [magicNumber, setMagicNumber] = useMagicNumber(2)
      console.log(magicNumber) // 2
    }

ExampleA and ExampleB share the same code that's run in the hook useMagicNumber, but the state reflected is unique to the component.

Then the confusion was "reuse state" and "share state". Hooks in themselves do neither. Provide primitives to build reusable behaviors. Yes. Solve issues classically considered the domain of Redux. Not on their own.

> Google will let the platform stagnate, as it has little to no reason to compete.

If they do, they will be replaced, just like iexplore was. So they won't stagnate unless they are stupid and want Firefox to take over.

> If they do, they will be replaced, just like iexplore was. So they won't stagnate unless they are stupid and want Firefox to take over.

From a practical perspective, ten years of stagnation is not very different from indefinite stagnation. Even if there's a light at the end of the tunnel, we're going to have to spend a huge chunk of our lives suffering through it.

And with Google, stagnation is probably the best case. If they continue to "move things forward" as a browser monopoly, they'll probably force many user-hostile things (like their recent proposal to cripple ad blockers https://bugs.chromium.org/p/chromium/issues/detail?id=896897...).

Do you have any starting point?

Maybe something similar to what we have now, but exposes much lower level aspects of the browser and gives you more fine grained control over it. WASM is a good starting point in that it lets you use whatever language you want. Now, we need a browser API that will let us draw directly to the window if we want to. I think a lot could be accomplished by creating the UI portions of a site programatically then dumping the content into a "renderMarkdown()" function.

That's just my idea, though. Hopefully, the current sad state of the web and the coming browser monoculture will spur others to experiment too. I know some gaming companies have experimented with the distributing and executing of x64 binary executables using the browser. I know others are looking into ways to chop up and do progressive loading on binary executables.

The appification of the Internet qualifies here, with Google Fuchsia running on Chromebooks and ARM-based desktops being a good opportunity for them to move most Internet based activities in apps on a platform they control.

I wonder if we'll see a resurgence of "real work" ui for desktops and laptops now that most of the "everyone else"/"the mainstream" has shifted to mobile.

I sure hope so. This may be a contentious opinion, but I strongly think that the 'average non-technical user' that has driven so much of modern UI development (for better or for worse) is not representative of someone who should have input when it comes to tools used by professionals. Complex tasks usually benefit from deep, rich interfaces. Simpler ones may be easier to learn, but will always be restrictive once baseline competence has been reached.

> and bring the country to a grinding halt.

And if it didn't come to a grinding halt? They risk demonstrating how worthless their jobs are.

If their jobs are indeed worthless, then it's a win, in that we can save tax-payer dollars for worthless jobs.

I think 3d holographic projections will be bigger than both.

Isn't that AR?

That's PR, projected reality. With AR you don't actually project anything into the physical world that can be eg observed by unaided eyesight.

Thanks for that - I've been tinkering with a Looking Glass over the last few evenings, and had found the relationship between it and VR to be awkward to articulate.

Can confirm. I fondly remember late nights hacking the Gentoo kernel so my college radio station could reliably live stream shows via icecast and darkice.

> Yikes, when did HN become so full of haters?

Since at least 2007. I'm sure we all remember the warm reception the Dropbox Show HN[0] got?

[0]: https://news.ycombinator.com/item?id=8863

> "The fact that some geniuses were laughed at does not imply that all who are laughed at are geniuses. They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown." - Carl Sagan

s/laughed/jeered/

I was one of the idiots who didn't understand the Dropbox monetization strategy. Until recently, I thought the strategy was "whales" like in a casino would pay for everyone. I think I couldn't get past the idea that they were giving something that keeps costing them money away for free forever. What I didn't realize is how "sticky" something like Dropbox can be. I don't think I can get most people who use Dropbox and pay $80 a year to switch to Google drive and pay $50 a year. They have a workflow there.

I guess I'm trying to justify my reaction to Dropbox. Frankly, I still don't understand why Dropbox turned down acquisition offer from Apple. I still don't get it.

I don't remember laughing at Dropbox though. It was more bewilderment than anything.

It's a little weird that he includes Columbus there. Columbus was many things and genius wasn't one of them. Persistent, egomaniacal, outrageously cruel to the point that the Spanish crown threw him in prison, extremely bad at basic arithmetic -- but not genius.

More importantly though, who is Fulton?

presumably https://en.wikipedia.org/wiki/Robert_Fulton