Re: JavaScript is only a tool

[Lorenzo L. Ancora]

> Call it dynamism if you want.

This is how it is technically called and the distinction is important.

> Then dynamism it's (or should be) enough useful on most scenarios.

Server-side scripting is not an alternative to client-side scripting, 
the two things bring heavily different results and offer different 
possibilities. Not all client-side scripts can be replaced (or are 
convenient to replace) in this way. The opposite, unfortunately, is not 
true, because - when there are no security implications - offloading the 
computing to the client is always advantageous for a webmaster.

> > Thus, the functionality offered by JavaScript can by no means be
> > replaced by server-side processing, but server-side processing can be
> > used to produce dynamic JavaScript to reduce the complexity of existing
> > client-side code (this is an advanced technique, often used with
> > server-side scripting frameworks).
> This argument seems same as "functionality offered by Adobe Flash can by
> no means be replaced by JavaScript" or "functionality of ELF or EXE can
> by no means be replaced by Flash, ActiveX or Java applets" > What is "enough" and what is 
> "desirable" ?

I'm sorry, your question is too vague and my answer would be redundant. 
Can you elaborate it further?

> The need to use JavaScript grows with developer's dependence of it to
> make a website nice or productive at his/her like.

There is no alternative to JavaScript, thus depending on JavaScript is 
equivalent on depending on CSS or HTML. Webmasters use these standards 
because there are no better/supported standards available. In general, 
webmasters always use the most widespread and supported technology.

> > Perhaps one could be in the condition of totally disabling JavaScript if
> > underage or in a very reclusive community, otherwise there will be
> > always a moment in which you will be forced to use it (and very often,
> > as it should be, its execution is transparent).
> Oh, I have not enough time to open a new thread about JavaScript
> transparency and bad practices over average users.

The world is unfair. It would be an endless mail thread! ;-)

> An HTML6 version is desirable to extend tags and properties that make
> JavaScript less and less necessary to validate forms, change UI
> behaviour (such as editor) or react to events.
> In the meanwhile, JavaScript is the main trap for human beings.

"JavaScript is the main trap for human beings" ... yes, it is an 
unavoidable trap. :-)
Furthermore, I'm sad to reveal the truth: markup languages like HTML 
(current and future versions) cannot replace scripting languages by no 
means. It is physically impossible, because a markup language with 
scripting capabilities becomes a scripting language, thus you would 
obtain only another kind of JavaScript. Actually, it is even worse, 
because a deeply integrated scripting system would be impossible to block.

> You are a bit confused:
> End users don't demand this or that, but they respond to companies
> competition to steal personal data and social data. Ens users demand
> humanity, and GAFAM (for example) serve "fake social" humanity.
> Web tracking is well-hidden under JavaScript "useful tools".
> "Ens users expect the best"

Web tracking exists with or without JavaScript. Server logs and cookies 
are more than sufficient to track end users, only that there has been no 
economic incentive to implement server-side tracking, because 
client-side tracking, while being less effective, is also more economic 
and easier to deploy in production. If JavaScript disappears 
entrepreneurs will only find another way to track their users, both for 
bad and for good.

I believe it is more a question of educating end users: if I asked you 
for your identity card now you would not give it to me very easily, so 
in the same way do not upload private data to websites you do not trust; 
in the same way do not install apps from vendors you don't trust. If you 
give permission it is then your responsibility.
JavaScript is only a tool, people can and will kill their privacy with 
or without it, because the issue is mental (superficiality), not technical.

> > JavaScript is required for chat, A/V streaming, live streaming,
> > security, ecommerce, gaming, social networking, banking, and so on, plus
> > it brings significant benefits in terms of security and accessibility in
> > many other more traditional applications, especially if the site is
> > large and needs faster ways to present information (end users rarely
> > spend more than 30 seconds on a web page if their attention is not
> > immediately captured).
>
> I completely disagree, and some JS-free CMS prove it.

