
HTML6 proposal for single-page apps without JavaScript - matthewmacleod
https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Mar/0071.html
======
jkoudys
This proposal is trying to take a common web design pattern, MVC, and make it
part of the official spec. HTML is a _markup language_, it's ridiculous to use
it as anything but a semantic language.

Here's my HTML6 proposal: There’s a standard design pattern emerging via
cascading style sheets, where content is styled directly via CSS. Everyone’s
into it because the layout looks so much nicer.

Since this is so common now, can we implement this directly in the browsers
via HTML so users can directly style their content without CSS? I propose
adding a <font> tag, so people can style their fonts, a <blink> tag so things
can blink, and a fun <marquee> tag so content can scroll.

~~~
timepiece
Don't speak ill of people with <font> or <center> infatuation as HN is built
on these tags. At the time of writing this comment, there's around 300 <font>
tags on the page and over 100 <center> ones

So, basically watch what you say buddy :)

~~~
Stormcaller
<font>, I don't think there's an excuse. we know for sure that it is not out
of incompetence but it was probably easier to write at the time and nobody
bothered to fix it because it doesn't really matter.

For the <center>, it is probably not the case here as this is just a text
based site but sometimes it is easier to center an image by that tag when your
site is partitioned in many margins it is not as easy to center some stuff, or
you might just prefer to add a tag.

I also like <br>, it really makes more sense to me and easier to write. It
doesn't really break anything either.

I wonder how many there are, like me, think that <center> and <br> are
actually really nice things to have?

~~~
timepiece
Not many but they're deprecated/obsolete for a reason, don't you think?

~~~
SiVal
br is neither deprecated nor obsolete

~~~
err4nt
HECK YEE! I even put classes in my <br> tags so I can get at them and decide
when and how they display!

------
outsidetheparty
Lots and lots of very bad ideas here -- backwards-incompatibility with
previous versions of HTML is always a good litmus test that a proposal hasn't
been thought through, as is "hey let's restructure everything around this one
currently-fashionable design pattern". (I kind of love how he just casually
embeds a SQL interpreter in the browser, too, that's a nice finishing touch.)

But the main thing is that this doesn't solve any problem that exists. We can
already do everything his proposal would enable; all this does is make it more
inflexible.

~~~
antonpug
+1

~~~
ryannevius
There's an "upvote" button, just to the left of the comment above.

~~~
thomasahle
You shouldn't use the upvote button for agreement.

On the other hand "+1" and "I agree" and "Well said!" clutter the forum.

How do we solve this?

~~~
preek
Honest question: If not for showing agreement, what is the reason for the
upvote button?

~~~
egeozcan
I thought it meant "nice contribution to the conversation". It's easy to come
to this conclusion when you think down-vote means "you're not contributing". I
up-voted many comments I totally disagree and down-voted many I agree (because
they were unrelated to the discussion). Am I a minority?

