Just to clarify: my suggestion to port Groff to JavaScript was really a joke. If one desires a JS-hosted Troff solution, the sane approach would be to:
- *Node + Browsers:* Transpile C++ to JavaScript with Emscripten - *Node only:* Create a native binding to C++ - *Prospective future: *Use WebAssembly to run binary applications in web environments. Porting Groff by hand to JavaScript is possible, but there are better solutions. Now, as for this: *> The Node package manager is among the least secure package management concepts on the planet* Yes I couldn't agree more. In fact, mine is probably one of the harshest opinions of the Node community. Doesn't mean I follow their (mis)practices and mistakes. =) > and the Node concept of modularization is the most excessive example of atomization syndrome i ever heard of. I hope that stuff is but a fashionable hype, it certainly lacks the potential of a sustainable technology Our opinions here are the same, but neither of them are new. Don't confuse NPM (Node Package Manager) as being integral to Node. Node is a runtime environment, NPM is everything about the Unix philosophy done wrong (I'd rather not spiral off an another rant here). *> … one of the main assets of groff: That it is completely stand-alone with minimal dependencies* So is all the code I've been writing. =) See for yourself <https://github.com/Alhadis/Roff.js/blob/master/package.json>; the only packages it references are a test-runner (Mocha) and an assertion library for said test-runner (Chai). Even those are being used very lightly. Its only "dependencies" are on Troff and on modern-day web technologies. I say "web technologies" because simply saying "the browser" is misleading, due to Electron blurring the lines between "desktop app" and "web app". *> Note that even though it's hard to maintain and certainly not recommended for any serious use, an OpenBSD port of Node does exist.* It's already outdated, and has no support for JS language features that have been introduced in more recent years: async/await, and support for native ES modules, which browsers have also started supporting. Moreover, the copy of NPM it bundles is so outdated, I had to disable 2FA on my npmjs.com account (!!!) just to publish a new release. Took me ages to figure out why my "login was wrong", only to find it predated NPM's belated support for 2FA. It reported an HTTP status 401, but didn't explain why. Classic NPM engineering, everybody! *> By the way, rewriting it to use C++11 would also give that away.* Yes, I'm quite sure browsers can run raw C++ directly from a webpage... =) *> But unless you complete the job, it's cheap talk anyway.* I'm still trying to finish the project I just mentioned. Without Electron, everything has stalled. And a lot of things have been forced onto the backburner due to a broken laptop and no money to replace it. Yours and theirs, - John On 10 January 2018 at 07:38, Ingo Schwarze <schwa...@usta.de> wrote: > Hi John, > > John Gardner wrote on Tue, Jan 09, 2018 at 07:24:25PM +1100: > > > I'm wondering how many people here might react if I suggested porting > > the entire Geoff codebase to JavaScript... > > My comment would be that would be a terrible choice. The Node > package manager is among the least secure package management concepts > on the planet, and the Node concept of modularization is the most > excessive example of atomization syndrome i ever heard of. I hope > that stuff is but a fashionable hype, it certainly lacks the potential > of a sustainable technology. But unless you complete the job, it's > cheap talk anyway. > > Also, basing groff on random, heavy-weight machinery would give away > one of the main assets of groff: That it is completely stand-alone > with minimal dependencies. By the way, rewriting it to use C++11 > would also give that away. > > Note that even though it's hard to maintain and certainly not > recommended for any serious use, an OpenBSD port of Node does exist. > > Yours, > Ingo >