A CMS does not require JavaScript and dynamism is enough (and for small 
websites it is fine, you can even use a flat-file database in these 
cases), however the correct presentation of the multimedia contents - 
that is, anything that goes beyond simple embedding - will require 
JavaScript. For example, using a socket to support a chat next to the 
video will require JavaScript, as well as allowing remote control of a 
streaming camera, leaving comments in real time, playing a multiplayer 
game, safely buy a product and so on. Countless websites have no choice 
but depend on JavaScript, mainly because, all these tasks, if performed 
without JavaScript, would make the site unable to support more than a 
few hundred users at a time and for those users it would be difficult to 
have good responsiveness, it would be incredibly inconvenient to have to 
reload the page for each interaction.

> This paragraph suggests you don't want society makes changes to progress
> to a better world. It's like saying "a very recluse community use
> electric-only vehicles".

Are you accusing me of something? Look, I limit myself to only describe 
facts, there is no personal opinion in my words. If you want an opinion, 
you have to ask for it explicitly.

Regarding the comparison, the answer is no, it is not the same thing, 
because electric vehicles are a very different type of good (material, 
innovative, luxury good) and are obviously subject to other economic 
rules. Governments, businesses, corporations and other entities make 
pressure to gain independence from non-renewable energy sources, so 
there is an enormous social/economic/ethical push toward the adoption of 
electric vehicles. The same cannot be said for the abandonment of 
JavaScript and, on the opposite, the rise of IoT represents a notable 
incentive towards its development.

> GAFAM lie to webmasters to they use tracking APIs and fonts, so GAFAM
> track end users by using webmasters as an instrument.
> And ens users (consumers) don't ONLY act to satisfy NEEDS; in the XXI
> century people act to satisfy created extectations.

This is all true, I agree.

> > JavaScript runs in multiple sandboxes and is no more or less vulnerable
> > than other web standards. > I completely disagree because of the focus of 
> > phrase: JavaScript makes
> user more vulnerable than other web standards (such as HTML). This is
> because of 3 reasons:
> 1. JavaScript's flexibility to do complex procedures.
> 2. End user's difficulty to trust on what are doing JS complex actions
> 3. Webmasters (such as GAFAM) bad practice to force people to accept new
> JS procedures, and this is followed by web browsers updates that support
> this evolution.
> Take a look into difficult for webmasters to apply strict CSP & SOP to
> websites.

1. This is the reason JavaScript exists. If something is simple you 
likely won't need to use it;
2. Unfortunately, very few end users question the purposes of the 
scripts executed and study the code inside a webpage. Almost the 
totality of the visitors of a website do not even think about the 
presence of JavaScript, which goes unnoticed;
3. The world is made up of potential customers and businesses. Those who 
maintain browsers are always looking for a compromise to allow the 
user's daily activities without interruptions, which also means meeting 
the needs of entrepreneurs.
4. They are very young standards, many webmasters have not yet received 
the continuous education to be able to use them correctly. By the way, 
companies which offer a service to the webmasters are able to track both 
the webmaster and the end user even when those standards are 
implemented. They are meant to enhance security, not privacy.

> > Obsolete computers are vulnerable and its your responsibility (or the
> > responsibility of your sysadmin) to install the security patches when
> > available. If you don't update your system, disabling JavaScript can
> > only reduce the attack surface and the only solution is to disconnect it
> > from the Internet. If you own vulnerable hardware, don't use it to
> > browse the Internet in the first place.
>
> This is a trap: I fee more vulnerable a website (also bank websites)
> full of third party JavaScript than most of obsolete computers.
> It's like to compare an old bycicle vulnerabilities with modern car with
> updated firmware.

JavaScript allows banks to distinguish real web browsers from bogus ones 
and encrypt information in real time. In addition, third-party scripts 
(where required) can be included after an integrity check, therefore 
without the possibility of being replaced if/when the third-party is 
compromised.

In many countries banks are forced to use JavaScript and apps during 
authentication.

