groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [groff] A typo on fsf groff wiki page, and question about releasing


From: John Gardner
Subject: Re: [groff] A typo on fsf groff wiki page, and question about releasing
Date: Wed, 10 Jan 2018 16:06:24 +1100

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 <address@hidden> 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
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]