React.js Introduction for People Who Know Just Enough JQuery

http://reactfordesigners.com/labs/reactjs-introduction-for-people-who-know-just-enough-jquery-to-get-by/

by chibicode • 11 years ago

614 230 11 years ago

reactfordesigners.com

jozan• 11 years ago

This is neat! Thanks for sharing.

chibicode16• 11 years ago

Thank you for reading!

iamflimflam12• 11 years ago

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

chibicode16• 11 years ago

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

iamflimflam12• 11 years ago

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

insin3• 11 years ago

The SurviveJS book is a good reference for this: http://survivejs.com/webpack_react/

chibicode16• 11 years ago

I'll add a link to it :)

TheAceOfHearts• 11 years ago

Not a walkthrough or guide, but I setup a boiletplate [0] that covers all your bases for development, production, and testing environments.

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

tracker12• 11 years ago

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

chibicode16• 11 years ago

Yup, React does one thing, does it right, and does the right thing :)

DigitalSea• 11 years ago

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.

tracker12• 11 years ago

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.

radiospiel• 11 years ago

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.

chibicode16• 11 years ago

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

aprdm• 11 years ago

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

Cheers

chibicode16• 11 years ago

Awesome :) Glad to hear that!

zamalek2• 11 years ago

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

Good work.

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

chibicode16• 11 years ago

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

DanSmooth• 11 years ago

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

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

hodwik3• 11 years ago

That's really funny, I'm always lamenting that I can't find tutorials as nice as the golang tour for other languages.

zamalek2• 11 years ago

I find the prose format nicer because it's easier to keep going, but the Go REPL has more information density. Guess it comes down the preference.

toxickg• 11 years ago

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

chibicode16• 11 years ago

Thank you :) !

sancha_2• 11 years ago

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.

chibicode16• 11 years ago

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

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

ases• 11 years ago

I'm getting this issue as well. Using Firefox 39 on OS X.

sancha_2• 11 years ago

Firefox on OSX, version 39.

falcolas• 11 years ago

Safari, OSX

heyalexej• 11 years ago

Same here [1].

    $ lsb_release -a
    No LSB modules are available.
    Distributor ID:	Ubuntu
    Description:	Ubuntu 14.10
    Release:	14.10
    Codename:	utopic

    $ google-chrome --version
    Google Chrome 43.0.2357.132

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

pvdebbe• 11 years ago

Same here, Firefox 38 on Lubuntu 12.04

philliphaydon• 11 years ago

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

Thanks.

chibicode16• 11 years ago

Thank you :) Totally agree, I knew Angular coming into React and it threw me off quite a bit as well.

noir_lord• 11 years ago

Agreed, I've built some pretty big and complex UI's with Knockout.js and this was an excellent guide into something else.

Really well written as well.

WorldWideWayne3• 11 years ago

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.

woah3• 11 years ago

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.

orheep• 11 years ago

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

http://pastebin.com/wbGZZs7U

chibicode16• 11 years ago

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.

ups101• 11 years ago

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.

SlashmanX• 11 years ago

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.

jarnix• 11 years ago

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

arenaninja• 11 years ago

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"

pjmlp• 11 years ago

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

It was a nice overview of React to me.

rashthedude2• 11 years ago

Beautiful article man.

ifdefdebug• 11 years ago

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

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

bbarn• 11 years ago

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.

BinaryIdiot2• 11 years ago

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.

jmkni• 11 years ago

Waow that sucks, they don't even update the URL with anchor links!

radnor• 11 years ago

It's a bug with JSBin and/or the browser. https://github.com/jsbin/jsbin/issues/2464

pkhagah• 11 years ago

Not really justifying history modification. But, if don't know, you can long click back button and press some random page in history stack to go to.

Omnipresent2• 11 years ago

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

chibicode16• 11 years ago

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

k__2• 11 years ago

Good article. Needed it two weeks ago :D

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

Grue3• 11 years ago

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

jon-wood• 11 years ago

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.

wangii• 11 years ago

I had exactly same feeling when I first saw it in 1 min: it's ugly and why the hell folks get excited by integrating template into javascript?

Please keep reading! It's really more than that! I wasted 2 years by not spending 20 more mins.

akhilcacharya• 11 years ago

Wow, this is exactly what I needed.

moonchrome5• 11 years ago

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

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

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

wil421• 11 years ago

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.

moonchrome5• 11 years ago

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.

rux• 11 years ago

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.

moonchrome5• 11 years ago

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.

