Totally going to sound a bit shit, but I think not having content like this is what drew me to hashnode in the first place. Nothing personal man, just my 2c

There is actually a lot of material available, including youtube videos. I recommend you have a search for "react isomorphic" and go from there. For the record, "universal" means a similar thing, but also encompasses mobile devices with the use of react-native. All it means is we render the application HTML on the server and send it straight to the client for client's react to pick up and do less legwork. Faster initial load times and the benefit of having a single code base. This is essentially how we used to do it by rendering our HTML in some PHP backend (wordpress, laravel, zend, sapphire etc) and then using jquery on the client to find some dom nodes and attach interactions to them. Presently this process is more meaningful and less fragmented, so this pattern is back. Just some examples from first page of results: https://scotch.io/tutorials/react-on-the-server-for-beginners-build-a-universal-react-and-node-app https://bensmithett.github.io/going-isomorphic-with-react/ (press space to advance slides) https://reactjsnews.com/isomorphic-react-in-real-life http://jmfurlott.com/tutorial-setting-up-a-simple-isomorphic-react-app/

In production, use even number versions like 4 or 6, these are the Long Term Support versions that will be patched for a certain time. These are the versions at which node.js is considered production-ready. The odd number versions are not LTS and you should generally stay away from them if you're worried about production stability. You should use NVM for managing versions, switching out a version is as easy as a single command, not to mention installing node.js through NVM takes care of every single permissions mumbo-jumbo problem I've ever encountered (global installs, jumbled installs, unhelpful or uncommon errors) and seen people inquire about. After NVM, node stopped being about googling problems and became a smooth experience. Upgrading node.js should not be very necessary unless your project calls for it (medium to large scale, you have read changelogs and understand some new feature or fix that will benefit you greatly), or you're upgrading to a minor/patch version like from 6.0.0 to 6.2.14 or something (fyi those are not real version numbers). In which case you had better written a comprehensive test suite with 100% coverage so you can make sure things are still functioning after you punch in that aforementioned single NVM command. If you're later upgrading from 6 to 8 then your tests better have tests ;) /s

You use the flux pattern instead of "2-way-bind". React is unidirectional flow, that's its organisational strength and coincidentally the main reason for choosing it and redux together. You can use a package like redux-form for the particular question you asked, where all your input fields dispatch actions to a top-level redux store, and this data can be "connected" to from any component (using redux) to "bind" it. React/redux work this way for everything. This is so that your actions (or "events") all pass through a central store where they can be dealt with. Then when the main store updates as a result, any connected components will re-render with new props if needed. It eliminates about a million race conditions, spaghetti and complicated chains in larger apps.

I'll second this entirely. After the years of ui/ux I realised that some things would just be a lot simpler if I coded them myself and proper attention will be paid to what is easily dismissed by programmers as "designer complex". My general life enjoyment went up drastically and now programming is possibly my favourite thing next to cooking up a mean breakfast (these things also go well together). I only wish I did this a lot, lot earlier. It's not as scary as it seems and small experiences here and there eventually end up being a relatively complete skill-set.

Appreciate the exploratory approach you've got going. Curious to read about ember (the only framework I see as being potentially interesting), though at the moment I must admit not much will sway me from react/redux (and now react-apollo) as it has fed me well over the last two years :D

Don't obsess over abstracting from the beginning. It'll get you stuck in infinite loops. Make your thing work, then tidy it up.

Mate you need these beers.

If making something new, slow is better unless you're a genius. If making a small piece / component to spec then fast is better unless you don't read the spec properly.

Unreal Engine 4 has a Blueprints Editor which is seamlessly integrated with their open-source c++ core. You can expose values from your c++ code to the Blueprints Editor as "nodes" to drag around and connect. A lot of people get into UE4 and use blueprints to begin their new projects and seem to be getting into the programming mindstate with a gentler curve. I saw a portion of projects beginning as blueprints-only and slowly gravitate towards a more sane blueprints/c++ mix. It was cool seeing people with no programming knowledge post questions and engage in the problem solving process that is so core to being a developer. This is all anecdotal evidence from what I've seen in UE4 forums, UE4 answerhub, stackoverflow etc, but I'm of the opinion this approach is helpful and encouraging to a portion of users. Personally, it was quite nice exploring the engine API in a lighter overview while being able to plug things together and rearrange them to test my boundaries, so I would do it again.