
Learn Raw React – No JSX, No Flux, No ES6, No Webpack - dlcmh
http://jamesknelson.com/learn-raw-react-no-jsx-flux-es6-webpack/
======
chadaustin
Reminds me of working on an old Windows UI almost two decades ago. All the
tutorials were basically "you should type this", and all the project templates
and UI editors in Visual Studio produced copious amounts of generated code.
Nobody seemed to really understand that generated code. So I sat down and
learned how to write a new MFC project from scratch, no templates or generated
code. Once I understood what it was doing, I felt like I could use the rest of
the ecosystem with confidence.

A useful, educational exercise!

~~~
tyingq
>>Reminds me of working on an old Windows UI

Me too, in a different way. It provides a very clear view of how MVC moves
from the back end to the front end. Coupled with other things that have moved
more of the meat of the work to the browser, you end up in a funny circular
place.

At a high level, it starts to look much more like the pre-web client/server
model of "fat clients" written in MS/MFC, or C/X11/Motif/Qt/etc, and the
backend relegated to mostly serving centralized data or events.

What's old is new again I suppose. The browser, in general, feels like a giant
step forward. I wish, though, that some ecosystem had evolved where Javascript
wasn't the sole supported client side language.

~~~
bonobo3000
>What's old is new again I suppose. The browser, in general, feels like a
giant step forward. I wish, though, that some ecosystem had evolved where
Javascript wasn't the sole supported client side language.

Webassembly is coming!

~~~
tyingq
That's somewhat encouraging, but if I understand it correctly, it would only
be practical for static typed languages. Something like Lua, Python, etc,
would be more desirable to me.

~~~
vmorgulis
It's a byte code (in an ast form) so any language could run.

I think the step after can be around package management (like in linux
distros) and full virtualisation in the browser.

We can even imagine the browser becoming useless so we could move to something
new for AI, drones and robots where webdesign is not a priority (simpler UI
like apps for mobiles).

~~~
tyingq
Not anytime soon, as far as I can tell:

Brendan Eich: _" wasm is really starting out as a target for static languages
like C++, it’s gonna be a while before we get other future extensions to wasm
like garbage collection and just-in-time compile to wasm, features we need for
dynamic languages to perform well, that’s gonna take a while to do, too"_

------
dclowd9901
First, kudos to the author for this approach. I avoided the hell out of react
for the longest time because of the JavaScript build soup you seemingly needed
to get anything to run. I would've loved a tut like this a year ago.

> At it’s most basic, React is a tool for rendering HTML with JavaScript.

Not really; at its most basic, it's a tool that inextricably ties DOM state
with JavaScript (a conceptual implementation of WebComponents). That's the
power of React. Yes, a byproduct of that is that it renders HTML, but you use
it so you don't have to use things like Sizzle to get into and manage the
state of the DOM. Its a small difference but meaningful in that you wouldn't
want to confuse its purpose with something like document.createElement().

~~~
akamaozu
> at its most basic, it's a tool that inextricably ties DOM state with
> JavaScript

Thank you for this!

It seems like many people get the impression that React is a really fancy
template engine, which sucks.

Part of what its capable of is rendering templates, but only as a byproduct of
the task you described.

------
manojlds
Why not JSX? To me, JSX is part of React. If someone starting with React sees
all that React.create element, they will run away.

~~~
jamesknelson
Author here. My target audience here was really people who've already decided
they're going to use React, and are keen on understanding what is going on
under the hood. And while I do love JSX (and use it in my own projects), my
feeling is that to really grok React, writing something without JSX is
invaluable.

~~~
SiVal
I'm part of that target audience, and you scored a bullseye with me. I always
prefer to learn a new technology this way, by building very simple things from
scratch and making minor modifications this way and that until I know what all
the low-level parts do. Then, you can add some conveniences to the mix
explaining what they do in terms of the underlying technology I just learned
(and I can tell which parts are the base technology and which belong to this
add-on), until I feel I could recreate these conveniences or build my own
alternatives, if I chose to.

That way, I can decide for myself how to use the technology, break away from
the typical stack of add-ons at any point I choose and take it from there in a
direction that better suits my needs, dig in and figure out what's going on if
I have a problem, and so on, rather than being helplessly dependent on a
magical black box.

Thank you for starting off by teaching low-level React without any JSX, Flux,
Redux, or whatever. I wish more tutorials did that.

