We Keep Coding

How can i integrate C# code into an existing Javascript website (Angular)?

We have a large ecosystem of Javascript websites, actually Angular, that we don't plan to rewrite in c# any time soon. So the goal here is to be able to use a vendor dll in our javascript to add new features. This is a proprietary system, we don't have any alternative, either we use their dll, either we don't have the feature. I'm putting a lot of hope in webassembly here because this looked like the silver bullet to use that dll without having to rewrite the whole project in a new language.
Problem: all the examples I can find are more about using Blazor to write a website or call javascript from Blazor, I can't find anything to include some ad-hoc C# code into an existing project. I would have thought it would be a great use case though because being able to leverage C# threadpool on a webpage sounds pretty good to me!
Anyone has done something similar or know some examples/tutorials I could follow?

As Tuan says Angular and C# don't really live together in the way you suggest.
I would say there are 2 separate approaches here.
Have an C#.NET MVC app but adjust the routing so the Angular App Handles some pages and the .NET app handles others. This is OK but there are so many pitfalls such as the fact that you can not share bundled CSS and JS or maintain the structure of your Angular controllers (amongst others).
A better way would be keep your lovely Angular app the way it is but have a separate Web API application/project and use the angular app to call the dll (reference in the project) within the correct context as a REST API (via a simple POST or GET call).
It's not too clear exactly what you want to do when you say "... able to use a vendor dll in our javascript to add new features ..." but you can find info on writing and implementing C# as a Web API in .NET core here
https://learn.microsoft.com/en-us/aspnet/core/tutorials/first-web-api?view=aspnetcore-3.1&tabs=visual-studio

NODE and CMS with angularjs: how do they cooperate

I'm thinking about making something with the MEAN stack. I need a way to edit the content of the site, like e.g. Wordpress offers (basically a CMS).
The confusing bit is how the CMS and Angular would work together. I've looked at a CMS named Keystone, and there you have to set up some routing etc. in Node. Won't this crash with the routing you set up in Angluar?
In other CMSs I've used, the creation of the views happens on the server side. In Angular, as far as I understand, you crate a HTML template, which you can populate with data in an angular controller. This also seems like something that could crash between CMSs and Angular. Is this the case?
Is there any other quirks or similar about Angular and content managment systems I should know about, or is it usually not much problems integrating the two?

meanjs.org has a pretty good approach to this. Install meanjs. It comes with a sigin/signup and even allows you to create articles from the vanilla install.
Put simply, when you are creating a web app with the MEAN stack, think of AngularJS as "THE" app, and node.js as the api.
If you approach building your web app as a javascript application (AngularJS), that happens to get its data from an server api (node.js), then you will begin to understand how to properly use the MEAN stack.
First: Angular will have the routes defined in the $routeProvider. Build the routing urls in AngularJS first. They are "THE" routes for your web app. A good way to look at it is to build the AngularJS portion with the ability to change your api server, even to another language (PHP, python, go, etc) if necessary.
Second: Build your AngularJS to communicate to the api with $resource. Essentially a $resource is an easy way to call out to an api using restful routing. This "restful routing" is now the routing that needs to be "mimicked/copied" into the routing for the node.js routes.
Often the AngularJS routes (the url) will match the $resource routing that matches the node.js routing.
Again, take a look at meanjs.org and you will have a better understanding on how to properly organize what "seems like" (and actually are) two separate apps.

Basically, you need three sets of routes (or two if you are doing it on the cheap).
Start out with a set of routes on the server that return regular webpages. Forget about JavaScript. Do not involve Angular at this stage.
Second, add another set of routes on the server which return data in a rawer form (such as JSON). This would typically be a RESTful API.
Third, add Angular to the client. When the view needs to be updated, update the URL in the browser and use Ajax to hit the RESTful API to get the data needed to populate it. (You want the URL you set the address bar to to match the URL of the page from the first set of routes that you are duplicating with JS and the data from the RESTful route).
If you are doing it on the cheap, like Gawker did, then you would skip the first set of routes and go direct to the JS+REST approach.

