That's a best practice for web sites. If you're making a website (where every page has roughly the same look and structure, but just different content), then it's probably a good best practice to have.

It all went haywire, however, when using the web for applications. While well-designed applications also have commonalities to them (button styles, margins, etc), the various screens and dialogs in an application vary way more in structure than the various pages on a typical informational web site tend to do.

It turns out that separating logic and presentation in web applications the way you would on web sites is a very bad match. You simply end up putting logic that is very closely tied together in three different places. E.g. typical jQuery code that falls apart the moment you change either the HTML (turn a div into a span, whatever), or the css class names, or the jquery selector/handler code, all of which is located in different files deep in a different directory hierarchy. For each single widget in your app (button, dropdown, LoginScreen, etc), it's much better to put all that code together.

And that's what React lets you do.

(note that this means that you really do want to tie your styles closely to your react components too - either inside the JS or with e.g. one .sass file for each React component)

As a web developer for the past 10 years I can't disagree with this more. It wasn't the easiest thing to accomplish maybe 5 years ago but it was always doable and now with web components it's incredibly easy.

React is cool but I wouldn't call separating logic and presentation bad. I would call that a best practice.

Even if that is true, it is not clear that trying to separate HTML, CSS and JS necessarily achieves a useful degree of separation between logic and presentation.

In "traditional" application development, we have long recognised that things like keeping the underlying data isolated from any particular presentation or interaction style can have advantages. However, you wouldn't find a lot of people arguing for creating a dialog box in some visual design tool in your IDE, writing separate code in a programming language to populate its controls and respond to interactions with them, and then somehow trying to join the dialog and the code up while keeping everything at arm's length.

Modular design has always been about keeping related aspects of a program together and minimising other dependencies. This means you can do useful things like changing one part of a program without running into surprising or uncontrolled side effects elsewhere. But if you have different aspects of the application that inherently do change together, as is often the case with HTML/CSS/JS in a web app, there is little benefit to trying to separate them for dogmatic reasons.

I agree and this is why I continued to iterate OP's word usage of separating logic and presentation. Separation of HTML, CSS and JavaScript isn't always useful or straight forward but separating business logic from the user interface is incredibly important, in my opinion.

Separation of HTML, CSS and JavaScript is more of an organizational thing in my mind. JSX makes the syntax awkward and more complex in my opinion especially when you're working with a group of designers who are constantly tweaking styles, element layouts, etc. But for a team of only developers it's not so bad. Still I personally find it easier to simply avoid JSX either way.

I agree, but if we're talking about using a front-end framework like React here, wouldn't that mean we're only talking about the UI parts of the application anyway?

Personally I'm not a big fan of either big frameworks generally or some details of React in particular, but the people behind React do make reasonable arguments in favour of their more component-based separation of concerns.

I don't think so; when working on code for a web application there is always code, styling and html elements that deal ONLY with the presentation side of it but then there is also code that handles talking to the backend, negotiating with web sockets, etc. That code really needs to be separated and what I'm referring to.

> the people behind React do make reasonable arguments in favour of their more component-based separation of concerns.

I love component based separations and I get the feeling many of us are talking about similar things.

Right, but React isn't normally used for things like back-end comms. It's often loosely described as being for the "V" in "MVC", which makes sense given the whole declarative specification of DOM content angle and the one-way data binding style.

I think it's very important to keep the interface away from the logic. Creating components in React that only drive the user interface isn't bad but it's not as straightforward as something native like dealing directly html and css. I've worked with many designers who are awesome at styling and making pages look great but when they have to edit any type of scripting or something outside of HTML / CSS it's a whole new skill-set they need to learn to be effective (a skill-set they don't really need that the majority do not have).

I do agree that there are concerns when it comes to having people edit certain aspects if they specialize, I have seen similar things in the past. I would say that this depends on the people you work with.

Depends on what we're referring to when we talk about logic. I consider the user anything the user directly interacts with while with the logic I was mostly referring to business logic. It's fine to have interactive pieces that need JavaScript as long as they're kept away from the business logic.

My rule of thumb is: the user interface and the business logic should be separated to the point where you can completely replace the business logic without touching the user interface and vice versa. That's the separations I strive for and it's incredibly helpful when a designer wants to completely rearrange everything about the user interface because only one area needs changing.

