Stripe has by far some of the best documentation and developer experience of any of the online-gateway payment processing options. With this vague of a question I'm going to assume you're just wanting to know if there are any major problems developers immediately encounter with it. My experience has been that many developers have already created resources on top of their API to make it even easier to consume it super easily from both the client/server. There are react/vue components for it: https://github.com/stripe/react-stripe-elements https://github.com/fromAtoB/vue-stripe-elements Server-side API wrappers for most popular backends, just look at their list of packages: https://github.com/stripe They aren't the cheapest option, but it's because of how easy they have made it for developers to integrate with them.

A lot of times when I'm just trying to test something with fake data I'll just put the JSON into a javascript object and import it into my file. If it's non-parsed JSON that's basically just a big string I first just go into the development tools console of chrome and do a JSON.parse(); of the string. And then copy and paste the output into an object. So if I had this sample JSON: { "data": { "forms": [ { "id": -4, "name": "New Form 2", "published": false, "publishedDate": null, "format": "[\"g:-1\", \"g:-4\"]", "groups": [ { "id": -1, "name": "Testing Edit", "format": "[]", "settings": "{\"locked\": false, \"showTitle\": true}", "type": "SECTION" }, { "id": -4, "name": "Section", "format": "[]", "settings": "{\"locked\": false, \"showTitle\": true}", "type": "SECTION" } ] } ] } } I would just put it in a file called fakeData.js and just have it export the object: // fakeData.js const jsonResponse = { "data": { "forms": [ { "id": -4, "name": "New Form 2", "published": false, "publishedDate": null, "format": "[\"g:-1\", \"g:-4\"]", "groups": [ { "id": -1, "name": "Testing Edit", "format": "[]", "settings": "{\"locked\": false, \"showTitle\": true}", "type": "SECTION" }, { "id": -4, "name": "Section", "format": "[]", "settings": "{\"locked\": false, \"showTitle\": true}", "type": "SECTION" } ] } ] } }; export jsonResponse; Then in your other file you just import that object and reference it in your component: //index.js import React from 'react'; import ReactDOM from 'react-dom'; import './index.css'; import registerServiceWorker from './registerServiceWorker'; // Fake Data import { jsonResponse } from './fakeData'; import {NavBar} from './NavBar/navbar'; import {Concert} from './Concert/concert'; ReactDOM.render(<NavBar />, document.getElementById('navbar')); ReactDOM.render(<Concert source={jsonResponse} />, document.getElementById('concert')); registerServiceWorker(); Might be a quick workaround if all you're attempting to do is work with fake data to get better at using react. Another option would be to use http://jsonstub.com/

The link is a 404

I think another answer you might be looking for, is that when you jump into a frontend project or boilerplate, what is all the backend node stuff and what's all the frontend browser JS stuff? This was pretty confusing to me for a while, because you have all this build process stuff going on, and the line starts to blur when developing if any of that webpack/gulp/grunt stuff ends up in the browser as well. All of the build tools are using Node.js to manipulate the file system and run local dev servers and other various things. This is all being ran on your machine and not in the browser. But the browser code gets served up by this (node) dev server for you to see in your browser with localhost:8080 or whatever. Then eventually you use Node.js to package up your browser code into a bundle (or you could call it a web-package...). This bundle is going to be executed in the browser, but it was transformed into its final state using Node.js. So basically anything that's usually in the src directory is going to be what's bundled up and sent to the browser. Anything that's in the webpack, grunt, gulp, server directories are going to be executing in the Node.js environment to assist you during development, and eventually helping you build out your production assets. If you have a server-side-rendered (SSR) app, you'll have some of that Node.js code running as a server in production to serve up your html/javascript/css assets. But you'll usually always still have other build-process Node.js code that never is executed in production, and is only meant to help build the browser bundled JS. I hope I wasn't too presumptuous in assuming this might be part of your question. I know that this was definitely a hazy thing for me for a while with all this isomorphic stuff going on. Especially when you're trying to download NPM packages that you think are for the browser, but it ends up only being for Node.js runtime.

Honestly I usually find it pretty difficult to be able to plan out exactly what components I'm going to need until I'm in the middle of trying to implement the UI. That's probably mostly because of a lack of upfront requirements most of the time haha. But I usually end up starting with a container redux connected component. Then as I start filling up the render with lots of UI, I start refactoring that UI out into smaller dumb components. This feels like a pretty natural progression for me, since you usually need to orchestrate a bunch of stuff from redux first. Then as you start flushing out all the interactions needed and start to see the pieces of UI that are good "dumb" component candidates you can just pop them out into stateless functions and put them in separate files. You're usually able to already know what props these dumb components need as well. I'm curious if others end up following this same approach?

A large problem I see often is some juniors not having a good attitude about solving problems. Web development is endlessly frustrating and there are so many conflicting opinions about what should be done or what is the best technology to use for the task or whatever. However, many juniors will complain often and loudly about how confusing everything is and that they wish it would just work more simply. Or they complain about how someone should have already made the codebase easier to consume or jump into, and are unwilling to be the change they want to see. I don't mind helping other devs, in fact I'm very passionate about teaching others and helping them grasp concepts that are difficult and I want to always be learning from those better than myself as well. However, when you have an attitude where you're always blaming everything on being chaotic or because it's not following best practices already, I just want to say "I know... it's complicated and hard, that's why we're valuable". Work towards being a developer that is willing to take on and solve very difficult/chaotic/messy problems with a positive attitude, and you'll be highly valued wherever you are.

Meh I actually enjoyed reading all of the different technologies and seeing if he mentioned one I didn't know. It's also really interesting actually seeing written out all of the technologies you often times end up needing to know in a lot of front end projects.

One of my favorite things about React/Redux ecosystem is that it pushes you to learn a lot of best practices within javascript such as smart use of functional programming, immutability, and modularity. Is it a fad? Well almost every javascript framework eventually feels like a fad because people are so crazy good at innovating on the frontend very quickly. Last year everyone was complaining about this and saying they were getting javascript fatigue. I for one love the innovation and am excited about new developments, but it can become taxing feeling like as soon as you've picked up the new hotness, it's already old. Which is why javascript fundamentals are key to staying relevant and not getting too frustrated with the churn. React has a pretty steep learning curve simply because of all the things you usually end up using in a project. React itself is relatively small but most everyone now uses React/Redux with a ton of middleware and addons to make development more scalable, and everyone is usually transpiling with babel/traceur to get ES6/ES2015 features. Not to mention lots of boilerplates are using webpack which is its own beast. So I would definitely first focus on javascript (ES5) and then once you're comfortable with those basics I would move onto learning ES6/ES2015 features. Then getting into react or any other new framework coming out in the next few years won't feel so heavy to learn. You can see by inspecting this very site that they built it with react :D

Unfortunately there are 1000's of developers just like @iSamuelBarney that don't think speaking to others in a respectful tone is necessary or worthwhile. They think speaking to others condescendingly is simply a way to prove that you're more correct in your opinion. See how I'm speaking as if he isn't here? It's kinda what it feels like...