I think you need CMS on MEAN stack development environment.
there are some cms on mean stack you can try.
PancilBlue
Calipso
try this.

I was trying something similar, I found this link very useful AngularJsCMS It has told about free respond cms which is based on angularjs and have the ability to create pages like wordpress and manage contents.

We have been working on a project using angular and keystonejs. Simply serve the default template layout found in keystone and inject the data-ng-view tag within the body tag. Serve this template for all requests to '/'.
Then write your angular app normally to consume endpoints. These endpoints can be done in keystone using the api middleware. In the routes/index.js file add a key/value pair in the routes object with the name of your custom endpoint then import the folder containing your endpoint function definitions.
var routes = {
views: importRoutes('./views'),
api: importRoutes('./api')
};
exports = module.exports = function(app) {
app.get('/api/posts', keystone.middleware.api, routes.api.post.index);}

I recently migrated my blog over to MEANie - a lightweight custom MEAN Stack CMS that I developed.
I made it open source for anyone to use and posted details and setup instructions on my blog at http://jasonwatmore.com/meanie.

Styling and Connecting the Backbone to a Ruby Server

So I've been doing a lot of learning on Backbone, Sass, RoR, Bootstrap, etc. and I am extremely frustrated that no sources I've found (including in Tuts+ and Code School) mention any way of putting it all together...I have no clue how to style a web page if all of the contents I want in the page are being built through backbone...so if I want to click on the "About" page on a website, have all that page's Backbone contents styled correctly when appended to the DOM.
Secondly, I'm not sure how I should be creating these web pages for a website; should I be creating the whole page in Backbone and then keep that on the server until someone clicks on, for example, that "About" page and then have the whole page loaded into the view? Or am I totally misunderstanding one of the ways you can use Backbone? Along with this then, how am I supposed to communicate Backbone to a Ruby Server? just using Ajax?
I'm looking for sources and anyone who can help me understand this stuff in clear terms!
Thanks so much,
-Stu.

