3 ms·

> On a current technology fad: React seems to be designed to ignore 40 years of accumulated software best practices. [1] Separation of concerns? Who needs that

> On a current technology fad: React seems to be designed to ignore 40 years of accumulated software best practices. [1] Separation of concerns? Who needs that any more? And the rationale for it is that it allows teams of 100 developers work together on an app. Open standards? Nah, how about lock-in to custom language extensions that will prevent you from migrating your code to the next web standard! Much better. That's some strawman right here. First, JSX is optional. Sencondly, JSX is open. You may disagree whether it's a standard or not, but you know what? If tomorrow you end up with a large codebase where you want to get rid of JSX, you just apply a JSX transpiler on your existing codebase. Problem solved. As for separation of concerns, you have a little bit more of a case. React does allow you to put business logic in your views... just like 99% percent of templating languages out there. But React does not force you to do that. You can have only the minimum amount of logic you need, and put most of your frontend business logic in your store.

SomeCallMeTim 11y ago
It's not just about the JSX part. That's a piece of the larger problem: The fact that the HTML & CSS are being built up in JavaScript at all. This troubles me at a deep level, and no matter the approach you use, it won't likely be portable to another framework. Templates using a "handlebars" syntax are pretty portable with minor tweaks, in general.
- spion 11y ago
  This happened because CSS and HTML are a totally broken model, useless for writing larger applications. They don't provide any sort of modularity / encapsulation - everything is in the open, present inside one big giant namespace with class names colliding with other class names and styles cascading through / being inherited by everything you want or don't want. Web Components / HTML Imports kind of solve this though, but they're still not there. http://caniuse.com/#search=components http://caniuse.com/#search=components JavaScript has lexical scope, and that pretty much solves everything. CSS styles are now local variables and need to be passed around. Components are not just a dump of HTML, but opaque functions - their inner structure cannot be (accidentaly) accessed by outside components. Ah - finally, a sensible programming model. Just imagine what would be possible if CSS class names were lexical, not global strings - and you could import them into HTML (perhaps with renaming). How big of a change that would be in terms of making things easier to separate. Well... React users got tired of imagining things :) http://glenmaddern.com/articles/css-modules http://glenmaddern.com/articles/css-modules
  - spion 11y ago
    Of course Web Components solve it by reinventing all the possible wheels. Tim forbid that we get standard lexical scope and parameter passing.
- mercurial 11y ago
  Well, you're only building raw HTML for your lower-level components (in JSX or in Javascript). The difference with standard templating is that this considerably more composable. In this regard, it's not very different from custom directives in Angular (from what I can see, I don't do Angular). And from my point of view, having this mix is much preferable to the traditional HTML templating + jQuery soup. You can't escape the fact that any non-trivial rendering needs some logic. If you don't let yourself get carried away, you get the exact amount of logic you need for your component in a reusable package. As someone currently porting a codebase from the dark ages of the web to React, I have difficulty expressing how nice that feels.

SomeCallMeTim 11y ago

It's not just about the JSX part. That's a piece of the larger problem: The fact that the HTML & CSS are being built up in JavaScript at all. This troubles me at a deep level, and no matter the approach you use, it won't likely be portable to another framework. Templates using a "handlebars" syntax are pretty portable with minor tweaks, in general.

spion 11y ago
This happened because CSS and HTML are a totally broken model, useless for writing larger applications. They don't provide any sort of modularity / encapsulation - everything is in the open, present inside one big giant namespace with class names colliding with other class names and styles cascading through / being inherited by everything you want or don't want. Web Components / HTML Imports kind of solve this though, but they're still not there. http://caniuse.com/#search=components http://caniuse.com/#search=components JavaScript has lexical scope, and that pretty much solves everything. CSS styles are now local variables and need to be passed around. Components are not just a dump of HTML, but opaque functions - their inner structure cannot be (accidentaly) accessed by outside components. Ah - finally, a sensible programming model. Just imagine what would be possible if CSS class names were lexical, not global strings - and you could import them into HTML (perhaps with renaming). How big of a change that would be in terms of making things easier to separate. Well... React users got tired of imagining things :) http://glenmaddern.com/articles/css-modules http://glenmaddern.com/articles/css-modules
- spion 11y ago
  Of course Web Components solve it by reinventing all the possible wheels. Tim forbid that we get standard lexical scope and parameter passing.
mercurial 11y ago
Well, you're only building raw HTML for your lower-level components (in JSX or in Javascript). The difference with standard templating is that this considerably more composable. In this regard, it's not very different from custom directives in Angular (from what I can see, I don't do Angular). And from my point of view, having this mix is much preferable to the traditional HTML templating + jQuery soup. You can't escape the fact that any non-trivial rendering needs some logic. If you don't let yourself get carried away, you get the exact amount of logic you need for your component in a reusable package. As someone currently porting a codebase from the dark ages of the web to React, I have difficulty expressing how nice that feels.