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).
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.
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.
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.
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]).
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.
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.
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.
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.
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.
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.
true, but to be fair, you'd probably also want to introduce variables like $addPhotoBtn, $tweetBtn, $textLengthLbl, etc, to avoid css queries on every keyboard change. That would add to solution length and also introduce a bind-step to avoid stale variables after a dom change.
Also, there's the authors very well-placed point that adding a new feature may lead to css query refactoring, eg. when $("textarea") doesn't cut it. I find html refactorings to be nb 1 cause for breaking progressively enhanced solutions like this one, probably bc I suck at naming elements.
Lastly, it should be noted that this refactored solution does not contain all the features of the final react solution.
Makes more sense to me to have the "Tweet" button enabled by default and disabled on load by JS. If there's an issue with the JS or it's disabled in the browser or whatever, the button should still work (with server side logic to catch empty Tweets). Right now, if the JS doesn't load you can't Tweet at all.
Just a small nitpick I had after thinking about the reasoning behind why the OP had disabled the button in JS rather than the HTML in the first place.
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.
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"
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.
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.
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.
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.
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.
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).
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.
>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.
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.
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.
My educational roots are in graphic design but I have taken on more and more front end development as my career has progressed to the point that I'm mostly coding these days.
With Web design, I started with simple HTML sites, learned CSS, then learned some JS to manipulate the DOMs I created.
Having run into some of the jQuery pitfalls that the author describes, This tutorial meets me where I'm at and takes me to a new place, using incremental, concrete, and practical examples to show me that React is a logical extension of JS in certain use cases.
Designers are visual people, so being able to see each step along the way and telling me why it's important is a really big deal. I have some projects now where I'm changing state quite a bit, and I can now see where React would be really useful. Designers also tend to get into the web coding stack from the front end first, so I think we end up thinking about coding a Web site in a really different way than back-end developers with a background in software engineering.
As a front end dev, I love it when people I work with use the right tools, and the mindset encouraged by making React things is just... good. The lisp/scheme/clojure wisebeards would approve of how it makes you think about UI.
I feel as though the move from raw JS to JQuery is similar in significance to the move from JQuery to React. So in answer to your question, I would say a dev who learned React would be more appealing as a hire and as a colleague, and it'd be well worth the investment for any future career.
I've spent ~2-3 years programming in clojure and prototyped stuff in clojurescript. While I love it for the domains it applies and it has influenced my programming considerably - I would never recommend random 9-5 Java dev shop to go pick up Clojure - there's just no point - Java works fine for what they are doing and their developers know it - learning Clojure would be a huge investment and the benefits wouldn't really be there.
The same thing is true for jQuery -> React. If you're a front end designer who does some programming - you need to learn the DOM and CSS, jQuery is just a simple tool to leverage that more easily.
React is a fundamental change that requires a lot of relearning and more importantly the benefits are questionable unless you're dealing with the scenarios it was designed for. You need to have experience with existing tech (that is way more intuitive, like two way data binding) to see what problems it solves - that's not in the domain of a jquery programmer.
I also wouldn't call people who "just know jQuery" devs but rather designers who know how to code.
In all seriousness, I've already had to rewrite a codebase because an inexperienced programmer (less than 2 years professional) chose it for a use case that wasn't even appropriate, and he did a terrible job implementing it correctly. My team that took over wasn't happy.
If programmers didn't do stuff solely because it's cool, then that would have been a day back on that project.
I guess the idea is that maybe they'd like to do things that they can't currently do? I'd even argue learning React is more compelling for someone who's never used any of the competing products that for someone who has.
I don't think anyone is saying people who know just enough jQuery NEED to know about React, just like jQuery, React is just another tool. To address your points though, React is "A javascript library for building user interfaces", it wasn't developed to be a tool to manage data flow patterns, it was built solely as a view library. Most people pick up jQuery as a means of manipulating their views/the dom so the target audience of both libraries as well as their use cases is very similar. Now I'm not saying the same thing will happen with React, but not too long ago people were saying the exact same thing about jQuery when it was introduced.
React has a significant learning curve and a different model from regular DOM. It has a significant cost over something like jQuery especially when you already know jQuery.
jQuery works just fine at small enough scale. Once you out-scale jQuery you will have problems that won't be solved just by using a different view library - you need to understand software engineering - which is why everyone who actually uses reacts also uses things like Flux, etc.
My point is jQuery works for what it's used, getting people to switch to React seems like a fad because "the cool kids are doing it".
I thought the linked article actually made the most convincing case I've seen yet for using React for "simple" UIs that you would normally build using jQuery. It demonstrates that even something simple like a tweet box (textarea, character countdown, a couple of buttons) benefits from the React methodology.
Novice programmers don't have the perspective to understand that the latest hot library may be old news in 6 months, and how the old adage of "hold a hammer and everything becomes a nail" can impact a project.
A year or so junior programmers figured out how to add Angular as a dependency into every single project whether it was needed or not, now people are teaching them how to do the same with React. The constant parade of new JS frameworks combined with the ease of package managers & compilers is creating a nightmare scenario when it comes to project bloat
I don't know why you think React is complex. At its basic form you need to know render method. Its one of the simplist to pickup. I suppose you need to change how you view your page, as a bunch of components instead of dom tags.
I have used it on complex single page app with Flux and without Flux along with simple small components for rails app. Now i don't feel the need to use JQuery but for the very simple single line ops(like hide, show etc). OfCourse i still use JQuery it for ajax.
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?
React certainly replaces Angular as a View+Controller framework (idk about Ember, although I know there's been work on integrating the performance benefits of Virtual DOM).
In scenarios with complex interactions, something like Flux is desirable, however small web apps work fine with simple JSON REST APIs.
React will probably just integrate those as they become usable, since React acts as a layer of abstraction between the DOM and your presentation logic.
Not so. React does not really play well with web components. Currently React has to internally define JSX elements for every known HTML element that's out there, namely to track internal state and respond to events (i.e. input fields). Because they won't be able to do the same for the vast ocean of web components that will be authored in the coming years, it will be difficult to provide clean interop with new custom elements. The React maintainers have even stated that they don't believe web components are the right way forward for web application development. React was never designed to work well with web components in the first place. On the other hand, the main reason why Angular 2.0 is such a drastic rewrite is because they needed to do it in order for Angular to work seamlessly with Web Components. It's no coincidence that both Angular and web components are Google initiatives.
But Angular is a glorified templating engine, where react is really about FRP and rendering from data. The React components you write are essentially web components that use DOM; as long as there are standard building blocks for web components in the future, you could easily port it to React.
Yes, but now you're requiring that developers go through the work of porting every single third party web component they might want to use in their project. That's the current pain we're all going through today with Angular, React, Ember, etc, which are basically glorified web component polyfills when it comes down to it. The whole point of Web Components is portability.
You're wrong about web components and react. As of 0.12, if you register a web component like you normally would, you can reference it in a react component. React no longer has a white list, and instead assumes all lower case tags are HTML tags (standard or custom).
The only drawback is that it doesn't support custom events out of the box. Instead, you have to manually create event listeners on elements on mount. As far as I can tell, there's no reason why it couldn't in the future though; Web component adoption is so low right now that it just hasn't been something people have complained about.
Not supporting custom events is pretty much the same as not supporting web components. What if you use a third party web component that has dozens of events? The goal should be interop with no additional plumbing required.
There was a time when React literally just didn't support web components, so I don't think that's really fair. Yes, it would be nice if it worked completely free, but if you're only listening to 2 or 3 events on a component, it is definitely a fair price to pay for being so bleeding edge.
> Can React also connect with backend APIs to fetch JSON and present them on the frontend?
Yes, obviously. My company uses it for this. Personally, I don't know if AngularJS is a better alternative moving forward because it has a bigger community and companies such as Microsoft are integrating it on Visual Studio.
How revolutionary does it end up being if you have to farm out a lot of hte stuff you'll do to other JavaScript libraries which presumably do not have a native component?
I said React Native is revolutionary. It's the first JS framework that lets you build native iOS and Android apps. Key word here being "native".
React itself was designed as a UI library, purely to be used as the "V" in an MVC app. It's like expecting D3.js to do your AJAX calls. Unless it's a full front-end framework, there's no point trying to do everything.
I mean that the competing frameworks are whole application frameworks instead of just a view; being able to write them and compile them to native would be even more powerful.
I've been told by several friends who love React that this is one of the main selling points.
It basically just gives you a view engine and then you have the flexibility to select what other libraries you want to supplement the rest of the app components.
This differs from other frameworks like Angular where you have to "go all in" and don't have the flexibility so that if something major changes (like when the Angular team announced HUGE changes coming in 2.0) you might get stuck with something you don't like. In this way, it's easier to switch out a part of your app as opposed to having to completely rewrite something if you use a full framework like AngularJS.
I get that but there's a sort of value to a monolith that gives you most of what you'd need to build an SPA with a "guarantee" that all the components are reasonably good too.
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.
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?
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'
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
Thanks, appreciate the pointer - the idea of adopting something potentially a future standard through a polyfill is appealing. @pvg I take your point about lack of browser support, but that's what polyfills are for after all! :)
In the meantime since asking I also came across restful.js (github [1], blog [2]) - it's new, but looks like a good framework-neutral alternative, if a little heavy at 27K minimised/uncompressed.
Edit: Actually, fetch.js + es6-promise-min.js = 26K, so not much in it.
> ? Can React also connect with backend APIs to fetch JSON and present them on the front-end?
Technically? No.
React doesn't include the direct code to main API calls. You're still going to need to make the 'API calls' 'yourself', whether with jQuery or raw XMLHttpRequest or whatever. React comes into play when you have the data and you're ready do actually do something with it.
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?
Yes, i think you miss something important here. It's a tradeoff. You should make your choice based on pros and cons, it's more objective than subjective when you hate something and you don't use it. It's harmful and useless thought:)
Yes, this appears to be the normal reaction to JSX (it took me 3 months to actually try React just because of the idea of it - more fool me).
My advice is to try it at least to the point where you've created a couple of components and rendered one inside the other. A component manages everything to do with how it works with props it's given and the state it manages, and how it renders is just another part of that concern.
One of the nice pros you get used to quite quickly is having your editor autocomplete event handler and data variable names, as they're all right there in the same file.
JSX is just sugar for React.createElement() function calls, the syntax of which otherwise gets quite unpleasant to write and maintain once you start nesting them to any degree (ask anyone who's used a DOM builder library for a complete app).
Once I started using React in practice though, it turned out to be pretty nice. It significantly reduces cognitive overhead when thinking about frontend elements. And if you're worried about your javascript file starting to look more like an HTML file, composition of JSX components helps break things up.
Even if I can't convince you that it's actually pretty nice, you can write React without using any JSX. Just use a live compiler http://facebook.github.io/react/jsx-compiler.html to translate any documentation into the vanilla JS equivalent.
Since it is code that just translates to javascript, it's nice because you can have onClick handlers and such right inline, without having the downsides of inline javascript. You build reusable components that are self contained with their content and their logic. So you know when you use a component, the logic comes with it. You don't miss out on important bindings.
Also i've never really gotten into all the string magic that angular templates use. ng-click="myEvent()", vs passing the event to the component as a property feels.
The concept behind directives like ng-click is actually pretty simple underneath.
The Angular parser will go through the elements in the DOM and look for attributes it knows about like ng-click. When it finds ng-click, it will run the expression "myEvent()" on the controller's $scope.
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.
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.
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.
So split it up. Most React projects make use of Webpack or Browserify, or use ES6 modules via Babel. There are emerging patterns for keeping concerns in separate places but still having one component you can drop in declaratively.
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.
> Except that there are use cases where you want to use boilerplate HTML in more than one component
In this case, you can split out that boilerplate into a separate, smaller component and reuse it inside as many other components as you need.
> By that logic we should be putting our data stores in the component, any translations required to internationalize the component, the database queries.
I respectfully disagree with your inference here - such functions can be abstracted and used by many components - in most cases there's no value in baking them directly into a component.
The exception to this is if the function is not abstract at all, makes no sense outside the context of the component, and therefore can't be reused. Then, it probably makes more sense to put it inside the component, rather than breaking it out into a separate file.
This is true of most if not all of the markup and styles used inside a component, which is why React encourages JSX and inline styles to be put directly inside the component as it's the only place they make sense, and the only place they'll be used. The markup, styles and component behaviour are intrinsically coupled, there is a lot of 1:1 referencing, and separating them out into separate files means you'll just be flicking between three files when working on a component, instead of one. Where there is 1:n referencing, well, that's when you should break your component into smaller, reusable pieces.
It bothers me because my super intelligent HTML editor becomes useless if I choose to use React.
The reason like Knockout.js because all the magic happens in a standard data-bind attribute, no funky syntax or paradigm shifts required. A purely functional solution like React seems like it's good for making games. Beyond that, for most sites, I think it would be more work to use React for little to no gain.
Knockout is a decent framework, I am using it on a large application currently. It has made some things that would be very hard much easier.
However it has a few issues.
1. Wrapping everything in observables is a bit annoying. Subtle issues can arise here in there especially if using the mapping plugin (which you kind of have to, it makes the process bearable).
2. If you start to have a lot of bindings on a page (a few hundred) performance degrades rapidly and there is a ton of DOM thrashing. Part of the problem is that a binding places an event handler directly on the DOM element. But there is also the initial load "flicker"/DOM thrash which for a significant page can take a second or two.
3. There are lots of workarounds such as rate limited observables, etc... But these are applied individually and become very tedious. They do not solve the entire problem either.
React solves all 3 of these so I can see significant benefits there. I have not switched myself but am experimenting. I do think Flux, Stores, etc.. are very overkill and actually poor architecture. But thankfully there are many alternatives cropping up which are much better.
There are definitely some issues. Regarding the mapping plugin, I managed to build a large custom CRM and accounts payable system without using it, but I did have to build out some custom routines in order to standardize my workflow...
React.js seems like it could be a good core for something like those alternative frameworks that you mentioned popping up. Aurelia looks interesting to me, but I don't think it uses React by default.
There are plenty of examples in other frameworks, e.g. sometimes view helpers in Rails output HTML. In certain situations it helps you write much cleaner code and it's easier to make more complex view components. Rails form helpers output HTML.
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.)
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.
235 comments
[ 1.7 ms ] story [ 248 ms ] threadI wrote about it a bit here [1].
Unfortunately... It does kind of assume you're familiar with CommonJS and a bit of the ecosystem.
[0] http://github.com/cesarandreu/web-app
[1] https://blog.cesarandreu.com/posts/a_reasonable_starting_poi...
Of course there are great alternatives with similar workflows (mercury, etc).
This tutorial is absolutely awesome.. and I think the deep dive is worth it for larger apps too.
Cheers
Good work.
[1]: https://tour.golang.org/welcome/1
Also: What's the deal with "the cow above"?
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.
Edit: I think it has to do with JSBin. I reported the issue here: https://github.com/jsbin/jsbin/issues/2464
Edit: It might have to do with JSBin. I reported it here: https://github.com/jsbin/jsbin/issues/2464
Edit: It might have to do with JSBin. I reported it here: https://github.com/jsbin/jsbin/issues/2464
Edit: It might have to do with JSBin. I reported it here: https://github.com/jsbin/jsbin/issues/2464
https://github.com/jsbin/jsbin/issues/2464
Thanks.
Really well written as well.
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.
http://pastebin.com/wbGZZs7U
Also, there's the authors very well-placed point that adding a new feature may lead to css query refactoring, eg. when $("textarea") doesn't cut it. I find html refactorings to be nb 1 cause for breaking progressively enhanced solutions like this one, probably bc I suck at naming elements.
Lastly, it should be noted that this refactored solution does not contain all the features of the final react solution.
Just a small nitpick I had after thinking about the reasoning behind why the OP had disabled the button in JS rather than the HTML in the first place.
http://pastebin.com/wbGZZs7U
It was a nice overview of React to me.
I think this kind of design should really be avoided, it breaks my user experience.
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.
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.
Please keep reading! It's really more than that! I wasted 2 years by not spending 20 more mins.
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).
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.
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.
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.
With Web design, I started with simple HTML sites, learned CSS, then learned some JS to manipulate the DOMs I created.
Having run into some of the jQuery pitfalls that the author describes, This tutorial meets me where I'm at and takes me to a new place, using incremental, concrete, and practical examples to show me that React is a logical extension of JS in certain use cases.
Designers are visual people, so being able to see each step along the way and telling me why it's important is a really big deal. I have some projects now where I'm changing state quite a bit, and I can now see where React would be really useful. Designers also tend to get into the web coding stack from the front end first, so I think we end up thinking about coding a Web site in a really different way than back-end developers with a background in software engineering.
I feel as though the move from raw JS to JQuery is similar in significance to the move from JQuery to React. So in answer to your question, I would say a dev who learned React would be more appealing as a hire and as a colleague, and it'd be well worth the investment for any future career.
The same thing is true for jQuery -> React. If you're a front end designer who does some programming - you need to learn the DOM and CSS, jQuery is just a simple tool to leverage that more easily.
React is a fundamental change that requires a lot of relearning and more importantly the benefits are questionable unless you're dealing with the scenarios it was designed for. You need to have experience with existing tech (that is way more intuitive, like two way data binding) to see what problems it solves - that's not in the domain of a jquery programmer.
I also wouldn't call people who "just know jQuery" devs but rather designers who know how to code.
In all seriousness, I've already had to rewrite a codebase because an inexperienced programmer (less than 2 years professional) chose it for a use case that wasn't even appropriate, and he did a terrible job implementing it correctly. My team that took over wasn't happy.
If programmers didn't do stuff solely because it's cool, then that would have been a day back on that project.
(And yes, there are cases where React is a bad choice, like with said project)
jQuery works just fine at small enough scale. Once you out-scale jQuery you will have problems that won't be solved just by using a different view library - you need to understand software engineering - which is why everyone who actually uses reacts also uses things like Flux, etc.
My point is jQuery works for what it's used, getting people to switch to React seems like a fad because "the cool kids are doing it".
Novice programmers don't have the perspective to understand that the latest hot library may be old news in 6 months, and how the old adage of "hold a hammer and everything becomes a nail" can impact a project.
A year or so junior programmers figured out how to add Angular as a dependency into every single project whether it was needed or not, now people are teaching them how to do the same with React. The constant parade of new JS frameworks combined with the ease of package managers & compilers is creating a nightmare scenario when it comes to project bloat
In scenarios with complex interactions, something like Flux is desirable, however small web apps work fine with simple JSON REST APIs.
https://github.com/Wildhoney/ReactShadow
The only drawback is that it doesn't support custom events out of the box. Instead, you have to manually create event listeners on elements on mount. As far as I can tell, there's no reason why it couldn't in the future though; Web component adoption is so low right now that it just hasn't been something people have complained about.
React is pretty new, once it gets bigger it'll also follow along too.
Yes, obviously. My company uses it for this. Personally, I don't know if AngularJS is a better alternative moving forward because it has a bigger community and companies such as Microsoft are integrating it on Visual Studio.
(Sadly being downvoted for saying this)
React will keep getting bigger, and AngularJS has no answer to React Native which I find pretty revolutionary.
I said React Native is revolutionary. It's the first JS framework that lets you build native iOS and Android apps. Key word here being "native".
React itself was designed as a UI library, purely to be used as the "V" in an MVC app. It's like expecting D3.js to do your AJAX calls. Unless it's a full front-end framework, there's no point trying to do everything.
It basically just gives you a view engine and then you have the flexibility to select what other libraries you want to supplement the rest of the app components.
This differs from other frameworks like Angular where you have to "go all in" and don't have the flexibility so that if something major changes (like when the Angular team announced HUGE changes coming in 2.0) you might get stuck with something you don't like. In this way, it's easier to switch out a part of your app as opposed to having to completely rewrite something if you use a full framework like AngularJS.
The folks working on Angular 2 are looking at interop with React Native's native shell so that you can write native apps in Angular (2) as well.
Yes.
In the meantime since asking I also came across restful.js (github [1], blog [2]) - it's new, but looks like a good framework-neutral alternative, if a little heavy at 27K minimised/uncompressed.
Edit: Actually, fetch.js + es6-promise-min.js = 26K, so not much in it.
[1] https://github.com/marmelab/restful.js [2] http://marmelab.com/blog/2015/03/10/deal-easily-with-your-re...
Technically? No.
React doesn't include the direct code to main API calls. You're still going to need to make the 'API calls' 'yourself', whether with jQuery or raw XMLHttpRequest or whatever. React comes into play when you have the data and you're ready do actually do something with it.
There's also a library to hook up React views directly to a Firebase (real-time JSON streaming) backend: https://www.firebase.com/blog/2014-05-01-using-firebase-with...
With angular I can keep all my HTML in my HTML files. Is this normal or am I completely missing something?
http://courseweb.lis.illinois.edu/~hkim214/lis514/img/Dr_Seu...
My advice is to try it at least to the point where you've created a couple of components and rendered one inside the other. A component manages everything to do with how it works with props it's given and the state it manages, and how it renders is just another part of that concern.
One of the nice pros you get used to quite quickly is having your editor autocomplete event handler and data variable names, as they're all right there in the same file.
JSX is just sugar for React.createElement() function calls, the syntax of which otherwise gets quite unpleasant to write and maintain once you start nesting them to any degree (ask anyone who's used a DOM builder library for a complete app).
Once I started using React in practice though, it turned out to be pretty nice. It significantly reduces cognitive overhead when thinking about frontend elements. And if you're worried about your javascript file starting to look more like an HTML file, composition of JSX components helps break things up.
Even if I can't convince you that it's actually pretty nice, you can write React without using any JSX. Just use a live compiler http://facebook.github.io/react/jsx-compiler.html to translate any documentation into the vanilla JS equivalent.
Also i've never really gotten into all the string magic that angular templates use. ng-click="myEvent()", vs passing the event to the component as a property feels.
The Angular parser will go through the elements in the DOM and look for attributes it knows about like ng-click. When it finds ng-click, it will run the expression "myEvent()" on the controller's $scope.
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.
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.
In this case, you can split out that boilerplate into a separate, smaller component and reuse it inside as many other components as you need.
> By that logic we should be putting our data stores in the component, any translations required to internationalize the component, the database queries.
I respectfully disagree with your inference here - such functions can be abstracted and used by many components - in most cases there's no value in baking them directly into a component.
The exception to this is if the function is not abstract at all, makes no sense outside the context of the component, and therefore can't be reused. Then, it probably makes more sense to put it inside the component, rather than breaking it out into a separate file.
This is true of most if not all of the markup and styles used inside a component, which is why React encourages JSX and inline styles to be put directly inside the component as it's the only place they make sense, and the only place they'll be used. The markup, styles and component behaviour are intrinsically coupled, there is a lot of 1:1 referencing, and separating them out into separate files means you'll just be flicking between three files when working on a component, instead of one. Where there is 1:n referencing, well, that's when you should break your component into smaller, reusable pieces.
The reason like Knockout.js because all the magic happens in a standard data-bind attribute, no funky syntax or paradigm shifts required. A purely functional solution like React seems like it's good for making games. Beyond that, for most sites, I think it would be more work to use React for little to no gain.
However it has a few issues.
1. Wrapping everything in observables is a bit annoying. Subtle issues can arise here in there especially if using the mapping plugin (which you kind of have to, it makes the process bearable).
2. If you start to have a lot of bindings on a page (a few hundred) performance degrades rapidly and there is a ton of DOM thrashing. Part of the problem is that a binding places an event handler directly on the DOM element. But there is also the initial load "flicker"/DOM thrash which for a significant page can take a second or two.
3. There are lots of workarounds such as rate limited observables, etc... But these are applied individually and become very tedious. They do not solve the entire problem either.
React solves all 3 of these so I can see significant benefits there. I have not switched myself but am experimenting. I do think Flux, Stores, etc.. are very overkill and actually poor architecture. But thankfully there are many alternatives cropping up which are much better.
React.js seems like it could be a good core for something like those alternative frameworks that you mentioned popping up. Aurelia looks interesting to me, but I don't think it uses React by default.
http://apidock.com/rails/ActionView/Helpers/TextHelper/conca...
http://thepugautomatic.com/2013/06/helpers/
http://guides.rubyonrails.org/form_helpers.html
https://github.com/rails/rails/blob/dd7af2c413a06ea44e50abf0...
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.)
EDIT: As per usual, I forgot the link: https://github.com/dahjelle/Programming-Worksheets/blob/mast...