How bad is libre Javascript for a website like this forum?

[Julius]

This topic was split off from here:
https://forum.freegamedev.net/viewtopic ... 039#p78968

Nonononono

That's the worst forum I've ever seen. Seriously. Turn off JavaScript (which I do), and it's 100% useless. Not broken, useless. All you get without JavaScript is a list of topics. No login, no posting, nothing. Even the absolute worst proprietary forum software has at least partial no-JavaScript support.

Yes it is a pure Javascript single page website. That is one of the reasons why I wanted to get feedback first and I partially understand where you are coming from. However, I have to disagree that it is useless and worst than a proprietary forum software. This forum software (Flarum) is 100% FLOSS, including the Javascript. As bad as random proprietary javascript can be on the web, the programming language itself is not inherently bad. Usually your way of blocking random javascript should also allow a whitelist of permissible FLOSS javascript sources. So why would you not simply whitelist community.freegamedev.net and use the forum? I am honestly curious, as that would seem to me the way to handle such issues, no?

[onpon4]

This forum software (Flarum) is 100% FLOSS, including the Javascript. As bad as random proprietary javascript can be on the web, the programming language itself is not inherently bad. Usually your way of blocking random javascript should also allow a whitelist of permissible FLOSS javascript sources. So why would you not simply whitelist community.freegamedev.net and use the forum? I am honestly curious, as that would seem to me the way to handle such issues, no?

No, for the reasons outlined in my article I linked to. In fact, I'm probably going to modify that because I don't support the idea of trying to "fix" JavaScript anymore; the very idea of client-side ad-hoc scripting is flawed and I don't support it.

Condensed version: Even if the script is 100% libre, I still can't control it. Every time I load the page, I get a new copy which may or may not be the same as the last one I got, so I can't even audit it. So being libre software is absolutely useless in this case. Whitelisting your JavaScript means I'm subjecting myself to that system. I have to just trust you. It's exactly the same sort of unfair deal that proprietary software offers. Worse, actually, because at least with proprietary software I can make sure I always have the same version.

Plus there's the other stuff people tend to mention. For example:

* XSS
* The simple fact that JavaScript always performs more poorly than HTML and CSS, wasting energy in the process
* Accessibility support
* Annoying "interactive" behaviors
* Screwing around with browser behavior (like the back button)
* Ridiculous hipster "solutions" to non-problems (like "infinite scrolling", possibly the worst design fad of the decade)

Put everything together. I don't care if it's libre or not. I don't want JavaScript use on the Web, period.

As to the point that "the programming language itself is not inherently bad", while I think JavaScript is the ugliest and most unusable programming language I've ever laid my eyes on, I agree; there's nothing inherently bad with its use, but that's only in the proper context. The only acceptable contexts for JavaScript in my book are things like desktop environments, browser extensions, and others that users install intentionally and permanently (until they decide to remove it of their own volition, of course). JavaScript on the Web, or really, any client-side scripting on the Web regardless of language, is what I don't tolerate.

[Julius]

Even if the script is 100% libre, I still can't control it. Every time I load the page, I get a new copy which may or may not be the same as the last one I got, so I can't even audit it. So being libre software is absolutely useless in this case. Whitelisting your JavaScript means I'm subjecting myself to that system. I have to just trust you. It's exactly the same sort of unfair deal that proprietary software offers. Worse, actually, because at least with proprietary software I can make sure I always have the same version.

Ok, I should have really read the link you posted

But regarding the quote above: While theoretically true, the exact same thing can be said about any package repository or other updating mechanism. It is possible to audit the Javascript code (download it in a sandbox etc. and you browser will cache the javascript so you know when it is the same version), but it is just not very realistic to do it for every update/download. In fact there is probably a lot of software running on your PC right now that you have not audited yourself, especially not the exact version that came with the latest system update...
So just as you are white-listing certain software update repositories because you trust them, the same can be done with websites delivering javascript. At some point there is always a certain level of trust necessary. And up to date browsers do a relatively good job in sandboxing the javascript code as well.

Edit: "I don't have to update the software on my PC"... yes* but you also don't have to visit a website; which you usually do to get the latest changes... if you don't want to be exposed to a new version at all you might also not want to get a new version of the HTML code, which is surely more limited than Javascript but fundamentally not that different and can also expose you to risks unless you audit it each time. Edit2: what I mean is that a website is inherently an *updated* piece of software as it's very function of content delivery requires it to be constantly "updated".

*unless you run a certain proprietary OS

[onpon4]

But regarding the quote above: While theoretically true, the exact same thing can be said about any package repository or other updating mechanism.

Untrue. You can choose when and whether to upgrade, and when you do, you know that it happened. There's no way to prevent a JavaScript update on a website. Whether you know about it or not, whether you audit it or not, you're stuck with it.

In fact there is probably a lot of software running on your PC right now that you have not audited yourself, especially not the exact version that came with the latest system update...

