Re: [whatwg] HTML6 proposal for single-page apps without Javascript

Some years ago there were also Internet Explorer 6, proprietary tags,
frameset web pages and the project for DHTML. There also was the idea of
simple JS expressions to be evaluated in CSS. Why does anybody not propose
to restore {expression()}?
Never been a fan of the "new is good" motto, but saying that things were
better in the past just because they were that way seems.... odd.
Delfin, you also cite the times (2002) when CSS could be effectively
disabled. Can you imagine a Web without CSS nowadays?
I don't think that Bobby's proposal focuses on ease of use. His model, as
it it planned now, seems quite complicated now. It is a different kind of
difficulty, but still difficult.

And planning to give "the coding power to the people" by means of
"inventing easier things" is wrong in its very merit. Javascript itself is
not a difficult programming language. In fact, Mr Mozumder's proposal seems
to lack uniformity because it does not make clear whether the author wants
to oppose the JS concept or the multiplication of frameworks.
Let's put it in 2 separate points:

1. fighting against frameworks is contrary to the very same logic you are
citing as support for Web "as it was". It is true that different frameworks
solve the same problem in different ways. Thus authors can choose the tools
which best fit to the project - or no tools at all, but this is the second
point. Yes, there could be a sort of "native framework" and it will have
its strong points.... as well as its liabilities, and if it doesn't cover a
specific document structure it must be switched in favor of another. I take
it for granted that Bobby has no ambition to write the ultimate framework,
and I'm also sure that he couldn't do it by himself, were he going to.
But it is also true that frameworks add weight to the page. A weight which
is only partially reduced by e.g. using Google CMS to serve frameworks like
jQuery, considering that if several websites use the same files, then once
a user visits one, the script files are cached. I think that the only, REAL
good point in Bobby's project is this: reducing weight, and thus reducing
loading lag (reduced to 0 when you have nothing to download); and reducing
execution time, as some frameworks have a long time being executed (but
then Mr Mozumder has to prove that UA native implementation will be faster
- it's a joke, of course. Mr Mozumder cannot prove anything about that)

2. fighting against JS itself is a completely different case. I have
discussed it in depth above and I guess nobody likes to re-read things.
JS has been part of "making web pages" for a long time now. It is the
necessary integration to HTML and CSS because neither HTML nor CSS are
meant for content manipulation. HTML exposes an API, the DOM, and that API
can be used for a lot of things. This is the good point of JS. It allows
authors to work on elements and attributes, as well as interface
attributes, methods and properties using a much more fine-grained structure
than simple HTML. To make an example, when loading an external content you
can access different properties allowing you to easily find out origin,
HTTP call response code, loading status and so on. You have nothing to test
it in native HTML, unless you say that calling, e.g.,
"model.data.status" property or "model.data.parse()" method is HTML. It
isn't, it's JS.
The majority of frameworks were born to provide a solution for a different
problem: object standardisation across platforms. Think about AJAX
standardisation made by jQuery and other frameworks: it was necessary when
there were at least 3 different ways to do a simple XmlHttpRequest.
It's simple as that. If there were a deep wish to find a common platform
for features implementation (this wish is increasing, though), you wouldn't
even need frameworks. You'd still need JS, though, in order to execute XHR,
in a standard, 360°-wide scenario. That standardisation is still unachieved
for JS. So does anybody want to say that JS is not Web for this? Fine, then
get rid of CSS too, as its implementation is far from being uniform.

If you want to lower the barrier to entry in Web design, the right solution
is not to remove complex things. Do you lower grammar standards because it
is too difficult to speak correctly? Do you lower any of your expectations
towards any aspect of life when that aspect becomes too tough? I respect
anybody's effort to make web pages, and I myself am quite new to this. But
each one must do what s/he can do, or learn more things. What is needed for
a better Web is standard. It is a ruleset that can be studied and applied
without thinking "Is this solution compatible with that specific version of
that specific browser?".

A final consideration: as JS is a scripting language, it has to be parsed
and compiled. If it presents errors, it cannot be executed and it stops.
With "HTML6" you are going to deliver a powerful tool to, say, fashion
bloggers and Tumblr users. Is it meant to have an error handling as HTML
has to do in order to cope with old days common errors, or will it have a
strict grammar not allowing mistakes? If the answer is the latter, then
fashion bloggers will still have something to study, eventually.

Delfin, that's verboseness!

2015-04-03 2:16 GMT+02:00 delfin <delfin@segonquart.net>:

>
>
> Hi all:
>
> I see some interesting things and a correc t approach of the MVC model
> -- speaking in terms of theory -- in the original proposal of Bobby.
>
> Let me tell you something funny:
>
>         * I do not see any unconvenient working with <tags>, as bones,
> because
> for, as far as I remember, my firsts experiences in the web were using
> <tag> , a programming language named _Coldfusion_. 1995. Anyone've heard
> of it?
>         * To me , the proposal of Bobby for the HMTL6 spec reminds me
> subtly
> that way of work, perfectly defined then and now as MVC. No kidding.
>         * Later, years later it came ECMAScript, I guess. For this the
> success
> of ActionSCript/flash, ECMaScript based in C and Perl, with a clear
> advantage over the Java plugins and the non-permitted Javascript ( in
> the banking sphere, for example )
>         * We might have in mind that The websites , since few years ago,
> were
> no made by developers, just few developers/programmers. It was the need
> of communication and self-publishing what spread the web. Developers
> were not then neither in its inception. Have a look at the forums and
> silos from 1006 till 2004 and you will agree with me. A professional
> coder is a professional coder.As far as I remember, developers were
> focused on something that in our days days is not really well paid, if
> it still exist, and if it is even get paid (joke). That was Middelware.
> Now the money is in the web. Making grammar for the web to produce
> hipertext. A simple TCP/Ip protocol.
>         * But HTML goes far from this, as we old cows knew. HTML is useful
> in
> the MAIL/SMTP protocol, in the GOPHER protocol as well as in a lot of
> scenarios aside from the HTTP/S/S2 we visit everyday.
>         * With all those protocols in mind, back then, designers ( like the
> future ones Bobby is referring to ) , without being trained developers,
> and coming from a background in the use of Hypercard and Graphical
> computers start to learn to code for the web. The Mosaic (Netscape) now
> dissapeared. After this, it came the need of standards and the oblivion
> of VBScript, JScript, and Tables. As far as I remember, you might buy a
> PowerPC station and you still were recommended to disable the CSS for (
> a lovely declarative-imperative language, that inherits directly from C,
> considered by then an afficionado and non-coder language ) "for a better
> navigation". That was in 2002, I guess.
>         * When I see people coding in a Terminal , I have a flashback as
> if I
> were at secondary school. Of course there is the need to know to code,
> as there is a need to know grammar. The need for this is simple: To use
> properly a language. In our case, the language of the web.
>
> Etcetera. Sorry for the verbose. I see all arguments right , and I
> perceive both side of the positions explained in this mailing list. But
> I do consider realy interesting the approach Bobby has made.
>
> Far more interesting ( appreciating the good use of JSON he explains )
> that keeping alive a lovely language that some of us we have been using
> for more than 15 years.
>
> I look and wait after the ECMAScript6 proposal, but I still have in mind
> there was a web, once where no javascruipt was needed. And it worked
> pretty well.
>
> My apologies for the verbose. Have all a good day.
>
> Regards
>
> ---
>
> Delfi Ramirez
>
> My digital signature [1]
>
> +34 633 589231
>  delfin@segonquart.net [2]
>
> twitter: delfinramirez
>
>  IRC: segonquart Skype: segonquart [3]
>
> http://segonquart.net [4]
>
> http://delfiramirez.info
>  [5]
>
> On 2015-04-02 21:22, Rimantas Liubertas wrote:
>
> > There are fundamental problems with your proposal, namely: 1) it relies
> on some undefined magic I believe that's called "programming".
>
> So that poor fashion designer will have to learn to program after all...
>
> >> 2) it changes HTML to something entirely different.
> > To what? HTML already has things like <SCRIPT> and other features not
> related to hypertext markup.
>
> I don't know to what, I never saw any examples how your MVC would look
> like.
> Would you care to show how something like
> http://backbonejs.org/docs/todos.html [6] would look if
> done your way?
>
> >> 3) you assume that those not willing to learn Javascript will somehow
> know how to use the features you propose without learning. How?
> > They use HTML, which is far more widespread than Javascript.
>
> But they don't do MVC with pure HTML.
>
> > There's a reason this proposal has gone viral outside of this list.
>
> Good luck.
>
> Best regards,
> Rimantas
>
>
>
> Links:
> ------
> [1] http://delfiramirez.info/public/dr_public_key.asc
> [2] mail:%20delfin@segonquart.net
> [3] skype:segonquart
> [4] http://segonquart.net
> [5] http://delfiramirez.info
> [6] http://backbonejs.org/docs/todos.html
>

Received on Friday, 3 April 2015 01:19:11 UTC