12 ms·
React: Finally, a great server/client web stack
- ocfx 13y agoI don't want to write a bunch of markup next to my javascript.
- masklinn 13y agoIt's cool, you don't have to use JSX, you can just use the React.DOM functions. Or build a backend for whatever your preferred template system is, as long as the backend ends up creating nodes of React.DOM objects. Or you go with Om[0] and use EDN[1], Enlive-style[2] or hiccup-style[3] tempting. Now if you want to physically separate the view logic and the corresponding markup generation, that's more debatable: they're extremely strongly coupled (and in fairly small chunks ideally) so you often can't trivially change one without the other, and thus keeping them together makes logical sense. See Pete Hunt's presentation which lumpypua linked, it tries to make that point fairly nicely. [0] https://github.com/swannodette/om https://github.com/swannodette/om [1] https://github.com/edn-format/edn https://github.com/edn-format/edn [2] https://github.com/ckirkendall/kioo https://github.com/ckirkendall/kioo [3] https://github.com/r0man/sablono https://github.com/r0man/sablono
- squidsoup 13y agoJSX isn't markup - it's XML which translates to Reacts internal representation which looks something like: <div className='foo'>bar</div> --> React.DOM.div({ className: 'foo', children: 'bar' }) You don't have to use it - it's a convenience provided for designers (and arguably developers who have realised that templating provides a false separation of concerns). Om notably (https://github.com/swannodette/om https://github.com/swannodette/om) ignores it.
- nacs 13y ago"JSX isn't markup - it's [Extensible Markup Language]"?
- rakoo 13y agoJSX isn't markup, it's a compiler that transforms common HTML-like to custom React.DOM objects. From the doc [0]: > JSX transforms from an XML-like syntax into native JavaScript. [0] http://facebook.github.io/react/docs/jsx-in-depth.html http://facebook.github.io/react/docs/jsx-in-depth.html
- squidsoup 13y agoSorry, to be clearer, I meant it isn't HTML.
- lumpypua 13y agoYes, yes you do. Pete Hunt's talk introducing React makes a really persuasive argument that in large frontend applications, having something markup-esque along with your JS is the best way to reduce component coupling and increase cohesion. http://2013.jsconf.eu/speakers/pete-hunt-react-rethinking-best-practices.html http://2013.jsconf.eu/speakers/pete-hunt-react-rethinking-be...
- spicyj 13y agoSeparation of concerns is a good goal, and your reaction is popular with people first seeing React (including me, several months ago!). But consider that usually JS to control a view is inextricably linked to the underlying HTML and you need to modify both whenever making any change regardless -- since that's the case, you might as well combine all of the code and markup for the view in one place. Work to separate concerns, not programming languages.
- thrush 13y agoWouldn't this make it even more difficult for search engines to index your pages? Also, I'm not sure we want a full rendering on the server. That will make the page appear to have a longer loading time rather than the other way around. Unless I'm misunderstanding what you're trying to say. It does sound interesting though. I'm looking forward to your follow up posts.
- spicyj 13y agoVarious companies (in one famous case, Twitter) have found that server rendering beats client rendering for initial rendering speed. React is designed so that if you care about server rendering, you can have the best of both worlds -- using Node you can render a component to HTML on the server, then pick it up the prepopulated DOM in client-side JS once your page loads. Since the server sends down plain HTML, search engines are happy too.
- shebson 13y agoExactly this. Serving fully formed html and picking it up by a client-side framework is great for crawlers and also great for performance. In addition to React, you should check out Rendr (https://github.com/airbnb/rendr https://github.com/airbnb/rendr) - it's a really cool library for doing this via server-side rendering of Backbone views.
- woah 13y agoTried this, you have to turn your entire Node deal into Backbone. Yuck.
- sahat 13y agoDownloaded rendr, fired up the first example simple_00, opening links - Users and Repos, was painfully slow. With server MVC frameworks at least there is an indication by the browser that page you clicked on is currently loading. With client-side MVC frameworks pages usually load instantly and data arrives shortly after. In rendr, maybe it's just a terrible example, you wait 2+ seconds for a page to load and there is zero indication that page is loading.
- hamxiaoz 13y agoAny demo? Or I guess it's at the end of the series.
- andreypopp 13y agoYou can see a little demo of React + Express + Browserify + server side rendering + routing with History API — https://github.com/andreypopp/react-app-express https://github.com/andreypopp/react-app-express
- xtrumanx 13y agoThis deserves its own blog post. You can probably skip explaining client.js (which seems to be stuff one can learn from React's docs) and just dive in to server.js and the npm packages that you wrote that this app uses. I've been uninterested in React but really like the idea of server-side rendering for js-heavy apps. Besides Rendr, do you know of any other similar libraries/frameworks?
- wookimiii 13y agoI have an example of React with websockets and level-db if you want to check it out. https://github.com/wookimiii/leveldb-with-react https://github.com/wookimiii/leveldb-with-react
- cslarson 13y agoi've been learning a little about both react, meteor and using them together: https://github.com/cslarson/react-meteor-server-example https://github.com/cslarson/react-meteor-server-example
- jamesbritt 13y agoThis is confusing. http://www.reactjs.com/ http://www.reactjs.com/, which I believe predates this other react.js
- tomphoolery 13y agoNot sure anyone actually cares about that older lib since Facebook's ReactJS is what powers Facebook.
- tomphoolery 13y ago> You can choose to use this, but after getting over my initial distaste for it ("Ack! Who got markup in my code!"), I could never go back to not using it. Or you could just use HTMLbars/Handlebars. Seems like "JSX" is just a more complicated version of a Mustache-esque logic-less template.
- themckman 13y agoMost of React's novelty, I think, comes from the Virtual DOM. Your view spits out a DOM tree using the React.DOM.* objects. The JSX allows you generate the appropriate calls to those constructors by writing something that more resembles HTML. You can't just use Handlebars, etc.
- hbbio 13y agoIt's not exactly novel. Opa (http://opalang.org http://opalang.org) has been doing this for a few years...
- jbeja 13y agoOpa should be more popular.
- taivare 13y agoAlso, fruitmachine (Github)- Financial Times - Graphics Lab. They say it handles multiple pages better then React. They also claim to have had the React concept first.
- jbeja 13y agoI never hear of it, i will give it a look. Thanks
- SkyMarshal 13y agoFwiw the Lift web framework has been diffing a server-side virtual DOM back to the client-side DOM via Ajax since 2007. And I wouldn't be surprised if the concept existed elsewhere even before that. Claims to be the first to have had the idea should be taken with a grain of salt.
- rubiquity 13y agoIf you used this with Backbone, could you throw Backbone's entire View object away and use this instead?
- ssorallen 13y agoYes, that's the approach I took in our Marathon project (https://github.com/mesosphere/marathon/tree/master/src/main/resources/assets https://github.com/mesosphere/marathon/tree/master/src/main/...). The view is React, the models are Backbone, and I intend to use Backbone's Router as well. Backbone.View is never used.
- jashkenas 13y agoYes, and that's a great use case for it. But you can also use your existing Backbone Views (if they have some nice, say, formatting or data-munging-for-display logic in them) and simply replace your render function with React. The next step you can take is replacing your HTML templates with React's JSX templates, if you'd like...
- rubiquity 13y agoThanks for replying and for your work on CoffeeScript and Backbone. I might give this a try as I love Backbone's Model layer. I think I like the second approach you suggested better. That might almost turn the Backbone.Views into ViewModels, right? I'm still up in the air on how I feel about the whole JSX thing but I'm willing to give it a try.
- SkyMarshal 13y agoFwiw JSX is totally unnecessary, and more verbose anyway. Using React without JSX feels almost like using HAML or something for your HTML.
- jbeja 13y agoReact meant to replace the V in any MV* client frameworks, so yeah you can use it instead
- 13y ago
- ForHackernews 13y agoAm I the only one that kind of thinks most websites should just be static pages? Like, I get pretty irritated when I go to read a blog post on Medium or wherever and it loads a header and a blank page, and then loads a bunch of javascript (mostly tracking and analytics frameworks), and finally goes out and gets the actual content. And then if I scroll down, it has to load some more garbage from Disqus or something. PLEASE JUST GIVE ME A STATIC PAGE WITH YOUR CONTENT. I really do not care if the comments don't refresh live.
- woah 13y agoStatistically speaking, yes, you are the only one.
- infecto 13y agoTo a large degree I agree with your sentiment. I have never had to manage a site with thousands of pages but I would assume even then any template changes would not be that hard to render and then upload to a CDN.
- hrvbr 13y agoYes, Instagram is super slow because of all its useless Javascript. And it took Twitter years of optimization to make it about as fast as static HTML.
- spullara 13y agoActually, Twitter gave up on it every performing and everything is rendered server-side.
- collypops 13y agoActually, it gave up on performing _everything_ client-side, and now renders the first page server-side, and then handles subsequent rendering client-side. It found a performant happy medium, which is something I hope React will enable a lot more people to do with a lot less work.
- deleted 13y ago[deleted]
- rubiquity 13y agoI'd imagine it's something like: Don't put complex logic in React Components, put it somewhere else and test it there.
- lucaswoj 13y agoThere aren't any library features for TDD per se but standard JavaScript testing practices work on React objects (barring some weirdness around autobound methods)
- tomhallett 13y agoI wrote a jasmine helper utility to tdd reactjs components. And I handle spying on functions which are autobound by react! I just launched it last week, so I will be working on some screencasts to explain using it in further detail. https://github.com/tommyh/jasmine-react https://github.com/tommyh/jasmine-react
- lsdafjklsd 13y agoI come from an Ember.js background and its router / nested layout management is the best I have used. I like react, and have been diving into OM as well in my free time, but I'm not sure of the best way to approach routing / page transitions. When I start an app, I do not think from the bottom up, which is the react way. I want to start with the login page and redirects, or get the major page transitions down. I'll be interested in seeing how you approach that.
- lumpypua 13y agoI don't think react speaks to that, nor does it care to speak to that. It only addresses the view component of the app.
- ttty 13y agoCan anybody explain to me how to use react.js without their "guard" feature. I need my app to throw the error natively and not wrapped by the framework. Thanks (http://stackoverflow.com/questions/21040538/how-to-disable-the-guard-feature-in-facebook-react-when-working-with-pure-java http://stackoverflow.com/questions/21040538/how-to-disable-t...)
- spicyj 13y agoCan you be more specific with the problem you're seeing? An example jsfiddle/jsbin would help. If you're referring to the fact that React sometimes catches and rethrows exceptions making it harder to debug, that's something I'm planning to try to fix soon. In the meantime you can use the blue stop sign in Chrome's Sources panel to catch the error as soon as it's thrown.
- ttty 13y agoyes, that's the problem.. I don't like too much the blue because hangs all the time on jquery on page refresh...
- jbeja 13y agoI am learning how to make desktop apps with Reactjs + Backbone + PouchDB and Brackets-Shell just for fun and learning purposes, so far it has been a very exciting experience.
- hamxiaoz 13y agoI'm doing angular.js + node-webkit for my desktop app, not bad. How is your Brackets-Shell experience?
- tel 13y agoCan someone explain to me what "isomorphic" means in the tagline for the linked Director library[1]? I have no idea how isomorphism is supposed to play into all of this? [1] "a tiny and isomorphic URL router for JavaScript http://github.com/flatiron/director" http://github.com/flatiron/director"
- WickyNilliams 13y agoIt means that it can be used on client and server. Its a term coined by (I believe) the nodejitsu people in this article [0]. Airbnb also used the term to describe their rendr library [1] which aims to allow exactly that: rendering on both client and server [0] http://blog.nodejitsu.com/scaling-isomorphic-javascript-code/ http://blog.nodejitsu.com/scaling-isomorphic-javascript-code... [1] http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/ http://nerds.airbnb.com/isomorphic-javascript-future-web-app...
- okayzedd 13y agohttp://superfluous.io/glossary/read/007_isomorphic_javascript.md http://superfluous.io/glossary/read/007_isomorphic_javascrip...
- tel 13y agoWhile I like the idea man do I her hate that term. You can't just be isomorphic: you must be isomorphic to or with respect to aomething. It's like McDonald's named their new hamburger the RESTful Patty.
- rurounijones 13y agoGod I am sick of the passive-agressive "Finally, we have something GOOD! for X" titles that disparage everything that already exists for X. I saw a reddit article yesterday about "Finally a way of doing X that doesn't suck" despite there already being libraries to do X. This casual dismissal and disparaging of existing work is the kind of thing that causes people to give up on stuff (WhytheLuckyStiff for example) It also causes me to be instantly antagonistic towards said new library / feature. It raises the bar that I expect them ot reach. "Oh? You are the ONLY good way to do something? Prove it"
- danenania 13y agoYou are making the same sort of evidence-less dismissal that you accuse the OP of (whereas the OP actually explains the reasoning behind his assertion). If you want to question the post's premise, at least point to some of these libraries that you believe are on par with react. Personally, I'm not aware of any that have nearly as compelling a model with regard to performance, composability, and minimization of mutable state. But if they exist, I'd love to know about them.
- magicalist 13y agoThere's no dismissal in the GP's post. They were merely stating that pretending that some project X is an island is off-putting (and it never is one), and that by claiming that it is, you put some readers already familiar with the field in a defensive mood rather than ready to read about something new.
- antjanus 13y agoHonestly, articles like that get more attention and discussion on HN. After the first person comments about how they're sick of articles that are titled like that, a real discussion starts among the other comments which is the goal. If the author named it: "React: A great way to do this and that". It'd get 5 upvotes, 10 minutes in the primetime and die off.
- sahat 13y agoI would be interested to know what exactly React solves when we already have so many options - Ember, Angular, Backbone to do the same thing. Why would one want to increase the complexity of the application by introducing "yet another new thing" on an already complex architecture. I am just not sold on React. If someone could show a demo of why should we use React instead of, Backbone.View for example, then we can talk.
- plaguuuuuu 13y agoI'm just reading about React now, but it seems it might be appropriate when you have a lot of stuff that needs to be reused Then again, Knockout would also be pretty good at this, so I dunno. There are a lot of criteria for evaluating a framework... development speed, maintainability, simplicity, functionality. And a lot of it is better evaluated experientially rather than theoretically.
- aymeric 13y agoKnockout.js is slow. React seems fast thanks to their virtual DOM. It matters when you want to develop a web app that caters for mobile clients too.
- TheHydroImpulse 13y agoI think you could break it down into several benefits. 1) Performance -- React, with it's Virtual DOM, and the new idea to treat the DOM as an expensive remote rendering pipeline will give you a huge performance boost. 2) Compose-ability & Modularity -- While React only serves as the "view", there's huge potential for really decoupling your application. 3) Library, not framework -- The notion that React is simply a library is awesome. While I'm not a huge fan of the 1000nd super small libraries to make up your app, without any magic or complexity; I enjoy not being locked-in to a particular solution. Especially when new (potential) solutions are being presented regularly. I think modularity will win in the end. If React doesn't serve your needs in 6 months, then you can easily (still involves work, though) switch it out for something better. But, if you use something like Ember.js, you're tied into it's ecosystem and framework.
- 13y ago
- xixixao 13y agoThe lack of understanding and amount of hatred against web applications (different from web pages) is both sickening and rejuvenating. It is sad because the article is fairly clear, it describes the future of most computing (since most "human" computing will happen on the web) and it really shouldn't be hard to understand. But I am glad that most of the top commenters here instead focus on hating "webdevs". It means these people will stay on the desktop and won't create clones of desktop applications in the browser (see google docs for a missed opportunity of a better office system). History will show which way things shifted, no need to flame about it here now.
- TeeWEE 13y agoI still don't get it that you would like to write in an inferior language such as js on the server side. Cm'on its broken by design. There are a lot of better alternatives. The only reason to use .js on the serverside is that you don't know better.
- andybak 13y agoTo a degree I agree with you but I'm downvoting for the trollish and inflammatory way you phrased your comment. However - there are lots of reasons to use javascript on the server even if we accept there are superior languages.
- kitd 13y agohttp://www.ractivejs.org/ http://www.ractivejs.org/ is another similar client-side view framework that uses a shadow DOM. I don't know how suitable it would be for server-side rendering though.