Right, but the point is that I could audit it if I wanted to, and I could refuse to update if I wanted to. Whether or not I actually do either of these things is my decision.

With client-side, dynamically installed JavaScript, I don't have that choice. Perhaps there might be a way to audit it, but refuse an upgrade? Nope.

"I don't have to update the software on my PC"... yes* but you also don't have to visit a website

That's rather like saying, "If you don't like the Windows auto-upgrade, you don't have to use a computer."

if you don't want to be exposed to a new version at all you might also not want to get a new version of the HTML code, which is surely more limited than Javascript but fundamentally not that different and can also expose you to risks unless you audit it each time.

HTML is not software. It's marked-up text. Any vulnerabilities related to HTML would be browser vulnerabilities (as in, a bug in the Web browser or rendering engine). That's not the same thing.

Vulnerabilities is very much secondary to the main point: I can't feasibly control the activity of these scripts, on my own computer. Since HTML is just text, this doesn't logically apply to HTML. It also doesn't logically apply to CSS, which is just a list of properties indicating what the page should look like. Vulnerabilities or not, the actual software in question when it comes to HTML and CSS is my Web browser, which (if it's libre, which in my case of course it is) I have and can reasonably exercise the four freedoms with.

[Lyberta]

Deleted.

[Julius]

But regarding the quote above: While theoretically true, the exact same thing can be said about any package repository or other updating mechanism.

Untrue. You can choose when and whether to upgrade, and when you do, you know that it happened. There's no way to prevent a JavaScript update on a website.

In fact there is probably a lot of software running on your PC right now that you have not audited yourself, especially not the exact version that came with the latest system update...

Right, but the point is that I could audit it if I wanted to, and I could refuse to update if I wanted to. Whether or not I actually do either of these things is my decision.

With client-side, dynamically installed JavaScript, I don't have that choice. Perhaps there might be a way to audit it, but refuse an upgrade? Nope.

"I don't have to update the software on my PC"... yes* but you also don't have to visit a website

That's rather like saying, "If you don't like the Windows auto-upgrade, you don't have to use a computer."

Yes there is a way to run websites with javascript without updating the javascript, it's called offline-mode and browser cache. However websites can not be really compared to desktop software, and the desktop software that is somewhat comparable usually also requires updates to stay usable. My main point was however, that websites by their very nature are transient and you visit them because you want to get the updates. The line between text content, media files and code (both HTML and Javascript) is rather blurry, especially with interactive websites. Think about OpenStreetMap for example.

if you don't want to be exposed to a new version at all you might also not want to get a new version of the HTML code, which is surely more limited than Javascript but fundamentally not that different and can also expose you to risks unless you audit it each time.

HTML is not software. It's marked-up text. Any vulnerabilities related to HTML would be browser vulnerabilities (as in, a bug in the Web browser or rendering engine). That's not the same thing.

Vulnerabilities is very much secondary to the main point: I can't feasibly control the activity of these scripts, on my own computer. Since HTML is just text, this doesn't logically apply to HTML. It also doesn't logically apply to CSS, which is just a list of properties indicating what the page should look like. Vulnerabilities or not, the actual software in question when it comes to HTML and CSS is my Web browser, which (if it's libre, which in my case of course it is) I have and can reasonably exercise the four freedoms with.

HTML/CSS has a lower vulnerability surface due to being much simpler, but it can still easily load risky content from third party servers and all kind of other stuff that is only visible when auditing the code.
Javascript is also just text that gets interpreted by your browser. Most of the real risks from Javascript are also related to browser-code vulnerabilities (breaking the sandbox etc.), but of course there is a higher vulnerability surface with running unkown complex javascript code from non-trust worthy sources compared to doing the same with simple HTML/CSS code.

[onpon4]

However websites can not be really compared to desktop software

Websites can't, but JavaScript programs can. That's the point: these JavaScript programs shouldn't be embedded into a website. A website should just be data, not a software package.

The line between text content, media files and code (both HTML and Javascript) is rather blurry, especially with interactive websites. Think about OpenStreetMap for example.

I'm not sure what point you're trying to make, but I disagree on the basic facts here: no, the line between text content, media files, and code is not blurry. In a website that uses PHP, HTML, CSS, and JavaScript, the only software is PHP and JavaScript. Of that, the only components I'm concerned about are those that are executed client-side; server-side PHP, JavaScript, Python, Ruby, etc code is no problem. Marked up text is no problem. Style sheets (which are just lists of value definitions) are no problem.

I'm not sure what OpenStreetMap is supposed to prove. The OpenStreetMap website is fundamentally designed in a flawed way. The JavaScript interface is really just an OSM client, but an OSM client should be installed by the user, separate from the browser (e.g. GNOME Maps). If the OSM team wants to offer a Web interface, the proper way to do that is with server-side code, and this is very possible. Google Maps used to work just fine without client-side code back in the day.

