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

31–40 of 145 posts

Re: A Primer for Building Single Page Applications with React

#31

Post by myhf »

fizixer wrote: post #11

Question from a JS layman: React is great in comparison to what? vanilla JS? Angular/Backbone/Ember? JQuery? any other *.JS? Also is this a good direction for "mobile first" approach? What about platform independence? (iOS/Android/Desktop agnostic, etc, etc). (bootstrap? phonegap?)

In comparison to Angular, React is more idiomatic. It is very easy to reason about the scope, lifecycle, and performance of React components if you are familiar with JavaScript as a language.

In comparison with Backbone/JQuery, React is more declarative. It encourages the developer to describe the structure of the UI in a given state and let the engine handle the transitions between states. It's possible to use Backbone models and events with React views with very little impedance mismatch.

I would like to hear an Ember expert's perspective.

React Native has an interesting approach to mobile-first development. The general philosophy is "learn once, write anywhere" instead of "write once, run anywhere". Most apps cannot make the most of their platform while being truly platform-independent, but unifying component lifecycle behavior between platforms could end up being easier on developers than learning the particulars of each platform, while producing a better result than a PhoneGap-style wrapper.

Re: A Primer for Building Single Page Applications with React

#33

Post by pjtops »

skrebbel wrote: post #17
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.

> 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? That's a best practice for web sites. If you're making a website (where every page has roughly the same look and structure, but just different content), then it's probably a good best practice to have. It all went haywire, however, when using the web for applications . While well-designed applica…

What about desktop/mobile applications - is it ok to mix your logic and presentation there?

Re: A Primer for Building Single Page Applications with React

#34

Post by NoGravitas »

skrebbel wrote: post #17
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.

> 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? That's a best practice for web sites. If you're making a website (where every page has roughly the same look and structure, but just different content), then it's probably a good best practice to have. It all went haywire, however, when using the web for applications . While well-designed applica…

Is the distinction between web sites and web apps really valid, though? No matter how dynamic your site is, you still have certain responsibilities to your users, including giving them the best user experience you can, but also things like accessibility, sane SEO, bookmarkable resources, and, in the long run, maintainability. Is a highly dynamic site really a "get out of jail free card" for best practices?

Re: A Primer for Building Single Page Applications with React

#35

Post by WhitneyLand »

matthewmacleod wrote: post #23
[deleted] wrote: post #22

Earlier quoted context omitted.

[deleted]

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…

It may not be correct, but do you deny that it's already been repeated enough that it'll take another 6-12 months of wasted hallway conversations discrediting it?

When that BillG email for money urban legend first came out relatives literally called just to ask about it.

Re: A Primer for Building Single Page Applications with React

#36

Post by loceng »

matthewmacleod wrote: post #19
loceng wrote: post #15

What are your thoughts on, and how do you let your clients know (since you're a web agency?), that using anything built by Facebook comes with a huge business risk? With the included PATENTS file, if Facebook decides a patent they filed is something you violate then they will sue you or ask for a royalty. If you try to fight it or even suggest it's not valid then your license for React and all other Facebook projects…

You have not been completely accurate here. Using code written by Facebook is not a huge business risk, unless you consider the use of any open-source code to be a business risk. The PATENTS file that Facebook distributes with it's open-source projects grants additional guaranteed rights. It does not place any additional restrictions or risks on your use of the software, above and beyond any that exist with other lic…

I'm copy/pasting what user DannyBee (his about on HN: "I'm an open source lawyer who hacks on compilers" via https://news.ycombinator.com/user?id=DannyBee ) has said here https://news.ycombinator.com/item?id=9113324 - he's replying to something another user said -

"Facebook is granting you additional rights on top of the BSD license. In the worst case, where you do something that causes the patent rights to be revoked, you're still left with the same rights you have under the BSD license. This is unambiguously safer to use than if they had released it under a vanilla BSD license. As for why Facebook did this, they're most likely trying to give away additional rights while still maintaining the ability to use these patents defensively, in the event someone sues them for infringing a different patent."

This is 100% totally and completely wrong :)

