Live data from Hacker News

How I learned to stop worrying and love React

firstdoit.com

51–60 of 107 posts

Re: How I learned to stop worrying and love React

#51

I encourage anyone who likes React and doesn't mind lisp to check out Reagent, an awesome Clojurescript library built atop React that manages to completely hide its complexity. It's by far the most fun I've ever had with web development; the way I feel now is like how I imagine people who've had religious epiphanies must feel when trying to show potential converts the proverbial light of god. https://reagent-project.…

could you elaborate what specific complexities it abstracts away?

Re: How I learned to stop worrying and love React

#52
post #47

Earlier quoted context omitted.

You might be confusing "logic" and "business logic" terms, I talk about "logic" exactly. Any logic and conditional cases makes design very difficult to change, because you can't anymore just move one piece of HTML (tags) to another place, or replace all classes with ctrl+f - it becomes very complicated with logic used to build it.

In practice, it is extraordinarily easy to move a React component from one place in the UI to another, most especially if you're using Flux, so that components are decoupled. That's been one of my favorite things about working with React: it actually works to design bottom-up, factoring low-level components out and then moving them around like cutouts. I could not do things like that in Knockout, or, god forbid, Must…

Components are made for code reuse - of course it should be easy to move them :) They are encapsulated.

Re: How I learned to stop worrying and love React

#53

Earlier quoted context omitted.

I use my years of experience, I don't need gut feeling for it. I really don't talk about backend, absolutely. While we have "createElement", we will use it with conditional cases and as result we will have mess of NOT-BUSINESS-logic and HTML code.

If you're using createElement you're doing it wrong.

Exactly! It's shortest version of what I think about JSX.

Re: How I learned to stop worrying and love React

#54
The virtual DOM is nice, although the only time I've seen a noticeable difference from two-way binding in speed is for tables with 1,000's of rows. The whole bit about React being more predictable than two-way binding is just an opinion though. Since any component can emit an event and change data, it's just as prone to loops and unpredictability. It's really just two different ways of thinking through the process. One's not better than the other.

Re: How I learned to stop worrying and love React

#55
post #47

Earlier quoted context omitted.

In practice, it is extraordinarily easy to move a React component from one place in the UI to another, most especially if you're using Flux, so that components are decoupled. That's been one of my favorite things about working with React: it actually works to design bottom-up, factoring low-level components out and then moving them around like cutouts. I could not do things like that in Knockout, or, god forbid, Must…

Components are made for code reuse - of course it should be easy to move them :) They are encapsulated.

I get the feeling that you're just arguing for the sake of arguing. You can't in one comment say that it's hard to move things around and then in the other comment say that of course it's not hard to move things around.

Re: How I learned to stop worrying and love React

#56
post #21
post #6

I recently worked on my first React project, after working with Angular code for a while. I'm willing to accept that as an app gets more complex, React/Flux really pays off. But there's something to be said for having a single template file for a single page in Angular, versus having JSX scattered among 20+ components for that same single page in React. When you want to get a 10,000-foot-view of how it all comes toge…

Agreed - I also found React a bit clunky with the explicit getters/setters compared to Angular. JSX is a bit of a weakness IMO - I absolutely rather have templates in separate files to reduce complexity/concerns located in a file. It also adds build tool complexity, which there is too much of in frontend currently. Otherwise, working in React is generally clean, but one can get that benefit by utilizing ES6 modules i…

Who's stopping you from putting your jsx in a seperate file?

Re: How I learned to stop worrying and love React

#57

Earlier quoted context omitted.

This is the first thing every dev says when he/she first discovers React. Logic and representation are not two unrelated pieces to keep them separate.

If you don't know yet reasons to keep them separate, please google about it before arguing without arguments. For example, read about Separation of Concerns: http://en.wikipedia.org/wiki/Separation_of_concerns //You can use "they" to replace "he/she".

You are just throwing unrelated links around. Parent's point was that in this case, logic and representation are one and the same concern. What you're doing is similar to using SoC to defend having to split up class definitions into .h and .cpp files.

Re: How I learned to stop worrying and love React

#58

Earlier quoted context omitted.

This is the first thing every dev says when he/she first discovers React. Logic and representation are not two unrelated pieces to keep them separate.

If you don't know yet reasons to keep them separate, please google about it before arguing without arguments. For example, read about Separation of Concerns: http://en.wikipedia.org/wiki/Separation_of_concerns //You can use "they" to replace "he/she".

Separation of concerns and separation of technologies are a different thing. It would appear you haven't done your research. See Pete Hunt's famous talk:

https://www.youtube.com/watch?v=x7cQ3mrcKaY

Re: How I learned to stop worrying and love React

#59
post #55

Earlier quoted context omitted.

Components are made for code reuse - of course it should be easy to move them :) They are encapsulated.

I get the feeling that you're just arguing for the sake of arguing. You can't in one comment say that it's hard to move things around and then in the other comment say that of course it's not hard to move things around.

Maybe if you will read my comments more closely you will see the difference between moving parts of HTML inside component and moving components. "Moving things around" is too broad term.

Re: How I learned to stop worrying and love React

#60
post #25
post #17

Earlier quoted context omitted.

> But there's something to be said for having a single template file for a single page in Angular, versus having JSX scattered among 20+ components for that same single page in React I'm not sure what you mean. There's nothing in React that would prevent you from making your pages just one huge component. You can split the code any way you like.

That's true. But React is generally associated with the Flux architecture pattern, which emphasizes small, modular, mostly stateless components.

There is a reason for that and it is because it makes for simpler code. Simpler code is easier to test and simple tested code should have less bugs. Also you get the advantage of reusability from all of the small components you build. If you don't want to follow the recommended programming practices, you don't have to but I would like to encurrage you to adopt them because they really are helpful.
Post reply on HN