Live data from Hacker News

How I learned to stop worrying and love React

firstdoit.com

21–30 of 107 posts

Re: How I learned to stop worrying and love React

#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 in general. React brings a lot of good things to the table, which is probably best exemplified by Angular 2 pulling a lot of ideas from it.

Re: How I learned to stop worrying and love React

#22
post #7
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!

Nice work. Hopefully you can write another one about Flux? :)

Thanks! Next one is definitely about Flux :)

Re: How I learned to stop worrying and love React

#23
post #19
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!

It's a really neat article. Thanks for explaining this stuff. I have no patience for it :)

It is my pleasure to be of service!

Re: How I learned to stop worrying and love React

#24

> However, all template languages are inherently crippled: they can never achieve the same expressiveness and power as code. Quite simply, {{# each}}, ng-repeat and databind="foreach" are all poor replacements for something that is native and trivial in JavaScript: a for loop. On the other hand, when using a template language I can put `foreach` loops and `if` conditions right into the template itself. And when using…

This is a great argument for using hiccup[1] and reagent[2] as well.

[1] https://github.com/weavejester/hiccup#syntax

[2] http://www.reagent-project.github.io

Re: How I learned to stop worrying and love React

#25
post #17
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…

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

Re: How I learned to stop worrying and love React

#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 can't say the same thing about React. Sure it's faster, and if you think your app is going to mutate into something big, consider using it. But I personally wouldn't make it my default choice.

Re: How I learned to stop worrying and love React

#27

> However, all template languages are inherently crippled: they can never achieve the same expressiveness and power as code. Quite simply, {{# each}}, ng-repeat and databind="foreach" are all poor replacements for something that is native and trivial in JavaScript: a for loop. On the other hand, when using a template language I can put `foreach` loops and `if` conditions right into the template itself. And when using…

> On the other hand, when using a template language I can put `foreach` loops and `if` conditions right into the template itself. And when using JSX I need to calculate the result of a `for` loop before the actual template and it looks much more complex and cumbersome.

You can inline eqivalent JavaScript statements in JSX, without typical template language limitations in terms of allowed expressions or scope:

    {this.props.foo > 5 && ...}

    {this.props.foos.map(foo => {foo})}

Re: How I learned to stop worrying and love React

#28

I went through something similar...and then I found Mithril ( http://lhorie.github.io/mithril/ ). I may be alone on this, but I've enjoyed working with Mithril much more than I ever did React. If you haven't given it a shot, I highly recommend you do.

I like Mithril a lot, but the only thing that puts me off it over React and Angular is I don't really know how to tie in third-party libraries like d3 and dropzone.

Re: How I learned to stop worrying and love React

#29
post #13

I went through something similar...and then I found Mithril ( http://lhorie.github.io/mithril/ ). I may be alone on this, but I've enjoyed working with Mithril much more than I ever did React. If you haven't given it a shot, I highly recommend you do.

What makes you like Mithril more? I've been looking at it for a while, and it seems very nice and lightweight. All I really want is an easy way to get performant DOM manipulations. With React I have to build the whole view around the component system, which isn't so flexible. Am I right in thinking that Mithril allows you to put the view together any way you want, as long as the end result is an object it can diff in…

D3 can do DOM manipulation a. It's more well known for its charting (SVG) functionality. But I've used it to build tables and other data-based DOM structures.

It's not ideal for all use cases. But for updating the DOM based on changes to the data, I find it to be a useful option.

Square built and fast library on top of D3 called Crossfilter. Speed is pretty amazing when you see the data source. http://square.github.io/crossfilter/

Re: How I learned to stop worrying and love React

#30
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 is vastly superior to a wall of text cluttered up by meaningless implementation details like "div".

Post reply on HN