HTML/CSS has a lower vulnerability surface due to being much simpler, but it can still easily load risky content from third party servers and all kind of other stuff that is only visible when auditing the code.

But it's not software. That distinction matters.

Javascript is also just text that gets interpreted by your browser.

Text that gets executed by your browser, via a turing-complete programming language.

Most of the real risks from Javascript are also related to browser-code vulnerabilities (breaking the sandbox etc.)

HTML doesn't need to be sandboxed, and neither does CSS.

And on the software side, you never hear of anyone sandboxing their C, Python, PHP, or Ruby code. You also don't sandbox the JavaScript code coming from extensions (which you installed on purpose). That's because when software is used and distributed properly, a sandbox isn't a feature; it's a hindrance. The fact that intentionally hindering JavaScript programs is routinely seen as a good thing, and failure to do so 100% (which will never happen, by the way) is seen as a bug, should speak to the fact that there's something inherently wrong with this approach of just taking random software and executing it in our computers, because a website says we should.

This also applies to office documents, by the way. Remember how malware authors used to take advantage of the MS Word "macros" feature to trick you into executing harmful code? Well, now they do that with JavaScript. It's the exact same principle: when you design a non-software document in such a way that it causes software to be executed, that's a fundamental security flaw. Good security never depends on telling users not to read something.

More importantly, though, it's a fundamental attack on users' liberty.

[Julius]

I was about to type up a point by point response on where I disagree, but IMHO this doesn't lead anywhere as we are mixing up a lot of very different issues and concepts.

So lets take a step back and look at it this way:

1. We agree that running random javascript from untrusted websites is a bad idea, and sandboxing it is only a stop-gap solution

2. You would prefer the browser to be incapable of executing script that is dynamically loaded from websites, and would prefer users to install apps instead
Side note: the usual channel for people to install apps is even more insecure and the risk from malicious apps is even higher than sandboxed javascript

3. I prefer that the user can make a conscious choice to trust javascript code and website, as ultimately there is no trust-free computing and transient web-applications are much better with client-side code
Side note: As you say yourself, your computer runs a lot of software you only trust, so maybe you just dislike that you are reminded of this fact if you have to white-list a website?

4. I really dislike having to download an separate app for every (semi-trusted) micro-service on the web that I only very rarely use And I would much rather point my grand-ma to a trusted website than to tell her to download and install an app

However none of the above is a "fundamental attack on users' liberty". There is zero functional difference between using your browser to navigate to a page, download an trusted FOSS app and executing it and a user navigating to a trusted website running FOSS code, downloading the javascript code after whitelisting it and then using that website (=executing the code).

Last side note: All-server-side websites running on pure php/ruby/python etc. are potentially more of an threat to liberty as their code/functionality is even less audit-able and out of the control of the user. Edit: lets take a theoretical online mapping app: is it more Free to have the web-server pre-render the tiles as lossy .jpg or it sending the source vector files which are then assembled by your browser running FOSS javascript code? In the latter case you can even modify the FOSS javascript code to change the look of the maps etc.

P.S.: Server side code is sand-boxed all the time, that is what Docker and VMs are doing. I am not a big fan of sandboxes as a "solution" to security/trust issues, but there are everywhere... on mobile every app is sandboxed as well

[Lyberta]

Deleted.

[Julius]

I'd say forcing users to execute JavaScript is a bad idea. Forum software shouldn't need to force users to run JS.

Yeah, fall-backs could be better with Flarum, also for accessibility reasons. But at some point there is also the fact that certain functionality does not work very well (or at all) on such fall-backs.

[onpon4]

1. We agree that running random javascript from untrusted websites is a bad idea, and sandboxing it is only a stop-gap solution

Correct, with one correction: my position is that automatically running any software from any website (or other document) is a bad idea.

2. You would prefer the browser to be incapable of executing script that is dynamically loaded from websites, and would prefer users to install apps instead

Not quite. If you're talking about so-called "Web apps", then yes, that would be accurate. But as far as websites go, where the purpose is to disseminate information, I think the best method is one based purely on text, markup, and styling. The only software involved should be the Web browser. Everything else should just be non-executable data.

3. I prefer that the user can make a conscious choice to trust javascript code and website, as ultimately there is no trust-free computing and transient web-applications are much better with client-side code

I don't understand what you mean by this.

Side note: As you say yourself, your computer runs a lot of software you only trust, so maybe you just dislike that you are reminded of this fact if you have to white-list a website?

No. As I said already, the reason I'm against automatic execution of arbitrary code that the user did not intentionally choose to install is because it makes it infeasible for the user to exercise the four freedoms.

4. I really dislike having to download an separate app for every (semi-trusted) micro-service on the web that I only very rarely use And I would much rather point my grand-ma to a trusted website than to tell her to download and install an app

