
React.js Introduction for People Who Know Just Enough JQuery - chibicode
http://reactfordesigners.com/labs/reactjs-introduction-for-people-who-know-just-enough-jquery-to-get-by/
======
michaelbuddy
I haven't gone through this page yet, but thank you for at least the attempt
at reaching somebody in my state of affairs. Front End work is very hard. The
front end design & what I would call the back-end front-end disciplines are
supposed to meld together according to job postings and over-zealous
recruiters, but it's a good deal more complex than I have been willing to put
up with, mostly because of the materials to get started and the unintuitive
tools that people who know what they are doing swear by.

Imagine being solid at design, pushing pixels, using HTML, CSS. Then suddenly
these program frameworks which are created by back-end programmers not visual
designers appear and the ramp up for the average technical person is immense.
For me it's been enough to turn me off them all together and make it a talking
point that "my javascript skills fall off at X,Y or Z" so recruiters and
employers know that despite being able to do a lot, I can't suddenly become
everything UI and everything back end just because the title of anything
"front end" is so versatile.

~~~
applecore
What do you mean? This:

    
    
        var createItem = function(itemText) {
          return (
            <li>{itemText}</li>
          );
        };
        return (
          <ul>{this.props.items.map(createItem)}</ul>
        );
    

...is clearly so much more logical than:

    
    
        <ul><li>{{item}}</li></ul>
    

