Sent from my iPhone
> On Apr 29, 2016, at 4:24 PM, Sylvain BERTRAND <sylvain.bertrand_AT_gmail.com> wrote:
>
> The main issue is java/ecma script on the "www DOM" (Document Object Model):
> Between noscript www browser code requirements and script-able www browser code
> requirements, there is an abyss in size and complexity.
>
> Additionnaly, the "modern" www tends to force the user to have a script-able
> www browser, even though many www sites could provide their services with a
> noscript www browser through a cleverly crafted main www portal or a dedicated
> noscript www portal on the side of the main (with all bells and whistles) www
> portal.
> ----------------------------------------------------------------------------
> ^
> |
> That's where the real fight is
>
Yes, the real issue is server side. Node.js needs to do DOM manipulation on the server side and do some kind of DOM sync using classical tech like delta instances in HTTP and a new spec for sessions and events. Then browsers like Dillo will be king. I wrote an article over a decade ago on this:
https://web.archive.org/web/20080121000851/http://tautology.org/software/articles/ajax
Then browsers can be fully declarative. Throw away the outdated Semantic Web arguments, it is just a whole lot easier to secure.
> For instance, youtube could provide a noscript www portal with <video> and/or
> <audio> html elements. EZ and reasonable to implement even for inexperienced
> coders around the globe. But no. You _must_ have a script-able www browser to
> enjoy youtube (the terms of use even forbid users to employ anything else in
> order to watch/listen to a video/audio stream). I have to admit, html needs a
> little extension to <video>/<audio> in order to support split video/audio
> streams. Basically, we would need a simple html-ed "DASH" manifest. But
> vp[98]/opus high/med/low qualities video/audio combined streams should be
> enough in most cases. (remainging cases would be handled with the standard
> "download then view" way).
>
> Another example: online banking. http, xhtml1.1 and css2.1 with basic forms are
> hell enough to provide banking services to www users. But no. You _must_ have a
> script-able www browser. And lately, it does apply to "verified by visa" and
> online payments...
>
> Sometimes, it does not work. For instance, soundcloud. Soundcloud needs a rich
> GUI to provide its services. But they could provide a simple http API to let
> people have their own GUI components. Many www sites have their www APIs, but
> need a redirection on a script-able www browser on the side for authentication...
> Ooops!
>
> ----
>
> You have only 2.5 modern open source engines which "can run the www":
> - webkit (massive and c++ is brain damaged)
> - blink (webkit google's fork, see above)
> - gecko (firefox, massive and c++ is brain damaged)
>
> BTW, I wonder if there is a http/mime way for a www browser to tell a http server:
> "noscript please".
>
> ----
>
> There is a team working on a C implemented www browser: netsurf. I got a little
> chat with one of its devs: "www DOM dynamicity through script is insane".
>
> cheers,
>
> --
> Sylvain
>
Received on Sat Apr 30 2016 - 02:32:23 CEST