Learn Raw React – No JSX, No Flux, No ES6, No Webpack
jamesknelson.com
jamesknelson.com
A useful, educational exercise!
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.
Webassembly is coming!
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).
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"
> 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().
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.
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.
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.
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.
In the article Mr. Nelson says the intended audience are people who have "spent a couple hours investigating" already.
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.
What was the benefit for you over simply using JSX?
Tutorials should be about teaching others. But many tutorials today seem to be more about showing what the author knows.
var tag = React.createElement
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...)
Check it out: http://mithril.js.org
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
I did something like this too. But less prose, a bit shorter and it starts a bit low-level.
Also, for more discussion regarding using React without JSX, see https://github.com/ustun/react-without-jsx
But since its pushing people in the right direction, I approve your message.
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.
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.
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.
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.
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.
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"
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.