We Keep Coding

difference between _app.js and document.js

I downloaded html css template and trying to integrate in "nextjs". What is difference between "_app.js" and "document.js"? where should i use/include "css, js" files? either in "_app.js" or inside "document.js" ?

As nextJS docs specify related to _app.js:
Next.js uses the App component to initialize pages. You can override it and control the page initialization and:
Persist layouts between page changes
Keeping state when navigating pages
Custom error handling using componentDidCatch
Inject additional data into pages
Add global CSS
Next page of the docs also specify that _document.js is:
A custom Document can update the and tags used to render
a Page. This file is only rendered on the server, so event handlers
like onClick cannot be used in _document.
So basically your global css should go in App.js. However if you need to import certain CDN styles for some libraries I suppose you can do that here as well (but you should probably consider using just _app.js for this as well as it can be seen in this example)
Regarding the JS question as wikipedia states:
Next.js is an open-source web development framework created by Vercel enabling React-based web applications with server-side rendering and generating static websites.
So basically you should import React components where you need them, but I would recommend you to follow a tutorial if you need to learn more about React (There are a lot of beginner NextJS tutorials that can cover this).

Does loading a font using #import inside a web component with shadow reload the file?

I'm using Stencil to create a native browser web component using shadow for view encapsulation.
If at the top of my SCSS file I use
#import url($url-icons);
Will that have each component redownload the font/icon files for each component instance, there-by having a negative effect on performance?
If so, what's the best practice to handle this sort of shared dependency?

The browser has a cache mechanism for those font files, so files "should" be downloaded only once (that's not the case when devtools are open with disable cache, which many developers use). But this is actually an implementation detail of the browser, and not of web components.
This means that importing the font itself inside a web component will cause multiple requests by the browser, and by that potentially have an extra cost - delegating the responsibility of fetching the font only once to the browser.
It's better to only include the font-family definition inside the web component css, and import the fonts (only) once in the app requiring the web components library or in the library init method (In Stencil you can add it to your defineCustomElements() call)

Does a web-component that ships server side logic cease to be a web-component?

The definition says the use of any or all of the 4 standards hugging the platform itself, makes a web component.
custom-element
shadow-dom
imports
templates
As an author, sometimes, I may have to work around some shortcomings / rather unsupported requirements, to get things cracking
for example, an HTML import is still not widely accepted and even when it is, it doesn't do foreign imports.
Even if that happens, Any external stylesheet is not strictly scoped.
and a <link rel=import type=css...> still has no traction
If I need to then scope an external stylesheet, I need to first localize it, do an html import and not type=css and then , I would have the scoped stylesheet within my element
I'd want a component, that'd not expect a developer integrating it to his site, do anything but install it.
the component would do an async fetch request to the php logic, which would wrap any external library as html and respond to the fetch
If I author a component then, with some server side logic say php, to CURL the foreign resource , and place a document on the origin that can be a local import to be scoped,
would it cease to be a web-component?
Is the deifnition strictly front-end only?

I think you are mixing things - you can't "author a component with server side logic" by definition - since components are just some sugar JS running in the browser.
You can however make your component fetch resources from server side using fetch api/ajax - it will still be a component. If you want it to be reusable by other you just need to make sure you gave enough configuration options.
As for the external CSS sheets, you can normally style your application, the trick is to have your "view components"(non-reusable components only related to your application business logic), not use shadow dom - then you can style your views and components normally. Alternatively you can create one big "shared-styles" file that your components include.

It would not be a "Web Component" in the sense Google defined it, and in the sense of the Stack Overflow web-component tag.
Anyway, it seems that the term "Web Components" is not officially used any more for a few years, maybe because the technologies it recovers are not at the same level of maturity and adoption in concurrent web browser, or maybe because the term was too generic (and then often used for client-sid e technologies like React or Angular).
Update
Of course you can design some custom elements that perfom server requests (Ajax-like, REST calls) to get some data or any other parameters that will affect their behaviour or rendering.
You can load exernal stylesheet in Shadow DOM with the #import url CSS rule.

so on my opinion Web Components can´t contain any server side logic. Let´s say a Component just renders Text and your Server puts this text into your component before he sends it to your client.
I´d say thats a bad idea since the component will be chached by your Browser and next time your client uses this component it will use the cached verison and will still contain the old text. Better would be to use ajax to load the content and keep your Component stateless.
On the other hand as you mention in your post sometimes it is necessary to use such machanisms to get around the shortcoming of Polymer. For instance importing a external css/js library wich wasn´t ment to import into polymer. In this case I use gulp to create importable files for polymer, not sure if this is considered bad habbit.

Handling application-wide elements in an MVVM view model

I have been trying to find some good sources on how to handle application-wide elements when using MVVM for web development. I am using knockoutjs.
By application-wide I mean elements like a site's navigation. Perhaps each page has a login box, search box, a footer etc.
Should these go into a separate view model? Or should you derive each page's view model from a base view model containing these? Or should these properties be left out of a view model alltogether?
Thanks in advance.

Consider treating all your supporting components (menu, footer, etc) just the way you treat your business components. Also I recommend having separate viewmodels per UI component regardless of type of the UI component. This makes your components highly loosely coupled.
For example, the menu may have own view model (without being a part of any global viewmodel). Now you may use a PubSub library to implement publisher/subscribe notifications to have loosely coupled communication between different UI components (viewmodels), where your business components may show/hide themselves as per the event request.
But specifically for implementing a menu component, I recommend using a router library that can respond to the URL changes (hashtag part of URL). Then you can simply change URL when users navigate on the mainmenu (simple anchor tag), and your component will be activated/deactivated by the router library. This will let you to bookmark and use browser history buttons.
Have a look at http://boilerplatejs.org which is a reference architecture for large scale JavaScript development. It has all above implemented on it's sample application. It uses UrlController to activate/deactivate components based on URL changes, where as DomController is used to place components statically on the DOM itself (e.g. for menu, footer, headers ). It uses knockoutjs for most of the sample UI components.
Disclaimer: I'm the founder of BoilerplateJS

Global CSS - how to implement multiple frameworks

I have a piece of web software / web app which is predominantly javascript. It uses extJS framework and considerable custom scripts. The global stylesheet, call it main.css, consists of extJS library styles and our own new styles and extJS style overrides. This is all compiled using SASS.
Now, I want to embed the app into a web page. This is being done without an embed wrapper, but actually running the app in the page, including using global styles.
The external content in the page (non-app) is custom design using Bootstrap CSS framework and some jquery elements along with some Bootstrap overrides and some custom styles.
We cannot load Bootstrap as the global CSS, since the styles are significantly different and independent of the app styles and therefore want to avoid clashes.
How may I call the syles for their relevant areas, ensuring we can also do things like version control/update the core frameworks - extJS, bootstrap, jquery etc. easily and avoid clashes between the global styles - effectively treating them as different silos?

I may be misunderstanding a critical piece to this, but since you're using SASS, could you simply use:
#some-custom-area {
#import "path/to/bootstrap-result.css";
}
That is, take the Bootstrap CSS framework and all the custom rules you've written for it (in whatever CSS files those land in after compilation) and import them into your global stylesheet... but wrapped in a #some-custom-area selector. When SASS compiles that, it'll ensure all rules from the Bootstrap side are valid only within #some-custom-area.
Is that viable?