Comment by lhorie | Hacker News Reader

Comment by lhorie | Hacker News Reader

(disclaimer: I'm the author of mithril.js, a framework that can be used w/ JSX)

My initial reaction on this is that this looks like a nice (if minor) DX improvement. Not having to type out `React` when it's seemingly not referenced anywhere makes sense.

The underlying signature change is also interesting. If you need to support IE9, then doing `jsx(name, {children})` is going to save a lot of array slice calls that would otherwise be needed for the `React.createElement(name, attrs, ...children)` signature.

On the plumbing side, there's something that bothers me about this change: given this is seemingly a small life quality improvement, it affects a lot of tooling infrastructure (babel, typescript, etc). From a purist perspective, this has a "cancerous" feel (as opposed to being "encapsulated"). This doesn't mean this is a "bad" change per se, but I do feel like it feeds into the idea that "software these days is way too complex"(tm) that has been popping up recently.

> From a purist perspective, this has a "cancerous" feel (as opposed to being "encapsulated")

I have the same feeling about much of the React ecosystem (edit: though I'd say "tightly coupled" rather than "cancerous"). The other day some folks were discussing the idea of building a new UI backed by a new GraphQL schema. We started talking about the possibility of delivering the UI independently of the GraphQL schema by using an existing REST API, and the idea was shot down as the GraphQL client we're using on the frontend is highly coupled to the UI components. Changing the data source later would have been a highly intrusive change.

I totally understand the benefits that a GraphQL client provides, but it feels like a serious architectural smell that changing the data layer is such a wide-ranging change in a web app. Wrapping a data-source in an API and being able to change the implementation without the rest of the application being impacted is really compelling, and I'm not convinced it's something worth trading-off.

As a counterexample to consider, I would suggest that a client-side web app is coupled to any remote data source intrinsically by a latency-sensitive connection over the network. As soon as you have enough data, you need to defer portions of it and load them on demand based on user interactions. So now the ways in which data was or wasn't factored in a way that mirrors the app impacts it.

Now, there are tradeoffs we can make to deliver an end state to a user: we can normalize and incrementally hydrate the data shown in the client and increase visible jank in the process, or we can realign the app's experience and/or data source around each other.

Decoupling UI components from business components is of course valuable, but that's different from taking that a step further and decoupling business components from the data source. The latter is a significantly more challenging proposition.

Also, there's some fuzziness here in what we mean by decouple. REST vs SOAP vs GraphQL as transfer layers can be abstracted away as implementation details, but I'd place a higher emphasis on the shape of the data and how it has to be traversed in the client. If you have a paginated list, for example, and you only want to load it once, but you need to display both a summary and load it incrementally, things can get complicated as more functionality is built out from that starting point, regardless of transfer layer.

As a counter-counter-argument, one could argue that there's coupling to the database and one might as well then write db queries from their single file components. One stack (meteor) took that idea of trading loose coupling for productivity to the extreme but then suddenly found itself in an awkward position when react and npm exploded in popularity (and Mongodb lost mindshare).

Surely something else will eventually displace react and/or graphql, just as previous stacks and paradigms have been overshadowed. But then we go back to my original assertion: refactoring away from the legacy of the tools we no longer like is decidedly going to be more complex if we chose to sacrifice loose coupling in favor of something else (performance, initial dev speed, what have you)

Case in point, esbuild looks like a very promising replacement for some web plumbing. But if there needs to be extra collaboration to support this there, other stacks can take the opportunity to dash ahead (e.g. vite) while the react team is busy collab'ing with all these compiler projects.

> but I'd place a higher emphasis on the shape of the data and how it has to be traversed in the client

There is something incredibly satisfying in rendering an entire UI experience from a single GraphQL payload, without having to build intermediary data structures to stitch it all together from multiple endpoints.

I agree that that tight coupling is a smell, but it's also not required; the Apollo (GraphQL) tooling offers it and some of the documentation encourages it for new users, but not using it is a first-class option too. That's the paradigm around which (for example) the entire application for which I recently co-led development is built. We didn't have any trouble using it, and while replacing GQL with REST would still be a heavy lift just due to the fact that it's a highly data-driven application for which we also maintain our own backend, we wouldn't need to touch the UI to make that change.

I don't love that the docs tend somewhat to encourage the API option with tighter coupling between UI and data, and the Apollo documentation is in general pretty lightweight by my standards. To criticize on that basis is fair. But it isn't anything like forced, and to write off GraphQL or React as "cancerous" on account of someone having made a less than optimal decision in how to use them seems premature.

> to write off GraphQL or React as "cancerous" on account of someone having made a less than optimal decision in how to use them seems premature.

Apologies, cancerous isn't how I'd describe it, but the sentiment of the quote did resonate. "Tightly coupled" is more representative of my concern.

Thanks for the counter-example!

The unencapsulated thing is exactly the feeling I got. I am most confused with others' code when there is implicit imports or declarations of any sort. "Where did this come from??? Why is this working???"

I had the same thoughts about React hooks although perhaps I don't correctly understand the motivations. Class components have extremely clear, compartmentalized lifecycle functions, and now the advice is... make everything a function-scoped closure? Let redux do some opaque context sorcery to update your components?

React (and others) hit the paradigm right on the head the first time, IMO. It's change for change at this point, which is fine I suppose.

>I had the same thoughts about React hooks although perhaps I don't correctly understand the motivations.

Not necessarily hoping to change your opinion but maybe this helps:

https://medium.com/@dan_abramov/making-sense-of-react-hooks-...

Both the old and the new transform are built on Babel, so Babel is involved. Both transforms participate in TypeScript typing, so TypeScript is involved.

Not that you're not well aware of both these points, but I do feel like the point at which to scruple over "software is too complex" comes somewhere well before the point where JSX is happening at all, and I'll admit it's a little confusing to see them apparently in the opposite order here, especially put in such strong terms as these.

After all, there's a distinction to be made between essential and accidental complexity. I'd argue that what both these transforms do is to abstract away a lot of the latter so that the former can be more easily seen and managed, and I think they do a pretty good job of it. (The rest of React, I'm not so sure about, some days...)

Mithril.js is a pleasure to use, thank you for it.

Reply on news.ycombinator.com