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

131–140 of 145 posts

Re: A Primer for Building Single Page Applications with React

#131

Post by Andir »

ripter wrote: post #106
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.

I wouldn't say I was "forced" to use JSX. I started out building React using only JavaScript notation to build the DOM (React.DOM.div, et al.) because I told myself that XML formatted text doesn't belong in my JavaScript. I then started to use JSX. It's a beautiful thing to get into if you give it more than a cursory glance. For one, readability is incredibly better with JSX and passing data becomes less of a chore.

Re: A Primer for Building Single Page Applications with React

#132

Post by lobster_johnson »

timepiece wrote: post #118
yazaddaruvala wrote: post #112

Earlier quoted context omitted.

> getting rid of inheritance altogether and settling for this interface boundary sharing 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 => Inte…

I aint no traditionalist or a Java supremacist :). I'm just an ordinary guy with passion for anything web development and I happen to like javascript a lot. 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 enthusi…

React isn't about breaking rules or disregarding best practices. It's simply recognizing that other principles need to be applied for a certain type of application.

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.

Re: A Primer for Building Single Page Applications with React

#133

Post by timepiece »

lobster_johnson wrote: post #132
timepiece wrote: post #118

Earlier quoted context omitted.

I aint no traditionalist or a Java supremacist :). I'm just an ordinary guy with passion for anything web development and I happen to like javascript a lot. 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 enthusi…

React isn't about breaking rules or disregarding best practices. It's simply recognizing that other principles need to be applied for a certain type of application. 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…

One of the best rebuttals I have read on this thread. I'm no React hater and I honestly consider trying it out just to see what's all the buzz about but it won't still fit my definition of proper SoC.

Re: A Primer for Building Single Page Applications with React

#134

Post by bronson »

bphogan wrote: post #111
dagw wrote: post #39

Earlier quoted context omitted.

Accessibility, SEO and bookmarkable resources aren't always a requirement. The GMail app (as opposed to the login page) for example doesn't need SEO. If you're targeting a known specific audience then you don't necessarily have to focus on accessibility. Bookmarkable resourecs doesn't always make sense either, for example if you're making a web based image editor (although I suppose you could create bookmarks into ea…

As a low vision computer user that supports disabled people on the web, and whose father spent 30 years working with disabled people, I can tell you for a fact that for some people, accessibility should be a requirement all the time. Especially as more things go toward the web. The disabled is a club anyone here can join, at any time.

Using the GP's example, it would take a huge amount of effort to make an online image editor accessible to the blind. I'm not sure that would be time well spent.

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

Re: A Primer for Building Single Page Applications with React

#135

Post by BinaryIdiot »

Silhouette wrote: post #130
BinaryIdiot wrote: post #129

Earlier quoted context omitted.

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

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

Re: A Primer for Building Single Page Applications with React

#136

Post by lobster_johnson »

timepiece wrote: post #133
lobster_johnson wrote: post #132

Earlier quoted context omitted.

React isn't about breaking rules or disregarding best practices. It's simply recognizing that other principles need to be applied for a certain type of application. 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…

One of the best rebuttals I have read on this thread. I'm no React hater and I honestly consider trying it out just to see what's all the buzz about but it won't still fit my definition of proper SoC.

I think you'd be surprised if you actually gave it a go. I'm something of a separation-of-concerns fussbucket myself.

Re: A Primer for Building Single Page Applications with React

#137

Post by swhipple »

loceng wrote: post #43
matthewmacleod wrote: post #23

Earlier quoted context omitted.

No, this is not correct. Please stop spreading this misinformation. Your license to use React is not contingent on 'not to sue them' – however, the additional patent grant that they give you is contingent on this. This patent grant is in addition to your license to use the software. If you accuse Facebook of violating one of your patents, then you automatically lose the right to use any of theirs. You do not lose you…

Facebook is changing the BSD license from being an implied license to being an explicit license, so it's not the same as BSD license; via DannyBee (open source lawyer), https://news.ycombinator.com/item?id=9113505

I think it's worth mentioning that software copyright licenses (like BSD) cover a particular implementation (a.k.a. "creative work") while U.S. patent licenses cover a design.

The likely reason for Facebook including the explicit patent license is that with an implicit license it is unclear if derivative works also share the rights to the granted patents (e.g. "can I take part of the implementation that utilizes a patented design and use it in another project?") [1].

The implicit patent rights of the BSD license may or may not extend to derivative works or different distributors, but the Facebook PATENTS file clarifies that it does not and avoids the ambiguity. For places outside of the U.S., that do not care about U.S. patent law, but do respect copyright, the BSD license is still in effect.

I don't think that simply using Facebook software will open up your business to a "huge business risk" -- any more so than you'd be doing by working on the assumption of an implied patent right grant on the derivative works permitted by the BSD license. IANAL.

[1] From the same thread: https://news.ycombinator.com/item?id=9113515

Re: A Primer for Building Single Page Applications with React

#138

Post by Silhouette »

BinaryIdiot wrote: post #135
Silhouette wrote: post #130

Earlier quoted context omitted.

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…

> 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, e…

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.

Re: A Primer for Building Single Page Applications with React

#139

Post by ARussell »

BinaryIdiot wrote: post #128
Bahamut wrote: post #107

Earlier quoted context omitted.

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

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.

Re: A Primer for Building Single Page Applications with React

#140

Post by jbergens »

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

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.
Post reply on HN