> > By law, banks have to discern legitimate users' legitimate web browsers
> > from clients trying to simulate a web browser; they must also carry out
> > checks on a time basis by law, to avoid brute force attacks and
> > complicate the potential thefts of credentials (and I'm sure also other
> > horrible frauds). Banks are forced to use all possible means to secure
> > their web portals.
>
> Some law reference?

See PSD2 \ 2015/2366/CE. It also depends on the specific nation, e.g. in 
Italy all banks require an app inside the smartphone or an advanced 
token of some kind and won't work without JavaScript.

Obviously, I cannot start citing the laws of every nation in the world, 
but in general the law of the various countries states that banks (and 
in general anyone who receives custody of an asset) must do everything 
possible to protect the security of the customer and the data entrusted. 
For example, almost all banks require a token or a digital certificate, 
which must be bound by very stringent time factors to avoid the 
fraudulent reuse of authentication codes. In addition, during all 
transactions the bank is obliged to verify that the user is real using a 
special intermediate page, tracking him to avoid data theft, person 
replacement and so on. Unfortunately, all of these security measures 
require JavaScript and often even captchas.

> Today's problem is the selling of people's information itself, beyond
> products.

This is why we call it "Information Society". ;-)

> > Everyone hates advertisements, but they are necessary for everyone, even
> > for those who distribute free software but do not intend to ask for
> > donations, for example. Without ads, you wouldn't be able to download
> > anything for free, because domains, servers and staff have a cost.
>
> Internet is a communication infrastructure.
> Communication does not require advertisements.
> I feel this thread is a conversation from really different worlds.

Internet is a communication infrastructure.
Infrastructure requires money to be maintained.
Ecommerce and ads are a source of income to sustain it.
JavaScript is required to sustain both and thus the Internet.

> > This does not make the protocols stateful, they remain stateless.
> > Developers, in fact, have to respect the standard and the state must be
> > kept with distinct means. In addition, webmasters and web server
> > developer cannot base their commits on inconsistent - albeit
> > standard-compliant - client software behavior.
>
> You are supposing webmasters and developers they all make their job with
> good practices and to be kind with end users. This is unrealistic.

Webmasters have all interest in being standard-compliant, so they can 
target more devices and receive more users. They make their interest, 
which in this case coincides with that of end users.

> I enjoy live talking with my neigboors and we don't need advertisements
> to do this at our street. I can pay a table and some chairs to enjoy a
> sunday with my friends, and I don't need advertisements to be happy with
> them.

I am very happy for you. Then you will go home and turn on the TV, where 
you will find commercials, otherwise you would not have any TV program 
except the news. Then you will read the morning paper, where there will 
be advertisements. When you start driving, you will notice the presence 
of billboards in the streets. At work, you will certainly receive 
advertising emails, some of which will end up in the SPAM folder. When 
you'll have a doubt about solving a complex problem at work, you will 
search the Internet, where the search engine and then the websites will 
show advertisements. Back home after work, you will stop for a coffee at 
the bar, where there is a poster advertising a famous drink on the wall. 
In line to pay for the coffee, you will notice that the radio is on and 
shortly afterwards an advertisement for a new insurance company will 
start. Once out of the bar, a truck will pass in front of you, and on 
its side you will notice the presence of a large advertisement for a 
museum in the suburbs. When at home you'll relax in the bathtub but, 
after a few moments, you'll hear far away the voice of a speaker mounted 
on a van, announcing an upcoming spectacle. At the end of the day, 
before going to bed, you'll end your reading of "I Malavoglia" by 
Giovanni Verga, an important novel and, before closing the last page, 
the last image you are able to see before dozing off, is the written ad 
containing an offering to get a discount on the next book, "The Divine 
Commedy" by Dante Alighieri.

...in your dreams, you'll then start remembering the catchy song from 
the ads and you'll wakeup with that in mind, ready to live another day 
as one of the many cogs of the modern economy.


