11–20 of 145 posts
Also is this a good direction for "mobile first" approach? What about platform independence? (iOS/Android/Desktop agnostic, etc, etc). (bootstrap? phonegap?)
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.
It's just two different schools of thought and really comes down to personal preference. Fashion ebbs and flows and what was old is new, and what was new is old.
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.
My favourite part is passing functions and complex objects as element properties. Very useful.
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 becomes voided. This gives incredible leverage and power to Facebook for anyone developing their core business with anything they've made/open sourced.
EDIT: https://github.com/Raynos/mercury was suggested as an alternative, I'm not sure how viable it is for different types of projects.
Can you build an SPA using just React? At the very least it seems like you'll need a URL router, and something like underscore.js to fill in the gaps.
But basically the answer is: yes, you can! You can even write an SPA using nothing but the regular W3C APIs! React just makes it very easy to keep the DOM in sync with your application state.
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.
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 applications also have commonalities to them (button styles, margins, etc), the various screens and dialogs in an application vary way more in structure than the various pages on a typical informational web site tend to do.
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. E.g. typical jQuery code that falls apart the moment you change either the HTML (turn a div into a span, whatever), or the css class names, or the jquery selector/handler code, all of which is located in different files deep in a different directory hierarchy. For each single widget in your app (button, dropdown, LoginScreen, etc), it's much better to put all that code together.
And that's what React lets you do.
(note that this means that you really do want to tie your styles closely to your react components too - either inside the JS or with e.g. one .sass file for each React component)
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…
Besides, Facebook is gonna sue you if you violate their patents, regardless of whether you use React or not. And the termination pertains to the patent license. They can't restrict your access to a BSD licensed software package.
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…
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 licenses that do not grant patent rights.
If you "try to fight it or even suggest it's not valid" then you do not lose your license for react and all other Facebook projects – what you lose is the additional patent rights grant. That's a huge difference!
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 is to think of your HTML as a part of your app, rather than just "something that is modified by the JS".