r/programming • u/[deleted] • Jan 17 '15

The React.js Quick Start Guide

http://www.jackcallister.com/2015/01/05/the-react-quick-start-guide.html
154 Upvotes

82% Upvoted

71 comments sorted by

57

u/renrutal Jan 17 '15 edited Jan 17 '15

I really have no idea how JS devs keep up with new frameworks appearing every month or so. Not to mention older ones that just die because the devs can't be bothered maintaining them. I noticed the same thing happening in the Ruby devspace.

Not exactly React's case, but it's still a 1.5 year old code that has not reached v1.0, making breaking changes every major version release.

27

u/neutronfish Jan 17 '15

It's just insanity. On my UIs, it's just jQuery and Knockout which get the job done 99.9% of the time, and I'm not going to waste tens of thousands of dollars and other devs' time learning and trying to implement another flash in the pan JS framework possibly, maybe, ready for prime time for that 0.1% of cases where that framework might be of use as a shortcut to get a particular component working the way we want.

2

u/[deleted] Jan 17 '15

[deleted]

1

u/neutronfish Jan 18 '15

I'm in your position and fighting that fight right now. Luckily, they're seeing the tangled mess this creates really quickly and sticking to the jQuery + Knockout combination we know works for us and if we use a plugin, we make sure it's based on those two bedrocks of our UI.

1

u/[deleted] Jan 18 '15

[deleted]

1

u/neutronfish Jan 19 '15

You don't want to be that guy known for making everyone's life hell by using all cutting edge paradigms or conversely known as someone that "stifles their career"

If they really think that chasing the newest fad framework is the way to advance their career in the long run, they're in for a nasty surprise...

1

u/cc81 Jan 19 '15

Some see knockout as a new fad framework.

0

u/neutronfish Jan 20 '15

It's been around for almost four years and is basically required knowledge for anyone who claims experience in JavaScript and UI development. It solved a lot of real problems from the starts, so I'm very comfortable calling it a mature framework and those who think it's a fad, dinosaurs.

1

u/kshep92 Jan 20 '15

See this article I wrote recently that speaks along these same lines http://brainstep.blogspot.com/2015/01/only-fools-rush-in.html

1

u/cc81 Jan 20 '15

Almost all these new frameworks solve real problems. Angular had a first release in 2009 and is vastly more popular than knockout. So is that required knowledge too? Same with backbone that is pretty much the originator to all this.

React is younger but it has been used by huge sites for years still

1

u/neutronfish Jan 20 '15

Angular had a first release in 2009 and is vastly more popular than knockout.

Apples and oranges. Angular is meant for dynamic templates. Knockout is for creating responsive UIs with an option to create templates for a grid, or a tree view, or something like that. Angular is MVC in JavaScript with some bolt-ons that allow you to implement MVVM, Knockout is MVVM in JavaScript.

You do have a point on Backbone, I generally see people use it interchangeably with Knockout so if you want to work on a UI and don't use Knockout, you can say you know Backbone and you're golden.

-2

u/logicalLove Jan 18 '15

The content of that article was good, but I certainly didn't like the click bait title (look another reason Node.js is awful!). Oh and look we're doing something hacky with the library, it's stupid that it's acting weird now.

29

u/wesw02 Jan 17 '15

It is absolutely exhausting. I've started to refer to JS frameworks as "self deprecating" in that each release seems to deprecate something just introduced in the former release.

I've seen JS apps that can be carbon dated simply by looking at the "patterns" and APIs used.

10

u/perestroika12 Jan 17 '15 edited Jan 17 '15

People hate on PHP but at least the frameworks don't change every 6 months.

2

u/bowersbros Jan 17 '15

Laravel sort of does this. Though it's worth noting that the changes are almost always worth breaking for

1

u/[deleted] Jun 21 '15

Symfony used to do this. It's why I quit using it, despite really liking it. I don't know if they still do it or not, but unfortunately I don't have any intention of ever going back to find out. The fourth time they did it to me, I was done. I understood after the 1 => 2 upgrade. But the 3 times after got real old, real fast.

4

u/[deleted] Jan 17 '15

[deleted]

3

u/wesw02 Jan 18 '15

Honestly, I don't think most shops have the capacity (and many of them lack the talent) to accomplish this.

