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

71–80 of 147 posts

Re: My Reaction to React

#71

Post by ohnomrbill »

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…

I fully agree that his version has flaws, and I certainly am not convinced that he presents a credible case against using React. But to be fair, I think part of his rationale for doing things this way is to avoid the configuration needed to develop with React. I'm somewhat ignorant, so what is the necessary tooling/configuration needed to convert this file to something that can easily be executed in the browser?

Re: My Reaction to React

#72

Post by luiscarli »

Specific tools are built for specific purposes.

Do you think the camera from an iPhone is better than DSLR with a 5k lens?

For the kind of pictures I take the iPhone is more than enough, I don't want the bulk and all the options of a DSLR.

For the web apps I built, it would be a very big hassle todo then without React and the modern front-end stack.

To deal with the complexity of my projects I need hight end tools. A lot of people don't.

Re: My Reaction to React

#73

Post by armandososa »

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…

I suspect trolling too. It would be too easy to make his code more readable, like abstracting all those `addEventListener` and `document.createElement` and make some kind of factory for his Definitive Module Pattern.

Also, what's with that syntax color scheme?

Re: My Reaction to React

#74

Post by armandososa »

vog wrote: post #30

I don't get the boilerplate around App.main: var App = { main: (function() { window.addEventListener('load', function() { // ... initialization ... }); })() }; The initialization code is with an event handler function, fine. But then: - Then registering of that event handler is stuffed into a closure, although it doesn't declare any variables or pollutes the global namespace in any way. - This closure is then called…

It's an exercise on how to do everything with more code.

Re: My Reaction to React

#75

Post by undo76 »

ohnomrbill wrote: post #71
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…

I fully agree that his version has flaws, and I certainly am not convinced that he presents a credible case against using React. But to be fair, I think part of his rationale for doing things this way is to avoid the configuration needed to develop with React. I'm somewhat ignorant, so what is the necessary tooling/configuration needed to convert this file to something that can easily be executed in the browser?

It is a misconception that you need a lot of configuration to start with React. The minimum setup requires just to import the React libs in your webpage and to transpile your code to ES5 using Babel in case you are using JSX/ES6 (recomended).

Of course for bigger projects, it pays off to use an automatic build tool like webpack or gulp.

https://jsbin.com/keyuqohusa/edit?html,js,output

https://babeljs.io/repl/#?experimental=false&evaluate=true&l...

Re: My Reaction to React

#76

Post by moron4hire »

basch wrote: post #69
ashearer wrote: post #66

Earlier quoted context omitted.

I see parallels to PHP initially taking off for web development instead of Python via mod_python. Paradoxically, it was so much fun to build your own web framework in Python that everyone did, so none got enough traction. By the time Django finally broke through, PHP (with a good-enough mini-framework baked in) already dominated Python for web development, and the fragmentation of the Python world was arguably a cont…

php was explicitly designed as a way to make dynamic web pages. it evolved from effort to achieve that goal. mod_python didnt come around until 2000. by then php4 was already out

PHP was never explicitly designed.

Re: My Reaction to React

#77

Post by m0dc »

brightball wrote: post #67
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…

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 micro-libs are introduced every couple of months.

I'm really hoping that one of these React dialects will win out soon, as it's not really a "common language" until everything is mutually intelligible.

Re: My Reaction to React

#78

Post by falcolas »

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.

Re: My Reaction to React

#79

Post by undo76 »

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.

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.

Re: My Reaction to React

#80

Post by brightball »

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…

I'm not an expert in this area, but the impression that I've gotten from the React front is that one of the benefits and reason for traction it isn't a framework as much as a very good way to handle the view layer that's flexible enough to let people take liberties with the rest of their application design...and the way that it handles it works very smoothly with server side rendering as well.

Much like jQuery being able to work with other JS libraries smoothly was a big selling point, React seems to be providing a modular approach that's flexible enough to work with many of the more opinionated options out there without having to dictate everything about the application.

One of the biggest churn points around JS frameworks wanting to do things this way or that way, full single page app or hybrid server side / client side, integrate to existing site or build from scratch.

End of the day, the browser is the view layer. Most of the other frameworks that try to make it significantly more than that are always going to lose when being applied to existing systems or server side heavy systems.

The React approach is basically just simplifying and removing pain points. It's easier for Rails to define some standards on the server and database side because the server side is where the core logic of every application lives. You're not going to try to apply Rails to an existing application, so it doesn't have to worry about fighting that battle. That is a major consideration of client side code, which is why you're seeing more wide spread usage of React. It fits more use cases instead of trying to be Rails in the browser.

Post reply on HN