I would much rather prefer an ecosystem where not every source of information in the world has its own dedicated client that works only on that one information source.

We're talking about forum software here, and we're posting on a forum right now; I'm not using JavaScript. So you and I can both plainly see that forums are not some complicated problem that needs a dedicated client. In fact HTML was already advanced enough for it decades ago, long before more recent extensions to HTML and CSS that made even more tasks possible in standard ways. All you need on the client side is the ability to send text over to the server, and simple hyperlinks, both of which are parts of the HTML standard.

Since you keep bringing "apps" up, that suggests to me that this recent ecosystem of making dedicated proprietary programs for accessing data on only a single server is something you take for granted. I don't. Just as I reject JavaScript, I also reject services that demand I download an unnecessary app. There are some cases where dedicated clients make sense; email, IRC, XMPP... but the vast majority of forced client-side JavaScript use is a result of Web developers' incompetence with the HTML and CSS standards. Flarum is in the latter category. There is no excuse for something as simple as displaying a login link or sending text to a server requiring JavaScript.

Just in case you think the number of websites I'm talking about, which don't need JavaScript but make it a requirement anyway, is small, it's not. Just a few examples:

* YouTube, rather than all of its JavaScript nonsense, could use plain old HTML5 video tags, with hyperlinks for lower video qualities if they want that feature. Here's a real-life example of an almost fully featured YouTube redirect without JavaScript requirements: https://invidio.us
* Disqus, rather than its JavaScript nonsense, could simply use an iframe, hyperlinks to pages, and HTML form data.
* BitBucket, rather than its JavaScript nonsense, could do what GitHub does. The same goes for GitLab and SourceForge, by the way. GitHub is an almost perfect example of how to do a modern Git host right without requiring JavaScript (despite what the FSF claims, GitHub has the best no-JS support of any Git host I've seen outside of Savannah, which is why I continue to use it).
* Walmart.com,[1] rather than its JavaScript nonsense, could do what Amazon was doing for years. Amazon used to not only not require JavaScript, it didn't even require cookies. Of course, though, Amazon has very much dropped the ball lately.
* Diaspora, rather than its JavaScript nonsense, could do what forum software has been doing for decades. Pages, POST, hyperlinks, that sort of thing.
* Wix. My God, Wix. Every website hosted on Wix is f***ed up with JavaScript nonsense, no matter how simple. I've designed at least half a dozen websites better than any Wix website.
* Lest we forget, Flarum, rather than its JavaScript nonsense, could do what all forum software has been doing for decades, including the software that currently runs this forum.

[1] Just a note: I'm a worker at Walmart, so I actually have a bit of a conflict of interest here. But when push comes to shove, I have to admit that Walmart.com is one of those bad website designs I'm talking about.

Last side note: All-server-side websites running on pure php/ruby/python etc. are potentially more of an threat to liberty as their code/functionality is even less audit-able and out of the control of the user.

No, because in that case, the client is not the user of the software. The owner of the server is the user. It's the same situation as the software in an ATM; the bank owns the ATM, not me, so it's their right to control what software runs in it, not mine. The exact same logic applies to Web servers.

Edit: lets take a theoretical online mapping app: is it more Free to have the web-server pre-render the tiles as lossy .jpg or it sending the source vector files which are then assembled by your browser running FOSS javascript code? In the latter case you can even modify the FOSS javascript code to change the look of the maps etc.

I would say that the former would be a case of "service as a software substitute" (SaaSS), and in the latter case, my nominal ability to modify the code is impractical. So my answer to your question is: neither. The proper solution is that this shouldn't be a Web service. This is one of those occasional things I was talking about where it should be a dedicated application, in this case something like GNOME Maps.

But at some point there is also the fact that certain functionality does not work very well (or at all) on such fall-backs.

Such as?

No, really, I want an answer to that. I have debated this topic before, and never once has anyone provided a single example of something that websites need to do which actually requires JavaScript. Perhaps you can be the first.

[Julius]

2. You would prefer the browser to be incapable of executing script that is dynamically loaded from websites, and would prefer users to install apps instead

Not quite. If you're talking about so-called "Web apps", then yes, that would be accurate. But as far as websites go, where the purpose is to disseminate information, I think the best method is one based purely on text, markup, and styling. The only software involved should be the Web browser. Everything else should just be non-executable data.

I disagree, websites these days are primary transient applications (meaning one time use apps that change all the time and where content, media and code is at most a blurry distinction, "web2.0"), and going back to the old days of text/information only websites ("web.1.0") would be a huge step backwards. The "Web 1.5" step in between, i.e. static/server-side websites with downloadable apps, was also much worse in regards to user liberty and security.

3. I prefer that the user can make a conscious choice to trust javascript code and website, as ultimately there is no trust-free computing and transient web-applications are much better with client-side code

I don't understand what you mean by this.

Side note: As you say yourself, your computer runs a lot of software you only trust, so maybe you just dislike that you are reminded of this fact if you have to white-list a website?

No. As I said already, the reason I'm against automatic execution of arbitrary code that the user did not intentionally choose to install is because it makes it infeasible for the user to exercise the four freedoms.

4. I really dislike having to download an separate app for every (semi-trusted) micro-service on the web that I only very rarely use And I would much rather point my grand-ma to a trusted website than to tell her to download and install an app

I would much rather prefer an ecosystem where not every source of information in the world has its own dedicated client that works only on that one information source.

Using a white-list is exactly the intentional choice to install software from a trusted source that you want, no? I agree that the javascript in the browser should work similar to Adobe Flash these days, i.e. that it is opt-in rather than opt-out, but all four freedoms are preserved just fine in my opinion.
I also find it very contradicting that you don't want a separate client for every information source, yet find javascript web-apps in the browser bad even though they were exactly created as a compromise solution to that very problem. Of course you can argue that not every micro-service really also needs a client side web-app, but often those web-apps are more libre, secure and also more user-friendly than the alternative you seem to propose. A forum is a bit of a grey area in that case as it can indeed work without javascript. But advanced functionality & usability is pretty poor (especially on mobile browsers) compared those utilizing javascript and more often than not people then resort to closed-source insecure mobile clients to view the forums, which are definitely worse than running whitelisted FOSS javascript in the browser.

Last side note: All-server-side websites running on pure php/ruby/python etc. are potentially more of an threat to liberty as their code/functionality is even less audit-able and out of the control of the user.

No, because in that case, the client is not the user of the software. The owner of the server is the user. It's the same situation as the software in an ATM; the bank owns the ATM, not me, so it's their right to control what software runs in it, not mine. The exact same logic applies to Web servers.

But the end result is that the user is using a service that is much less libre than if it was mostly implemented in client side javascript. An ATM is much less libre than if a FOSS javascript web-app or stand-alone app would be using a banking API.

Edit: lets take a theoretical online mapping app: is it more Free to have the web-server pre-render the tiles as lossy .jpg or it sending the source vector files which are then assembled by your browser running FOSS javascript code? In the latter case you can even modify the FOSS javascript code to change the look of the maps etc.

I would say that the former would be a case of "service as a software substitute" (SaaSS), and in the latter case, my nominal ability to modify the code is impractical. So my answer to your question is: neither. The proper solution is that this shouldn't be a Web service. This is one of those occasional things I was talking about where it should be a dedicated application, in this case something like GNOME Maps.

But at some point there is also the fact that certain functionality does not work very well (or at all) on such fall-backs.

Such as?

No, really, I want an answer to that. I have debated this topic before, and never once has anyone provided a single example of something that websites need to do which actually requires JavaScript. Perhaps you can be the first.

Online maps are such an example, or interactive public transport schedule query systems. Of course those could be implemented as dedicated applications or with much less functionality and software freedoms as server-side only software. But neither of these options is more libre, secure or userfriendly. I am really not sure why you think a dedicated app is better than one running in the browser? In nearly all cases it is less secure: it has much larger attack surface, usually can intrude in your system much deeper and the compiled code is much more opaque to the user and more difficult to audit in praxis as well. In addition browser code tends to be highly scrutinized by security experts... some random app than never gets updated? Not so much. And you also don't really win anything in regards to "trust" issues as you still have to trust the source of the software itself and the update mechanism it usually utilizes.

So to summarize: You seem to want more "Web1.0", which I partially understand but in the end we have to disagree as there are many useful transient web-apps. And all alternatives to pure "Web1.0" you seem to propose are less libre and less secure than running libre javascript from trusted white-listed sources in your FOSS web-browser.

[charlie]

Condensed version: Even if the script is 100% libre, I still can't control it.

So this is you misunderstanding the difference between libre and ethical. Libre, free and open source software is not about you being in control of the end product. It is about access to, freedom to use and modify and distribute the source code and the software you create from that source code. Just because some JS loads when you visit a website does not infringe upon those rights.

Now, if you bring up ethics, you might have a point but then again I might be inclined to disagree. I don't think there's anything intrinsically ethically wrong about having some script that runs clientside on websites, even though that can be abused by nefarious websites. It's like saying screesavers are unethical because some people distribute viruses with screensavers.

[Huitsi]

Expecting you to run a specific program to fetch some information doesn’t sound like a freedom issue to me, unless said program is proprietary. I do however think that it is bad design for a website to expect JS or even CSS. (Ideally HTML should be human-readable just as plain text.) Using CSS and JS to enhance the site is acceptable, but they shouldn’t be required.

I also consider “webapps” that have no point without interactivity to be different from “web pages” with static content and maybe a form. I don’t think “webapps” can or should be killed since they’re just too useful as universal applications. I think we have a much better fighting chance trying to push back the requirement of scripting on pages that could just be static (though things aren’t looking too great here either).

Forums, as has already been mentioned, can be done just as static website, so an app shouldn’t be used instead. And considering the community that is being hosted, noscripters should definitely be taken into account.

Posted using lynx just because I could.

[onpon4]

websites these days are primary transient applications (meaning one time use apps that change all the time and where content, media and code is at most a blurry distinction, "web2.0"), and going back to the old days of text/information only websites ("web.1.0") would be a huge step backwards.

"Web 2.0" is just a nonsense buzzword that serves as an excuse for bad website design.

Just to note, most websites continue to work without JavaScript. It's only a small handful of websites, some of them quite popular, that insist on this nonsense.

Using a white-list is exactly the intentional choice to install software from a trusted source that you want, no?

No, because that whitelist also signs you up for auto-updates.

I also find it very contradicting that you don't want a separate client for every information source, yet find javascript web-apps in the browser bad even though they were exactly created as a compromise solution to that very problem.

It's not a "compromise". JavaScript code for any Web page is a dedicated client for that information source. The only difference is that it's done silently, so people can pretend that there's a difference.

But advanced functionality & usability is pretty poor (especially on mobile browsers) compared those utilizing javascript and more often than not people then resort to closed-source insecure mobile clients to view the forums, which are definitely worse than running whitelisted FOSS javascript in the browser.

Advanced functionality such as...?

Regarding mobile browsers, I've had exactly the opposite experience you describe. Phones are usually poorly capable of handling the JavaScript nonsense you find on websites. In fact back when I actually used a mobile phone, it often took several minutes for JavaScript-laden sites to load. This is because with all this redundant development going on, you get tons of inefficient, unnecessary software.

What mobile devices actually require that many forums lack is responsive design. Unfortunately, a lot of Web developers these days are refusing to use responsive design in such a way that it doesn't create a JavaScript requirement, despite how easy it is. To wit, all of these websites have proper responsive design (try viewing them on a mobile phone):

https://onpon4.github.io
http://hexoshi.nongnu.org
https://kotc-game.github.io

It's really not that hard, and JavaScript has nothing to do with it.

But the end result is that the user is using a service that is much less libre than if it was mostly implemented in client side javascript. An ATM is much less libre than if a FOSS javascript web-app or stand-alone app would be using a banking API.

It's not about "the end result", as you call it. It's about your freedom to control your computing. Any Web server runs code; that's not your computing, and it's absurd to consider it a freedom hit for you when someone you're communicating with is using proprietary software on their end.

Most retailers, as far as I can tell, use Windows to run their self-checkouts. Knowing that, would you consider it to be a violation of your freedom to use the self-checkout system you don't own to ring up your groceries? Or what about the fact that all cash registers run proprietary software? Or what about the fact that ordering stuff online, the company that processes and sends the items uses proprietary software? Is buying stuff a hit on your freedom? If you think so, then your view of freedom is incompatible with any form of interaction with the outside world, and the only way to be consistent is to isolate yourself from all technology, even more so than Amish people do. If (like me) you don't think so, then it logically follows that server-side code running on servers you don't own isn't a hit on your freedom, either.

Online maps

I've already granted that these have to be specialized software, but for a different reason: because to not do so would result in SaaSS. It's perfectly possible, in fact quite easy, to have e.g. a service for finding directions, and it's also possible via use of hyperlinks and server-side code to make it possible to view a map.

The proper way for a map to function is for you to have map software that downloads large chunks of map data, saves it permanently, and then uses it on your computer to find routes. This is in fact how most GPS navigation devices work.

In any case, for specialized, complex software such as this, I am in favor of dedicated software that the user intentionally installs, like GNOME Maps or Marble.

interactive public transport schedule query systems

In what way does a public transport schedule query system need to be "interactive"? What does it need to do that requires JavaScript, and why?

Of course those could be implemented... as server-side only software

You put a lot of loaded statements where I put an ellipsis there, but are you not admitting that the JavaScript is unnecessary if you admit that you can implement the software server-side?

You seem to just take for granted that you get "less software freedom" with server-side only software. If that's the case, shouldn't you be refusing to interact with any server? Or for that matter, any other computer you don't personally control? It seems to me that it logically follows.

I am really not sure why you think a dedicated app is better than one running in the browser?

Because you can feasibly exercise the four freedoms with it, which is not the case with automatically loaded JavaScript because of the basic design of the JavaScript system.

usually can intrude in your system much deeper

Not a problem if you're only running libre software.

In addition browser code tends to be highly scrutinized by security experts... some random app than never gets updated?

What do you mean, "never gets updated"? GNOME Maps, Thunderbird, HexChat, Pidgin... these are all programs that get updates, through my repository.

And you also don't really win anything in regards to "trust" issues as you still have to trust the source of the software itself and the update mechanism it usually utilizes.

All I download software from is the repository of my distro specifically for this reason. Why are you assuming that a world without JavaScript involves downloading software from untrusted sources? It's the opposite: the whole system of JavaScript is about automatically downloading and executing thousands or millions of programs from untrusted sources.

You seem to want more "Web1.0"

There is no such thing as "Web 1.0". If by that you mean the version of the Web with less HTML and CSS capability, where Flash was dominant, then heck no, I don't want to go back to that. I want to go to a system where websites use the HTML and CSS standards to do what they need to do, rather than reinventing the wheel with client-side software that disrupts clients' freedom and creates security problems. And I'd like to see HTML and CSS expanded so they can do even more stuff, and JavaScript as a standard to be deprecated and eventually removed from the standard.

And in the meantime, I'd like websites to be designed in a competent way, such that they at least work without JavaScript. To be clear, most websites do this just fine, including most forum software, as I alluded to earlier.

And all alternatives to pure "Web1.0" you seem to propose are less libre and less secure than running libre javascript from trusted white-listed sources in your FOSS web-browser.

You do remember that JavaScript predates the whole "Web 2.0" buzzword, right? JavaScript was developed way back in the mid-1990s. It was a problem back then, too, only at the time the problem of Flash and ActionScript was more pertinent. Now that Flash is dead, certain websites continue to do what they previously did with Flash, even though HTML and CSS were heavily extended to make it unnecessary (e.g. the video tag). But there are also more and more websites doing things right. Heck, I'll show some examples:

http://channelawesome.com/
https://www.churchofsatan.com
https://github.com/ [1]
https://www.invidio.us/

Turn off JavaScript, and take a look at all of those websites. Do you see poor functionality? Do they look ugly? I don't think either is the case; I think these websites are glorious in their design. And while most websites haven't quite gotten to the point of being as great as these ones, most at least work very well or even entirely without JavaScript.

[1] There are still some caveats here, but it's been getting better and better over time.

See, you seem to be operating under the assumption that supporting JavaScript-less browsers is a step backward. I see it in exactly the opposite way. Not supporting JavaScript-less browsers is a step backward, and working fantastically and looking great without the need for any JavaScript at all is the future I envisage.

So this is you misunderstanding the difference between libre and ethical. Libre, free and open source software is not about you being in control of the end product. It is about access to, freedom to use and modify and distribute the source code and the software you create from that source code.

No, you're talking about the open source position, which I don't support. I support the libre software position.

I do however think that it is bad design for a website to expect JS or even CSS. (Ideally HTML should be human-readable just as plain text.) Using CSS and JS to enhance the site is acceptable, but they shouldn’t be required.

Yeah, that's a good point: CSS is a beautifier and should never be required for functionality. I don't tend to focus on that detail too much, though, because JavaScript is the more pertinent issue. That being said, I do make sure to design my websites in such a way that the CSS being missing doesn't hurt readability.

[Julius]

Honestly, you now seem to arguing for the sake of arguing I addressed every single point you raised in my previous posts, and you seem to conveniently overlook the ones I made about FOSS javascript from trusted sources being more libre and secure than the alternative you propose (except for the pure HTML/CSS pages only option, which works to a limited extend for some webservices, but not for all or at least is usually serious downgrade over the service with client side code). I also never said that I would completely avoid non-libre services, but if I have the choice between a completely non-libre one (Your ATM example) and one that at least gives me the four software freedoms to some extend, I usually prefer the latter (even if less convenient).

Edit: rest assured, your concerns are definitly not being taken lightly, and I would also prefer a forum that has a better non-javascript fallback than Flarum (while still having a good user experience for those willing to whitelist the javascript). But in the end it is also a matter of priorities and what serves a majority of the users best.

[Julius]

Also for reference a similar topic on the Discourse meta forums:
https://meta.discourse.org/t/is-a-javas ... -that-bad/

[onpon4]

you seem to conveniently overlook the ones I made about FOSS javascript from trusted sources being more libre and secure than the alternative you propose

I think I already explained that you misrepresented the alternative I propose by suggesting that I'm in favor of something I'm not. My alternative is:

the pure HTML/CSS pages only option

...which is not the supposed alternative you argued against; your points were an argument against a strawman, that strawman being the position that downloading apps for everything is the way to go.

That is, unless you want to backpedal and say that you made the absurd claim that the existence of more software adds freedom... which you do seem intent on doing. See below.

except for the pure HTML/CSS pages only option, which works to a limited extend for some webservices, but not for all or at least is usually serious downgrade over the service with client side code

I'm still waiting for examples. The only valid example you gave so far was map software, to which my response was that it shouldn't be on the Web at all, and I gave two examples of it being done right: GNOME Maps and Marble. The other example you gave was far too generic to be meaningful.

I also never said that I would completely avoid non-libre services, but if I have the choice between a completely non-libre one (Your ATM example) and one that at least gives me the four software freedoms to some extend, I usually prefer the latter (even if less convenient).

Freedom is not additive. You do not have more freedom because you have more libre software. If you had more freedom just by adding more software, then more complex software would inherently be "more libre" than simple software, and adding tons of unnecessary, redundant libre software on top of a Windows installation would be "more libre" than a completely libre minimalist OS.

It doesn't work that way. If you wanted to measure how much freedom you have in your computing, it wouldn't be based on how much libre software you have; it would be based on how much proprietary software you run, and completely unaffected by the amount of libre software you run alongside it. So adding LibreOffice to your Windows system doesn't give you extra freedom, but you could reasonably say that removing Microsoft Office does give you more freedom.

But in the end it is also a matter of priorities and what serves a majority of the users best.

That's your prerogative, but just be aware that at least one of your users will simply leave the community if you choose that option, since GameDev.net would suddenly become the obviously better choice.

In any case, this discussion has inspired me to revise my article and push for the future I want to see in the Web in earnest. So for that, I thank you.

[Lyberta]

Deleted.

[dulsi]

For a forum it probably isn't a big deal but in some cases javascript may allow the site to offload some of the processing so that the web server doesn't need to be as powerful. For a commercial site that is earning a lot of money it might be reasonable to say you don't want to be donating computing resources. But for free community sites that could be a compromise that makes sense. (Even for commercial sites it might make sense if the cost would be high enough the company would need to charge more for the service.)

There is also the cost of maintenance. We aren't designing forum software. We are limited to what is available. Granted there are javascript free forums but Julius has stated that mobile support is important to him and you also need to judge the viability of the community around the software. If the software doesn't have much of the development community, security bug may languish unfixed. (I'm not versed in forum software so I'm not saying such a system doesn't exist.)

[Wuzzy]

I also dislike websites that hard-depend on JavaScript. Those are no longer websites, those are complete computer programs. I think that JavaScript is rarely really *required* for ordinary websites and if added, it should be used to enhance the user experience, but it should not be abused.
JavaScript-only websites are basically a huge “fuck you” to their users.

I also disagree in part with the whole “usability” premise that is often used as justification. JavaScript is often ABUSED to introduce wildly different concepts that the user has to understand first. Manipulating the browser widgets, or messing with ANY of the browser controls is very evil, but it still happens sometimes. JavaScript is not equal to usability.

A strong reason is accessibility. Scripted content can't be parsed. Scripted content can't be archived. Marked up content can. Tor users also hate JavaScript for good reasons.
I am a huge fan of the principle KISS. JavaScript is not free. It always comes at a complexity cost. Complexity is the enemy of security.
I am also thinking that executable code should be avoided when you can. If you can do the same thing with much less code, go for it. A lot of programmers fall in the trap of writing tons and tons and tons of code and re-inventing the wheel because coding is what they do. But a good programmer should not just code, but also be good in designing a software. My argument is, whenever you have executable code, it can break and it can be insecure.

Stupid (i.e. simple) code and smart data strucutres is often much better than the other way around.
In the web, I've seen far too often JavaScript re-implementing basic features that stock HTML and CSS already offer. CSS has many awesome features which some web devs seem to be completely unaware of. To web devs I strongly suggest to really learn how to CSS before proceeding with more complex stuff. CSS has some interesting GUI features as well.

And at this point I did not even bring up the issue of freedom. This is on top of all that.

Anyway. These were some of my random ramblings.

[Julius]

https://discuss.flarum.org/d/18526-both ... -we-fix-it

Related discussion on the Flarum meta board.

[zzo38]

Auto updating code is a bad idea. Furthermore, even if it is FOSS, it is not necessarily the case that it does what is desirable; it isn't very helpful if the user cannot easily modify and replace it. Furthermore, JavaScripts should be unneeded for most web pages (although sometimes may be helpful as an optional feature, e.g. client-side validation; if it is not enabled then server-side validation will still be done anyways). However, this is also true of CSS, although less so since it is easier to replace and less likely to cause undesirable operation. My opinion is that often plain HTML is suitable anyways.

Some people had mentioned that the owner is the server operator so that what I mentioned about the user unable to replace it does not apply. That is true for server-side JavaScript code, which will work even if client-side JavaScript is disabled. However, for client-side JavaScript code, that is not the case; it is sent to the client and the client can and should be operated by the end-user's specifications.

There are some problems (and some good things) with the JavaScript programming language, but that is irrelevant; client-side scripting is problematic regardless of the programming language. Criticism of the programming language is mostly not relevant here (although if parts of it are going to run inefficiently, perhaps that might be a possible criticism since it wastes the client's power; I/O capabilities also might be, but JavaScript doesn't have inherent I/O capabilities (they are part of WWW, not JS) so that isn't relevant in this case).