Live data from Hacker News

React is winning by default and slowing innovation

lorenstew.art

711–720 of 866 posts

Re: React is winning by default and slowing innovation

#711
post #637

Earlier quoted context omitted.

Based on how they are run they are completely not just ordinary JavaScript functions, hook era components are also not just JavaScript functions, it's a very complicated system. React calling them "just functions" is untrue, just marketing buzz words, and it leads developers into traps.

> React calling them "just functions" is untrue I'm pretty sure this is also untrue. AFAIK React has never used that phrase (and at the very least, I can't find it anywhere official right now), it came from other people convincing newcomers that hooks aren't something more complicated like objects (comparing to class-based components). React has always treated them as special functions, hence always prefixing them wi…

> it came from other people convincing newcomers

Yeah I think you're right

Re: React is winning by default and slowing innovation

#712

> The problem isn’t React itself, it’s the React-by-default mindset. I think this is not-seeing-the-forest-for-the-trees. The reason why we’ve been having this discussion for 20+ years is because HTML was not designed to be an app platform. It’s a document standard that we’ve grafted an app ecosystem on top of. In Windows, Mac, or iPhone software development, there’s One Correct Way to develop apps. Yeah, there’s som…

I don't know about Mac, but windows had WPF, winforms, UWP - all blessed by microsoft (I'm sure I'm missing a few), and often maintained at the same time.

A huge amount of windows apps were built with Java, you had to install the JDK separately - one such thing that comes to mind is Minecraft, another is Jetbrains IDE.

Most of the major native apps you use most often, like browsers, render things directly using DirectX and similar, not to mention games which are made almost entirely in third-party engines that are far from Microsoft display frameworks. (There are also 2-3 competitors to DirectX - such as Vulcan and OpenGL )

And of course there are quite a lot of popular apps that use other frameworks like QT

Re: React is winning by default and slowing innovation

#713

Earlier quoted context omitted.

So JSX is pure Javascript and not, say, a dialect of XML embedded in JS? Because it sure looks like the former even though it compiles to the latter. React isn't Javascript. It's a franken-language that looks superficially like a mix of JavaScript and XML whilst following the rules of neither. That's why there is such a thing as a React compiler - a good sign that you're not writing JS, which doesn't have compilers.…

JSX isn't and hasn't even been necessary to use React. The first version of my company's site didn't have a build step and called createElement manually. And in the decade I've been writing for React, I've never used the React compiler. But saying that it's proof that it's not JavaScript it's like saying that V8 is proof that JavaScript is too complicated because otherwise it would be fast enough not to need a JIT. A…

If you also have experience using JSX in a React app, I'd love to hear any opinions/experiences you have with doing the JSX style vs createElement() style coding.

I understand how they map to each other but I've only done JSX. That said, I'm old so calling functions all over the place is in my wheelhouse, and I'd love to hear from folks who have done both.

Re: React is winning by default and slowing innovation

#715
post #472

React isn’t just "winning by default" It's winning because at the core it's just JavaScript function composition. A component is a function, conditionals are `if (...) { ... } else { ... }`, loops are `map()`. JSX is just sugar for function calls. In Svelte you are writing XML with little JavaScript islands inside it. Instead of if you get `{#if}{:else}{/if}`. Thats not "ergonomic" – thats a mini-language stapled on…

So JSX is pure Javascript and not, say, a dialect of XML embedded in JS? Because it sure looks like the former even though it compiles to the latter. React isn't Javascript. It's a franken-language that looks superficially like a mix of JavaScript and XML whilst following the rules of neither. That's why there is such a thing as a React compiler - a good sign that you're not writing JS, which doesn't have compilers.…

>The semantics of React code are very different to imperative straight line code.

Yes and all you have to do is learn why those semantics exist in order to do react well.

Unfortunately too many programmers still think they can just mimic other code to figure it out.

Re: React is winning by default and slowing innovation

