Hacker News Reader

Comment by warent | Hacker News Reader

> but all of the other ideas have been implemented and used on the web before.

Is this true? I've worked in web dev for like 6 yrs now and React has provided a significant number of concepts and technologies I'd never seen before and still dont see elsewhere.

For example, JSX. Yes, it originated in php but React was its first time being implemented in the frontend.

Also the concept of hooks and functional components. The fact that you explicitly define side-effects in the render of a function, with memoization or execution dependent on arbitrary state, is a new invention as far as I'm concerned.

View on HN

Honestly, the separation of concerns movement where content writers do HTML, designers do CSS and programmers do Javascript, all with with minimal overlap, set web development back a good 10 years. React was a wake up call that the three are intertwined so closely that you cannot think about them in isolation.

One of the early criticisms of React was: “You can’t do HTML in Javascript. You shouldn’t be styling in JS! That violates the separation of concerns.” React skyrocketed productivity and allowed scaling without spaghetti. That’s why it won.

CSSZenGarden was fun, but how many companies seriously did redesigns by just swapping a style sheet? Only repeat the dogma if it makes sense....

HTML in JavaScript still feels wrong to me and I still hate JSX. The Vue and Svelte approach to simply having the HTML in the same file was much more digestible.

I think React won because it had a more gradual learning curve than Angular and a didn’t drastically change between versions.

And the idea that HTML/CSS/JS are non-isolated is over-thinking it. It only applies to the world of Webapps. HTML can be published and served all day without CSS or JavaScript. And you can do a lot with HTML and CSS alone.

Why hate JSX? There are lots of benefits to it, like debuggability and variable scoping rules are exactly those of javascript. Templating languages, on the otherhand, are not debuggable and have awkward scoping rules. And, they always feel broken in one way or another.

JSX is not magical which is what I appreciate the most about it.

Don’t forget proper and full typescript support. Going back to vue (2) after doing tsx was like going back to jquery; loads more context switching and mistakes.

The ability to type `children` alone makes a world of difference.

Yes, yes and yes. All of these concepts are variations of what has been done before in a number of ways. Mostly by "FP academics" who "live in fantasy land", until everyone else starts using them too.

Transpiling, hooks and components have all been done (and done better) before React came along, but often they were laughed out as esoteric toys that have nothing to with "real programming". It's just hard to teach these concepts until you actually use them, and it's hard to get people to use these concepts unless they are included in something else that you need.

The same happened early with React, both JSX and VDOM were laughed at by many developers because "they looked stupid" to people who didn't understand them and were used to one way of doing things. MVC+jQuery+templates was the flavour of the day.

Same thing with TypeScript, FRP and so on.

Most likely, whatever concept is gaining momentum today, it's an exact or approximate copy, or in rare cases a novel remix of what has been researched 10-20 years ago, and used in production for 5 years before you heard about it on HN

These people who like to apply category theory etc. in programming have heard this mocking of their work as stupid esoteric fantasy (and then seeing them become mainstream later) so often that they literally called one of their specs "Fantasy Land" https://github.com/fantasyland/fantasy-land

There's still lot of work to be done. JavaScript doesn't even have proper immutable data structures natively, which would be a REAL low hanging fruit.

I'm very curious what the better, academic version of VDOM, hooks and components that has already been done looks like in comparison to React.

Svelte does reactive UI without a VDOM at all. Every DOM operation flows from declarative instructions based on the state of the application, without a need for VDOM or hooks.

The compiler is quite mature and used by countless apps in production right now.

https://svelte.dev/

I've been using it myself and it doesn't feel academic at all. The Svelte Kit toolkit, a successor to the Sapper frameworks is also ready to use but it's not 1.0 yet so might be a bit unstable. But if you're worried about having to figure things out then you can use Sapper+Svelte or just Svelte just fine, and they're very robust and well documented.

I know what Svelte is. Svelte wasn't done before React or by "FP academics" though, which is what you said in the comment I replied to.

As I said, the VDOM was novel. However, unidirectional data flow, lenses and FRP with RxJs all predate React. There was also Elm which was a full framework that was based on these concepts, and ClojureScript with its whole ecosystem that did things a bit differently. Though most people who do utilise functional programming concepts prefer not to use a framework but pick-and-choose libraries that do the job for that specific project. That means that the field was (and is) very scattered, and there's no single "React but better and made earlier". Because React is a unique combination of tools. But each of those tools have been done in one form or another many times, except for the VDOM, which I believe was novel.