I think that there is a certain amount of logic that is necessary in our views. Otherwise, JavaScript would not exist. Manipulating the DOM via the vanilla API or via jQuery is only hiding that logic in another file. The logic is still there, and calling it "separate" is not useful, in my opinion.

I like the way React bundles this view-specific logic and the markup together. Now I don't have to look at some HTML and wonder if some JavaScript somewhere is messing with it.

CSS is another matter entirely. CSS doesn't change behavior and is another concern entirely, so I do still prefer it to live in its own files rather than being inline. React doesn't change anything about this, and that is fine by me.

No, of course not. React proposes to replace one "best practice" by a different one. In React, the best practice is to divide your application up in a deep hierarchy of components, each of which adds one single little layer of abstraction over the other. Then, put all the logic and presentation that's relevant for that little piece of abstraction together inside that little component.

This way, you have very good separation of concerns - all "Button" stuff is together in the Button component, all AreYouSureDialog stuff is together in the AreYouSureDialog component (which in turn uses Button components), and so on. Because components can only interact with each other via props and refs, you also have very fine-grained control over the interface: it's difficult for the programmer of a parent component to influence the behavior of the child component any further than by the interfaces that the child component explicitly exposes for that (= props, and public methods for use via refs).

How is all that a "get out of jail free card"?

I've found that this design principle works very well with teams, even with junior team members. I've seen people who had never gotten further than building 10000-line CSS files with all kinds of horrible hacks let loose in a React project. After we explained the component principle and made an example component to easily copy&paste, they independently and without further encouragement started making React components for each little possibly-reusable part of the application. Buttons, frames, dialogs, cards, lists, you name it. React really makes it easy to make well-structured code and difficult to make things a mess.

I don't see how and of this impacts any of the responsibilities you mention (good UX, accessibility, etc) so I can't respond to that part of your comment.

You seem to focus only on the few drawbacks of CSS inheritance and to ignore its biggest advantages like you don't have to write declaration for every and each element on the page and rely instead on inheritance for props to cascade properly.

Yeah sometimes undesired consequences occur on elements but it's easy to remedy the situation if you know what are you doing but by moving all the presentation info to your logic layer in development, and then littering the structure/content layer i.e. HTML via style attribute in run time, this is unacceptables and can't be seen as progress for the industry in any way.

This presentation explains what problems React inline CSS solves. https://speakerdeck.com/vjeux/react-css-in-js

EDIT: I gave wrong presentation link initially.

Could you please summarize in a few sentences what are these probs this approach deem to solve?

Because I have seen demos and talks from React people and I was appalled at their neglect of best practices and bending the rules just to push their product and technologies on the community

Luckily, you can use CSS best practices with React.

The problems mentioned in the presentation, followed by some CSS-friendly solutions --

1) Global namespace: all selectors are global

Use a naming convention.

2) Dependencies: no way to specify that a block of markup depends on a particular CSS module

Use a build process and a naming convention that includes a component name.

3) Dead code elimination: difficult to determine when styles are no longer needed

Loop over components and extract CSS component names from class attributes.

4) Minification: can't minify class names in markup

Not a bottleneck, nobody cares.

5) Sharing constants: can't share constants/variables with javascript

Use rework/postcss.

6) Non-deterministic resolution: loading styles asynchronously can result in different results since specificity assumes later rules should override earlier rules and async load order is arbitrary

Use SUIT CSS to prevent collisions and normalize specificity.

7) Isolation: base component CSS can be trashed by authors of subcomponents, making it difficult to change base CSS.

Reduce responsibilities of base component CSS. Encourage use of modifier classes. Ban tag selectors from component CSS. Use a SUIT CSS compliance checker.

I use SUIT CSS with React and couldn't be happier.

I'm all for progress and challenging/questioning previous norms or traditions. I hate dogma and dogmatic people like the next guy but I need first to see improvement in the new thing before going adopting it.

What I see now frankly is the opposite of progress. I see people advocating for dispensing of "separation pf concerns" & "progressive enhancement" in the name of "progress" and "modernization" but in reality it's just a lame excuse to regress to a state of affairs that we guys fought too hard to combat it and bring awareness to the community of its pitfalls and shortcomings.

