
My Reaction to React - ingve
https://pseudoconcurrentthought.wordpress.com/2016/01/26/my-reaction-to-react/
======
skewart
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 the most valuable thing about frameworks is that they are common
languages. They make it easier for developers to dive into a new code base and
quickly understand what's going on. It's not entirely about functionality. I
think this is partly why framework usage seems to be so trend and style
driven; everyone wants to be using what everyone else is using.

~~~
brightball
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 that the frameworks do so little on top of what the language
already offers that it's easy to create your own. Javascript and PHP are clear
cut cases for the latter since both languages are out of the box built for the
web. jQuery was the last real unification in the Javascript world.

I don't entirely care which framework becomes dominant as much as I just want
A framework to become dominant. React looks like it is gaining that momentum,
but you immediately see the problem play out when there's a thread about how
great React is followed by 100 "X is better because it doesn't handle Y the
way that React does" followed by another post about how "X is worse because of
the way it handles Y". There's something about the Javascript world that seems
ready to create new frameworks instead of contributing to existing ones.

I took a sales class years ago and the biggest takeaway from it was "People
buy pain relief". jQuery was dominant because it solved a huge pain point,
cross browser compatibility, in a way that made natural sense for people
working in the browser by using CSS references...AND it was built to run side
by side with any other JS library (Prototype, Mootools, etc) so you could
safely invest in learning it and know you'd be able to use it on any project
that came along. During a time when IE6 compatibility was a big deal this was
huge. During a time when a lot of people were trying to solve the problem and
you'd inevitably end up on a project that chose one of the other dozen
options, side by side compatibility was huge.

These were major points of pain relief that jQuery brought to the table and
that's how it won.

~~~
m0dc
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.

~~~
sotojuan
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.

~~~
m0dc
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/Redux/Webpack turns out to be.

~~~
brightball
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.

------
undo76
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 have a DOM API in the server capable of emiting
plain HTML).

Nevertheless, I agree that using React for such a trivial project would be too
much, but there are other alternative frameworks that would fit for this kind
of task (e.g. riot.js, Cycle.js, [Insert here your favourite one]).

My React version:

    
    
      const DATA = {    
        name: 'John Smith',
        imgURL: 'http://lorempixel.com/100/100/',
        hobbyList: ['coding', 'writing', 'skiing']
      }
    
      const App = ({ profileData }) => (
        <div>
          <Profile { ...profileData } />
          <Hobbies { ...profileData } />
        </div>
      );
    
      const Profile = ({ name, imgURL }) => (
        <div>              
          <h3>{name}</h3>
          <img src={imgURL} />
        </div>
      );    
    
      const Hobbies = ({ hobbyList }) => (
        <div>
          <h5>My hobbies:</h5>
          <ul>
            { hobbyList.map( (hobby, idx) => (
              <li key={ idx }>{ hobby }</li>
            ))}
          </ul>
        </div>
      );
    
      ReactDOM.render(<App profileData={DATA} />, document.getElementById('content'));

~~~
ohnomrbill
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?

~~~
undo76
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://jsbin.com/keyuqohusa/edit?html,js,output)