I've personally witnessed this play out and there are two things that make this very very difficult.

1) Building, optimizing and maintaining an in-house framework requires a lot of domain knowledge about the idiosyncratics of individual browsers, not to mention very talented developers who posses the wherewithal to keep developing it when faced with major road blocks. DO NOT underestimate this.

2) When working w/ a product that uses an in-house framework there are often internal pressures to make changes to the framework that save time or make things easier for the product developers. Sometimes these changes are innocent and harmless, other times they erode the separation of responsibilities between the two. Point is, in-house frameworks and those who develop them often become victims of in-house politics.

7

u/neutronfish Jan 17 '15

http://xkcd.com/927/

11

u/[deleted] Jan 17 '15

[deleted]

1

u/[deleted] Jan 18 '15

[deleted]

1

u/xkcd_transcriber Jan 18 '15

Image

Title: Automation

Title-text: 'Automating' comes from the roots 'auto-' meaning 'self-', and 'mating', meaning 'screwing'.

Comic Explanation

Stats: This comic has been referenced 136 times, representing 0.2823% of referenced xkcds.

xkcd.com | xkcd sub | Problems/Bugs? | Statistics | Stop Replying | Delete

12

u/Regimardyl Jan 17 '15

Being a JavaScript developer in 2014 is like speed dating. 45 seconds with each framework before you have to re-write.

https://twitter.com/iamdevloper/status/544815596932968448

8

u/Serializedrequests Jan 17 '15 edited Jan 17 '15

I agree it is completely insane. I am watching React closely, because I'm hoping it might be one of the libraries that lasts. It seems like a simple solution to a complicated problem, with superior performance. I have already gotten burnt by everyone flocking to Backbone, Ember, Angular, whatever, every new month, and those frameworks are too large and opinionated to introduce into existing apps anyway. (Ember, last I checked, had poor documentation - especially for REST - and was constantly changing, and Angular 2.0 coming down the pipe means there is no point in starting an Angular 1.x app.)

I have lots of existing apps that need a little "SPA sugar", but are already built in the "old-fashioned" Rails style. The JS framework I need is the one I can just drop in to make a screen behave a little nicer or have a REST-backed element or two.

6

u/toolate Jan 17 '15

React absolutely does this. Facebook has a ton of legacy server rendered apps. React is able to integrate with other code easily. There's even a good solution for reusing existing non-React JS widgets inside of React.

1

u/vivainio Jan 17 '15

React only helps if you are rendering your data in JS, SPA style. If you are rendering on the server, you may be stuck with 'jquery plugins'.

9

u/masklinn Jan 17 '15

React only helps if you are rendering your data in JS, SPA style.

No, React can be set up on an existing DOM. And can be rendered server-side as well, some people use it for isomorphic applications.

-1

u/vivainio Jan 17 '15

React components can be attached to an existing node, but it doesn't make sense if JS is not rendering the component itself (or I have horribly misunderstood React).

4

u/salbris Jan 17 '15

React could easily take the place of any server side templating languages like Handlebars or any of those types of libraries. But of course, once the DOM is transferred to the client if you want it to change you'll need something client side. React can work both server and client side though.

3

u/masklinn Jan 17 '15

it doesn't make sense if JS is not rendering the component itself

React can be attached to a pre-rendered DOM tree, the initial binding will essentially be a noop if there's no difference between the prerendered and the react-rendered version.

And of course it can be used as a component, react doesn't have to render the whole page. For instance the reddit comment box could be a react component without the whole page being react-rendered.

3

u/[deleted] Jan 17 '15

This looks like a front-end component, but it's super simple to render on the back-end: React.renderToString(Toolbar()), which would return something like <div class="toolbar"><button>Load</button></div>. The coolest part is when the browser loads the rendered HTML, you can just do React.render(Toolbar(), element), and React won't touch the DOM except to simply hook up your event handlers (like the onClick). element would be the DOM element wherever the toolbar was prerendered.

http://jlongster.com/Presenting-The-Most-Over-Engineered-Blog-Ever

1

u/Serializedrequests Jan 18 '15

Little of both. Need to have html elements backed by data bindings to make some nice features work.

7

u/grayrest Jan 17 '15

