Hacker News Reader

> all about developer experience and neglected user experience

I think this is a mix of good old cargo culting and how hot the dev market is. Small companies don't have the leverage to tell their engineers "no" when they do a bit of resume driven development.

React makes sense for many of sites at larger tech companies paying big salaries because many of them are delivering a richer "application" experience. Some engineers blindly follow what "better" (massive air quotes) companies are doing. Others who want to work at these companies want the skills that will make them more hireable and so choose React. Devs who are not in either of these other camps make a small enough group they don't generally get their way.

I’ve worked in React full time for seven years, and the biggest thing I’ve learned is that too many companies choose it when it’s absolutely not the right choice.

Plenty of things are basically websites with forms and a dash of interactivity. Building a full single page web app for this is a waste of everyone’s time and their customers CPU cycles, and it’s not even faster to develop most of the time…

My current job is a fully fledged web application for a B2B IoT platform, with soft real-time data and huge interactivity. React et al. fit this better, and because we have some control over who and what devices are using it, it’s (frankly, mitigated if you know what you’re doing) overhead isn’t a problem.

I love React, I really do. But it’s not the right fit for everything, and I’ve earned a huge amount of money coming in to save projects that are failing due to that incorrect choice.

I have worked on a project that literally served static text on a page with static links, some embedded media, a bookmark toggle thing, and a hamburger menu, that were heavily using React.

The reason I was told was that they wanted the "components" framework to support modularity and reuse. Is there an alternative for that purpose?

In Ruby on Rails there is gem called ViewComponent. Create and being used by github.

May be something similar should be there for other frameworks too.

Static site generators. I recommend Hugo.

Most server-side templating systems (or static site builders that use the same or similar templating tools) allow for easy modularity and reuse, but if they really need that “SPA” type feel then htmx is a brilliant and simple choice to add behaviour without needing to adopt a fully SPA architecture

https://htmx.org/

I’d agree with you except for the fact that it’s really hard to say that developer experience today is better than what it was before. Especially once you adjust for the fact that browsers are so much better and standardized.

Downloading and installing JQuery and some plugins versus the Byzantine nightmare of dependencies, transpilation and hacks upon hacks that is modern JS development? It was objectively better in every respect before.

Until your dependencies start to form a tree, and you can't just rely on all the global variables being loaded in the right order anymore…

Vendoring every dependency and having to manually keep track of all the updates was objectively worse than NPM as well.

Then again, having a couple of .js files just sitting on my server meant some rando having a temper tantrum and deleting their repo wouldn't break my site, or half of the internet.

That also won’t happen with NPM.

Only because it happened once and then they fixed it, but it was never a problem in the old days. Having one company and one package manager act as a single point of failure for essentially all of the javascript in the universe was a bad idea.

It looks and feels a lot more like "real" programming now but the whole house of cards seems to tip over and burst into flames every other week.

I think this is a bit hyperbolic for a problem that happened once and then they fixed it. I also don't really know what you're talking about with regard to the house of cards constantly tipping over…? It honestly just seems like you have an axe to grind here.

React and its ilk doesn't even deliver on those goals. It encourages bad programming, makes terrible software practices easy and separates code so the piles of unmaintainable garbage don't smash into each other too harshly.

It doesn't actually empower anything - it acts as a scolding nanny prohibiting people from making things explode.

It does this by imposing a narrow opinion about things that's constantly changing with each release as it herds the programmer through very specific and alarmingly complicated ways of doing things.

It's fundamentally a tool of oppression, not one of expression and one of coercion and not liberation. I hate it so much.

What is your preferred alternative to react for creating a data driven web application?

Normal Javascript and 10,000 hours like when mastering anything else.

HTML, CSS and Javascript are already extremely high level and capable. Do some xlib programming some day if you want that to be obvious.

A basic reactive data structure is only a few lines of JS.

So user clicks something -> app state gets changed -> modify DOM in response.

http://meiosis.js.org/

Here's a good description of a framework agnostic approach.

js.org? That must have been a big pricetag.

js.org subdomains are actually a free service run by some really nice people. As a poor student it was very nice to discover that I could have a nice domain for my project for free :p