On another note, a React component in FP is just any regular old JS function with a signature: `(state) => HTML string`. React is such a simple concept that it wouldn't have needed any sort of library, if it weren't for the performance and DOM reset issues.

> However, unidirectional data flow, lenses and FRP with RxJs all predate React.

They may predate React, but React made them easy.

Good luck explaining how lenses work.

Rx? it took the author of RxJava months to understand the concept. And he had the author of Rx.net there to explain stuff to him. [1]

> there's no single "React but better and made earlier".

Yes. And that is precisely the point

[1] https://twitter.com/dmitriid/status/811561007504093184

Well that's why said

> React made a huge impact on web dev and deservingly so

The VDOM was revolutionary, no question about it. The comment I was replying to didn't even mention it.

Your original comment was literally this, emphasis mine:

--- start quote ---

All of these concepts are variations of what has been done before in a number of ways. Mostly by "FP academics" who "live in fantasy land", until everyone else starts using them too.

Transpiling, hooks and components have all been done (and done better) before React came along

--- end quote ---

When asked about the emphasized part, you mentioned Svelte for some reason. When called out on that, you went and listed a bunch of things, ... none of which are really better, and are quite esoteric. To the point that it took the authors of some implementations months to understand the concepts.

React (pre-hooks) could be picked up in less than a day, and just worked. Re-creating React concepts from scratch was a three-page tutorial.

If you judge technologies based on a single anecdote you've heard on the internet then I don't think this conversation serves any purpose. I don't know what bone you have to pick with any technology other than React, but achieving declarative DOM manipulation pre-React was as simple as `(state) => $('<div>').innerText(state.message)` with the plain old jQuery. That was definitely easier than learning React, and by building a component structure with vanilla javascript functions, you could have all the functionality and expressiveness of JSX without a compile step or external libraries.

Of course this would cause problems that I've described in this thread before (scroll/form state resets, performance problems etc.), so the VDOM was the missing piece of the puzzle. Overall the concept of declarative UI was incredibly simple and predated React, but the VDOM was a great thing that solved the problems people were having with declarative DOM manipulation. If React had shipped just with the VDOM implementation, it wouldn't have needed to expand into a full-fledged framework and introduce a bunch of band-aids on top it. React deservedly skyrocketed, and the VDOM was an incredible thing to introduce at the time, but every part of React is quickly becoming outdated as more FP concepts from the past are introduced into the mainstream.

So all in all, React shaked things up in a good way, and finally people are ready to move on to make their apps actually reactive and taking a serious look on things that have been "academic" before.

> If you judge technologies based on a single anecdote you've heard on the internet

I don't

> I don't know what bone you have to pick with any technology other than React

I don't have a bone to pick.

> but achieving declarative DOM manipulation pre-React was as simple as

Yes, it was possibly achievable. Did anyone achieve it? You claimed that evertyhing React has was done better before React. When asked about examples, you answered first with Svelte (which appeared after React), and then with disparate technologies which are are at best esoteric and at worst extremely complex.

> That was definitely easier than learning React, and by building a component structure with vanilla javascript functions, you could have all the functionality and expressiveness of JSX without a compile step or external libraries.

You probably could, but did you? Oh, wait, you didn't. The hot tech du jour when React was released were knockout.js and backbone.js.

And, once again, the etirety of "learning React" took less than a day. And "building a component structure using vanilla javascript functions" was literally a three-page tutorial if you wanted it.

Compare this to Rx that you gave as an example of something "better than React". The author of the original Rx.Net sat by the author of RxJava, and it still took the author of RxJava several months to understand the concept. Lens, another of your examples, is esoteric even in Haskell.

But sure, "everything was done better before React came along" :-\

> React shaked things up in a good way

Indeed, it did.

Funnily enough, you start with "Transpiling, hooks and components have all been done (and done better) before React came along" and then continue with "there's no single 'React but better and made earlier'."

>You probably could, but did you? Oh, wait, you didn't. The hot tech du jour when React was released were knockout.js and backbone.js.

I did. It's kind of funny to hear that you cannot even entertain the idea that people actually did declarative UIs before React with plain old vanilla JS, because that was my bread and butter back in the day. That's precisely how I did frontend until React came along, and so did many others. We sometimes sprinkled in some CoffeeScript to get nicer function syntax, before () => {} and babel existed, but it wasn't necessary if we wanted to avoid a compile step.