orthoganol4• 11 years ago

What?? How dare you question React?

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.

sgarman• 11 years ago

This has nothing to do with react and everything to do with the implementation.

emodendroket5• 11 years ago

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.

tjsix• 11 years ago

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.

moonchrome5• 11 years ago

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

simonw• 11 years ago

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.

rwhitman• 11 years ago

100% agree with your point.

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

prapam2• 11 years ago

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.

Omnipresent2• 11 years ago

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?

liamzebedee• 11 years ago

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.

ergo14• 11 years ago

I'm more interested to see if polymer/x-tag/webcomponents will replace react/angular/other stuff.

vcarl2• 11 years ago

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.

pcr04• 11 years ago

AngularJS already has third-party libraries for polymer/webcomponents, and from what I've heard, they're integrating it more solidly in Angular 2.0

React is pretty new, once it gets bigger it'll also follow along too.

wslh2• 11 years ago

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.

(Sadly being downvoted for saying this)

pcr04• 11 years ago

I've read through the docs and they basically use JQuery for AJAX calls. Is that what you were referring to?

React will keep getting bigger, and AngularJS has no answer to React Native which I find pretty revolutionary.

applecore3• 11 years ago

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.

tptacek• 11 years ago

I can't imagine using React and Knockout in the same project.

scoot2• 11 years ago

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?

madeofpalk• 11 years ago

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

amk_• 11 years ago

I found this tutorial series to be pretty good, demoing React with Ampersand as the model/controller: http://learn.humanjavascript.com/react-ampersand/introductio...

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

paaaaaaaaaa• 11 years ago

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?

mandazi• 11 years ago

I too find that unusual. I feel it's hard to maintain the HTML when it's int he JS.

zecho• 11 years ago

This is a good tutorial for people who think the React way is weird.

http://courseweb.lis.illinois.edu/~hkim214/lis514/img/Dr_Seu...

revskill• 11 years ago

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

insin3• 11 years ago

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

moron4hire• 11 years ago

Can we really call it syntactic sugar when it leaves a bitter taste in your mouth?

lojack• 11 years ago

At first I was turned off by this as well.

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.

agmcleod• 11 years ago

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.

gordonzhu• 11 years ago

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.

andybak• 11 years ago

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.

marknutter7• 11 years ago

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.

WorldWideWayne3• 11 years ago

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.

stephenhuey• 11 years ago

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.

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

FloNeu• 11 years ago

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

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

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

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

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

starikovs• 11 years ago

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

dahjelle2• 11 years ago

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

EDIT: As per usual, I forgot the link: https://github.com/dahjelle/Programming-Worksheets/blob/mast...

thirdtruck2• 11 years ago

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

dahjelle2• 11 years ago

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

vezzy-fnord6• 11 years ago

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

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

xixixao5• 11 years ago

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

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

vezzy-fnord6• 11 years ago

Are they pure? I don't think JS has any way to guarantee referential transparency, though of course the use of a virtual DOM can mitigate side effects by having well-defined behavior.

Furthermore, the input-process-output model can hardly warrant being called "functional" in of itself, unless you really want to overload the term.

The React way of independent handlers that trigger events which incrementally calculate state and update views, is, in fact, quite similar to how Smalltalk UI paradigms work, right down to the installation of an event handler resembling a message send operation.

If you don't believe me, check out the Morphic framework that Self uses to implement its environment UI. The similarities are striking: http://handbook.selflanguage.org/current/morphic.html

shostack• 11 years ago

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

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

barrkel2• 11 years ago

Before React: to make a transition, let's change this, this and then that, mutating state on every step

That's nonsense. There have been data binding frameworks used for well over a decade in JS development - I know I wrote one in the early 2000s. You can't write a decently sized app in JS without developing something like data binding, unless you love busywork and bugs, or have zero prior experience of what came before in GUI frameworks.

Data binding is designed exactly to prevent the need to explicitly mutate all the views at every point that the model can change. Instead you write bindings that project the model into the view, and make the model reactive, so that changes to it propagate automatically. It's the same in any decently sized Backbone app - that's why the Collection and Model give you all these events.

What's new in React is the idea of cheaply creating a virtual DOM and extracting a set of diffs from it that can then be applied to the real DOM. I did something vaguely similar, again in the early 2000s, but the motive then was to reduce the amount of data on the wire (the server had a data-bound model of what was displayed on screen, but only sent diffs back to the client). It's a neat idea and an excellent implementation, but it's not original or groundbreaking.