(i'll use this opportunity to plug my project, https://campfire.js.org)

This is a crazy harsh opinion to have about a templating library and the general practice of designing systems that are hard to misuse.

The value of “guardrails” like type checking, borrow checking, and simple APIs is they allow you to turn your brain off when coding. I don’t write code because it’s an artistic expression of self, I write code because it’s a lowish stress job and I need to eat.

In my free time I get some joy out of writing clever code but by far 99% of the code I write I want to be boring.

And that's where we part ways.

All crafts have this - the corporate musician working on commercials and tv shows that's just trying to raise a family and "The Artist" that wants a free expression of their very soul.

I'm a slightly crazy person who is passionate about the liberatory potential of technology and how it reshapes society, hopefully as an empowering tool that benefits all. To quote Fred Brooks “The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination."

While you are happily working within the system, doing your job competently, and enjoying the fruits of your labor.

We can still be friends, but I'm going to be that wacky bird pushing the envelope, it's in my very soul and I don't think I can change that.

You’re both right. Group hug!

But do you actually have a job doing that? I want to dream as much as the next person, but I’m not being paid to dream (not to the extend you are describing anyway).

I'm sorry but could you please explain? I've never heard React (or any software really) being described this way. How does React act as a scolding nanny? The language it's written in already too liberal. I can't even imagine what one could consider complicated about React (UI libraries in every language are at some level complicated).

On another note, most of these complaints, IMO, aren't even specific to React. We were barreling down this future during the days of jQuery.

Sure, I'll take a snippet from an upcoming book of mine that I need to finish

ReactJS has a wildly inflexible architecture that aggressively forces their users to conform to an orthodoxy. As an example let's say we have the following code

    function C() {
      var A = {
            something: () => console.log("hi")
          }, 
          B = document.createElement('div');

      B.onclick = () => A.something();
    }

This small snippet of code violates "best practices" in react and thus is almost, but not quite impossible to do.

See the problem here is that B and A are directly interacting with each other. If we were to map things in react-land, they would show that C has "children" of A and B and here A and B talk to each other "horizontally" which is heretic to the purity of the orthodoxy.

The hierarchical nature here is an unwavering assertion about the world. Essentially the claim is as follows:

      C
     / \
    A---B

The A <=> B is what forces us to wear a scarlet letter and live on the edge of the town.

Therefore we no longer solve a problem. Instead, we are imposed upon us an aesthetic puritism do to a natural belief of "props down, events up". A popular way to do this basic programming technique that's been readily available in effectively every programming language since the first digital computer (Plankalkül had it in 1942) is the usual suspects either add "a new testament" to the orthodoxy, in this case with something called "redux" or figure out an acrobatic way to comply.

Let's do the second. So we need to "pass down" things that will "pass up". We have a solution, now we must go backwards, first we will go into "classes" to make things more orthodox.

    class A {
      componentDidMount() {
        this.props.connector(this);
      }
      something() {
        console.log('hi');
      }
      render() {
        return;
      }
    };

    class B {
      render() {
        return <div onClick={ this.props.onClick }>
      }
    };

    class C {
      constructor() {
        super(props);

        // here's our connecting function
        this.connector = this.connector.bind(this);
        this.onclick = this.onclick.bind(this);
        this.state = {connector: ''};
      }

      connector(obj) {
        this.setState({connector: obj});
      }

      onclick() {
        this.state.connector.something();
      }

      render() {
        return (
          <A connector={ this.connector } />
          <B onClick={ this.onclick } />
        );
      }
    };

So to simplify this flow

    A -> B

We now do

    C -> A -> C -> B -> C -> A

Or as a diagram, we get the following:

       .---◢ ◣----.
     .▶B---▶C--.   \
     |  ◤--'|\  ▼  /
      \____/  '►A-'

See how we do multiple round trips passing things through C in order to maintain the hierarchy? This is how we stay within the orthodoxy

If this looks like Ptolemaic astonomy, that's not a coincidence! In Ptolemaic astronomy the assumption of Earth being the center of the universe was enforced as the orthodoxy. As a result you got epicycles upon epicycles because the simpler model was forbidden.

People were so committed to the more convoluted orthodoxy that anyone who questioned it was put on trial for heresy.

Claiming that A -> B was even possible was the crime.

The great success of React is in enforcing a new kind of authoritarianism: it enforces doctrine by explicitly disallowing heretical code.

This is hands down the most nuts example I have ever seen used to make a point about code.

A problem that I have never seen before, an extremely complicated description, a terrible implementation in react using class components, some weird circular diagrams.

This looks like it's generated by GPT-3.

What is this piece of code even supposed to do?

    function C() {
      var A = {
            something: () => console.log("hi")
          }, 
          B = document.createElement('div');

      B.onclick = () => A.something();
    }

In react:

  function C() {
    const A = {
      something: () => console.log("hi")
    };

    return <div onClick={A.something} />
  }

It's horizontal message passing. Your example is still hierarchical. About the classes: that chapter was written before they decided to change almost everything for the nth time.

I'm glad you disagree btw. If everyone agreed with me than honestly, I'd not be pushing hard enough.

Could you give a piece of usable code that highlights the problem? I really did not understand the point you are making from the example you gave.

I'll consider rewriting it. That section was about doctrine and aesthetics. For instance, you were talking about the functional component way of writing react, or how I talked about

"If reality falls outside the doctrine and really can't be denied then instead of fixing the assumption more often the orthodoxy is amended. A new wing in politics, a new testament in religion, a new movement in the arts, and a new version in software. It permits the avoidance of admitting the failures of orthodoxy while permitting a mechanism to address its shortcomings."

I don't think we'll come to an agreement on this and that's fine, it means I am staking a clear and controversial position which is my goal. Honest people can disagree and I really do appreciate your honesty. Thanks

I was just asking for a simple code example not a philosophical debate about assumptions, orthodoxy and doctrine.

Isn't it possible to connect your abstract ideas to a real world example? And why create en extremely obfuscated react class implementation of something that can be done in 3 lines of functional react code?

Sure. All of them can be organized as hierarchies and that's the point, the organization is codependent with the communication.

Let's say you have things with locations and a map (scooters, restaurants, hidden gold, whatever). You click a thing, it highlights it on the map. You click the map, it highlights a thing.

The obvious to me way of doing this is singletons (or globals).

You've got some routine itemhighlight(thing) or mapcenter(thing) and you generate the things on the page and use something simple like html data attributes to pass things around.

In react there's a fairly unorthodox hack I've got to do things like this but normally you'd have a map component and then some list component with item components.

Then when you tap the map, the stuff is passed up to a container component that gets passed to the list component that goes back to the item component, so long as you create some connections for that to happen.

Everything goes up and down the hierarchy. You don't just directly talk horizontally.

Now sure, there's arguments for and against both approaches and they are as contentious as type systems and editors. But the question was about the "scolding nanny".

Without react you can do both approaches, the first of which requires competency and skill to do well without creating a mess sure. But in react you are precluded from doing the first unless you wrangle it and work around the framework.

It disciplines and limits your freedom. I understand corporate hierarchies, pecking orders, and reasons for doing this. I'm a true anarchist though and that limitation really pushes my buttons.

Given all that, I use react regardless because I first and foremost try to be responsible adult and think it's the current most popular and professional way to do things for the day I'll eventually move on and hand over my code to someone else.

But I fucking hate it. It's a seething and very unhealthy vitriolic hate.

You can have global singletons in React too that trigger events without passing them through the component hierarchy. It's just not clean design in my opinion. The same reason we avoid global variables in most applications, frontend or not.

If you want to go for a sane way of managing global state you can use redux or context which don't require you passing state up and down the component hierarchy. But in my experience, usually when you design your hierarchy and your data well it makes most sense actually using the hierarchy to your advantage.

There's something fractal about it where the higher-level components deal with higher-level state and problems. In the case of the map you have a shared state between the map and the controls which should be explicit in my opinion and not hidden in one of the components' html data attributes.

The more complex applications I develop, the more appreciate the concept of having a "single source of truth" and not sprinkling states in child components.

Right, I claim that limitation was self-imposed and then they found out how unreasonable it was so now they have multiple workarounds in order to emulate the functionality you'd get without them there at all.

So instead of the direct path, now you are doing a much more complicated circuitous path because the orthodoxy had to be amended.

Again, you're going to say this is good and I'm going to say it's bad. I see a problem where you see a solution. This is not reconcilable, that's why there's so many different programming languages. There's no right answer here and I'm ok with merely having a collection of opinions. It's like politics and religion. Whatever, people are different.

>Could you give a piece of usable code that highlights the problem

A shopping cart. The cart state exists in the header of the web page, but the "add to cart" button exists on the product description, far away from the cart. Ultimately, I think, it ends up being a question about state management which is always the hardest part of UI frameworks IMO

But a shopping cart is just a piece of state which you modify through an event listener to a button which in turn updates the UI again.

These days you can do it with a useState or useReducer hook but there are countless ways to implement it, react or not.

But where does that state live? I imagine GP would like to live on the `Cart` component, but since the Add to Cart button isn't a child of the Cart component, you would have to "pass up" some connector. Alternatively you would just have the state live in a common ancestor of both (or at the Root) but I imagine that GP doesn't like that either (global state).

To me it seems obvious that React would be hierarchical. It is a view layer that creates a virtual DOM, that then gets rendered down into the browser DOM. Which is hierarchical.

Horizontal message passing is really a state related issue and lives outside of React.

You can manage your state however you want and then wire up the components however you want. Since those two things are separate concerns. Although there are a ton of options in the ecosystem to do that.

Maybe I'm missing something but your first example in React can just be:

  const B = ({onClick}) => <div onClick={onClick} />;

  function C() {
    const A = {
      something: () => console.log("hi")
    };
    
    return <B onClick={() => A.something()} />;
  }

If your flow degenerates into C -> A -> C -> B -> C -> A then don't blame React because you are missing something obvious(and basic).

First, I want to thank you for the deep dive into one of your grievances with React. I completely understand this wart in React, so much so, that I use it an interview question for frontend developers. This kind of "connecting" is where even more complexity has often reared it's head as the common "solutions" are using something like Redux. A trivial example of what you are trying to explain is like a shopping cart; where the cart exists in the header, but the button to add items to it may exist elsewhere.

That said,

>The great success of React is in enforcing a new kind of authoritarianism: it enforces doctrine by explicitly disallowing heretical code.

I don't think this is a bad thing, after all the success of Rust is also predicated on explicitly disallowing heretical code that may have been commonplace in C. Constraints lead to more maintainable code, which is ultimately what frameworks these provide. I don't think your complaint is unique to React due to the fact it's HTML that influences that hierarchal design. That said, I'm not a front-end dev, and I my exposure to UI patterns is relatively limited; so I'm looking forward to your eventual book.

Wouldn't you just wire up

Button Press -> State -> Shopping Cart View

Just have the state have a function for dispatching a change to the shopping cart which is passed to the button component and pass the actual state to the shopping cart view.

You can have the state live in a parent component, use redux, use context or go more hacky.

>live in a parent component, use redux, use context or go more hacky.

My initial reading of OP's post is that this is the "hack" he doesn't like (even Context wasn't all that encouraged in React IIRC). My amusement, however, is this is, to him, a fundamentally philosophical disagreement with the design of React

> piles of garbage that talentless hacks write don't smash into each other too harshly

That's the entire point. Software is eating the world, and there's not enough talented engineers. We can't just wish thousands more talented engineers into existence, so instead we have to come up with tools that will make people that only have 3 months of coding school under their belt and money as their only motivation reasonably productive.

If you're a god engineer, you have experience of working around constraints. That's just another one.

Oh yes, React is the language of “talentless hacks.” This elitism is gross and wrong and you should rethink your outlook on the world if you believe this.

Elitism? I consider myself to be one of them.

This is not true. It's not that React was specifically designed so that incompetent programmers can create apps. It's that with any good framework or technology people will always flock to the popular one. This is the exact same reason why Java is bashed and Linus prefers C programmers.

An excellent programmer will write excellent code using React, in Java or in C++. It's not about the tool, it's about the one wielding it.

It's hard to believe that you have serious experience in react. Or maybe you've just never seen it down correctly... I have the exact opposite take.

Before react I hated UI programming so much. But the way react deals with state makes it so much easier to build and maintain complex applications.

All you have to do is define how your application responds to any given state and provide explicit controls for asking to update that state. If you do that correctly, your application will be predicable and easy to reason about.

The biggest challenge is it's just not the normal imperative programming model that most devs are used to. It takes time and understand to do correctly, but what doesn't?

> But the way react deals with state makes it so much easier to build and maintain complex applications.

Real question; not being snippy...

I didn't think React had any state management included. A lot of people I've spoken to seem to use Redux, a third party library for handling state.

Is my understanding incorrect?

Reacts out of the box "useState" along side the unidirectional data flow acts as a lightweight, yet very powerful form of state management.

Redux takes that to the next level but is based on similar principles of "reactive" programming. For complex state heavy applications it's extremely powerful, but often overkill for many smaller applications.

Hi, I'm a Redux maintainer. React has always had "state management" built in in the form of component state: `this.setState` in class components, and `useState/useReducer` in function components. Those work just fine.

However, that _is_ limited in that you can only access state inside the current component, or pass it down the tree as props/context. If you need to access data broadly across the component tree, or the data itself does not lend itself to a tree-shaped usage pattern, or you need to minimize the number of components that re-render when you update, or you need to use it _outside_ the component tree, then you may want to look at an external state management library.

I've talked about the tradeoffs in these approaches numerous times:

https://blog.isquaredsoftware.com/2021/01/context-redux-diff...

https://changelog.com/posts/when-and-when-not-to-reach-for-r...

https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...

All that said: React makes writing an application with any meaningful amount of complexity _vastly_ easier to do than trying to do it with either preceding UI frameworks (AngularJS 1.x, Backbone, etc) or jQuery. It isn't perfect, but it's well-suited for a wide range of application development use cases.

React has 'useReducer' now, which can replace redux for most use cases.

But I also think 'react' means two different things. One the one hand, it's "just a library". In industry, it tends to mean... react + JSX + react-router + redux + react-this + react-that + react-redux-this-and-that all tied together with create-react-app. Plus its own command line tools, and browser plugins. It starts to feel very much like a framework then, if not a platform of its own.

I've been using it daily for 5 years and have been programming professionally for about 25. My criticisms of react can fill many pages (and what more, I've written them).

I'll readily admit to being a passionate radical about this stuff. The things I have to say are basically just a bunch of bomb throws and I don't feel this is the appropriate place nor do I have the requisite time.

Rest assured, I've put in a considerable amount of time and effort into my thoughts on the matter and we'll likely disagree, but let's not do that here.

Have you posted your thoughts anywhere online you could share? I'd like to read them just to get perspective of the other side

Don't mean to blow too much smoke but I really liked this response. I don't know if I could be that reasonable if a piece of tech I liked was attacked.

It's reasonable. I know people care and disagree with me and that's welcome.

I'll think about how to best present it gently and prepare something.

The stuff I have is really much more for the STS people who think Silicon Valley should literally be dismantled brick by brick. That's a different audience than my fellow startup engineers (I've got my feet in many conflicting camps)

