Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My Reaction to React

pseudoconcurrentthought.wordpress.com

Post reply on HN
Print view View original

121–130 of 147 posts

Re: My Reaction to React

#121

Post by Chris_Newton »

falcolas wrote: post #78
undo76 wrote: post #64

Am I the only one that thinks that the author is trolling? I mean, the final code has obvious flaws: a) Difficult to read and mantain. (Compare with the version below). b) Inefficient in a real world scenario as it has to recreate the DOM every time the model changes. c) Difficult to test as it requires a DOM API. d) XSS issues (Text returned from the service is not escaped in the DOM!) e) Non isomorphic (Unless we h…

Without taking sides, understanding your application requires a fairly complete understanding of React, JSX, Javascript, the DOM, and how React ties all of this stuff together. Sure, your code by itself is quite small, but when you add React, it grows by the size of React. On the other hand, just by knowing Javascript and the DOM, you can understand exactly what is happening in the OP's code.

You make a fair point. That said, one of the nice things about React is that even a moderately experienced JS programmer can learn the basic mechanics (including how to use JSX) in a few hours. That’s a reasonable investment for a useful tool, and React has a much shorter learning curve than most of the larger JS frameworks.

Re: My Reaction to React

#122

Post by warfangle »

undo76 wrote: post #79
falcolas wrote: post #78

Earlier quoted context omitted.

Without taking sides, understanding your application requires a fairly complete understanding of React, JSX, Javascript, the DOM, and how React ties all of this stuff together. Sure, your code by itself is quite small, but when you add React, it grows by the size of React. On the other hand, just by knowing Javascript and the DOM, you can understand exactly what is happening in the OP's code.

Well, technically you don't need to know JSX, but it pays off to know it IMHO. Moreover, the DOM API is much more complicated than React API and the latest doesn't depend on the particular browser you are using. But yes, to use a technology, you need to understand it. Regarding the size, you are right, I wouldn't recommend to use React for such a tiny task.

IMHO, the JSX as used in this example is pretty obvious if you know ES6 syntax. The only "weird" part is curly braces for data interpolation, but even that is pretty semantically obvious.

Re: My Reaction to React

#123

Post by EdSharkey »

m0dc wrote: post #77
brightball wrote: post #67

Earlier quoted context omitted.

100% agree on the common language front. The real challenge is when you're dealing with a language that has framework saturation, so there isn't really a "common" framework. Ruby and Python have Rails and Django which goes a LOOOOONG way in fixing this problem. Not many languages have that one, dominant framework and usually that's because people keep inventing new ones to deal with shortcomings of current ones OR th…

The problem with coalescing around React is that it's not really a framework. The lack of a default Rails-like monolith encourages every dev to assemble their project from a la carte pieces - so every React app has a different project structure, a different data library, a different build tool, etc. Even worse: since everyone wants to build their app "the right way", there's constant churn as new best practices and m…

React is a UI component framework. The testing-in-isolation and composition you can do with React makes it very productive. It's good for reasoning about the fine details in a UI.

Yeah, it would be good to get a router and couple that with React. React is not a total solution for making a web app, and anyone that picks it up seriously will learn that very quickly.

We need lots more libraries like React that focus on one area of development and do that well rather than all these own-the-world frameworks that have both shiny and awkward parts. I want devs to do their front-end library selections very carefully and build a mosaic that fits together well for their app's particular use cases.

Re: My Reaction to React

#124

Post by Chris_Newton »

cloverich wrote: post #119
mstade wrote: post #115

Earlier quoted context omitted.

I don't know, I think this "use what's out there" mentality gets out of hand at times, and at least makes me kind of depressed. For sure, I think you should use whatever is available if the only reasons you want to roll your own tooling basically comes down to syntax or "but it feels nicer" kind of arguments – that's like reinventing screwdrivers because the handle of one gave you a blister that one time when you wer…

> But if you have different ideas about how to structure things, come up with new abstractions that you find solve the problems at hand better than any of the abstractions available to you, then by all means do roll your own. We don't need more clones, but we do need fresh thinking and ideas that don't follow the pack. My view on this is that generally if you haven't extensively used at least a couple of existing fra…

My view on this is that generally if you haven't extensively used at least a couple of existing frameworks, it seems unlikely you'll do anything than re-invent existing stuff (at best) in a slightly different fashion.

If your background is mainly in modern JS development, that’s probably true. I don’t think it holds more widely, though. Modern JS lives a little bit in its own world, and the state of the art in that world is sometimes decades behind the wider programming industry.

With the interest in things like React and Flux there has been a lot of discussion in the JS community recently about unidirectional data flow. However, the same sort of separation of input interactions from output rendering goes back to at least the 1970s and 1980s when ideas like MVC were being developed.

Similarly, React and similar libraries get a lot of attention for the declarative way you can specify rendering and the relatively efficient way they update the DOM, but again we’ve had declarative UI libraries on the desktop for decades, and anyone who was doing graphics programming in the last millennium will be all too familiar with doing batched updates.

It’s not much of a stretch to think that someone with a background building UIs in some of these other contexts might have different ideas to the current JS community about the architecture they want for their UI code, nor that some of those different ideas might be better for some projects than the mainstream today.

Re: My Reaction to React

#125

Post by goldbrick »

jonahx wrote: post #97
undo76 wrote: post #64

Am I the only one that thinks that the author is trolling? I mean, the final code has obvious flaws: a) Difficult to read and mantain. (Compare with the version below). b) Inefficient in a real world scenario as it has to recreate the DOM every time the model changes. c) Difficult to test as it requires a DOM API. d) XSS issues (Text returned from the service is not escaped in the DOM!) e) Non isomorphic (Unless we h…

Thanks for posting your React version and offering a bullet list of real points of critique. That said, please don't use the word "trolling" to make what is essentially an ad-hominem attack against someone whose point you disagree with. The author probably spent at least an hour, if not multiple hours, thinking through a problem and presenting a solution as a blog post. Whatever you think of his argument, this is cle…

Thinking through the deeply complex problem of how to display a static heading, image and three bullet points? This is master troll material. I LOLed greatly.

Re: My Reaction to React

#126

Post by jwiley »

up_and_up wrote: post #94
skewart wrote: post #9

I went down a similar path a few years ago when starting a new project. Instead of learning a new framework I wrote my own. It took less time overall, since the logic wasn't especially hard to write, and it was easier to debug - at first. Everything changed as soon as another developer, then two, then three, started working on it with me. They were not happy about learning how to use my custom MVC framework. Perhaps…

> Instead of learning a new framework I wrote my own. Hands down, the worst code I have ever inherited from another developer is in a scenario like this. Happened to me a bunch of times. Worst ever was a former boss who didnt "trust" Prototype.js nor jQuery and decided to write his own version. Pure hell. Please be kind to your fellow programmer brethren. Unless the problem you are trying to solve is uber simple and…

I second that emotion. I inherited an entire ecommerce platform built around Yahoo Store's proprietary RHTML language. The only documentation was a single comment:

"RHTML turing complete?"

I never did find out the answer to that, because I only lasted one month at the job. I'm sure it was a great learning exercise / psychotic breakdown for the original author.

Re: My Reaction to React

#127

Post by dchest »

undo76 wrote: post #64

Am I the only one that thinks that the author is trolling? I mean, the final code has obvious flaws: a) Difficult to read and mantain. (Compare with the version below). b) Inefficient in a real world scenario as it has to recreate the DOM every time the model changes. c) Difficult to test as it requires a DOM API. d) XSS issues (Text returned from the service is not escaped in the DOM!) e) Non isomorphic (Unless we h…

Could you please point out where the XSS issues are?

Re: My Reaction to React

#128

Post by marknutter »

EdwardMSmith wrote: post #113
marknutter wrote: post #84

Earlier quoted context omitted.

The major difference being, if something is written as a Polymer web component, it's immediately usable by anybody else writing for the web (with the possible exception being React developers because of their unwillingness to acknowledge or adopt web components as a standard).

> Trying to compare and contrast React with WebComponents inevitably results in specious conclusions, because the two libraries are built to solve different problems. WebComponents provide strong encapsulation for reusable components, while React provides a declarative library that keeps the DOM in sync with your data. The two goals are complementary; engineers can mix-and-match the technologies. As a developer, you…

Directly from your link:

"Note: The programming models of the two component systems (web components vs. react components) differ in that web components often expose an imperative API (for instance, a video web component might expose play() and pause() functions). To the extent that web components are declarative functions of their attributes, they should work, but to access the imperative APIs of a web component, you will need to attach a ref to the component and interact with the DOM node directly. If you are using third-party web components, the recommended solution is to write a React component that behaves as a wrapper for your web component. At this time, events emitted by a web component may not properly propagate through a React render tree. You will need to manually attach event handlers to handle these events within your React components."

It's worse than that, though. Web components that maintain their own state can be randomly squashed by React's virtual-DOM diffing algorithm because of the way elements are held in memory. They are just not compatible, and the React Core team has made no apologies about not agreeing with the overall concept of Web Components.

Re: My Reaction to React

#129

Post by brightball »

m0dc wrote: post #110
sotojuan wrote: post #98

Earlier quoted context omitted.

Doesn't seem like it will ever be that way for React to be honest. If you want a JS monolith try Ember. Angular 2 may also be that way since it uses Ember's CLI tool.

I love Ember - and one of the best things about it is its emphasis on convention over configuration. React is the exact opposite. While it's an amazing library, it only makes up one part of a front-end stack, which causes everyone to waste tons of time deciding on what the other parts should be. A set of sane, accepted defaults would help the community tremendously. Personally, I'm hopeful that that's what React/Redu…

I'm going to take a leap and assume you've done some Rails work because Ember tends to have a lot of Rails users.

In Rails, there's a default view layer handled by ERB but it can be mixed and matched with HAML, Slim or any other view layer. Likewise, you can use ERB, HAML and Slim outside of Rails entirely.

There are frameworks like Meteor that let you have an interchangeable view layer. There are others that build the entire full stack framework around THEIR view layer.

If Meteor made React the default view layer...that would be a step towards unifying the fronts. One full stack system with a shared layer that can be use inside or outside of that particular framework.

Re: My Reaction to React

#130

Post by brlewis »

undo76 wrote: post #79
falcolas wrote: post #78

Earlier quoted context omitted.

Without taking sides, understanding your application requires a fairly complete understanding of React, JSX, Javascript, the DOM, and how React ties all of this stuff together. Sure, your code by itself is quite small, but when you add React, it grows by the size of React. On the other hand, just by knowing Javascript and the DOM, you can understand exactly what is happening in the OP's code.

Well, technically you don't need to know JSX, but it pays off to know it IMHO. Moreover, the DOM API is much more complicated than React API and the latest doesn't depend on the particular browser you are using. But yes, to use a technology, you need to understand it. Regarding the size, you are right, I wouldn't recommend to use React for such a tiny task.

Regarding size, a Mithril/MSX implementation would look about the same.
Post reply on HN