Source: [https://www.airpair.com/angularjs/posts/angular-vs-react-
the...](https://www.airpair.com/angularjs/posts/angular-vs-react-the-tie-
breaker#1-9-templating)

~~~
oinksoft
That named helper function isn't necessary, so this might be more appropriate:

    
    
      return <ul>
        {this.props.items.map(item => <li>{item}</li>)}
      </ul>;
    

vs. the Angular version:

    
    
      <ul ng-repeat="item in items">
        <li>{{ item }}</li>
      </ul>
    

The Angular template is more readable at the expense of ngRepeat's complexity.
Neither example includes Component/directive boilerplate. The directive
boilerplate is generally worse, because it requires a separate template file
or an ugly template string, knowledge of the directives API itself which is
baroque in the extreme, and $scope-wrestling (whereas JSX' scope is the same
as JS').

In my opinion reuse of the React component is more straightforward, you
explicitly import/require it while in Angular you specify its providing module
as an angular.module dependency, which has implications for config block
ordering.

~~~
btown
I used to struggle to answer this when talking to Angular folks about React.
Then I came across a situation where I needed to recursively build a DOM tree
based on complicated calculations on a per-node basis and also calculated
values at the top level. If I'd been doing it with ng-repeat, the logic would
be split confusingly (and unnecessarily) between the template and the
controller, and I'd need to pass down any information from the top-level
ancestor manually.

In React, I just create a renderNode method that's called by render at the top
level, and renderNode on non-terminal nodes returns <div>{children}</div>
where children is a map whose mapping function returns this.renderNode. The
entire algorithm is grokkable at a single glance, and there's no need to
create Directives to add any fancy features or special cases in the future. No
need to read pages of documentation about ng-repeat and its intricacies; it's
all just Javascript.

Yes, Angular "just works." But React "just works" the first time you try it.

------
vezzy-fnord
Speaking as someone not intimately involved in the web development community,
React looks decent but absolutely not worthy of the obscene amounts of hype it
received... unless what web devs had before was really that horrible, because
that's the impression I got. Though from what I can tell, jQuery and React are
somewhat orthogonal tools, as I have used the former and it goes beyond
rendering views.

What I cannot figure out is all the harping on about "functional style". The
React examples all felt more Smalltalk-ish to me than anything else (I suppose
unsurprising given JavaScript's vague influences from Self). The use of
closures doesn't really change the conceptual patterns much. Is it because the
tutorial can only cover so much ground, or is it that since some of the
primary buzz around FP was the management of mutable state, to the point that
people now instinctively associate the idea with FP?

~~~
xixixao
Before React: to make a transition, let's change this, this and then that,
mutating state on every step. After React: have one pure function, which takes
as input the current state and produces the desired output.

This is the main shift. It's very similar to how imperative programming is
done in Java vs Haskell.

~~~
shostack
Can you dumb this down slightly for an "early" developer with a real world
example by any chance?

I'm not grokking the significance of why changing everything and having
mutations is bad.

~~~
orthoganol
It's just nicer to use if you have complex UI. OP's response was poor IMO,
just because something follows some abstract principles doesn't necessarily
give it value for us. I'll give you examples of things I've worked on where
React made sense & where it didn't:

-E.g. use React (or Backbone, Angular, etc.): A real-time document editor, with many interacting components, with lots of real time updating of the UI. Definitely needed a framework like that, and it was great.

-E.g. don't use React, because in these cases it's a total Rube Goldberg machine (extra steps to achieve the exact same outcome): Basic web app with some ajax submissions, adding results to DOM type of stuff. Maybe small html fragments cloned, inserted by jQuery. No extra fancy client interactivity.

^If people claim you should use React for the latter (undoubtedly some will),
they are very likely just people who follow trends to follow trends, or maybe
don't have a ton of web experience and it's one of the few things they've
learned and are sticking to. It's just so unnecessary (not to mention 100kb+
of overhead, & in my experience comes out to about x3 the amount of code). But
yeah, absolutely use React if it's anything like the first use case.

~~~
xixixao
1) React does not make simple apps overly complex. It might feel like more
work if you are more used to jQuery. If you are used to React instead, it
really won't have a huge negative impact on a small app. 2) React will scale.
It will be a much better vehicle for future development (as you admit, it is
more suited for more complex cases than jQuery).

I was not making a judgement on the value of the approach, although I
personally believe that this paradigm shift has a huge positive impact and is
applicable in lots of cases. If I can choose between lots of computation
intertwined with state mutation and a declarative approach where the mutation
happens on the smallest scale, up the call stack, I will always choose the
latter (of course, unless you have to mutate to gain performance).

~~~
orthoganol
I didn't say it's more complex, I just said more steps.

Yes, if app is planning on being more complex, sure use Angular or Backbone or
Ember or React. Otherwise, don't. Your pet projects sure, use it; if my team
is billing clients, I've learned from experience, you're screwing them if
you're not just using basic jQuery or even raw JavaScript which is a lot
better to work with these days. If your reasons are only rooted in your
abstract preference of design ideals w/o looking pragmatically at the
situations, you're likely doubly screwing them.

Fyi this "paradigm shift" is like 8 years old, React is not disruptive, it's
just another variation.

------
dahjelle
Shameless plug: I wrote my own React introduction—geared more for people that
know some JS and HTML, but not necessarily any other JS libraries. More
specifically, it very gradually builds up from rendering a single JSX tag to
enough components, state, and props to build React's to-do example. I found
React has an unusually gradual learning curve—you can really build up concepts
bit-by-bit.

EDIT: As per usual, I forgot the link:
[https://github.com/dahjelle/Programming-
Worksheets/blob/mast...](https://github.com/dahjelle/Programming-
Worksheets/blob/master/React.js/IntroductoryReact.markdown)

~~~
thirdtruck
Thanks. I was very much in need of this, especially with so many companies
expecting React expertise of new hires these days.

~~~
dahjelle
Glad to hear it! Very open to contributions/suggestions!

------
philliphaydon
As someone who knows Angular and Knockout. I found this great. Because react
is a different way of thinking IMO that most tutorials I read were not easy to
get up and running so I just threw in the towel and forgot about react. Most
people make too many assumptions on the skill level of the reader (myself
included when I blog) and it can be frustrating.

Thanks.

~~~
WorldWideWayne
Knockout.js is my favorite because it doesn't make me hack my HTML documents
into pieces if I don't want to, but if I want to, it lets me make web
components that work all the way back to IE6.

I also like that it doesn't require anything beyond normal HTML to make
templates and it doesn't require learning some huge framework just to bind a
simple data-set into the page. You can also read through the entire code-base
in an afternoon.

~~~
woah
I worked on a project with around 20 developers using knockout (with two lead
developers essentially writing their own framework as we went) and it was a
ridiculous mess. I think it can be a good tool for prototyping, but it is
horrible on a large app. You're always changing some observable and having
something far far away break completely. React with immutable.js is much
better because you really can focus on one component at a time in complete
isolation.

~~~
gedy
Knockout on it's own is just data-binding, we ended up using this as the SPA
framework around Knockout: [http://durandaljs.com/](http://durandaljs.com/)

------
ifdefdebug
Maybe slightly off-topic, but the tutorial page adds entries to my (Firefox)
back button as I scroll down. So when I tried to "back" to HN, nothing
happened. Second, third back, nothing happened. Opening the back list, a dozen
or so entries and they all do nothing.

I think this kind of design should really be avoided, it breaks my user
experience.

~~~
bbarn
Yeah, I'm really getting tired of this "You just changed pages and didn't know
it" pattern I'm seeing more and more. I'm not sure why people want to have
this single page app at all costs, but if you want the single page app, than a
single click of "back" should work.

~~~
BinaryIdiot
I think there is value in doing single page apps but mostly for web
applications not really for just a website. Still I completely agree that
breaking the back button needs to be avoided.

~~~
azernik
I think a more useful distinction is - mess with back-button history if and
only if the user perceives a page transition regardless of if the location bar
changed it there was a page load.

------
zamalek
Consumable content aside, I absolutely _love_ the format of the tutorial. It's
_significantly_ more pleasant to dig into compared to what seems to be the
more common tutorial format (e.g. [1]).

Good work.

[1]: [https://tour.golang.org/welcome/1](https://tour.golang.org/welcome/1)

~~~
chibicode
Thank you so much! :) I also found that a blog format is much easier to
consume than a REPL/in-browser editor based one.

~~~
DanSmooth
It is, but the tutorial could have made good use of pagination or anchors, so
one could bookmark where one has left off.

Also: What's the deal with "the cow above"?

~~~
krat0sprakhar
I think thats a joke on the cow printed on the ORielly book (also about React)

------
Omnipresent
Is React meant to replace Ember/Angular type of frameworks? Can React also
connect with backend APIs to fetch JSON and present them on the frontend? I've
been waiting to nosedive into Angular2 (when its out), is React a better
alternative to get started with?

~~~
applecore
Yes, it's pretty much unnecessary to include React and a framework like
Angular, Ember, or Knockout in the same project. And of course React works
well with REST and GraphQL APIs for communicating with a backend. React is
definitely a better alternative to a heavyweight framework like Angular for
new projects.

~~~
scoot
As a relative newcomer jo JS frontend development, is there a canonical JS
REST client library that works well with React / Flux, or do I have to write
that myself?

~~~
woah
Fetch is really easy to use, and is native in modern browsers. There are
several polyfills as well. It eliminates the need for any libraries.

~~~
pvg
Fetch looks interesting but as far as I can tell, it's an in-progress standard
with no support on any version of Safari or IE or any mobile browser
whatsoever. Seems like it has a bit to go before it being 'native in modern
browsers'

~~~
callum85
You can polyfill it in those browsers. Just use polyfill.io, or if you prefer,
manually feature-detect it and if necessary load Github's fetch polyfill,
which is good:
[https://github.com/github/fetch](https://github.com/github/fetch)

------
hit8run
Sorry but nowadays I feel that jQuery is like php for the frontend: people get
results fast but the average code quality is so shitty. Why on earth is jQuery
used for things that normal js can do instantly? There are so many libs out
there based on jQuery even though this dependency is absolutely unnecessary. I
might sound arrogant but people should get an understanding for JavaScript and
learn how to use it before stacking layers of abstraction. Ajax with normal JS
for example is not so hard. One doesn't need all the fancy
angular/jQuery/whatsoever helpers. If one knows the basics it's okay to use
some convenience stuff from time to time but I feel that so many low quality
devs are solely relying on their precious xxx kb libs just to display a simple
hello world.

~~~
digitalsushi
I have a friend with a web publishing business. She uses guess and check with
text edit copy/paste to build websites for clients. I've shown her the console
log countless times and she always rolls her eyes when I extoll its value.

She makes 50% more than me, has cash in the bank, and loves her life.

All I have is picking on her javascript. And I'm not even really any good at
it.

I think there's no reason to be correct when your goal is to buy food and pay
rent.

~~~
eastbayjake
No offense, but what do you do where a guess-and-check person makes 50% more
than you? Is she just hustling for clients who have no idea what they're doing
re: web design and using marginal technical knowledge to make pages for them?

------
paaaaaaaaaa
I have looked at react.js a couple times after reading more and more buzz
about how fantastic it is. However I'm instantly turned off of switching to it
when I read that HTML (which isn't HTML and is actually something called JSX)
goes in your js files.

With angular I can keep all my HTML in my HTML files. Is this normal or am I
completely missing something?

~~~
andybak
Ask yourself why that bothers you and boil down your objections to a practical
point. You can then evaluate whether there is a real cost and whether it's
outweighed by other things.

A lot of these issues turn out to be things we learnt were bad ages ago and
have forgotten why. The original context you learnt in might be sufficiently
different or other factors might mitigate the underlying issue.

In the case of JSX - we were all told that to keep css, js and html separate -
that inlines js and styles are bad. These things are all partially true but in
a react.js project your components are usually tiny and there is always an
inescapable dependence between js and html. It is therefore very different
from when we used to see long html documents littered with onclick.

~~~
marknutter
Except that there _are_ use cases where you want to use boilerplate HTML in
more than one component (i.e. bootstrap). Also, I've never quite understood
the argument that everything that goes into defining a component should live
in one file. By that logic we should be putting our data stores in the
component, any translations required to internationalize the component, the
database queries - heck - why not put the tests in the component while your at
it.

The real reason we keep "technologies" separate is so that we understand what
realm we're working at any given moment. Furthermore, we can distribute
responsibilities across multiple team members focused on different
disciplines. Facebook has the kind of clout internally to force their
designers to use JSX and inline styles, but many organizations do not have
that kind of alignment.

~~~
cpr
Actually, with GraphQL and now Om Next, you _do_ put your data store "queries"
in the component. It's a great idea.

~~~
marknutter
I think it's all fine and dandy, and I like the idea of isolated components,
but I'm not sold on shoving everything into one file. It just smacks of
preference.

~~~
mateuszf
One file per one component sounds like a better representation of one real
world concept using code. It translates 1 to 1.

~~~
marknutter
Then just put all the files for a component into a single folder, which
translates 1 to 1. Again, this is all just a matter of preference, and with
pre-compilers you could glob all your js/css/html into one file using _any_
framework if you really wanted to. Seems silly to me, but to each their own.

------
orheep
I see the point but noone in their right mind would write the javascript like
that. When written better it's a good amount shorter than the React solution.

[http://pastebin.com/wbGZZs7U](http://pastebin.com/wbGZZs7U)

~~~
chibicode
I totally agree, in fact I'm going to link this :) The point I wanted to make
is that every feature requires a bit of refactoring like this, whereas React
puts some structure.

------
sancha_
Thank you, great intro to react. Easy for me as a backend dev to follow and
get a grasp of React.

One thing, the page loaded constantly itself, after reading half through the
tutorial (3-4 minutes), I had about a hundred entries for the same page in the
tab history. This makes the website aweful.

~~~
chibicode
Thanks and oh no, do you know which browser/OS you're using? Not sure if it's
the JSBin thing...

Edit: I think it has to do with JSBin. I reported the issue here:
[https://github.com/jsbin/jsbin/issues/2464](https://github.com/jsbin/jsbin/issues/2464)

~~~
heyalexej
Same here [1].

    
    
        $ lsb_release -a
        No LSB modules are available.
        Distributor ID:	Ubuntu
        Description:	Ubuntu 14.10
        Release:	14.10
        Codename:	utopic
    
        $ google-chrome --version
        Google Chrome 43.0.2357.132
    

[1] [https://imgur.com/JN5PlqN](https://imgur.com/JN5PlqN)

~~~
chibicode
Thanks! Looks like the issue is with JSBin embed. I reported it here:

[https://github.com/jsbin/jsbin/issues/2464](https://github.com/jsbin/jsbin/issues/2464)

------
Grue3
Can React use separate HTML templates? I find this style of mixing markup and
Javascript super-ugly.

~~~
jon-wood
Done right you don't really do a lot of mixing markup and Javascript - you'll
have a render method which takes your components current state and turns it
into markup, with everything else being straight Javascript.

There are ways to avoid it, but I'd encourage you to give it a while before
looking for a way out, because almost everyone I know who had that initial
reaction has come round to it.

------
moonchrome
OK I may be off point here - but why do people who know just enough JQuery
need to know about React ?

Wasn't React developed as a tool to manage complex data flow patterns inside
of a big web app like Facebook ? Why does your average JQuery developer need
to know or care about this whole new abstraction layer ?

Even though I've seen it a 100 times by now I'm still amazed by how fad driven
programming culture is and I feel like this is a perfect example : React -
come learn this complex peace of technology to solve problems you never had
(and probably never will).

~~~
wil421
Its aimed at JS beginners, a lot of us started with simple web development
picked up some JQuery and are looking for something more powerful. This looks
like a great segue to building rich front-ends.

In fact if you look at the URL the site is called reactfordesigners.com.

~~~
moonchrome
>In fact if you look at the URL the site is called reactfordesigners.com.

You would want your designers to write frontend code that is complex enough to
require React ?

The way I've worked with designers is they create sketches and prototypes just
to demonstrate the concepts with whatever they are familiar with and then
developers turn that in to actual maintainable code with feedback.

~~~
pcr0
The title says > React.js Introduction for People Who Know Just Enough JQuery
to Get By

Unless you're working at a really big shop, designer these days is almost
synonymous with UI/UX engineer or front-end engineer. Considering the target
audience is JQuery users, React is not too far of a jump and doesn't have to
be restricted to "complex" websites.

~~~
moonchrome
In order for benefits of React to outweigh the costs you need to have a web
application with complex data flow. jQuery is proven to work and there is no
problem with it in anything less.

At the point where you actually need React you also need to understand
software engineer or you're going to get a mess no matter what the framework
is.

------
blhack
Can somebody explain to me what is so bad about jquery? I use jquery every
single day to make web pages do the things that I want them to do.

But my javascript hipster friends all claim that this is wrong and stupid and
that I shouldn't use jquery because of some abstract reason that nobody ever
seems to be able to articulate to me.

~~~
joshcanhelp
My $0.02 ...

There's nothing wrong with just using jQuery. For many, many
applications/projects it's a great tool and does everything you need.

What happens as a project/app/site grows is that you add more and more and
more jQuery to a single file and it starts to get hard to maintain (hard to
find what you want, hard to change something without something else blowing
up, hard to navigate the files you're using). Frameworks like React, Backbone,
Angular, etc were made to drive large, complicated, often single-page
applications where you have massive amounts of interacting code and want to
generally simplify what you're writing and how it's architected.

So, in the end, these are meant to help you organize code, be more productive,
and have a more coherent architecture. That's the idea, at least. The tweetbot
example here is simple because you're just learning so, if this is the only
thing you're building on a page, it probably makes more sense to just use
jQuery.

I think the typical road from jQuery-only to using a framework is your apps
get bigger and you start to think "this is hard to maintain." Then you see an
example of a framework doing something that would really help your process and
see how it could improve the code you're writing. You try it out, it makes the
process easier/more enjoyable, and you continue learning more. Or it doesn't
and you swear it off.

AFAICT, these frameworks grow out of a person or team that figures out a more
productive way to write code for what they're working on. That becomes a
boilerplate they use, then grows into something they think would help others
out. Then it gets a name and we all argue about it. In the end, it's just one
person's/team's/company's idea of how to write code better, which may or may
not work for other people/teams/companies.

------
sgrove
Also interesting to see the pitch on "ClojureScript is a Product Design
Tool"[0], written by Precursor's designer. A lot of this stuff can be made
more accessible for designers and FE developers who don't _want_ to have to
deep dive into all the new-fangled frameworks.

[0] [https://precursorapp.com/blog/clojure-is-a-product-design-
to...](https://precursorapp.com/blog/clojure-is-a-product-design-tool)

------
arenaninja
I'm excited for ReactJS catching fire. I've been using a lot of it lately, and
most recently I had to go back to a set of components I built to add
functionality. In total, the front-end took maybe 20 minutes: no fishing
around for the right selector or clashing functions. Just "here's a new
button, attach this event"

------
FloNeu
If you must compare Angular with React, then at least compare it to
ReactJs+Flux+more or Angular-Templates with React-Templates.

React is more like the view-lib of a framework. I like them both (also ember,
knockout, backbone) and unfortunately think the battle isn't decided yet. Will
take some time if ever...

Complain to Steve Jobs(1), for killing Flash/Flex, as you could to client-side
apps with desktop performance, without the hassle of Cross-Browser testing and
so on... In my opinion the concepts of Angular and React+Flux are heavily
based on the features this platform provided.

(1) IMHO the Only good thing he ever did (for the web), as it forced the
proprietary software out... but led to the great Framework-War :)

P.S.: Also Actionscript 3 was ECMAScript(Javascript) plus Classes, Types and
more... ( I wondered about which Version that was latly and found out they
implemented ECMAScript and extended it with features requested by users.)

~~~
starikovs
BTW, if you use Backbone you can simply use React as a View.

------
aprdm
Really well written, as a backend developer who has been playing a little bit
with frontend lately this hits the sweet spot :)

Cheers

~~~
chibicode
Awesome :) Glad to hear that!

------
marcamillion
This tutorial is awesome! I love the tone and how it knows EXACTLY who it is
written for.

This may be a bit late, but I would LOVE for someone to do this for JS in a
Rails App (or even CoffeeScript). I am desparately searching for good
tutorials for people that are "borderline-decent" at jQuery but are Rails
devs. I can't find any.

I understand, in theory, how to render some JS on a view and all this good
stuff - but once you go into creating a UI that feels like a modern UI with
lots of lil AJAXy elements...it can become a pain REAL quick with a bunch of
`...js.erb`s all over the place with no seeming pattern to them.

So I would love if someone had a tutorial just like this, for how to create a
simple and sexy app that looks like an Angular/Ember app but just using
CoffeeScript/jQuery/vanilla JS.

Anyone know of any such thing?

~~~
boundlessdreamz
I think the problem lies in the '.js.erb'. Write javascript in separate
javascript files (in app/assets/javascripts/) and use JSON to get data from
the rails backend.

Have you seen this? [http://todomvc.com/](http://todomvc.com/) You can try
implementing a backend in Rails for the jquery example.
[https://github.com/tastejs/todomvc/tree/gh-
pages/examples/jq...](https://github.com/tastejs/todomvc/tree/gh-
pages/examples/jquery).

The JS file shows how to organize javascript code -
[https://github.com/tastejs/todomvc/blob/gh-
pages/examples/jq...](https://github.com/tastejs/todomvc/blob/gh-
pages/examples/jquery/js/app.js)

Also unless you really like coffeescript, stick with javascript. If the syntax
is bothering you, you can write in ES6 (next version of javascript) which has
nicer syntax and use babel to convert to ES5

1\.
[https://gist.github.com/danielgtaylor/0b60c2ed1f069f118562](https://gist.github.com/danielgtaylor/0b60c2ed1f069f118562)

2\.
[http://justicen.com/#/posts/74046fea9a4c61477db9](http://justicen.com/#/posts/74046fea9a4c61477db9)

~~~
marcamillion
I hadn't seen todomvc but it doesn't quite address my issues. It still feels
too disconnected from where I am.

Also, I do write JS in separate JS files - but my understanding is that when
you want a response to be in JS, don't you have to use a corresponding
`...js.erb` file to handle the action/response?

How else would you update the DOM after the action has been completed?

~~~
boundlessdreamz
You send the response as json and act upon it. Have a look at this -
[http://jsbin.com/depuvelixu/edit?html,js,output](http://jsbin.com/depuvelixu/edit?html,js,output)

The json the code fetches is static but it can be served by a rails app. The
DOM manipulation gets painful which is the reason people adopt JS frameworks.

------
iamflimflam1
Really great tutorial - would be good in the next steps to talk about getting
webpack setup etc..

~~~
chibicode
Thanks! I definitely should put more in the next steps, like
examples/talks/etc. I wanted to ship this asap :)

~~~
iamflimflam1
Shipping - for some reason in my day job I can ship to almost any deadline.
Side projects - one day I'll finally finish one...

------
k__
Good article. Needed it two weeks ago :D

I did 4 years ExtJS and 1 year Ember. React was totally different but rather
nice to work with. The API surface is so much smaller.

------
toxickg
Great job, man! You make some strong points here that clearly reflect the
important differences of these two approaches! Well done!

~~~
chibicode
Thank you :) !

------
jarnix
Comparing jquery to React (or Angular/Aurelia/etc) is obvious but the article
is great for beginners though.

------
hive_mind
Great concept (tutorials for people who know just enough JQuery). Would love
more tutorials (for Angular, e.g.) for such people.

TodoMVC was a great effort. But unfortunately, the actual Todo creations are
not well documented (for beginners to figure out how and why certain things
were done).

------
radiospiel
This is really neat.. one thing though: there is nothing magic about 'the
"magic" state'; it would IMHO be better to just call it state (or inner state,
or so), and to explain that once the state is changed react rerenders the
component automatically.

~~~
chibicode
Yup, I agree... will fix! Thank you!

------
tracker1
I think this article demonstrates very well why I think React should be the
first choice for any new web projects... what to go with it (ember, flux (and
related), or other) is open to more debate.

Of course there are great alternatives with similar workflows (mercury, etc).

~~~
DigitalSea
I think this sums up React.js perfectly. Easy to learn and build something
with, but the discussion around Flux and what libraries to use to implement it
can complicate and deter newbies. The official explanation of Flux on
Facebook's own site I think does a poor job explaining it in a way most
developers (new and senior alike) can understand.

~~~
tracker1
That's very fair, it gets even more complicated when trying to do
server/client mixed rendering with it. It's all very hard to grasp in a deeper
level.

This tutorial is absolutely awesome.. and I think the deep dive is worth it
for larger apps too.

------
sergiotapia
This is the first React article I read where it actually compares and
contrasts the jQuery approach and the React approach. I feel like React makes
sense now, even though writing my HTML inside JS still feels off.

------
Omnipresent
That is a truly impressive tutorial. Just curious, how much time did you spend
on putting it together? Additional props for doing it being a dad!

~~~
chibicode
A few hours every night for a week :) But I'm not a dad, haha.

------
pjmlp
My web experience is mostly custom in-house web frameworks, JSP, JSF,
WebForms, jQuery and basic Angular.

It was a nice overview of React to me.

------
rashthedude
Would you be open to the idea of writing something similar for React Native if
you are interested and/or find the time?

------
jozan
This is neat! Thanks for sharing.

~~~
chibicode
Thank you for reading!

------
akhilcacharya
Wow, this is exactly what I needed.

------
rashthedude
Beautiful article man.

------
curiousjorge
am I the only one fine with using just jQuery and ajax? I've written a chrome
extension with 4k lines of code and I never had any problems. Instead of
breaking things into separate classes and components, I just put them in
separate files or in logical sequence. I'm sure this can get a lot messy with
more than one developer but so far my projects, I almost always just use some
jQuery library or plugin that does 80% of what I want to do and hack the rest.

~~~
BinaryIdiot
There are dozens of us! Dozens!

In all seriousness I typically work with a lot of designers; asking them to
update markup in JSX versus HTML is simply not possible. It's not because they
can't figure it out but it makes it more difficult for them to quickly test
and they typically break JavaScript in many, unexpected ways. While I'm fine
with the UI and business logic separation where UI can contain markup _and_
scripting, I don't think the answer is this awkward solution of shoving HTML
into the scripting.

~~~
thoman23
This is what worries me. We are using Angular, and my non-technical co-founder
knows just enough HTML and CSS that she makes a very useful contribution to
our front-end development. Sometimes the contribution is in the form of HTML
mockups produced outside of our app that are easy for me to port over, and
sometimes it's direct contributions to the codebase. I worry that if I went
the React JSX route that it would be much harder for her, or pure designers
that we might hire, to meaningfully pitch in.

~~~
magicalist
A fine thing to do in that case is just to use React but without the JSX.

~~~
thoman23
My understanding was that forgoing JSX would make the situation worse by
falling back to imperatively manipulating the (virtual) DOM within your
component. If there is a way to have an external, declarative HTML document
using React I would be very interested.