Presuming that you want to build a single page app it is important to understand each one responsibilities:
Rails
Create a full stack application that runs on server
Create a consumable API
Manage assets pipeline
...
Backbone
To manage your frontend javascript application
Decouple data from the views using Models
Connect an API over a RESTful JSON interface
...
Keep in mind this is a oversimplification of both...
Rails will handle the backend, retrieving an API to be consumed by Backbone. The Rails assets pipeline will deliver all files that Backbone needs, including the css that will style you app.
It might be somehow confusing since you will hear concepts that eventually will clash between them, like in both ends will have Models, Views and Router, but they will live live independently from each other, one will work on the server-side (Rails) and the other on the client-side (Backbone).
To give an example:
Rails would render:
domain
|-index.html
|-js/*.js
|-css/*.css
`-api/*.json
Backbone would use the DOM (index.html) and the js scripts to execute logic, append the views into the DOM and Read/Write data using ajax through the API.
Another confusing thing would be views, since Rails will generate those for you, and backbone will also have their own views, so the usual setup:
In the client-side, Backbone will be have at least the following parts:
Router — it will orchestrate your app, binding an event a route, let's say /#about page and create a view and pass the respective model:
Model — it will request data from the API and dispatch an event when done
View — it will use a template to render the model data
In this case Rails would manage the page assets and provide the API, Backbone would have it own router, models, views and templates to render the page on the client-side.
This also means that the way you combine both it could be only answered regarding the project specificities, and there a lot of ways to use both.
That said, IMHO it's really important to first understand how a full Backbone app works,
then use something like backbone-rails gem, to see how both can be managed in a consistente way.

I know what you mean--there's a lot of random tutorials out there for Backbone but not a lot that put it all together. To a certain extent that's just how it is, unfortunately, but I'd say once you're past learning the basics from Code School and others, the hands down best resource for how to actually build complicated apps is:
BackboneRails: http://www.backbonerails.com/
It covers the stack you're talking about mostly. The first few screencasts are free and then subsequent ones are paid but well worth it. Building on the skills I've learned from BackboneRails and I've built several fairly complicated apps that turned out great. Good luck!

How to structure Javascript architecture to complement a PHP MVC web app?

I am working on a new JavaScript architecture for a web app iteration. The previous iteration had lots of inline code, scattered includes, no directory structure for .js files and everything was in the global namespace. I am aiming to: keep the script includes in the footer, keep everything in an application namespace/object, add organization to the .js files and minify all the application specific files in to one bundle.js
I am trying to take a modular approach based on Nicholas Zakas: “Scalable JavaScript Application Architecture” http://www.yuiblog.com/blog/2009/09/17/video-bayjax-sept-09/
the site is currently structred like so
/app
/models
/views
/home
/auth
/meta
about.tpl
contact.tpl
privacy.tpl
/controllers
home.php
auth.php
meta.php
/public
/js
core.js
/modules
module files here
/jquery
jqueryplugins here
/controllers
home.js
auth.js
meta.js
the controllers have methods which correspond to our url routing and view rendering. For example http://localhost/meta/contact would call the "contact" action on the "meta" controller and render the meta/contact template.
I am planning the js architecture around a single initialization call to the apps global object passing it the controller and method as arguments i.e.
localwebapp.init(controller, method);
At this point in the design I am struggling on inheritance and module implementation. Some modules will be global and be used throughout all the site, some modules will be used through out specific controllers, and some modules will be on controller actions only.
Modules are independent and will not communicate with each other they will need to be assigned to a "sandbox" which they will check with for event triggers
I'm thinking I will need sandbox and module classes. The controller scripts will basically be a few lines of modules being assigned to the sandbox and initialized.
Let me know if I am reinventing a wheel here. Any direction is much appreciated. I have looked in to javascript MVC frame works like JavaScriptMVC but it looks like it is not what I need

We use JavaScript MVC as well. You can use both in an application.
In our case, our application is more frontend driven and the backend side (ZF with MVC) is a REST API and JavaScript MVC makes it easy to do so. The feature set is still in the PHP part, and not client-side, we just utilize a lot of parts of JavaScript MVC to make it look snappier, etc..
In the end, I see no reason why it couldn't be the other way around though.
I think the misconception about the view part in MVC is that it's something to see in the browser. The view can be XML or JSON as well. I'm sure you know that, but I wanted to emphasize this part since it is what throws most people off.
If you generally ask about JavaScript MVC -- I don't know if it's the best MVC framework (client-side-wise), but it forces you to define models, controllers and it comes with a testing framework to make sure things go according to plan.
Let me know if this helps!

Best Way to Organize an ExtJS Project

I've just started developing an ExtJS application that I plan to support with a very lightweight JSON PHP service. Other than that, it will be standalone. My question is, what is the best way to organize the files and classes that will inevitably come into existence? Anyone have any experience with large ExtJS projects (several thousand lines).
­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­

I would start here http://blog.extjs.eu/know-how/writing-a-big-application-in-ext/
This site gives a good introductory overview of how to structure your application.
We are currently using these ideas in two of our ASP.NET MVC / ExtJS applications.

While developing your application your file and folder structure shouldn't really matter as you're probably going to want to minimize the release code and stick it in a single JS file when you're done. An automated handler or build script is probably going to be the best bet for this (see http://extjs.com/forum/showthread.php?t=44158).
That said, I've read somewhere on the ExtJS forums that a single file per class is advisable, and I can attest to that from my own experience.

I suggest users are willing to wait for an application to load, so we typically load all of JS during initial app startup. I suggest loading and eval'ing JS files as needed is unnecessary - especially when all JS will be minified before deployment to production.
I suggest namepsaces, one class per file, and a well-defined and well-documented class hierarchy.

When starting new big project, I decided to make it modular. Usually, in big projects not all modules are used by a particular user, so I load them on demand. F.e., if a project would have 50+ modules, the big probability is that user is working only with 10-.
Such architecture lets you to have the initial code relatively small.
Modules are stored on the server and loaded by AJAX call, eval'uating the responseText in AJAX callback. The only issue with this, you must keep track on module dependencies, which could be stored inside modules as well. I have a class called Module, and I check every new module instance for existance within the task. If it doesn't yet exist, I load it from the server.