Live data from Hacker News

React is holding me hostage

emnudge.dev

321–330 of 553 posts

Re: React is holding me hostage

#321

I don't understand the animosity around useEffect. It executes a function based on a list of dependent variables. That's it. Once you understand that, its purpose becomes very clear. You don't want to rerender? Use useEffect with an empty array! Or don't use any state variables! You want to show something new to your customers / users without rerendering? Well sorry, that's impossible, regardless of any framework you…

I agree, and I'd like an anti-hooks person to explain their thoughts a bit more. My impression is that they believe useEffect inclines devs to cause side-effects in the component, quickly making the logic of a component difficult to follow- for example, a useEffect that sets a state that kicks off another useEffect that sets another state that kicks off another useEffect... But this problem existed before hooks: old…

My problem with hooks isn't the philosophy but the ergonomics and footguns it creates.

Compare that with Vue composition api, and you can see how idea of hooks can be implemented much better[0]

[0] https://vuejs.org/guide/extras/composition-api-faq.html#comp...

Re: React is holding me hostage

#322

I never understood why React became so popular. I thought it was a kind of mass hysteria. I was exposed to a broad range of front end frameworks early in my career (Backbone, SproutCore, JavaScriptMVC/CanJS, AngularJS), one of my colleagues was experimenting with Google's PolymerJS and recommended it. After trying it out, I was blown away by its elegance and simplicity. Yet somehow it never caught on. When React came…

I'm with you on this.

Re: React is holding me hostage

#323

I'm still a React guy. I've also worked with Angular and Vue and toyed with Svelte. People tend to compare these frameworks on things that don't matter - often it's performance. We used to compare React performance to AngularJs performance too, which was meaningless. VDom is nice. Reactivity in signals is nice. Limiting rerenders is nice. But I choose frameworks because of developer ergonomics. The killer feature for…

> When using React I usually just use MobX and everything just works. MobX is signals library. In other words, you are already using the signals way of doing things if you mostly manage your state with MobX. I still use MobX as well if I think I can't use SolidJS. SolidJs if you haven't looked has MobX-like tools built in, computed, autoruns and all the same tools, it triggers "renders" when one of the signals change…

I haven't used SolidJS, so I can't comment much. But Signals have very good developer ergonomics. But from my experience other frameworks that use them come with drawbacks that I don't get with react. So MobX+React works better for me than - let's say vue.

From a brief look at their website, the downsides for using SolidJs for me seem pretty big. At the very first example, if you change it slightly you can see my problems:

  const CountingComponent = () => {
    const [count, setCount] = createSignal(0);
    const interval = setInterval(
      () => setCount(count => count + 1),
      1000
    );
    onCleanup(() => clearInterval(interval));
    if (count() % 2 == 0) {
      return Even count value is {count()};
    }
    return Odd count value is {count()};
  };
1. MobX let's me use objects without additional syntax (createSignal, count() instrad of just count)

2. The fact that the component does not rerender and that my code does not automatically change between even and odd text means I'll probably need to have an additional mental model for writing SolidJS components. Using React+MobX I just write as I would write any other function and it'll just work (There's magic involved, but manageable magic)

Re: React is holding me hostage

#324
This quote from the article somehow justifies my continued willful ignorance of React:

> It’s just abstractly funny to watch the ecosystem of a UI renderer work so tirelessly to keep using it while avoiding every part of it.

Re: React is holding me hostage

#325

I'm still a React guy. I've also worked with Angular and Vue and toyed with Svelte. People tend to compare these frameworks on things that don't matter - often it's performance. We used to compare React performance to AngularJs performance too, which was meaningless. VDom is nice. Reactivity in signals is nice. Limiting rerenders is nice. But I choose frameworks because of developer ergonomics. The killer feature for…

In my opinion, React was pretty much complete without the introduction of Hooks. Shifting from the previous Component-derived mental models to Hooks was a cause of many runtime issues in at least 2 companies that I worked for.

Unfortunately, React went from less-capable and more understandable to more-capable and less-understandable model. But yeah, that's just a newbie-coder take.

Re: React is holding me hostage

#326
You all will hate this: I've been a pro coder for 44 years, at a high level. I was an early Assembly programmer on the pre-release Mac in '83, a 3D graphics researcher during most of the 80's, OS developer for 3D0 & the first PlayStation, and quite a bit more. I have over 40 high profile commercial applications published.

I think React creates needless complexity. The software I write is complex by it's nature, I do not need the software I create my application within to exponentially increase that complexity. React does not just let one write code and create one's application, React dictates how the code is written, and if that does not fit with one's application structure you must change it. And React developers cannot wrap their heads around anything other than React's dictated way to write React, so... they are useless.

So, what do I use: nothing. I just write html/css with direct DOM access via js, very minimally. Dicking around with the web page is the least priority of the applications I write, and the freedom to create the application structure as the purpose of the application dictates is far more important to my clients. Plus, I do not write consumer click bait vehicle software, I write software for people to accomplish things, typically complex things of the nature an engineer, designer, or architect would use.

Re: React is holding me hostage

#327
I came from the video game world. I used to program for the Playstation 1 and 2. For me, all these reactive frameworks are baffling. Is it weird that I just prefer immediate mode UIs and roll my own state management and "reactivity" on a project by project basis?

I may be wrong here, or it could be my age showing, but I feel like explicit UI systems like that might be more verbose, but I find them more accessible to dive into and less "magic".

I'm totally lost and baffled by everyone's enthusiasm for these increasingly arcane and complex abstractions. I suppose they are necessities that arise when you reach a scale that I have not yet encountered (I work on small to medium sized teams of a dozen or dozens rather than hundreds of programmers).

Re: React is holding me hostage

#328
Can't say I relate to this, interesting perspective nonetheless.

This line however "It is not obvious that your component re-renders on state updates." is kinda strange, maybe it's not obvious if you didn't read any documentation or tutorial?

also "You could build your own framework in an hour using reactive primitives [...]" is the same as when people say "just make your own sorting algoritm", yeah sure you can get the exact behaviour you want, but come on.

Re: React is holding me hostage

#329

I never understood why React became so popular. I thought it was a kind of mass hysteria. I was exposed to a broad range of front end frameworks early in my career (Backbone, SproutCore, JavaScriptMVC/CanJS, AngularJS), one of my colleagues was experimenting with Google's PolymerJS and recommended it. After trying it out, I was blown away by its elegance and simplicity. Yet somehow it never caught on. When React came…

I totally agree.

Re: React is holding me hostage

#330

Earlier quoted context omitted.

> Surely people can find better use for their time and energy than churning through half-baked frameworks? We should have all stayed on backbone or Prototype.js with that logic. People look for alternatives because the status quo is awful (slow, verbose, footgunful). You’re saying “who needs cars when we got horses? Cars break down all the time”

No, when you mention js libraries you are already starting the clock way too late. The UI problem is not new. People were already building clunky UI cars long ago. MFC was introduced by Microsoft in 1992. Of course the emergence of the web platform and mobile/touch devices complicates the matter as you now have a proliferation of platforms to address (desktop native, desktop web, mobile native, mobile web) but my arg…

For what you're talking about, Computer Science History needs to be taught, which it is not, and if it did it would be filled with current industry trend propaganda. Fact of the matter, every developer have to learn it all themselves because this history is not taught. However, most developers get caught up in a "build now!, ship now! now! now! now!" and no history or accrued deep knowledge from other developers can be transferred with any quality or retention.
Post reply on HN