#716
post #679

Earlier quoted context omitted.

So basically react class components? It definitely was not easier in those days. When your just using vanilla react, I've never had a problem with hooks being that hard to reason about. Once you add in SSR, routers, query caching frameworks, etc the "lifecycle & state" starts to get confusing. This is mostly a problem with the additional complexity of these frameworks (nextjs, tanstack) and not react at its core. Bui…

But you cannot really develop anything meaningful without adding frameworks. I guess redux solves both "state" and "messages" at once, that's good. But what you work with then is not "vanilla react" at all. I don't even think "vanilla react" can really exist, beyond toy examples. You either use frameworks or write them yourself (worse).

> But you cannot really develop anything meaningful without adding frameworks.

You can develop extremely powerful web-apps using just React + Redux. Once you need to start dealing with SSR for SEO & server side caching, data preloading, hydration, etc... things get complex.

But honestly that's because those concepts are inherently complex and that complexity can only be reduced so far. Another problem is they get baked into these framework as the "default" and often over utilized when they aren't actually needed.

Re: React is winning by default and slowing innovation

#717
post #187

If something innovates enough to be a lot better than react then it will start winning. I haven’t seen anything yet

React, _combined with its ecosystem_, feels like a local maxima. System D may be better than C++, but it wasn't better _enough_. We needed massive improvements offered by Rust to move the C++ community (not everyone, I know).

Re: React is winning by default and slowing innovation

#718

Earlier quoted context omitted.

I read the original article and many surrounding discussions & follow-up articles. Not confusion perhaps, but many see it as friction, including the complaints from the original article. From where I'm looking at, it's just a side effect of dealing with concurrency with no threads, what the article also mentions. So, you know, it is what it is, at the end? Now we have people coming up with different definitions of co…

The complaint is that it's not just "function composition" (per GP) at all anymore. You're dealing with "component lifecycles". Composition doesn't really work out with hooks, for reference see any non-toy React codebase.

It's like dealing with event handler registrations. You cannot compose those too, as they are "hooks" for when a specific event occurs.

Hook definitions can be a composition of reusable functions and other hooks, like any event handlers (e => filterKeys('cmd+s, ctrl+s', preventDefault(e)).then(save)). It's possible to break this anology (you can register an event handler in an if branch) but I hope it gets the point across.

Re: React is winning by default and slowing innovation

#719
post #472

React isn’t just "winning by default" It's winning because at the core it's just JavaScript function composition. A component is a function, conditionals are `if (...) { ... } else { ... }`, loops are `map()`. JSX is just sugar for function calls. In Svelte you are writing XML with little JavaScript islands inside it. Instead of if you get `{#if}{:else}{/if}`. Thats not "ergonomic" – thats a mini-language stapled on…

> React feels natural because it never asks you to stop writing JavaScript

I want to increment some counter on the webpage. Which approach feels natural?

  increment = () => {
    this.setState((prevState) => ({ count: prevState.count + 1 }));
  };

  const increment = () => setCount((count) => count + 1);

  function increment() {
    count += 1;
  }
No one wakes up saying "please let me mutate simple state with function calls".

Re: React is winning by default and slowing innovation

#720
post #472

React isn’t just "winning by default" It's winning because at the core it's just JavaScript function composition. A component is a function, conditionals are `if (...) { ... } else { ... }`, loops are `map()`. JSX is just sugar for function calls. In Svelte you are writing XML with little JavaScript islands inside it. Instead of if you get `{#if}{:else}{/if}`. Thats not "ergonomic" – thats a mini-language stapled on…

I don't understand how this comment is the top, because it makes no sense.

No one writing markup says "Damn, I wish I could write this inline with my javascript." Have you even seen a react component before? People writing javascript containing the markup which, in turn, contains more inline javascript statements for conditional rendering. No logical person would argue "this is better than {#if}{:else}{/if}".

Post reply on HN