Live data from Hacker News

My Reaction to React

pseudoconcurrentthought.wordpress.com

91–100 of 147 posts

Re: My Reaction to React

#91
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?

[deleted]

Re: My Reaction to React

#92

I won't make an argument for Angular or Flux/Redux because those are very opiniated frameworks that might be overkill or simply not at all how you want to go about your app's architecture. But React is about the view. You can't possibly be convinced that manually traversing the dom is just as easy and expressive as using JSX. Even in the simplest of interactive (as in you need Javascript) components or pages. React's…

One thing that helps me overcome template/boilerplate paralysis is when there are a few sentences for each of the submodules that explain what they do, how they fit into the larger picture, and why they were chosen over similar alternatives.

Re: My Reaction to React

#93
What bothers me about React is that there's too much magic going on under the hood, I like minimal libraries that I can easily reason about. jQuery isn't small but is really simple. Backbone too - you could just read the source to instantly answer any questions. Angular & React remind me of RoR - sacrificing simplicity in favour of "magic" for a few made-up use cases. Being forced to do things the framework's way (embedding HTML in your code, always having to diff the DOM, etc) to adhere to framework's principles sometimes becomes a hindrance

I've ended up doing the same - writing yet another super minimal framework: https://github.com/techlayer/espresso.js

It borrows lots of concepts from React, but is faster & more memory efficient in under 500 LOCs.

Re: My Reaction to React

#94
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 obvious or you are just "doing it for fun/knowledge/etc", find a well-adopted framework, with good documentation and get to work.

Re: My Reaction to React

#95
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?

This article was my first exposure to React, and it goes through the basics of building a very simple "list of people" using nothing more than a single HTML file. It doesn't even use JSX, instead showing you how to build the raw JS that the JSX would compile to. I found it to be a great introduction without a lot of overhead to learn.

http://jamesknelson.com/learn-raw-react-no-jsx-flux-es6-webp...

Re: My Reaction to React

#97
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 clearly not the work of the troll.

"He's trolling" has recently become the tech community's version of Salem's "She's a witch."

Re: My Reaction to React

#98
post #77

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…

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.

Re: My Reaction to React

#99
post #69

Earlier quoted context omitted.

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.

semantics? php wasnt written to be a programming language. it was words written with an explicit purpose.

Re: My Reaction to React

#100
Having built many enterprise web apps over the years with the built-in MVC framework, I continue to be baffled as to why developers build frameworks instead of building applications. Is there an alternate universe that I'm not aware of where you can make more money building frameworks?
Post reply on HN