
HTML is done - AndrewDucker
https://www.tbray.org/ongoing/When/201x/2015/06/05/End-of-HTML
======
crimsonalucard
On the backend the developer chooses his universe. Whether it'd be ruby,
python, mongo, postgresql, nodejs, haskell, go, whatever. If the universe
sucks people can change everything. If you hate the mopho stack (mongo and
php), that's ok, you got other options.

With the browser everyone is stuck with one universe. The only thing that
changes are front end frameworks which offer some flexibility. Still, if html
sucks we're stuck with it. If you hate html or javascript then you hate the
entire front end. You exist outside of that universe because Nothing can
change it. End of story.

I don't know how it could be done while keeping things secure, but it would be
awesome if the browser universe was as flexible as the backend. If I could
swap between html and any other kind of media based declarative language as
easily as I can swap between python and ruby on the backend, it would change
the face of frontend development and make it more accessible. In fact what if
I wanted to develop my own language that interfaces with the rendering engine?
The browser should permit that, because the Web is too broad to be dominated
by a single language(HTML).

I think this should be the next step.

~~~
isaiahg
What would be really nice is something similar to .Net's virtual machine CLR.
It would offer the flexibility to design in whatever language you want and
possibly a performance boost as well.

~~~
sparkie
The CLR isn't really very flexible. Most languages that run on it are pretty
similar. If you try to implement a language like Haskell on top of it for
example, it quickly becomes obvious that it isn't a good fit - because the CLR
has no support for higher kinds, typeclasses, laziness, parametric
polymorphism etc. Sure, you can implement a Haskell interpreter/compiler that
converts to .NET, but there certainly won't be any performance boost by boxing
everything into objects and having several layers of indirection to simply
invoke a function (and not really any advantage over writing such interpreter
in say, JS).

A more ideal VM would be one which doesn't force a particular paradigm on you,
but just abstracts over the CPU, using capabilities to restrict which
instructions can be invoked. The CLR lacks such capabilities. Perhaps
something like SafeHaskell would be in the right direction, where side-effects
are limited, and the user can optionally allow websites to invoke trusted
modules.

~~~
jaen
A low-level safe VM? That exists with PNaCl (Portable Native Client), which of
course everybody dislikes as a web technology.

------
founderling
Would be nice to see some examples of what people don't like about
HTML+CSS+JS. I find it quite wonderful.

You can make all kinds of magic happen in a simple text file. In an intuitive
way. Want to tell something? Just write it:

    
    
        This is some text. How easy was that?
    

Want to show an image? Just a few keystrokes:

    
    
        <img id=animal src="my_kitten.jpg">
    

Want to style it? Here we go:

    
    
        <style>.animal { border: 5px solid green }</style>
    

Want to change it programmatically? Easy:

    
    
        <script>document.getElementById("animal").src="my_dog.jpg"</script>
    

Deployment? Instantly. Developer tools needed? A text editor. Compatibility?
Runs everywhere. Speed? Im often shocked, how fast stuff runs these days.

I think we created a paradise. And I enjoy "living" in it every day.

~~~
crimsonalucard
What if I want to use html+css+js to dynamically draw a 1024x1024 picture of a
cat with pixel level detail? I'm sure it can be done. But wow. That code would
be ugly.

Or how about dynamically drawing a diagonal line or swirl across the page?

I apologize for the lack of an example, but I'm sure you can imagine how much
harder that would be in html and css then it is with a renderer that has
bezier curves and lines as primitives.

~~~
founderling

        What if I want to use html+css+js to
        dynamically draw a 1024x1024 picture of a cat
    

Here is your cat:

