7 ms·
The Road to React 1.0
- rubiquity 13y agoI absolutely love React. It's small and does what it aims to do just great. You can probably learn React in an hour or two. I don't really mind the React.createClass semantics because I'm aware of how many ways there are to build objects in JavaScript. This roadmap seems useful, but please don't add too many features and ruin a wonderful thing.
- skrebbel 13y agoI really love React. We use React for view components, and TypeScript for everything else. The ES6 class syntax would be great for us, because it'll allow our view code to look more like our TypeScript code, and still work in all browsers (because we already use the JSX compiler anyway). Nevertheless, a simple way to put JSX inside TypeScript code would be even cooler (and I suspect that CoffeeScript people might have similar feelings wrt JSX).
- lucian1900 13y agoWhat I'd really like to see is a switch to macros instead of preprocessors, so you could use (almost) arbitrary transformers together. While not always possible, it would at least let one easily mix, say, JSX and generators from different libraries.
- andreypopp 13y agoYou could take a look at https://github.com/andreypopp/sweet-jsx https://github.com/andreypopp/sweet-jsx which fences the JSX syntax inside tagged template literal.
- lukasm 13y agoCan you tell more what's your tech stack with TypeScript?
- skrebbel 13y agoSure. We're building a single page webapp here at http://izooble.com http://izooble.com. Our frontend is Model-View-Nothing with React for the view and TypeScript for everything else. We build with gulp, and avoid browserify because it makes debugging more difficult. Therefore, we generate a debug and a production build: the production build simply concats all generated JS, and the debug build keeps the separate JS files with source maps back to the .ts sources. We autogenerate the index.html. Some of us code TypeScript in Visual Studio, which is awesome. Many just use a text editor and `gulp watch`, though, which works remarkably good as well. I wish there was good TypeScript IDE support on other platforms than Windows. The entire team has previous experience that makes them think strongly in terms of classes and object. TypeScript is a very natural fit for a team like this, and made us productive very fast. Prototypal inheritance, not so sure. On the backend, we do C#, hosted on Linux with Mono (we have devs running Linux, Mac and Windows, we're just as cross-platform as your average Python shop). We use ServiceStack v3 for the API and PostgreSQL for data. We heavily rely on stored procedures and Postgres-specific features (such as returning cursor sets instead of gigantic joins) for making the backend very lean and simple. We use Docker for running stuff locally and in production. Our designers just run the backend docker containers locally with a single click (in Vagrant). They never installed Mono or Postgres anywhere. Is that what you wanted to know?
- SanderMak 13y agoWebStorm from JetBrains has good TypeScript support. You could look into that as VS alternative. Another question: our TypeScript compile-times are approaching 5/6 seconds whenever gulp watch triggers. Imo this is too long for a workable frontend workflow. Did you guys find a way to incrementally compile TS with gulp?
- skrebbel 13y agoNo, we did not. Our stack is still on the grow but we're starting to run into the same problem. That said, we have many small files, so I'm pretty certain that for us, setting up gulp to always only recompile whichever file changed (which we currently don't do) should be good enough. Afaik there's ways to do this with gulp but I did not investigate yet. Do you guys manage to only recompile changed files? Thanks for the WebStorm hint! Did not know that!
- plorkyeran 13y agoI don't think CoffeeScript would benefit much from JSX, since the sugar for function calls and object literals applies well to React. For example, one of the examples from the React page translated to plain CoffeeScript: JSX: <div> <h3>TODO</h3> <TodoList items={this.state.items} /> <form onSubmit={this.handleSubmit}> <input onChange={this.onChange} value={this.state.text} /> <button>{'Add #' + (this.state.items.length + 1)}</button> </form> </div> CS: R.div null, R.h3 null, 'TODO' TodoList items: @state.items R.form onSubmit: @handleSubmit, R.input onChange: @onChange, value: @state.text R.button null, "Add ##{@state.items.length +1}" A hypothetical CSX would probably be more along the lines of Haml or Slim than XML syntax (closing tags would be pretty weird and out of place), and plain CS isn't that different from them already.
- rubiquity 13y agoIn CoffeeScript you can use backticks and still use JSX. Example: `/** @jsx React.DOM */` Todo = React.createClass render: -> ` <div> <h3>TODO</h3> <TodoList items={this.state.items} /> <form onSubmit={this.handleSubmit}> <input onChange={this.onChange} value={this.state.text} /> <button>{'Add #' + (this.state.items.length + 1)}</button> </form> </div> ` Just remember when compiling the CoffeeScript files to pass the bare, and --no-header flags. coffee -bc --no-header todo.coffee
- jbeja 13y agoIs worth notice that there is also: https://github.com/atom/react-coffee https://github.com/atom/react-coffee. class Welcome extends Component render: -> @div -> @text "Hello" @span @props.name component = new Welcome(name: "World") element = component.buildElement()</pre>
- skrebbel 13y agoNo, that is not sufficient. The point is getting designers to shift paradigm and start writing React components. This is a major shift, because while the designers I've worked with have all done a little JavaScript here and there, it's seldom much more than copy/pasting some jQuery code from Stack Overflow. HTML/CSS is their home turf. To you, the CoffeeScript literals might be just as good as the JSX stuff, but to someone who's already out of his comfort zone because the markup is in the middle of all kinds of weird React.createClass stuff, it's a very major difference. JSX really strikes a sweet spot here.
- mambodog 13y agoCan't help you for Typescript, but for Coffeescript I've implemented a basic rewriter for JSX-in-Coffee: https://github.com/jsdf/coffee-jsx-transformer https://github.com/jsdf/coffee-jsx-transformer
- aboodman 13y agoReact is awesome. It is the biggest change to how I approach web development that I can remember over the last 10+ years. It has made many things that used to be laborious and error-prone fun and robust (URLs for every state in a SPA, enabling search crawlers for SPAs, live updates, infinite/virtual scrolling, unit testing). I keep finding more things it works really well for. I really need to write an article about this at some point. Anyway, if you haven't spent some time playing with it I really recommend doing so.
- vineire 13y agoI would love to read that article.
- jholly 13y agoReact is absolutely incredible! They only thing i'd ask for is better support for mobile applications. Namely, touch gestures (tap, swipe, pinch, etc). Since react uses synthetic events, perhaps pointer-events can be baked right in so that it's backwards compatible, replacing touch* events.
- nebstrebor 13y agoI've done sufficient with both Angular and React to have decided to go with React for next our project. Its a better fit for this particular project because the "reusable components" paradigm fits what we're doing, which includes building a non-model-specific framework that we can reuse for different models, where the framework renders slightly differently based on meta data provided with the model. We'll probably use Backbone for the model (& meta) & router. I like Angular, and would like to use it for a project that's more concrete and less meta.
- jholly 13y agoSomething about Angular rubs me the wrong way. I think it has to do with dirty checking. Either that or the scope magic that happens. React, comparatively, is quite straight forward. I hope it stays that way, a minimal API and no magic. The more I look into react the more I wonder if some intermediary representation of the DOM ought to be standardized so that a native "diff/batch" algorithm can be provided as regular functions. I think react would help this cause if it can break up into several projects (react-events, react-virtual-dom, react-dom-diff/batch, etc). Perhaps other projects can adopt parts of react into their own frameworks. Just a thought.
- jordwalke 13y agoCore team member here. That's excellent feedback and we are definitely going to be pushing in that direction where we can. API simplicity will always be a primary goal and a modular core implementation will help advancement of mobile support and testability. The event system is already self contained and shouldn't depend on anything in React at all.
- 13y ago
- jbeja 13y agoI feel like, all the comments in this thread are spams.
- deleted 13y ago[deleted]
- ineedtosleep 13y agoNot to be confused with react.js[0], which is the first result if you search for "react js" in DDG. [0] http://reactjs.com/ http://reactjs.com/
- sehr 13y agoI think this is going to be needed less and less in react-related posts, that repo hasn't been updated in over 3 years.
- arenaninja 13y agoI actually landed on that link a week ago, and gave up on learning reactjs. I've heard of the various JS frameworks over the past two years, but only until this month I was considering using one (NIH mentality @ work). I tried out AngularJS and it made sense, but I had issue after issue with npm deps. I tired of web searching, and went to my default search engine (DDG) to look up reactjs. Just an anecdote I felt like sharing. I upvoted grandparent because someone took the time to downvote him, but believe it or not, I wasn't going to click the link until I read the commends and had him clarify it for me.
- sehr 13y agoWeird, I suspect it'll fall of the top ranking pretty soon though. React is really interesting though, and from what I understand it's possible to use it with Angular, seems like you're on the right track!
- mrcwinn 13y agoI haven't yet put React in production (possibly in the next month or so), but so far working with it has been fantastic. In my case, I've been refactoring some complicated Backbone views as React components, but still mixing in Backbone models, collections, and the event bus. So far, the event system has proven to be vital. Since React has one-way communications from parent to child, the existing Backbone event system is useful if you need to trigger an event back up the chain. Every time I finish up a React component, I'm blown away by how much simpler (and shorter) the code is compared to a traditional Backbone view — particularly when multiple subviews are involved. I've tried just about everything - Meteor, Ember, Angular, and others. Meteor is of course its own special case, but of the client-side libraries and frameworks, nothing's quite felt right in my opinion. Backbone is still going strong for me, and React gives it a whole new life. JSX can be a tough pill the swallow — and I should note it's entirely optional — but I've found it really useful to have your component markup just lines away from your component logic. Embrace it. :-)
- AdrianRossouw 13y agoI think backbone is going to be here for a while, because I don't actively expect it to get more complex over time. every release just feels like it's tuning it up. Oh, and you should check out marionette's extended event system. It's quite useful.
- mrcwinn 13y agoThanks! And I agree. I have Backbone code from quite a while ago and it's still holding strong today. The thing with Backbone, as opposed to some more convention-orientated frameworks like Ember, is that it's as good as the programmer. And if you are an experienced Backbone developer, that can be _damn_ good. If Backbone had any weakness, it was managing subview chaos at large scale. React does a great job solving that - and introduces other opportunities for better patterns. Thinking in terms of reusable components, and maybe even using those components on the server side as well, is pretty exciting.
- AdrianRossouw 13y ago
- 2bit 13y agoLoving React, it gives me the same joy that learning D3 did but offers a more powerful abstraction. I've been able to render the same markup on the server as on the client using Browserify. If you like D3, you should give React a try.
- ludwigvan 13y agoI love React too! Just wanted to share some anectodal evidence about an angular app I am in the process of rewriting in react. For now, I am reimplementing the main functionality as a directive in react, keeping other angular parts. (Angular directive is there to make the transition seamless, while keeping other parts like routing etc. in angular) Performance had become unacceptable in angular and hard to track. Mutable state with two-way bindings made it hard to reason about. React makes state much easier to reason about. App performs noticably faster (three/four times faster), memory consumption is halved. React devtools is very helpful to inspect the virtual DOM. Integration with other libraries is very easy, it doesn't try to own your app like Angular. Getting up to speed with react is very easy too with a small and very nice to use API. I would encourage everyone doing webapp development to check it out, at least for a demo app to get a sense of it. Go through the tutorial on the site and you'll feel comfortable within hours. Had I mentioned that I love React?
- andyl 13y agoWe started in Backbone, then migrated to Angular to mitigate nested view chaos. Latest rewrite drops Angular in favor of React and a bit of Backbone, mostly to reduce the learning curve for new devs. Using React for views is the simplest/most robust stack we've experienced. Easier to share/reuse code, easier to debug. React with Coffeescript has been super great - dropping JSX lowers the learning curve even more, especially since we already use and love slim, and Coffee/React sort of resembles slim.
- hamxiaoz 13y agoI'm using Angular and I'd like to try react. Is it easy to transform an angular project to backbone + react? Do you have to use Marionette?
- freyr 13y ago>> then migrated to Angular to mitigate nested view chaos. For the record, and for those who are unfamiliar, "nested view chaos" isn't an inherent characteristic of Backbone, and it can also be mitigated by writing good, thoughtful code (often easier said than done). Using React views can make life easier, since composition of nested components is part of the design.
- oh_sigh 13y agoYeah...I imagine that the original poster is going to be making a very similar post in 1 year, saying "We started in React, but switched to <sexy new tool> because <some fault of our own that we then blame on React>"
- RivieraKid 13y agoReact is the next jQuery, it has a solid chance of becoming similarly uniquitous. It's a paradigm shift, Angular and Ember are basically obsoleted.
- ebryn 13y agoEmber is going to be as fast, if not faster, than React with HTMLBars integration. Expect to hear more about that in the coming weeks. For more info, check out my talk at the Ember NYC meetup here: http://bit.ly/P2Wu6X http://bit.ly/P2Wu6X
- lomnakkus 13y agoSpeed is not why React is great. It's great because it's so unbelievably simple (conceptually) and does what it does robustly and clearly.
- iamstef 13y agoo_0) .... walks away slowly....
- zghst 13y ago<3 React! It is a serious paradigm shift that has finally brought the #1 thing that I care about the most! Performance With React, my app got around x13 more performant