Develop Reference

Parsing and Modifying local HTML with Node.js

I kind of have a weird question that's probably very basic. I'm pretty new to web development and front-end stuff in general.
Premise
First of all, my only real other experience with JS is using node.js to make a discord bot, as well as use D3 to make some basic GUI stuff.
I'm trying to make a GitHub pages wiki for a game I play. In the game, there are units, which I've encoded as JSON files, as well as a folder of images. All I really want is a basic index.html page with links to HTML pages for all the units. But since units are constantly being added, I am constantly updating the JSON so I want to be able to generate the HTML files for the units as well as updating index.html automatically.
The Method
Since all I really know is node.js, I've been trying to use that to make the HTML files. What I'm trying to do right now is this hacky thing of using fs to read in the HTML files, then use jsdom to parse them into something I can use jquery to edit. After that I just want to serialize the jsdom into a string and use fs to write to the file. Right now I can successfully deserialize with jsdom and serialize the html back with fs. But I'm having trouble editing the actual HTML.
Question
First of all, I have no idea whether this is a good way to do what I've described at all, I'm still in the very early stages, so I'm welcome to suggestions on other libraries or just completely redoing the project. The closest thing I've found that's similar to what I want to do is this GitHub snippet from 10 years ago, unfortunately, I'm sure a lot of it is outdated and my puny knowledge is not able to adapt to this to modern js: https://gist.github.com/clarkdave/959811. I was wondering whether someone could do that for me, or suggest a better way of doing what I'm trying to do. You can see what I'm currently trying to do here: https://github.com/aayu3/ATBotJSONDependencies

"In order to be able to generate HTML, and Auto-Update webpages based on a configuration, input, &/or data, you need a template engine. You might not know it, but that is what your building already, well sorta. You have the right idea, using fs to read your HTML, but your going to need to go a few steps further."
Read your HTML files, and store the read HTML as a string inside your Node.js code-base.
"sounds like you have done this already."
Build a Parsing-Engine
"You can build one, or implement a pre-built parser via a Node.js module, you can probably find a few different parsers on NPM."
Create a Library that Manipulates Strings
"You need to implement a library that can alter the HTML after it has been read. You can implement a simple library, custom for a single webpage, or you can build something that is a bit more dynamic in its use, something that you can re implement for a later purpose, which, semantically, would actually be closer to an API, rather than a library."
Build/Implement a Compiler
"The last thing you need to implement is a "compiler". This takes the HTML, that you have altered — which should be in the form of a string at this point — and compiles it back to HTML. Like the parser, you can implement a pre-built compiler, or write it yourself."
"Most people do not build their own engines, because its not financially feasible. To build something quickly, and easily, its far more efficient to use a tool that has been pre-built, and a lot of the tools that already have template engines built into them, have been built by very good opensource developers, or companies with a lot of money (e.g. React is built by Facebook)."
There's really no shortage to the options you have.
I have listed some alternate options you can choose below:
"Including a tutorial about building your own template engine, which is considered by most to be the hard way. The hard-way isn't always the worst way though. In this case, choosing the hard-way — building your own template engine — offers an insight to the mechanics of the popular tools that contemporary web developers use,"
The first is the obvious HTML Template Engine.
Right now Handlebars and Pug are really popular. A template engine is essentially a rendering tool that that coverts a special variable syntax used in your html to data that is stored, usually, in JSON format somewhere, and if that data is dynamic, the variable in your page will change depending on the state of your data. It might sound a bit confusing at first, but I promise this is quite simple. Bellow is the syntax commonly used.
// Your Data.
{
animal: "My little dog, Sophie.",
place: "Santa Rosa, Ca.",
}
// Your HTML template, or your input.
<h3>{{place}}</h3>
<p>{{animal}}</p>
// Your HTML output, that is compile and rendered by your template engine.
<h3>Santa Rosa, Ca.</h3>
<p>My little dog, Sophie.</p>
Here is a link to an online tool built by Handlebars, for experimenting with their template engine. In-fact I used that tool to create the example above.
You have two other options
For the second option, you could use a full blown framework like React or Vue. Personally I have never used React, but I have spent sometime with Vue. Vue implements the same Double Curly Bracket Syntax that the template engines use (which is demonstrated in the above example). Vue takes things a step further though, or it might be more correct to say Vue takes things 5-thousand and 42 steps further which is why some people choose it over a template engine, on the flip side it is also why many people choose to not use it (same goes for React). I am a Vanilla JS Guy myself...
...and as a Vanilla lover the 3rd Option you have, is what I do. Build a simple yet extremely powerful template engine for yourself. Though this may sound the most ludicrous and time consuming, its not. The frameworks will take you far more time to learn, and building a template engine for your self only takes a few functions, though it would be quicker to implement one that's already made for you from Option #1 above, however; Building your own template engine ensures you understand whats going on under that hood of yours, and not only that, but you become a mechanic to your own engine under your hood. You will be able to swap parts and make adjustments as you please. Bellow is a small bit of code that looks simple, but has a lot going on in it.
var render = (template, data) => {
return template.replace(/{{(.*?)}}/g, (match) => {
return data[match.split(/{{|}}/).filter(Boolean)[0]]
})
}
The snippet above was written by ShadowTime2000 at Hackernoon.com.
The snippet above is a great example for demonstrating the render function that is at the heart of most every JavaScript template engine (for the sake of correctness there are exceptions, but that is irrelevant here). The snippet above came from an entire guide that is a wonderful free resource that I suggest reading. Link is below.
Shadowtime2000's Tutorial on Template Engines
By the way I don't know shadow-time, and I am not trying to market his stuff. I really like the way he thinks. IMHO, Shadowtime2000 writes, very useful tutorials/guides, which is becoming increasingly harder to find the more I learn.
I hope something above helps you mate,
CHEERS!