[https://babeljs.io/repl/#?experimental=false&evaluate=true&l...](https://babeljs.io/repl/#?experimental=false&evaluate=true&loose=false&spec=false&code=%20%20const%20DATA%20%3D%20%7B%20%20%20%20%0D%0A%20%20%20%20name%3A%20'John%20Smith'%2C%0D%0A%20%20%20%20imgURL%3A%20'http%3A%2F%2Florempixel.com%2F100%2F100%2F'%2C%0D%0A%20%20%20%20hobbyList%3A%20%5B'coding'%2C%20'writing'%2C%20'skiing'%5D%0D%0A%20%20%7D%0D%0A%0D%0A%20%20const%20App%20%3D%20\(%7B%20profileData%20%7D\)%20%3D%3E%20\(%0D%0A%20%20%20%20%3Cdiv%3E%0D%0A%20%20%20%20%20%20%3CProfile%20%7B%20...profileData%20%7D%20%2F%3E%0D%0A%20%20%20%20%20%20%3CHobbies%20%7B%20...profileData%20%7D%20%2F%3E%0D%0A%20%20%20%20%3C%2Fdiv%3E%0D%0A%20%20\)%3B%0D%0A%0D%0A%20%20const%20Profile%20%3D%20\(%7B%20name%2C%20imgURL%20%7D\)%20%3D%3E%20\(%0D%0A%20%20%20%20%3Cdiv%3E%20%20%20%20%20%20%20%20%20%20%20%20%20%20%0D%0A%20%20%20%20%20%20%3Ch3%3E%7Bname%7D%3C%2Fh3%3E%0D%0A%20%20%20%20%20%20%3Cimg%20src%3D%7BimgURL%7D%20%2F%3E%0D%0A%20%20%20%20%3C%2Fdiv%3E%0D%0A%20%20\)%3B%20%20%20%20%0D%0A%0D%0A%20%20const%20Hobbies%20%3D%20\(%7B%20hobbyList%20%7D\)%20%3D%3E%20\(%0D%0A%20%20%20%20%3Cdiv%3E%0D%0A%20%20%20%20%20%20%3Ch5%3EMy%20hobbies%3A%3C%2Fh5%3E%0D%0A%20%20%20%20%20%20%3Cul%3E%0D%0A%20%20%20%20%20%20%20%20%7B%20hobbyList.map\(%20\(hobby%2C%20idx\)%20%3D%3E%20\(%0D%0A%20%20%20%20%20%20%20%20%20%20%3Cli%20key%3D%7B%20idx%20%7D%3E%7B%20hobby%20%7D%3C%2Fli%3E%0D%0A%20%20%20%20%20%20%20%20\)\)%7D%0D%0A%20%20%20%20%20%20%3C%2Ful%3E%0D%0A%20%20%20%20%3C%2Fdiv%3E%0D%0A%20%20\)%3B)

~~~
true_religion
I think the issue people have with React is that a lot of tutorials assume you
are already using NPM/Babel.

If you're using a module importer already then adding React to your stack is
pretty easy. For example with JSPM:

$ jspm install --dev react react-dom $ npm install --save-dev babel-preset-
react

Then add 'react' to your .babelrc preset.

In your ES6 javascript file you can now use react via:

import React from 'react';

\----

That's it.

However, if you have none of that already set up... Then you'll naturally be
persuaded that now is the time to get a 'modern' javascript environment setup
and doing so can take time. It took me about 2 days of beating through
RequireJS --> Webpack --> JSPM before I settled on the latter.

Figuring all that was difficult, but looking back on it was extremely useful
to now have all my Javascript bundling done within JSPM rather than using some
Django bundler, and downloading raw JS files from the internet without evening
using Babel to help me write ES6/ES7.

------
iLoch
Okay I think the author is severely misinformed as to why we use React. I say
this because the very first thing he says is to use MVC architecture and then
goes on to write his own framework ( _from scratch???????_ )

...Why?

This solves none of the problems React was designed to solve and only makes
things more complicated by introducing new APIs only you know.

Yes, this approach with vanilla JS is great for small apps. What makes you
think this app won't grow?

I hardly see how this is a reaction to React other than to say "I didn't
really read into why people are using React or what it's trying to solve, but
I'm pretty sure I can solve this problem with my own framework I just whipped
up.

Sorry for the brash delivery.

~~~
adrianp
I'm not really fighting you on the merits of frameworks (which should be
obvious to everyone), but are you implying that implementing a design pattern
is equivalent to building a framework?

~~~
iLoch
Not at all but what is the end goal of this if we consider that the code base
will increase in size? You'd likely start adding more and more things to it to
make it easier to work with and eventually you've unintentionally rolled your
own framework.

React could also still be implemented as part of the author's view because
they haven't covered any of the problems with large cascading data updates. So
there's literally no argument against React in this post. It's basically just
a post about how to implement a design pattern in a language, React doesn't
even need to be mentioned. I might even call it click bait.

~~~
calahad
He's not trying to make an argument against React. I take him at his word
here, mostly because it was indeed helpful for me:

"If you want to use React, fine, I am not trying to convince anyone not to. I
just want to show that components in a JavaScript application are quite simple
to do and do not require any framework at all to do so."

There are a lot of less experienced web developers being steered towards react
that can gain a lot by understanding what is being laid out here, whereas I
think more advanced developers like yourself have so much assumed knowledge
that its hard for you to see past what from your perspective are glaring
differences/inadequacies in the approach he's taking in the article.

~~~
jasode
_> He's not trying to make an argument against React._

I disagree. He actually _is making an argument against React_ but disguising
it with a _passive-aggressive_ writing style. That said, it doesn't mean his
article is not helpful because like you said, it _did_ help you.