Il 24/07/21 17:06, Narcis Garcia ha scritto:
> El 24/7/21 a les 14:02, Lorenzo L. Ancora ha escrit:
> > > You must differenciate scripts to be run server-side or client-side.
> > > You can't have interactivity without server-side code (such as PHP or
> > > Python), and YOU CAN have interactivity without client-side code (such
> > > as JavaScript or VBScript): Just HTML forms and links.
> >
> > I already did but I believe you are a bit confused: reactivity and
> > interactivity refer only to web pages that have been already downloaded
> > by the web browser (and they refer exclusively to web browsers, not to
> > other kind of clients). Reactivity and interactivity have nothing to do
> > with server-side processing, which is physically incapable of offering
> > any of those because HTTP/S is a stateless client-server protocol.
> >
> > What you were perhaps referring to is dynamism, which is another
> > entirely different concept. Dynamism is the ability of a server to send
> > different web pages based on different voluntary/involuntary user input
> > and has nothing to do with DOM changes once the transfer is complete.
> > Static websites always upload the same webpage; dynamic websites produce
> > the webpage via scripts or other means during each client request and
> > then upload their output.
>
> Call it dynamism if you want. Then dynamism it's (or should be) enough
> useful on most scenarios.
>
> > Thus, the functionality offered by JavaScript can by no means be
> > replaced by server-side processing, but server-side processing can be
> > used to produce dynamic JavaScript to reduce the complexity of existing
> > client-side code (this is an advanced technique, often used with
> > server-side scripting frameworks).
>
> This argument seems same as "functionality offered by Adobe Flash can by
> no means be replaced by JavaScript" or "functionality of ELF or EXE can
> by no means be replaced by Flash, ActiveX or Java applets"
> What is "enough" and what is "desirable" ?
>
> > > Really few scenarios I've seen with client-side code really required;
> > > for example a WYSIWYG editor. Not much more.
> >
> > Maybe you haven't read part of the thread (note the title change).
> > The need to use JavaScript grows with the size of the website and the
> > number of users. In the majority of websites (banks, e-commerce, trading
> > portals, web chats, videoconferencing, video streaming, live streaming,
> > and so on), JavaScript is not optional but - unless the website is very
> > small and amateurish - not using it is always disadvantageous and
> > uneconomical.
>
> The need to use JavaScript grows with developer's dependence of it to
> make a website nice or productive at his/her like.
>
> > Perhaps one could be in the condition of totally disabling JavaScript if
> > underage or in a very reclusive community, otherwise there will be
> > always a moment in which you will be forced to use it (and very often,
> > as it should be, its execution is transparent).
>
> Oh, I have not enough time to open a new thread about JavaScript
> transparency and bad practices over average users.
>
> > Il 21/07/21 06:52, Narcis Garcia ha scritto:
> > > El 20/7/21 a les 21:34, Lorenzo L. Ancora via ha escrit:
> > > > A script is interpreted and subject to indirect execution. The sandbox
> > > > is just an addition to this process, which improves its already high
> > > > security.
> > > >
> > > > After all, you can't have interactivity without running some code,
> > > > either explicitly or explicitly. The ability to execute code is a
> > > > prerequisite for making web pages interactive. Maybe in 10 years they
> > > > will invent the web 9.0 and it will all be different, but for now the
> > > > reality is that you have to run hundreds of small scripts just to shop
> > > > online or access your bank.
> > >
> > > You must differenciate scripts to be run server-side or client-side.
> > > You can't have interactivity without server-side code (such as PHP or
> > > Python), and YOU CAN have interactivity without client-side code (such
> > > as JavaScript or VBScript): Just HTML forms and links.
> > >
> > > Really few scenarios I've seen with client-side code really required;
> > > for example a WYSIWYG editor. Not much more.
>
> An HTML6 version is desirable to extend tags and properties that make
> JavaScript less and less necessary to validate forms, change UI
> behaviour (such as editor) or react to events.
> In the meanwhile, JavaScript is the main trap for human beings.