Is it possible to combine Dojo with other JS frameworks?

We are using Dojo (1.9.3) as a JS framework for building a single page application. We are however spending too much time on the quirks of Dojo, so even simple tasks take a long time to implement. And since there is lack of proper documentation, we often have to resort to reading the source code and then implementing a workaround.
I feel that we would speed up development, and make it easier to maintain the code if we moved to some other framework. Our codebase is rather large, since it is a complex application, so we do not have time to re-write the whole thing at once. I was therefore hoping that it might be possible to combine Dojo with some other framework, so that we can move away from Dojo incrementally. I have only dabbled with these other framework in my spare time, and only wrote some small example apps, so I do not feel that I can really say whether or not they would play well with another framework, so I'm hoping that some of you out there can.
The frameworks I've been looking into - in the order of what I'd prefer based on my short investigation, but feel free to convince me otherwise.
Ember
React
Polymer
Angular (last due to me being scared of the major 2.0 overhaul)
While the main question is whether or not it is possible, please also advice on if you think it is a bad idea to do so.

The most I can say from the Dojo end of things is that Dojo itself is a toolkit, not a framework per se, and thus generally should not interfere with other scripts or frameworks. The reverse, on the other hand, can't always be said. So while I can't speak for all of the choices in your list, I do not think that Dojo itself will get in your way.
One possible exception I can think of is if any of the frameworks in question augment native prototypes, particularly Object, since that will affect enumerable properties in all objects and can wreak havoc on any scripts that use for...in loops without hasOwnProperty.
The only other exception I can think of is whether any of the frameworks in question for some reason do not coexist well with an AMD module loader.
That being said, I would also advise you to take the "promise" of frameworks with a grain of salt - you say that right now you are finding that implementing things with Dojo takes effort, and naturally the frameworks you list are attractive because they make certain parts of application development easy by offering patterns and conventions - but the question you should ask is, how hard does your framework make your job the moment you need to do something outside or against those conventions? Dojo may have a learning curve, but it generally doesn't prevent you from doing anything.