I interpreted the following paragraph as passive-aggressive:

 _" If you want to use React, fine, I am not trying to convince anyone not to.
I just want to show that components in a JavaScript application are quite
simple to do and do not require any framework at all to do so."_

It follows the very familiar template of X-is-overkill-so-let-me-enlighten-
you-young-grasshopper. Another example would be, "Hey, if you want to use a
bazooka to kill a house fly, don't let me stop you but I just want to point
out you can take a plain old rolled up newspaper and just swat at with a quick
motion of the arm."

That type of rhetorical construct has been common sport in technical
discussions for decades.[1]

Why interpret his paragraph like that? Look at his previous 2 paragraphs about
seeing another "react, angular, ember", etc and how it's just tiring. (In
other words, he's telegraphing to readers that he's intelligent enough not to
have to learn them or need them.)

Yes, he does show the underlying skeleton of a "view" by showing some
homegrown Javascript code but notice how he leaves out the concept of "DOM
diffing algorithm". The virtual DOM is one of the features that makes React
perform better with many components and changes.

Now if the author starts implementing more and more things that React does to
achieve feature parity, he will end up inventing his own
Pseudoconcurrentthought-framework. At that point, someone else will come along
and write " _the Pseudoconcurrentthought framework is not necessary. You can
do it with plain old Javascript_ " At the point, the cycle of critique will
have repeated itself.

[1]E.g. "Angular is overkill when you can just use JQuery"; "JQuery is
overkill when you can just use plain Javascript getelementbyid()"; "Using
Javascript on the web page form is overkill to compute sales tax since you can
just issue a POST and have the server send back another HTML page with the new
sales tax amount", and so on and so on.

~~~
calahad
I don't really think we disagree on that much here. I think the only place we
veer off is that I feel as though he's just trying to talk to his audience, vs
being passive-aggressive.

The intended reader, as I interpreted it, would be the someone that reads
Javascript Fatigue articles and goes "hell yeah". For this person the
abundance of frameworks probably does feel tiresome. The person for whom this
kind of advice would be patronizing doesn't seem to be who this article was
meant for (although now I see what you mean by the title being click-bait)

------
jasim
React is just a library. It is the ideas behind it that are important:

a) building web front-ends by dividing them into components which are first-
class citizens of the codebase, and can be composed, parameterized and reused,
just like pure functions. [1]

b) expressing the view as a pure function of state has replaced any need to
mutate the DOM manually and think about transitions ($.remove(), $.append()
etc.). We need virtual-dom and diffing to be able to pull this off
successfully, which makes this abstraction irreducible.

c) interspersing content-inside-code (JSX) is better than code-inside-content
(template languages like Angular). [2]

The recent 'React fatigue' is due to people trying to figure out how to best
manage state within this framework and causing a lot of noise in the process.
And that is perfectly fine, but if you are confused by it, just use vanilla
React and React's immutability helpers, keep all the state in the root node
and pass everything down as props {...this.props}, and then when you get a
hang of it, hop on to Redux. There is no 'one true way'; as long as your app
works and you can hold it in your head, everything is fine.

