Unbelievably productive. I don't think there is another good choice right now. I've been on every other framework (large, complex backbone apps, companies you've heard of) and the codebases have been insane. New programmer onramp time is down a lot, time to feature is down a lot. The codebase complexity seems to scale linearly with actions and stores, other frameworks felt more like quadratic (jk, don't respond to that).
Ask HN: ReactJS – Do you use it? Do you like it?
51–60 of 78 posts
Re: Ask HN: ReactJS – Do you use it? Do you like it?
#52Unbelievably productive. I don't think there is another good choice right now. I've been on every other framework (large, complex backbone apps, companies you've heard of) and the codebases have been insane. New programmer onramp time is down a lot, time to feature is down a lot. The codebase complexity seems to scale linearly with actions and stores, other frameworks felt more like quadratic (jk, don't respond to that).
Re: Ask HN: ReactJS – Do you use it? Do you like it?
#53Earlier quoted context omitted.
Would you mind elaborating on the TypeScript comment? Is anything broken or just suboptimal?
It's suboptimal and obscure. There is barely any up to date resources on it. So far I've managed to get to stuff presented on the window, but as soon as you start messing with references to the DOM components, things start to break down. It's a shame, I really think Typescript and React would be the answer to getting a decent code base. One of the cool parts, is that you get to define what your property is with stati…
Honestly, who cares? I'm not being mean, it's true, look: https://www.google.com/trends/explore#q=typescript
No one cares.
Re: Ask HN: ReactJS – Do you use it? Do you like it?
#54Earlier quoted context omitted.
Would you mind elaborating on the TypeScript comment? Is anything broken or just suboptimal?
It's suboptimal and obscure. There is barely any up to date resources on it. So far I've managed to get to stuff presented on the window, but as soon as you start messing with references to the DOM components, things start to break down. It's a shame, I really think Typescript and React would be the answer to getting a decent code base. One of the cool parts, is that you get to define what your property is with stati…
The Redmond cult, closely followed by... a city I've never heard of in Japan? Toss it in the graveyard with the rest: https://github.com/jashkenas/coffeescript/wiki/List-of-langu...
Re: Ask HN: ReactJS – Do you use it? Do you like it?
#55I like React because it's closer to JavaScript than any other JS library I've used. The public API is tiny; you get better at React by getting better at JavaScript.
The only thing I don't like about React is the rapid churn in architecture best-practices (Flux et al). This is in stark contrast to Ember—which nails conventions and tooling but is written far about vanilla JS.
We use React because components are a great abstraction for the web. React components are also very transportable, making them a great addition to integrated systems like Rails.
I like to focus on transferable skills. I don't want to be a Backbone/Ember/Angular/whatever developer. I want to be a good JavaScript developer. React makes that happen.
Re: Ask HN: ReactJS – Do you use it? Do you like it?
#56I've moved from angular to react and i'm happy. Simple, really simple!!! interface. All you need is to remember just few methods of one (ONE!!!) class. It's fast enough to create interfaces with a lot of objects. With react and react-native i start publish my projects on github, because they has a simple structure and can be easily supported. I almost forget jQuery, it's really rare situation when i need to access re…
Thanks a lot for all the links. Great material to go over.
Re: Ask HN: ReactJS – Do you use it? Do you like it?
#57Short answer: it's great. I don't mean to echo the already loud voices of people championing React, but they're right: it's just awesome to write. I think React has the right abstractions for today's web development: I am frequently able to express complex UI with very little SLOC. It's easy to see what a component does, and it's easy to jump into a project with little to no experience. On that last point: I write so…
I think repeating some of the already mentioned answers is good - it shows common things that developers like.
Re: Ask HN: ReactJS – Do you use it? Do you like it?
#58I use React for almost all my projects and I'm definitely happy with it. It addresses one of the main problems - many developers in your team contributing to the same code. React IMO helps us write predictable code even when there are many developers contributing to the same code.
Also, my favorite quote -
Before React - Don't mix HTML and JS React - Mix HTML and JS
Imagine. It simply tells you - do things like when you started learning web development ``, change things as much as you want, and we'll take care of it. Just keep doing whatever feels natural. I've been waiting all this while from the moment I started writing code for browser - I wanted to use `onclick=func`, `onchange=func`, and `if (isHidden) return ` and it just lets me do that.
Re: Ask HN: ReactJS – Do you use it? Do you like it?
#59I've used it for multiple apps at this point and it's been a huge win for me in terms of productivity (I'm also quite enjoying Reagent with ClojureScript so far, but I'll withhold judgement on that for now). Trying to apply simple FRP-style abstractions over state changes like Signals becomes infinitely more tractable in React, where components are just functions that return data (as opposed to most frameworks, like…
The point of flux is one way data flow. Your data lives in ONE place (the "store"), and then it's fed into your views, which render it in a deterministic fashion. User interaction triggers actions, which circle back around to modify the data in your stores. Data should only be modified by actions, and views should only change when your data does.
There's a lot of advantages to this (in terms of performance, but much more importantly, in terms of being able to reason about your code). You could think of it as an event bus, and you might even implement it with one, but that's an implementation detail. In terms of your actual code, your store will list which actions it wishes to be respond to, your views will list which stores they want data from, and you'll have some UI elements that trigger actions. Your view doesn't "know" about events; it knows that it'll be rendered with the data it needs passed in as props, and re-rendered with the new data it needs.
You're probably using PouchDB more or less as a store. If not, you probably should be, and it would be trivial to write a very lightweight wrapper around it to tie it into your existing flux implementation of choice. What flux is trying to get you to avoid is some sort of ugly ball of ad hoc AJAX calls and local component state. PouchDB is already pushing you the same direction. (Which is probably why you don't see a point.)
Re: Ask HN: ReactJS – Do you use it? Do you like it?
#60It's great but it's a real pity that the most recent way of doing things with version 0.13 and ES2015 is quite different to the earlier ways of doing things. Don't get me wrong - the newest ways of working with 0.13 and ES6/ES2015 are superb. It's just that as a result of the changes much of the documentation, discussion, questions and answers and blog posts must first be examined to work out which version and way of…
If you're comfortable with ES5, one option is to paste examples into the Babel REPL here:
This will give you a familiar reference for what is going on, and quickly. It also translates the JSX which could be a good or bad thing depending on your preference. Running your own instance offline allows for a lot more customization.