aggronn3• 11 years ago

unless what web devs had before was really that horrible

As a big fan of react, I think that this isn't really a fair thing to say. I feel as though this statement implies that front end dev is not complex and therefore it surprises you that there is room for significant improvement. I'm sure that's not what you were thinking, but really, building complex imperative UIs with state can be very difficult, and react does represent a new step in the paradigm shift away from imperative development. Whether React is the future or not, components and composition are here to stay, and I think a increasingly large portion of the community is interested in writing web applications with immutability--all of which suites flux (and react) very well, and does not suite jquery very well.

React doesn't enable anything that you simply couldn't do with jquery and backbone, but it does make a lot of it way easier and reduces overall complexity by a ton, especially if you're developing with component structure and immutability in mind.

wrsh073• 11 years ago

It's considered "functional style" because react is a functional reactive programming framework.

This is about more than just managing state.

If you're not familiar with FRP, then I think learning more about the theoretical side might help clarify why everyone is describing react as functional.

vezzy-fnord6• 11 years ago

I am familiar with FRP.

I have never seen React described as FRP, and a Google search for "React FRP" confirms that this is a heterodox belief and in fact it is you who might need to learn more.

jamra2• 11 years ago

I think that the reverence of current frameworks is a response to the faults of the previous framework that was revered.

We started with JQuery. It was fast and had a simple API. People started to learn JQuery more than they learned Javascript. You even had Stack Overflow answers that nudged people away from Javascript stating the robustness of JQuery's libraries (specifically how it worked the same on every browser).

Then, we realized that we did not want to set up our events as one offs. The result was very spaghetti code. Backbone came out of this. It was light and allowed us to modularize our code. However, it didn't really give enough structure so we switched to Angular. Angular was the holy grail. It did everything for us. Events automatically propagated state changes to our objects and automatically redrew our view afterwards. We didn't have to think anymore. It did the thinking for us.

Little by little, we started to realize that when you outsource your thinking to your framework, you end up getting stuck in crevices that your framework hasn't anticipated. In Angular, it's difficult to share state between controllers. It's outstandingly slow in that it redraws far too often. The thing that I personally was most sore about was the fact that Angular, similarly to JQuery became the new Javascript. Instead of learning how Javascript works, you needed to learn how to use Angular. This means that you couldn't just port in good Javascript code directly. You needed an Angular directive. Try using a simple charting library such as HighCharts. The examples don't work as is. You need to use the Angular version. It gets messy and all that modularization starts to work against you. It works against you because you don't have control over your javascript.

Here comes React. It takes a step back from the hand holding of Angular and just handles the rendering. You can design your Javascript classes and functions as you see fit. If you need to port in Highcharts, go for it. You can use the JQuery plugin if it suits you. All React really does is handle the rendering and re-rendering of your dynamic content on screen. It will also allow you to propagate events that will change the state of your objects, but does not do so in the same way Angular did. It gives you more granular control.

I suggest you try it out. The JSX syntax might throw you off at first, but don't give up. It's necessary for how React obtains its amazing speed. If you're just getting started, don't worry about the difference between Shadow and Virtual DOM.

thoman235• 11 years ago

It absolutely is not difficult to share state across Angular controllers. Services work great for this. I also dispute that you are too far removed from "vanilla" Javascript when using Angular. I recently integrated some externally written d3 javascript code and it works as expected without forcing a conversion to "the Angular way". Finally, I certainly dispute that Angular is too slow. Our Investmynd app has a fairly data and interaction heavy front end, and its performance is quite snappy if I do say so myself. :)

Now what I do think is true is that Angular is a fairly complicated beast, which when combined with the poor standard documentation, makes it a non-trivial endeavor to learn and use properly.

curiousjorge• 11 years ago

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

peacemaker• 11 years ago

Nope, you're not the only one I agree completely. I'm tired of what seems like an endless supply of new, mega-hyped frameworks that seem to provide only marginal improvements.

I'll take the time to learn something new when it is truly groundbreaking but until then I care more about the end product than what was used to make it.

BinaryIdiot2• 11 years ago

There are dozens of us! Dozens!

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

thoman235• 11 years ago

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

ryanSrich• 11 years ago

This is why I've implemented a prototyping framework at Catalyze that's built with Angular, the same framework we use on the production front-end.

The flow typically looks like this:

1. Create conceptual wireframes

2. Build static UI components (typically in sketch)

    - This step helps us define the look and feel of the product before jumping into code. However these are not full page mockups. It's more like an internal UI kit, and for the most part, it's fairly standard across products. So we don't have to update it often.

