On 2020-08-14, Theo wrote:
> Poprocks  wrote:
>> On 2020-08-13, Axel Berger wrote:
>> > That's not the main point. Very few sites come even near to being valid.
>> > 90 % of the bloat (and the same share of the malware entry points) come
>> > from trying to second guess, whatever the author might have meant by the
>> > utter nonsense he wrote.
>>
>> I don't agree with that at all.  I'd say that accounts for some of the
>> overhead, but a very small percentage.
>
> Indeed, and a site that isn't valid HTML according to the spec doesn't take
> materially more compute resource to parse.  Maybe it's more ambiguous and
> the results might differ between browsers, but it's not slower.  HTML isn't
> the problem, Javascript is.

Yes, agreed.  HTML was *designed* to be forgiving, as part of its
/modus operandi/.  This video by Professor Brailsford is on point:

https://www.youtube.com/watch?v=-csXdj4WVwA

What do you perceive to be the issue with JavaScript?  Is it an inherent
with the language itself, or is it just over-used?

I think we can probably all agree that when it was conceived in 1995, it
was probably only intended to give webpages a bit of "help" with some
client-side operations, but not to completely replace the heavy lifting
of processing of information, which ought to be done on the server side
with more capable languages (yes, I am aware of Node.js and all that
jazz.  Not super familiar with it, but it all still seems like trying to
pound a round peg into a square hole to me).

> (I put sites like Facebook and Youtube through the W3C validator.  They
> didn't pass, but the problems were mostly applying name="..." to elements
> that should have that according to the spec.  That's not going to slow down
> parsing - but those things are necessary for Javascript to manipulate the
> DOM)
>
>> The real issue is that webpages have stopped becoming *pages* and are
>> now essentially applications in and of themselves, all being run through
>> essentially slow, interpreted languages.
>
> And some of those scripts are doing intrinsically complicated things, like
> doing a live auction of the user's eyeballs to the highest bidder advertiser
> - all while the page loads.

I think this is an example of a *good* usage of JavaScript.

However, for users who disable JavaScript, in such situations the page
ought to still *work* and show the updated information if the user
reloads the page, instead of just refusing to work at all, which is what
we see all too often.

> Block those things and page load times come down a lot, but there's still
> tons of complicated Javascript in something like Google Docs which you can't
> block or it won't work.

Indeed.  In a way --- although it seems to have happened historically by
accident --- I think the original idea starting with Netscape Navigator
(2.x I believe, but certainly by 3.0) to have JavaScript do some
light-duty client-side capabilities, and have Java do some heavier-duty
web-based applications through Java applets, was on the right track.

Now, with --- to use your example --- Google Docs, I can barely get the
thing to run on my 2-in-1 Intel CherryTrail tablet, with 4GB of RAM and
a (admittedly underpowered) multicore x86_64 processor.

And yet, I know if I was somehow able to access the Android mobile app
(likely written in Java incidentally, though I stand to be corrected on
this), my guess is it'd work quite well.

> To the OP, there are browsers that have a full webkit engine (so the JS
> works) but the UI is written in C(++) not in Javascript, which makes them
> faster and lower footprint.  Look at Otter Browser, QtWebkit and some
> others.

I'll add that I've been quite impressed by Falkon.  It utilizes Qt
WebEngine but has a fully native C++ Qt interface.  It won't be as light
and zippy as something like links -g or dillo, of course, but it seems
to be a very good candidate for a "middle-weight" browser.  It also
manages to look quite a bit like Chrome, which makes the interface
friendly and familiar.

I can't quite free myself from the teet of Chromium just yet, but Falkon
has a better chance of becoming my new daily driver than (sadly) the
likes of Firefox.

--- SoupGate-Win32 v1.05