Components are easy. Just write a function... Until you want to automatically unregister event handlers when the component is removed Until you want to compose them and select child and parent components without traversing the DOM Until you want to pass options to the components in various ways, and have default values for them Until you want to store component state and re-render part of the component whenever somet…
Are you making an argument against react or an argument against writing react in a pure functional style? Because unless I'm very much mistaken: ComponentWillUnmount Props Props state for the first few complaints. React is just the view layer, arguing against react because "you need a framework" is like arguing that no one should write their own applications without a framework. It is a separate discussion than what…
My Reaction to React
111–120 of 147 posts
Re: My Reaction to React
#112Earlier quoted context omitted.
semantics? php wasnt written to be a programming language. it was words written with an explicit purpose.
No, read the history of PHP. It started out as just a hack for a school assignment. It accumulated hacks to do different things over time. It didn't ever have an explicit design effort until way long after it had been adopted around the world and they decided they might try to make up for some of it's cruft.
Re: My Reaction to React
#113Earlier quoted context omitted.
> it works with W3C standards instead of going off on a tangent and hacking the DOM entirely While this sounds good on the surface (standards!) I think it is missing part the bigger picture. React, and more generally, the whole ecosystem of related libraries/frameworks it has spawned, is most importantly defined by a move to describing components using pure functions. The virtual DOM diffing is, in my view, just an i…
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).
Re: My Reaction to React
#114Earlier quoted context omitted.
No, read the history of PHP. It started out as just a hack for a school assignment. It accumulated hacks to do different things over time. It didn't ever have an explicit design effort until way long after it had been adopted around the world and they decided they might try to make up for some of it's cruft.
ok so it is semantics. replace design with written.
Re: My Reaction to React
#115I 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…
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. That's how we progress, by challenging the status quo.
Apologies for the incoherent rant, I hope the point gets across anyway.
Re: My Reaction to React
#116Specific 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…
Re: My Reaction to React
#117Re: My Reaction to React
#118It's missing the most important React feature (Virtual-DOM diff.). More specifically, he's manually adding and keeping track of all DOM elements. Once elements need to be updated, he would need to go back in the DOM and manually add/remove/change elements.. welcome back to the jquery messy world. Whereas with React, the render function doesn't change because it gets smartly rerendered. Also, as far as I'm concerned,…
Let's be clear, manually updating the DOM is as optimized as you can possibly be. Virtual-DOM isn't somehow magically more efficient than direct, imperative manipulation of the DOM. Virtual-DOM diffing was created to try to emulate the effect of refreshing the entire page every time state changes like we did with stateless web applications but do it in a relatively performant way.
Optimized in the sense that it uses less memory and cpu. But the code isn't optimized for humans to reason about (not to mention changing it.)
React was never about performance, it's about maintainability, readability and reasonability.
For me readable and maintainable code is (almost always) more important than fast code.
Re: My Reaction to React
#119Earlier quoted context omitted.
> 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 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…
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. But otherwise I definitely agree the "use whats out there" gets way out of hand -- but for me this is mostly for relatively straight forward stuff.
Re: My Reaction to React
#120Am 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?
The only essentials you need are React itself and, because the example uses ES2015 and JSX code, Babel to transpile the script into more portable JS that will run in today’s browsers.
In practice you’d probably also be using Node/NPM to manage packages and a tool like Browserify or Webpack to resolve dependencies. I’ll use Browserify.
So, here is a complete working example. For the script, we’ll use undo76’s original code verbatim, and add imports of the React modules at the start of the file. Let’s call this index.src.js:
import React from "react";
import ReactDOM from "react-dom";
const DATA = {
name: 'John Smith',
imgURL: 'http://lorempixel.com/100/100/',
hobbyList: ['coding', 'writing', 'skiing']
}
const App = ({ profileData }) => (
);
const Profile = ({ name, imgURL }) => (
{name}
);
const Hobbies = ({ hobbyList }) => (
My hobbies:
{ hobbyList.map( (hobby, idx) => (
{ hobby }
))}
);
ReactDOM.render(, document.getElementById('content'));
As usual, we need an HTML file to load that script, though it doesn’t need to do much else except provide a with an ID where we’ll put the content that React renders. Otherwise just use your preferred boilerplate. Let’s call this index.html:
React test
Finally, we need the tools and React packages: npm init
npm install --save react react-dom
npm install --save-dev browserify babelify babel-preset-es2015 babel-preset-react
Now we can run Browserify to generate our output JS file (adjust the / to \ if you’re running on Windows): node_modules/.bin/browserify index.src.js -o index.js -t [ babelify --presets [ es2015 react ] ]
That will produce index.js, which is just the code from undo76 linked with React and then transpiled to a more portable level of JS that today’s browsers can cope with. (Incidentally, this is literally the first example on the Babelify documentation page, which gives you an idea of how routine it is once you’re familiar with these tools.)Now load index.html in your browser of choice and enjoy. :-)