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

101–110 of 145 posts

Re: A Primer for Building Single Page Applications with React

#101

Post by mejari »

timepiece wrote: post #84
nwienert wrote: post #78

Earlier quoted context omitted.

I've actually never found myself more productive than with React, by a long shot. The reasons why mixing them together makes sense are above us in the thread, but I'd highly recommend vjeux's presentation on CSS in JS: 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

vjeux's presentation only applies to a very specific use case at his org namely FB. I should not imitate him just because of the fact that it fitted or served FB right. We should think on our own and figure what works for us and not blindly follow FB's or any other org's lead. 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 ind…

>We should think on our own and figure what works for us and not blindly follow

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.

Re: A Primer for Building Single Page Applications with React

#102

Post by timepiece »

mejari wrote: post #99
timepiece wrote: post #67

Earlier quoted context omitted.

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

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.

Re: A Primer for Building Single Page Applications with React

#103

Post by timepiece »

mejari wrote: post #101
timepiece wrote: post #84

Earlier quoted context omitted.

vjeux's presentation only applies to a very specific use case at his org namely FB. I should not imitate him just because of the fact that it fitted or served FB right. We should think on our own and figure what works for us and not blindly follow FB's or any other org's lead. 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 ind…

>We should think on our own and figure what works for us and not blindly follow 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.

https://news.ycombinator.com/item?id=9258259

Re: A Primer for Building Single Page Applications with React

#104

Post by mejari »

timepiece wrote: post #102
mejari wrote: post #99

Earlier quoted context omitted.

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…

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

Re: A Primer for Building Single Page Applications with React

#105

Post by mejari »

timepiece wrote: post #98
nightski wrote: post #94

Earlier quoted context omitted.

I am curious, what concerns are not being separated? You have presentation markup with presentation logic. Actually it seems to me the concerns are being brought closer together. Or are you making artificial boundaries between declarative and imperative code?

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 they should be.

Re: A Primer for Building Single Page Applications with React

#106

Post by ripter »

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.

I have the same feelings. That's why I like projects like http://www.ractivejs.org/ and http://rivetsjs.com/ . They have the productivity benefits without forcing you to use JSX.

Re: A Primer for Building Single Page Applications with React

#107

Post by Bahamut »

BinaryIdiot wrote: post #89
Bahamut wrote: post #74

Earlier quoted context omitted.

Web Components does what React essentially does, bring them together.

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.

Re: A Primer for Building Single Page Applications with React

#109

Post by origin-unknown »

timepiece wrote: post #67
rpedela wrote: post #66

Earlier quoted context omitted.

> 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

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.

Re: A Primer for Building Single Page Applications with React

#110

Post by mtrimpe »

JustSomeNobody wrote: post #75
emehrkay wrote: post #49

Earlier quoted context omitted.

This is a great question. The little iOS development that I've done it seems like the script and style are tied together with the markup. 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 dire…

Not familiar with react and barely JavaScript, but why is bad? I mean as longs as the function calls a function on another module and doesn't contain any more logic than that. The other module remains testable, and the only logic in the UI is a function call. If the interface of the module changes, sure the UI would have to change, but I tend to think people over think things at this point (my opinion and I hope it d…

As far as I'm concerned was bad because 'function' was a global variable reference.

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

Post reply on HN