[1] - [http://www.jasimabasheer.com/posts/on-
react.html](http://www.jasimabasheer.com/posts/on-react.html) [2] -
[http://www.jasimabasheer.com/posts/evolution-of-view-
templat...](http://www.jasimabasheer.com/posts/evolution-of-view-
templating.html)

~~~
wanda

        There is no 'one true way';
        as long as your app works and 
        you can hold it in your 
        head, everything is fine.
    

With all due respect, this is the major criticism of adopting React, given
that it's still in active development and given that many who are looking at
using it have established apps using other patterns already.

~~~
jasim
React's API is fairly stable, and has been for a long time. Redux has almost
become the de-facto standard for new projects, but again, it is just a library
around a good idea: do all state transitions inside a pure function - get an
input, return a new output, and the entire view gets re-rendered with it.

You can use React's immutability helpers inside it, or or performance in large
state trees, use ImmutableJS that gives persistent immutable data-structures.
This comes at the cost of having to use its own methods like map and filter,
instead of normal JS everywhere.

But that is pretty much it. There are a few more other concerns that'll
necessitate the use of redux-thunk, (which at its core is a few lines long),
but you don't need to worry about any of this upfront. The thing with React is
that unless you make costly architectural decisions upfront, you can always
learn as you build, and figure out the right way to structure your project.
Once you've built a fairly large project, you'll form your own set of opinions
on which way you like to think about front-end code, and that'll inform you on
your next project.

There is a learning curve, but with React, you are always thinking about
fundamental things like encapsulation and message-passing than trying to learn
non-transferable knowledge about a particular framework's quirks and
conventions.

~~~
wanda
You don't need to sell it to me, I see the advantages--but precisely because I
understand those advantages, I actually intend to complete my next project
with Cycle.js [1].

[1]: [http://cycle.js.org](http://cycle.js.org)

~~~
jasim
Awesome! A lot of smart people have been saying good things about Cycle.JS,
but I unfortunately have been unable to wrap my head around it. The idea of
putting stream of user-generated events front and center appeals to the
puritan in me, but I find it more natural to think about the front-end
beginning with the rendered view, and events and their mutation (uni-
directional actions) later.

The Elm language is yet another area that gives the fear of missing out on the
'better than yesterday's abstraction'. But as long as I'm able to build great
software with the tools I know and patterns my brain is comfortable
manipulating, they can wait. This is the line of thinking that I mentioned in
the original post about no one true way.

------
vog
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 immediately and its return value is stored into
App.main, although it doesn't return anything, so App.main is declared as
"undefined".

So there are two layers around that code which serve no purpose at all. Why
not simplifying it? All you want is an App namespace and an event handler for
window / load:

    
    
        var App = {};
    
        window.addEventListener('load', function() {
            // ... initialization ...
        });
    

Or, if you want a "real" main function (i.e. an "App.main" that is actually a
function):

    
    
        var App = {
            main: function() {
                // ... initialization ...
            }
        };
        window.addEventListener('load', App.main)
    

If you put your <script> tags within <body>, right before </body>, you could
simplify this further to:

    
    
        var App = {
            main: function() {
                // ... initialization ...
            }
        };
        App.main();

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

------
jondubois
I've tried most of the major frontend JavaScript frameworks. My favourite one
is Google's Polymer framework - I like it specifically because it is very
lightweight, easy to setup, easy to integrate into existing projects and it's
ideal for building complex single-page apps.

The best thing about Polymer is that, unlike React, it works with W3C
standards instead of going off on a tangent and hacking the DOM entirely. It
extends current HTML5 standards instead of creating its own universe.

With Polymer, each component has its own mini-DOM which is actually a real DOM
- Not the virtual layer you get in React which keeps overwriting the real DOM.

Unlike Angular, Polymer gives you a lot of control when it comes to how data
flows throughout your app. Because of this, there are a few different
component-level configs that you need get your head around. For example, by
default in Polymer, data only flows downwards to child components, you have to
enable a special 'notify' attribute to allow data to flow upwards to parents
(this is different from Angular where data flows freely wherever there is a
placeholder for it in your DOM).

I think React has been getting way too much hype. Polymer, on the other hand,
is ridiculously under-hyped. Of those people I know who used both React and
Polymer, all of them preferred Polymer. I'd like to hear alternative opinions
from other people though.

~~~
gcommer
> 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 implementation detail; a means towards achieving the end goal of
a simpler program design via pure functions.

On a different but closely related note: Angular and Polymer both use template
systems which have to reinvent control structures (looping, filtering,
conditionals, ...) embedded into HTML via tag attributes (eg, `<li
repeat="{{todoItems}}">`). Contrast this with React (and especially
ClojureScript's Om or Reagent), where any such logic is implemented directly
using the languages normal mechanisms for it (map/filter, loops and if
statements, etc.). Using HTML template languages is realy just raising up HTML
and treating it as some special class of data, whereas React-style libraries
recognize that it's all just trees (AKA lists of lists), and programming
languages are already very good at building them up and manipulating them.
Programming languages are designed for manipulating data; HTML isn't.

~~~
marknutter
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).

~~~
EdwardMSmith
> 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 are free to use React in your
> WebComponents, or to use WebComponents in React, or both.

[https://facebook.github.io/react/docs/webcomponents.html](https://facebook.github.io/react/docs/webcomponents.html)

~~~
marknutter
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.

------
EGreg
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 something in the state changes (since storing state in the DOM and
reading it from there is bad)

Until you want to load javascript files on demand to construct and manage
components instead of loading everything in one huge js file up front for a
big website

Until you want to have a unified CSS convention so you can style all these
components

That's when you need a well tested framework.

~~~
eterm
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 to use for the view
rendering.

~~~
jabagawee
I think GP is making an argument _for_ React by calling it the framework,
whereas the OP is the "raw" component.

------
codemusings
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 concept and syntax is super easy to understand and perfect for
modularizing the components of your app. The real problem IMHO is the tool
chain. That's what drives developers unfamiliar with the ecosystem away. And
of course the fact that it seems to change all the time. The first time I
looked at React they rolled their own transpiler. Now Babel is the recommended
way to go.

According to the tutorial page you should either use browserify or webpack.
You don't have to - but without them stuff gets messy pretty quick. Of course
if you pick one of these up you also have to learn how to use them and you
will want plugin A, B and C to get to your simple Hello, World React App in
the first place.

So yeah. That's why it's so easy to step away from that thinking why don't I
just simply roll my own framework.

~~~
marknutter
> You don't have to - but without them stuff gets messy pretty quick.

Which is the same as saying "you have to".

Can't we just accept that developing with React is no longer as simple as just
stitching some views together? It's as if the collective React community is
very insecure about the fact that writing web applications is gonna be hard
and complicated no matter how shiny your tools are.

Sure, you don't have to use JSX, but without it stuff gets messy pretty quick.

And you don't _have_ to use flux/redux, but without it stuff gets messy pretty
quick.

Also, you don't _have to use_ ReactRouter, but without it stuff gets messy
pretty quick.

You don't have to use....

~~~
true_religion
Are there any other options out there part from Flux/Redux patterns?

I've been looking into using React (well for the past 4 days of solid
research), but I'm finding that pure reducers are a mental-mismatch for me.

I'd like something that helps me manage state, and perhaps constraints its
flow (like Reach does with unidirecitonal renddering), but not something that
tries to abstract state away completely.

~~~
marknutter
Relay and Falcor both remove the need for Flux, I believe, but those solutions
involve the backend I believe.

~~~
true_religion
Yes. That's true. I've found out about GraphQL lately, which seems to be with
a real possibility for me to use since I have a python backend and Graphene
will help with creating an api for GraphQL to consume.

------
pluma
Great idea. Spend 10 minutes writing your framework that gets you 80% of the
way. Can't wait for the next decade worth of follow-ups that attempt to patch
up the remaining 20%.

Frameworks don't exist just because someone wanted to write a framework. They
exist because they solve problems. And they solve problems you likely forgot
to think about so you don't have to. Like not losing cursor positions when re-
rendering, or not breaking the DOM when trying to re-use input elements or
manipulate tables.

React is actually great in this regard: it doesn't try to solve everything, it
just focusses on one problem (two if you include React-DOM/Native) and solves
it well. Redux is another great example (the entire API can be implemented in
less than 100 lines).

The reason libraries and frameworks like React and Backbone and Angular and
Ember exist is that direct DOM manipulation doesn't scale. It's on a lower
level of abstraction than the application you're trying to build. And the
advantage of React (and similar libraries like Mercury) is that it just lets
you build components (i.e. partial DOM trees) -- it's trivial to swap the
component library out in the future without having to touch any of the
application logic around it.

------
tobr
There are some subtle bugs in this code. For example `new
App.View.Hobbies(model.hobbyList)` is not going to do what you're expecting
when the `Hobbies` function is explicitly returning an object.

I like the premise of the post, but I did not find the end result very
convincing.

------
mrborgen
I wrote the original article this one is based upon.

I very much enjoyed reading this one. Though I always find it more beginner
friendly to start off with a framework rather than going vanilla. That goes
for almost all subjects in tech. Then you can dive deeper into the material
once you have a basic understanding.

Here is a link to the original article: [https://medium.com/learning-new-
stuff/building-your-first-re...](https://medium.com/learning-new-
stuff/building-your-first-react-js-app-d53b0c98dc#.p890hj6dp)

------
Wintamute
Ugh. Aside from trivially simple projects trying to go framework-less just
means you end up writing your own buggy unmaintainable franken-framework.

And look at those code examples in the article. Such a simple app, and yet
already a confusing mass of IIFEs, module patterns and whatnot.

Framework churn is indeed tiring but throwing out what I would consider
basic/essential tools of frontend (module bundling for starters) doesn't make
sense.

Besides, React is a library for efficiently rendering large DOM trees ... so
I'm not sure what point he's making by re-implementing an MVC framework?!

------
d0m
It'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, jsx is a big part of what I like about React.
Basically, being able to add html from javascript instead of using all kind of
hacks.

~~~
marknutter
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.

~~~
Kwastie
> manually updating the DOM is as optimized as you can possibly be.

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.

~~~
d0m
On big project, it becomes impossible to optimize the DOM interaction
yourself, so you start to do very inefficient operations for sanity's sake.
React on the other hand abstract that for you.

I had a project with Angular where one page was really slow. I re-implemented
it with backbone / jquery, it was a bit faster but really hard to read and
maintain. With React, the code was simpler AND faster, which I was really
surprised about.

------
bshimmin
Those screenshots of code are kind of a challenge to read.

~~~
Imagenuity
The images are downsized. I had to open the images in a new tab and remove the
resizing parameters from the end of the URL to read it. Makes me wonder why
the actual code wasn't just put in <code> tags.

------
mclovinit
Only time I ever attempted something remotely similar was during a PoC using a
specialized client device (think RF handheld) that needed to render content
quickly in a custom browser. Loading tons of dependencies was my concern. So
writing custom components with pure JS was the approach BUT those components
were not for rendering views and instead for initializing behavior with regard
to keypress behavior per view. Attempting to render content was still done
with a server side templating framework (Thymeleaf). This was eventually
abandoned because development and testing cross browser (on a PC) was buggy.

As many have already stated, a tutorial like this is interesting for hobby
projects, but I would not adopt this approach in production. Libraries and
frameworks have a lot of energy invested in them and should be considered
early.

------
fiatjaf
You didn't get the rerender-everything-everytime breakthrough, the only React
feature that makes it worth using.

------
FlyingSnake
Thank you for writing this article.

I'm an iOS/Backend developer looking to do some lightweight front-end
programming, and whenever I look at the JS landscape I shudder.

Nearly every suggestion from JS developers is on the line "Have you tried
"React/Angular/Ember/ObscureJS?". The Grunt/Gulp/Yeoman/Bower/Npm/Batman.js
etc toolchain makes me question my sanity. Is it so difficult to just use
Plain Old JavaScript™ and be done with it?

Sorry for the rant, I wish novice JS developers like us had a better way to
get initiated in the JS land.

~~~
pluma
Just pick one and be done with it. It's not JS that is holding you down, it's
Analysis Paralysis. There are too many choices and you lack the knowledge to
make an educated decision.

Pick one. Yes, you will pick the wrong one. That's okay. It will always turn
out to be the wrong one eventually (if only because your requirements will
change).

Don't obsess with what's hot. Figure out _why_ it's hot, and what makes it
different than the thing that was hot the previous week. If there's no
sufficiently discernible difference you can probably afford not to pay
attention to it until it pops up again.

The frontend ecosystem is in constant flux because the frontend platform is in
constant flux. HTML has stopped using version numbers. JS itself has
transitioned to yearly releases. CSS has fragmented into dozens of separately
versioned specs.

That's just the way it is.

------
ilovefood
The first Javascript post I enjoyed reading, this looks simple for humans like
me. It is more readable and more understandable. You should write more
Javascript tutorials and show that things don't have to suck. This is how I
should have started learning Javascript. I bet the time lost in not using a
framework is gained with a better understanding of what is happening and also
with an absence of imposed conventions. Just my 2 cents

~~~
ry_ry
Yes and no.

Homerolled solutions such as this are free of another developers assumptions,
but tend to scale poorly. Generally they need to be modified as new
requirements are created, or unforeseen circumstances arise.

Over time you end up putting together more and more logic in and the illogical
conclusion is that you end up building your own heavily bespoke version of
React/Angular/jQuery/whatever, before realising you actually need to go back
and start again.

There is absolutely nothing wrong with writing your own libs (it's educational
and character building!) but to chuck json through a constructor is trivial.
Sure - this code renders views in a simple and relatively inefficient way, but
drawing boxes is only part of what React is doing.

~~~
ilovefood
You are absolutely right, but I do believe people should start learning the
alphabet before trying to read a book.

React looks fine to me and at my daily job our frontend devs do some amazing
job. I just wanted to learn and all I seem to find is how to learn javascript
through React, and not React through Javascript.

I do agree this is a home made solution and would not work nicely with lots of
devs involved. I'm talking about learning though, and we devs are usually bad
teachers when we don't know how to boil it down to the essentials.

How many people do you know that only use React to draw boxes and not for the
advantages it brings?

~~~
yazaddaruvala
I'd argue that you're analogy is broken.

Yes, frameworks are built from the basics and novels are built from an
alphabet.

However, Frameworks reduce relative complexity, increasing their audience.
Novels actually have an increased relative complexity reducing their audience.

While, its hard to find good analogies outside software development, it might
be more correct to say: if javascript is the alphabet, then React is a picture
book.

Picture books lowering the relative complexity, allow literate and illiterate
people alike to mostly understand a story. Here its easier to see that the
Framework (pictures) help novices (the illiterate, i.e. children), as soon as
possible, to become independent and productive (understand the story). There
is also the added benefit that exposure to both words and pictures
simultaneously allows for an understanding of the alphabet and grammar, i.e.
helps the learning process.

------
halayli
It's not like none of us went down this path until one day the app becomes
unmaintainable and incoherent, with broken bindings and inconsistent states.

------
TheAceOfHearts
I don't know what point you're trying to make. Sure, if you don't really need
any of these tools and libraries... Don't use them?

If you're gonna be building a sophisticated application, it's going to have to
deal with a TON of challenges, and there's not really any way around em. Why
not learn some of the more robust tooling and make life easier for yourself?

------
eddd
I am no a JavaScript expert - I started playing with frontend (jQuery doesn't
count) only recently. The only problem I have with your approach is that the
model might mutate. For small projects it is ok - but for larger ones
overriding state from many places generates pesky race conditions that are
source of all evil. I am not advocating for react as well - to me it is just a
view layer. Combining it with redux, flux or any other library concept makes
everything complex. And add javascript build tools on the top of that (good
javascript sucks). As a mostly "backend" developer (python, erlang, elixir) I
really started to like ELM ([http://elm-lang.org/docs#complete-
guide](http://elm-lang.org/docs#complete-guide)) which solves all the problems
as a language.

1\. Language forces you to model-view-controller style

2\. Language makes the model immutable

3\. Language forces you to use correct types which saves a lot of trouble.

On the other hand, I a new to frontend - so I might be wrong.

~~~
lisivka
Just use database at client side (e.g. PouchDB), which will solve your
problems with concurrent modifications. Your Views will display data from DB.
Your Controllers will put data into DB. Your DB will be Model. As bonus,
PouchDB is able to replicate to CouchDB server without need to configure
CouchDB at all (except CORS), which is superb for quick prototyping of real
apps using clientside javascript only.

------
vog
All future frameworks should be designed to be easy to learn. This means
removing (or at least better isolation of) complexity, but also making a nicer
API and writing tutorials as an essential part of the framework. If there's
anything really cumbersome to explain in the tutorials, it should be
simplified.

So I recommend the author learn minimalistic libraries like Riot instead of
React. Those are really lightweight and very easy to grasp. However, even the
docs of Riot could still be improved. Despite its simplicity, I could have
learned it in half the time if it had a better tutorial.

Essentially, this means applying findings from UI design to framework API
design. Here, the user is a developer, but surprisingly many principles still
hold: Principle of least surprise, make similar things look similar, make
different things clearly different, and so on.

------
why-el
Has anyone wondered how similar in spirit React is to the way html and js were
originally meant to be written (with embedded callbacks, e.g. `<a href=bla
onClick='myfynction>`)? Isn't the `a` in some sense a React component with
explicit and local state changes, only missing a explicit render?
Theoretically one could build on top of this to make Angular/React style
custom components without the need to re-invent state management code.

Of course, I am missing many good features of React (due to my lack of
understanding, as I am not a front end developer), but at least conceptually
one could argue the original idea was there all along. Perhaps the real power
of React lies in the excellent diff algorithm they came up with. Any thoughts?

~~~
pluma
The power is that it behaves within the scopes of your JavaScript code.
"onclick" in HTML can only refer to the global scope. In React it's within the
scope the element is defined in.

But the more poignant observation about React is that the components aren't
actually anything like templates. You can think of React components as
descriptions of the structure of the DOM -- if the equivalent structures in
the DOM already exist[1], they are just "progressively enhanced" when you run
React on them. The only reason you would want to generate that HTML on the
server with React instead of writing that HTML yourself is that it avoids
unnecessary duplication.

[1]: currently React needs to add proprietary attributes to identify markup
generated by React but this will be made redundant in an upcoming version.

------
mrcwinn
Every (large, meant for production at scale) application needs a framework.
That doesn't mean it should be someone else's framework. And while there are
certainly "giants" on whose shoulders a developer can stand, in the JavaScript
ecosystem in particular, a lot of frameworks feature shockingly bad code or
untested patterns.

So, be careful, avoid magic, let your software express requirements, and then
choose a tool accordingly.

------
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.

------
karussell
Maybe completely off-topic: I've not yet looked really into React and I'm
still hesitating as I've seen this mixture of logic (JavaScript) and
presentation (HTML) before e.g. via JSP stuff. Or am I misunderstanding
something?

Why not create components that do still separate logic and view like Apache
Wicket does/did?

------
akrymski
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](https://github.com/techlayer/espresso.js)

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

------
gotofritz
How very naive.

------
intrasight
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?

------
moron4hire
My feeling on the subject of "framework churn" and "tool fatigue" in the JS
world is that it stems from the general self-deprecating nature of front-end
developers.

For years, if you did a lot of work in JS, you were constantly being told to
switch to a "real" language, that you "shouldn't reinvent the wheel", that you
weren't a "real" developer. I think, for a lot of people who got into
programming web sites through non-CS paths, that perception that JS wasn't
"really programming" was helpful at first, to make it seem more accessible,
but it is now hurting people. I've been working in JS (and other languages)
for 20 years now. I've heard it all. First, JS wasn't C. Then, it wasn't Java.
Then, it wasn't C#, or PHP. It was "too high level". It "couldn't perform".
Nowadays, people want to call it "too low level", whatever that means. I don't
think it's a great language, no, but the web as a platform has a lot of
advantages that are extremely attractive to small teams (which I think are the
vast majority of teams).

Beginners don't understand what is going on with their code. It's a mystery
why it works at all. If you can trust yourself to build anything, then it
doesn't really matter what framework you choose, or really if you even choose
a framework. You know you can never truly get stuck in a corner, because you
can always write another program to get yourself out of it in some way. But
beginners--and not-quite-beginners in JS who have been indoctrinated into
thinking they are perpetual beginners--lack that confidence.

Because of this, such people are fearful of striking their own path. They want
to swim with the school--safety in numbers. But there isn't any one school, so
when multiple frameworks are out, and you never know which your Snr. Dev is
going to choose at your next job (and you're constantly fearful that your lack
of skill will be recognized and you'll be booted), you start to worry about
ever being able to keep up.

And it might seem like a paradox--why would any such people start a new
framework project when they lack basic confidence in their own skills?--but I
think this is _why_ there _are_ so many frameworks that have risen to the
level of awareness in the popular conscience. There are a few people who have
crossed the line into confidence, but they don't yet know that their surface
syntax doesn't really make them any different than the others, and then the
mass of unconfident people amplify the importance of the project beyond what
it maybe should deserve, because of the worry that they might be missing out
on some important information that will come up on a job interview in the near
future. It used to be you didn't need to have intimate knowledge of your
future employer's framework before you walked in the door, they just expected
that you had applicable experience and would be able to learn it as you went.

If you're starting a project now, you don't need a JS framework. I see a lot
of people thinking way too far ahead. For the vast majority of projects, they
aren't Facebook. You don't need a framework to make a simple activity feed. I
see very small code bases worried about continuous integration and automated
build servers. Nobody can just play with code anymore. Everyone is thinking
about "scalability" and "hiring" and "doing a startup". That's ostensibly why
_we_ are _here_ on HN, but HN--contrary to popular belief--is not the be-all,
end-all of the internet. I think this is also a contributing factor to tool
fatigue. People are so afraid of "reinventing the wheel" that they aren't
willing to just play around with code. They can't tolerate it for themselves
and they can't tolerate it in others (because they fear it will become yet
another thing they think they will have to learn). But playing and making your
own framework is how you learn to evaluate the plethora of frameworks and
throw away 90% of them for being trivially easy to implement on your own.

So what is the solution? A lot of people are doubling-down on the "don't
reinvent the wheel" trope. I think that's stupidly close-minded and will lead
to such people getting left behind in the coming Singularity. Even if the
literal "singularity" never happens, the pace of technological development is
not going to slow down just because you're uncomfortable with it. The only
surviving strategy is to learn how to cope with the rapid change of the
market. And you do that by learning the core concepts to the point that you
are completely capable of "reinventing the wheel" whenever you damn well
please.

------
SeeThruHead
Article totally misses the point of react...

