Comment by skrebbel | Hacker News Reader

Comment by skrebbel | Hacker News Reader

Parent Full thread

> Is a highly dynamic site really a "get out of jail free card" for best practices?

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.

it's difficult for the programmer of a parent component to influence the behavior of the child component

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.

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

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

EDIT: I gave wrong presentation link initially.

This presentation explains what problems React inline CSS solves

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

I'm curious, which demos and talks are you referring to?

One of those done at the latest ReactJS Conf where they introduced React Native. Check their channel on YT for the info.

Why are you looking at this as "bending the rules" instead of as creating new rules for a new way of building web applications? Just hand-waving "best practices" doesn't actually mean that something is best practices if someone else comes up with a better practice.

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

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

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.

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

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 <style> tags and code in <script> 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.

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?

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.

My main complaint with CSS in JS is that a strict naming convention solves a lot of the problems without coupling styles in application bundles. Basically, I don't want to invalidate my JS bundle just to include a new visual theme.

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.

Seriously, all these points sound very fancy and I suspect that they bring unequivocal productivity gain to the dev environment but my main beef with FB or any other org is that they push this workflow or other methodologies as universal best practices or even distort reality and claim that mixing content/presentation/logic is the only right way to "separation of concerns" and all what you knew before about this topic is a hoax and big lie.

I think you're reading too much into it. I see it as a new way of working with new tools that Facebook has found to be better for them. We can try the new tools and see if it works better for us.

Reply on news.ycombinator.com