As someone who has to make impactful "tech stack" decisions on a daily basis, I try to challenge my personal preferences as often as I can.

When someone has a strong negative take on something I thought was great, that's a perfect opportunity to learn deeply about trade-offs or concerns I might not be fully aware of.

If nothing else, it gives me an opportunity to evaluate potential issue, put guards in place to reduce the impact, and arms me to defend my choices should the need arise.

From your other comments you yourself admit that this is a fringe opinion, and I respect that a lot.

I think one thing that would help strengthen your stance would be a plausible explanation for why people seem to actually like React and friends so much.

Maybe your experience is different, but I'm often seeing people want to use React or Vue and lament the times they're stuck with JQuery or something more "old-school".

>> IMO the biggest problem is that the industry became all about developer experience and neglected user experience.

I recently transitioned from being a developer to being an accessibility engineer. I've been able to see first hand how the user experience has been neglected, especially for people with disabilities.

A lot of the JS frameworks are getting better at A11Y, but its still a major work in progress.

Developer time == money.

There is always a time vs end user experience tradeoff, even with physical goods. I think it's part of a bigger trend towards (more prolific) crappy stuff generally.

I do think there is space for tools that improve the user experience whilst not regressing on easy of development.

> I do think there is space for tools that improve the user experience whilst not regressing on easy of development.

