Ethical Javascript Reference

23 replies [Last post]
davidpgil
Offline
Joined: 08/26/2015

Is there some type of reference on writing ethical Javascript?

I found this: https://www.gnu.org/software/librejs/manual/librejs.html

But it seems to just be about a browser plugin.

hack and hack
Offline
Joined: 04/02/2015

Isn't it simply about publishing sources/keep them readable (not minified) ?

Tirifto
Offline
Joined: 02/19/2015

Not really; as far as I know, JavaScript programs are still programs like any other, so in order for them to be free software, they must be properly released under a free license. Usually you can find a comment about the license if you look at the script, which can be free, but could also be proprietary.

hack and hack
Offline
Joined: 04/02/2015

Oh, true, I thought it (kind of), but this has to be explicit. Thanks for the info :)

quantumgravity
Offline
Joined: 04/22/2013

Just properly license your files as free software.

Tirifto
Offline
Joined: 02/19/2015

There is a guide on how to properly license JavaScript scripts here: http://www.gnu.org/software/librejs/free-your-javascript.html

Indeed this has been written to be compatible with the LibreJS add-on, but the methods described there also allow one to easily see what the license is by looking at the script itself, so you might as well follow that rather than other types of formatting (which may still count as free licensing, but probably won't be readable by LibreJS).

Note that LibreJS itself doesn't work very well, even if you follow the guidelines precisely, but the guidelines themselves seem good to me and will be useful if they fix LibreJS or someone decides to write a similar program from scratch.

ADFENO
Offline
Joined: 12/31/2012

Sometimes it can be tricky because the web site developer or owner
*doesn't even understand the HTML specification* he uses for a given
page.

For example, I remember seeing some web site developers saying that
assignments to event handlers (/e.g./: onload, onfocus, onscroll,
onclick, oninput, onplay, onsubmit) aren't considered JavaScript code.

So of course LibreJS will probably block JS similar to this:

# Begin of HTML page
About
# End of HTML page

I said "similar" because this example might actually pass, it depends on
how trivial this script is for LibreJS. "Real-life usage" of event
handlers to do URI mapping are twice as more complex than this one.

Once a web site owner or developer writes the page so as to make use of
such event handlers in the HTML tags, then *the whole HTML page* has to
have a JS license comment in the head of the document, inside the very
first lone script tag.

And of curse, we can't discard the possibility of having bugs on GNU
LibreJS, because software is human creation, and since humans aren't
perfect, neither their creations are.

--
- [[https://libreplanet.org/wiki/User:Adfeno]]
- Palestrante e consultor sobre /software/ livre (não confundir com
gratis).
- "WhatsApp"? Ele não é livre, por isso não uso. Iguais a ele prefiro
GNU Ring, ou Tox. Quer outras formas de contato? Adicione o vCard
que está no endereço acima aos teus contatos.
- Pretende me enviar arquivos .doc, .ppt, .cdr, ou .mp3? OK, eu
aceito, mas não repasso. Entrego apenas em formatos favoráveis ao
/software/ livre. Favor entrar em contato em caso de dúvida.

onpon4
Offline
Joined: 05/30/2012

I don't think any client-side use of JavaScript code for Web pages is currently acceptable due to the way browsers behave. I wrote about that here:

https://onpon4.github.io/other/kill-js/

J.B. Nicholson-Owens
Offline
Joined: 06/09/2014

name at domain wrote:
> I don't think any client-side use of JavaScript code for Web pages is
> currently acceptable due to the way browsers behave. I wrote about that here:
>
> https://onpon4.github.io/other/kill-js/

I'm convinced of the same points -- there is no practical means to leverage
the freedoms of free software for browser-based Javascript (JS) in any
browser, not even free software browsers right now.

I react by not running any JS and avoiding websites that require JS
whenever possible.

This limits what I can do on the web, to be sure, but it also means the
latest insecurities, monitoring systems, and other malware delivered via
websites are less likely to affect my system.

If one is designing a website it's very important that the site:

- host resources (fonts, graphics, movies, documents, etc.) locally, not
refer to resources on other sites whenever possible.

- host everything behind https, and redirect http to the same request via
https.

- use form submission to accept input and HTML+CSS to do markup and style
(CSS, as far as I know, isn't capable of executing anything client-side, so
it's safer to do animations and other stylistic changes in CSS instead of JS).

I'm all for running a browser in a restricted environment so no browser
code can eat up too much CPU time, memory, can't read/write anything
(including browser-maintained state) outside a specific directory I set up
so I can control what the JS has access to. But that's not easy to set up
and that's not the default setup for most OSes.

Such a setup is not what ordinary users using default configurations with
free software browsers get. Right now this is pretty leading-edge stuff
being done with some OSes (perhaps Joanna Rutkowska's Qubes OS, which I
understand to be a GNU/Linux system, can do this?). There is much to be
done addressing real-world problems with this approach, but this approach
has some promising results.

jorgesumle
Offline
Joined: 06/01/2016

There is a nice HTML tag that most web developers miss, the noscript tag. Developers should, at least, try to have the same functionality without using JS.

I would consider ethical the JS if it doesn't execute weird things, don't interact with any third service that could sell my data (e.g. Google), etc.

quantumgravity
Offline
Joined: 04/22/2013

It is impossible to create modern web apps with all of the functionality users nowadays expect without using javascript (or a similar language that would raise the same concerns). Everybody who argues against that is somehow stuck in the nineties.
That said, I think it's completely unnecessary to abandon javascript.
Critics of javascript always argue that it gets executed silently without the user even knowing or agreeing on it. This issue could be solved by the browser. Why not ask for permission everytime a javascript app of siginifcant complecity is about to be executed, offer the possibility to check the license and review the code? There could be also some kind of mechanism that loads the javascript app automatically next time you visit the website, checking if the code changed since then.

onpon4
Offline
Joined: 05/30/2012

> It is impossible to create modern web apps with all of the functionality users nowadays expect without using javascript (or a similar language that would raise the same concerns).

I have seen this claim time and time again, and never once has anyone provided any example of a needed JavaScript functionality for websites. I'm sorry, things like Google Docs don't count. Those shouldn't be embedded onto Web pages. The user should be downloading them, saving them, and running them like any other program on their computer. Even in the case of something like Diaspora, it should be a client program no different in principle from an email client, and any Web-based interface should be minimal and usable without JavaScript. If client-side JavaScript is required for something, don't include it. Put it in the client program.

> Everybody who argues against that is somehow stuck in the nineties.

I never used the Web in the nineties and JavaScript was always, to my knowledge, a part of my experience on the Web. This here is nothing more than an appeal to novelty, anyway. A bad design is a bad design, regardless of how new or old it is.

> This issue could be solved by the browser.

It could be, but it hasn't been. Would you like to do the legwork? My article also outlines what a browser would need to do to make libre JavaScript code on the Web acceptable. A Firefox extension should do the trick.

quantumgravity
Offline
Joined: 04/22/2013

Why don't you program a webbased email frontend like gmail without javascript? Good luck!
Well, you will probably argue that nobody needs those kind of services, since you can check your mail with desktop mail client...
that's true, but people *want* them and they expect this kind of functionality in a webbrowser.
In a CMS they also expect a handy image uploader that can handle drag and drop, maybe allowing you to sort the uploaded images via drag and drop and so on.
Impossible without js.

I'm pretty sure that the only reason you never heard "a single example" is because you always refuse to accept those examples as valid ones.

onpon4
Offline
Joined: 05/30/2012

> Why don't you program a webbased email frontend like gmail without javascript?

Is that supposed to be some kind of joke? Until just around a decade ago, no webmail system required JavaScript. Heck, Gmail still doesn't require JavaScript to use webmail AFAIK, and there are other services with Webmail that doesn't require JavaScript. Riseup.net (my host) is one of them! You might as well challenge someone to write a program that edits text files.

> In a CMS they also expect a handy image uploader that can handle drag and drop, maybe allowing you to sort the uploaded images via drag and drop and so on.

"Drag and drop" is not a job or functionality. It's an aesthetic. Drag-and-drop just for a file upload will usually work, no JavaScript required, because it's already a feature of the Web browser. Why don't you try turning JavaScript off and dragging a file to the "Browse" button for attaching a file on this very website? It works. Here, I've attached something to this post that way.

Drag-and-drop for sorting things? That can be achieved just as easily with standard inputs. Buttons, for example, or to order things more quickly, a bunch of listboxes indicating new desired positions (one next to each item) and a "submit" button. In that case it's not quite as convenient, but still possible.

> I'm pretty sure that the only reason you never heard "a single example" is because you always refuse to accept those examples as valid ones.

No, no example I have been given has ever been one where I couldn't either point to an example of a website that achieves the desired outcome without JavaScript, or conceptualize a very obvious alternative solution to the same problem.

For aesthetic reasons, I can see the point in making use of JavaScript. But aesthetic reasons are no excuse for requiring JavaScript. You can use your pretty JavaScript code for drag-and-drop sorting and put a fallback JS-free version using standard inputs behind a noscript tag. And aesthetic reasons are not a valid reason to suggest that JavaScript embedded into Web pages is a necessary feature.

AttachmentSize
Windows Text Document.txt 4 bytes
quantumgravity
Offline
Joined: 04/22/2013

"Is that supposed to be some kind of joke? Until just around a decade ago, no webmail system required JavaScript. Heck, Gmail still doesn't require JavaScript to use webmail AFAIK, and there are other services with Webmail that doesn't require JavaScript. Riseup.net (my host) is one of them!"

You were not properly reading. I didn't talk about "a webmail system" but about the one like gmail, including functions like live-notifications if an email arrives and even a chat that shows all the contacts that are online.
Impossible without js.

You also forget the whole ajax world. Pagination is considered to be old fashioned and tedious to use; users expect pictures to dynamically load as they scroll down.

Of course you can group all of this stuff as eyecandy. But as a webdesigner you're facing competition and have to deliver eyecandy, because people want it.
And there is no reason not to do it if you release your javascript code under a free license.

onpon4
Offline
Joined: 05/30/2012

> live-notifications if an email arrives

Then yeah, use an email client. It's not appropriate or efficient in the slightest to have a tab constantly open in the background so that it can run a lightweight JavaScript version of an email client.

> even a chat that shows all the contacts that are online.

That's a completely separate job from email. But again, use an XMPP client. Web pages are not supposed to be software. They're supposed to present you with information found on the Web, which neither email nor XMPP are a part of.

> Pagination is considered to be old fashioned and tedious to use; users expect pictures to dynamically load as they scroll down.

By God, nothing has ever annoyed me more than this design trend, and no, I don't think it's done because "users expect" it. Infinite scrolling is the worst idea ever conceptualized by a human. It makes things impossible to find while offering no real advantages over regular pages.

To wit, with infinite scrolling:

1. You have to scroll until you find what you're looking for. You can't just click on the appropriate page link. You can't take shortcuts. All you can do is scroll, scroll, scroll.

2. The loading for each section takes just as long as a static, plain HTML page with the same contents would.

3. On phones and tablets, you don't even have the "end" key, so you really do have to constantly drag, drag, drag, drag your finger over and over again. No shortcuts.

4. After a while, the page becomes so big that it takes forever to return to the top of the page on phones, and no matter where you are, it becomes inordinately difficult to find your way back to a previous point.

5. If you accidentally do anything to leave or refresh the page, you're right back to the beginning. Just spent ten minutes scrolling trying to find and old post, and accidentally clicked on a link? Sorry! You have to do that all over again.

That last point especially.

I have also never met a single person who has said that they like infinite scrolling better than simple pages. It's always "people" or some other vague descriptor like that. Never any specific person, much less for a specific reason.

> have to deliver eyecandy, because people want it.

Again, I have never met anyone who demanded eyecandy on websites. No one cares. If the website looks good and presents the information it's supposed to present, that's all the viewers need.

What I have seen plenty of is users getting pissed because some badly written JavaScript either slows their computer down, or makes a page take forever to load, or ruins the back button, destroys their work, what have you. They never know that JavaScript caused the problem, but it always does.

> And there is no reason not to do it if you release your javascript code under a free license.

To an extent. A lot of JavaScript code is detrimental. But even if your JavaScript code has no such problems, there is reason not to require it. Again, that's for the reasons I outlined here:

https://onpon4.github.io/other/kill-js/

quantumgravity
Offline
Joined: 04/22/2013

"Web pages are not supposed to be software."

I think this is the core of our disagreement, and all further arguments will always end up returning to this one.
While it may be your opinion that "web pages are not supposed to be software", other people have a different opinion, and for very good reasons. First of all: why not?
With web based programming languages, it's a breeze to create a gui for your application, while on the desktop you have to deal with a huge jungle of different libraries like gtk, qt, wxwidgets and so on. All of those require a significant amount of time to get used to their very own way of creating a graphical frontend, showing buttons, forms, tabs, reacting on events - all the stuff that a browser can do easily and in a very intuitive way with html and javascript.
Your app will very likely run on any device, at least if you take care, it can be even used with smartphones and tablets.

Why should I spent time and effort to learn a desktop gui library whose future is uncertain and radius is limited in order to create an app that a lot of people will not bother to download and install?
It's already there: your browser can do all of this stuff. If you want it or not, webpages did become software.
Rather than refusing to accept this development, we should rather face it and try to solve the ethical issues that come with it.
I already proposed a lot of steps how it can be done.

onpon4
Offline
Joined: 05/30/2012

> First of all: why not?

It's inefficient, unnecessarily dangerous, inordinately difficult for the user to control (if not outright impossible), doesn't work without an Internet connection, is inherently spyware, and unnecessary. Essentially, it's all the same problems as SaaSS, with added security risk.

"Why not?" is not a "very good reason" to do something. It's a question.

> With web based programming languages, it's a breeze to create a gui for your application, while on the desktop you have to deal with a huge jungle of different libraries like gtk, qt, wxwidgets and so on.

I have no idea how easy it is to design a GUI in an HTML page, but come on, you can't be serious. You don't need to deal with "a huge jungle" of different libraries. You just need to choose one of them. There are even pretty designer GUIs like Qt Designer that you can use.

> All of those require a significant amount of time to get used to their very own way of creating a graphical frontend, showing buttons, forms, tabs, reacting on events - all the stuff that a browser can do easily and in a very intuitive way with html and javascript.

Are you implying that HTML and JavaScript don't have to be learned?

> Your app will very likely run on any device, at least if you take care, it can be even used with smartphones and tablets.

Yeah, if that device has an Internet connection, and your server serving that Web app is still up, and all HTML features your Web app depends on are supporded and enabled. But you're approaching this from the standpoint of a developer who wants their app to be popular. I'm sorry, but the popularity of your app, as a developer, is egotistical and unimportant. What matters is the liberty of the users.

> Why should I spent time and effort to learn a desktop gui library whose future is uncertain and radius is limited in order to create an app that a lot of people will not bother to download and install?

Are we even on the same page here? I don't have a problem with using JavaScript as a language. I have a problem with embedding JavaScript code, or any software, into Web pages. If all you want to do is use HTML and JavaScript to write a desktop application that runs locally, have at it. Send people the download the exact same way you would any other download. You can even bundle in an HTML and JavaScript interpreter for good measure. This is very different from making users visit a Web page any time they want to use an app. It's not a Web application (it's not accessed through the Web), just a local JavaScript application.

quantumgravity
Offline
Joined: 04/22/2013

"Yeah, if that device has an Internet connection, and your server serving that Web app is still up, and all HTML features your Web app depends on are supporded and enabled. But you're approaching this from the standpoint of a developer who wants their app to be popular"

That's reminding me of somebody who is arguing against the benefits of cars in comparison to horses. "If the car is not running out of gasoline, if it's not broken, if there are big enough streets..."
There is no perfect technology so far, everything is evolving. Servers will become more reliable, internet connection just as normal as electricity.

"Are you implying that HTML and JavaScript don't have to be learned?"

A lot of people already did learn them already. If those people want to make an app, why wouldn't they make use of their knowledge?

"It's inefficient..."
depends on your criteria of "efficiency". For a webdeveloper, using the knowledge he already has in order to achieve the desired result is very efficient. For a user, getting his app without having to install it, just by clicking a link, is very efficient.
Now it is true that performance of interpreted languages like javascript are far inferior to compiled languages like c++.
But for a lot of projects, this doesn't really matter. By the way, python is also not one of the most efficient languages out there...

"...unnecessarily dangerous..."
... if used without care. But security issues are also present in the desktop world...

"...is inherently spyware"
That's just nonsense. The apps I built so far don't spy on anybody, and anybody who reads the source code can verify this.
The only thing I can see is who actually requested the app, equivalent to who downloaded it in the desktop world.
Quite the opposite: while desktop apps come to the user most of the time in binary form, the user has to trust the guy who compiled and packaged the app not to mess with the code before compiling.
You can not check if the source code you see is really the source code you get. It's different with javascript apps: open the source code, and there you go, you can verify it right away.

" I'm sorry, but the popularity of your app, as a developer, is egotistical and unimportant. What matters is the liberty of the users."

You talk as if you have to decide for one single criteria. You can strive for popularity and still care about the liberty of the users, you know.
You're being overly dramatic and emotional here.

onpon4
Offline
Joined: 05/30/2012

Why did you say nothing to the last paragraph in my post?

> A lot of people already did learn them already. If those people want to make an app, why wouldn't they make use of their knowledge?

Maybe they would. Seriously, how could this possibly be your answer when I already clarified my position in the last paragraph of my previous post, which you didn't respond to? I'm not against JavaScript as a language. I'm against the use of JavaScript on the Web. If you already know JavaScript and want to make an application as a local JavaScript application, that's fine. It's when such a program is served by a server as a Web application that there's a problem.

> Now it is true that performance of interpreted languages

That's not what I meant by "inefficient". I meant that the system of JavaScript on the Web is inefficient. You can't just download the program once and execute it whenever you like; every time, you have to open a Web browser and navigate to the website. It's a waste of bandwidth.

> ... if used without care. But security issues are also present in the desktop world...

The system of JavaScript on the Web is what I was saying is unnecessarily dangerous. The system being one that just takes programs offered by arbitrary sources and runs them without question. This is not the same thing as normal security vulnerabilities. It's rather a security breach waiting to happen. This has nothing whatsoever to do with how you as a developer program things in JavaScript.

> That's just nonsense. The apps I built so far don't spy on anybody, and anybody who reads the source code can verify this.

No, they're inherently spyware because every time they're used, your server is contacted. As in, no matter how friendly the code is, it's set up in such a way that you can track when they are running the program.

quantumgravity
Offline
Joined: 04/22/2013

"Why did you say nothing to the last paragraph in my post?"

Because if you understood the rest of my points, your proposal in the last paragraph becomes obsolete. Using javascript locally with some kind of html interpreter?
Why in the world would you avoid the webbrowser like that? You are aware that you can store many javascript apps onto your pc and then execute it without internet connection as many times as you want? Very often the browser even does it for you, storing the code in his cache ( a fact that you ignored through out your whole post).
Of course many of those javascript apps are dependent on a working internet connection, but so are many desktop apps.
Others are not. You can right now search for a simple calculator app online, go to "save page" and then pull the ethernet cable.

Well, I agree that it would be handy to package bigger web apps as some sort of browser add on, so that it really stays in the browser and doesn't have to be downloaded over and over again.
By the way, I never claimed that the situation with web based apps should stay the way it is now, but I guess I start to repeat myself.

"No, they're inherently spyware because every time they're used, your server is contacted. As in, no matter how friendly the code is, it's set up in such a way that you can track when they are running the program."
Again, not true.
If the browser doesn't store the app in his cache, then it might be true, but it's a matter of configuration. And if the app depends on a server connection by its nature, then this would also hold for an equivalent desktop app.

onpon4
Offline
Joined: 05/30/2012

> Why in the world would you avoid the webbrowser like that?

A Web browser is an HTML and JavaScript interpreter. I didn't say it had to be an interpreter that isn't a Web browser. Only that it shouldn't be on the Web, i.e. used by accessing it on the Web.

> You are aware that you can store many javascript apps onto your pc and then execute it without internet connection as many times as you want?

Yes, exactly! If you are using HTML and JavaScript to make applications, that's what I advocate.

> Very often the browser even does it for you, storing the code in his cache ( a fact that you ignored through out your whole post).

I ignored that fact because it's irrelevant. The browser caches Web pages, and caching JavaScript code is a part of that. It doesn't cache them forever, only for a short time to avoid wasting bandwidth unnecessarily. This is entirely unrelated to what we are talking about.

> Of course many of those javascript apps are dependent on a working internet connection, but so are many desktop apps.

There's a big difference between a client you install connecting to a server and the server installing the client for you.

> Others are not. You can right now search for a simple calculator app online, go to "save page" and then pull the ethernet cable.

And that's fine. As long as this calculator program is libre, there's nothing wrong with it.

So let's get back to the original point: this is a separate thing from Websites. My points were thus:

1. Websites do not need JavaScript.

2. JavaScript applications do need JavaScript, by definition. However, they should not be made into "Web apps". They should be distributed the same way as any program. Therefore, the need for JavaScript applications to have JavaScript is not a valid justification for the use of JavaScript on the Web.

Notice that none of this has to do with the merits of JavaScript as a language for building applications. It's all about its use on the Web.

jorgesumle
Offline
Joined: 06/01/2016

The other day a was programming a survey. In the first block of questions, you would have to put your personal information (age, number of sons, stuff like that). Then there is a radio button you must say if you are student or not. If you check yes, the questions of the student appear; else questions of a worker. That works with JavaScript, concretely jQuery, and it's LibreJS compatible. But I, as a competent web developer, have to make sure the form works well for people with JavaScript disabled, so I use the noscript tag, and, only for people who doesn't use JS, show all questions and change the name of the question by writting (answer if you're a student or answer only if you're a worker). But anyway, I could have used another solution with PHP.

The web would work very nicely without JS. The websites would load more quickly and it would be more difficult to track users.

davidpgil
Offline
Joined: 08/26/2015

Out of all the responses, I like your the most. A good solution for a problem made too complex.

----- Original Message -----
From: name at domain
To: "trisquel-users" <name at domain>
Sent: Saturday, May 27, 2017 10:53:31 AM
Subject: Re: [Trisquel-users] Ethical Javascript Reference

The other day a was making a survey. In the first block of question, you
would have to put your personal information (age, number of sons, staff like
that). Then there is a radio button you must check if you are student or not.
If you check yes, the questions of the student appear; else questions of a
worker. That works with JavaScript, concretely jQuery, and it's LibreJS
compatible. But I, as a competent web developer, have to make sure the form
works well for people with JavaScript disabled, so I use the tag, and, only
for people who doesn't use JS, show all questions and change the name of the
question by writting (answer if you're a student or answer only if you're a
worker). But anyway, I could have used another solution with PHP.

The web would work very nicely without JS. The websites would load more
quickly and it would be more difficult to track users.