> 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.
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.
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.
> 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.
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.
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.
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 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?
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.
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.
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.
As with all technologies it matters how they are used; I simply stated web components make the separation easier than ever before but that doesn't mean the same can't be done with JSX.
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).
Some components turn out to need logic though - consider some of the Twitter Bootstrap components that rely on JavaScript. They would not work without the JS.
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 agree with this. I also think it that keeping logic out of views is a good idea, but I think that like many one-liners, there is more to it than just that.
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.
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.