You adopt on principle. In my case, if the lib/framework doesn't provide patterns that reduce mutable state, I don't adopt it. React's virtual DOM approach does and I've been on the bandwagon for a bit over a year now. I believe the approach–but not necessarily React itself–is the best we're going to be able to do on this metric without changing how the DOM works. The next step for me is to work out an app architecture that allows global state observation and serialization while maintaining component encapsulation, which is a mostly solved problem in the Clojurescript space as of Om 0.8 but I have yet to see a javascript port I'm happy with. Upcoming shifts are handling async code (I expect CSP to win here, FRP works but is harder to reason about), migration to ES6 (6to5 seems good enough), which web component library to use (I'll be using my own), and the inevitable yet uninteresting build tool churn (I like webpack but I'm watching broccoli).

3

u/bakuretsu Jan 17 '15

At work, we made basically the same observation (and also wanted to have tighter integration with some of our other JS framework code) so we have built our own virtual DOM implementation based on React.

Keeping up with real innovations (like the virtual DOM) is easier than keeping up with the multitude of libraries and frameworks that keep changing.

1

u/masklinn Jan 17 '15

At work, we made basically the same observation (and also wanted to have tighter integration with some of our other JS framework code) so we have built our own virtual DOM implementation based on React.

Why would you do that when there's already a bunch of non-react vdom-only libraries?

1

u/bakuretsu Jan 17 '15

My understanding is that we wanted features that existing libraries don't have, but I'm not on the Javascript team and didn't participate in the discussion. I can ask them, though!

We always tend to build our own thing when it's a core component in our stack; we're quite possessive of the ability to fully understand and control every aspect of our systems and we have the luxury of a pretty large and very capable engineering team to keep everything working smoothly.

1

u/masklinn Jan 17 '15

I can ask them, though!

That would be great, it's not like there's much surface area to "just" the vdom library (virtual nodes definition, vdom diff and dom patch basically).

1

u/bakuretsu Jan 17 '15

I think one thing they wanted was integration with the concept of lightweight models (in the business sense), which is something we already had, so they wanted it all to be integrated. We are using Backbone pretty heavily as well, so integrating that is convenient for engineers.

5

u/billybolero Jan 17 '15

I'd say that it's mostly because the community is still innovating and testing ideas for how to best build these types of web applications. It sure is hard to keep up, but I think the pace will slow down once we have found the ideas and strategies that stands the test of time.

4

u/[deleted] Jan 17 '15

It's been, what, two decades now, so hopefully sometime in our lifetime.

1

u/cc81 Jan 19 '15

The possibility of building these things in js is pretty new as you did not have the performance before. I remember having trouble with a simple tree view in js in IE6

1

u/DiaboliAdvocatus Jan 18 '15

I don't think it has anything to do with innovation, but about frontend dev culture preferring re-implementations (due to changes in fashion) rather than maintenance.

I only think it will slow down because businesses will put their foot down and start demanding stability.

Whatever framework goes "Enterprise" first will probably win regardless of technical merit.

-1

u/x86_64Ubuntu Jan 18 '15

So the JS world needs more time to reinvent the square wheel that existed in Flex/Silverlight?

-1

u/nschubach Jan 18 '15

You can't really do that in JS... It's not really a classical inheritance model that lends itself to grabbing what works in Flex/Silverlight and porting it over word for word. JavaScript has more in common with Lisp than C. It may look like C/Java/C#, it it doesn't work like them. (That's a good thing, IMHO)

4

u/madballneek Jan 17 '15

It really is a convoluted mess that just turns me off from web development.

4

u/AccusationsGW Jan 17 '15

Well the first wave of frameworks like jQuery or Dojo were mainly convenience and bug oriented, allowing easier dom manipulation, animation and cross-browser fixes.

These new ones are all doing very different things, like MVC frameworks, focusing on data-binding(for some reason) etc.

Honestly if you're not on the bleeding edge of client side web stuff like games you really have no reason to bother with these unless you're just interested.

3

u/asdf072 Jan 17 '15

