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…
How I learned to stop worrying and love React
61–70 of 107 posts
Re: How I learned to stop worrying and love React
#62I 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…
The new Glimmer engine in Ember.js gives you React-like DOM diffing without the use of JSX, and baked into a very organized and easy to grasp framework to boot.
Re: How I learned to stop worrying and love React
#63Earlier quoted context omitted.
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
#64I finally got into React after being told by a friend for months that I need to. I'll be honest the whole thing just looks like premature optimisation to me. I still find the structure of an angular app a lot easier to grasp, it might be that I'm used to it but I remember the first time using Angular that it all made sense to me. I liked it instantly. Coming from Backbone, it certainly was a breath of fresh air. I ca…
Re: How I learned to stop worrying and love React
#65Earlier quoted context omitted.
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
#66Earlier quoted context omitted.
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
#67Wow, author here. Woke up to a lot of unexpected traffic on the blog. I hope you like this article. I took a long time to understand React and, now I do, I hope other people don't take as long as I did!
You have a talent for clearly explaining complex abstractions. Nice work!
Re: How I learned to stop worrying and love React
#68The separation of the view and logic is an arbitrary separation that isn't always efficient. It's like owning a bunch of power tools and organizing by color instead of by function.
Templates have components like search bars and login forms and they have logic related to those components. Why should component logic and template code be separated when both the logic and template components serve the same function? Code should be organized by segregating things into widgets. This, to me, makes more sense.
I think the only thing missing from React is the ability to incorporate local css styles into the widget. Again like I said if there are styles associated exclusively with a widget, there's no point in segregating styles into some separate css file.
Logic, structure, and style should be unified and organized by function, not by category.
Re: How I learned to stop worrying and love React
#69Earlier 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..
You want to look at the DOM structure of the page as it exists in the loaded page and have I got a treat for you! Figure out how to open the web inspector for your browser; the keyboard shortcuts are ctrl-shift-I or cmd-shift-I or cmd-opt-I on a few (platform, browser) pairs. (This will show you the actual DOM, not the React components... but since you were talking about 'view-source', this might help you too.)
Re: How I learned to stop worrying and love React
#70Earlier quoted context omitted.
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.
I was making a simpler point, though.
Some of the reactions I see to React seem to come from the notion that it's mixing application logic with view logic. That's an easy misconception to get from reading the tutorials and quick-start documentation: after all, it's using raw Javascript to generate HTML, which is the same language other frameworks use for application logic.
The misconception comes I think from comparing React to Angular. Angular is an application framework. React is solely a view framework. It happens that React uses Javascript --- which works amazingly well in practice! --- to express views. But that doesn't mean it's mixing application logic and view logic.
That's all I was saying. The semantic argument between "components" and "HTML" is totally uninteresting to me. The important point, regarding ease of moving "bits of UI" around, is that React makes it astonishingly easy to do that. It's one of the selling points of React.