3. Build the styleguide from the UI kit in Sass (within the framework)

    - Again, this is fairly standard so it's mostly templatized. We have an internal UI styleguide that's built already. So most of the changes per product are minimal (they're mostly small tweaks to give each product more character).

4. Build the prototype (within the framework)

    - Since we use a template for each new prototype things like routing and more complex Angular concepts are already set up. Because of this designers aren't forced to approach the steep part of the hockey stick. They can stick to the view layer.

nsomaru• 11 years ago

Do you have an example of a large web application that uses just jQuery and tries to achieve single-page-application type UI?

I ask because I'm a backend (Django) dev looking at upping my frontend chops (having previously used jQuery and ajax to glue things here and there), and I'm overwhelmed by the choice of frontend frameworks at the moment. I'd love to see how a big jQuery project is set up.

Particularly terrified of making a time investment and finding out that my chosen framework is no longer the hotness of the week. Because, support and community and stable API's count.

Chris_Newton2• 11 years ago

One project that I work on has a non-trivial front-end (it’s around 50K lines of code) that has been successfully maintained for quite a few years now. It predates all the current trendy JS frameworks becoming popular, and HTML5 for that matter, so instead it uses jQuery and jQuery UI for the basics, along with a Java applet for some graphical aspects.

Based on that experience, I smile a little when I see people claiming that you can’t build significant web apps without a modern framework. Of course you can. The architecture for the app I mentioned has something close to a traditional MVC structure, uses a simple observer system for keeping everything in sync, and generally follows good modular design practices. Nothing about writing code for a web front end magically breaks all the UI ideas we’ve been using successfully in other environments for decades, and people have used those techniques to build UIs vastly more complicated than any web app ever written.

That all said, it’s also true that as the interactions between different parts of models and the rendering of views becomes more complicated in a UI, writing manual code to update the DOM via jQuery becomes tedious. I thought this article summed up the problem quite nicely with the code snippets and diagrams showing potentially SxR relationships between state and rendering when you manually and directly update the latter, compared with S+R relationships when you isolate each side with a good architecture.

So, I’d say the more interesting question if you’re building a not-small web app is whether you are better off building your own architecture or reusing someone else’s. That has the same trade-offs as any other framework decisions in programming; again there is nothing special about writing a web-based front-end really. On the plus side for a comprehensive framework, you get a lot of basic things much quicker than writing them yourself, and the popular frameworks have huge ecosystems built around them so a lot of not-so-basic things can be had relatively easily as well if you need them. On the minus side, in practice you will forever be constrained to work as the frameworks want, which can become a heavy burden later on if you do need to do things that aren’t a perfect fit, and you are locked into external dependencies with uncertain long-term support.

Something I find interesting about React is that although it’s often compared with big front-end frameworks like Angular, it’s really closer to a library than a framework. Fundamentally, you use React to do exactly one job: manage the rendering and events within a specific part of the DOM. It’s agnostic about where any underlying state comes from, what triggers updates to that state, what you’re doing in response to any events, or what you’re doing anywhere else in the DOM. The entire API for React doesn’t quite fit on a single screen, but a minimal working example only depends on three functions that feature in React’s defined interfaces, and even in real production code you probably won’t use more than a handful.

So if you’re the kind of developer who is concerned about bloat and dependencies but also wants to use good tools instead of reinventing the wheel, a library like React is probably a reasonable compromise between retaining control and long-term flexibility in your code but also automating things you really would waste quite a bit of time on otherwise. I suspect this balance is the main reason why it seems to attract favourable comments from a variety of developers, including those who generally don’t like the heavier frameworks and all that comes with buying into them.

Just by way of completeness, probably the most controversial aspect of React is the way it winds up with its version of HTML templates being embedded directly within the JS code (with some optional but convenient syntax that a preprocessor turns into real JavaScript). You aren’t likely to be getting one person/team designing your mark-up and styling and then having a separate person/team implementing your JS coding if you use React. In this respect it does also come with a degree of lock-in, because transferring those mark-up/template assets to another rendering library or framework later would be a chore. However, that’s somewhat true for most other template-rendering tools you might use as well, because they all tend have their own syntactic quirks, so I’m not sure it’s really worse than other reasonable choices you might make.

So in summary, you certainly can build web apps using manual, direct DOM manipulation via jQuery and the like, but you will also wind up inventing much the same kind of tools that many of these frameworks provide to a degree. There is a balance to be struck between retaining full control and flexibility vs. using good tools, just like any other programming with libraries and frameworks. As for React specifically, it really sits closer to the library end of the spectrum than a lot of modern JS frameworks, so if you do want a modern tool to help with rendering and managing events in your DOM but don’t like the big framework lock-in, it’s probably worth a little of your time to investigate whether it’s a good choice for your project.

dntrkv• 11 years ago

That is pretty much where every frontend dev starts out and then quickly realizes that as your codebase grows and you have different types of data and events firing back and forth, things get unwieldy fast. I'm sure you think your 4k lines of functions across however many files works for you, but I think if you really take the time to learn one of the good JS frameworks, you will be amazed on how much cleaner and robust your code will become.

downboy• 11 years ago

Agreed, but every 2nd job ad requires knowledge of some new framework on the block. I feel like I need to stay current to be employable.

Nemcue2• 11 years ago

Sure you can be productive as a single developer. The problem is when you're handed a project from another single developer-project, and the project is a hot mess of spaghetti jQuery where business logic is intertwined with DOM manipulation. It's basically impossible to work with unless you've created the code yourself.

wrsh073• 11 years ago

I'm sure this can get a lot messy [sic] with more than one developer ...

Frameworks are for programmers who must collaborate.

hiou• 11 years ago

I think part of it has to do with the fact that web development is a very large and diverse field. It's very possible that the types of projects you work on do not require a different approach. For example a web application with a large about of UI elements. Or very specific client requirements. Or a continuous cycle of iterations over time. Or a common structure for a team.

Indeed the old web dev write once, pass it to the client and never see it again has quite a bit of difference in requirements to the large scale robust web application that needs to be able to survive a long period of iteration and maintenance.

michaelbuddy3• 11 years ago

I haven't gone through this page yet, but thank you for at least the attempt at reaching somebody in my state of affairs. Front End work is very hard. The front end design & what I would call the back-end front-end disciplines are supposed to meld together according to job postings and over-zealous recruiters, but it's a good deal more complex than I have been willing to put up with, mostly because of the materials to get started and the unintuitive tools that people who know what they are doing swear by.

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

thirdtruck2• 11 years ago

I feel your pain. Job expectations for front-end work (and, no doubt, other tech areas) have grown terribly incoherent. It seems like a lot of companies expect new hires to train themselves into unicorns on their current employer's time, when they could just hire someone now and give them a decent amount of time to ramp up instead.

michaelbuddy3• 11 years ago

I think for the needs of front end, the recruiting world would be better off targeting back end people heavy programmers, maybe .net or java and their migration to the front end frameworks will be much easier than the designers will be. It sounds awesome for a designer to pick up javascript and just run with it, but I personally see a pretty thick wall between focusing on design, graphics, presentation and then solving all the programming problems to go with it. Again personal experience, it's been easier for me to shut off the valve of code completely, so I'm not distracted by consequences of how it will be built. I know that sounds counter intuitive but just knowing some of the avid javascripters, those who can build apps with it, they don't really have the ability to get out of that mode to design something, they are always living the framework. They will make something nice, but alone their work rarely surpasses the level of beauty or refinement of a really good designer artist.

Yes I know those hybrids exist, but unfortunately there aren't nearly enough of them to fill all the positions. Not only that, but I'd argue that a lot of them who are hybrids, you're not going to get their best work from both areas if they are expected to deliver from both disciplines on projects. Not on the deadlines that employers will set at least.

And I suspect a similar problem exists in actual building architecture. Yeah some building designers are good at accomodating for all the variables of planning codes, but they aren't going to be (nearly as often) fantastic at aesthetics that somebody who works outside those constraints might be capable of. There's a lot of value in designing first, then put those styles of thinking together (designers and architects) separate people and from that point later in the process of creation you start solving the challenges like plumbing codes, metallurgy afterwards. Part of this is me complaining, but it's my attempt at experience of always being a crossover person and how you never really feel like you're honing a craft, you just feel like you're being left behind and not properly cultivating what you enjoy most.

applecore3• 11 years ago

What do you mean? This:

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

...is clearly so much more logical than:

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

Source: https://www.airpair.com/angularjs/posts/angular-vs-react-the...

garry• 11 years ago

This obscures React's main strength, which is making it so that you don't have to worry about edge case states. In complex UI's, this is the #1 source of bugs.

cdelsolar• 11 years ago

Yes it is. What is {{item}}? Where did it come from?

vvpan• 11 years ago

That is a terrible comparison.

mrev19• 11 years ago

Besides incorrectly quoting the example at the cited link and being a deceptive/incomplete comparison, what does this even have to do with the op?

munro• 11 years ago

If you like Angular's style you can use react-templates [1], most people just prefer the React way. In theory there shouldn't be any overhead, but since in JavaScript abstractions aren't free you're going to pay some price.

Also the angular equivalent would be

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

And the react-templates equivalent would be

    <ul><li rt-repeat="item in this.state.items">{item}</li></ul>

[1] http://wix.github.io/react-templates/

oinksoft• 11 years ago

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

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

vs. the Angular version:

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

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

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

ricardobeat• 11 years ago

These frameworks are not actually created by back-end programmers, clientside code has become as complex and specialized (sometimes more) than the server in the past decade.

But there is still room for good designers who code; plenty of research, user testing and prototyping to be done before getting down the tech rabbit hole. A good team is multi-disciplinary and not necessarily composed of 'unicorns' only.

sgrove• 11 years ago

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

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

blhack• 11 years ago

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

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

joshcanhelp• 11 years ago

My $0.02 ...

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

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

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

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

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

wging• 11 years ago

There are two arguments that could be made.

1: you can do without jquery, and therefore you should. if all you need is $('#my_id') then it's overkill and it's better to save on download speed by leaving jquery out. See http://youmightnotneedjquery.com/

That said, jquery is a powerful tool and it's widely used for a reason.

2: unrestrained use of jquery, if it's your only tool, can lead to code that is hard to understand, and easy to get wrong. if any part of your code can modify any part of your page, then it is a good idea to retreat from that and be careful/organized about what you do, and when/where you do it. that organization is what JS frameworks try to help with.

you may or may not find your life is improved by such frameworks, depending on what you're doing.

Raphmedia• 11 years ago

Nothing at all. Use jQuery. If things get unwieldy, split your code into multiple files, then merge & minify them with grunt or gulp.

jayhuang• 11 years ago

There's nothing wrong with jQuery. Aside from extending and abstracting parts of JS and DOM traversal, it also removes many of the complexities with cross-browser support, especially with dated browsers.

The biggest issue is when you take something like jQuery and try to have a multi member team working on a significantly complex and large application. It quickly gets out of hand, messy, and increasingly difficult to maintain. This is without taking into consideration the issues that arise if the developers on the team don't have a basic grasp of how to write jQuery code that still performs well with large amounts of actions/DOM manipulation.

Many interviews for front-end positions also want to make sure you don't only know jQuery, but at least have some grasp on DOM traversal/manipulation without crutches like jQuery.

A lot of the bashing though, is really just from people with a superiority complex instead of logical reasoning. Or it's just people who repeat what they hear, kind of like one of the largest hate trains of all: PHP. Kind of like the story about the monkeys, bananas, and a ladder: http://www.wisdompills.com/2014/05/28/the-famous-social-expe...

hit8run2• 11 years ago

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

eastbayjake2• 11 years ago

I'm totally with you that jQuery is a crutch for a lot of devs, but it's also the easiest way to ensure backwards compatibility for IE 6+. If you have enterprise customers who refuse to upgrade it's probably the most stable way to support them while leveraging the power of modern browsers for enlightened users who have them.

hit8run2• 11 years ago

Good that you mention this point. This is for me the main reason to use jQuery in a project: backwards compatibility. I am gladly in the position where I make my own business decisions and so I choose which browsers I want to support. That said I totally refuse to support super-old browsers like IE6. I even refuse to support IE9. If someone has trouble using a site built on modern standards: Go get a modern browser. If it looks shitty on your old IE6 then don't blame me.

digitalsushi• 11 years ago

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

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

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

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

eastbayjake2• 11 years ago

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

hive_mind• 11 years ago

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

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

sergiotapia• 11 years ago

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

rashthedude2• 11 years ago

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

marcamillion2• 11 years ago

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

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

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

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

Anyone know of any such thing?

boundlessdreamz2• 11 years ago

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

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

The JS file shows how to organize javascript code - https://github.com/tastejs/todomvc/blob/gh-pages/examples/jq...

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

1. https://gist.github.com/danielgtaylor/0b60c2ed1f069f118562

2. http://justicen.com/#/posts/74046fea9a4c61477db9

marcamillion2• 11 years ago

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

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

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

React.js Introduction for People Who Know Just Enough JQuery

Related Stories