Firstly right to the jargon ,is there any actual difference between
the two or do they mean the same?
Fluid in its historical context meant it was NOT fixed i.e it expanded if a wider screen was available. Precursor to responsive. Fluid does not mean it adapts to smalleer/tablet/smartphone screens.
Responsive means, it adapts to device/screensize.
Is it safe to classify the current development mainly a html5/css3
based one ?
This feature is based on Media Queries which I think is a feature of CSS3, so CSS3 is a prerequisite.
What Popular frameworks are available to easily implement this?
Bootstrap is one.
What are the most common compatibility issues in terms of different browser types?
Volumes could be written on incompatibilities. But you just should be aware that there are differences. Proper resets have been developed and improved. Keep an eye on those and try to test as much as you can. Newer features have varying level of compliance in different browsers, so be aware of that.
I understand there are methods like this http://css-tricks.com/resolution-specific-stylesheets/ which does this come under?.
This is an example of media query. The feature which makes responsive design work.
Are there any external browser detection methods besides the api calls specific to the >browser that are employed in this regard?
I am not sure, but generally, browsers have an identifier which is part of the HTTP request. It is not strictly speaking "reliable" as you can easily craft an HTTP request and claim to be from Chrome, but practically, it works.
Is it safe to assume that just accounting for proper scaling from width 980px onwards to the maximum size would be sufficient to accommodate this? given we aren't presenting any new information for the new size.
Just because the industry trend is to lock at 980px does not mean you cannot design for a bigger screen. If your usecase mandates that you present a more richer content to bigger screen, perhaps you can tinker with it. But generally the practice is that 980 is the max contemporary designers consider desktop top be, considering there is no new content. (but this assumption is not set in stone - you can decide to ditch it if it makes sense)
Does it make sense to have additional information ( which conflicts with purpose of responsive web design) to utilize the top size and beyond?
Actually this debate is still ongoing, but I personally think, responsive design means you have the opportunity to present content differently, and even different content. So what is best for a smart phone is not going to be sufficient for a desktop. In the end it would be your personal judgement based on your requirements.
You are completely right that it should be the same artifacts that are deployed to all environments. Especially in npm, dependencies tend to be loosely defined so a updated dependency could easily break the build just by building at different times. Even if you don't use hat or tilde in packages.json transient dependencies could be less strict with versioning.
What is suggested in the other answer regarding dotenv will not work unless you combine it with #2 og #3 from this answer.
Basically you have a few options.
Switch on the url in order to find the current environment you are in. This is a complete hack. Do not do this!!
Have some server side code replace global vars in index.html on each request. The simplest solution depends on what you have installed on your server. It could be php or even something simple as SSI if you are on IIS. You will want to keep you index.html as valid html so you still can do local development. SSI is nice in this regard since it works inside comments. If you do php, keep your index.html and make a index.php which reads index.html but replaces your vars. A html parser works well for this replacement.
Setup your release to generate a transformed index.html from the index.html created during build. This transformed index contains a snapshot of variables for a given environment when release is run on the environment.
If your needs are simply configuration variables, I would recommend #3. If you need something a little more advanced, go for #2.
Best Answer
Dont use frames ;) What you could do is to provide the links to the other departement and in the end of the url set some kind of GET variable ex mysite.com?commingFromApp=true And then on the website you could make a method the prints the menu to the website, and if commingFromApp is not true then print out the menu, and if its true dont print it because the user is comming from the app and should not see the menu