------
matthewtoast
Nice work! I'm really happy to see this kind of restrained approach to
introducing React. I wish it had been the first tutorial I encountered. I hope
it inspires other teachers.

Tutorials should be about teaching others. But many tutorials today seem to be
more about showing what the author knows.

------
niothiel
If you like doing this sort of thing, check out
[http://mithril.js.org](http://mithril.js.org).

------
mbrock
Great stuff!

    
    
        var tag = React.createElement
    

Could make the code nicer to read...

~~~
wereHamster
or even h1 = React.createFactory('h1'), ... and so on for every that you use
in the file, and then use h1({}, 'text') in the code.

~~~
brianshaler
What about h1 = React.DOM.h1;?

Personally, I moved from using DOM tag names as variable names ('a' being the
worst) to saving 'var DOM = React.DOM' (or '{DOM} = React') and then calling
DOM.a(props, children...)

------
kelkes
Was looking for something like this to get started with React. Many Kudos!

------
zapu
I've found React itself pretty easy and fun. Finding the right libraries (I
still don't know what I should use for promises) and connecting all the
tooling with one of the build systems is the part I'm losing sleep over.

~~~
dclowd9901
Any a+ spec library will do. I prefer bluebird.

------
Kiro
I just can't be bothered with build tools. I just want to include a JS and use
it. That's how I roll. How can I overcome this?

~~~
mbrock
Just keep doing that. If you then start feeling some pains that a build tool
could help with, install the build tool and move on.

------
benatkin
I think _raw_ React is React as it's defined by the project maintainers. JSX
always seems to be a part of this.

~~~
twic
I think "raw" distinguishes something from the normal state in which it is
consumed. For example, a raw Big Mac is not the thing that McDonald's want to
give you, but it's an interesting thing to study if you want to understand how
a Big Mac works.

------
firasd
This is great. Also see the React docs tutorial:
[https://facebook.github.io/react/docs/tutorial.html](https://facebook.github.io/react/docs/tutorial.html)

------
tyingq
This sort of "deconstructed" approach was helpful for me.

I also found it easier to start learning first with a decent foundation of
just "what is a virtual dom?"

This was useful: [https://github.com/Matt-Esch/virtual-
dom](https://github.com/Matt-Esch/virtual-dom)

------
k__
Good work.

I did something like this too. But less prose, a bit shorter and it starts a
bit low-level.

[https://github.com/kay-is/react-from-zero](https://github.com/kay-is/react-
from-zero)

------
ludwigvan
Good article.

Also, for more discussion regarding using React without JSX, see
[https://github.com/ustun/react-without-jsx](https://github.com/ustun/react-
without-jsx)

------
proc0
Thanks. I actually don't like JSX. It seems it encourages logic and
presentation mixup. Plain React.js seems good for Views as they advertise. I
think React.js + ES6 + functional library, will make a good combo.

~~~
firasd
Not using JSX won't mean your React doesn't mix HTML & JS though. React's
whole philosophy is to mix them. So it just means you will have to keep typing
".createElement('h1'...)" instead of typing "<h1>".

------
kra34
You're so close! just change it to "Learn Raw Javascript - No React - no jsx
..."

But since its pushing people in the right direction, I approve your message.

------
draw_down
ES6 is the variant of the language we will be using in the future (and many of
us presently). It's not a fancy gewgaw that hipster devs use to look cool.

~~~
rnnr
He's point was to make a gentler and more approachable introduction to react
without any fancy transpiling tools. He isn't mocking any of these
technologies. Awesome writer kudos to him.

------
neurowolf
This looks great, thanks!

------
crudbug
Now add RxJS !

~~~
Ronsenshi
I hope you meant add RxJS in possible future tutorials.

It is very clear that author's intention for this post was to avoid any
unnecessary clutter - hence no Flux, no JSX etc. Adding RxJS and with it a
whole train that is functional programming is definitely not something that
would be helpful for people who just want to "get" React.

------
jbeja
Why not Clojurescript with Reagent?

------
marknutter
The problem is, of course, that JSX, Flux, and Webpack came to be because of
_problems_ that people ran into when using just raw react. JSX solves the
problem of not being declarative enough and being too foreign to designers.
Flux solves the problem of having to cascade data through dozens of children
for mundane tasks. Then of course Webpack solves the problem of needing to
transpile JSX and ES6 to plain JavaScript and minifying/uglifying/etc your
assets. There is no such thing as "raw React" because building a web
application is complicated no matter how you slice it. You either use a svelte
library like React or Backbone and bolt on everything else you need yourself,
or you just use a batteries-included framework like Ember, Angular, or Aurelia
and let someone else provide a convention for you to follow.

Complexity, sadly, is impossible to avoid.

~~~
BinaryIdiot
> Complexity, sadly, is impossible to avoid.

Complexity is impossible to avoid? Reading this just makes my heart sad. There
is no reason you can't avoid complexity here.

Minifying and concatenating of assets is a very understood thing. It's really
easy to do in fact. Whatever building solution you use (grunt, gulp, plain
scripts), minifying and concatenating of resources should be a few lines of
code if that.

Transpiling I don't get. Yeah I'd love to use the new hotness of ECMAScript 6
but ECMAScript 5 has awesome support everywhere and isn't so significantly
different to 6 that productivity is horrible; why can't we just use ECMAScript
5 until 6 is more readily available? But I digress because if you have to
transpile that's still an easy build step. If you want to do it with every
file change then that sucks, stop doing that. That's only useful in edge cases
like debugging older browsers.

For JSX just don't use it. HTML and JavaScript is kinda awkward to begin with;
combining them together in some mixed format only to be separated seems like a
way to just obfuscate the real way it works. I find it far, far better to
understand how they work than trying to abstract them to some awkward degree
that can't be used without transpiling.

Maybe I'm an old timer not using the new hotness that is JSX, Webpack, etc but
I just don't understand why anyone would bother bringing in that extra
complexity when it's unnecessary even from a productivity standpoint. But I
digress, maybe I'll just get downvoted here I just don't get it.

~~~
1stop
Once you add a transpile step, your "transpile step" can give you a lot more
confidence, with linting, and flow, and ecmascript 6.

Minifying, concatenating, and compiling only used code paths/files and assets
is only a few lines of code ( _with webpack_ ).

JSX to me is the more natural way to use React. I don't understand what the
benefit of moving away from <html> is. It's more verbose, and harder to read
if you construct your views in pure-js. (imo)

To me, using webpack is avoiding complexity. It's a set and forget exercise,
sure it's a bummer upfront. But once it's running, it's pretty smooth.

~~~
BinaryIdiot
> Once you add a transpile step, your "transpile step" can give you a lot more
> confidence, with linting, and flow, and ecmascript 6.

Linting is separate. Transpiling, for me, gives me less confidence because I
write in one language, it has to run a transpiler to turn into another
language giving me an extra point of failure (transpiler bugs suck; I ran into
a few with CoffeeScript a few years back. Turned me off from ever using one
again). Unless you have mappings debugging also has to be done in a separate
language than what you write in which is really hard for me to get used to (I
had to debug CoffeeScript back before it had chrome mappings).

> Minifying, concatenating, and compiling only used code paths/files and
> assets is only a few lines of code (with webpack).

Also only takes a few lines without webpack. For example my open source
project, msngr.js, uses grunt and it's only a few lines of code specifying
input and output.

I also have a private project that does the step with a loop and a few
additional lines of code (uses no grunt or gulp).

> JSX to me is the more natural way to use React. I don't understand what the
> benefit of moving away from <html> is. It's more verbose, and harder to read
> if you construct your views in pure-js. (imo)

JSX is probably a more natural way of working with React but it still
abstracts away from the awkward JavaScript and HTML realities of the day. I've
become jaded with frameworks that do that because I've run into far too many
developers that don't understand how HTML and JavaScript really work and run
into errors that are easily fixed if they understand how the underlying
technology works.

HTML's relationship with CSS and JavaScript is still kinda awkward so I
understand why there are seemingly dozens of frameworks that abstract away
from the whole thing.

> To me, using webpack is avoiding complexity. It's a set and forget exercise,
> sure it's a bummer upfront. But once it's running, it's pretty smooth.

I've used it and just didn't get the point of the thing. It helps that I avoid
pretty much anything that gets transpiled (otherwise I could see it being more
useful). If you don't do anything with transpiling I don't think it's very
useful.

~~~
1stop
I think I mostly agree with you.

But with source mappings, trans-piling is pretty neat. With ECMAScript 6,
Coffee, or Typescript. I remember the days of buggy Coffee and agree it was
ridiculous when you hit a compile bug. But all the transpilers are much more
mature now, and with source mappings you always know which line is wrong, and
can even breakpoint and debug etc.