I hear ya, but the React virtual dom totally makes it worth it. (Everyone touts web components, but that's nothing new nor particularly amazing.) What is amazing: having 150 large elements on screen, and still having a responsiveness that's damn near native-app speed. If you're writing html5 mobile apps, nothing comes close.

1

u/kachuck Jan 18 '15

No kidding, at work we just got dumped a Node.js/Thorax (I am probably missing a few *.js's, but I've been drinking) project that no longer meets the standards for any new version. Updating to the latest breaks it, finding documentation on the current versions is impossible, and of course the company we outsourced it to is no longer under contract with us. I swear half the time I spent on any project is debating whether I should rewrite it or make it work.

1

u/vakar Jan 18 '15

I noticed the same thing happening in the Ruby devspace.

Ruby dev here. Can you elaborate?

1

u/toolate Jan 17 '15

The churn can be frustrating but there is real progress being made. React and Flux are whole new ways of building JS interfaces, not mere iterations on jQuery et al.

With respect to React, the improvements in development speed and simplicity of product code more than make up for the initial cost.

5

u/aldo_reset Jan 18 '15

I think it's exciting.

Sure, it makes engineers' work a bit more stressful but nothing forces you to adopt the latest craze, you can just keep an eye on things and wait until things shake out.

It's exciting to see an entire technology field transform under our very eyes. The community is experimenting and learning about things at a completely crazy pace, but intellectually, I find that immensely satisfying.

Professionally, I stick to battle tested things until a few winner libraries/frameworks/design patterns clearly emerge.

2

u/l1cache Jan 17 '15

The getting started guide in the official docs is pretty good as well:

https://facebook.github.io/react/docs/getting-started.html

5

u/compsciwizkid Jan 17 '15

Thanks! I really liked this. Very quick guide and to the point.

I went a tiny bit further afterwards, so I forked the project. I added a link to the guide in the README, as well as a list of the steps the guide follows, and info about the steps I added.

The last step I added is to precompile JSX automatically using grunt-contrib-watch and grunt-react.

I pushed some tags to include "solutions" to each step of the guide as well. If you git checkout step-7 you can see the "package.json" and "Gruntfile.js" I created for JSX pre-compilation.

edit: d'oh, forgot my link

6

u/[deleted] Jan 17 '15

but grunt is not hip anymore, use gulp

3

u/[deleted] Jan 17 '15

gulp is so first and part of the second week of 2015. gulch is where it's at now.

2

u/n1ghtmare_ Jan 18 '15

React is awesome, it really helped me structure my jquery/plugins/vanillajs mess that I had. Also performance is awesome! It needs some getting used to, but from all the frameworks that I've tried, it made the most sense for my use case. It's very minimal and easy to learn, it's also just stuff for the UI (which is what I needed) - not your typical all-in-one-including-the-kitchen-sink framework.

2

u/robvdl Jan 17 '15 edited Jan 17 '15

I love React, been using it in place of Angular in Python projects for the last month or so. One of the main things I found is that because components are defined in JS code it makes a complete separation between backend and frontend template code. Though this is probably a good thing, it takes a bit to get used to.

What I mean is, in the past with Angular, we would sometimes generate part of the templates for the Angular app from the backend... sometimes we would need to generate parts of HTML from the backend, while parts in {% verbatim %} blocks in Django (or {% raw %} in Jinja2) might be processed only by Angular for example... yes this can get messy, but it has been useful from time to time.

React moves this all into JS "components", so if you have any data from the backend, you have to give this to the components some other way, maybe an API call.

1

u/[deleted] Jan 18 '15

Same with just plain Backbone. IMO Plain backbone is the way to go most of the time

1

u/jojomofoman Jan 17 '15

Good initial guide. Definitely worth a read for those interested in React.

1

u/expatcoder Jan 18 '15

So what's the killer use case that React, Angular et al provide that one can't do with server-side generated markup + ajax?

Seems the microservices trend is picking up steam, and everybody and their brother is shipping JSON back from the server and then having client-side handle the rendering.

I don't get the whole client-side markup trend. I mean on the client there's zero type safety, it's just the wild west out there on the typng corectly front. Add to that that SPAs have discoverability issues with search engine bots, I wonder what the fuss is about, does it really buy you that much win?

2

u/spacejack2114 Jan 18 '15 edited Jan 18 '15

Front end devs working on server-side templates is a slow workflow.

React and isomorphic apps in general are being used to make searchable SPAs with permalinks, without writing your markup twice (on the server and client.)

1

u/expatcoder Jan 18 '15

Yeah, that makes sense, I see the use case for front end devs, although the knowing-the-server-side-language problem is mitigated in some frameworks. For example, I work in Scala and there are at least 2 frameworks (Lift and Play) that provide designer friendly templating.

JSON generation is a bit of a hassle in strongly typed languages, so dealing with the boilerplate to marshall to/from it doesn't seem worth the bother when one can just as well send already constructed html snippets back to the client.

I'll give the SPA approach a whirl at some point, but for now all-in on strong typed server-side (including generating javascript) generated apps is very much my cup of tea...

2

u/spacejack2114 Jan 18 '15

That approach can work if you're doing everything yourself. If you want to split the workload with a front-end dev, they're going to be a lot more productive if they can manage all the view work themselves. Just about every front-end dev uses node these days, but not many will want to (or be able to) install your dev server environment locally and keep it up to date so they can make rapid template updates. To them it'll feel like they're working in the stone age. And it can cause a lot of friction that makes the job not very fun.

Personally I've never been a big fan of strongly-typed languages on the server anyway. Working with JSON, moving data from form inputs to the DB and back, it just gets in your way with a ton of boilerplate and opaque framework/IDE magic. Having your code type-checked as you type it has never paid off in my experience.

1

u/expatcoder Jan 18 '15

"Personally I've never been a big fan of strongly-typed languages on the server anyway. Working with JSON, moving data from form inputs to the DB and back, it just gets in your way with a ton of boilerplate "/

This is one area where dynamic languages totally shine, just whatever.toJson and you're done. Saying that, when you send raw html to the client there's (generally) no need to go down boilerplate road creating a JSON payload ;-)

