Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I learned to stop worrying and love React

firstdoit.com

Post reply on HN
Print view View original

81–90 of 107 posts

Re: How I learned to stop worrying and love React

#81

Post by bryanlarsen »

xtrumanx wrote: post #79
insin wrote: post #27

Earlier quoted context omitted.

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

You've gotta admit though that inlining isn't the usual case. Especially if you're not using ES6 and the component your inlining is a few or more lines long.

It depends on who's doing the coding. I've got some inlined loops that are ~20 lines long, and I think it works & looks better than assigning the loop to a variable before the render and inlining the variable.

Re: How I learned to stop worrying and love React

#82

Post by mixonic »

cloverich wrote: post #42
bryanlarsen wrote: post #30

Earlier quoted context omitted.

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

Check out this addon: https://github.com/pangratz/ember-cli-htmlbars-inline-precom...

We've started using it for inline templates in tests, but it should work just great with inline templates for components.

The pods convention you described definitely helps though.

Re: How I learned to stop worrying and love React

#83

Post by simplify »

ryannevius wrote: post #4

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.

A lot of people praise Mithril for its small file size and speed, but one of its greatest and perhaps most overlooked advantages is its small learning curve. You only really need to understand two things to get started: what a component is (a plain JS object with controller and view), and when a redraw happens (once on m.mount, and once after every event handler).

Why is a low learning curve important? Several reasons. If you're a developer, it's not a huge investment to learn (how difficult was it to learn backbone / angular / ember?). If you're a startup / company, you don't need to look for X developers, where X is a difficult-to-pick-up JavaScript framework. You also save money by having a shorter on-boarding period for those non-X developers.

I've worked in a hackathon group that picked Mithril up and created amazing results with it right away. I teach at a coding school, and by far Mithril has been the easiest JS framework for my students to learn and work with. For being so powerful, Mithril is quite easy to get started with – and that means a lot.

Re: How I learned to stop worrying and love React

#84

Post by arms »

logicchains wrote: post #35

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

I'm a big fan of Clojure and React, but haven't used Clojurescript or Reagent. I find React pretty easy to grok so I'd be interested in how you think Reagent makes it easier to use.

Re: How I learned to stop worrying and love React

#85

Post by arms »

todd3834 wrote: post #60
jawns wrote: post #25

Earlier quoted context omitted.

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.

I want to +1 the "makes for simpler code." I'm working on a side project in my free time on nights and weekends. I find the simplicity of React makes it very easy to jump back in after not working on it for a week, or when coding while I'm tired. Working with simple components allows me to constantly move forward, even if it's only for 30 minutes or an hour a night

Re: How I learned to stop worrying and love React

#86

Post by mavdi »

todd3834 wrote: post #64
mavdi wrote: 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.

Fair enough, I might need to spend more time with it. I certainly like the idea of testing components individually.

Re: How I learned to stop worrying and love React

#87

Post by tomjen3 »

hcarvalhoalves wrote: post #50
EugeneOZ wrote: post #45

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.

I am playing around with React and if you want to keep it JSscripty (being the only dev who actually likes JS) or you want to use coffee script then createElement isn't actually horrible to use.

Especially not if you make an alias to ce or something like that.

Re: How I learned to stop worrying and love React

#88

Post by DennisP »

nathanaldensr wrote: post #15
diminish wrote: post #5

Question for experts: why Browsers do not get the idea of updating changes the way react does automatically possibly with a start, stop transaction or better without.

It would be wonderful if browsers acted more like game engines. Collect user input and at the beginning of every rendering "frame", allow JavaScript to process the input and modify a virtual DOM. Then, render the virtual DOM. It would be so much easier to reason about web applications this way.

I'm messing around with ideas for an experimental hypertext engine, now you've got me tempted to try building it on a game engine. Looks like Unity might have halfway-decent text support.

Re: How I learned to stop worrying and love React

#89

Post by logicchains »

findjashua wrote: post #51
logicchains wrote: post #35

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?

It essentially combines all of React into a single component, the Reagent atom. It's used exactly like a normal Clojure atom, but whenever it's updated, Reagent will automatically update all Reagent components that depend on it. I find this quite elegant, as it allows one to write pretty much any reactive ui using only three functions: deref, update and render-component. Reagent atoms can even be passed between Clojurescript async threads, and will still work as expected, which completely eliminates the need for any kind of callback hell.

So what it eliminates is the need to learn React. Anyone who understands how Clojure atoms work and how to use Hiccup-style HTML templating will be able to use Reagent with almost zero learning curve.

Re: How I learned to stop worrying and love React

#90

Post by logicchains »

arms wrote: post #84
logicchains wrote: post #35

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

I'm a big fan of Clojure and React, but haven't used Clojurescript or Reagent. I find React pretty easy to grok so I'd be interested in how you think Reagent makes it easier to use.

Reagent means you don't have to grok Reagent at all. If you know how Clojure atoms work, how to use Hiccup-style templates, and understand that all templates ('components') that dereference a Reagent atom will be automatically updated when the atom is, then you know how to use Reagent.
Post reply on HN