Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Primer for Building Single Page Applications with React

github.com

Post reply on HN
Print view View original

121–130 of 145 posts

Re: A Primer for Building Single Page Applications with React

#121

Post by timepiece »

mejari wrote: post #104
timepiece wrote: post #102

Earlier quoted context omitted.

You guys have to convince us first that mixing content+structure/presentation/logic is the best way to go forward in web development for the following reasons 1,2,3 ..etc. 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…

>You guys have to convince us first that mixing content+structure/presentation/logic is the best way to go forward in web development for the following reasons 1,2,3 ..etc. 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 enhan…

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.

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.

Re: A Primer for Building Single Page Applications with React

#122

Post by timepiece »

mejari wrote: post #105
timepiece wrote: post #98

Earlier quoted context omitted.

I'm OK with presentational markup co-existing with logic but to be honest I prefer it the template way not the other way around where the markup is the guest at the JS file. 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.

>Now I'll have to maintain markup/presentation/logic in the same place 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 t…

What about bringing CSS declarations to the mix?

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?

Re: A Primer for Building Single Page Applications with React

#123

Post by timepiece »

cc81 wrote: post #119
timepiece wrote: post #102

Earlier quoted context omitted.

You guys have to convince us first that mixing content+structure/presentation/logic is the best way to go forward in web development for the following reasons 1,2,3 ..etc. 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…

You are already doing that in a normal template. Let us say you are building a shopping cart. 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. T…

The main difference is that the logic in template files is the guest here while the markup is the host. We're used to include presentation info in tags and code in tags. So, it is not really a great deal of change to include template language within our content even though I still prefer logic-less or minimal logic template languages over full blown ones to avoid turning web pages into a whole mess.

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.

Re: A Primer for Building Single Page Applications with React

#125

Post by cc81 »

timepiece wrote: post #123
cc81 wrote: post #119

Earlier quoted context omitted.

You are already doing that in a normal template. Let us say you are building a shopping cart. 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. T…

The main difference is that the logic in template files is the guest here while the markup is the host. We're used to include presentation info in tags and code in tags. So, it is not really a great deal of change to include template language within our content even though I still prefer logic-less or minimal logic template languages over full blown ones to avoid turning web pages into a whole mess. But the problem w…

It is still mixing presentation with logic if you use a template file. So why do you think it is alright to violate SoC in that case?

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?

Re: A Primer for Building Single Page Applications with React

#126

Post by pjtops »

nicksellen wrote: post #21
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.

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.

Re: A Primer for Building Single Page Applications with React

#127

Post by timepiece »

cc81 wrote: post #125
timepiece wrote: post #123

Earlier quoted context omitted.

The main difference is that the logic in template files is the guest here while the markup is the host. We're used to include presentation info in tags and code in tags. So, it is not really a great deal of change to include template language within our content even though I still prefer logic-less or minimal logic template languages over full blown ones to avoid turning web pages into a whole mess. But the problem w…

It is still mixing presentation with logic if you use a template file. So why do you think it is alright to violate SoC in that case? 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 technolog…

It is still mixing presentation with logic if you use a template file. So why do you think it is alright to violate SoC in that case?

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.

Re: A Primer for Building Single Page Applications with React

#128

Post by BinaryIdiot »

Bahamut wrote: post #107
BinaryIdiot wrote: post #89

Earlier quoted context omitted.

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'…

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.

> Some components turn out to need logic though

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.

Re: A Primer for Building Single Page Applications with React

#129

Post by BinaryIdiot »

Silhouette wrote: post #116
BinaryIdiot wrote: post #63

Earlier quoted context omitted.

> 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 incredib…

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…

> 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.

Re: A Primer for Building Single Page Applications with React

#130

Post by Silhouette »

BinaryIdiot wrote: post #129
Silhouette wrote: post #116

Earlier quoted context omitted.

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…

> 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 importan…

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.

Post reply on HN