> El 24/7/21 a les 14:02, Lorenzo L. Ancora ha escrit:
> > > You must differenciate scripts to be run server-side or client-side.
> > > You can't have interactivity without server-side code (such as PHP or
> > > Python), and YOU CAN have interactivity without client-side code (such
> > > as JavaScript or VBScript): Just HTML forms and links. 
> >
> > I already did but I believe you are a bit confused: reactivity and
> > interactivity refer only to web pages that have been already downloaded
> > by the web browser (and they refer exclusively to web browsers, not to
> > other kind of clients). Reactivity and interactivity have nothing to do
> > with server-side processing, which is physically incapable of offering
> > any of those because HTTP/S is a stateless client-server protocol.
> >
> > What you were perhaps referring to is dynamism, which is another
> > entirely different concept. Dynamism is the ability of a server to send
> > different web pages based on different voluntary/involuntary user input
> > and has nothing to do with DOM changes once the transfer is complete.
> > Static websites always upload the same webpage; dynamic websites produce
> > the webpage via scripts or other means during each client request and
> > then upload their output.
>
> Call it dynamism if you want. Then dynamism it's (or should be) enough
> useful on most scenarios.
>
> > Thus, the functionality offered by JavaScript can by no means be
> > replaced by server-side processing, but server-side processing can be
> > used to produce dynamic JavaScript to reduce the complexity of existing
> > client-side code (this is an advanced technique, often used with
> > server-side scripting frameworks).
>
> This argument seems same as "functionality offered by Adobe Flash can by
> no means be replaced by JavaScript" or "functionality of ELF or EXE can
> by no means be replaced by Flash, ActiveX or Java applets"
> What is "enough" and what is "desirable" ?
>
> > > Really few scenarios I've seen with client-side code really required;
> > > for example a WYSIWYG editor. Not much more.
> >
> > Maybe you haven't read part of the thread (note the title change).
> > The need to use JavaScript grows with the size of the website and the
> > number of users. In the majority of websites (banks, e-commerce, trading
> > portals, web chats, videoconferencing, video streaming, live streaming,
> > and so on), JavaScript is not optional but - unless the website is very
> > small and amateurish - not using it is always disadvantageous and
> > uneconomical.
>
> The need to use JavaScript grows with developer's dependence of it to
> make a website nice or productive at his/her like.
>
> > Perhaps one could be in the condition of totally disabling JavaScript if
> > underage or in a very reclusive community, otherwise there will be
> > always a moment in which you will be forced to use it (and very often,
> > as it should be, its execution is transparent).
>
> Oh, I have not enough time to open a new thread about JavaScript
> transparency and bad practices over average users.
>
> > Il 21/07/21 06:52, Narcis Garcia ha scritto:
> > > El 20/7/21 a les 21:34, Lorenzo L. Ancora via ha escrit:
> > > > A script is interpreted and subject to indirect execution. The sandbox
> > > > is just an addition to this process, which improves its already high
> > > > security.
> > > >
> > > > After all, you can't have interactivity without running some code,
> > > > either explicitly or explicitly. The ability to execute code is a
> > > > prerequisite for making web pages interactive. Maybe in 10 years they
> > > > will invent the web 9.0 and it will all be different, but for now the
> > > > reality is that you have to run hundreds of small scripts just to shop
> > > > online or access your bank.
> > >
> > > You must differenciate scripts to be run server-side or client-side.
> > > You can't have interactivity without server-side code (such as PHP or
> > > Python), and YOU CAN have interactivity without client-side code (such
> > > as JavaScript or VBScript): Just HTML forms and links.
> > >
> > > Really few scenarios I've seen with client-side code really required;
> > > for example a WYSIWYG editor. Not much more.
>
> An HTML6 version is desirable to extend tags and properties that make
> JavaScript less and less necessary to validate forms, change UI
> behaviour (such as editor) or react to events.
> In the meanwhile, JavaScript is the main trap for human beings.
>
> --
> Narcis Garcia

--
All messages from/to this account should be considered private.
Messages from/to newsletters should not be reshared.
TZ: Europe/Rome (Italy - CEST).

OpenPGP_signature
Description: OpenPGP digital signature