I think in most common scenarios a single mounting point makes sense. It mirrors closely what larger single page application frameworks like Angular and Aurelia do. Inject into the body or a DIV, then swap out the contents depending on where you are in the app.

Nice one @theonlyrealtodd glad you made some headway. It sounds like the developer has incorrectly used global modules which are generally reserved for tooling, not dependencies an application relies on. Moment for example would go into dependencies and not be installed globally. A CLI tool like Gulp, you would install globally and then also define it in your devDependencies to lock the version locally. You shouldn't need a VM, Node on Windows is the same as Node on Unix.

Are you both using the same version of Node.js? Support for future specification features works well in Node 6.x, which is the latest version, but as you discovered Node 4. which is the stable version needs use strict and has some limitations. To my knowledge Ubuntu should not come with any already installed dependencies. The only thing for dependencies I can think of is global Node modules are being used. But it is quite strange that Moment would ever be a global Node module. I would compare versions of Node being used by running: node -v -I think that is a good place to start.

Define terrible. If said terrible code worked and meant the deadline was meant, depending on the situation, it might be unavoidable. I am not ashamed to admit I have been in this situation. If a company can't manage their timelines appropriately, promise clients unrealistic timelines or worse: underquote to pocket the cash, then what is the alternative? I think we have all been in this situation before: Boss/Project manager: the project is due in two weeks, you're a smart guy and John will help you. This is a great client and we really want to woo them. This will just be a one time thing, in future we will properly plan for projects like this. Developer: Uh.. I don't think two weeks is achievable. If no changes are made and I get finalised designs, then we might be able to get it done. Designer: I just have a few design tweaks I want to make, nothing major. I have just redesigned this page, changed the font and oh, we need to make it look good on small, medium and large screens as well. Before you know it, you're leaving at 10pm every night. You're coming in at 7am and you're also working weekends to get the work done. Even if things aren't being changed (which in many situations, they are because others are under the pump as well), you'll be putting in serious overtime. I personally know of companies who factor in overtime into their estimates. They deliberately promise delivery dates that cannot be met without overtime. It's shady, but a lot of companies do it. It's amazing what being in fear of losing your job can do. Sometimes nothing you say or do can change that, except finding somewhere else to work. Sometimes even when you speak up, nothing changes because the decision has already been made without consulting you first, the client has been told a date already. If you work for a company that do client work like a studio that does Wordpress websites or apps, this situation is something you will encounter, some places more than others.

Sam Stephenson strikes me as the kind of guy who says things without thinking. React is quite an non-opinionated view library that makes no prior assumptions about what you are using it for. While Facebook might have built it with the original intent of making UI composition a lot easier for their developers and UI teams, it's not a niche library. It is no more a "Facebook specific" technology than PHP is. Look at other solutions, Rails came out of 37signals, Django was created by a newspaper. Some of the best frameworks and libraries were spun out of existing organisations/projects built to meet company needs. And look no further than Angular which came about from Google's internal Greentea team who work on a private CRM tool that Google use. The bottom line is: it shouldn't matter who created a particular framework, tool or library. You should always pick a particular piece of technology because it meets your needs.

I have a few I always use in my applications these days. Cloning things is something I find myself doing routinely in single page applications and comparing values. I could list way more, but I stopped at three, it was hard just choosing one. Cloning an array: function cloneArray (array) { return array .slice(); } Cloning an object: function cloneObject ( obj ) { return JSON .parse( JSON .stringify(obj)); } Object comparison: For comparing if two objects are the same. Loops through and checks if their properties match, their lengths and so on. function objectIsEqual ( a, b ) { var aProps = Object .keys(a); var bProps = Object .keys(b); if (aProps.length !== bProps.length) { return false ; } for ( let i = 0 ; i < aProps.length; i++) { var propName = aProps[i]; if (a[propName] !== b[propName]) { return false ; } } return true ; }

How about no library at all and just use a native XMLHttpRequest instead? Fetch is alright, but it has quite a few shortcomings now and you need a polyfill to even use it across browsers. The specification is in flux and until they address the issues like cancellation and monitoring file upload progress. var request = new XMLHttpRequest(); request.open( 'GET' , '/api/content' , true ); request.onload = function ( ) { if ( this .status >= 200 && this .status < 400 ) { var data = JSON .parse( this .response); } else { console .error( 'Response received and there was an error' ); } }; request.onerror = function ( ) { console .error( 'Request error' ); }; request.send();