Re: [Help-librejs] Avoiding the javascript Trap server-side

[Dmitry Alexandrov]

> Thank you for the elaborate response Dmitry!

Your are welcome.

But, I see, you preferred to move our dialogue off-list.  As I found nothing 
private in it, that was probably for the reason that it went somewhat off-topic 
there.  However, I would say that this topic important enough to be public, and 
hope that LibreJS developers and other subscribers will excuse us.  If they 
know any better list to discuss that (I, alas, do not), I would appreciate that 
info.

For now, I took a liberty to move it back to <address@hidden> by resending your 
message and continuing there.

>> What most of them still do (despite the great progress in LibreJS I
>> noticed from a user point of view) is not relying on some automatic
>> analysers, but simply stick with ‘do not run’ as a default policy,
>> possibly making some unavoidable exceptions manually.
>
> I understand, that a lot of people will just disable javascript,
> seeing as libreJS can sometimes lead to firefox not responding at all,
> if a website loads too much stuff (trisquel.info is a good
> example).

And others do not use Firefox at all, for instance.

> The thing is, I want to blog about free software, the importance of
> free licenses and in general record my user experience trying out
> different solutions (like using Diaspora as a replacement fro
> Facebook, or running free software only for all daily tasks, or
> video/voice chat with people on Windows, something along these
> lines).

Sounds nice.  I would definitely like to see it, when it’s published (in the 
case it’s in English or Russian).

> It would be self-contradictory to use javascript that is not free
> software.

I by no means was trying to persuade you to serve nonfree programs from your 
webpage.  (Not to say, that unrecognisable by LibreJS is not equal to nonfree).

Not pushing any programs at all would not contradict anything — that is the 
point, I was trying to emphasize.

>> So if the website management system, which you’d set your choose on,
>> will not fall back to a pure data interface in a sense of falling to
>> nowhere instead \[https://kolab.org\], I am afraid that it will be
>> perceived as unusable, with no regards to whether programs it relies
>> on are free or not. Many will just remain unaware of that fact.
>
> I can only second that. A website should be able to fall back to a
> usable interface, if the client chooses to not run javascript. This is
> what I was also focusing on.

Thanks for shattering my wrongful misgivings.  :-)

> Apparently there is an almost perfect solution out there. There are
> CMS systems that do not rely on javascript being run at the
> client. Like jekyll for example.

‘CMS’ and Jekyll...  Hmm, see few paragraphs below.

> It looks amazing right now, almost done implementing all the
> features I'd like to have for the beginning. However, I can still
> implement some javascript to enhance the experience, just little fun
> animations here and there,

I was under impression that after CSS3 (and 4) there no much need in 
client-side javascripts to implement some fun animations.

> nothing that is necessary for using and reading the website. There
> will be a notification on the site somewhere, that it supports
> libreJS and all the script is free, so the user can enable it, if so
> desired.

In such case, you might also eventually find that all these scripts are 
detected as ‘trivial’ by LibreJS and therefore allowed.  That is not a excuse 
to serve nonfree pieces of software, of course.  Just no special labels 
required.

>> Falling to a screen that honestly explains that ‘management system’
>> developers were not able to make a simple website, that does not
>> even allow you to post anything, without relying on auxiliary
>> program on client \[https://code.gov\]; or, all the more, thrusting
>> a visitor to a nag page, that advertises to install a nonfree
>> browser, not even bothering to preserve an original location
>> \[https://vk.com\] — such things hardly help either.
>
> That's not what I would consider a good practice either.
>
>> So, if providing a standard way, that does not depends on any ad-hoc
>> programs, to interact with all features your website, is indeed
>> unfeasible, then, please, consider providing it to some extent, at
>> the very least for reading the pages.
>
> The good news is, it is absolutely feasible. I can have all the
> convenience of a CMS (using pre-made themes that are easy to
> customize, not editing textfiles over ssh on the server in order to
> post an update

Well, AFAIK, Git should work over WebDAV also.  And nothing, of course, can 
prevent you from treating a website hosted along with its VC repo as a mere 
bunch of files and use any protocol your hoster allows, even FTP, from any 
place.

> but rather using a web interface)

There are free web interfaces to VC systems, of course.  If not most of them, 
then some supports editing files in browser.

On a first glance, there is no much point in making it world-readable, and 
therefore neither in making its free client-side software LibreJS-compatible.  
(You and, possibly, a limited number of your co-authors, would not find any 
difficulties to simply whitelist it, I suppose.)

But let me assure you, that having a proper (yet read-only) access to a VC in 
addition to usual final HTMLs, might be pretty useful for a visitor in some 
cases.  Popularization of such approach is a rare thing we maybe should thank 
GitHub with its ‘Pages’.  (While there was no any innovation, of course, the 
same gnu.org has been doing that for ages.)

So, if you were going to bother with LibreJS labels even for it, then, for 
instance, Kalithea [https://kallithea-scm.org], while not providing them out of 
a box, might look like an easy target: its javascript, as far as I see, are 
served in sources (except jQuery), static and with human-readable labels 
already.

> and at the same time the whole website appears to be (on the client
> side) only static .html files.

So there will be no any posting (commenting, etc) facilities for a random 
visitor?  Then you really do not need any ‘management system’ at all.  Some 
system for building HTML (plus CSS, plus RSS/Atom, plus whatever) from sources 
(in Texinfo, Org, some simplified HTML, whatever else), that is so called 
‘static site generator’, would be enough.

> Jekyll is a tool for generating static webpages from a bunch of text
> files that use different markup languages.
>
> Jekyll supports different plugins, themes and filters, which in
> effect allows for static sidebars with navigation elements,
> multi-lingual websites, all the basic positive things about a CMS
> without relying on javascript at all.

Ah, yes, this is exactly a ‘static website generator’ not a ‘website content 
management system’ in a usual sense of that phrase, which implies some 
on-the-fly server-side generation (that is ‘dynamism’).

Indeed, Dr. Stallman was quite right by awarding that word combination with his 
“prize for vacuity”:

| The term “content management” takes the prize for vacuity.
| “Content” means “some sort of information,” and “management” in this
| context means “doing something with it.”  So a “content management
| system” is a system for doing something to some sort of information.
| Nearly all programs fit that description.
— https://www.gnu.org/philosophy/words-to-avoid.en.html#Content

;-)

> So, in such an environment, javascript can be used to enhance the
> experience, add some animation to the menus for example,

Definitely should be possible without Javascript.

> just fun little things that are not really necessary for the basic
> interaction with the website.