Live data from Hacker News

How I learned to stop worrying and love React

firstdoit.com

61–70 of 107 posts

Re: How I learned to stop worrying and love React

#61

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…

I thought JSX was just a cosmetic overlay to regular JavaScript functions. I'm not a react expert but I'm pretty sure `return whatever` just returns an object with a property of div and value of whatever. Exactly the same as writing `return React.DOM.div(null, whatever)` or whatever the vanilla version is.

Re: How I learned to stop worrying and love React

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

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.

Ember might be well organized and a great framework but I'm not sure I agree with "easy to grasp". There is so much automagic that when something tries to deviate from the common Ember patterns I worry that you are going to have a bad time. I say that having hardly used Ember outside of the intro tutorials so please someone correct me if I am wrong.

Re: How I learned to stop worrying and love React

#63

Earlier 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

Hm.. I didn't say a word about separation of technologies. If you have one non-broken piece of HTML and related piece of JS to make it "live" - it's one thing. If you use JS/php/python/ruby/lua/whatever to generate HTML, composing it by small pieces into one (inside one component) - it's another thing and it's exactly what I'm talking about.

Re: How I learned to stop worrying and love React

#64
post #26

I 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…

For me, it isn't about the optimization, it is about the way it lets you break your app into simple reliable components. There was a moment when building my first React application where it just clicked and I realized how much I was enjoying the reusability and ease of testing all of my components. I have never been able to write such well tested front end code. Also, the reusability of my code has skyrocketed.

Re: How I learned to stop worrying and love React

#65
post #57

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

Don't put your words into my mouth with "allegories", I hate it. I don't talk about cpp and headers at all, I talk about view templates and view logic.

Re: How I learned to stop worrying and love React

#66
post #56
post #21

Earlier 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?

Build tool complexity is what I dislike - it's certainly possible, but the trend I dislike is build tooling increasing complexity of the build system of the frontend, decreasing accessibility for onboarding developers. JSX is an unnecessary offender in this department, bringing us farther away from plain HTML.

Re: How I learned to stop worrying and love React

#67
post #2

Wow, 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!

I clicked through to a few of your other recommended posts and ended up emailing myself a bunch of links to read later. I particularly enjoyed 'Promises Are Not Optional' (http://firstdoit.com/promises-are-not-optional/)

You have a talent for clearly explaining complex abstractions. Nice work!

Re: How I learned to stop worrying and love React

#68
I've never used react but from what I read it's a more intuitive organization of components.

The 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

#69
post #18

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

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

Or hit F12, works in every browser and platform as long as the key is present.

Re: How I learned to stop worrying and love React

#70
post #55

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

The distinction you're making between "HTML" and "facility for encapsulating generated HTML" seems pretty arbitrary.

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.

Post reply on HN