There are a million articles and talks that provide exactly this. If you don't find them convincing that's fine, but don't act like no one is providing them.

> I see people advocating for dispensing of "separation pf concerns" & "progressive enhancement" in the name of "progress" and "modernization"

If that's what you see then you're looking in some weird places. The drivers behind React aren't just vague ideas like "modernization", they're the real-world benefits people are seeing when developing and using these new ideas. You're doing a disservice to everyone by fabricating the reasons behind these ideas just because you don't like them.

>in reality it's just a lame excuse to regress to a state of affairs that we guys fought too hard to combat it

This really just seems like a stodgy "get off my lawn, kids!" approach, which is at odds with your "I hate dogma" statements. Do you honestly believe that people are pushing in this direction solely as an excuse to regress things and make it worse? Even if you think that it is "regressing" things, you can't possibly be so conservative and entrenched as to actually believe that is people's goal, can you?

If you have been asked what's the most important convincing reason to switch to React, what would be your answer?

Please no mention of web apps vs web docs. We're already established that.

- It has been all about progress and modernization all the time. Progress in terms of productivity gains and speed was the motivation behind dropping jQuery centered architecture and going for an MVC framework instead and it's what's motivating the spawning of these frameworks as well. I don't know why this point is contentious one for you.

Do you honestly believe that people are pushing in this direction solely as an excuse to regress things and make it worse?

I didn't say that and I don't believe that they're intentionally pushing in this way to harm the industry and the community but I do believe that , while in the midst of chasing the latest trendy object, they won't realize that they're giving up very valuable stuff that benefited the industry for a long time.

The template will contain logic like an iteration over what has currently been put in the basket. And maybe some condition that if the basket is empty you should show a friendly string instead. Then you have some additional logic in a js file that will collapse the list of items if the user does not want to see everything. This is usually done by using a id/class or html element to grab on to.

The idea behind React is that you put all possible states and ways the view can render in a component. You still would (generally) not have actual logic in it; like grabbing data from the server or calculating stuff.

It is different yes but I think it is a neat idea. We will have to see if it is a viable path forward but I think this "rethinking best practices" is really good and has already influenced the rest of the frameworks quite a lot.

But the problem with React is they are not being honest with marketing their technology. They claim that their approach to blending everything together as "separation of concerns " and some of their evangelists had even the nerve to claim that their approach is the only true way to best practices and that we have been doing it wrong all this time. So, it turned from product evangelism to pure propaganda for them.

If they were forthcoming about it from the get go "Hey guys, we know that violates SoC but you guys we'll make up in terms of productivity gains and speed what you will give up in maintenance and readability" but instead they keep pushing their propaganda and people seem to eat it up.

They have been very detailed with what you get with React and their first presentation was even called "Rethinking best practices".

It does not violate separation of concerns. For me it is the opposite and you actually have real separation of concerns instead of separation of technologies. And even if my project is pretty young it feels like it will be easier to maintain.

How often don't you have DOM manipulation (hiding or showing a div) in the same Javascript file as some actual logic. How is that separated concerns?

I am not puritan or dogmatic. That's what I have been trying to convey here. I'm pragmatic to the core but I am no propagandist.

If I was asked if template languages violate SoC, I would not hesitate to reply "SURE" but I'm keeping to a minimum and I'm using logic-less flavors instead.

But reinterpreting SoC as SoT and trying to evade admitting that you guys at fault is not really something to commend you on. Too much revisionism and propaganda for my taste.

Especially as more things go toward the web.

The disabled is a club anyone here can join, at any time.

All the GP is saying is that the trade-offs will depend on your audience.

  >  if it’s not curlable, it’s not on the web.

