5 ms·

I don't get it. Anyone whose created sites with only JQuery and felt that pain has moved to frameworks like angular/ember/knockout/etc. Those frameworks help

by schtoo 13y ago

I don't get it. Anyone whose created sites with only JQuery and felt that pain has moved to frameworks like angular/ember/knockout/etc. Those frameworks help decouple the html from your js. This seems exactly opposite. It like developing with JQuery where you had something like: $('.whatever').append('<div>Hello ' + this.props.name + '</div>'); and now with JSX you can do (minus the React structure around it): <div>{'Hello ' + this.props.name}</div> So... looks a bit nicer... less quotes...? But so what. I don't want to tightly couple my presentation to my logic.

gwright 13y ago
Decoupling is not necessarily about using different languages for the different components. Smalltalk MVC was all written in Smalltalk for example and that doesn't mean that the M the V and the C weren't decoupled. I have no experience with React but using JSX (or Javascript) to manipulate the DOM doesn't necessarily mean your view is not decoupled from your controller or model. I have been looking at Angular a lot lately and this is another example where view components are constructed from a mix of html(templates), the DOM (directives), and Javascript (the code that implements directives). The model is pure Javascript objects and the controller is also Javascript. Decoupling is an abstract concept that can be realized in many different ways.
- schtoo 13y ago
  Imagine this scenario: I've developed my app. Designer gets hired later and spits out a cool new layout and design... No feature changes at all. similarly... Then next year, management decides we need to give the app a "fresh new look" for v2. [If I'm using React or JQuery-only] From what I can tell, this will cause me to have to dive through a whole bunch of JS code where I'm sifting through business logic and imperative code to find JSX/html sprinkled throughout and make the necessary changes. Also, since I'm changing actual code the chances of introducing new bugs in this process is high. [If I'm using Angular] Go through html. Change html and css. Leave code and business logic alone. This is not an entirely contrived situation (at least not for me). As I'm working towards a releasable product, one of the areas that go through the most change and flux is the design and layout.
  - peterhunt 13y ago
    With React, if you've structured your components correctly (i.e. only display logic) it should be straightforward to change the layout. In fact, it should be easier, since React is modular and has clearly defined boundaries and semantics. Working with React components vs angular directives are pretty similar in terms of difficulty for designers, IMO, but we think that React components are easier to build than directives. Most designers can figure it out if they know html.

by schtoo 13y ago

gwright 13y ago

Decoupling is not necessarily about using different languages for the different components. Smalltalk MVC was all written in Smalltalk for example and that doesn't mean that the M the V and the C weren't decoupled. I have no experience with React but using JSX (or Javascript) to manipulate the DOM doesn't necessarily mean your view is not decoupled from your controller or model. I have been looking at Angular a lot lately and this is another example where view components are constructed from a mix of html(templates), the DOM (directives), and Javascript (the code that implements directives). The model is pure Javascript objects and the controller is also Javascript. Decoupling is an abstract concept that can be realized in many different ways.

schtoo 13y ago
Imagine this scenario: I've developed my app. Designer gets hired later and spits out a cool new layout and design... No feature changes at all. similarly... Then next year, management decides we need to give the app a "fresh new look" for v2. [If I'm using React or JQuery-only] From what I can tell, this will cause me to have to dive through a whole bunch of JS code where I'm sifting through business logic and imperative code to find JSX/html sprinkled throughout and make the necessary changes. Also, since I'm changing actual code the chances of introducing new bugs in this process is high. [If I'm using Angular] Go through html. Change html and css. Leave code and business logic alone. This is not an entirely contrived situation (at least not for me). As I'm working towards a releasable product, one of the areas that go through the most change and flux is the design and layout.
- peterhunt 13y ago
  With React, if you've structured your components correctly (i.e. only display logic) it should be straightforward to change the layout. In fact, it should be easier, since React is modular and has clearly defined boundaries and semantics. Working with React components vs angular directives are pretty similar in terms of difficulty for designers, IMO, but we think that React components are easier to build than directives. Most designers can figure it out if they know html.