~~~
preek
Well, the HN guidelines[1] do not mention any rule as what constitutes 'right'
voting criteria. As a regular HN user of over 6 years it feels even surreal to
be in a discussion about the basic features of this wonderful platform. It's
never wrong to question the basic premises of life, though(;

I do believe we have the a similar kind of understanding for when to up-vote.
What is a 'nice contribution to the conversation' other than arguments or
facts that 'I do agree with' in them being a nice contribution to the
conversation.

I fear we would have to have a meta-discussion on the concepts of good and bad
and how they are flawed in that there are no montains without valleys^^

1\.
[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

------
_wmd
I'm not necessarily opposed to something along these lines, except that it's
basically already been tried: XSLT was essentially the inverse of this, where
data endpoints were annotated with some static rendering descriptors. To me
the XSLT approach seems cleaner, in that the URLs the browser is visiting are
for the raw data itself, the URL scheme between machine and human is
identical, and so on. XSLT also encouraged producing network-friendly compound
representations for data, rather than the typical small collection of pure
CRUD endpoints over fixed structures (/users/1, /comments/1231, etc.), since
XSLT had limited ability to trigger loading external data without falling back
to Javascript hacks or similar.

But I imagine the tragic flaw in both the data binding proposal here and how
XSLT worked is massively increased complexity for fairly little gain - and I
think that's why XSLT has died a gentle death over the past decade.

Still, both ideas appeal to me from the perspective of escaping horrendous
chunks of procedural macros being shipped with data just to make it render on
the client.

~~~
outsidetheparty
Yep. I used to _love_ XSLT -- working in it finally forced me to understand
recursion at, like, a deep cellular level -- but the whole time I was using it
I knew it was a doomed language (because most people don't want to have to
understand recursion at a deep cellular level just to be able to lay out a
damn web page.)

~~~
jkoudys
XSLT is still good to learn -- I think it's conceptually sound, but its
implementations are often terrible. I think the big pain points for most
people are how finicky XML is in general, but also that any libs you use to
generate your XML and translate it require an absurd amount of configuration.
Years ago, I saw all the weaknesses in mixed PHP/html for building pages, but
all the server-side templating languages looked terrible (still do). I fell in
love with the idea that was championed back in the late 90s, where you use
your application to build XML, which only describes your data. You'd then have
some XSLT on your web server (or in-browser) that would transform the XML into
your document.

Nowadays, this isn't that different of an approach from using my server-side
PHP/python/node/Go to generate JSON, then building my DOM based on client-side
templates; since I use ReactJS, my transforms are even still XML. A lot of the
best-practices I learned from XSLT transferred over nicely too, e.g. avoiding
control logic (<xsl:if>) in favour of <xsl:apply-templates>, since good
javascript client-side templates should avoid branching control logic in
favour of just Array.prototype.map() wherever you can.

I think the real key isn't about understanding recursion, though you will
gradually gain an appreciation for it, but understanding composition.
Templating is too often done in the style common among poor developers, where
they think about building a whole "page", instead of defining the components
of that page. XSLT, in theory, would've been great for that, it's just a pain
in the butt to actually implement.

tl;dr if there is a need for this proposal, it would be better met by cleaning
out all the cruft from XSLT, and building implementations that don't require
such arcane syntax nobody can use it.

~~~
T-hawk
XSLT is conceptually sound indeed, a transformation of tree structures. But
the _requirements_ and _real-world usage cases_ thrown at it are often
terribly suited for it.

Real applications just don't fall neatly into tree transformations. I
inherited a financial reporting web app using XSLT as the rendering mechanism.
Requirements included things like running totals (state!), suppressing leading
values when repeated between rows (also state), alternating row colors,
external dependencies such as numeric formatting based on user's locale
settings. A stateless tree transformation doesn't express that elegantly, so
you end up with fantastically complicated and ugly XPath hacks. A running
total would come from something like "sum all my parent's children with an
index less than mine". Then that breaks when something comes up to introduce a
need for another layer beneath that parent.

XSLT is purely functional. <xsl:if>template</xsl:if> isn't even control logic,
it is functional evaluation, the same as Lisp's (if x template nil). <xsl:for-
each> also isn't an imperative loop (it's map) even though it looks imperative
and most enterprise programmers trained on imperative languages think it is
and use it as such. So it's no surprise that XSLT in the wild ends up as a
messy ball of mud.

Most templating languages have this problem, including PHP/HTML. The messy
nature of real requirements isn't unique to XSLT. But XSLT manifests it most
dramatically since it lacks a stateful and imperative framework to fall back
on.

~~~
spdustin
Just in case you're using XSL still, you could use <xsl:key/> to let you
quickly do subtotals by summing the node set of items that match whatever
grouping level you're on when you emit the last item in the group.

    
    
      <xsl:key name="items-by-order" match="item" use="../@orderid"/>
    
      ...snip...
    
      <!-- Union current item node with last item node of the order - if it's the same, the count will be one -->
      <xsl:if test="count(. | key('items-by-order', ../@orderid)[last()]) = 1">
        <xsl:value-of select="sum(key('items-by-order', ../@orderid))"/>
      </xsl:if>
    

Running totals would be similar, except that your apply-templates for the item
group would include a select that restricts the available nodes to the key()
function's result, and you would sum current node with preceding nodes.

------
jerf
The use of XMLHttpRequest to fetch JSON has come to dominate to the point that
people seem to forget that it had any other use, but it is worth occasionally
reminding people that the _original_ purpose was to fetch HTML, which the
browser turned into DOM nodes via its fast parsing path, which could then be
added to the page via DOM manipulation.

I fully realize this is not what the linked page is proposing, but it is not
clear to me that using that wouldn't be a better idea, leaving the selection
of templating to the user. Template languages, while smaller than programming
languages, share their characteristic that there isn't obvious One Solution
That Solves Everything. You can optimize them for different use cases and it
is not clear to me that we can or should privilege one over the others. Given
how rapidly the web is heading _away_ from an overprivileged programming
language being the only choice, this seems like going the wrong direction.

(Also, if your template language is slowing your server down, fix that. That's
a problem with your implementation language, not the fundamental concept.)

~~~
TazeTSchnitzel
Uh, the original purpose of XMLHttpRequest was to fetch _XML_ , as its name
implies.

AJAX stands for Asynchronous JavaScript And _XML_

~~~
jerf
I'm not able to substantiate this with links, but I believe the idea was that
the "XML" in question was going to be XHTML most likely, rather than generic
"XML", though it did support the generic XML use case. I could be wrong, if
the original Outlook web interface this was supported for really did return
XML that was not XHTML at some point.

It was a crazy time. XHTML was still "inevitable", and people were pretty
sloppy with the terms.

~~~
frik
Wrong.

It was called "XMLHTTP", created by Microsoft for Outlook Web Access 2000.
Mozilla implemented it as XMLHttpRequest JavaScript object in Gecko.

The main reason of XHR/AJAX was XML, but Text and HTML are supported too.

See Wikipedia for the correct history:

[http://en.wikipedia.org/wiki/XMLHttpRequest](http://en.wikipedia.org/wiki/XMLHttpRequest)

Microsoft never implemented the XHTML standards in Internet Explorer. IE
cannot open files with .xhtml file extension and with .htm(l) extension the
page is rendered with HTML quirksmode.

~~~
tmzt
Any idea what the MSDN tree view used in the 1998 timeframe? I know it loaded
the contents on demand when you expand3d a node and I remember it doing so
using an automation object with CreateObject.

~~~
frik
MSDN used HTML4 frames for a long time (afaik until ca. 2006). The left side
bar (left frame) with the tree was a Java applet and with the relauch in 2000
a DHTML page. The tree was expanded using DHTML (a marketing term that
describes HTML with heavy Javascript usage). Javascript was used to change the
visibility of DOM nodes (tree). That data of the TOC tree was loaded as XML
(XMLHTTP).

Article that explains the MSDN server backend (1999):
[https://web.archive.org/web/19990505061257/http://msdn.micro...](https://web.archive.org/web/19990505061257/http://msdn.microsoft.com/msdn-
online/MSDNchronicles.asp)

Before that relaunch in 2000, the MSDN library used (MS) Java for the left
side bar (TOC tree):
[https://web.archive.org/web/19990423231040/http://msdn.micro...](https://web.archive.org/web/19990423231040/http://msdn.microsoft.com/library/default.htm)

The DHTML version of MSN library (2000):
[https://web.archive.org/web/20000510200809/http://msdn.micro...](https://web.archive.org/web/20000510200809/http://msdn.microsoft.com/library/default.asp)
, the 2001 version works:
[https://web.archive.org/web/20011108064645/http://msdn.micro...](https://web.archive.org/web/20011108064645/http://msdn.microsoft.com/library/default.asp)

XML toc tree data:
[https://web.archive.org/web/*/http://msdn.microsoft.com/libr...](https://web.archive.org/web/*/http://msdn.microsoft.com/library/msdn-
online/shared/xmltoc/inc/toc.inc) (sadly not archived)

------
agumonkey
Other members are worried this is just shifting complexity for no real value.
A mistake they did in the past.

[https://lists.w3.org/Archives/Public/public-whatwg-
archive/2...](https://lists.w3.org/Archives/Public/public-whatwg-
archive/2015Mar/0073.html)

My opinion too.

------
copsarebastards
These single-page apps are becoming pervasive but they are also fundamentally
breaking the internet. Here are some common ways in which they are broken:

1\. History is screwed up. You wanted a back button that took you back to the
content you were looking at? Sucks to be you. The content you were looking at
was dynamically loaded after ten different buttons you clicked, and now that
the page is loaded fresh those button clicks are gone. Good luck finding it
again. This especially goes for any of those infinite scroll websites: those
should die.

2\. Tabs don't work. Hey this link looks interesting, I'll open it in a new
tab to look at later. Oh wait that was actually a JavaScript link and what
often ends up happening is you end up with a blank page, or the same one page
app loaded with it's initial content.

3\. Save page doesn't work. You can save the page and pull it up and
everything works because the JavaScript fetches the content. But there's one
problem: I was saving that page to view on the bus where I have spotty
internet if any. Sucks to be me.

4\. Accessibility is broken. Oh, you're blind? Arthritic and have trouble
using a mouse? Well, sorry, we had to size things in a certain way to make the
animations work and tab order was too hard to get working, so I guess you
can't use my website. Sucks to be you!

5\. Security is broken. If you app loads content from a server that isn't
yours, you can no longer verify security.

There are solutions to all of these problems but they're very difficult and
90% of one page apps don't solve these problems because they don't care.

I'm not against one page apps on principal, but a one page app standard that
doesn't address these concerns is only going to make them worse. Unless we can
solve these issues I'm against any one page app standard.

~~~
nilliams
I agree with you in principle that if apps don't meet 1, 2, 4 & 5 they
shouldn't see light of day but I think your points are largely spurious or
handled by any semi-competent dev.

1 & 2 are a basic feature of JS MVC frameworks. I get that some people still
probably mess this up, but there's no excuse to do so at this point. 3\.
Irrelevant/FUD? No normal user 'saves' web-pages, unless it's something like a
receipt, which any sane dev would make a separate html page and not part of
the app. 4\. is totally false as screen-readers support JavaScript. 5\. is
false/strawman as any half-sane SPA developer still authenticates using a
regular back-end framework and I've no idea what 'If you app loads content
from a server that isn't yours' has to do with single-page apps.

~~~
copsarebastards
> 1 & 2 are a basic feature of JS MVC frameworks. I get that some people still
> probably mess this up, but there's no excuse to do so at this point.

I'm not sure what it would even mean for this to not be broken in a one-page
app. If you're displaying more than one conceptually grouped set of content on
one page, you're breaking the web's concept of a page: a page is one
conceptually grouped set of content. JS MVC frameworks allow you to back and
forward between "pages" within a page using the hashed href trick, but they
can't keep your scroll location without rendering the page to determine
layout, unless there's some magic I'm not aware of.

> 3\. Irrelevant/FUD? No normal user 'saves' web-pages, unless it's something
> like a receipt, which any sane dev would make a separate html page and not
> part of the app.

I love when people tell me that nobody does what I do all the time. And it's
not just me: a lot of people save pages for later reading, especially in
academia.

> 4\. is totally false as screen-readers support JavaScript.

Yes, screen readers support JavaScript, but JavaScript rarely supports screen
readers. It's clear you've never actually attempted to browse the web using a
screen reader.

> 5\. is false/strawman as any half-sane SPA developer still authenticates
> using a regular back-end framework and I've no idea what 'If you app loads
> content from a server that isn't yours' has to do with single-page apps.

JavaScript security is a fucking joke. I'm not sure what you think
authentication does when your JavaScript is running in the same namespace as
all the other JavaScript in a page and malicious code needs simply to tell
authenticated code what to do to spoof an identity. A server can do nothing to
provide security when the requests from a browser are coming from an
authenticated user (but are actually made by malicious JavaScript in the
page).

Plenty of apps include advertisements from arbitrary sources, hence loading
content from a server that isn't yours.

------
romaniv
Honestly, looks too complicated. I'm doing AJAX without custom JavaScript
right now. The way it looks:

<form action="x" replace="#y"> <!-- .. --> </form>

<div id="y" />

You submit the form, it loads the result in the background and replaces
content of Y div with content of whatever has id="y" on the new page.

splice-result-into takes any CSS selector as its parameter, so you can apply
this to multiple elements at once.

The entire library is around 100 lines of code with no dependencies. 100%
backwards compatible, degradable and easy to add to existing multipage apps.
It could easily be implemented as a standard HTML feature.

------
antonpug
This is why you don't let "Editor-In-Chief" do web development. Sounds to me
like someone's too lazy to learn JavaScript. When will people stop trying to
make HTML into an all-in-one product? It was built to be simple, to provide
markup and that's it. That's the magic behind the troika of HTML-JS-CSS. They
all deal with individual, meaningful functions to make a site work. Blending
function with markup is just bad coding. Thumbs down.

------
lollipop26
Have seen several tries on this approach:

\- Angular seems to provide something similar already with its ng-* attributes
and directives.

\- JavaServer Faces also do the same thing, where a server-side controller is
bound to HTML or UI widgets (and skip writing CSS and JS because they're pre-
styled, pre-programmed).

This works for simple stuff, but for much more complex stuff (multiple view
interactions, custom views), this becomes a pain to write because you start to
create workarounds for things it wasn't prepared to do.

Also, while I'm no expert, but let's just leave HTML, CSS and JS as is. You
can always create a framework that provides you that same functionality. In
fact, Angular has directives, React has JSX, Ember has components. Several
other frameworks do it as well.

Reminds me of E4X, where they tried to bake in XML syntax into JS. This time,
it's behavior and logic into the markup. Nope.

------
cjfont
“<A href="sql:select from *”>"

An anti-pattern if I've ever seen one.

~~~
yc1010
Yeh my thought when I seen that was "...what could possibly go wrong..."

------
RandomBK
I really don't like this proposal. For me, HTML is the markup for the design
of the page, while JavaScript makes up the logic. While some frameworks break
this, they are strictly opt-in, and they still offer a bit of separation of
duties. I'd rather see the HTML standard stay markup-focus for now.

~~~
Someone1234
I wish strict XHTML was taken more seriously.

HTML is the structure, CSS is the look, and JavaScript is the logic. With a
strict XHTML style you can further enforce this by removing former standards
which don't follow that design (e.g. OnClick="" <b> <i> <font> etc).

HTML5 is alright, but I'd like to see a strict HTML5 which bans a ton of
classic HTML4.1 elements completely and also follows XHTML's much more logical
<br /> style (and bans things like <br> which make no sense).

I understand why they went the way they did (backwards compatibility mostly),
but feel like the web would be in a better place ten years from now if a
strict spec for at least HTML was commonly used.

~~~
TazeTSchnitzel
Strictness accomplishes nothing whatsoever. If you remove presentational
elements, people just abuse semantic elements.

~~~
astine
I would make parsers and generators much easier to write.

~~~
emodendroket
But there are millions of pages that will never be updated and if a browser
can't render them people are going to blame the browser, not the use of
deprecated HTML elements (an issue they won't even have awareness of).

~~~
Someone1234
That's just a generic argument for no new HTML ever.

~~~
emodendroket
No it isn't; it's an argument against breaking changes.

------
ender7
I don't want to be flippant here, but anyone who thinks you can build a high-
quality UI with a solely declarative system hasn't built very many UIs.

------
bananaoomarang
This is interesting, but like others I think HTML should be kept strictly for
templating, and this adds an unnecessary amount of logic. It might be tempting
to see this as _removing_ complication, but in actuality it will probably
_add_ to it by reducing separation of concerns.

I think it would be good for less ambitious projects, but in the end it would
cripple the building of more ambitious ones. If we already have
Angular/React/Components/Whatever, shouldn't we just keep working on them and
leave the HTML spec unpolluted?

~~~
moron4hire
HTML does not do templating, either.

~~~
pfooti
I'm just going to leave this here:

[https://html.spec.whatwg.org/multipage/scripting.html#the-
te...](https://html.spec.whatwg.org/multipage/scripting.html#the-template-
element)

~~~
path411
That's really just an alias'd script tag. You are still using javascript to
actually do the templating.

------
kowdermeister
Too bad, this is already implemented as a standard (cough-cough Mozilla) as
part of Web Components.

[http://www.html5rocks.com/en/tutorials/webcomponents/imports...](http://www.html5rocks.com/en/tutorials/webcomponents/imports/)

Reading the comments I felt many people thought this is an official
recommendation. It's the mailing list folks, the same place where somebody
suggested to replace JavaScript with AS3 because it would solve every problem
of mankind.

~~~
drinchev
That was my initial thought. Also you can basically declare any custom tags (
with dash in the name [1] ). Which with some good javascript could accomplish
easily ( and I would say in more clean way ) what it's being offered by the
OP.

If he likes this kind of writing his AJAX implementation he can easily do so
by doing his own framework.

I think HTML5 is doing pretty, pretty good and it's underestimated in what it
can be achieved.

[1]
[http://www.html5rocks.com/en/tutorials/webcomponents/custome...](http://www.html5rocks.com/en/tutorials/webcomponents/customelements/)

------
Cshelton
Instead, why don't we eliminate the need for Apps in a browser to require
HTML. Right now, our large scale app has one div inside the <body>. It's just
an anchor for our SPA built in React js. We should push for browsers that can
launch from a .js file, rather than requiring html. Have a base UI.kit that
can even keep css, or use javascript to stylize. I'd like the 'base' UI to be
as skeleton and simple as possible. We can keep the <html> style markup, but
with javascript first. Similar to what JSX does with React. This would also
fix the DOM problem we are currently stuck with. This is a rough, quick
typeup, thoughts though?

EDIT: and most importantly, get multi-threaded javascrip in the browser.
Running the UI, events, and logic all on separate threads. Many observe
patterns would most likely be used.

~~~
Touche
> Instead, why don't we eliminate the need for Apps in a browser to require
> HTML.

Accessibility.

~~~
Cshelton
Touche, love the user name. Yes, right now it would seem impossible and
browsers would have to support backwards compatibility. What I'm saying is let
browsers still support regular html sites. In addition though, be able to
specify a 'javascript app'. I see no limiting reason in modern browsers why
this would be an issue. At some point, the web has to move forward and say,
'sorry, if you are not running JS, we can't really support you'. Yes, I know
the backlash that would come, but we've got to move forward, maybe there is a
better way? I'm not sure.

(My project does not require supporting anything below IE 11, it's the
greatest blessing, ever.)

------
madoublet
Single page apps seem like a hack to make browser apps feel like they are
closer to native apps. Because most SPAs have a set flow, it seems like we
should be able to use prefetching to tell the browser what is most likely to
happen next. For example, if you are on a list, then you can tell the browser
to prefetch the details.

<link rel="next" href="details.html">

What I feel like is missing from this equation is a nice transition between
pages. How nice would it be to have something like this:

<a href="details.html" transition="slide-left">Details</a>

If the browser prefetched the details and handled the transition, I would see
no need for an SPA. We would get the benefits without having to implement a
hack.

~~~
Touche
So if you have a list of 100 links you are going to prefetch all 100?

~~~
madoublet
No, that is not really the use of prefetch. It is for more predictable flows.

------
pothibo
> Everyone’s into it because the responsiveness is so much better than loading
> a full page - 10-50ms with a clean API load vs. 300-1500ms for a full HTML
> page load.

Maybe if you start with an argument to support your claim, you want to have
actual numbers. And those _real numbers_ would tell a different story.

------
arenaninja
Great, now I need 3 years experience in it by the end of the month

~~~
Roboprog
No kidding. I just started learning Angular, and now this.

Fortunately, it sounds like it will die an unpopular death.

------
thomasfoster96
I see three problem here, none of which have anything to do with HTML as a
markup language.

1\. The amount of DOM manipulation required for a relatively advanced single
page app is not very efficient, quick or performant.

2\. Web apps don't work well without a reasonably up to date javascript engine
- users may not even allow Javasacript to be run. This breaks alot of web
apps.

3\. There isn't an (easy) way to request parts of a resource easily using
HTTP.

Luckily these issues have solutions:

1\. Invest time in a new successor or radical improvement over the current DOM
- think an asynchronous, thread safe API. Fix things that deal with HTML,
don't try and make HTML anything more than a markup language.

2\. Either make your web apps fallback to HTML + CSS or start convincing
people that using Javascript isn't a huge privacy issue. Fallbacks can be easy
if you want them to be.

3\. I'm sure there are way to request specific parts of a page (indeed, I
coded such a way myself in PHP a few years ago), but someone needs to build an
awesome abstraction over HTTP to make this easier.

~~~
emodendroket
> Either make your web apps fallback to HTML + CSS

So make two Web apps with the same functionality, basically?

~~~
insin
Or make one app with an isomorphic base which gets progressively enhanced when
JavaScript runs on the client.

~~~
emodendroket
Yes, but if you're doing a true "SPA" then "progressive enhancement" really
does just mean having two versions of everything.

~~~
insin
Not any more - once you can prerender the "SPA" on the server and use the same
codebase to rehydrate it on the client and take over - which you can do today
with React and soon with Ember - then with the right setup the "progressive
enhancement" bit can be "am I on the client now? let's do some extra stuff"
implemented as part of the same component.

e.g. here's a form that uses the same React component to render on the server,
to handle regular form submissions and render redisplay when invalid and to
progressively enhance with live validation and ajax form submission when
JavaScript is available on the client: [https://isomorphic-
lab.herokuapp.com/add-thing](https://isomorphic-lab.herokuapp.com/add-thing)

------
daemonk
I think we should keep HTML simple and enforce a strict separation between
template and logic. However, I do like the idea of adding a native "model"
attribute to the DOM element that can automatically get/parse json and update
accordingly.

~~~
smt88
Have you ever used React? What do you think about the React/Flux methods of
mixing template and logic?

~~~
daemonk
Good point. I do use react and I find jsx to be very convenient. I guess the
question is: would I want to write something similar to JSX and have the
browser be able to interpret that natively. I honestly don't know.

~~~
smt88
Yeah, I'm ambivalent myself.

The main problem with W3 standards is that they assumed they knew what we'd
want to do with them. No one predicted HTML would become the UI layer for
complex replacements for desktop applications, so for a long time, it sucked
at that job.

Now they're trying to rectify those mistakes, but I think they might be going
too far in the other direction.

Instead, web standards need to be as simple, low-level, and generic as
possible. The more HTML approaches an opinionated UI framework, the worse off
we all are (in my opinion).

------
xsace
_Model references are defined so that it can call any object, with the ability
to define conditions to access objects, perhaps looping through lists of
objects via SQL select statements and using TEMPLATE tags to create new DOM
objects._

What - the - fuck

------
simi_
As someone who thinks about making a HTML/CSS/JS replacement at some point in
the future, I look forward to these guys completely fucking up the standard.

------
asimpletune
I'm pretty sure this is similar to meteor js and transparent reactive
programming, except just getting rid of the templates and using html instead.
I don't think he realizes it that way, bc he keeps mentioning wanting to not
have to use js.

I would be down to have a nice standard way of providing templates , adding
onto html thus keeping it backwards compatible but that's it.

what he's proposing could be could be backwards compatible

------
deitcher
I don't like this. I would like to see a standardized html way to load html
partials into other html, similar to ng-include. I think that is clean. But to
start mixing logic? How are you supposed to render a JSON array loaded via
ajax? How do you put in authentication information or headers? How do you do
error handling? This is the stuff that is handled by angular or ember or
knockout or aurelia or etc.

------
tinganho
I definitely don't like this proposal. SPA:s is under a heavily innovative
period. Standardizing it will only slow downs its' development.

~~~
iso8859-1
No one will force you to use it, browsers have always been reasonably
backwards compatible, except regarding stuff like ActiveX, applets, and HSTS.

------
phkahler
I always thought XSLT has some SQL-like capabilities and I have always been
angry that one can't simply pass a parameter to the interpreter via link. The
idea being that menus could become active just by having links specify an item
selected when they are clicked on and reload the same page. It's one little
tiny thing (passing the parameter) that could make dynamic static pages.

------
baby
I'm very skeptical about this. HTML is a fixed language for reasons. It is not
supposed to be able to parse a JSON file.

------
jalfresi
Am I mistaken, but this kinda looks like XForms. Why not just use XForms?

Edit: Obviously I understand that XForms isn't a viable option these days, but
that is kinda my point. Why isn't XForms an option? Those reasons appear to
apply to this proposal too...

~~~
pjmlp
Because XHTML was killed, when it could have become the XAML of the web, so
the circle comes back to "another day another hack".

------
picks_at_nits
“All DSLs grow in complexity until they are Turing-Complete, then JWZ’s Law
takes over.”

------
jeeyoungk
There are some dangerous thoughts in this thread, for example:
[https://lists.w3.org/Archives/Public/public-whatwg-
archive/2...](https://lists.w3.org/Archives/Public/public-whatwg-
archive/2015Mar/0079.html)

"These javascript frameworks are all trying to do this, but none of them do it
easily and they’re always being redesigned."

Things are being redesigned because there are flaws and limitations. Making
something, and stamping it as "HTML6" doesn't automatically make it perfect.
It would simply hinder the development further.

------
nishantrana
Yes we have to make the html and css more dynamic for single page application
because it will take less time and single handed coded by the developers. So
in this time we have to use frameworks that have some additional features that
we dont use in our website or application we use some of them which is really
suit to our need and there are lots of browser having compatibility issues if
html and css become more dynamic and independent the compatibility issue will
be solve and we dont need for extra time for using plugins and make them for
our needs.

------
aikah
What happened to web components ? isn't supposed to solve these issues ?

~~~
Svenstaro
I wonder the same. Isn't that the quasi standard way of doing this?

------
namuol
What is this moonspeak?

Modern web apps do _so much more_ than what this proposal is trying to solve.

React + Relay/GraphQL is much more likely to be the next real big step forward
on the horizon of web/app development.

------
k_sze
Technically, I don't think it would be very useful except for apps that are
simple state machines. If you want something Turing-complete, you might as
well stick to JavaScript.

------
AngryAntlion
Has anyone looked at the source of his site? www.futureclaw.com

~~~
frik
The worst site I saw in 2015, it's broken in IE11 and Firefox.

Or are all the double and triple scrollbars intentional? And the code, the
"Editor-In-Chief" seem to be stuck the 1990s, with all CAPS HTML tags and HTML
2 style code.

------
Yuioup
HTML is like violence. If it doesn't work, use more.

------
liuyanghejerry
It is pretty funny these years, cause app(qml, for example) really wants to be
web, and web(single-page-app-like web) really wants to be app.

------
sumitgt
I'm sure no one wants to go down this path.

Why mess with the amazing separation of concern that exists between HTML,
JavaScript and CSS.

------
davesque
Don't agree with this. I think improving Javascript's API for the DOM is a
much better path forward.

------
sebastianconcpt
A naive attempt to do the same we do now just waaaaaaay more inflexibly.

The author needs to watch this a meditate on why Alan Kay said what he said
about the web architecture:
[http://youtu.be/oKg1hTOQXoY](http://youtu.be/oKg1hTOQXoY)

------
lobo_tuerto
It seems it is the same idea behind Polymer's core-ajax, what do you think?

[https://www.polymer-project.org/0.5/docs/elements/core-
ajax....](https://www.polymer-project.org/0.5/docs/elements/core-ajax.html)

------
adambrod
One of HTML's largest flaws is speed. Can't we work on making the DOM faster?

~~~
Someone1234
HTML's DOM isn't slow, it is the CSS which makes it slow. When you manipulate
the DOM the vast majority of the time spent regenerating it is in CSS, the raw
node tree itself is fairly cheap.

------
33a
Thankfully this looks like it is never gonna happen, and is instead just a
random suggestion posted to a newsgroup (which carries very little
weight/credibility).

In my judgment this feature is highly redundant and unnecessarily complicated.

------
evvvvr
Among all the other reasons why this is bad, i think that guy never had heard
about different environments (production, staging etc.) API URL's in mark-up,
yeah

------
lovamova
Why not DOM streaming or lazy DOM? We don’t need HTML6.

------
jkot
Nice, now it only needs some scripting language. I am sure you could invite
something in a few days....

WTF?? Please please, just start over!

------
itsbits
Its not completely to replace Javascript but basically a standard to load HTML
like iframes except its not.

------
miralabs
spa apps are more complex that the example. Sure it looks it could work but
the amount of logic within an SPA is not just a simple click here , fetch json
, replace html fragment. The title is a bit misleading. I don't think it's
possible to do SPA without Javascript.

------
windar
This must be a joke. Why force a design pattern on anyone who wants to create
an SPA?

------
doczoidberg
I don't like this proposal. An SPA is more than just getting json from a
server.

------
ape4
As for a name... Single-Page Apps Without JavaScript = SPAWJS. Or just SPAWS.

------
Dirlewanger
Never too early to start work on something we'll see in a couple decades.

------
hias
so...iframes?

~~~
CraneWorm
... except instead of loading arbitrary url he actually proposes some
structure. This could work for most websites depending on ajax to load their
content. Say, instead of xml you get a language similar to django templates.

------
wantab
Too many new people creating web pages these days ignore the science behind it
all.