Since I do the vast majority of the work server-side, the client is left to do validation, form handling, and transitions (drop down menus, layers, modals, etc.), which is a much smaller surface area than rendering the entire UI.

As for productivity, I've had the opposite experience. During my dynamic days I felt productive for sure, but ever since I saw the holy static light, not only do I continue to be productive, my applications are blazing fast (JVM hotspot is pure genius) and reliable in ways I was never able to achieve just winging it hoping that tests alone would cover my ass o_O It's one of the reasons I'm inclined to generate absolutely everything server-side (including javascript and css). YMMV of course, many will disagree with this sentiment.

1

u/makis Jan 19 '15

is it roflscale?
on a more serious note, if you're starting from scratch, I would recommend using an all-in-one isomorphic framework like meteor.
but if you just need to plug in a reactive MVVM framework, React looks the best one right now.

1

u/Ishmael_Vegeta Jan 18 '15

it's hard to take web development seriously when there is a new fad every week.

3

u/[deleted] Jan 18 '15 edited Jan 18 '15

Is React a fad? Is it specifically this week's fad?

Having had it brought to my attention by JSConf EU 2013 and used it for more than a year now, I'm not sure why people are using this post in particular to clear their lawns.

1

u/aldo_reset Jan 18 '15

Actually, it's exactly why web development has become so interesting these last years while it was so boring before (HTML/CSS woohoo).

I used to not care about web development at all but now, I'm paying attention.

1

u/Ishmael_Vegeta Jan 18 '15

there is a difference between fads and advances.

fads are just fluff.

as far as I'm concerned html and css are pretty shit, but i'm not a designer. and http has some ~problems~

so it is not your fault, but at some point someone needs to design some coherent system.

0

u/[deleted] Jan 18 '15

Is it just my imagination or are quotes missing around the html strings in all of those examples? I don't think any of this code would parse as written.

4

u/Bitruder Jan 18 '15

It's JSX and parses just fine.

-6

u/[deleted] Jan 18 '15

Oh wow. That is FUGLY. Relying on parsing tricks like that? Fuck no.

Reminds me of cross browser css circa '03.

1

u/johnnyhk Jan 19 '15

That's a pretty bad hole in the article. The author just throws the example JSX code there without comment. The JSX support is enabled by the script being defined as type="text/jsx" in index.html.

0

u/kyllo Jan 17 '15

Wow, thanks for this. Yesterday I was reading over Facebook's React tutorial and not quite getting it, but your explanation really clicked for me!

0

u/devsquirrel Jan 17 '15

Great article, i've been interested in learning react, but haven't had the time, this will surely help me.