13 ms·

Why We Moved to React

158 points by sorcercode 11y ago

tracker1 11y ago
In this way, it seems that React makes a lot of sense as a migration path. Honestly, I find flux/redux and other unidirectional data flows are much easier to scale than most patterns for UI development, especially class/oo ones. That said, React is just a part of it, and some flows are counter-intuitive in React. This must be said because it is true... that said, I find that React is far better, all around than most of the other options I've used, and I've been building web apps for two decades now. I'm currently working on supporting an Angular 1.x app, have a proof of concept built in Redux+React, and another app I've been instructed to write in Angular 2. I've also built a couple of SPAs using Backbone. In the end the Redux flow has meant less code as features are added, and I'm working towards writing my Angular 2 app with that in mind. Modern React takes a lot of tooling setup to get started (or starting with someone's existing boilerplate), but the shear amount of boilerplate code that you have to write with Angular2 is just unnerving. The DI model is awkward, and I'm not enjoying it at all... The Redux+React proof of concept is for half the functionality of the Angular 1.x app, I'm pushing for the change in the next version... with about 1/3 the functionality, the code is 1/10th the size, and there's a lot less complexity... A single state tree, in the end is easier to reason with, even if you're only looking at part of it. It's much easier to deal with, even with scale than trying to add more message channels in an application between components. Getting used to separating actions via a single dispatcher, and the resulting state changes takes getting used to... but so much easier in the end.
- jsprogrammer 11y ago
  Do you know of a worthy Redux+React boilerplate project?
  - sidmitra 11y ago
    There're some here: https://github.com/facebook/react/wiki/Examples https://github.com/facebook/react/wiki/Examples
  - phereford 11y ago
    https://github.com/coryhouse/react-slingshot https://github.com/coryhouse/react-slingshot is my go to boilerplate.
  - carsie 11y ago
    https://github.com/GordyD/3ree https://github.com/GordyD/3ree is a good starting point for React + Redux (+ RethinkDB).
    - tracker1 11y ago
      My anagram is r3k[1] (React, Redux, RethinkDB, Koa) ... Still a work in progress. Wanting to get to the point where I have an adaptive login (local account, google, facebook, twitter) and some public/private pages with universal rendering. Been working on it as time permits. [1] https://github.com/tracker1/r3k-example https://github.com/tracker1/r3k-example
  - afarrell 11y ago
    http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial.html http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial... is good if actually want a hand-holding walkthrough rather than just a boilerplate.
  - acemarke 11y ago
    I've got a list of some particularly good ones at https://github.com/markerikson/react-redux-links/blob/master/boilerplates-and-starter-kits.md https://github.com/markerikson/react-redux-links/blob/master... . There's also a link to a little "starter kit search engine" someone built that lets you filter about 50-60 of them by various attributes.
- tomekowal 11y ago
  Have you checked Elm? I know there is a big difference between switching frameworks and entire language, but the benefits are really nice. Elm really enforces unidirectional data flows throughout entire application. For me it's like react on steroids.
- iSnow 11y ago
  > with about 1/3 the functionality, the code is 1/10th the size Yeah, that's the usual 80/20 rule at play.
- doczoidberg 11y ago
  Angular CLI helps much with the Angular 2 boilerplate code: https://github.com/angular/angular-cli https://github.com/angular/angular-cli
- novaleaf 11y ago
  I've been using Redux, and it is pretty much required if you have multiple components who need to update when a single state changes.... but pretty unhappy as the amount of scafolding required. It's not nearly as "isolated concerns" as it should be.
  - alias240 11y ago
    Take a look at MobX. It's a different paradigm that requires very little boilerplate and results in more isolated components that react independently upon changes to state. https://github.com/mobxjs/mobx https://github.com/mobxjs/mobx
  - true_religion 11y ago
    Right. I can give two alternatives. 1. Elm. I was just about to throw away the idea of Flux in a web app till I saw TodoMVC implemented in Elm. In Elm everything is immutable, and as a functional language, it has a lot of helpful syntax to help you deal with immutability. Shoehorning immutability into Javascript seems to require a lot of scaffolding by comparison. 2. MobX, it's been mentioned elsewhere but I can't help but sing its praises. Writing in MobX means that using controllers/dispatchers/actions/supervisors or another form of managing dataflow returns to being an architectural concern you can pattern to your application's needs, rather than being something that's required by default for anything more than a Todo app.
phat4life 11y ago
Personally, I prefer more web-component like frameworks. Vue.js is more usable, and easier to understand than React, but stuff like React Native is why React.js is worth learning. I strongly dislike the JSX syntax as well. Its messy, and difficult to read. I would like my to write my components as dom nodes, like with Vue.js, Riot. The way that react.js handles css, is also messy. I would rather just defined a <style> tag like in Vue.js.
- madeofpalk 11y ago
  What is it that you don't like about react and css? React actually has nothing to do with CSS - 'by default', you just include a stylesheet as normal. If you want to upgrade, you can just something like CSS Modules with webpack's css-loader to make per-component stylesheets a lot better.
- matroosberg 11y ago
  React does not require you to use JSX. Writing views with React.DOM is actually a quite nice alternative. This article gives an explanation: https://www.packtpub.com/books/content/using-reactjs-without-jsx https://www.packtpub.com/books/content/using-reactjs-without... However, newer React and Babel versions no longer compile JSX to React.DOM methods as the article shows, but other methods. Example for Babel: https://babeljs.io/repl/#?experimental=false&evaluate=true&loose=false&spec=false&code=React.renderComponent(%0A%3Ch1%3EHello%2C%20world!%3C%2Fh1%3E%2C%0Adocument.getElementById('example')%0A)%3B%0A%0A https://babeljs.io/repl/#?experimental=false&evaluate=true&l...
- mercurial 11y ago
  > I strongly dislike the JSX syntax as well. Its messy, and difficult to read. I've read quite a few criticism of JSX but "difficult to read" is a first. It's not significantly different than any templating system out there (eg, ERB). It's just XML with interpolated code, what's confusing about it?
  - BinaryIdiot 11y ago
    > what's confusing about it? In my opinion the confusing part is mostly the fact that taking a markup language and embedding it into a scripting language is really awkward. You have two completely different types of syntax not only existing together but working together. Also I've worked on multiple teams where designers will re-style and even change the markup of pages but trying to get non-developers to do this with JSX is just painful. I find HTML and the DOM API awkward at times but since that's the final state I just prefer to work with that.
capkutay 11y ago
> As an experiment, we tried writing a separate app to try out the popular Flux library. Is there one 'popular Flux library'? Perhaps they meant redux? No other mention of it in the article.
- phereford 11y ago
  There are lots of popular Flux libraries. https://github.com/acdlite/flummox https://github.com/acdlite/flummox https://facebook.github.io/flux/ https://facebook.github.io/flux/ https://github.com/reflux/refluxjs https://github.com/reflux/refluxjs http://fluxxor.com/ http://fluxxor.com/ https://github.com/reactjs/redux https://github.com/reactjs/redux Each of these appear popular in their own right. Given they mentioned Flux, it probably is the actual Flux library.
  - dominic_cocch 11y ago
    Yep, it was the actual Flux library. However, we're not totally settled on that choice just yet.
    - phereford 11y ago
      Awesome! I had chosen flux for one project I was on and really enjoyed it! Thanks for the post!
  - girvo 11y ago
    Flummox, while amazing (and my favourite) has been deprecated in favour of Redux. That said, my personal replacement is Alt.js[0], which has the same style of architecture and API that Flummox had [0] http://alt.js.org http://alt.js.org
- honua 11y ago
  Redux is best http://github.com/rackt/redux http://github.com/rackt/redux
b34r 11y ago
The forceUpdate API is murderous for performance, since it causes the entire tree to do a vdom rerender, bypassing shouldComponentUpdate() checks. Should really try and find another way to trigger a re-render.
- dominic_cocch 11y ago
  Definitely agree. In our real code we're much more sensitive of performance. This was just a quick way to show a simple way Backbone can be used with React. I think it'd be interesting for us to do another post in the future about how we measure and improve performance within our React apps. There aren't a ton of articles about this with relation to Bakcbone, it seems. Thanks for giving it a read!
  - rgbrgb 11y ago
    Would definitely like to read that one. We have a backbone/react app and generally use your example pattern, but I can see how it would take a toll on performance at some point. What's the general pattern you use if not forceUpdate? I suppose you could use something like @setState(model: model) but you still have mutable models to deal with in shouldComponentUpdate. Have you guys come up with a good way to reconcile backbone's tendency towards mutation and the performance benefits of immutable props?
    - dominic_cocch 11y ago
      Yes and no, really. We mostly keep our backbone models as props and keep them immutable by pure convention. You really could just call set() on one of them and cause some problems. This isn't great long term, of course. Code reviews and code style guides help here for now. We've also at times converted backbone models to simple objects at the parent level and passed them down that way. Keeps things simpler, but we lose some of the niceties of the backbone model api. Once the models are objects, you can use componentShouldUpdate pretty defensively if you need. We've also used throttled and debounced functions for anything which gets hit very heavily.
- AgentME 11y ago
jorgecurio 11y ago
one of the biggest changes was accepting that React is different from old way of doing things like with jquery. I used jQuery to build 4k loc applications. It's a fucking blast when you are just wiring up the template and watching the UI come alive...to me that was the power of jQuery. No need to think, just go and make everything stick like glue. Angular.js was also right in that regard....add annotation to HTML. but this shit doesn't scale when application grows. I'm still frustrated that I can't write shit in jQuery anymore because HN have collectively ruled against it and I guess at 4k loc it has become very hairy. But I still argue if your needs are pretty small, like make a small widget app that has two buttons and makes ajax request to an endpoint, no other frontend framework can even touch jQuery in this territory.... In fact the overhead of having to think about states, structures, components organized in hierarchy...this shit adds to my stress and I can't experiment fast...but then also was the stress from not being able to add new features because the jQuery app grew in complexity.... difficult times gentlemen difficult times. I've been holding on to jQuery since 2009...maybe it's time to venture out entirely with React.js? Or should I crawl back to the comfortable cave that is jQuery where I can make anything very quickly.
- baby 11y ago
  I'm pretty sure you can use both. I use jQuery more like an enhanced javascript. React I use for designing real interactive components. If you have a small javascript feature to implement, just write in jQuery.
- petepete 11y ago
  I'm also still in the jQuery cave, for the same reasons you are. For most of what I do, it's enough, but on my current app, there are a couple of places (complex booking forms) where the code can get messy really fast. I might give React a try when the opportunity presents itself.
- leeoniya 11y ago
  you may find https://github.com/leeoniya/domvm https://github.com/leeoniya/domvm interesting. Disclaimer: mine, and has about another month to 1.0 stability.
- 11y ago
philmander 11y ago
It's clear why using React in your Backbone views is beneficial, but I'd be genuinely interested to know what tangible benefit moving the models (and, thus, entirely from Backbone I guess) to flux/redux etc brings you, besides just keeping up with the latest conventions.
- dominic_cocch 11y ago
  The backbone model api was made with totally mutable data in mind. React, on the other hand, only works well with immutable props and some mutable state in the top levels of components. That's our first issue, for sure. Backbone also has a dependency on jQuery, which isn't very useful in React apps since mutatuing the DOM (one of jQuery's main purposes) is a no no. So most of the Backbone library isn't very useful to us anymore. I do still really enjoy the backbone way of fetching and saving models, especially in a Rails context. But I think we can get those features in other ways.
  - petetnt 11y ago
    That's pretty much experience too: our apps that use React + Backbone, I find myself more and more using a fraction of the features (very basic API integration (fetching, saving) and the router), both of which could be easily replaced with something else. Not that it would be particularly hard to extensively use Backbone with React, it's just that there seems to be other (better) ways to do the same things too.
  - pramodliv1 11y ago
    I use React and Backbone too. Here's the source code: https://github.com/pixyj/feel/tree/master/client/app https://github.com/pixyj/feel/tree/master/client/app I use jQuery for animations and also for non-crud pixel-level DOM manipulations as in the graph shown in the home page: https://conceptcoaster.com/course/python-tutorial/ https://conceptcoaster.com/course/python-tutorial/ In the graph, I need to dynamically calculate height of certain elements based on the height of others. The height cannot be predicted in advance. Can React work for such cases too?
    - 11y ago
ezequiel-garzon 11y ago
As I go over the impressive list of big sites adopting React [1] I feel there must be something wrong with this current survey [2], which states a mere 67 of the top 10000 sites are using it. Any insight will be welcome. [1] https://github.com/facebook/react/wiki/Sites-Using-React https://github.com/facebook/react/wiki/Sites-Using-React [2] http://trends.builtwith.com/javascript/javascript-library http://trends.builtwith.com/javascript/javascript-library
- chrischen 11y ago
  While easier than before to do server side rendering, it's still non trivial to do a react app that preserves SEO and renders on the server if your app isn't already a nodejs app. It would require running either V8 to render on the server behind whatever language your backend is already written in, or calling node to serve your backend, relegating your existing backend to an API (and tying the backend rendering to your API along with the Frontend to use the same API isn't simple either).
  - dominic_cocch 11y ago
    That is definitely one limiting aspect for some places. We actually have a similar issue, since we're a Rails shop first and foremost. Luckily there are a few tools we can use to make it work well with Rails. Maybe a future post! I also think jQuery and other libraries with large usage are kind of Swiss army knives, so more people have more use for them. I do believe over time React will become as pervasive as jQuery. Or possibly even the DOM api will eventually allow a similar style of building things natively. This seems to be happening to jQuery now :)
  - girvo 11y ago
    Indeed. We had to tackle this for Expedia's Viewfinder[0] (which was done by utilising nodejs as the server), and we're tackling it again for another project that has it's server-side rendering done in PHP. Interestingly, we are leveraging the v8js PHP plugin to be able to execute JS from inside a PHP context, sharing variables between them as needed. Though I'm not convinced its the perfect way of tackling this problem, there's still a lot of quirks and bugs. [0] https://www.expedia.com/pictures https://www.expedia.com/pictures
kensign 11y ago
No matter how I try to accept it, it is a really bad idea to embed views into business logic. You have no clear separation of concerns and this can create a lot of headaches as the sophistication of the application grows. Instacart is a great product, but it has a lot of room to grow still. What happens when you get into some deeper aspects of UX? I presume you do your own UX research and these highly segmented views are going to be a pain to manage. You'll also need to worry about how you run BDD tests for specifications and scenarios. How can this be achieved in React as you write test suites for user stories and non-UI acceptance tests? How will this impact your continuous delivery/integration systems as well? You'll have to rewrite all your test suites into Jest, right? There are architectural trade-offs for sure. Can you definitely say you've performed a thorough analysis before making this decision? There's a difference between having a clear strategy to move from one tech to another and knowing that the migration will not just bury you into a deeper whole than the one you think you're escaping. http://aurelia.io/ http://aurelia.io/ is based on webcomponents (MVVM), ES6, and current web standards. It's amazingly simple and good architects can use their own structural patterns to create code that can actually scale with the product. DDD and BDD methodologies mesh perfectly into the development workflow, especially with Agile product development. I wish you well, but I really think React is a short sell with dire consequences.
- judofyr 11y ago
  There's nothing in React which forces you to embed the views into business logic. React is just a view framework. How you structure your code is entirely up to you.
- sehr 11y ago
  There's nothing in React that forces you to use Jest or rethink your testing process.
- anewhnaccount 11y ago
  There is a clear separation of concerns. The React component is the view. React doesn't tell you what to do with the other bits (although people seem to have plenty of different ideas). There's generally less lock-in to a particular way of doing things with a view library like React than with a whole framework like the one you're promoting.
ridiculous_fish 11y ago
React has been quite nice, and very fast to work on. But there's one aspect that's concerning. You have state and props, and the React tree diffing algorithm attempts to make some minimal set of changes that preserves state. However this algorithm is a heuristic, and so it's possible to hit a case where your component gets a different component's state. For example, say there's a text field which has keyboard focus. Another text field is added above it: the keyboard focus should stay in the bottom text field. But React has no notion of identity and doesn't know whether the top or bottom text field is new. All it sees is a diff from one text field to two, and who knows which one will get focus! React's answer to this is to introduce identity by assigning each component a key, and that works. But this is reactive: I notice a bug, and fix that case by assigning a key, but still most elements do not have a key and it is not reasonable to add one. I'm stuck hoping that the opaque tree-diffing heuristic is correct enough for my case. How do other React users handle this? How do you go from "seems to work" to "I am certain React's tree diff will assign the right state to the right components in all cases?"
- dominic_cocch 11y ago
  This should really only be an issue when the children of an element are all the same type of element and are at the same depth level. For example, this is very common for li elements in a ul element. We try to keep the structure of the html so that wrappers generally keep different UI components separate from each other. In other cases, like in the example in the blog post, we just use the index from the .map() loop to add a key to every element we know will need one. React should also warn you when this is an issue.
  - bsimpson 11y ago
    Moreover, you'll get a warning in the console if there are ambiguous children telling you to add keys.
  - ash 11y ago
    > we just use the index from the .map() loop to add a key to every element Doing this could hide weird bugs. Let's say we render a list of posts with "remove" button for each one. The user clicks on "remove" button, we modify the underlying this.state.posts. And on next re-render removed post key would be assigned to the next post! The next post could inherit just-deleted post handlers, for example. It's much better to use unique keys like database ids.
kzhahou 11y ago
Dominic, when did you start rolling out this change, and how long have significant parts of production been on it? I'd be very interested in a follow-up in a year, once it's grown to the size of the backbone app it's replacing, and been battle-tested (in prod and in development)
- dominic_cocch 11y ago
  We've slowly been growing our React presence on the site for almost a year now. At this point, we're fairly close to the size of the original Backbone app as far as views are concerned. We're still somewhat tangled in with Backbone, but it's been a great success internally. Performance-wise, development speed-wise and also developer happiness-wise we haven't hit too many snags.
bschwindHN 11y ago
I like the idea of React. I like it even more when you take out all the frills and boilerplate. If you haven't already, I would encourage you to give Clojurescript and Reagent a try: https://reagent-project.github.io https://reagent-project.github.io I decided to use it for a small client for a chat server my company runs. The initial environment setup on OS X wasn't the smoothest, but once I got that taken care of the actual development was very pleasing and quick. You need to know just a few core concepts and then you can more or less replicate the common patterns you use in React - application state, component properties, local component state, initial values for local state, etc. Along with that, you get immutable data structures and the benefits of the Google Closure Compiler out of the box. Give it a shot!
- dm3 11y ago
  If you're ready to check out Clojurescript, I strongly recommend trying out Hoplon: https://github.com/hoplon/hoplon https://github.com/hoplon/hoplon It requires a certain shift in thinking when coming from pretty much any other framework. However, it avoids all of the unnecessary complexities of React by exposing the DOM elements directly as functions. The mindshare behind it might be low compared to Om or Reagent, but the people that are using it are pretty active at Clojurians slack channel #hoplon and on IRC (freenode, #hoplon). It's also FRP-based and pretty efficient. Highly recommend!
Kiro 11y ago
I'm interested in learning more about reusability. One problem I have with React is that I've made this component called Product and then I need another Product component but in a different context, for example in a listing with a thumbnail. Much like the carrot example. How do you approach this exactly? Shouldn't it be based on the same component somehow?
- astazangasta 11y ago
  I think the vague answer is 'use mixins', but they are generally unsatisfying. One hopes that using ES6 classes to define react components this way would allow proper inheritance, but the whole ES6 thing is a mess that breaks a bunch of other things (notably autobinding this). Upshot is my code remains repetitive. Where possible you can use composability, extracting common function into a subcomponent, but this doesn't always make for neater code.
  - wereHamster 11y ago
    Ugh no. Please don't use mixins or inheritance. Composition is the way to go. https://en.wikipedia.org/wiki/Composition_over_inheritance https://en.wikipedia.org/wiki/Composition_over_inheritance
    - Kiro 11y ago
      Do you have any example React code using composition?
      - wereHamster 11y ago
        Same way you compose functions or HTML elements. Functions: add(1,multiply(2,3)) HTML: <div>foo <span>bar</span> </div> React: <Container> <Header>foo</Header> <p>content</p> </Container>
        Bahamut 11y ago
        To be pedantic, that is not quite composition - I've made this exact mistake before too. Composition is where you have a function f o g (o being the traditional mathematical notation for composition), where (f o g)(a) = b satisfies g(f(a)) = b. Composition is a useful tool, and so is writing functions like this, but they are two different ideas.
Aleman360 11y ago
As a C++/XAML mobile app dev, I'm baffled by how a common UI like this (lots of lists?) requires such a deep dive.
- wanda 11y ago
  To attract young, hip developers, or to justify incumbent hip developers.
- badsha 11y ago
  Saw your comment in another post about how the Start Menu is really just an XAML app. I was wondering, how did you guys make it transparent and blur? I have been trying to figure that out for the past 2 days and have had no success yet.
drdaeman 11y ago
I must've done something wrong, but I haven't attained that "zen" part when I tried to use React. On the contrary, it felt like I'm writing a giant pile of boilerplate code "just to use React", where there shouldn't be any. A simple, almost ToDo-like form quickly grew to 7 files, averaging 100 SLOC each, with a air-filled boilerplate-feeling classes (yet not lacking works-by-convention magic) that juggle data through those render -> onClick={e => this.onItemAdd(e)} -> onItemAdd -> addItem -> update -> UpdatePromise -> handleUpdateItems -> render loops. Sure, everything's logical but that feels like I'm deeply stuck in the wheel of Samsara, writing code for its own sake and not attaining any Enlightenment. ;)
- dominotw 11y ago
  > render -> onClick={e => this.onItemAdd(e)} -> onItemAdd -> addItem -> update -> UpdatePromise -> handleUpdateItems -> render loops you seem to have fallen prey to overengineered examples. that example should be >> render -> onClick={e => this.onItemAdd(e)} thats it, data change should re render the tree.
  - drdaeman 11y ago
    Well, maybe. But I also wanted it to sync up with the server too (onItemAdd actually updated component's own state with extra "save in progress" flag, handleUpdateItems would clear it later).
    - dominotw 11y ago
      well then you are doing much more than A simple, almost ToDo-like You can do things like writing sever-syced component,mixin ect .
- jonheller 11y ago
  Me either. I understand the benefits but for side projects and stuff it's just not a very fun language to learn or use. Even Angular, with it's weird paradigms, seems more natural.
aioprisan 11y ago
I was checking out their careers page and they're looking for a senior engineer to lead 5 engineers, but they require masters degrees? Really? Newsflash: a one year degree isn't what's needed to be a successful team lead.
- jackdempsey 11y ago
  The next bullet point: "Employer will also accept a Bachelor’s degree or foreign equivalent in Computer Science, Computer Engineering, Information Technology, or related technical field and 5 years of progressive, post-baccalaureate experience in a related field." We don't require a Masters. Some engineers have one (or PhD even) but that's much less important than being a great engineer.
  - aioprisan 11y ago
    You missed my point entirely. A one year degree isn't the equivalent of 5 years of post-bac experience in the field, and that is your first bullet point, the "expected" and most discouraging one - folks stop reading after that. That some folks have masters or PhD degrees is great, but shouldn't be an expectation for a team lead role. I'm sure you'll have issues trying to attract talent with that kind of messaging and expectations.
carsongross 11y ago
Peguy's quote: "And it will never be known what acts of cowardice have been motivated by the fear of looking insufficiently progressive." becomes more and more relevant to the tech world. We are managing a few lists. How is this so complicated?
- rgbrgb 11y ago
  If you have a less complicated way to build a big beautiful app like instacart, I'm all ears (that's why I'm reading this). Or are you just saying we should give users a CLI and be done with it?
  - carsongross 11y ago
    http://intercoolerjs.org http://intercoolerjs.org
    - rgbrgb 11y ago
      Nice, looks very simple. But I don't see how it would make it simpler to build an app like instacart. Try instacart, the app is borderline magical. I've never seen a bug with their cart or the awesome realtime-multiplayer shopping. I'm guessing if you tried to build an experience like that with just intercooler, your codebase would end up being significantly more complex.
pmlnr 11y ago
https://www.instacart.com/ https://www.instacart.com/ -> among the JS loaded: static-react-base-{id}.js 273KB. It it just me thinking that ~300KB of code, about to be evaluated in the browser is a bad idea?
- GoToRO 11y ago
  I feel the same, but people use it because they can deliver things faster (and get the money sooner). Sure, after that the client will maybe get complaints about website crashing user's mobile browser on cheap phones but those phones will get replaced soon (5 years?) so the problem will fix itself. On a second thought, how do you access the Contact form on a website you can't even load? :)
ausjke 11y ago
for newcomers is it too hard to find all the pieces that need to work with React to make a final product? I just started with Angularjs 1.x, while it has its faults I found it's easier to get started. maybe React is better suited for the experienced who knows how to bootstrap all the components? I'm interested in learning React _after_ I get more familiar with the javascript-ecosystem, and it seems to start with angularjs will be a good approach?
partycoder 11y ago
Saying CoffeeScript is simpler than JavaScript is the same as saying: I am going to make traffic simpler by removing lane delimiters, traffic signaling, lights, street names. You end up with a "simpler" language, but it is also less safe to use. Python will throw you an error with inconsistent indentation, but that's not the case in CoffeeScript. So any little messing with the whitespace, which is impossible to infer automatically, and you have a bug. Then, you can massively auto-format JavaScript, use great tools that inference type information from documentation, etc... but with VomitScript, you are pretty much on your own. In fact using an advanced editor and nano will probably make no difference. "Duh but I want to type less"... NOBODOY CARES about you typing less. If you care about typing less use templates in your editor and autocomplete.
ConAntonakos 11y ago
What is Instacart using for its routing logic?
- dominic_cocch 11y ago
  For now we use Rails on the server and a single backbone router for the the client side. This isn't how we want it stay. :) We do have a couple side apps internally using React Router. We've liked it so far, but it's a pretty basic implementation.

158 points by sorcercode 11y ago

In this way, it seems that React makes a lot of sense as a migration path. Honestly, I find flux/redux and other unidirectional data flows are much easier to scale than most patterns for UI development, especially class/oo ones. That said, React is just a part of it, and some flows are counter-intuitive in React. This must be said because it is true... that said, I find that React is far better, all around than most of the other options I've used, and I've been building web apps for two decades now. I'm currently working on supporting an Angular 1.x app, have a proof of concept built in Redux+React, and another app I've been instructed to write in Angular 2. I've also built a couple of SPAs using Backbone. In the end the Redux flow has meant less code as features are added, and I'm working towards writing my Angular 2 app with that in mind. Modern React takes a lot of tooling setup to get started (or starting with someone's existing boilerplate), but the shear amount of boilerplate code that you have to write with Angular2 is just unnerving. The DI model is awkward, and I'm not enjoying it at all... The Redux+React proof of concept is for half the functionality of the Angular 1.x app, I'm pushing for the change in the next version... with about 1/3 the functionality, the code is 1/10th the size, and there's a lot less complexity... A single state tree, in the end is easier to reason with, even if you're only looking at part of it. It's much easier to deal with, even with scale than trying to add more message channels in an application between components. Getting used to separating actions via a single dispatcher, and the resulting state changes takes getting used to... but so much easier in the end.

jsprogrammer 11y ago
Do you know of a worthy Redux+React boilerplate project?
- sidmitra 11y ago
  There're some here: https://github.com/facebook/react/wiki/Examples https://github.com/facebook/react/wiki/Examples
- phereford 11y ago
  https://github.com/coryhouse/react-slingshot https://github.com/coryhouse/react-slingshot is my go to boilerplate.
- carsie 11y ago
  https://github.com/GordyD/3ree https://github.com/GordyD/3ree is a good starting point for React + Redux (+ RethinkDB).
  - tracker1 11y ago
    My anagram is r3k[1] (React, Redux, RethinkDB, Koa) ... Still a work in progress. Wanting to get to the point where I have an adaptive login (local account, google, facebook, twitter) and some public/private pages with universal rendering. Been working on it as time permits. [1] https://github.com/tracker1/r3k-example https://github.com/tracker1/r3k-example
- afarrell 11y ago
  http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial.html http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial... is good if actually want a hand-holding walkthrough rather than just a boilerplate.
- acemarke 11y ago
  I've got a list of some particularly good ones at https://github.com/markerikson/react-redux-links/blob/master/boilerplates-and-starter-kits.md https://github.com/markerikson/react-redux-links/blob/master... . There's also a link to a little "starter kit search engine" someone built that lets you filter about 50-60 of them by various attributes.
tomekowal 11y ago
Have you checked Elm? I know there is a big difference between switching frameworks and entire language, but the benefits are really nice. Elm really enforces unidirectional data flows throughout entire application. For me it's like react on steroids.
iSnow 11y ago
> with about 1/3 the functionality, the code is 1/10th the size Yeah, that's the usual 80/20 rule at play.
doczoidberg 11y ago
Angular CLI helps much with the Angular 2 boilerplate code: https://github.com/angular/angular-cli https://github.com/angular/angular-cli
novaleaf 11y ago
I've been using Redux, and it is pretty much required if you have multiple components who need to update when a single state changes.... but pretty unhappy as the amount of scafolding required. It's not nearly as "isolated concerns" as it should be.
- alias240 11y ago
  Take a look at MobX. It's a different paradigm that requires very little boilerplate and results in more isolated components that react independently upon changes to state. https://github.com/mobxjs/mobx https://github.com/mobxjs/mobx
- true_religion 11y ago
  Right. I can give two alternatives. 1. Elm. I was just about to throw away the idea of Flux in a web app till I saw TodoMVC implemented in Elm. In Elm everything is immutable, and as a functional language, it has a lot of helpful syntax to help you deal with immutability. Shoehorning immutability into Javascript seems to require a lot of scaffolding by comparison. 2. MobX, it's been mentioned elsewhere but I can't help but sing its praises. Writing in MobX means that using controllers/dispatchers/actions/supervisors or another form of managing dataflow returns to being an architectural concern you can pattern to your application's needs, rather than being something that's required by default for anything more than a Todo app.

phat4life 11y ago

Personally, I prefer more web-component like frameworks. Vue.js is more usable, and easier to understand than React, but stuff like React Native is why React.js is worth learning. I strongly dislike the JSX syntax as well. Its messy, and difficult to read. I would like my to write my components as dom nodes, like with Vue.js, Riot. The way that react.js handles css, is also messy. I would rather just defined a <style> tag like in Vue.js.

madeofpalk 11y ago
What is it that you don't like about react and css? React actually has nothing to do with CSS - 'by default', you just include a stylesheet as normal. If you want to upgrade, you can just something like CSS Modules with webpack's css-loader to make per-component stylesheets a lot better.
matroosberg 11y ago
React does not require you to use JSX. Writing views with React.DOM is actually a quite nice alternative. This article gives an explanation: https://www.packtpub.com/books/content/using-reactjs-without-jsx https://www.packtpub.com/books/content/using-reactjs-without... However, newer React and Babel versions no longer compile JSX to React.DOM methods as the article shows, but other methods. Example for Babel: https://babeljs.io/repl/#?experimental=false&evaluate=true&loose=false&spec=false&code=React.renderComponent(%0A%3Ch1%3EHello%2C%20world!%3C%2Fh1%3E%2C%0Adocument.getElementById('example')%0A)%3B%0A%0A https://babeljs.io/repl/#?experimental=false&evaluate=true&l...
mercurial 11y ago
> I strongly dislike the JSX syntax as well. Its messy, and difficult to read. I've read quite a few criticism of JSX but "difficult to read" is a first. It's not significantly different than any templating system out there (eg, ERB). It's just XML with interpolated code, what's confusing about it?
- BinaryIdiot 11y ago
  > what's confusing about it? In my opinion the confusing part is mostly the fact that taking a markup language and embedding it into a scripting language is really awkward. You have two completely different types of syntax not only existing together but working together. Also I've worked on multiple teams where designers will re-style and even change the markup of pages but trying to get non-developers to do this with JSX is just painful. I find HTML and the DOM API awkward at times but since that's the final state I just prefer to work with that.

capkutay 11y ago

> As an experiment, we tried writing a separate app to try out the popular Flux library. Is there one 'popular Flux library'? Perhaps they meant redux? No other mention of it in the article.

phereford 11y ago
There are lots of popular Flux libraries. https://github.com/acdlite/flummox https://github.com/acdlite/flummox https://facebook.github.io/flux/ https://facebook.github.io/flux/ https://github.com/reflux/refluxjs https://github.com/reflux/refluxjs http://fluxxor.com/ http://fluxxor.com/ https://github.com/reactjs/redux https://github.com/reactjs/redux Each of these appear popular in their own right. Given they mentioned Flux, it probably is the actual Flux library.
- dominic_cocch 11y ago
  Yep, it was the actual Flux library. However, we're not totally settled on that choice just yet.
  - phereford 11y ago
    Awesome! I had chosen flux for one project I was on and really enjoyed it! Thanks for the post!
- girvo 11y ago
  Flummox, while amazing (and my favourite) has been deprecated in favour of Redux. That said, my personal replacement is Alt.js[0], which has the same style of architecture and API that Flummox had [0] http://alt.js.org http://alt.js.org
honua 11y ago
Redux is best http://github.com/rackt/redux http://github.com/rackt/redux

b34r 11y ago

The forceUpdate API is murderous for performance, since it causes the entire tree to do a vdom rerender, bypassing shouldComponentUpdate() checks. Should really try and find another way to trigger a re-render.

dominic_cocch 11y ago
Definitely agree. In our real code we're much more sensitive of performance. This was just a quick way to show a simple way Backbone can be used with React. I think it'd be interesting for us to do another post in the future about how we measure and improve performance within our React apps. There aren't a ton of articles about this with relation to Bakcbone, it seems. Thanks for giving it a read!
- rgbrgb 11y ago
  Would definitely like to read that one. We have a backbone/react app and generally use your example pattern, but I can see how it would take a toll on performance at some point. What's the general pattern you use if not forceUpdate? I suppose you could use something like @setState(model: model) but you still have mutable models to deal with in shouldComponentUpdate. Have you guys come up with a good way to reconcile backbone's tendency towards mutation and the performance benefits of immutable props?
  - dominic_cocch 11y ago
    Yes and no, really. We mostly keep our backbone models as props and keep them immutable by pure convention. You really could just call set() on one of them and cause some problems. This isn't great long term, of course. Code reviews and code style guides help here for now. We've also at times converted backbone models to simple objects at the parent level and passed them down that way. Keeps things simpler, but we lose some of the niceties of the backbone model api. Once the models are objects, you can use componentShouldUpdate pretty defensively if you need. We've also used throttled and debounced functions for anything which gets hit very heavily.
AgentME 11y ago

jorgecurio 11y ago

one of the biggest changes was accepting that React is different from old way of doing things like with jquery. I used jQuery to build 4k loc applications. It's a fucking blast when you are just wiring up the template and watching the UI come alive...to me that was the power of jQuery. No need to think, just go and make everything stick like glue. Angular.js was also right in that regard....add annotation to HTML. but this shit doesn't scale when application grows. I'm still frustrated that I can't write shit in jQuery anymore because HN have collectively ruled against it and I guess at 4k loc it has become very hairy. But I still argue if your needs are pretty small, like make a small widget app that has two buttons and makes ajax request to an endpoint, no other frontend framework can even touch jQuery in this territory.... In fact the overhead of having to think about states, structures, components organized in hierarchy...this shit adds to my stress and I can't experiment fast...but then also was the stress from not being able to add new features because the jQuery app grew in complexity.... difficult times gentlemen difficult times. I've been holding on to jQuery since 2009...maybe it's time to venture out entirely with React.js? Or should I crawl back to the comfortable cave that is jQuery where I can make anything very quickly.

baby 11y ago
I'm pretty sure you can use both. I use jQuery more like an enhanced javascript. React I use for designing real interactive components. If you have a small javascript feature to implement, just write in jQuery.
petepete 11y ago
I'm also still in the jQuery cave, for the same reasons you are. For most of what I do, it's enough, but on my current app, there are a couple of places (complex booking forms) where the code can get messy really fast. I might give React a try when the opportunity presents itself.
leeoniya 11y ago
you may find https://github.com/leeoniya/domvm https://github.com/leeoniya/domvm interesting. Disclaimer: mine, and has about another month to 1.0 stability.
11y ago

philmander 11y ago

It's clear why using React in your Backbone views is beneficial, but I'd be genuinely interested to know what tangible benefit moving the models (and, thus, entirely from Backbone I guess) to flux/redux etc brings you, besides just keeping up with the latest conventions.

dominic_cocch 11y ago
The backbone model api was made with totally mutable data in mind. React, on the other hand, only works well with immutable props and some mutable state in the top levels of components. That's our first issue, for sure. Backbone also has a dependency on jQuery, which isn't very useful in React apps since mutatuing the DOM (one of jQuery's main purposes) is a no no. So most of the Backbone library isn't very useful to us anymore. I do still really enjoy the backbone way of fetching and saving models, especially in a Rails context. But I think we can get those features in other ways.
- petetnt 11y ago
  That's pretty much experience too: our apps that use React + Backbone, I find myself more and more using a fraction of the features (very basic API integration (fetching, saving) and the router), both of which could be easily replaced with something else. Not that it would be particularly hard to extensively use Backbone with React, it's just that there seems to be other (better) ways to do the same things too.
- pramodliv1 11y ago
  I use React and Backbone too. Here's the source code: https://github.com/pixyj/feel/tree/master/client/app https://github.com/pixyj/feel/tree/master/client/app I use jQuery for animations and also for non-crud pixel-level DOM manipulations as in the graph shown in the home page: https://conceptcoaster.com/course/python-tutorial/ https://conceptcoaster.com/course/python-tutorial/ In the graph, I need to dynamically calculate height of certain elements based on the height of others. The height cannot be predicted in advance. Can React work for such cases too?
  - 11y ago

ezequiel-garzon 11y ago

As I go over the impressive list of big sites adopting React [1] I feel there must be something wrong with this current survey [2], which states a mere 67 of the top 10000 sites are using it. Any insight will be welcome. [1] https://github.com/facebook/react/wiki/Sites-Using-React https://github.com/facebook/react/wiki/Sites-Using-React [2] http://trends.builtwith.com/javascript/javascript-library http://trends.builtwith.com/javascript/javascript-library

chrischen 11y ago
While easier than before to do server side rendering, it's still non trivial to do a react app that preserves SEO and renders on the server if your app isn't already a nodejs app. It would require running either V8 to render on the server behind whatever language your backend is already written in, or calling node to serve your backend, relegating your existing backend to an API (and tying the backend rendering to your API along with the Frontend to use the same API isn't simple either).
- dominic_cocch 11y ago
  That is definitely one limiting aspect for some places. We actually have a similar issue, since we're a Rails shop first and foremost. Luckily there are a few tools we can use to make it work well with Rails. Maybe a future post! I also think jQuery and other libraries with large usage are kind of Swiss army knives, so more people have more use for them. I do believe over time React will become as pervasive as jQuery. Or possibly even the DOM api will eventually allow a similar style of building things natively. This seems to be happening to jQuery now :)
- girvo 11y ago
  Indeed. We had to tackle this for Expedia's Viewfinder[0] (which was done by utilising nodejs as the server), and we're tackling it again for another project that has it's server-side rendering done in PHP. Interestingly, we are leveraging the v8js PHP plugin to be able to execute JS from inside a PHP context, sharing variables between them as needed. Though I'm not convinced its the perfect way of tackling this problem, there's still a lot of quirks and bugs. [0] https://www.expedia.com/pictures https://www.expedia.com/pictures

kensign 11y ago

No matter how I try to accept it, it is a really bad idea to embed views into business logic. You have no clear separation of concerns and this can create a lot of headaches as the sophistication of the application grows. Instacart is a great product, but it has a lot of room to grow still. What happens when you get into some deeper aspects of UX? I presume you do your own UX research and these highly segmented views are going to be a pain to manage. You'll also need to worry about how you run BDD tests for specifications and scenarios. How can this be achieved in React as you write test suites for user stories and non-UI acceptance tests? How will this impact your continuous delivery/integration systems as well? You'll have to rewrite all your test suites into Jest, right? There are architectural trade-offs for sure. Can you definitely say you've performed a thorough analysis before making this decision? There's a difference between having a clear strategy to move from one tech to another and knowing that the migration will not just bury you into a deeper whole than the one you think you're escaping. http://aurelia.io/ http://aurelia.io/ is based on webcomponents (MVVM), ES6, and current web standards. It's amazingly simple and good architects can use their own structural patterns to create code that can actually scale with the product. DDD and BDD methodologies mesh perfectly into the development workflow, especially with Agile product development. I wish you well, but I really think React is a short sell with dire consequences.

judofyr 11y ago
There's nothing in React which forces you to embed the views into business logic. React is just a view framework. How you structure your code is entirely up to you.
sehr 11y ago
There's nothing in React that forces you to use Jest or rethink your testing process.
anewhnaccount 11y ago
There is a clear separation of concerns. The React component is the view. React doesn't tell you what to do with the other bits (although people seem to have plenty of different ideas). There's generally less lock-in to a particular way of doing things with a view library like React than with a whole framework like the one you're promoting.

ridiculous_fish 11y ago

React has been quite nice, and very fast to work on. But there's one aspect that's concerning. You have state and props, and the React tree diffing algorithm attempts to make some minimal set of changes that preserves state. However this algorithm is a heuristic, and so it's possible to hit a case where your component gets a different component's state. For example, say there's a text field which has keyboard focus. Another text field is added above it: the keyboard focus should stay in the bottom text field. But React has no notion of identity and doesn't know whether the top or bottom text field is new. All it sees is a diff from one text field to two, and who knows which one will get focus! React's answer to this is to introduce identity by assigning each component a key, and that works. But this is reactive: I notice a bug, and fix that case by assigning a key, but still most elements do not have a key and it is not reasonable to add one. I'm stuck hoping that the opaque tree-diffing heuristic is correct enough for my case. How do other React users handle this? How do you go from "seems to work" to "I am certain React's tree diff will assign the right state to the right components in all cases?"

dominic_cocch 11y ago
This should really only be an issue when the children of an element are all the same type of element and are at the same depth level. For example, this is very common for li elements in a ul element. We try to keep the structure of the html so that wrappers generally keep different UI components separate from each other. In other cases, like in the example in the blog post, we just use the index from the .map() loop to add a key to every element we know will need one. React should also warn you when this is an issue.
- bsimpson 11y ago
  Moreover, you'll get a warning in the console if there are ambiguous children telling you to add keys.
- ash 11y ago
  > we just use the index from the .map() loop to add a key to every element Doing this could hide weird bugs. Let's say we render a list of posts with "remove" button for each one. The user clicks on "remove" button, we modify the underlying this.state.posts. And on next re-render removed post key would be assigned to the next post! The next post could inherit just-deleted post handlers, for example. It's much better to use unique keys like database ids.

kzhahou 11y ago

Dominic, when did you start rolling out this change, and how long have significant parts of production been on it? I'd be very interested in a follow-up in a year, once it's grown to the size of the backbone app it's replacing, and been battle-tested (in prod and in development)

dominic_cocch 11y ago
We've slowly been growing our React presence on the site for almost a year now. At this point, we're fairly close to the size of the original Backbone app as far as views are concerned. We're still somewhat tangled in with Backbone, but it's been a great success internally. Performance-wise, development speed-wise and also developer happiness-wise we haven't hit too many snags.

bschwindHN 11y ago

I like the idea of React. I like it even more when you take out all the frills and boilerplate. If you haven't already, I would encourage you to give Clojurescript and Reagent a try: https://reagent-project.github.io https://reagent-project.github.io I decided to use it for a small client for a chat server my company runs. The initial environment setup on OS X wasn't the smoothest, but once I got that taken care of the actual development was very pleasing and quick. You need to know just a few core concepts and then you can more or less replicate the common patterns you use in React - application state, component properties, local component state, initial values for local state, etc. Along with that, you get immutable data structures and the benefits of the Google Closure Compiler out of the box. Give it a shot!

dm3 11y ago
If you're ready to check out Clojurescript, I strongly recommend trying out Hoplon: https://github.com/hoplon/hoplon https://github.com/hoplon/hoplon It requires a certain shift in thinking when coming from pretty much any other framework. However, it avoids all of the unnecessary complexities of React by exposing the DOM elements directly as functions. The mindshare behind it might be low compared to Om or Reagent, but the people that are using it are pretty active at Clojurians slack channel #hoplon and on IRC (freenode, #hoplon). It's also FRP-based and pretty efficient. Highly recommend!

Kiro 11y ago

I'm interested in learning more about reusability. One problem I have with React is that I've made this component called Product and then I need another Product component but in a different context, for example in a listing with a thumbnail. Much like the carrot example. How do you approach this exactly? Shouldn't it be based on the same component somehow?

astazangasta 11y ago
I think the vague answer is 'use mixins', but they are generally unsatisfying. One hopes that using ES6 classes to define react components this way would allow proper inheritance, but the whole ES6 thing is a mess that breaks a bunch of other things (notably autobinding this). Upshot is my code remains repetitive. Where possible you can use composability, extracting common function into a subcomponent, but this doesn't always make for neater code.
- wereHamster 11y ago
  Ugh no. Please don't use mixins or inheritance. Composition is the way to go. https://en.wikipedia.org/wiki/Composition_over_inheritance https://en.wikipedia.org/wiki/Composition_over_inheritance
  - Kiro 11y ago
    Do you have any example React code using composition?
    - wereHamster 11y ago
      Same way you compose functions or HTML elements. Functions: add(1,multiply(2,3)) HTML: <div>foo <span>bar</span> </div> React: <Container> <Header>foo</Header> <p>content</p> </Container>
      - Bahamut 11y ago
        To be pedantic, that is not quite composition - I've made this exact mistake before too. Composition is where you have a function f o g (o being the traditional mathematical notation for composition), where (f o g)(a) = b satisfies g(f(a)) = b. Composition is a useful tool, and so is writing functions like this, but they are two different ideas.

Aleman360 11y ago

As a C++/XAML mobile app dev, I'm baffled by how a common UI like this (lots of lists?) requires such a deep dive.

wanda 11y ago
To attract young, hip developers, or to justify incumbent hip developers.
badsha 11y ago
Saw your comment in another post about how the Start Menu is really just an XAML app. I was wondering, how did you guys make it transparent and blur? I have been trying to figure that out for the past 2 days and have had no success yet.

drdaeman 11y ago

I must've done something wrong, but I haven't attained that "zen" part when I tried to use React. On the contrary, it felt like I'm writing a giant pile of boilerplate code "just to use React", where there shouldn't be any. A simple, almost ToDo-like form quickly grew to 7 files, averaging 100 SLOC each, with a air-filled boilerplate-feeling classes (yet not lacking works-by-convention magic) that juggle data through those render -> onClick={e => this.onItemAdd(e)} -> onItemAdd -> addItem -> update -> UpdatePromise -> handleUpdateItems -> render loops. Sure, everything's logical but that feels like I'm deeply stuck in the wheel of Samsara, writing code for its own sake and not attaining any Enlightenment. ;)

dominotw 11y ago
> render -> onClick={e => this.onItemAdd(e)} -> onItemAdd -> addItem -> update -> UpdatePromise -> handleUpdateItems -> render loops you seem to have fallen prey to overengineered examples. that example should be >> render -> onClick={e => this.onItemAdd(e)} thats it, data change should re render the tree.
- drdaeman 11y ago
  Well, maybe. But I also wanted it to sync up with the server too (onItemAdd actually updated component's own state with extra "save in progress" flag, handleUpdateItems would clear it later).
  - dominotw 11y ago
    well then you are doing much more than A simple, almost ToDo-like You can do things like writing sever-syced component,mixin ect .
jonheller 11y ago
Me either. I understand the benefits but for side projects and stuff it's just not a very fun language to learn or use. Even Angular, with it's weird paradigms, seems more natural.

aioprisan 11y ago

I was checking out their careers page and they're looking for a senior engineer to lead 5 engineers, but they require masters degrees? Really? Newsflash: a one year degree isn't what's needed to be a successful team lead.

jackdempsey 11y ago
The next bullet point: "Employer will also accept a Bachelor’s degree or foreign equivalent in Computer Science, Computer Engineering, Information Technology, or related technical field and 5 years of progressive, post-baccalaureate experience in a related field." We don't require a Masters. Some engineers have one (or PhD even) but that's much less important than being a great engineer.
- aioprisan 11y ago
  You missed my point entirely. A one year degree isn't the equivalent of 5 years of post-bac experience in the field, and that is your first bullet point, the "expected" and most discouraging one - folks stop reading after that. That some folks have masters or PhD degrees is great, but shouldn't be an expectation for a team lead role. I'm sure you'll have issues trying to attract talent with that kind of messaging and expectations.

carsongross 11y ago

Peguy's quote: "And it will never be known what acts of cowardice have been motivated by the fear of looking insufficiently progressive." becomes more and more relevant to the tech world. We are managing a few lists. How is this so complicated?

rgbrgb 11y ago
If you have a less complicated way to build a big beautiful app like instacart, I'm all ears (that's why I'm reading this). Or are you just saying we should give users a CLI and be done with it?
- carsongross 11y ago
  http://intercoolerjs.org http://intercoolerjs.org
  - rgbrgb 11y ago
    Nice, looks very simple. But I don't see how it would make it simpler to build an app like instacart. Try instacart, the app is borderline magical. I've never seen a bug with their cart or the awesome realtime-multiplayer shopping. I'm guessing if you tried to build an experience like that with just intercooler, your codebase would end up being significantly more complex.

pmlnr 11y ago

https://www.instacart.com/ https://www.instacart.com/ -> among the JS loaded: static-react-base-{id}.js 273KB. It it just me thinking that ~300KB of code, about to be evaluated in the browser is a bad idea?

GoToRO 11y ago
I feel the same, but people use it because they can deliver things faster (and get the money sooner). Sure, after that the client will maybe get complaints about website crashing user's mobile browser on cheap phones but those phones will get replaced soon (5 years?) so the problem will fix itself. On a second thought, how do you access the Contact form on a website you can't even load? :)

ausjke 11y ago

for newcomers is it too hard to find all the pieces that need to work with React to make a final product? I just started with Angularjs 1.x, while it has its faults I found it's easier to get started. maybe React is better suited for the experienced who knows how to bootstrap all the components? I'm interested in learning React _after_ I get more familiar with the javascript-ecosystem, and it seems to start with angularjs will be a good approach?

partycoder 11y ago

Saying CoffeeScript is simpler than JavaScript is the same as saying: I am going to make traffic simpler by removing lane delimiters, traffic signaling, lights, street names. You end up with a "simpler" language, but it is also less safe to use. Python will throw you an error with inconsistent indentation, but that's not the case in CoffeeScript. So any little messing with the whitespace, which is impossible to infer automatically, and you have a bug. Then, you can massively auto-format JavaScript, use great tools that inference type information from documentation, etc... but with VomitScript, you are pretty much on your own. In fact using an advanced editor and nano will probably make no difference. "Duh but I want to type less"... NOBODOY CARES about you typing less. If you care about typing less use templates in your editor and autocomplete.

ConAntonakos 11y ago

What is Instacart using for its routing logic?

dominic_cocch 11y ago
For now we use Rails on the server and a single backbone router for the the client side. This isn't how we want it stay. :) We do have a couple side apps internally using React Router. We've liked it so far, but it's a pretty basic implementation.