The BSD license normally includes an implied patent license.

It says " Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met .. "

This grants an implied patent license to the patents necessary to actually do this, as long as you meet the restrictions.

This is actually well settled law. You don't get to give people stuff unrestricted, and say "you can use this for free", and then say "just kidding, what i meant was, you can use this for free as long as you pay me for the patents" However, when you do what facebook has done, and give an explicit license, you have overwritten the terms of that implied license, and you get no implied license.

So it is not only "not unambiguously safer", you are not "left with the same rights you had under the bsd license if it is revoked".

This is because if you revoke the explicit grant, you get nothing in terms of patents. But the implicit grant is not revokable unless you violate the copyright license.

So sorry, but this is not "better than the default" and does not in fact, help you.

Re: A Primer for Building Single Page Applications with React

#37

Post by skrebbel »

NoGravitas wrote: post #34
skrebbel wrote: post #17

Earlier quoted context omitted.

> 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? That's a best practice for web sites. If you're making a website (where every page has roughly the same look and structure, but just different content), then it's probably a good best practice to have. It all went haywire, however, when using the web for applications . While well-designed applica…

Is the distinction between web sites and web apps really valid, though? No matter how dynamic your site is, you still have certain responsibilities to your users, including giving them the best user experience you can, but also things like accessibility, sane SEO, bookmarkable resources, and, in the long run, maintainability. Is a highly dynamic site really a "get out of jail free card" for best practices?

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

Re: A Primer for Building Single Page Applications with React

#38

Post by loceng »

dada78641 wrote: post #18
loceng wrote: post #15

What are your thoughts on, and how do you let your clients know (since you're a web agency?), that using anything built by Facebook comes with a huge business risk? With the included PATENTS file, if Facebook decides a patent they filed is something you violate then they will sue you or ask for a royalty. If you try to fight it or even suggest it's not valid then your license for React and all other Facebook projects…

It's undue paranoia. It says essentially the same thing as the Apache 'Grant of Patent License' section. Namely, if you instigate a patent lawsuit, the free patent license offered by Facebook no longer applies. It would be impossible for Facebook or Apache to engage in patent lawsuits if they did not include this termination clause. Besides, Facebook is gonna sue you if you violate their patents, regardless of whethe…

This isn't accurate according to what DannyBee says, an open source lawyer - please read my comment above at https://news.ycombinator.com/item?id=9256093 that includes copy/paste of a comment he's made before.

TL;DR: 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.

Re: A Primer for Building Single Page Applications with React

#39

Post by dagw »

NoGravitas wrote: post #34
skrebbel wrote: post #17

Earlier quoted context omitted.

> 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? That's a best practice for web sites. If you're making a website (where every page has roughly the same look and structure, but just different content), then it's probably a good best practice to have. It all went haywire, however, when using the web for applications . While well-designed applica…

Is the distinction between web sites and web apps really valid, though? No matter how dynamic your site is, you still have certain responsibilities to your users, including giving them the best user experience you can, but also things like accessibility, sane SEO, bookmarkable resources, and, in the long run, maintainability. Is a highly dynamic site really a "get out of jail free card" for best practices?

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 each images editing history or something if you're doing non-destructive editing) . Maintainability is of course important, but I've yet to see a convincing argument that one approach gives a priori better maintainability.

Re: A Primer for Building Single Page Applications with React

#40

Post by philbo »

skrebbel wrote: post #17
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.

> 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? That's a best practice for web sites. If you're making a website (where every page has roughly the same look and structure, but just different content), then it's probably a good best practice to have. It all went haywire, however, when using the web for applications . While well-designed applica…

The reason I usually prefer to separate script and markup is that it makes the logic easier to test and those tests less brittle when the markup changes. Not having had any experience with react, I was wondering what the accepted approach to testing is?
Post reply on HN