A Primer for Building Single Page Applications with React • Hacker News Board

Re: A Primer for Building Single Page Applications with React

#141

Post by jbergens » Wed, Mar 25, 2015, 9:57 AM UTC

Retozi wrote: post #60

unklefolk wrote: post #12

Honest question here from someone new to React. Isn't the way it mixes in HTML, CSS classes and JS altogether something we were trying to get away from a few years ago? It feels a bit like old school ASP! I'm not trying to be flippant, I just was always taught about separation and mixing HTML markup with JS logic seems like we are going the other way.

In my opinion it is a misconception that React "mixes" representation and logic. You can _implement_ both representation and logic with React. (instead of JS for logic, and some clunky template language for representation). This does not mean that you should mix it. usually you end up with "representation" components that are "dumb", and logic components, that do not care about the representation of their children. s…

This is a great way of separating things. We did this (or something very similar) years ago with ASP.NET and it worked like a charm.

Re: A Primer for Building Single Page Applications with React

#142

Post by jbergens » Wed, Mar 25, 2015, 10:00 AM UTC

go1979 wrote: post #48

myhf wrote: post #31

Earlier quoted context omitted.

In comparison to Angular, React is more idiomatic . It is very easy to reason about the scope, lifecycle, and performance of React components if you are familiar with JavaScript as a language. In comparison with Backbone/JQuery, React is more declarative . It encourages the developer to describe the structure of the UI in a given state and let the engine handle the transitions between states. It's possible to use Bac…

I'm not an expert ... I dabbled a bit in Angular and found it really confusing and hard to debug. React worked mostly as expected. There were some gotchas but I managed to get through them in a few days. I just wish we had a non-proliferation treaty on Flux frameworks.

The proliferation of Flux frameworks will probably continue for a while. Then, hopefully, things will settle down and we will only have a few frameworks left that have clear differences which makes it easy to choose between them. I currently like Reflux and would choose that as a start if I created a new project.

https://github.com/spoike/refluxjs

[Edit added link to Reflux]

Re: A Primer for Building Single Page Applications with React

#143

Post by uptownJimmy » Thu, Mar 26, 2015, 12:39 AM UTC

timepiece wrote: post #90

uptownJimmy wrote: post #88

Earlier quoted context omitted.

I don't give a hoot about "separation of concerns" unless it makes really, really good sense, which it often does not.

Fair enough but please don't go around telling that mixing content/presentation/logic in a single entity is a valid case of "separation of concerns" but on a micro and not macro level. That's just not right!

There's a lot of things that may or may not be "right", and I'm not trying to do them, either...

Re: A Primer for Building Single Page Applications with React

#144

Post by andrewrice » Thu, Mar 26, 2015, 3:07 PM UTC

TheAceOfHearts wrote: post #85

andrewrice wrote: post #68

This is great. Does anyone know of a similar primer for Angular 1.*?

One problem is that angular 1.x is considerably more complicated than react. There's John Papa's style guide [0], but IMO it's not great. There's an angular review [1] that I believe hits the nail on the head: "Angular wants you to build your application in a particular way, but it’s not very explicit about it. Call it “passive-aggressive architecture.”" After using angular for over ~2 years, I'm far happier with rea…

Thanks for the insight! :) I'm just starting to get my feet wet with JS frameworks so the input is appreciated.

Re: A Primer for Building Single Page Applications with React

#145

Post by nicksellen » Fri, Mar 27, 2015, 12:24 AM UTC

pjtops wrote: post #126

nicksellen wrote: post #21

Earlier quoted context omitted.

The idea was approximately that html was the data and css was the presentation. In reality they are quite connected and you have to write the html to support how it will be presented, a change to the presentation often requires a change to the data (html), and this doesn't really make sense. I think a saner approach is to start with plain old data (e.g. some JSON) and have a function that can turn that into html/css/…

If changing CSS requires changing the markup, you are doing it wrong. Look into approaches like BEM, and demo sites like CSS Zen Garden.

Changing the presentation often involves more than changing the CSS alone. For example, you might have a table of data that you want to change into a bootstrap .row/.col structure. The data itself has not changed, only the presentation, and this required a change of HTML.

The CSS always needs enough hooks in the HTML to do it's work, without the right hooks some things are impossible with CSS alone (or would be unnecessarily obscure/tricky/brittle).

HTML isn't a general data format in the way JSON is.