Just because some frameworks were prevalent at the time didn't mean that everyone used them. Large portion of seasoned developers rejected all frameworks and still do today. They had shot themselves in the foot with MVC/"trying to do everything" -frameworks enough times to learn that not all answers come from a single framework that encompasses your whole application. This is nothing new or esoteric, and still today a good lesson to learn for new developers. Instead many people continue to use "the standard" framework, fighting against it when it fails to fit the domain logic of their app, and waiting for a new framework to arrive to save the day. Frameworks have gotten much more flexible about this today, but React wasn't anything revolutionary on the framework side of things.

It's not as simple as "React bad/React good". A framework/library can be good in certain aspects and bad in others. I loved React when it came out, because of the VDOM. Wasn't a fan of everything else though, and especially not a fan of how it was used as "the new standard framework to tightly couple your application into". This is not a contradiction, it's just non black-and-white thinking.

> I did. It's kind of funny to hear that you cannot even entertain the idea that people actually did declarative UIs before React with plain old vanilla JS

By you I meant "collective you". I don't care what individual developers did that no one knows about.

> Just because some frameworks were prevalent at the time didn't mean that everyone used them.

    define: prevalent

    1 : generally or widely accepted, practiced, or favored : widespread

    2 : being in ascendancy : dominant

> Large portion .. upto ... flexible about this today

Bears little to no relevance on the discussion

> React wasn't anything revolutionary on the framework side of things.

Except, it was. It upended the prevalent way of doing things and ushered in a new prevalent way of doing things.

    define: reovultionary

    1 c : constituting or bringing about a major or fundamental change

I did bring about a fundamental change: the prevalent way of doing things on the web changed.

> It's not as simple as "React bad/React good".

Of course it's not. But we're not discussing whether it's bad or good.

> it's just non black-and-white thinking.

So far your "non black and white thinking" is "everything React has was done better befroe React, but I can't show anything to prove this except some disparate things that are both complex and esoteric, and I can also go on a prolonged discourse about how some developers don't use frameworks and may have done things a la React before React".

I already told you what I did and several developers did before React to combat the same problems the React addressed, but somehow you seem to dismiss all of it. If you don't want to believe it, that's fine. I know what kind of code I wrote before React, your ramblings won't change it. Have a good day.

This disagreement is related to discussing different things:

What devs can implement on their own beyond frameworks, and what frameworks mean to how the community as a whole operates.

"Defaults matter."

I remember it a bit differently

for context, I wrote the first web frp+vdom and helped inspire the creation of rxLinq and related systems, and we even did a whacky thing back then that predicted Parse/Firebase/redux/graphql/falcor, including some basic features they still don't have (should have spun out a startup instead of getting a PhD!). our group even did the first lenses for the web, though that one ended up much less usable. I think we did all that around 2003, while the alternatives were PrototypeJS, jQuery, and a couple other more sugar-level things

however.... react with hooks, jsx, and the various css modes nowadays is pretty awesome, and eliminates most of the needs for streams. main lack there is more for rich animation, than web apps. graphql, redux, and friends are all still clearly clunky technologies with limited shelf lives, so I'd focus more there than react for basic abstractions

at the same time, nowadays I think more about synthesis, ml, end-to-end GPU computing (actually proposed that back then too!) and other more powerful ideas than revisiting frp/lenses/etc...

Then I stand corrected. :) Maybe I wasn't looking hard enough earlier.

How is the vdom novel? Any retention mode GUI does that, hell the DOM itself does that. It’s only novel in that they reimplemented it in “user-land”, because of the performance shortcoming of the DOM.

It was novel because you couldn't refresh the whole DOM based on your application state without user experience suffering, before VDOM diffing came along.

And they still had to execute the DOM operations anyway so I feel scepticism of React was warranted.

When the complex reality of JS applications was reached in React, React shortcoming became more and more apparent.

There's no free lunch.

The easier to mentally digest appeal of 'redraw the whole thing every-time'* was fantastic but performance was always going to take a massive hit past an easily reached point.

* The difference this time was the diff engine was going to be smarter than before but it was not good enough.

> all predate React. There was also Elm

No, React was first. It was in production, if internally, for more than a year before Elm came onto the scene.

The esotericity is not in the expressible semantics, but in the syntax.

I think the Opa language was doing JSX-like code in the frontend before JSX http://opalang.org/

Both Opa and JSX were created in 2011. Opa had other innovations as well, such having the same code base run on both client and server (like Next.js). Unfortunately it didn't get traction and was abandoned by the creators.

JSX as syntax goes back to ES4 and the E4X specification (though the function aspect goes back to php as far as I know).

Reply on news.ycombinator.com