Hacker News new | comments | show | ask | jobs | submit login
Learn Raw React – No JSX, No Flux, No ES6, No Webpack (jamesknelson.com)
243 points by dlcmh 439 days ago | hide | past | web | 58 comments | favorite



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!


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


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


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.


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


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"


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


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


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.


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.


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.


When I started learning iOS dev, every tutorial pointed me at the interface builder. It drove me nuts because I'm doing this magic and things are happening but when something fails I have no clue what to do, and guess what: things failed a lot and for weird reasons when you used IB and didn't know how it worked under the hood.

Granted JSX is far less bloated than IB, but its important to understand <Component /> bootstraps a react class component and <div> just renders a div.


> If someone starting with React sees all that React.create element, they will run away.

That's a possible reaction. Other developers would refactor instead of running away, though. Not using JSX doesn't mean typing React.createElement all over the place.

var e = React.createElement

And you already have much neater code. You can even go further and create functions for p, h1, input etc. and you're almost down to the expression power of JSX. And as a bonus, you don't have to spend time learning the JSX compiler and syntax.


I don't think this is intended to replace 101-level tutorials. This is to help break down what's going on behind the scenes after you've been through todolist etc.

In the article Mr. Nelson says the intended audience are people who have "spent a couple hours investigating" already.


Absolutely this. I just started learning React a few days ago, and I absolutely would not have given it a chance with all those React.createElements. That looks like hell.


Some people don't like JSX. This is fine. But to imply that it's not part of React by calling the non-JSX variant "raw React" is misleading.


It's not misleading at all. I've created several React apps without JSX. I just didn't feel I had a need for it, and React without JSX worked really well.

People make these exaggerated comparisons of raw React code vs. JSX where they show unrefactored code with React.createElement spammed all over the place. With functional programming principles you can cut that syntax down to almost the expression power of JSX.


> you can cut that syntax down to almost the expression power of JSX.

What was the benefit for you over simply using JSX?


No need to use or understand a compiler. Also plain JS has better existing tooling (IDE plugins etc.) than JSX.


Not for me. I hate JSX, mainly because I like coffeescript and jade. I write all my code, view and otherwise, in coffee.


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.


If you like doing this sort of thing, check out http://mithril.js.org.


Great stuff!

    var tag = React.createElement
Could make the code nicer to read...


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.


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


Mithril.js uses 'm()'.

Check it out: http://mithril.js.org


You've hit the nail on the head. I've never seen a fair JSX vs. React.createElement comparison on a blog post. The latter is never given even a basic refactoring such as you and your child comment suggested.


The verbosity makes things easier to understand for beginners.


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


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.


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


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?


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.


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


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.


This is great. Also see the React docs tutorial: https://facebook.github.io/react/docs/tutorial.html


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


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


Good article.

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


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.


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


It mixes presentation and presentation logic. You don't have to use a poor language to build your HTML.


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.


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.


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.


This looks great, thanks!


Now add RxJS !


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.


Why not Clojurescript with Reagent?


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.


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


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.


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


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.


Not every application faces all the problems you mention:

A lot of teams don't have the "designer" problem and are just fine without JSX.

Passing data through dozens of children is not a problem in every application, a lot of simple CRUD stuff can do just fine without Flux.

Even bundling is not necessary for progressively enhanced websites, and for most SPAs a really simple, naive strategy will do just fine.

If the requirements of your project are ambitious, some complexity is not avoidable.

But the problem today is that a lot of unneeded complexity is introduced into projects because people want to adhere to "best practice" and don't question what they need and what they don't need.

In my opinion, it is a huge mistake to not actively resist complexity creeping into your project. You should only give in if it there is proof that it makes sense economically.

This issue is another variant of "premature optimization is the root of all evil"


Another quote I try to live by is from Brian Kernighan, who said "Controlling complexity is the essence of computer programming." It's common programmer humor that early in our career we fall in love with building beautiful and complex machines, but as we gain experience learn how to keep it simple, short and concise while accomplishing the same task.


Webpack is awesome, and sort of unrelated to React.js. It's a SPA bundler that works across server and client. It virtually works with anything, so I'm not sure why it's getting mentioned with React.js necessarily.


React and Webpack are both awesome, they both work across server and client, they complement each other rather well. Obviously they are mentioned together a lot.

You can use React without Webpack just fine, as the article shows you can use React without any bundler at all. But it is just so much better with Webpack. When you really start making components and put them in separate files, the raw approach in the article will not scale very well.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: