15 ms·

Removing User Interface Complexity, or Why React is Awesome

632 points by jlongster 12y ago

derwildemomo 12y ago
As a recommendation to the author, it would make sense to show the example/demo area the whole time, not only once I scroll down. It confused me. A lot.
- joshstrange 12y ago
  Agreed, I really like the demo area but it's a bit of a shock when it first shows up.
  - jlongster 12y ago
    Heh, it's been mixed reactions. I will probably tweak the initial experience, but will need some time because I can't leave it open on load because it blocks the header.
    - outworlder 12y ago
      I thought it was nifty. The shocking aspect might just be the big layout change. Perhaps a notification ("Check out the demo") so the user has to click it to enable the side pane, and then its business as usual.
      - cnp 12y ago
        I liked the layout as well. One thing I would change would be to make the code area wider than the demo area, as some of your lines wrap, where the demo area rarely needs a line break.
    - joaren 12y ago
      It's a pretty crappy experience. I'm reading an article, suddenly the text decides to move left for 'no good reason' to create a narrow but empty sidebar. WTF? I don't like reading things on the left side of my monitor, so I make the window wider to try and put the text back in the middle. Except now the demo area gets even wider (why? you don't use it for anything but tiny things?). As I scroll, the various iframe loads create annoying jank, and to top it off, there's a bug at the end of the post where it moves horizontally for no good reason. If you're going to do stuff like this, you need to polish it waaay better. This reminds me of the UI animations in the new Firefox. A good idea ruined by implementation, would've been better to leave them out.
  - ErikRogneby 12y ago
    Sometimes a shock is good. I took it as, "Hey, this page just gained new abilities." Then I clicked and moused over the square and the triangle to see what they were about.
  - scotty79 12y ago
    That demo area sliding out actually caused me to actually read the article. I was just about to close it with "meh, react"
- johnlbevan2 12y ago
  Agreed 100% Desired Reaction: Oh cool, a demo popped up just when it was needed. My Reaction: Huh? Ugh, that's annoying. Wow, and I scroll back up and it moves again; I didn't ask for that either.
roycehaynes 12y ago
Great post. I recently started a project using reactjs, and I have nothing but good things to say. The unidirectional data flow, the declarative nature, and the virtual DOM makes it powerful and very easy to like. The best resource is to follow the tutorial (link below). The tutorial explains everything you may have a question about when comparing it to Backbone, Angular, or Ember. http://facebook.github.io/react/docs/tutorial.html http://facebook.github.io/react/docs/tutorial.html I also found the IRC channel to be very, very helpful. The only downside is that you still have to rely on other tools to make a true SPA like routing.
- roycehaynes 12y ago
  I found this blog post to be very useful on how to leverage Backbone.Route with Reactjs. https://medium.com/react-tutorials/c00be0cf1592 https://medium.com/react-tutorials/c00be0cf1592
NathanKP 12y ago
I really like the core concepts of React, especially the way it is designed to help you organize your code into reusable components. I think the key to making React take off is building a centralized repository for components that are open source. Then building your webapp would be as easy as importing the components you need: bower install react-navbar bower install react-signup-form bower install react-sso-signin-form I think this is definitely the future of how front end web development will be one day.
- colinramsay 12y ago
  Surely this doesn't have anything to do with react though? Bower[1] or Component [2] will do this. [1] http://bower.io/ http://bower.io/ [2] http://component.io/ http://component.io/ edit: the parent comment originally referenced a theoretical `react` command and didn't mention bower, which is why I brought it up.
  - rjknight 12y ago
    Bower and component are more like package managers. GP is talking about a library of re-usable user interface components. Unfortunately, my best attempt at an analogy is Visual Basic controls, which might not be a great precedent, but the idea itself is a good one.
    - colinramsay 12y ago
      Well they just edited their initial post to specifically use a `bower` command rather the theoretical `react` command, so I'm not sure. What would the different be between your VB-style controls and something like this confirmation popup: https://github.com/component/confirmation-popover https://github.com/component/confirmation-popover
      - rjknight 12y ago
        React has a much richer notion of what a 'component' is. To date, most JavaScript libraries lack shared assumptions about how you will build your UI. jQuery plugins make only the extremely minimal assumption that you will apply the plugin to some DOM element - beyond that, how the plugins behave, how they manage their state, properties etc. is not defined by any standards or even assumptions. The confirmation popover you link to is a good example. It's a black-box component which exposes a fairly minimal interface. The constructor for this component works like this: new ConfirmationPopover(msg, [title]) To attach the popover to an element you need to do: popover.show(el, [fn]) However, if we take another component from the same library, the swipe component[1], we see different conventions. Its constructor: Swipe(el) It also has a show method which takes totally different parameters: .show(i, [ms], [options]) This is why I describe such systems as package managers or library managers - they're just a way of importing and exporting code and don't do anything to aid reuse. They're not particularly likely to play well together, lack standard interfaces and are almost certainly not composable in any meaningful way. React components are different because React defines some standard details of how components behave, how to extend them, how to inspect them and pass data back and forth. Components can contain other components, and all components have a relative place in the render tree. This makes possible standard developer tools that can be used to observe and inspect components in a DOM-like tree structure[2]. So, you could certainly use bower to distribute React components. What's different about React isn't how the code is distributed but the fact that you can have expectations about how, say, a React photo gallery component would behave that you would not get from some other JS library. [1] https://github.com/component/swipe https://github.com/component/swipe [2] http://facebook.github.io/react/blog/2014/01/02/react-chrome-developer-tools.html http://facebook.github.io/react/blog/2014/01/02/react-chrome...
adamors 12y ago
Would you recommend using React instead of Angular for JS heavy areas of a website that is built with a server side framework (like Rails, Django etc.)? I developed a rather complex SPA with Angular recently and I cannot go back to the ghetto that is jQuery when using server side rendering.
- camus2 12y ago
  Angular solves more than the UI problem,React on its own doesnt solve the architecturing problem , AngularJS does. The big weakness of Angular is server side rendering,which involves heavy solutions like phantomjs,while you can render react components on the server. Angular is not very good at rendering/managing svg either,that's a fact. I would argue maintaining pure html templates is not that hard. But frankly Angular solves so many problems these are minor issues.Writing complex lob applications is so easy with Angular I wouldnt want to use anything else. The only case i'd switch back to backbone+react/vue/ractive and jquery is when i'm writing interactive experiences that are not CRUD apps. So no,dont switch to React for the sake of switching especially since AngularJS just works. I mean people dont even bother learning javascript,they learn AngularJS ...
  - polskibus 12y ago
    Flux is Facebook's architecture for using React in a larger scheme. http://facebook.github.io/react/blog/2014/05/06/flux.htm http://facebook.github.io/react/blog/2014/05/06/flux.htm It has been discussed on HN before : https://news.ycombinator.com/item?id=7719957 https://news.ycombinator.com/item?id=7719957 Some good comments there, worth checking out. Personally, I think the message loop architecture proved very good in Windows when processors were slow and had only 1 core and it is at least worth giving it a try in web development.
  - adamors 12y ago
    > Angular solves more than the UI problem Hence my question. I feel like for some apps I don't need 60% of what Angular has to offer (routing, controllers, modules etc.) I would be satisfied with just directives. Which are probably the part of Angular I like the least. For SPAs I see no other alternative to Angular currently. In instances where I need heavy JS only on some pages, I'm not sure.
Flimm 12y ago
Please don't break the back button (Firefox and Chrome). In Firefox 29.0 on Ubuntu 14.04, the left sidebar with the text of the blog disappears and is replaced with a white space. I do not experience this on Chrome.
- liquidise 12y ago
  Add Opera to that list as well, or anything Blink based i would assume
  - jlongster 12y ago
    He said he did not experience in Chrome. Is there any chance you could take a screenshot/screencast of the bug? I haven't been able to reproduce.
- jlongster 12y ago
  I just tried it on Firefox 26 on OSX and could not replicate. It has worked for everyone I've had test the page. The only thing that happens when you press back is the animation to load the right demo. There might be something buggy with how the CSS animation is using your graphics driver?
  - hashberry 12y ago
    Back button breaking on latest version of Chrome/Win7 here. Scrolling up and down adds history.
    - jlongster 12y ago
      It adds history?? What is the URL changing to?
      - ben336 12y ago
        URL doesn't appear to change in chrome, but the back button just cycles through the various demo screens after you've scrolled down for a while.
zawaideh 12y ago
Instead of having React altogether, wouldn't it make sense to have the browser keep track of a virtual DOM, and only repaint whatever changes on its own, while managing its own requestAnimationFrame and paint cycles? P.S. I haven't looked into this in depth, just throwing an idea out there.
- rdtsc 12y ago
  Yeah if the technology was in the browser that would possible. From what I understand, the core idea is that changes are applied to the virtual DOM in a very simple way (from the application point of view). Then there is another piece of code that knows how to efficiently find the diff between the vDOM and DOM and apply the changes. It seems that last part could be done by the browser.
  - stuki 12y ago
    The additional layer of redirection, at least conceptually enables the use of application specific, or pluggable, vDOMs and/or diffing strategies.
- rjknight 12y ago
  I may be mistaken here, but I think that the main advantage of the virtual DOM is to avoid calling across the JavaScript-native boundary. Since calling browser APIs is inherently expensive, the virtual DOM improves performance by reducing the number of calls to these APIs and/or batching them together. Similar techniques have been used in other types of programs where performance is critical - for instance, user mode networking and user-mode thread scheduling can be quicker than the kernel-mode equivalent because it reduces or eliminates expensive system calls.
zenojevski 12y ago
For those who are only interested in the render loop, I made a library[1] around this abstraction. I plan to expand it with a toolkit to allow thinking in terms of batches, queues and consumers, à la bacon.js[2]. [1]: https://github.com/zenoamaro/honeyloops https://github.com/zenoamaro/honeyloops [2]: https://github.com/baconjs/bacon.js https://github.com/baconjs/bacon.js
platz 12y ago
I was at a meetup where the speaker suggested react is great for business-like apps, but for things with an insane amount of dom objects like html games, it tends to get bogged down. Since React claims to be super fact, has done a performance comparison to see in what situations and how much better react performs in certain cases, compared to say, angular.js or more vanilla frameworks? (Also I hear that there is a really great speedup that using OM gives you, but I haven't seen any comparisons with om either)
- camus2 12y ago
  if you are going to update the DOM 60 times per second no databinding/reactive whatever framework makes sense. there is so much overhead with these solutions performances would just be bad. However it would be interesting to extract the virtual DOM from React to use it in the context DOM based games, being able to mark elements as dirty in order to redraw them is a usefull feature.One just doesnt need all the JSX/databinindg stuff for a game driven by a gameloop.
  - spicyj 12y ago
    JSX is a build step and is completely optional. If by "databinding stuff" you mean React's setState and friends, almost all of React's code deals with the actual diffing and browser handling. Components are not much more than functions from props to a virtual DOM output. It's easy to use React without ever calling React.createClass (just pass the output of React.DOM to renderComponent). Still, we're looking at separating these parts of React so that you don't have to pay the file bytes but it's not a very significant difference right now anyway.
    - camus2 12y ago
      thanks for the info, i'll try to hack something with React for my next DOM based game and see if it works.
- slattery 12y ago
  Check out this example of a 3D game using React: http://facebook.github.io/react/blog/2013/08/26/community-roundup-7.html#wolfenstein-rendering-engine-ported-to-react http://facebook.github.io/react/blog/2013/08/26/community-ro... (Wolfenstein Rendering Engine Ported to React)
rdtsc 12y ago
As mostly an outsider to the web front end development, React.js is probably the easiest one for me to understand among the typical "frameworks", especially Angular and Ember. After all the excitement about Angular for example, I went to learn about it and just got lost with new concepts: DOM transclusion, scopes, services, directives, ng-apps, controllers, dependency inversion and so on. I can use it but need someone to hold my hand. It reminded me of Enterprise Java Beans. But so far just learning how React is put together and looking at the tutorials it seems like less of a framework and easier to understand altogether. I suspect this might become the new way to build web applications. Well anyway, don't take this too seriously, I as said, I am an outsider to this.
- beat 12y ago
  I feel your pain. I'm a backend guy who has to learn front end all of the sudden. To my mind, React just makes sense. I understand that other modern frameworks like Angular and Ember "make sense" as well, in that they're current best implementations of well-understood best practice, but from my outsider perspective, it looks as complicated and baroque as Catholic theology. Yes, it's all very beautiful and such, but I don't know if I'll ever be able to instinctively grok it. React? I grok that.
  - steveklabnik 12y ago
    If you're a backend person, thinking about Ember as being more of a Smalltalk MVC than a Rails MVC helps a lot.
- svachalek 12y ago
  I've been doing Angular for about a year now and am pretty comfortable with it, but I definitely remember going through that brick wall and see it every time I try to explain it to someone new. React looks much more straightforward to pick up but I am curious whether someone who has "mastered" both would find one or the other more powerful or maintainable.
  - RussianCow 12y ago
malvosenior 12y ago
For those that haven't tried it, David Nolen's Om for ClojureScript is an excellent React framework. https://github.com/swannodette/om https://github.com/swannodette/om I've not used vanilla React, but Om is certainly fantastic and apparently adds a bunch of stuff that's not in the JS version. Also, a web framework written by the guy that wrote most of the language you're using? Win!
- ThomasDeutsch 12y ago
  I would love to support a JS project that is something like a port of OM to JS.
  - malvosenior 12y ago
    I understand that there are sometimes practical reasons for not being able to use ClojureScript, but have you given it a go? It's really very, very nice (much nicer than JS in pretty much every way). * Immutable data (you can get some of this in JS with Nolen's Mori http://swannodette.github.io/mori/ http://swannodette.github.io/mori/) * Better functional programming than Underscore (map :mykey some-objects) * Great syntax: homoiconicity, thrush operator, first class set, regex, map, vector syntax * Macros! * Use of cool frameworks: Om, core.async * Same language as back-end if using Clojure It was quite frankly intimidating to get started with it all as an ex-Java/Obj-c/Python/JS dev but I could never go back.
    - ThomasDeutsch 12y ago
      OM and ClojureScript are great - but it is all about choice. Sometimes i prefer/need JS as a language. It would be great to get the AMAZING clojure-community ideas into the JS world.
      - malvosenior 12y ago
        Yep, camus2 points out environments like jsbin. Bookmarklets are another place you wouldn't use something like ClojureScript. I'd argue once you go beyond "small" things though switching to ClojureScript is preferable to duplicating large parts of its functionality in separate JS libs.
IanDrake 12y ago
Tester: The UI is wrong right here... Developer: Hmm...I wonder how long it's going to take me to figure out where that HTML was generated in my javascript.
- polskibus 12y ago
  Did you see this tool ? I find it quite helpful for debugging JSX and finding the root of the problem. http://facebook.github.io/react/blog/2014/01/02/react-chrome-developer-tools.html http://facebook.github.io/react/blog/2014/01/02/react-chrome...
- Zelphyr 12y ago
  You hit the nail on the head why these things are bad. You can either build something on a mass production line, where you're just screwing the same bolt in day in and day out, or become a master craftsman and build it with proper care, design, and quality. These frameworks are nothing more than a factory floor and if all you do is build apps with a framework you're little more than a paid glue stick piecing bits of code together. Or you can become a master software developer and build something of quality without needing a crutch like a framework. Now, if the needs of the project are such that a framework will suffice then by all means, use a framework. Chances are, if you're doing more than building a working prototype then at some point a framework is going to fail you. If you enjoy building apps using frameworks then by all means, do it. But to my mind you're doing your customer a disservice. Contrast that with great software developers (and I've been fortunate to have worked with some really great developers) who abhor these frameworks. They can get more done with less code and ultimately deliver the project faster without frameworks. The tradeoff is that it takes time and dedication to achieve that level of mastery. I personally would prefer that path.
  - aquark 12y ago
    Of course it really is frameworks all the way down. Unless maybe you're building systems by laying out your own transitors. The trick is to understand the strengths and weaknesses of any given framework and match those with the constraints of your project.
iamwil 12y ago
Has anyone tried to use a different template engine with React? I was just wondering, since I didn't want to use JSX inline, and writing out html with React.DOM isn't appealing either. I just wanted a way to put templates in <script> tags that get loaded by React Components. That way, I won't be mixing templates and the behavior of the components. Has anyone done this before?
- cnp 12y ago
  There's this: https://github.com/mereskin/jsxify https://github.com/mereskin/jsxify But really, once you get used to keeping everything together it really does feel better. You just have to try it out. Personally, since I use CoffeeScript, I like this lib: https://github.com/atom/reactionary https://github.com/atom/reactionary which, since it strips out the required `null` or `{}` first parameter, feels very much like haml or jade.
  - iamwil 12y ago
    I use coffeescript too, so I should be able to use reactionary to write the dom helpers it exposes in my JSX. So then the coffeescript -> jsx on server side, then jsx -> javascript browser side, is how it works, right? I think I'm slowly being convinced putting it together in the same file makes sense, since it's a single component, and the what's being displayed is coupled with what you'd do with it, so I guess it should belong in the same place?
    - cnp 12y ago
      Well, the way you should do it is abandon .jsx completely, and just stick to .coffee. Something like this: React.createClass render: -> {div, h1, span} = require 'reactionary' div class: 'home', h1 "Hows it going!" Clean and simple, particularly with CoffeeScripts default return. As far as templates go -- and this is what I always tell people -- structure your code in a clean way which makes the render function pop out and you might as well be working with a separate file! It really does make more sense after a while.
tomdale 12y ago
This is a really thoroughly researched post and jlongster has my gratitude for writing it up. I have two concerns with this approach. Take everything I say with a grain of salt as one of the authors of Ember.js. First, as described here and as actually implemented by Om, this eliminates complexity by spamming the component with state change notifications via requestAnimationFrame (rAF). That may be a fair tradeoff in the end, but I would be nervous about building a large-scale app that relied on diffing performance for every data-bound element fitting in rAF's 16ms window. (I'll also mention that this puts a pretty firm cap on how you can use data binding in your app, and it tends to mean that people just use binding from the JavaScript -> DOM layer. One of the nicest things about Ember, IMO, is that you can model your entire application, from the model layer all the way up to the templates, with an FRP-like data flow.) My second concern is that components libraries really don't do anything to help you manage which components are on screen, and in a way that doesn't break the URL. So many JavaScript apps feel broken because you can't share them, you can't hit the back button, you can't hit refresh and not lose state, etc. People think MVC is an application architecture, but in fact MVC is a component architecture— your app is composed of many MVCs, all interacting with each other. Without an abstraction to help you manage that (whether it's something like Ember or something you've rolled yourself), it's easy for the complexity of managing which components are on screen and what models they're plugged into to spin quickly out of control. I have yet to see the source code for any app that scales this approach out beyond simple demos, which I hope changes because I would love to see how the rubber hits the pavement. It's always interesting to see different approaches to this problem. I don't think it's as revolutionary as many people want to make it out to be, but I've never been opposed to borrowing good ideas liberally, either. Thanks again, James!
- jlongster 12y ago
  Thanks for the rational response, Tom. I hope this doesn't get buried (someone is going through and downvoting at least all of my comment to 0). Blog posts are best when they are sensational, and I try not to overdue it. I think React has a lot of good ideas, but "revolutionary" is a strong word. I think "refreshing" is a better word. Regardless, I think both React and Ember are the best 2 solutions out there right now, with quite different philosophies, and I'm happy that users have a choice. Using rAF in my post was pretty much a hack. I think it was fun to take that and run with it. When you use React though, you don't actually do that, you use its `setState` method, or you use something like Cortex. If you look at my cortex example, you do use setters and getters, which give you a way to notify data change. Why don't we just use models like Ember? Because React still doesn't care how we model our data -- even if we have to call `set()` to trigger a paint update, what we get is the choice to use something like persistent data structures for our models. === I was completely wrong about Om, it does not continuously trigger rerendering/diffing ever 16ms with rAF. It only uses rAF to batch rendering, so multiple repaints are throttled to a minimum of 16ms === The on-screen issue is interesting; I need to think about it more to see if we can actually leverage it in production apps. I think we can for large list views. You don't share scroll state, do you? I absolutely agree that too many JS apps are breaking the web, and I love that Ember has defaults to make that not happen. There is a grave danger in using React and not taking care to do things right. I'm actually really, really happy about the idea of React and Ember being the 2 ways to choose to build webapps. I have the upmost respect and love for Ember, I think it does a lot of things right, and I wouldn't be surprised if things like routing wasn't copied for libraries to use for React. <3
outworlder 12y ago
I was half-expecting a gambit Scheme post :)
valarauca1 12y ago
It was really cool, until I realized that scrolling broke the back button. I thought one of the cardinal sins of web design was don't break the back button.
__abc 12y ago
back button behavior is atrocious ....
- alttab 12y ago
  But Javascript is awesome! Its the future.
  - Zelphyr 12y ago
    Javascript doesn't inherently break the back button. Sloppy developers do.
    - alttab 12y ago
      Certainly, but sloppy developers using Javascript makes it way easier to break the back button than server-side rendering.
      - modarts 12y ago
        You can break the living hell out of the back button with server-centric solutions (hello asp.net, and POST's for everything)
        alttab 12y ago
        Fair point. I feel like us server folk have figured that part out by now at least, the Javascript stuff is still quite the wild west on the client.
badman_ting 12y ago
I recently watched a presentation about React's approach (I think from a recent JSConf) and it sold me, at least enough to try. The approach makes total sense to me, and I agree with many of its criticisms of Angular in particular. I really loved the reconsidering of our idea of "separation of concerns", that if we reconsider the scope of the concern, we can devise an approach where templating and logic go together. I'm excited by these ideas.
- davidgbeck 12y ago
  Seems like putting templates inside js is a step backwards. The advantage is that you can package templates together with js? That problem is still solvable while maintaining separation. For instaces with browserify tramsforms you can just require( 'my-template' ). https://github.com/epeli/node-hbsfy https://github.com/epeli/node-hbsfy https://github.com/rotundasoftware/nunjucksify https://github.com/rotundasoftware/nunjucksify
jbeja 12y ago
I hate OP website, why i got to click the back button 10 times to comeback here?
mattdeboard 12y ago
This is great except the button is broken.
etrinh 12y ago
Not to distract from the topic, but jlongster's posts should be a case study into how to make an effective demo/tutorial on the web. The side by side code/demo format is very well done and should be the de facto way to do code + demo. There have been so many times when I've been reading a tutorial and click on a demo link that opens a new tab. This makes me completely lose context as I switch back and forth between the tutorial and various demo links. For another example of a post that takes advantage of the dynamic nature of the web page, check out jlongster's sweet.js tutorial[1]. It's a tutorial on writing macros with JS that you can actually interact with (you can make modifications to the example code snippets and see your macros expand on the fly). Very cool. [1]: http://jlongster.com/Writing-Your-First-Sweet.js-Macro http://jlongster.com/Writing-Your-First-Sweet.js-Macro
cnp 12y ago
This is definitely a "Sell this to your boss" type of post :) Great work.
ulisesrmzroche 12y ago
I'm honestly really, really wary of minimalistic front-end frameworks after two years of working on single page web apps. All that ends up happening in practice is untested, messy code with deadlines up your ass and 0 developer ergonomics. Zero.
- dangoor 12y ago
  It's hard to say what, exactly, you're referring to here. React, in many ways, is not so much a framework but rather a really smart template system. It's ergonomics, I've found, are quite nice.
nostrademons 12y ago
I think this post is missing something in its description of Web Components: the fundamental difference between a JS-based framework like React and a Web Components-based framework like Polymer is that the former takes JS objects as primitives and the DOM as an implementation artifact, while the latter takes the DOM as a primitive and JS as an implementation artifact. You cannot wrap your head around Web Components and give both it and JS frameworks a fair shake until you can make this mental shift in perspective fluently. The line in the post where "You can't even do something as basic as that with Web Components.": var MyToolbar = require('shared-components/toolbar'); In fact has a direct analogue with HTML imports: <link rel="import" href="shared-components/toolbar.html"> And that's key to understanding Web Components. The idea of the standard is that you can now define your own custom HTML elements, and those elements function exactly like the DOM elements that are built into the browser. This is a key strategic point: they function exactly like the DOM elements that are built into the browser because Google/Mozilla/Opera/et al hope to build the popular ones into the browser eventually, just like we've gotten <input type=date> and <details>/<summary> based on common web usage patterns. A number of the other code samples in the article also have direct analogues in Polymer as well. For example, the App/Toolbar example halfway down the page would be this: <polymer-element name="Toolbar" attributes="number"> <template> <div> <button value="increment" on-click="{{increment}}"> <button value="decrement" on-click="{{decrement}}"> </div> </template> <script> Polymer('toolbar', { number: 0, increment: function() { this.number++; } decrement: function() { this.number--; } }); </script> </polymer-element> <polymer-element name="App"> <template> <div> <span>{{toolbar.number}}</span> <Toolbar number=0 id="toolbar"></Toolbar> </div> </template> <script> Polymer('App', { created: function() { this.toolbar = this.$.toolbar; } }); </script> </polymer-element> You can decide for yourself whether you like that or you like the Bloop example more - my point with this post is to educate, not evangelize - but the key point is that you can define your own tags and elements just like regular DOM elements, give them behavior with Javascript, make them "smart" through data-binding so you don't have to manually wire up handlers, and then compose them like you would compose a manual HTML fragment.
- spankalee 12y ago
mushishi 12y ago
The awkward right panel that changed abruptly from time to time, especially the first transition, made me skip the content. Using a non-common ui idiom is risky. The presentation and topic don't match in a way that reader (i.e. me) had enough expectations left when it comes to what you might actually have to say.
- mmabbq 12y ago
  I feel kinda bad that you're being downvoted. I also felt the presentation was a little jarring. The right panel seemed to change at strange times related to the content I was reading. Perhaps it was an overuse of the "change things while the user is scrolling to make it seem cool" theme I've been seeing a lot. On the other hand, I actually found the content pretty great, but I'm not a web developer so take that with a grain of salt...
1986v 12y ago
If school books had online versions like this page, it would make reading so much more fun. Great read, by the way.
jafaku 12y ago
Damn, Javascript is only becoming messier. I think I'll just watch it from the distance and wait until someone figures out the best way to deal with it.
- Rygu 12y ago
  That might take a few browser generations sadly. HTML6 anyone? edit: HTML/next apparently: http://www.w3.org/wiki/HTML/next http://www.w3.org/wiki/HTML/next
__david__ 12y ago
So I'm curious how one would implement something like drag and drop in a React app? Would you model the drag in the main data model somehow? Or would you do that all externally (with traditional DOM manipulation) and then update the model when the drag is complete?
- cnp 12y ago
  The latter. You would use html5's draggable, then update on complete. Check out http://webcloud.se/sortable-list-component-react-js/ http://webcloud.se/sortable-list-component-react-js/
- dugmartin 12y ago
  I wouldn't use the DOM. To "embrace" React you really need to forgot the real DOM exists and instead track the drag in the components state and handle moving the items around in the render function.
gooserock 12y ago
I like the state and property features of React, but I still don't understand why more people aren't using Chaplin instead. Because quite honestly, the syntax of every other framework - React, Ember, and especially Angular - is complete gobbledygook by comparison. Example: in Chaplin, components are views or subviews (because it's still an MVC framework, which is another discussion for another time). The views by default render automatically without you having to call anything. But if you did, you'd write @render() (because hey, Coffeescript saves keystrokes and sanity). That automatically renders the component in the place you've already specified as its container attribute, or if you haven't it renders to the body by default. Whereas in React, you have to write this garbage: Bloop.renderComponent(Box(), document.body); WHY. Can't we write a framework that intuits some of this crap? Shouldn't we use a framework that reduces the time we spend writing code?
- pestaa 12y ago
  Automatic rendering is fine in small projects. Seemingly random appearance of widgets would, however, drive the debugging person crazy. Comparing this.render to Bloop.renderComponent is superficial. If rendering needs to have a handle on different resources, you'd either violate the encapsulation in the former example, or write a service to couple them on a separate layer -- that service might as well be called Bloop. Some of this crap makes hard things possible.
- krebby 12y ago
  I've been a longtime user of Chaplin and I love it, particularly when it comes to the Composer and Dispatcher. I've been experimenting recently with killing the view layer completely in favor of React templates, since I think react does a better job of managing view state, but doesn't include the rest of the stuff I need for my app like routing and data management.
mrcwinn 12y ago
Curious if anyone has experimented with Go+React - specifically rendering on the server side as well. Similar to Rails / react_ujs (react-rails gem), seems like you would need to provide Go with access to a v8 runtime and a FuncMap helper in the template to call for the necessary component (JSX -> markup). I've really enjoyed React and I've enjoyed Go in my spare time, but I still find myself using npm for a lot of the, um, grunt work.
ufo 12y ago
I experimented with React a bit but I was a bit bugged by how large it was. The basic idea of rendering to a virtual DOM and having unidirectional data flow is really simple but I had trouble actually diving in to React's source code and seeing things under the hood (for example, I had to find a blog to see how the diffing algorithm worked). What are the other libraries out there that we can use for this virtual DOM pattern right now? I only found mithril[1] that similarly does the template rendering with Javascript but I still don't know how different to React it is in the end? Is the diffing algorithm similar? Do they handle corner cases the same (many attributes need to be treated specially when writing them to DOM)? Simplifying it a bit: other than the virtual DOM, is the rest of React also the best way to structure apps? What would the ideal "barebones" virtual DOM library look like? [1] http://lhorie.github.io/mithril/ http://lhorie.github.io/mithril/
- vjeux 12y ago
  While the basic idea of rendering to a virtual DOM is simple, making it work well for large applications require a lot more than a toy implementation as described in the article. In order to get adopted, React needs to coexist with existing applications/third party libraries that do manual DOM mutations. The life cycle methods are there to deal with this. React implements its own class system that supports mixins and type annotations. The plan is to change the API to use ES6 classes (we're working to improve the standard to support all React use cases). React re-implements its own event system in order to make it fast, memory efficient and abstract away browser differences. Making composable components is not as straightforward as it first seems. There are a lot of edge cases like refs, owner/parent to be handled. Then, as you mentioned, there's the diff algorithm and batching strategies which need to be implemented in a performant and memory efficient way. And provide hooks for the user to be able to give it hints via shouldComponentUpdate.
- Raynos 12y ago
  I have a similar frustration with React. The source code is very hard to read our follow. An ideal "barebones" virtual dom library looks like https://github.com/Matt-Esch/virtual-dom https://github.com/Matt-Esch/virtual-dom . The `virtual-dom` module was build out of frustration with the readability of react source code and is the minimal modular subset. I've also built a small framework on top `virtual-dom` to add in essentials like immutable state and event handling ( https://github.com/Raynos/mercury https://github.com/Raynos/mercury ). Whilst mercury might not be the best way to structure apps, it's an approach that is getting me far and I'm drawing strong inspiration from FRP and FP systems like Elm and om.
gcb0 12y ago
my gripe with those is that you remove UI complexity but shove usability and accessibility over some dark orifice. All those things are cool for social apps (a.k.a. fart apps) but for business ready platforms this is just silly. for example, a link that i can middle click or bookmark or send to someone, etc would be much more useful even if not as spiffy as those scrolls
cellis 12y ago
Needs a catchy buzzword. So, can we all agree to name this ... NoHTML?
jdnier 12y ago
Leo Horie, author of Mithril, has written a blog post where he explains how to re-implement some of the article's examples using Mithril (React-like client-side Javascript MVC framework): http://lhorie.github.io/mithril-blog/an-exercise-in-awesomeness.html http://lhorie.github.io/mithril-blog/an-exercise-in-awesomen...
- jdnier 12y ago
  Mithril docs: http://lhorie.github.io/mithril/ http://lhorie.github.io/mithril/
deleted 12y ago
[deleted]
redOctober13 12y ago
Just want to say thanks to jlongster and everyone who's commented on here; I created an account just to say thanks. I'm an amateur web dev/designer trying to figure out how to move beyond static web pages, and have read what would probably amount to a literal ton of material were it printed out, on frameworks, libraries, and more acronyms than I could imagine. Outside of HTML, JS, and CSS, even "basic" things like Sass and CoffeeScript I hadn't heard of just a few months ago, and I've since been all over the world (wide web) looking for info on ASP.NET (which my group at work decided last year was what we should be doing "web-kinda stuff" in, as well as Angular, Ember, Backbone, Knockout, Node, etc etc, and everything new (to me) that research like that comes with. The discussion here has led me to a few more things to research, but I feel it's been very helpful in helping me think critically about the vast array of possibilities a budding web designer has to deal with. I just wanted somebody to provide an objective view of "If you're going to be doing medium-complexity web apps end-to-end, then learn ______" and I still would love that, but don't think it's possible to get. The alternative, as I've been doing, is just to learn a little about everything, try to figure out the kind of things I plan to do, and then find the paradigm that works, be it vanilla technologies, something like React, Web Components, or a framework (and I've been trying to learn Angular and like it, but it's tough to grasp). It just seems like as soon as I've decided on what I want to learn, I read a new post with a title like "Why You Shouldn't Use <whatever I just decided to learn> and Why <something new I've never heard of> Is Really the Way to Go." So anyways, a long-winded thanks, but a thank you nevertheless for the open discussion here; I feel better now that I'm not trying to find the one-and-done "best" thing for making web apps in general.

632 points by jlongster 12y ago

As a recommendation to the author, it would make sense to show the example/demo area the whole time, not only once I scroll down. It confused me. A lot.

joshstrange 12y ago
Agreed, I really like the demo area but it's a bit of a shock when it first shows up.
- jlongster 12y ago
  Heh, it's been mixed reactions. I will probably tweak the initial experience, but will need some time because I can't leave it open on load because it blocks the header.
  - outworlder 12y ago
    I thought it was nifty. The shocking aspect might just be the big layout change. Perhaps a notification ("Check out the demo") so the user has to click it to enable the side pane, and then its business as usual.
    - cnp 12y ago
      I liked the layout as well. One thing I would change would be to make the code area wider than the demo area, as some of your lines wrap, where the demo area rarely needs a line break.
  - joaren 12y ago
    It's a pretty crappy experience. I'm reading an article, suddenly the text decides to move left for 'no good reason' to create a narrow but empty sidebar. WTF? I don't like reading things on the left side of my monitor, so I make the window wider to try and put the text back in the middle. Except now the demo area gets even wider (why? you don't use it for anything but tiny things?). As I scroll, the various iframe loads create annoying jank, and to top it off, there's a bug at the end of the post where it moves horizontally for no good reason. If you're going to do stuff like this, you need to polish it waaay better. This reminds me of the UI animations in the new Firefox. A good idea ruined by implementation, would've been better to leave them out.
- ErikRogneby 12y ago
  Sometimes a shock is good. I took it as, "Hey, this page just gained new abilities." Then I clicked and moused over the square and the triangle to see what they were about.
- scotty79 12y ago
  That demo area sliding out actually caused me to actually read the article. I was just about to close it with "meh, react"
johnlbevan2 12y ago
Agreed 100% Desired Reaction: Oh cool, a demo popped up just when it was needed. My Reaction: Huh? Ugh, that's annoying. Wow, and I scroll back up and it moves again; I didn't ask for that either.

roycehaynes 12y ago

Great post. I recently started a project using reactjs, and I have nothing but good things to say. The unidirectional data flow, the declarative nature, and the virtual DOM makes it powerful and very easy to like. The best resource is to follow the tutorial (link below). The tutorial explains everything you may have a question about when comparing it to Backbone, Angular, or Ember. http://facebook.github.io/react/docs/tutorial.html http://facebook.github.io/react/docs/tutorial.html I also found the IRC channel to be very, very helpful. The only downside is that you still have to rely on other tools to make a true SPA like routing.

roycehaynes 12y ago
I found this blog post to be very useful on how to leverage Backbone.Route with Reactjs. https://medium.com/react-tutorials/c00be0cf1592 https://medium.com/react-tutorials/c00be0cf1592

NathanKP 12y ago

I really like the core concepts of React, especially the way it is designed to help you organize your code into reusable components. I think the key to making React take off is building a centralized repository for components that are open source. Then building your webapp would be as easy as importing the components you need: bower install react-navbar bower install react-signup-form bower install react-sso-signin-form I think this is definitely the future of how front end web development will be one day.

colinramsay 12y ago
Surely this doesn't have anything to do with react though? Bower[1] or Component [2] will do this. [1] http://bower.io/ http://bower.io/ [2] http://component.io/ http://component.io/ edit: the parent comment originally referenced a theoretical `react` command and didn't mention bower, which is why I brought it up.
- rjknight 12y ago
  Bower and component are more like package managers. GP is talking about a library of re-usable user interface components. Unfortunately, my best attempt at an analogy is Visual Basic controls, which might not be a great precedent, but the idea itself is a good one.
  - colinramsay 12y ago
    Well they just edited their initial post to specifically use a `bower` command rather the theoretical `react` command, so I'm not sure. What would the different be between your VB-style controls and something like this confirmation popup: https://github.com/component/confirmation-popover https://github.com/component/confirmation-popover
    - rjknight 12y ago
      React has a much richer notion of what a 'component' is. To date, most JavaScript libraries lack shared assumptions about how you will build your UI. jQuery plugins make only the extremely minimal assumption that you will apply the plugin to some DOM element - beyond that, how the plugins behave, how they manage their state, properties etc. is not defined by any standards or even assumptions. The confirmation popover you link to is a good example. It's a black-box component which exposes a fairly minimal interface. The constructor for this component works like this: new ConfirmationPopover(msg, [title]) To attach the popover to an element you need to do: popover.show(el, [fn]) However, if we take another component from the same library, the swipe component[1], we see different conventions. Its constructor: Swipe(el) It also has a show method which takes totally different parameters: .show(i, [ms], [options]) This is why I describe such systems as package managers or library managers - they're just a way of importing and exporting code and don't do anything to aid reuse. They're not particularly likely to play well together, lack standard interfaces and are almost certainly not composable in any meaningful way. React components are different because React defines some standard details of how components behave, how to extend them, how to inspect them and pass data back and forth. Components can contain other components, and all components have a relative place in the render tree. This makes possible standard developer tools that can be used to observe and inspect components in a DOM-like tree structure[2]. So, you could certainly use bower to distribute React components. What's different about React isn't how the code is distributed but the fact that you can have expectations about how, say, a React photo gallery component would behave that you would not get from some other JS library. [1] https://github.com/component/swipe https://github.com/component/swipe [2] http://facebook.github.io/react/blog/2014/01/02/react-chrome-developer-tools.html http://facebook.github.io/react/blog/2014/01/02/react-chrome...

adamors 12y ago

Would you recommend using React instead of Angular for JS heavy areas of a website that is built with a server side framework (like Rails, Django etc.)? I developed a rather complex SPA with Angular recently and I cannot go back to the ghetto that is jQuery when using server side rendering.

camus2 12y ago
Angular solves more than the UI problem,React on its own doesnt solve the architecturing problem , AngularJS does. The big weakness of Angular is server side rendering,which involves heavy solutions like phantomjs,while you can render react components on the server. Angular is not very good at rendering/managing svg either,that's a fact. I would argue maintaining pure html templates is not that hard. But frankly Angular solves so many problems these are minor issues.Writing complex lob applications is so easy with Angular I wouldnt want to use anything else. The only case i'd switch back to backbone+react/vue/ractive and jquery is when i'm writing interactive experiences that are not CRUD apps. So no,dont switch to React for the sake of switching especially since AngularJS just works. I mean people dont even bother learning javascript,they learn AngularJS ...
- polskibus 12y ago
  Flux is Facebook's architecture for using React in a larger scheme. http://facebook.github.io/react/blog/2014/05/06/flux.htm http://facebook.github.io/react/blog/2014/05/06/flux.htm It has been discussed on HN before : https://news.ycombinator.com/item?id=7719957 https://news.ycombinator.com/item?id=7719957 Some good comments there, worth checking out. Personally, I think the message loop architecture proved very good in Windows when processors were slow and had only 1 core and it is at least worth giving it a try in web development.
- adamors 12y ago
  > Angular solves more than the UI problem Hence my question. I feel like for some apps I don't need 60% of what Angular has to offer (routing, controllers, modules etc.) I would be satisfied with just directives. Which are probably the part of Angular I like the least. For SPAs I see no other alternative to Angular currently. In instances where I need heavy JS only on some pages, I'm not sure.

Flimm 12y ago

Please don't break the back button (Firefox and Chrome). In Firefox 29.0 on Ubuntu 14.04, the left sidebar with the text of the blog disappears and is replaced with a white space. I do not experience this on Chrome.

liquidise 12y ago
Add Opera to that list as well, or anything Blink based i would assume
- jlongster 12y ago
  He said he did not experience in Chrome. Is there any chance you could take a screenshot/screencast of the bug? I haven't been able to reproduce.
jlongster 12y ago
I just tried it on Firefox 26 on OSX and could not replicate. It has worked for everyone I've had test the page. The only thing that happens when you press back is the animation to load the right demo. There might be something buggy with how the CSS animation is using your graphics driver?
- hashberry 12y ago
  Back button breaking on latest version of Chrome/Win7 here. Scrolling up and down adds history.
  - jlongster 12y ago
    It adds history?? What is the URL changing to?
    - ben336 12y ago
      URL doesn't appear to change in chrome, but the back button just cycles through the various demo screens after you've scrolled down for a while.

zawaideh 12y ago

Instead of having React altogether, wouldn't it make sense to have the browser keep track of a virtual DOM, and only repaint whatever changes on its own, while managing its own requestAnimationFrame and paint cycles? P.S. I haven't looked into this in depth, just throwing an idea out there.

rdtsc 12y ago
Yeah if the technology was in the browser that would possible. From what I understand, the core idea is that changes are applied to the virtual DOM in a very simple way (from the application point of view). Then there is another piece of code that knows how to efficiently find the diff between the vDOM and DOM and apply the changes. It seems that last part could be done by the browser.
- stuki 12y ago
  The additional layer of redirection, at least conceptually enables the use of application specific, or pluggable, vDOMs and/or diffing strategies.
rjknight 12y ago
I may be mistaken here, but I think that the main advantage of the virtual DOM is to avoid calling across the JavaScript-native boundary. Since calling browser APIs is inherently expensive, the virtual DOM improves performance by reducing the number of calls to these APIs and/or batching them together. Similar techniques have been used in other types of programs where performance is critical - for instance, user mode networking and user-mode thread scheduling can be quicker than the kernel-mode equivalent because it reduces or eliminates expensive system calls.

zenojevski 12y ago

For those who are only interested in the render loop, I made a library[1] around this abstraction. I plan to expand it with a toolkit to allow thinking in terms of batches, queues and consumers, à la bacon.js[2]. [1]: https://github.com/zenoamaro/honeyloops https://github.com/zenoamaro/honeyloops [2]: https://github.com/baconjs/bacon.js https://github.com/baconjs/bacon.js

platz 12y ago

I was at a meetup where the speaker suggested react is great for business-like apps, but for things with an insane amount of dom objects like html games, it tends to get bogged down. Since React claims to be super fact, has done a performance comparison to see in what situations and how much better react performs in certain cases, compared to say, angular.js or more vanilla frameworks? (Also I hear that there is a really great speedup that using OM gives you, but I haven't seen any comparisons with om either)

camus2 12y ago
if you are going to update the DOM 60 times per second no databinding/reactive whatever framework makes sense. there is so much overhead with these solutions performances would just be bad. However it would be interesting to extract the virtual DOM from React to use it in the context DOM based games, being able to mark elements as dirty in order to redraw them is a usefull feature.One just doesnt need all the JSX/databinindg stuff for a game driven by a gameloop.
- spicyj 12y ago
  JSX is a build step and is completely optional. If by "databinding stuff" you mean React's setState and friends, almost all of React's code deals with the actual diffing and browser handling. Components are not much more than functions from props to a virtual DOM output. It's easy to use React without ever calling React.createClass (just pass the output of React.DOM to renderComponent). Still, we're looking at separating these parts of React so that you don't have to pay the file bytes but it's not a very significant difference right now anyway.
  - camus2 12y ago
    thanks for the info, i'll try to hack something with React for my next DOM based game and see if it works.
slattery 12y ago
Check out this example of a 3D game using React: http://facebook.github.io/react/blog/2013/08/26/community-roundup-7.html#wolfenstein-rendering-engine-ported-to-react http://facebook.github.io/react/blog/2013/08/26/community-ro... (Wolfenstein Rendering Engine Ported to React)

rdtsc 12y ago

As mostly an outsider to the web front end development, React.js is probably the easiest one for me to understand among the typical "frameworks", especially Angular and Ember. After all the excitement about Angular for example, I went to learn about it and just got lost with new concepts: DOM transclusion, scopes, services, directives, ng-apps, controllers, dependency inversion and so on. I can use it but need someone to hold my hand. It reminded me of Enterprise Java Beans. But so far just learning how React is put together and looking at the tutorials it seems like less of a framework and easier to understand altogether. I suspect this might become the new way to build web applications. Well anyway, don't take this too seriously, I as said, I am an outsider to this.

beat 12y ago
I feel your pain. I'm a backend guy who has to learn front end all of the sudden. To my mind, React just makes sense. I understand that other modern frameworks like Angular and Ember "make sense" as well, in that they're current best implementations of well-understood best practice, but from my outsider perspective, it looks as complicated and baroque as Catholic theology. Yes, it's all very beautiful and such, but I don't know if I'll ever be able to instinctively grok it. React? I grok that.
- steveklabnik 12y ago
  If you're a backend person, thinking about Ember as being more of a Smalltalk MVC than a Rails MVC helps a lot.
svachalek 12y ago
I've been doing Angular for about a year now and am pretty comfortable with it, but I definitely remember going through that brick wall and see it every time I try to explain it to someone new. React looks much more straightforward to pick up but I am curious whether someone who has "mastered" both would find one or the other more powerful or maintainable.
- RussianCow 12y ago

malvosenior 12y ago

For those that haven't tried it, David Nolen's Om for ClojureScript is an excellent React framework. https://github.com/swannodette/om https://github.com/swannodette/om I've not used vanilla React, but Om is certainly fantastic and apparently adds a bunch of stuff that's not in the JS version. Also, a web framework written by the guy that wrote most of the language you're using? Win!

ThomasDeutsch 12y ago
I would love to support a JS project that is something like a port of OM to JS.
- malvosenior 12y ago
  I understand that there are sometimes practical reasons for not being able to use ClojureScript, but have you given it a go? It's really very, very nice (much nicer than JS in pretty much every way). * Immutable data (you can get some of this in JS with Nolen's Mori http://swannodette.github.io/mori/ http://swannodette.github.io/mori/) * Better functional programming than Underscore (map :mykey some-objects) * Great syntax: homoiconicity, thrush operator, first class set, regex, map, vector syntax * Macros! * Use of cool frameworks: Om, core.async * Same language as back-end if using Clojure It was quite frankly intimidating to get started with it all as an ex-Java/Obj-c/Python/JS dev but I could never go back.
  - ThomasDeutsch 12y ago
    OM and ClojureScript are great - but it is all about choice. Sometimes i prefer/need JS as a language. It would be great to get the AMAZING clojure-community ideas into the JS world.
    - malvosenior 12y ago
      Yep, camus2 points out environments like jsbin. Bookmarklets are another place you wouldn't use something like ClojureScript. I'd argue once you go beyond "small" things though switching to ClojureScript is preferable to duplicating large parts of its functionality in separate JS libs.

IanDrake 12y ago

Tester: The UI is wrong right here... Developer: Hmm...I wonder how long it's going to take me to figure out where that HTML was generated in my javascript.

polskibus 12y ago
Did you see this tool ? I find it quite helpful for debugging JSX and finding the root of the problem. http://facebook.github.io/react/blog/2014/01/02/react-chrome-developer-tools.html http://facebook.github.io/react/blog/2014/01/02/react-chrome...
Zelphyr 12y ago
You hit the nail on the head why these things are bad. You can either build something on a mass production line, where you're just screwing the same bolt in day in and day out, or become a master craftsman and build it with proper care, design, and quality. These frameworks are nothing more than a factory floor and if all you do is build apps with a framework you're little more than a paid glue stick piecing bits of code together. Or you can become a master software developer and build something of quality without needing a crutch like a framework. Now, if the needs of the project are such that a framework will suffice then by all means, use a framework. Chances are, if you're doing more than building a working prototype then at some point a framework is going to fail you. If you enjoy building apps using frameworks then by all means, do it. But to my mind you're doing your customer a disservice. Contrast that with great software developers (and I've been fortunate to have worked with some really great developers) who abhor these frameworks. They can get more done with less code and ultimately deliver the project faster without frameworks. The tradeoff is that it takes time and dedication to achieve that level of mastery. I personally would prefer that path.
- aquark 12y ago
  Of course it really is frameworks all the way down. Unless maybe you're building systems by laying out your own transitors. The trick is to understand the strengths and weaknesses of any given framework and match those with the constraints of your project.

iamwil 12y ago

Has anyone tried to use a different template engine with React? I was just wondering, since I didn't want to use JSX inline, and writing out html with React.DOM isn't appealing either. I just wanted a way to put templates in <script> tags that get loaded by React Components. That way, I won't be mixing templates and the behavior of the components. Has anyone done this before?

cnp 12y ago
There's this: https://github.com/mereskin/jsxify https://github.com/mereskin/jsxify But really, once you get used to keeping everything together it really does feel better. You just have to try it out. Personally, since I use CoffeeScript, I like this lib: https://github.com/atom/reactionary https://github.com/atom/reactionary which, since it strips out the required `null` or `{}` first parameter, feels very much like haml or jade.
- iamwil 12y ago
  I use coffeescript too, so I should be able to use reactionary to write the dom helpers it exposes in my JSX. So then the coffeescript -> jsx on server side, then jsx -> javascript browser side, is how it works, right? I think I'm slowly being convinced putting it together in the same file makes sense, since it's a single component, and the what's being displayed is coupled with what you'd do with it, so I guess it should belong in the same place?
  - cnp 12y ago
    Well, the way you should do it is abandon .jsx completely, and just stick to .coffee. Something like this: React.createClass render: -> {div, h1, span} = require 'reactionary' div class: 'home', h1 "Hows it going!" Clean and simple, particularly with CoffeeScripts default return. As far as templates go -- and this is what I always tell people -- structure your code in a clean way which makes the render function pop out and you might as well be working with a separate file! It really does make more sense after a while.

tomdale 12y ago

This is a really thoroughly researched post and jlongster has my gratitude for writing it up. I have two concerns with this approach. Take everything I say with a grain of salt as one of the authors of Ember.js. First, as described here and as actually implemented by Om, this eliminates complexity by spamming the component with state change notifications via requestAnimationFrame (rAF). That may be a fair tradeoff in the end, but I would be nervous about building a large-scale app that relied on diffing performance for every data-bound element fitting in rAF's 16ms window. (I'll also mention that this puts a pretty firm cap on how you can use data binding in your app, and it tends to mean that people just use binding from the JavaScript -> DOM layer. One of the nicest things about Ember, IMO, is that you can model your entire application, from the model layer all the way up to the templates, with an FRP-like data flow.) My second concern is that components libraries really don't do anything to help you manage which components are on screen, and in a way that doesn't break the URL. So many JavaScript apps feel broken because you can't share them, you can't hit the back button, you can't hit refresh and not lose state, etc. People think MVC is an application architecture, but in fact MVC is a component architecture— your app is composed of many MVCs, all interacting with each other. Without an abstraction to help you manage that (whether it's something like Ember or something you've rolled yourself), it's easy for the complexity of managing which components are on screen and what models they're plugged into to spin quickly out of control. I have yet to see the source code for any app that scales this approach out beyond simple demos, which I hope changes because I would love to see how the rubber hits the pavement. It's always interesting to see different approaches to this problem. I don't think it's as revolutionary as many people want to make it out to be, but I've never been opposed to borrowing good ideas liberally, either. Thanks again, James!

jlongster 12y ago
Thanks for the rational response, Tom. I hope this doesn't get buried (someone is going through and downvoting at least all of my comment to 0). Blog posts are best when they are sensational, and I try not to overdue it. I think React has a lot of good ideas, but "revolutionary" is a strong word. I think "refreshing" is a better word. Regardless, I think both React and Ember are the best 2 solutions out there right now, with quite different philosophies, and I'm happy that users have a choice. Using rAF in my post was pretty much a hack. I think it was fun to take that and run with it. When you use React though, you don't actually do that, you use its `setState` method, or you use something like Cortex. If you look at my cortex example, you do use setters and getters, which give you a way to notify data change. Why don't we just use models like Ember? Because React still doesn't care how we model our data -- even if we have to call `set()` to trigger a paint update, what we get is the choice to use something like persistent data structures for our models. === I was completely wrong about Om, it does not continuously trigger rerendering/diffing ever 16ms with rAF. It only uses rAF to batch rendering, so multiple repaints are throttled to a minimum of 16ms === The on-screen issue is interesting; I need to think about it more to see if we can actually leverage it in production apps. I think we can for large list views. You don't share scroll state, do you? I absolutely agree that too many JS apps are breaking the web, and I love that Ember has defaults to make that not happen. There is a grave danger in using React and not taking care to do things right. I'm actually really, really happy about the idea of React and Ember being the 2 ways to choose to build webapps. I have the upmost respect and love for Ember, I think it does a lot of things right, and I wouldn't be surprised if things like routing wasn't copied for libraries to use for React. <3

outworlder 12y ago

I was half-expecting a gambit Scheme post :)

valarauca1 12y ago

It was really cool, until I realized that scrolling broke the back button. I thought one of the cardinal sins of web design was don't break the back button.

__abc 12y ago

back button behavior is atrocious ....

alttab 12y ago
But Javascript is awesome! Its the future.
- Zelphyr 12y ago
  Javascript doesn't inherently break the back button. Sloppy developers do.
  - alttab 12y ago
    Certainly, but sloppy developers using Javascript makes it way easier to break the back button than server-side rendering.
    - modarts 12y ago
      You can break the living hell out of the back button with server-centric solutions (hello asp.net, and POST's for everything)
      - alttab 12y ago
        Fair point. I feel like us server folk have figured that part out by now at least, the Javascript stuff is still quite the wild west on the client.

badman_ting 12y ago

I recently watched a presentation about React's approach (I think from a recent JSConf) and it sold me, at least enough to try. The approach makes total sense to me, and I agree with many of its criticisms of Angular in particular. I really loved the reconsidering of our idea of "separation of concerns", that if we reconsider the scope of the concern, we can devise an approach where templating and logic go together. I'm excited by these ideas.

davidgbeck 12y ago
Seems like putting templates inside js is a step backwards. The advantage is that you can package templates together with js? That problem is still solvable while maintaining separation. For instaces with browserify tramsforms you can just require( 'my-template' ). https://github.com/epeli/node-hbsfy https://github.com/epeli/node-hbsfy https://github.com/rotundasoftware/nunjucksify https://github.com/rotundasoftware/nunjucksify

jbeja 12y ago

I hate OP website, why i got to click the back button 10 times to comeback here?

mattdeboard 12y ago

This is great except the button is broken.

etrinh 12y ago

Not to distract from the topic, but jlongster's posts should be a case study into how to make an effective demo/tutorial on the web. The side by side code/demo format is very well done and should be the de facto way to do code + demo. There have been so many times when I've been reading a tutorial and click on a demo link that opens a new tab. This makes me completely lose context as I switch back and forth between the tutorial and various demo links. For another example of a post that takes advantage of the dynamic nature of the web page, check out jlongster's sweet.js tutorial[1]. It's a tutorial on writing macros with JS that you can actually interact with (you can make modifications to the example code snippets and see your macros expand on the fly). Very cool. [1]: http://jlongster.com/Writing-Your-First-Sweet.js-Macro http://jlongster.com/Writing-Your-First-Sweet.js-Macro

cnp 12y ago

This is definitely a "Sell this to your boss" type of post :) Great work.

ulisesrmzroche 12y ago

I'm honestly really, really wary of minimalistic front-end frameworks after two years of working on single page web apps. All that ends up happening in practice is untested, messy code with deadlines up your ass and 0 developer ergonomics. Zero.

dangoor 12y ago
It's hard to say what, exactly, you're referring to here. React, in many ways, is not so much a framework but rather a really smart template system. It's ergonomics, I've found, are quite nice.

nostrademons 12y ago

I think this post is missing something in its description of Web Components: the fundamental difference between a JS-based framework like React and a Web Components-based framework like Polymer is that the former takes JS objects as primitives and the DOM as an implementation artifact, while the latter takes the DOM as a primitive and JS as an implementation artifact. You cannot wrap your head around Web Components and give both it and JS frameworks a fair shake until you can make this mental shift in perspective fluently. The line in the post where "You can't even do something as basic as that with Web Components.": var MyToolbar = require('shared-components/toolbar'); In fact has a direct analogue with HTML imports: <link rel="import" href="shared-components/toolbar.html"> And that's key to understanding Web Components. The idea of the standard is that you can now define your own custom HTML elements, and those elements function exactly like the DOM elements that are built into the browser. This is a key strategic point: they function exactly like the DOM elements that are built into the browser because Google/Mozilla/Opera/et al hope to build the popular ones into the browser eventually, just like we've gotten <input type=date> and <details>/<summary> based on common web usage patterns. A number of the other code samples in the article also have direct analogues in Polymer as well. For example, the App/Toolbar example halfway down the page would be this: <polymer-element name="Toolbar" attributes="number"> <template> <div> <button value="increment" on-click="{{increment}}"> <button value="decrement" on-click="{{decrement}}"> </div> </template> <script> Polymer('toolbar', { number: 0, increment: function() { this.number++; } decrement: function() { this.number--; } }); </script> </polymer-element> <polymer-element name="App"> <template> <div> <span>{{toolbar.number}}</span> <Toolbar number=0 id="toolbar"></Toolbar> </div> </template> <script> Polymer('App', { created: function() { this.toolbar = this.$.toolbar; } }); </script> </polymer-element> You can decide for yourself whether you like that or you like the Bloop example more - my point with this post is to educate, not evangelize - but the key point is that you can define your own tags and elements just like regular DOM elements, give them behavior with Javascript, make them "smart" through data-binding so you don't have to manually wire up handlers, and then compose them like you would compose a manual HTML fragment.

spankalee 12y ago

mushishi 12y ago

The awkward right panel that changed abruptly from time to time, especially the first transition, made me skip the content. Using a non-common ui idiom is risky. The presentation and topic don't match in a way that reader (i.e. me) had enough expectations left when it comes to what you might actually have to say.

mmabbq 12y ago
I feel kinda bad that you're being downvoted. I also felt the presentation was a little jarring. The right panel seemed to change at strange times related to the content I was reading. Perhaps it was an overuse of the "change things while the user is scrolling to make it seem cool" theme I've been seeing a lot. On the other hand, I actually found the content pretty great, but I'm not a web developer so take that with a grain of salt...

1986v 12y ago

If school books had online versions like this page, it would make reading so much more fun. Great read, by the way.

jafaku 12y ago

Damn, Javascript is only becoming messier. I think I'll just watch it from the distance and wait until someone figures out the best way to deal with it.

Rygu 12y ago
That might take a few browser generations sadly. HTML6 anyone? edit: HTML/next apparently: http://www.w3.org/wiki/HTML/next http://www.w3.org/wiki/HTML/next

__david__ 12y ago

So I'm curious how one would implement something like drag and drop in a React app? Would you model the drag in the main data model somehow? Or would you do that all externally (with traditional DOM manipulation) and then update the model when the drag is complete?

cnp 12y ago
The latter. You would use html5's draggable, then update on complete. Check out http://webcloud.se/sortable-list-component-react-js/ http://webcloud.se/sortable-list-component-react-js/
dugmartin 12y ago
I wouldn't use the DOM. To "embrace" React you really need to forgot the real DOM exists and instead track the drag in the components state and handle moving the items around in the render function.

gooserock 12y ago

I like the state and property features of React, but I still don't understand why more people aren't using Chaplin instead. Because quite honestly, the syntax of every other framework - React, Ember, and especially Angular - is complete gobbledygook by comparison. Example: in Chaplin, components are views or subviews (because it's still an MVC framework, which is another discussion for another time). The views by default render automatically without you having to call anything. But if you did, you'd write @render() (because hey, Coffeescript saves keystrokes and sanity). That automatically renders the component in the place you've already specified as its container attribute, or if you haven't it renders to the body by default. Whereas in React, you have to write this garbage: Bloop.renderComponent(Box(), document.body); WHY. Can't we write a framework that intuits some of this crap? Shouldn't we use a framework that reduces the time we spend writing code?

pestaa 12y ago
Automatic rendering is fine in small projects. Seemingly random appearance of widgets would, however, drive the debugging person crazy. Comparing this.render to Bloop.renderComponent is superficial. If rendering needs to have a handle on different resources, you'd either violate the encapsulation in the former example, or write a service to couple them on a separate layer -- that service might as well be called Bloop. Some of this crap makes hard things possible.
krebby 12y ago
I've been a longtime user of Chaplin and I love it, particularly when it comes to the Composer and Dispatcher. I've been experimenting recently with killing the view layer completely in favor of React templates, since I think react does a better job of managing view state, but doesn't include the rest of the stuff I need for my app like routing and data management.

mrcwinn 12y ago

Curious if anyone has experimented with Go+React - specifically rendering on the server side as well. Similar to Rails / react_ujs (react-rails gem), seems like you would need to provide Go with access to a v8 runtime and a FuncMap helper in the template to call for the necessary component (JSX -> markup). I've really enjoyed React and I've enjoyed Go in my spare time, but I still find myself using npm for a lot of the, um, grunt work.

ufo 12y ago

I experimented with React a bit but I was a bit bugged by how large it was. The basic idea of rendering to a virtual DOM and having unidirectional data flow is really simple but I had trouble actually diving in to React's source code and seeing things under the hood (for example, I had to find a blog to see how the diffing algorithm worked). What are the other libraries out there that we can use for this virtual DOM pattern right now? I only found mithril[1] that similarly does the template rendering with Javascript but I still don't know how different to React it is in the end? Is the diffing algorithm similar? Do they handle corner cases the same (many attributes need to be treated specially when writing them to DOM)? Simplifying it a bit: other than the virtual DOM, is the rest of React also the best way to structure apps? What would the ideal "barebones" virtual DOM library look like? [1] http://lhorie.github.io/mithril/ http://lhorie.github.io/mithril/

vjeux 12y ago
While the basic idea of rendering to a virtual DOM is simple, making it work well for large applications require a lot more than a toy implementation as described in the article. In order to get adopted, React needs to coexist with existing applications/third party libraries that do manual DOM mutations. The life cycle methods are there to deal with this. React implements its own class system that supports mixins and type annotations. The plan is to change the API to use ES6 classes (we're working to improve the standard to support all React use cases). React re-implements its own event system in order to make it fast, memory efficient and abstract away browser differences. Making composable components is not as straightforward as it first seems. There are a lot of edge cases like refs, owner/parent to be handled. Then, as you mentioned, there's the diff algorithm and batching strategies which need to be implemented in a performant and memory efficient way. And provide hooks for the user to be able to give it hints via shouldComponentUpdate.
Raynos 12y ago
I have a similar frustration with React. The source code is very hard to read our follow. An ideal "barebones" virtual dom library looks like https://github.com/Matt-Esch/virtual-dom https://github.com/Matt-Esch/virtual-dom . The `virtual-dom` module was build out of frustration with the readability of react source code and is the minimal modular subset. I've also built a small framework on top `virtual-dom` to add in essentials like immutable state and event handling ( https://github.com/Raynos/mercury https://github.com/Raynos/mercury ). Whilst mercury might not be the best way to structure apps, it's an approach that is getting me far and I'm drawing strong inspiration from FRP and FP systems like Elm and om.

gcb0 12y ago

my gripe with those is that you remove UI complexity but shove usability and accessibility over some dark orifice. All those things are cool for social apps (a.k.a. fart apps) but for business ready platforms this is just silly. for example, a link that i can middle click or bookmark or send to someone, etc would be much more useful even if not as spiffy as those scrolls

cellis 12y ago

Needs a catchy buzzword. So, can we all agree to name this ... NoHTML?

jdnier 12y ago

Leo Horie, author of Mithril, has written a blog post where he explains how to re-implement some of the article's examples using Mithril (React-like client-side Javascript MVC framework): http://lhorie.github.io/mithril-blog/an-exercise-in-awesomeness.html http://lhorie.github.io/mithril-blog/an-exercise-in-awesomen...

jdnier 12y ago
Mithril docs: http://lhorie.github.io/mithril/ http://lhorie.github.io/mithril/

deleted 12y ago

[deleted]

redOctober13 12y ago

Just want to say thanks to jlongster and everyone who's commented on here; I created an account just to say thanks. I'm an amateur web dev/designer trying to figure out how to move beyond static web pages, and have read what would probably amount to a literal ton of material were it printed out, on frameworks, libraries, and more acronyms than I could imagine. Outside of HTML, JS, and CSS, even "basic" things like Sass and CoffeeScript I hadn't heard of just a few months ago, and I've since been all over the world (wide web) looking for info on ASP.NET (which my group at work decided last year was what we should be doing "web-kinda stuff" in, as well as Angular, Ember, Backbone, Knockout, Node, etc etc, and everything new (to me) that research like that comes with. The discussion here has led me to a few more things to research, but I feel it's been very helpful in helping me think critically about the vast array of possibilities a budding web designer has to deal with. I just wanted somebody to provide an objective view of "If you're going to be doing medium-complexity web apps end-to-end, then learn ______" and I still would love that, but don't think it's possible to get. The alternative, as I've been doing, is just to learn a little about everything, try to figure out the kind of things I plan to do, and then find the paradigm that works, be it vanilla technologies, something like React, Web Components, or a framework (and I've been trying to learn Angular and like it, but it's tough to grasp). It just seems like as soon as I've decided on what I want to learn, I read a new post with a title like "Why You Shouldn't Use <whatever I just decided to learn> and Why <something new I've never heard of> Is Really the Way to Go." So anyways, a long-winded thanks, but a thank you nevertheless for the open discussion here; I feel better now that I'm not trying to find the one-and-done "best" thing for making web apps in general.