Comment by eyelidlessness | Hacker News Reader

Comment by eyelidlessness | Hacker News Reader

The things I most value about React (and other similar libraries) but seldom see mentioned in these kinds of comparisons are:

- Rendered components are a data structure, not a template. As a result, React is renderer-agnostic (enabling libraries like React Native, trivial SSR, even rendering to arbitrary APIs like smart TVs), and it’s simple to manipulate those data structures (allowing a variety of abstractions and optimizations that are substantially more complex and error prone when the rendered product is an HTML string or DOM tree).

- Quite a lot of common problems can be solved with pure functions (props in, rendered structure out), which are simple to reason about and maintain, and rarely require any advanced knowledge of anything besides HTML/JSX.

- Static type checking and automated testing of JSX are well supported, and trivial to run without a heavy (eg browser) environment, out of the box.

- The proximity of data and rendered structure is easy to reason about, navigate, and validate.

I’m sure these qualities can be achieved with other UI frameworks whose default rendered product is templates, and perhaps I underestimate the extent to which they’re priorities in Vue (or Svelte, or any other library not defaulting to JSX), but since they so rarely come up in these comparisons or the other libraries’ elevator pitches, I assume they’re just not high on their priority lists.

As a Vue developer I appreciate this post, explaining how data/template proximity of React can be advantageous. If you like data/template separation Vue might be worth a shot.

Vue 3 is introducing a detached renderer, and given it's amazing component boundaries and decision caching it will give React a good run for the money on things like native output.

Vue 3 also introduces the composition API utilizing other features mentioned.

To each is own!

Pardon the derailment, but "To each is own" is a fascinating mondegreen [1] I've been seeing surprisingly often lately. The classic phrase was the strangely gendered "to each his own [choice]" and the "proper" phrase is probably "to each their own [choice]". "To each is own" implies something else, but I'm not entirely sure what. "To each is own[er] [of choices]" perhaps?

I've seen it like two or three times in recent weeks and find it fascinating. (Sorry, not trying single you out, or derail the conversation too much, but armchair linguistics is a hobby of many on HN and somewhat curious if others have spotted it.)

[1] https://en.wikipedia.org/wiki/Mondegreen

haha interesting, I think I was trying to emphasis personal preference, some of what picking a framework comes down to.

In my idiolect, changing the gender of pronouns inside of idioms is highly marked, even though I use singular "they" as the epicene pronoun.

> The classic phrase was ... strangely gendered

I don't think it was "strangely" gendered; despite recent growth in the corpus frequency of singular "they", many formal manuals of style still prohibit its usage, preferring "one" as the epicene pronoun. Singular "they" has existed for about as long as Modern English, but generic "he" was significantly more common throughout the 20th century. Given how long idioms take to change, generally speaking, I think it should be unsurprising that this usage of generic "he" remains common.

The classic paper on this is "Androcentrism in prescriptive grammar", from 1974, which presents the argument that singular "they" was more common before the prescriptive grammar movement in English, which greater increased how common generic "he" was[0].

[0] https://www.cambridge.org/core/journals/language-in-society/...

"Strangely" was my simplistic way of very briefly glossing over that history that those "prescriptive grammar" changes was a I feel strange period in the language where Classical Latin studies influenced a redirect of the language's course that shifted a lot of idioms from say their Shakespearean Middle English states for some weird idea that being more like Classical Latin was a good thing for English.

Probably a typo on "to each his own"

I wouldn't say that data/template proximity is required or desirable in React.

Yes, you _can_ do fetching and rendering in a single function, but that doesn't mean you should.

I will even go a step further and say that, in React, there is no data-part. React is nothing but a really powerful templating system.

(EDIT: It's actually more nuanced, but this is how I approach it.)

The data-layer is usually handled by another library like Redux, Apollo Client or React-Query/useSWR.

thanks for the clarity

I think probably my proximity point is less clear than it could be. The “proximity” I find appealing is that a component is either a function of data (“props”) returning the rendered structure, or an encapsulation of props and state returning the same... and in those cases (especially with static type checking) makes it easy to understand and navigate data flow, in a way that a template separate from its data types usually isn’t. Of course it’s good to separate the business logic from the rendering, but that still produces a more clear understanding of the data flow.

I am starting a new web project next week (first web project in years), thank you for your explanation. I like treating code as data and vice-versa so i figure REact will be better for me than Vue, despite my initial choice. For sure it will be better than vanilla+Jquery :P

I’d strongly encourage looking at Next.js (with TypeScript if you prefer or have an open mind to it; TS support is first class now with no additional action needed than using .ts/.tsx files). It’s really great out of the box for many common web needs, has sensible defaults but easily configurable using other common tools, provides SSR/SSG/many optimizations out of the box, and a great track record of continual improvement.

Re: comparing to jQuery.

A lot of the ease and benefits depends on your style.

If your code pattern was to have variables holding your state and rendering html based on that, you will have an easy transition to React ( and likely didn't suffer horrible pains with jQuery).

If your code style is to update the DOM to reflect your state, and when you need to know something about state, you read the DOM, then React will feel odd and complex (and you likely have had jQuery projects work great until they hit a level of complexity and then they suddenly become brittle and hard to change)

This is why I prefer React - the best practices if React are just the best practices for functions. (That and I don't like the pseudo js syntax of Vue with the mysterious scoping)

Reply on news.ycombinator.com