[http://upload.wikimedia.org/wikipedia/commons/f/fd/Ghostscri...](http://upload.wikimedia.org/wikipedia/commons/f/fd/Ghostscript_Tiger.svg)

    
    
        a renderer that has bezier curves and lines
    

SVG is part of the HTML standard and has those. And much more:

[http://www.google.com/search?q=svg+examples](http://www.google.com/search?q=svg+examples)

~~~
crimsonalucard
I said pixel level. That's vector level. Also by html+css+javascript I thought
you meant strictly primitives within that domain like spans and divs. While
svg is part of html5 people typically don't think of svg when someone says to
write something in html+css+javascript.

Either way, well played, sir.

------
Udo
The point of the article seems to be that HTML is done because it's "basically
OK", and everything around it is done because it's awful and can't be salvaged
anyway. I _hope_ the next logical step implied here after this is NOT going
back to native applications for everything.

    
    
      The browser-as-a-platform is based on a lousy pro­gram­ming 
      lan­guage ad­dress­ing a lousy ob­ject mod­el and us­ing a lousy 
      stylesheet lan­guage for vi­su­al­s.
    

I think JavaScript is a suboptimal programming language because it has too
many features, and on top of that they tacked on yet more features recently. I
wouldn't call CSS lousy either, and the API of the DOM even got better over
the years.

We almost never phase anything out, and that's a problem, but I think the core
issue causing suckage within the 3 pillars (4 if you count the DOM separately)
is that they have been explicitly designed to not work together very well.
While you can - and often are forced to - extend CSS and HTML with JavaScript,
they didn't make the interplay between them especially synergistic.

As for

    
    
      HTML? Not per­fec­t, but plen­ty good enough.
    

no, I don't think so, especially if we're discarding JS and CSS as garbage,
HTML does not deserve to get a free pass.

    
    
      Even if we want­ed to im­prove it, there are no ob­vi­ous can­di­dates to do the work.
    

I don't get why we're all of a sudden in an arbitrarily constructed situation
where the whole web platform can never be iterated on again. Ever. But if the
point is that whatever comes next probably won't come out of a committee that
sounds about right.

I agree that _some_ of the frameworks mentioned exist to work around the
issues we created in the browser platform. Especially the functionality of
React should be considered for an adoption scenario, maybe not the exact React
API, but something along those lines that makes working on (or at least
applying) diffs easier. The same goes for handlebars-like templating. I would
rather see some of these adopted than the effort that goes into giving classes
to JavaScript.

~~~
coldtea
> _I think JavaScript is a suboptimal programming language because it has too
> many features, and on top of that they tacked on yet more features
> recently._

No, that's not what makes a programming language "suboptimal".

(In fact following this logic to the inverse would make something like
Brainfuck the optimal language).

It's not the number of features that makes a language problematic (of which
Javascript, even ES7, doesn't have more than Python or Ruby do, and those are
considered quite OK languages).

It's suitability to the task (e.g. you wouldn't want to use Fortran for text
processing), how well the features play together (you don't want conflicting
behaviors and edge cases a la C++), expressibility, aesthetics, coherence (and
of course, tooling, speed, ubiquitness, etc).

> _I wouldn 't call CSS lousy either_

But CSS is lousy. It was overdesigned in parts nobody cares about,
underdesigned where it would matter, an ad-hoc model for styling, and even
mis-named, as it not only styles, it also layouts. And in that area it has
been horrible, failing for decades to provide the most basic blocks to build
layouts, and having people use hacks like "floats" to do so.

~~~
Udo
_> (In fact following this logic to the inverse would make something like
Brainfuck the optimal language)._

You can reduce any argument to an absurd extreme. It's fair and fine to
disagree with every single opinion I express, but I don't recognize your
impression of that particular point as something I wrote.

My point was, and I'm sorry if I failed to get this across, that in my opinion
there are bad parts in JS which could have been stripped away, making it
better for an admittedly arbitrary as-defined-by-Udo's-mood-today value of
"better".

Every single thing about this discussion, including the original article, is a
matter of opinion. I agree with much of what you said about CSS and the need
for a language to fit a purpose, and I don't want you to get the impression
that I'm trying to say everything about HTML/CSS/JS is awesome.

~~~
coldtea
> _You can reduce any argument to an absurd extreme. It 's fair and fine to
> disagree with every single opinion I express, but I don't recognize your
> impression of that particular point as something I wrote._

You're right on this.

On my end though, I accept the other extreme of what I said: a language can
have the most features any other language has times two, and still be great.

That is, number of features is not really relevant as to whether a language is
good or not.

People seem to think for example "oh, adding this and that would make Java too
complicated and too hard to learn etc". At the same time nobody complaints
against C# who has twice the number of features or even more. In fact most
people find programming in C# is a joy compared to Java.

------
jnbiche
I lean toward languages with static typing for application development, but
now that there is ES6 and typed arrays, JavaScript is a pretty nice language
to program in. And there are a number of very powerful APIs available to
browser JS that many people still aren't aware of/don't use to their full
potential: WebRTC, Web Audio, WebGL, Transferable Objects in Web Workers, and
so forth.

I've now stopped using jQuery for DOM manipulations, and use plain JavaScript
in most cases involving simple manipulations (I do use React for complex
applications).

CSS has some problems that grid and Flexbox should help alleviate.

But all in all, I'd say the Web is in a pretty good state.

~~~
hliyan
I agree. As a C++ developer of ten years (before switching two years back),
trust me when I say: JavaScript is not a bad language at all. Six years ago I
used to laugh at the language. It has come a _long_ way since then (or I've
learned more). So much so, it is now my favorite language.