You can use them together, but it also depends on what you're trying to do. Some actions might take more time for integration than others.
Dijit
I only have experience with Ember.js and AngularJS, but a common concept in these frameworks is data binding. Data binding allows you to simply update the model and the view will reflect the changes in the model.
However, these usually do not work nicely with widgets. Widgets (like the Dijit library) create their own DOM and because of it, frameworks like Ember.js or AngularJS are not "aware" of these changes and cannot update the view in that case.
To make it work, you will have to wrap your widgets into components (Ember.js) or directives (AngularJS). An example of such wrapping can be found in this answer.
Dependency loading
Dependency loading might be confusing. AngularJS comes with their own dependency injection system, and means that you will have to use the Dojo AMD loader for Dojo modules and AngularJS dependency injection for AngularJS. The two work nicely together as far as I know (I've seen examples with the RequireJS AMD loader, so it should be possible).
With Ember.js I had a bit more troubles integrating with the AMD loader. The creator of Ember.js (Tom Dale) does not believe in AMD, and I've seen several issues trying to load Ember.js components with an AMD loader.
It all depends on how you wish to use these frameworks and what extra effort you want to make. To me it looks like you're not even sure what to use these frameworks for, since React.js or Polymer has a completely different purpose than AngularJS or Ember.js for example.

Is there an CDI-like mechanism thinkable for JavaScript

Before diving into JavaScript I was doing a lot of Java and especially liked the concept of context dependency injection. I used Google Guice a lot.
I know that JavaScript is not statically typed. And there are modulization concepts like used by requireJs or Node.js (even did something myself).
But is it thinkable or are there already solutions to inject dependencies based on a loosely defined interface.. (hope that isn't too stupid to ask)

The closest thing I have seen to what you are asking for (I think) is Architect from tim caswell.
It allows you to register modules abilities and requirements, so you can essentially request something that can preform an action, and have Architect check all the available modules to see if any of them support such an action.

You may also want to take a look at Errai (http://www.jboss.org/errai). It brings the client and sever together using the same programming paradigm by using the GWT javascript compiler bringing CDI to the browser (they're also working on JPA in the browser as well).

Backbone View Templates - Storing Them As External Files

I've been tinkering around with Backbone.js and wanted to know if there is possible to load View templates from external files. I've been using Underscore.js's micro template solution and including all my templates inside my HTML document has been bothering me.
I wanted to know if there is a standard way of doing this. Is there any good practice I should follow?
Thank you all for you time and help :-)

For all the template libraries that compile strings to javascript, with a little code in the header, each template could be stored in a separate file and exported through a common windows.myTemplates object or similar. The code would just evaluate the given string (the actual template), and bind the result to the windows object to make it available to other scripts. This way each template would be it's own script and would be accesses through a global object like windows.myTemplates.someTemplate.
That does not mean this is a good idea; unless you have many and/or big templates that are loaded very seldom, the normal goal is to minimize the roundtrips to the server, which is the exact opposite of what you are doing. Server-side, things are a bit different, but I'm assuming you're talking client side (based on your question).
There are fancier ways of pulling things in only when needed (google "javascript AMD", require.js and similar), but those are a bit more challenging to get started with.

mustache.js vs. jquery-tmpl

I'm looking at javascript templating for the first time and mustache and jquery-tmpl are the top contenders at the moment.
Some of my requirements:
templates will live in separate files to be included on multiple pages
all (or almost all) data will come from calls to a restful api which returns json
we're a java/eclipse shop, so syntax highlighting and compatibility with that would be nice, if it's an issue at all
Anyone know of any comparisons in terms of speed, ease of use, flexibility, stability? Any other factors I should be considering? Other top templating engines?
(I know there are other questions on this general topic, but I don't see any direct, broad comparisons between these two.)

My reason to choose mustache over any other template language was that it is implemented for any language you are likely to use. As it is also a true logic agnostic templating language your templates become portable. Therfore you gain the flexibility to choose to render your templates on the client or server side. Even though I have no benchmark available I don't think that performance should be an issue.

Initially I started out using jquery templates but development on that halted a long time ago.
Have a look at handlebar.js as an alternative to mustache.js ( see http://catchvar.com/jquery-tmpljs-vs-handlebarsjs )
handlebar.js seems to be about 2x faster than mustache.
I've been using handlebar in a few projects and mustasche in one or two. I much prefer handlebar and find it 'better'. Here's a nice tutorial by Andrew Burgess I found.
Edit Mar-2013: Also since then Twitter have released Hogan.js which looks awesome like everything else that Twitter does, so I'll be investigating that too at some point.