Live data from Hacker News

How I learned to stop worrying and love React

firstdoit.com

41–50 of 107 posts

Re: How I learned to stop worrying and love React

#41

There is a lot of good and even awesome things in ReactJS universe, except JSX. Thousands of developers took their lessons in PHP/Perl/Python about mixing logic and representation, and now in nightmares they will generate HTML from logic, especially by parts and in worst case - using conditional cases. Everybody who tried to change design of website, written using something like "if ($birthday) $html .= getBirthdayBu…

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".

Re: How I learned to stop worrying and love React

#42
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…

To each their own, I guess. I think that any template that's more than 4-5 lines (not including closing tags) is generally a mess and can benefit from being split into more components. AKA the single responsibility principle. Structuring a program with a large number of small components is very awkward when templates and code are in separate files. As far as that 1000 foot view, a nice tree view of React components i…

> Structuring a program with a large number of small components is very awkward when templates and code are in separate files.

I agree. We've developed a fairly complex Ember application, and the component hierarchy feels cluttered with everything separated by component and template. E.g. I have /my-component/component and /my-component/template instead of just my-component.js. Its funny coming full circle in MVC apps, but I find myself frustrated writing 1-5 line templates -- that I have to import. Why can't I just put it in the same file as the component, and have one file? Subjective to be sure, but I'd much prefer React style components in our project.

Re: How I learned to stop worrying and love React

#43

There is a lot of good and even awesome things in ReactJS universe, except JSX. Thousands of developers took their lessons in PHP/Perl/Python about mixing logic and representation, and now in nightmares they will generate HTML from logic, especially by parts and in worst case - using conditional cases. Everybody who tried to change design of website, written using something like "if ($birthday) $html .= getBirthdayBu…

You are using your gut feeling, but that's not how React works at all.

JSX is not HTML, mixing logic/presentation is not a concern because you're not dividing your rendering between backend/frontend, and finally you don't even have to care about the final HTML representation of your component, it's just an implementation detail.

Finally, it's all declarative since you're never modifying a DOM tree - and declarative is a pre-requisite for good UI frameworks.

Re: How I learned to stop worrying and love React

#44
post #40

There is a lot of good and even awesome things in ReactJS universe, except JSX. Thousands of developers took their lessons in PHP/Perl/Python about mixing logic and representation, and now in nightmares they will generate HTML from logic, especially by parts and in worst case - using conditional cases. Everybody who tried to change design of website, written using something like "if ($birthday) $html .= getBirthdayBu…

You might be confusing programming languages with concepts. Don't think of React as "a container for logic and a system for doing views". Think of it solely as view logic . It's not mixing views with program logic. It's only view. There's nothing to mix. It just happens --- wonderfully --- to use a real programming language to represent those views. The notions of logic, controllers, models, storage, and all that jaz…

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.

Re: How I learned to stop worrying and love React

#45

There is a lot of good and even awesome things in ReactJS universe, except JSX. Thousands of developers took their lessons in PHP/Perl/Python about mixing logic and representation, and now in nightmares they will generate HTML from logic, especially by parts and in worst case - using conditional cases. Everybody who tried to change design of website, written using something like "if ($birthday) $html .= getBirthdayBu…

You are using your gut feeling, but that's not how React works at all. JSX is not HTML, mixing logic/presentation is not a concern because you're not dividing your rendering between backend/frontend, and finally you don't even have to care about the final HTML representation of your component, it's just an implementation detail. Finally, it's all declarative since you're never modifying a DOM tree - and declarative i…

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.

Re: How I learned to stop worrying and love React

#46
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…

Because you're still tied to thinking in terms of master templates and interpolating strings - maybe because of how designs are handed off to you?

The smallest unit in UI design is a component, and React maps well to that, allowing you to treat components as functions (you can compose, specialize). You'll realize the power of that once you work with real UI designers who understand designing from inside-out as opposed to dumping a PSD mock of the entire page.

Re: How I learned to stop worrying and love React

#47
post #40

Earlier quoted context omitted.

You might be confusing programming languages with concepts. Don't think of React as "a container for logic and a system for doing views". Think of it solely as view logic . It's not mixing views with program logic. It's only view. There's nothing to mix. It just happens --- wonderfully --- to use a real programming language to represent those views. The notions of logic, controllers, models, storage, and all that jaz…

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, Mustache and server-side templates; not without changing the application logic to account for the move.

Re: How I learned to stop worrying and love React

#48
post #11

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. Good point; How does one view the resulting react-page anyway? CTRL+U shows no matter what state the SPA is in..

In Chrome, there's a cool React dev tools extension that shows you the React components. https://chrome.google.com/webstore/detail/react-developer-to...

That's actually better than looking at the HTML output, unless you're debugging something really weird. With React you should treat HTML as an implementation detail and work in terms of component trees.

Re: How I learned to stop worrying and love React

#49
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…

If you use react-router (port of ember's router), you get a view of the components on the page for each route. Then you can drill down into your component of interest.

Re: How I learned to stop worrying and love React

#50

Earlier quoted context omitted.

You are using your gut feeling, but that's not how React works at all. JSX is not HTML, mixing logic/presentation is not a concern because you're not dividing your rendering between backend/frontend, and finally you don't even have to care about the final HTML representation of your component, it's just an implementation detail. Finally, it's all declarative since you're never modifying a DOM tree - and declarative i…

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.
Post reply on HN