As a side note: do try to _not_ convert JavaScript into a static language --
there are certain types of boilerplate/generated code that I could never
eliminate with C++ due to static typing. With JS, it was a breeze.

~~~
innguest
Unsurprisingly, from the point of view of a C++ programmer, JS doesn't look
bad at all.

~~~
zerr
That's not generally true. Another C++ dev here. I wish Dart had more
success... If I were forced today (to do front-end) at least it should be
TypeScript.

------
peterashford
The basic problem can be described quite simply. HTML was designed for the
World Wide Web - a matrix of hyperlinked documents. For that purpose it more
or less has succeeded (some people were more ambitious about what authoring
hypertext should have achieved but I'll ignore that wrinkle). However, these
days people want to do things with the web other than write hypertext -
they're wanting applications on the web in just the same way we want
applications on our computers or apps on our phones. And for THAT purpose,
HTML / CSS / DOM is utter gobshite. If I want to write an application, the
bottom of layer of that shouldn't be "now convert that into something that
perverts document layout of the browser to look like something that hasn't
been laid out like an HTML document".

We need a technology that is suitable as a compilation target: a virtual
machine. It can be optimised to hell (better than JS which necessarily is
always compromised by having to be JavaScript and not byte code) and we need a
suite of basic machine systems - sound, graphics, storage. We're not really
all that far off from these things with what is supplied with HTML 5 it just
sucks that the core of the affair - HTML/CSS/JS - is rotten through and
through.

~~~
sktrdie
I think UI really shines using the Web stack because it was built using async
tools from the very beginning. UI development should be async from the get go.
In other non-webby systems you do UI using async but you're still using
blocking tools (for example by using Java's mixture of async for UI but
blocking for other stuff). JavaScript on the other hand, and all of its
libraries, are entirely async which makes it a pleasure to work with - it's a
much more natural environment to be doing UI in (single thread and everything
is there to be used without multi-threading complicated stuff).

This is a big insight that JS and other webby-tools have given to the UI
world, and I strongly believe something entirely async needs to exist for the
desktop/mobile world as well - fortunately there is in the form of
node.js/electron/nw.js.

Now in terms of how that's handled behind the scenes, I don't really care (use
a nice VM, use a whatever mixture of whatever you want). Just give me a fully-
async toolset to build my app in a single thread and I'm happy.

~~~
peterashford
I can't agree that UI via JS async is a pleasure to work with. I can't think
of a UI technology I've found less pleasurable to work with. No - there was an
ancient C GUI that used all C Macros to compose - that was worse... but only
just.

------
javajosh
Tim Bray or not, it's irresponsible to point out a pile of shit without
pointing to a shovel. (And for the record I disagree that there is a pile of
shit. I see a bazaar of indy components.)

The browser exists in open opposition to iOS and Android, technically,
culturally, and stewardship-wise. No-one in their right mind is going to pick
a web host that charges you 30% of revenue. And yet, that's what Apple has
managed to get (and they just control the BLOB distribution channel, they
don't even provide runtime servers!).

The whole shebang is sorting itself out and I for one think it's going to be
very, very cool.

~~~
nly
> No-one in their right mind is going to pick a web host that charges you 30%
> of revenue.

Eh? What stops you from publishing a free app with ads?

~~~
mikegioia
Integrity? User experience?

~~~
nly
Nobody seems to care about that on the web.

------
forrest92
What frustrates me about these kind of articles is that they ignore things
other than technical perfection. Yes, the web platform isn't the ideal work
environment, but at least its got mass adoption and has some kind of standard.
Its much easier to program a web front end than it is to program and
distribute a gui application using qt. Yes, the web development area needs
improvement. JS, CSS, etc. aren't perfect, but improvements are being made,
the technology is being pushed forward with every new version number.

~~~
harigov
I disagree when you say that its easier to program web front-end than Qt/GUI
application. Although improvements are being made, they are mostly patches
rather than rethinking the design given the current usage. I do agree with the
author in that there are many broken tools and languages.

~~~
bryanlarsen
It may be easier to program a Qt application, but it's not easier to program
and _distribute_ a Qt application.

~~~
meddlepal
Distribution seems like an easy problem to solve... App stores or software
repositories. Am I missing something here? In 2015 all the major platforms
have or the other other.

~~~
coldtea
Exactly. For every web startup or established player, there's an equivalent
native app running on a mobile phone, or also on the Desktop (from Facebook,
and Twitter to Skype etc).

~~~
copperx
What is the native equivalent to Facebook?

~~~
coldtea
The Facebook mobile app.

(Famously it was original done as a web-widget and Zuckenburg admitted this
was a mistake and turned it to fully native UI).

~~~
bryanlarsen
"fully native" just means that it has multiple web views rather than one.

------
serve_yay
I basically agree, except that I really like JavaScript (the language, not the
APIs necessarily) and I think it gets a bad rap.

~~~
savanaly
I have only programmed in Ruby and Java and Javascript (and the first two only
a little). ES5 and before js does seem worse than the other languages I've
experienced, but not by much. And ES6 is sort of a joy to write. Leaving
callbacks behind for promises and writing in a largely functional style is
very satisfying in js right now.

------
nkozyra
Popular javascript frameworks exist to "work around" problems with javascript
and CSS frameworks exist to "work around" problems with CSS?

There's no magic with Angular or Bootstrap, they're codifying an approach
using 100% native JS or CSS. Even SASS and LESS are just alternative ways to
produce CSS. This is not novel in computing.

~~~
bradhe
Totally true. That's like saying the Ruby on Rails exists because Ruby is
somehow deficient.

~~~
fao_
But, your analogy is flawed; the situations are incomparable.

You're not forced to use Rails for your server application, many other
software exists _as well_ as Rails: Django, PHP, etc. However you /are/ forced
to use Javascript, CSS and the DOM; Unless you're a Big Browser Vendor and can
try and coerce support (and even so, the amount of websites made in something
like Dash is pitiful afaik). People made frameworks and libraries that make it
bearable (SCSS, JQuery, etc), but that doesn't mean everything is solved...

~~~
nkozyra
That's a totally different analogy altogether. The argument expressed on that
page isn't that there is a lack of choices, but that the choices are
inherently flawed (and somehow "fixed" by frameworks that lie on top).

------
isaiahg
I happen to like JavaScript but I agree about HTML, CSS, and the DOM. Actually
I would like them to die. It doesn't take a PHD to see that we've moved beyond
what the original platform was designed to do. It was designed for documents
and styling those documents, but very little of what we do today is making
documents. Webapps are king now and designing them means having to work around
this outdated platform built for documents. It's so bad that now we require
books such as JavaScript the Good Parts to explicitly tell us how to avoid
these warts.

Instead of iterating further on HTML I think a new open platform should be
built that specifically targets interactivity and building applications. Keep
HTML for documents, what it was meant for, and begin focusing on something
that can address the current needs of developers.

~~~
jdub
_very little of what we do today is making documents_

Do you spend more of your time on the web using applications than you do
reading documents?

I kind of doubt it. Maybe. But probably not.

It may be that you spend more time _making_ web applications than documents.
That's understandable.

But is the web primarily for you as a developer, or as a user?

~~~
industriousthou
I would say a substantial amount of time is spent by most users using
applications. For instance, Facebook might eat up more than 50% of some users
time on the internet, which I think falls under the category of application.
Or Youtube, Gmail, etc.

There may be a small minority or users who spend a lot of time reading
documents (and I applaud them!), but most users are interacting with web
applications.

~~~
chipotle_coyote
Of the three examples you gave -- Facebook, YouTube, and Gmail -- you could
make a good case that only Gmail is actually an _application:_ it's a mail
client that runs in the browser. YouTube is arguably almost as document-
centric than Hacker News is; it's simply that the documents in question are
built around embedded videos and their comments. Facebook is somewhere in the
middle. It's accreted application-like qualities over the years, but at its
core it's assembling a list of text and image items -- i.e., documents -- into
a master timeline.

I'd submit that an awful lot of web sites that people spend time on have been
made _very_ JS-heavy and "application-y" despite being fundamentally document-
driven. In part I'm sure this is due to the rise of native mobile applications
-- have your server just use a JSON API and make your "web page" a JavaScript
application that talks to it the same way your iOS and Android apps do. That
development model has become the hammer web developers are using to hit an
awful lot of things that maybe really aren't that nail-like.

~~~
cactusface
But what are emails if not documents? Social media is just fancy document
sharing.

------
jokoon
It's the same problem XML has. It's bloated and unreadable for a human. YAML
is much better in that regard, and I wonder if one could build a document
language with a syntax that resemble json.

Have you ever opened the html content of any common webpage ? It's insane, in
size and indenting, it's impossible to make sense of it, it would make much
more sense to have an _open_ binary format and let developers deal with it.
HTML has way too many attribute that stacked on each others. People will
defend its openness, but I pity the guys who write html parser for internet
browsers.

HTML thrived because its openness allowed to bypass microsoft and its closed
solutions, but other than that...

------
intrasight
They are all "done" in that it is unlikely that anything will replace them any
time soon. We don't event have, AFAICT, anything on the horizon. But there's a
reason for that, and that is that the HTML/JS/CSS stack is the "virtual
machine" or "assembly language" of UI development, and as such, we can't any
more say they suck than does programming in assembly language. Assembly
language is the "given" \- unless you build your own CPU. This stack is
likewise the "given" at the moment, and developers build an amazing array of
tool, services, and billion dollar companies on this VM. Nobody controls this
VM, so nobody can engage in rent-seeking behaviour. This has the pleasant
effect also that most libraries built on top of are also open-source, and we
end up with a very Darwinian landscape. We are now in the Cambrian Explosion,
and the body plans that evolve must, by that way of thinking, be the best
adapted for their environment.

------
jph
HTML has many areas to improve still -- for example HTML-next can make it
easier to do hypertext markup to a list of articles, including article title,
author, date, contact links to social sites, and some summary text.

(Currently this is accomplished by munging the tags for cite, article, author,
and jumping through some small hoops for microformats.)

------
ivanhoe
Different people have different problems. For a web dev HTTP is "basically OK"
as author says, but for a network engineer it is very much not (to the point
that 2.0 was created to be completely different). I personally don't see how
some new html/js/css dialect could efficiently solve the problems for everyone
out there. How do you make both CoffeeScript and Dart user happy with a single
syntax? I prefer to have a bunch of specialized high-level tools to choose
from depending on a situation, than forcing them all into some one-size-fits-
all mishmash (which almost always fails)

------
agumonkey
Joking about how html6 should be p,a,li,h,span only I googled it. And some
people are pretty serious about a massive future version
[http://www.html6.io/](http://www.html6.io/)

~~~
bpicolo
"This specification is about the 6th version of HТML (HyperTurtle Markup
Language), not HTML"

~~~
misuba
"HТML uses a Cyrillic ‘Т’ to avoid any possible confusion with HTML." brb
laughing until I cry

------
cbr
As long as there are very common things that you can only do with JavaScript,
HTML is not done. With declarative syntax the browser can be so much faster.

------
pacomerh
Headline means HTML is in an acceptable state, a little misleading

------
Kenji
As long as we distribute "HTML is done" messages in HTML, it is not done. Well
played, though.

~~~
itistoday2
This is the problem with reading only the title of an article...

~~~
Kenji
I did read the entirety of the article. Do you mind elaborating?

~~~
itistoday2
He's not saying "HTML is done" as in "over" or "not to be used". He seems to
mean something along the lines of "feature complete" and suggests further
efforts focus on parts of the web that are lacking (JavaScript, DOM, CSS).

------
PretzelFisch
There needs to come a point where we let html and javascript exist for static
linked documents. And build something better for our applications. Java and
Silverlight have failed spectacularly at this so that future does seem quite
bleak. There is still some hope with chrome plugins I think.

------
briholt
With CSS, the concept of differentiated HTML tags basically became obsolete.
The purpose of HTML now is just to break apart and identify the content fields
in an XML format. The only tags I really use in the HTML body are _div_ and
_a_ \- and I only use _a_ because I can't add a _href_ attribute into a _div_.
Some people have tried to argue against this way of doing things ("divitus")
but as far as I can tell their criticisms are pedantic, not practical. If some
one has a good practical argument for specialized HTML tag names, I'd love to
hear it.

~~~
bjudson
The argument against this approach is that it's not always humans accessing
web pages. And even if it is humans, sometimes they need computer assistance
to interpret the content.
[http://en.wikipedia.org/wiki/Semantic_HTML](http://en.wikipedia.org/wiki/Semantic_HTML)

~~~
briholt
As the article says, this is equivalently achieved by naming div classes and
IDs (or some other attribute like _itemprop_ a la schema.org). Also I'd say a
completely style-free HTML scheme with open-ended semantic tag names (XML)
styled by CSS is equivalent. The point is HTML doesn't serve a useful styling
purpose.

~~~
bjudson
I don't have a strong opinion on whether browsers should provide default
styling, as it's trivial to override (although many web pages do rely on it).
I agree that HTML tag names don't serve a very useful styling purpose, but
they provide a useful structural purpose that cannot be easily replaced by
using open-ended tag names or classnames. Custom Elements
([http://w3c.github.io/webcomponents/spec/custom/](http://w3c.github.io/webcomponents/spec/custom/))
are in the process of being implemented, but I don't think that's an argument
for throwing out the standard, structural elements that provide a common API
for interpreting document structure.