Agreed. I feel like I spend 50% of my time on here promoting Svelte which is wildly out of whack with how much I actually use it but to my mind it’s a great example of a tool that prioritises developer experience and user experience without compromise. There is hope.

Elixir's LiveView is similar in my eyes, and more "client-side" tools like Surface (akin to Storybook) are making their way into the Elixir ecosystem.

What is the alternative to catering to developer experience though?

If developers struggle with performant technologies / methods / frameworks, I'm sure they're going to end up producing crap apps in the end still.

Rather than complain, we should be focusing on making good performance the happy path. In fact, I'd say that's most of what the latest frameworks that are popular focus on, so I don't really understand the issue.

If you build the developer experience, they will come. If you don't, I hate to say it, but everyone has mouths to feed.

Hmm, I don’t think this is actually true. There was plenty to complain about at any point in the development of the web, and complaing about bloated frameworks are simply the complaint du jour.

In practice I load every webpage once (even very complicated applications can be loaded in under 2MB), and then go on my merry way.

> IMO the biggest problem is that the industry became all about developer experience and neglected user experience.

Web development leverages a terrible developer experience to create a terrible user experience.

Do you really think the developer experience or user experience were much better in the days of Windows Forms?

Or that building large web applications in jquery or vanillajs can't lead to problematic code even when junior developers are used?