One common way is to have React render into a simulated DOM (e.g. https://github.com/tmpvar/jsdom) and then trigger event handlers with code. You make assertions over the structure of the rendered DOM to know whether things went fine, all without a browser attached.

A dumber way that works remarkably OK too for simpler scenarios is to just have React render stuff to HTML strings and do regexes over those strings. Hacky, and if you're doing serious app development you probably don't want this, but it's a very easy way to get started.

I think about how painful it would be adding a custom button(new behavior) to a notification on a website: you either add an event listener to the dom and listen for it to bubble or add it to the button directly(the easier option). These new web frameworks seem to be adding it directly to the dom node -- we're back to <a onClick="function('value')"> which is faster, but traditionally harder to manage. But since everything is a structured component (all of these things implement an interface) we can build them faster and worry about it on the component level and not the markup level.

I've been playing with React and Riot and it is a very interesting approach. You can build things out a lot faster than you used to and that is what matters in the end. The user will not care if you separate concerns (as long as the page renders and is accessible, but that is another story).

I don't think that's the case for React though so I'm not sure if the GP saw some other drawbacks in it (apart from the aesthetic of separating logic from presentation.)

So, how do you reason about that?

For example, we frequently create generic containers that modify the behavior of the child or parent. One example is a container that automatically sets its children to be "sticky" once you scroll past it. Another common parent is one that renders it's children is a modal (lightbox, dialog or similar). Another is a child component that, if you nest it into another, can notify the parent whenever its dimensions change.

You claim it is "settling" but I'll try to explain why its not only not "settling" but actually encouraging best practices. I'm not sure what language you're most familiar with but since you're talking about inheritance I'll try to provide Java analogies.

Hierarchal components => Hierarchical composition of classes

Mixins => Interfaces with default implementations (possible as of Java 8)

Inheritance, as defined by the OO paradigm, is very rarely the correct solution. Even in a language like Java, when it comes to classes, the best practice is to use composition over inheritance. If you haven't heard this before, or you don't agree, sorry but I'd rather not get into this myself. There are a ton of really good resources online about this, they will do a far better job explaining than I would.

So, I'm okay with non classical inheritance or any other non conventional constructs that would make our lives easier but I'm really skeptical about the direction that these frameworks is taking the industry as a whole in, and I believe that their lack of enthusiasm for established best practices and breaking the rules without offering well thought and coherent alternatives is worrisome.

Those principles are in fact old, and originate in the desktop app. Every single desktop UI framework throughout history, from Xerox Star to Visual Basic to Swing to Delphi to Cocoa, has modeled the UI in terms of components (sometimes called controls or widgets) that can be contained within each other. Components are logically independent containers whose behaviour and rendering follow them around; drop a button onto a form, for example, and you get "button behaviour" without having to implement anything yourself. React follows this exact pattern.

The reason people are interested in "breaking" rules such as separation of style and markup is because those principles don't apply well to this way of doing things. Components aren't document markup to be styled, they're views that need to draw themselves. You can devise various ways to continue using CSS to "skin" these components, but this is ultimately the enemy of a good component. It turns out that for components to be true containers, they have to have complete control over their own rendering, and inserting global CSS that cascades into a component tends to violate that boundary. In other words, the component _is_ presentation, and therefore a "separation" makes no sense because there isn't much to separate.

You can debate the merit of modern single-page apps, but people are building them, and need the tools to do so. At the same time it's clear that people (not just developers) want both the power of the web, and the power of desktop apps, and developers are now trying to discover how this hybridization — the appification of the web browser and the webification of the desktop — can be attained. React is probably just one step in the search for some better converging structure.

You criticize React a lot in this thread, but I can assure that it's well thought and coherent. I've been a web developer for about 20 years, and this is the most productive and content I have been about working in a browser. I recommend trying it out.

It's just two different schools of thought and really comes down to personal preference. Fashion ebbs and flows and what was old is new, and what was new is old.

The core idea is that presentation logic belongs with the presentation; you cannot separate the two. In classical MVC frameworks such as Cocoa, this is accomplished with a controller that is tightly coupled with its view. Most people use Interface Builder and maintain the view in a separate file, but this is purely a pragmatic design allowing IB to use a different file format from your code. You could write the entire UI in Objective-C/Swift code, right in the controller, and in terms of layering there would not be a lick of difference.

React, like other MVC-bases systems, encourage the UI logic to be slim and strictly UI-oriented, and to move the application logic -- that which deals with the flow of data/state -- to a separate layer.

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.

see https://medium.com/@dan_abramov/smart-and-dumb-components-7c...

Just because it shares the implementation mechanism, it does not mean that they are mixed together. You can of course, but most of the time, you should not.

In other words, use css classes to style similarly looking elements instead of defining the styles inline (style attribute). Or use event delegation instead of adding a bunch of onClick attributes on your elements.

When talking about developer productivity (ie. maintenance, new feature development) what's more important than separation of technologies is separation of concerns at the "component" level.

Component in this context can be simply defined as a single file that contains all the logic required to render and manipulate a single DOM element throughout its lifecycle.

What React does (as is Angular to a lesser extend) is allow you to mix markup and behaviour while developing but keep those things separate when generating the end result.

React's building block is the 'component' – the idea being that this is an isolated part of the application. By its very nature, isolating a component means separating the HTML from all the other HTML, and the script from all the other script.

Since components are generally quite small, it makes sense to bundle these together. You don't suffer the problems that encouraged people to separate concerns in the first place (things like have loads of interacting code that's duplicated and closely tied to structure), so it's OK to take a different approach – and I must say, in practice it works really well.

