On 2025-08-15, Carlos E. R. wrote:

On 2025-08-15 10:35, rbowman wrote:

On Thu, 14 Aug 2025 23:38:22 +0200, Carlos E. R. wrote:

On 2025-08-14 23:22, Computer Nerd Kev wrote:

[...]

Well Intel are one of the top sponsors of the Linux Foundation too:
https://www.linuxfoundation.org/about/members

(buggy Javascript required, and that made Firefox fill up all my PC's
RAM and freeze, so I had to kill it. Just to display some company
logos. Huff! I wouldn't choose Linux as my OS based on that website!)

The page loads fine here.

It did load in Brave and only took 1.4 of the 8 cores to do so. I didn't
note the RAM usage.

In Ffx I looked at "about:processes" and it only went up when moving
the "cursor" up/dn, ie, when displaying a new section of it, as
expected.

Still, working fine in one browser (or a few) but not in others can't be
the new normal for FLOSS websites.

This is the same free software world that was constantly hit by vendor
lock-in and proprietary stuff from MICROS~1, this is the same free
software world where some sites would only work in IE in the late 90s,
early 2000s and left out free software users.

It still strikes me as unbelievable that it's now acceptable for free
software entities to have websites that require new hardware and require features only implemented in a few browsers.

It was already bad to see such novelty sites switching to approaches
where javascript must be enabled, but no, nowadays you also get
"intensive processor usage" and "requires unavailable features". If
you're lucky, you also get "requires webgl".

--
Nuno Silva

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Nuno Silva <nunojsilva@invalid.invalid> wrote:

On 2025-08-15, Carlos E. R. wrote:

On 2025-08-15 10:35, rbowman wrote:

On Thu, 14 Aug 2025 23:38:22 +0200, Carlos E. R. wrote:

On 2025-08-14 23:22, Computer Nerd Kev wrote:

https://www.linuxfoundation.org/about/members
(buggy Javascript required, and that made Firefox fill up all my PC's >>>>> RAM and freeze, so I had to kill it. Just to display some company
logos. Huff! I wouldn't choose Linux as my OS based on that website!) >>>>>

The page loads fine here.

It did load in Brave and only took 1.4 of the 8 cores to do so. I didn't >>> note the RAM usage.

In Ffx I looked at "about:processes" and it only went up when moving
the "cursor" up/dn, ie, when displaying a new section of it, as
expected.

Still, working fine in one browser (or a few) but not in others can't be
the new normal for FLOSS websites.

This is the same free software world that was constantly hit by vendor lock-in and proprietary stuff from MICROS~1, this is the same free
software world where some sites would only work in IE in the late 90s,
early 2000s and left out free software users.

It still strikes me as unbelievable that it's now acceptable for free software entities to have websites that require new hardware and require features only implemented in a few browsers.

Exactly, and to do what here? Displaying headings and company
logos! HTML was designed from the start to do that perfectly well.
Requiring Javascript is pure willful over-complication for the sake
of it, and in so doing introduced a bug where there needn't be one.
The code to do all that is in the browser, it's in all major
browsers from the 1990s even, I shouldn't be facing bugs with that
in 2025 just because someone wanted to do it "their way" with
Javascript instead!

This is exactly why, when faced with such empty JS-required pages
in Dillo, I'm better off just moving on and browsing other websites
rather than conceding (as people keep telling me I should do) and
loading them Firefox, where they're free to lock up my whole
system.

--
__ __
#_ < |\| |< _#

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/08/2025 01:38, Computer Nerd Kev wrote:

This is exactly why, when faced with such empty JS-required pages
in Dillo, I'm better off just moving on and browsing other websites
rather than conceding (as people keep telling me I should do) and
loading them Firefox, where they're free to lock up my whole
system.

Mmm. yes. I sort of agree.

I've noticed various sites that will send Firefox into random RAMGrab™

On my Laptop (4GB only) some video sites if left running videos, can
lock up the audio which then endlessly repeats the same 250ms of audio.
Making it a suitable political candidate I suppose...

However my home websites all use JavaScript as a very convenient way to
write a real-time user control interface.

If you change something you want it to immediately change (AJAX) the
server end and update the (local) screen

This is not the original intention of HTML, but it's the simplest way
for one device running a browser to control another.

--
“People believe certain stories because everyone important tells them,
and people tell those stories because everyone important believes them.
Indeed, when a conventional wisdom is at its fullest strength, one’s agreement with that conventional wisdom becomes almost a litmus test of
one’s suitability to be taken seriously.”

Paul Krugman

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The Natural Philosopher <tnp@invalid.invalid> wrote:

On 16/08/2025 01:38, Computer Nerd Kev wrote:

This is exactly why, when faced with such empty JS-required pages
in Dillo, I'm better off just moving on and browsing other websites
rather than conceding (as people keep telling me I should do) and
loading them Firefox, where they're free to lock up my whole
system.

Mmm. yes. I sort of agree.

I've noticed various sites that will send Firefox into random RAMGrab(TM)

On my Laptop (4GB only) some video sites if left running videos, can
lock up the audio which then endlessly repeats the same 250ms of audio. Making it a suitable political candidate I suppose...

However my home websites all use JavaScript as a very convenient way to
write a real-time user control interface.

If you change something you want it to immediately change (AJAX) the
server end and update the (local) screen

This is not the original intention of HTML, but it's the simplest way
for one device running a browser to control another.

Yes, well this is exactly my point. The content shown on the page
in question is exactly "the original intention of HTML", but they
use JS anyway and hence cause new problems where there needn't be
any.

People can have their JS for video sites (though these do have less
excuse now with HTML5 adding support for them) and whatever you're
doing (though I'd seek a different approach personally). But if I'm
browsing for basic information like what HTML _was_ intended to
display and a website blanks me in Dillo because I'm not running
their JS anyway, I'll look elsewhere. Either they're using JS just
for the sake of it, or they're actually trying to do something
sneeky (often now just for blocking non-humans, sometimes with the
wrong conclusion in my case anyway).

--
__ __
#_ < |\| |< _#

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 16 Aug 2025 10:39:21 +0100, The Natural Philosopher wrote:

However my home websites all use JavaScript as a very convenient way to
write a real-time user control interface.

If you change something you want it to immediately change (AJAX) the
server end and update the (local) screen

This is not the original intention of HTML, but it's the simplest way
for one device running a browser to control another.

AJAX or Dynamic HTML is a very old concept. What really turbocharged it
was Google’s introduction of its “V8” JavaScript implementation in Chrome/
Chromium, that took JavaScript from “usable but slow” to “approaching the speed of compiled code”. Now, you could do seriously complex interactions that were entirely local to a web page.

Of course, the concept was quickly embraced by other browser developers.
And now as a result we have “Web 2.0”, and the use of web-based interfaces for, not quite everything, but certainly getting close.

There is another step beyond that, and that is the use of “WebSocket” connections for continuous live full-duplex communication between client
and server. Found a use for those yet?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 17 Aug 2025 01:08:39 -0000 (UTC), Lawrence D’Oliveiro wrote:

There is another step beyond that, and that is the use of “WebSocket” connections for continuous live full-duplex communication between client
and server. Found a use for those yet?

Hell yes!

var io = require('socket.io')(http);

In our legacy system the Motif clients and the web map all established a connection to the node server and passed data back and forth.

socket.request.connection.remoteAddress

is the IP of the machine originating the connection. Using that to match
up the messages the map would only display the incidents and resources
that dispatch had active since everything on that machine was connected
via the server.

The map in the browser used the socket.io library. The Motif clients made
a standard socket connection and sent a file with a

Content-Type: application/json

header.

Of course the server also provided static files and other data common to
the map.

The updated product was strictly browser based and done in Angular so that introduces protobufs and so forth to the game. The map was integrated. The Motif clients didn't need a map or interaction with a node server; that
was all a configurable option. The Angular product definitely needed nginx
and a lot more wiring. The daemons remained the same.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)