I agree... I've thought about trying to get the app running locally, etc.. so I can try and maybe create a node/js version of the site, running against the same database. I don't remember enough ruby to be productive at all in the codebase either.
I write node scripts that run from package.json and/or interface with utilities/binaries from npm packages mostly. Even for projects that aren't node, as it's installed everywhere.
Here's an example from an active mono-repo.
"husky": {
"hooks": {
"pre-commit": "node -r esm !main/scripts/run-child-npm-task precommit"
}
},
"scripts": {
"reset:db": "node -r esm !main/scripts/reset-db",
"build": "node -r esm !main/scripts/run-child-npm-task build",
"test": "node -r esm !main/scripts/run-child-npm-task test",
"first-init": "node -r esm !main/scripts/first-init"
}
A typical script for me has the following shell…
import path from "path";
import shell from "shelljs";
export async function main(skip) {
if (skip) return;
... work goes here ...
}
main(!!module.parent).catch(err => {
console.error(err);
process.exit((err && err.code) || 666);
});
Generally, path and shelljs are nearly always used, so I start with the above and add more as needed. the mz package has also been useful, but mostly replaced with internal options.
As to comments on deleting accounts, it's really easy to create an account... and even then, a lot of it may be done manually so that even if you delete an account a new one could be created, even with a captcha etc.
A lot of the spammy articles are from accounts that only have one article posted. Requiring X karma (at least an upvoted comment or something) might help the bulk of it.
It depends on what the focus is. I might recommend a jQuery base for a web based application that didn't serve to mostly display content today, outside of that VueJS is about as easy to graft on, similar for preact/inferno as other JSX/React look alikes at a relatively low overhead.
My preference for applications is for React first. Vue just doesn't feel like it would scale to full-size Applications. Both vue and angular seem to have holes in their server-rendering options and angular in particular seems far more complicated than putting the lego pieces together with react + mobx/redux and fetch/axios.
There are a few jquery alternatives if you want to inherit most of the utility bits without the bulk.
Very cool... I was afraid this was a text content filter, which are generally very bad all around.
That said, I'm not sure a naked blue woman might not trigger the filter, while a couple of tan colored bowls might. Automated content filtering often become more trouble than it's worth with many false positives and negatives respectively.
I'm still not sure I get why Bit is any more useful than just straight npm... I had similar feelings about Bower, which also had node+npm as a prerequisite.
I write node scripts that run from package.json and/or interface with utilities/binaries from npm packages mostly. Even for projects that aren't node, as it's installed everywhere. Here's an example from an active mono-repo. "husky": { "hooks": { "pre-commit": "node -r esm !main/scripts/run-child-npm-task precommit" } }, "scripts": { "reset:db": "node -r esm !main/scripts/reset-db", "build": "node -r esm !main/scripts/run-child-npm-task build", "test": "node -r esm !main/scripts/run-child-npm-task test", "first-init": "node -r esm !main/scripts/first-init" } A typical script for me has the following shell… import path from "path"; import shell from "shelljs"; export async function main(skip) { if (skip) return; ... work goes here ... } main(!!module.parent).catch(err => { console.error(err); process.exit((err && err.code) || 666); }); Generally, path and shelljs are nearly always used, so I start with the above and add more as needed. the mz package has also been useful, but mostly replaced with internal options.