CSS is a separate issue – React doesn't mix CSS into the pot at all.

Not quite true, ReactNative does, React supports it[0] and one of the lead devs (vjeux, gave the reactjs conf 2015 keynote) has a presentation on doing exactly that[1] alongside being the lead dev on Facebook's css-layout (which IIRC underlies ReactNative's layouting)

[0] https://facebook.github.io/react/tips/inline-styles.html

[1] https://speakerdeck.com/vjeux/react-css-in-js

[2] https://github.com/facebook/css-layout/graphs/contributors

Sure. React even ships with testing utilities to make that easier: http://facebook.github.io/react/docs/test-utils.html

> I'm wondering how the marrying of presentation and logic affects that.

Depends on the exact component. For pure components as part of bigger applications it's really quite easy, just render the component with a known dataset and see if it's got everything where things should be. Then again, that's similar to testing templates… most people don't really test their templates.

For self-contained "widget" components things are a bit harder, it's similar to testing DOM-based widgets really.

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/js. This is what react allows by using props/state as the input to the component/rendering function. It also permits you to pass complex objects as props/state but I like keeping to simple data as much as possible.

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.

My favourite part is passing functions and complex objects as element properties. Very useful.

The idea is to think of your HTML as a part of your app, rather than just "something that is modified by the JS".

In contrast to Angular where we're told to put logic in templates (or just HTML files) it looks a lot better.

First, they came for the HTML markup and said "come on guys, JSX is just some XML on steroids. You should not worry at all" and we didn't speak up.

Then they came for CSS and said "come on guys, they're just small components and the same as placing the CSS declarations via the style attribute anyway blah blah blah" and we didn't speak up.

So you don't really know what's gonna be their next victim. There's a lot of revisionism and reinterpretation of best practices going on in the industry and hipsters and fanbois seem to go chasing the latest shiny and trendy object out there.

Nothing we can do to help save these people!

But seriously guys, have you seen any React dev code with all those CSS declarations and HTML markup over each other?

I pity the ones who will be assigned maintain this spaghetti code.

https://speakerdeck.com/vjeux/react-css-in-js

I have apps in production with it you can look at the code to as well:

https://github.com/reapp/hacker-news-app

Re productivity, if it works for you, good for you but please don't attempt to reinterpret/bend the rules that are well established in the industry just to avoid criticism. For me, it's just an act of intellectual dishonesty.

React does violate the principle of separation of concerns and "we're working on a component not a document level" is not fooling anyone.

We should alert and educate people on this issue and then they can decide for themselves if they would go ahead nevertheless or stick to their guns. That's all!

Or are you making artificial boundaries between declarative and imperative code?

But throwing CSS declarations to the mix is just too much for me. Now I'll have to maintain markup/presentation/logic in the same place, that's a nightmare and ticking bomb IMHO.

Only if you're doing it wrong. Presentation logic and markup will be in the same place sure, that's a good thing, but any application logic not dealing directly with displaying dom elements shouldn't be in and among your presentation code. Your concerns are separated and your presentation code is in the same place, like you would logically think they should be.

I have watched React Native talks in which they were advocating for this and bluntly calling it proper "separation of concerns".

But when you say that presentational markup and logic should be grouped together, doesn't this mean that we have to divide our js files even further to separate business logic from presentation or view logic?

But doesn't your last comment rail against all these "fanbois" not blindly following "best practices" and actually attempting to find out what works best?

In fact, your next sentence in this comment:

>please don't attempt to reinterpret/bend the rules that are well established in the industry

You seem to be contradicting yourself.