
HTML is the Web - mmoez
https://www.petelambert.com/journal/html-is-the-web
======
meerita
I pretty much agree with all the article. Back in 2001, when Web Standards
were on the rise, people used to validate their HTML code. It was shown as a
badge of prestige when you had 0 errors. Semantic HTML was a hot topic and
most of the developers I worked with were a sort of HTML taliban. But the
popularity of frameworks helped developers forget the basics and concentrate
more on learning how to get the most out of these projects. If we also sum
that I don't see true impact on SEO by having the best HTML I think it's
pretty clear semantics and validation isn't relevant anymore.

When people ask me why SEO isn't working. Well, try to see the first results
on Google, and check their code. Most of the times you will see worsen HTML
validation and semantics trumped over better (not perfect), not mentioning the
first page is mostly paid ads. Google is not like back in the 2000s. Things
has changed.

~~~
tobyhinloopen
All my webpages had the valid xhtml badge!

[https://commons.wikimedia.org/wiki/File:Valid_XHTML_1.0.svg](https://commons.wikimedia.org/wiki/File:Valid_XHTML_1.0.svg)

I still have a hard time un-learning `<br />`

~~~
rimliu
Opening can of worms: did you serve them with any of the available XML MIME
types? If not they worked simply because of the bug in the browsers (SHORTTAG
means a different thing in HTML compared to XML) and all XHTML code served
with HTML MIME type would be littered with ">" if browser treated it right ;)

~~~
innocenat
I once toyed with the idea of serving XHTML page as application/xhtml+xml, but
the fact the browser (back then, not sure about now) will just display XHTML
error and doesn't render anything was a deal breaker for me.

~~~
sureaboutthis
By "the browser" you mean "Internet Explorer". The only browser that couldn't
handle XHTML.

~~~
ricardobeat
With XHTML any syntax error completely aborts rendering, there is no fallback
- the browser will display a native error page instead.

~~~
sureaboutthis
Has nothing to do with what I said. IE couldn't handle XHTML until IE9

[https://blogs.msdn.microsoft.com/ie/2010/11/01/xhtml-in-
ie9/](https://blogs.msdn.microsoft.com/ie/2010/11/01/xhtml-in-ie9/)

~~~
ricardobeat
Sorry, but you’re mistaken. The parent never brought up IE - he was referring
to the fact that when serving XHTML with the correct mime-type
(application/xhtml+xml), any error causes the page not to render at all. This
behaviour is intended per spec and was the same across all browsers, not due
to lack of support. It’s called “draconian error handling”, consequence of
being XML, and was a major factor in the death of XHTML.

~~~
sureaboutthis
The death of XHTML was brought on by the then crop of kids who don't want to
understand how computers work and want it all done for them with someone
else's code cause computer science is too hard and they'd have to think and
thinking is too hard.

While I often hear this "draconian error handling" about XML/XHTML by such
people who then complain that a language compiler is just as draconian and
real programmers complain when it's not and doesn't catch their every little
mistake.

It's this lack of education and drive for the pursuit of knowledge and
understanding that caused XHTML to fall out of favor and no other reason.

~~~
bmn__
That's all well until you have external content (e.g. blog with comments or
blog roll headlines). Many an enthusiastic Web author in the 2000s migrated
off XHTML again. Not because getting it right is too hard (each fix for each
problem is quite straight-forward and often trivial), but because when you
have the choice between having a completely broken page/site until you have
time to log on and fix it and having a miniscully broken part of a page that's
easily ignored by a visitor, then the idealism was just too bothersome.
Unfortunately, that's human nature. Also see: rms's principles as exemplified
by his life-style and how many follow his example perfectly.

------
gargravarr
The biggest takeaway is that HTML was originally designed to degrade
gracefully. If your browser didn't support the intended graphical layout, it
would still be able to extract the hierarchy and display a usable web page,
even if you were using pure text (e.g. lynx). This kept the web accessible no
matter what you were using.

These days, none of that occurs. Just try switching off Javascript (I use
NoScript heavily to avoid invasive ad trackers). 75% of web pages don't load
at all. Others completely mangle their layouts into an unnavigable mess. Only
a very small subset of pages are readable. And these are just landing pages -
pages that should welcome one and all to the site. Most of the time, unless
I'm looking for something specific on the site, if it loads a blank or mangled
page, I just move on. If everything's a dynamically-arranged <div>, the
browser has no hope of making sense of it.

You can lead a horse to water, sure...

~~~
manbearpiggy
Web pages should be designed to load without js.

~~~
dbtx
Web pages that don't show anything without JS are broken. Ones that show only
a message about enabling JS are worse. It seems JS;DR was already a thing long
before I felt the need for it yesterday, when I simply missed that article
about synths at ableton.com because it was broken.
[https://indieweb.org/js;dr](https://indieweb.org/js;dr)

~~~
komali2
What about web applications? I am the office champion of accessible web, but
recently we made a web based game, in canvas. Without js, there's no game
engine, so we had a noscript tag.

That synths article uses built in JavaScript synths (using audio apis). I
agree the text should display without JavaScript but the purpose of the
article (get hands on with synths) is eliminated without JS.

Basically, the web not only is a document delivery place, it's also the new
Newgrounds. None of those games would work if you disabled flash, why should
web applications (beyond ones that are simple documents) work without
JavaScript?

~~~
dthedev
If you like synths on the web, check this out.

[https://learningsynths.ableton.com/](https://learningsynths.ableton.com/)

~~~
komali2
Cheers, but that is the exact article we're discussing lol

------
Zelphyr
I feel like many people here are misreading the OP as anti-framework and I
didn’t read it that way at all. Sure, there is an element of, “you don’t need
to immediately grab the nearest framework as the solution to _every_ problem”,
and that’s something I personally agree with.

But the point I think the author is trying to make is that whether you do or
don’t use a framework, you need to understand the fundamentals. The
fundamental language of a browser has always been HTML. JavaScript and CSS are
great and came along in due time but before all that there was HTML. So
whether you’re simply marking up a document or building a full-fledged web app
with React or Vue, you’re doing yourself a disservice by not learning and
using proper HTML.

~~~
brianzelip
Yes! It’s about semantic HTML. For example, starting a Vue component with a
<section> or <ul> as root element.

------
okaleniuk
As an experiment, I started
[https://wordsandbuttons.online/](https://wordsandbuttons.online/) in plain
hand-crafted HTML+CSS+JS (JS for the interactive bits only). Every page is
self-sufficient, there are no dependencies, no dynamic data exchange, no HTML
generators, - nothing. And it works so well, I don't really want any
frameworks now.

It's perfectly malleable - I can make every page do exactly what I want it to.
It's lean and fast - every page even with all the interactive plots, games and
quizzes, and syntax highlighting, is still under 64K. And it doesn't
accumulate technical debt. There are no dependencies, even within the project.
An occasional bug from the past wouldn't bite me in the future.

At the beginning, I thought that typing the HTML by hand would be too tedious.
But it's not. It is a bit boring, sure, but it's only like 5% of all the work
so usually I don't really want to automate it.

And when I do, I just write scripts that handle HTML just like any other text.
Works wonders for me.

~~~
NohatCoder
It is truly astonishing how much people believe that they need frameworks.

Your site looks nice, but one comment I'll make about your coding style is
that you (or anyone getting inspired from your code) should probably switch
away from innerHTML as the default choice for DOM modification. In a lot of
otherwise useful contexts it is an HTML injection hole. (For the record it
doesn't seem to be a security issue for the kind of content you have made, but
better kill the habit before it becomes a problem.)

For a while I used document.createElement and friends to generate injection-
free DOM, but that style takes a lot more typing than innerHTML usually does.
Eventually I made a tiny library for easing the job, and I haven't looked back
since. I don't think anyone else uses it, but so far it is definitely worth it
for the one happy user.
[https://github.com/NoHatCoder/DOM_Maker](https://github.com/NoHatCoder/DOM_Maker)

~~~
arantius
I did something very similar back in 2006:
[https://programming.arantius.com/dollar-e](https://programming.arantius.com/dollar-e)

------
ktpsns
I recently used Semantic-UI ([http://semantic-ui.com/](http://semantic-
ui.com/)) in a project. Semantic-UI is a web framework where "semantic" means
there are human readable class names like

    
    
       <button class="minor red labeled button">
    

Compared to Bootstrap, Semantic-UI ships with high level "components"
("views", "modules", "collections"). And here comes the ugly: They all abuse
HTML as if it was 2008. Div soup everywhere. Even lists have to be formatted
as Divs, something I havent done since ages, something like:

    
    
       <div class="ui list">
         <div class="ui list item">...</div>
         <div class="ui list item">...</div>
       </div>
    

It really felt as if the knowledge about semantic html tags got lost
somewhere. Or the authors of this popular CSS framework have another
understanding of "semantic". It doesen't meet my quality of structured HTML,
thought.

~~~
notoverthere
Oh my! I didn't believe that code example you just gave, so I had to go look
it up for myself. I'm astounded.

[https://semantic-ui.com/elements/list.html#list](https://semantic-
ui.com/elements/list.html#list)

~~~
ry4nolson
to be somewhat/slightly fair, the very next example talks about using a `ul`
for the list.

~~~
notoverthere
But according to the docs that's "for convenience". Its semantic value isn't
discussed.

So presumably the 'proper' way to do it, if you're not looking for
convenience, is to use `div`s. /s

------
grey-area
Web pages started as documents, and have gradually evolved to support ever
more complex uses, so that now they are effectively a platform for application
delivery (and a very good one) as well as for document delivery. Oftentimes
web applications are a mix of both data delivery and data manipulation, so the
line is not clearly drawn. This has inevitably created a tension between those
who see apps as the only future, and those who see docs as the purpose of the
web, and apps as an afterthought (a camp the author of this article falls
into). I don't think it's useful to attempt to set up a dichotomy between Apps
and Docs and pick a side. Very few websites are pure document stores, and very
few apps don't require documents, urls for resources etc.

Personally I think the web should evolve to play to its strengths: Simplicity,
Flexibility, Separation of data from code and from style.

It'd be nice if instead of trying to shove javascript into every hole because
it happened to be bundled with browsers, we pushed browsers to bundle more
runtimes for client-side work (a WASM standard library if you like), so that
the web can continue to be a place where you can post about javascript on a
server running arc software, and not care which technology the server or
server uses, which can be swapped out at will. One of the great joys of web
development from my point of view is not being tied to a particular language
or ecosystem, because the web is heterogeneous.

------
onion2k
_A Web page is a document._

No it's not. It never was. Even a long time ago when websites were static
things rendered by the browser once and then left alone there was _always_ a
tree of nodes underlying everything. The only thing that's changed in the past
three decades is that now when we make websites and web apps we often ship a
little JS application that lets the user modify the underlying tree. _That 's_
what the web is now and HTML is just what we use to describe the initial state
of the tree (and arguably it's the wrong language for that job, but hey ho).
Using semantic markup is important for a bunch of things like accessibility,
but you can't really expect the initial state of the page to stay the same
after it's loaded, and software that renders things from the web has to deal
with that.

If you're old enough you might remember that once there were no stylesheets.
HTML wasn't just the content and structure, but also the _visual_ description.
We used font tags. We used color attributes. We used spacer gifs. We don't do
that now because it sucked. We moved forwards. The same is becoming true for
HTML. Users demanded interactivity, and we gave them exactly that, and
browsers turned in to things that run little applications rather than things
that render mark up. The web has grown and evolved and moved on, and thinking
of the web as "HTML pages" is _just plain out of date_.

That's not to say static content isn't still useful. It is. _Very_ useful. But
static HTML pages isn't the web, and the single page application genie isn't
going back in the bottle.

~~~
thaumasiotes
> We moved forwards. The same is becoming true for HTML. Users demanded
> interactivity, and we gave them exactly that, and browsers turned in to
> things that run little applications rather than things that render mark up.

As I like to occasionally point out in wasm threads, the browser was a thing
that ran little applications all along, in the form of Java applets. I have
yet to see an explanation of how wasm applets are a different approach to the
problem, but they sure are a more popular one.

~~~
onion2k
The difference is timing. Computers weren't really ready for applets back in
the mid-2000s when Java was pushing to be the thing that made web pages
interactive. The performance (in terms of download speed, start up, and
actually running them) was usually pretty horrible. Now the hardware has
caught up it's the language that's the bottleneck, so WASM might prove to be a
decent idea.

Also Java tried to be a gateway out of the browser to the OS, and that's just
a terrible idea for security. WASM isn't trying to be that, and hopefully it
never will.

------
sloum
I couldn't agree more. HTML is so basic that you have no excuse to not do it
in the ballpark of right (accessibility can be tricky and right is not always
completely clear, but in 90% of cases you should have a good idea). Using a
solid css reset solves most of your visual issues with using semantic
elements/structuring following proper standards. Use the reset and then write
css however you want to. The current state of the web (being nothing but an
advertising platform for the most part) is what is driving a lot of people to
other protocols. A return to sanely structured CONTENT over
pretty/fancy/neat/whatever looking would be, in this writers opinion, a
wonderful thing. I know in a perfect world we'd have both, but that is not how
things have played out for the most part. Maybe the next thing, that replaces
the web eventually, will get it right. :-/

------
flohofwoe
Unpopular opinion... but I think this is a too limited view of the web. My
contrary opinion is that the _actually_ important feature of the web is the
URL, and the important feature of the browser is that it provides a sandboxed
platform for running untrusted code without a builtin "walled garden moral
police".

It would be nice if operating systems would be exactly that, but for some
reason "commercial" OS vendors are not able or willing to provide a safe
"native" sandbox completely uncoupled from curated app stores.

The ability of a browser to be a document viewer with a very limited layout
system should be implemented in an optional layer on top of a bare bones
browser.

Again, this should all be provided by the underlying operating systems (click
an URL and instantly run cross-platform applications in a safe sandbox), but
for some reason we didn't get that. It's the same with Electron apps by the
way, those wouldn't exist if operating systems would come with cross-platform
UI frameworks that are actually better than the unholy mix of HTML+CSS+JS. But
Microsoft, Apple etc... had decades to get their act together without
delivering.

~~~
bo1024
I'm inclined to disagree, but I guess the real problem is that webpages on the
internet are being forced to serve both purposes.

Paradigm 1 - interconnected, hyperlinked web of text-and-content-based
documents: open, accessible, amenable to indexing and tooling and so forth.

Paradigm 2 - delivery vehicle for cross-platform, full-featured, somewhat-
security-sandboxed, applications.

I agree with the article that it's sad if Paradigm 1 is trampled to make way
for Paradigm 2, just because (as you point out) we haven't been able to
develop a viable alternative. In theory these could coexist, but the point of
the article is people are being trained in Paradigm 2 and try to use it for
purposes that are much more suited for Paradigm 1.

Just as sad, Paradigm 1 is more oriented around decentralization, giving
power, options, and information to the user; Paradigm 2 is often exploited for
lock-in, control over user's decisions, collecting information about the user,
etc.

~~~
dccoolgai
I think what the author is saying is that paradigm 2 is built _on top of_
paradigm 1 and if you can't do #1 right, then by definition _neither_ can be
right. It's astounding the number of interview candidates who are super-fluent
in JS but can't tell you to save their lives why it's a bad idea to put a
click handler on a div. React will die (It's already started to) and we'll
migrate back to the actual Web at some point and for my money it can't happen
fast enough.

~~~
hombre_fatal
> It's astounding the number of interview candidates who are super-fluent in
> JS but can't tell you to save their lives why it's a bad idea to put a click
> handler on a div.

Go on?

~~~
snek
Putting a click element on a div is transparent to accessibility systems. And
no, it isn't possible to consider an element with an onclick the same as a
button, because events bubble, which means the element with the event listener
isn't necessarily the element being watched for a click. IIRC there even used
to be a "good practice" where people would attach a single click handler at
the root and use it to dispatch events based on the `event.target` instead of
attaching a separate handler to each target.

~~~
dsego
React does that, they call it synthetic events, but it's hidden from the
developer. In jQuery it used to be called event delegation, made it easy to
handle events on dynamic elements without the need to constantly attach/detach
handlers.

------
Dowwie
So, frontend tooling is freeing developers from mundane tasks and cognitive
overhead at the cost of not strictly following standards and recommendations.
The tooling could be improved to more closely follow standards, but maybe
those standards ought not be followed? Maybe the standards need to evolve with
real world use. DIV has broader applications than what a committee envisioned.
Sites are running, business is accomplished, goals are met while not strictly
adhering to antequated standards.

If I make a tool with an intended use but the world uses it in another
unanticipated way, and they're happy about doing so, then that is a very
fortunate accident. I then shape the next iteration of my tool around real
world use.

------
hypertexthero
Someone I met recently met who delegates work to web developers for a living
had this to say about JavaScript frameworks: They are very seldom necessary
for a job, and their main function is to create more work for more developers
to get paid.

As an “old school” designer who writes HTML and CSS by hand, with JavaScript
for progressive enhancement, I found myself agreeing, and it reminded me of
this, from back in 2001:
[https://www.thenoodleincident.com/tutorials/box_lesson/why.h...](https://www.thenoodleincident.com/tutorials/box_lesson/why.html)

> The idea of HTML et al is a document markup language that would grow. Its
> architects saw we were going digital and sat back and took a long view. A
> very long view. They laid the foundations for a language that would work
> with all the conceivable technology of the time, and would be expandable to
> the unconceivable technology that would follow. So that documents would
> never be unretrievable due to age. Ever. A browser in 2050 would be able to
> read a 1994 document. And in 2094. And so on. They made a stand of cultural
> importance to the world.

The slow, less usable feeling of JavaScript-heavy websites — my current
personal website included — has remained a constant, and I mourn the reduced
usability of View Source as a map for learning, lost in the forest of DIVs and
obfuscated JS in much of today’s World Wide Web.

~~~
dshacker
I'd argue the opposite point, the problem with static websites is that they
were bad at capturing state. That is what lead to the bloat of JQuery messes
in websites and inefficient parsing of the HTML tree. Now that developers have
so many platforms to target in so many ways, having a consistent way of state
to permeate through websites reduces work.

Don't take me wrong, I love crafting my website 20kb of CSS over static files.
Always sign me up for a static site, but for complex websites, where
interactivty and state are needed, it's important to have these frameworks.

------
grappler
This is the kind of thing that drove me away from frontend development a few
years back. I explicitly ignored the learn-the-javascript-framework-du-jour
attitudes.

On a project where I was doing frontend work, I just tried to think about the
semantics of html elements and http requests, and reason my way through the
tasks from first principles. I really enjoyed doing that actually, and don't
regret it. But it didn't teach me angular which is what the frontend people at
that company were using at the time, or probably any of the other ones.

I hope to venture into frontend land again, because I think it's a valuable
skillset, but I hope the next time I do things will have settled into
something a bit more sane. When I find a layer of a technology stack that
seems to have been misused or misunderstood, my tendency has been to stop at
that point and dive into a rabbit hole trying to understand what is going
wrong and how to fix it.

------
tannhaeuser
Idk, on the one hand, HTML is what made the web great as an easy medium for
self-publishing. This has now mostly been driven ad absurdum by CSS, the
expectations towards super-stylish content, and hence centralized platforms a
la github, medium, etc. I mean I'm pretty ok at CSS, but the amount of hacks
and stuff you have to do for even the most basic layouting and typographic
stuff outside your regular markup is just mind-boggling, and not something you
can call reasonable by any measure (including Flexbox and Grid and whatnot).
OTOH, coming from print, there just was no blueprint for declarative,
interactive, responsive web pages [1] so some concessions had to made wrt to
evolution of the web. I always thought of JavaScript as a mid-term measure to
try stuff until such a time when we could, from hindsight, integrate
declarative UI features into HTML. But that hasn't happened, and HTML has
essentially stagnated instead relative to JavaScript and CSS. What we have is
this unholy HTML-CSS-JS trinity hardwired into people's heads with strong
opinions on which goes where a la "semantic" markup, but absolutely no logical
or scientific base for back up. It's all fun until you realize we're going to
loose most digital content of our decade, and a once-strong medium for digital
communication (markup, HTML) has been overtaken by corporate interests, nerds
seeking an intellectual challenge because they can, feature creep and misuse
of the web to counter a software crisis, self-sustaining web economies and
generational churn, and other unintended consequences.

[1] technically, there was SGML and HyTime, HyperCard, Xanadu

------
2T1Qka0rEiPr
As much as I like the sentiment, in my opinion HTML is very much a means to an
end - that end being delivering content to your end consumers.

I was very much behind the "separation of concerns" brigade (with respect to
HTML/CSS/JS) a few years ago, but the invent of React/Angular etc. and the
"component driven architecture" has seen an end to that.

It's a shame - from my perspective, new entrants into the front-end market
lack much of the knowledge I'd regard as fundamental even a few years back
(most saliently for me TypeScript/ES2015 obscuring JS's prototypal
inheritance) - but its also understandable.

------
zemnmez
> My big concern is at the bottom of that technology pyramid. The lowest
> common denominator of the Web. The foundation. The rhythm section. The
> ladyfingers in the Web trifle. It’s the HTML.

This is perhaps an annoying pedantic answer, but I feel like this discounts
what HTML actually _represents_ , and what the Javascript libraries operate
on, which is the DOM, bypassing HTML syntax often completely. The HTML,
fundamentally is a representation of this Document Object Model, and if we're
to be essentialist, HTML's success relies on good fundamental ideas of _what
kind of document it generates_.

I do, however absolutely agree that the semantic representation of a document
is important, and HTML's ideas of what a good representation of a document
looks like really do shape the success of the web. This is why in very
successful frameworks like React for example go so far as to implement their
own pseudo-HTML transpiler that turns HTML-like representations of DOM nodes
into DOM construction calls.

That said, I think there is a certain kind of essentiallism echoed in this
post that goes along the lines of 'everything can't just be <div>s with
classes' and I agree with that, but I don't think it has to do with writing
more HTML-like DOM trees as much as augmenting the DOM to integrate more
modern representations of DOM operation. I hope that in the future, systems
like React leverage something similar to Custom Elements to truly represent
their functionality in the DOM tree, as God intended ;)

------
gorpomon
I always chime into these articles with the exact same sentiment: this is a
business problem, not a developer problem.

Developers love simplicity and semantics. But when a UI gets to a certain
level of complexity (I say 10 interactions per page) then semantics get hard
to maintain or translate.

I'm building a recommendation engine for a client right now. Lots of wooshes,
whirring and moving parts, a good amount of items don't directly translate to
semantic HTML elements. It's not clear if my app should have <section> tags,
<article> tags or <aside> tags.

And again, when a developer has to manage that much complexity, then it's a-ok
to breakdown or lose semantics in exchange for comprehensibility. Pretty much
any trade-off is ok for comprehensibility. And making my users pay the 500kb
React tax is a-ok with me, because I'm not superman and it's only 500kb. One
un-optimized image can be that size. It's worth it for the project to be
maintainable and reasonable by the next person.

And one day when the business stakeholder decides that people on your
education site don't need badges, or that quality content matters more than
gamification, then we can dial these interactions back and make the web sane
again.

~~~
andersonvom
Since the article's main point is that you should use semantics as much as
possible, it's probably better that you used the "wrong" tag when choosing
between _< section>_ or _< article>_, than using the wrong tag and choosing _<
div>_s for lack of not even having asked the question "what should this be?".

While rewriting what's already out there may be a business decision, choosing
between what HTML tag to use when changing/writing new ones, is completely
business agnostic.

~~~
player2121
There are plenty of apps out there where you cannot apply HTML document
semantics or that would be a waste of time (money) doing so.

If using canvas or web-assembly would be easier/possible than using HTML tags
for a rendering layer, nobody would ever disturb the HTML document designers
with this div "soup" :)

Semantic HTML serves 2 purposes: lets search engines correctly index your
content and makes it easier for a human to edit this HTML directly. Other than
that, there is no other reason which requires semantic HTML.

True accessibility is achieved through other means.

------
jonahrd
> If you’re writing code that renders things in a browser, this is your job.

Nitpick: I write code that renders things in a browser. I do not touch HTML. I
use GL/D3D/Vulkan and C++.

I'm not really sure what point I'm making, perhaps that the author might want
to consider the other parts of the web/web browsers.

Edit: to clarify, I work on the lowest level of browser's rendering stack.

------
Lowkeyloki
The author is right, but this comes off very much as "old man yells at cloud"
to me. Sorry.

~~~
Lowkeyloki
Let me give slightly more context. As a developer, I'd love to use div less
often. However, I feel like the promise of the "semantic web" fell short. And
"web components" as a first-class HTML citizen isn't really there. So
React/Vue components are the best we've got even though they're actually just
divs and spans at the lowest level. I want the web to be semantic and
componentized. But it's not there yet and this is the best we've got.

~~~
myguysi
You can use React/Vue and still write semantic HTML, no?

~~~
Lowkeyloki
I mainly work in React. You can write semantic HTML up to a point. Things like
article, section, header, footer, etc. are supported. But if you wanted to
make up your own tag and expect it to act like a div, I think React would
complain that it doesn't understand that tag.

That's what I meant by "the promise of the semantic web". As I originally
understood it, you could make your own custom tags that describe the intent of
the document. You wouldn't be bound by what the w3c or browser vendors
blessed. Any tags that were unknown to the browser would be treated mostly the
same as a div. Web components occupy a similar space.

~~~
SahAssar
That does not match how I think of the semantic web at all. For example:

> make your own custom tags that describe the intent of the document

If you make up your own tags for everything then to a visitor (human, bot,
indexer or otherwise) it describes nothing, since those tags only have that
meaning on your site (and worse, they have different meanings on other sites).
Semantic web or RDF or Linked Data or whatever you want to call it is not
about describing your document within the context of your document, it's about
making sure your document is understood in relation to all the documents that
link to it and all the documents that it links to.

~~~
Lowkeyloki
I looked up what the semantic web actually is and you're right. But at the
same time, I was surprised to find that it's all properties! The tags are all
divs and spans!

I guess the semantic web is orthogonal to this discussion. My apologies. I
guess it's another buzzword that was thrown around for a time. In that case,
assume I meant web components whenever I said semantic web.

------
kekeke
The problem is bigger, IMO. Frontend is generally a disgrace for this
profession. Biggest projects are a mess that would never see the light of day
had they been backend-related. Babel, React, Webpack are maintained far worse
than libraries having 10% of their userbase in languages like Python. JS is a
fucked up language and we all know it. You couldn't done any worse if you
tried to. Until we as a community will not stop tolerating this bullshit,
problems will be solved using 2000% more memory/cpu/io than they actually
need.

------
_pmf_
Nobody is claiming HTML is not necessary. It's just not sufficient.

~~~
BlueTemplar
And CSS. Not sufficient for what? If you want to make a full-fledged program
with a weird custom interface instead of a website, maybe don't try to use the
browser as a virtual machine?

------
mcgwiz
Taking a linguistic perspective, one can analyze HTML usage through the lenses
of prescription and description.

Prescriptively, HTML was designed to be used a certain way. "Proper" use of it
supports a variety of use cases beyond graphical browser-based publications
and applications.

Descriptively, there is no "right" or "wrong", "proper" or "improper". <div>s
and <span>s are often enough because they get The Job™ done, for some critical
subset of all "jobs." It is true that web scraping and machine parsing of
content becomes harder when tags aren't applied semantically, and that text-
and speech-based browsing is more difficult. It would seem that those needs
are simply not substantial enough to the commissioners of web development work
to warrant the extra attention and care, especially in the hyper-competitive,
sink-or-swim environment of tech startups.

It is (nominally) what it is (actually).

The real problem is a lack of exploitation and education of the secondary
applications of semantic HTML and how it fits in with related technologies
(HTTP headers vs <META>, URLs and fragment identifiers, microformats and CSS
semantic class naming) by product designers. This would naturally drive
developer interest. In the meantime, those who do understand these things can
continue to devise solutions orders of magnitude more efficient or effective.

------
amw-zero
This way of thinking just isn’t aging well. HTML is the view part of the web,
and it turns out users want more application-like behavior and developers want
to build applications and not websites. Caveat, this is still only true for
some applications. Static HTML is still fine for certain applications. Just
never the ones I work on.

It started with AJAX and now we’ve converged on single page apps, which are
effectively native clients where the target platform is the browser. There is
simply a real demand for rich client UX and you can’t get that with pure HTML.
Which is no surprise because it wasn’t designed for that. It was designed for
sharing textual documents, as the article proclaims. But is that an accurate
model of an application? I don’t think it is. The web has evolved to support
more than just hyperlinked documents. Good or bad, that’s why people want.

------
CharlesW
> _It’s all about what gets consumed by the consumer._

It's not about the _what_. It's about _how_ it's delivered and consumed.

One could provide a web-like experience using any number of proprietary
technologies. It's only "The Web" when you _deliver_ that experience in an
open and standards-based way, and consumers _consume_ it using their
standards-supporting client of choice.

Podcasts are another great example of "The Web". What makes a podcast a
podcast isn't what gets consumed, but _how_ it's delivered and consumed. You
can post an audio show on proprietary platforms that require proprietary
clients, but those aren't podcasts any more than a web page saved as PDF is
still a web page. If you can't play it in a podcast app, it's not a podcast.

------
rangerpolitic
The new approaches to HTML/CSS run directly counter to the specs sometimes.

Take Bulma for example. They provide styles for titles and subtitles, but
their examples use h1 elements.

See:
[https://bulma.io/documentation/elements/title/](https://bulma.io/documentation/elements/title/)

Why is that a problem?

This is explicitly addressed in the HTML 5.2 specification.

> h1–h6 elements must not be used to markup subheadings, subtitles,
> alternative titles and taglines unless intended to be the heading for a new
> section or subsection.

See: [https://www.w3.org/TR/html52/sections.html#headings-and-
sect...](https://www.w3.org/TR/html52/sections.html#headings-and-sections)

As the author suggests, they don't understand the tools they're using.

~~~
SahAssar
I'm not a fan of bulma, but that is not a valid complaint. If you give a `h3`
the class `title is-1` it will look like their example `h1`. If you add a `h1`
without any classes it won't even have any of the styling of `title is-1`
unless you add the classes.

If anything they are purposely decoupling the styling from the semantics to
make it more obvious which one you are choosing (although the example could
make this more clear).

------
tomxor
> It’s about usability and accessibility. If you don’t think the semantic
> structure of your Web page or app is important then you’re essentially
> saying “Well, it works for me in my browser, ship it”.

I'm interested, how close to reality is this view of front end devs?

In my day job, it's difficult to get through a project without encountering
WCAG 2.x or some other accessibility criteria. Which usually forces you to be
more semantic in order to avoid having to be more explicit using aria to tell
screen readers etc what your special version of HTML means. Is this so
uncommon? This comes up as a contractual obligation all the time in
educational products, is this not the case in most other sectors?

~~~
jamesgeck0
> I'm interested, how close to reality is this view of front end devs?

It rings true to me. Accessibility isn't really on the radar of many of the
developers I've worked with, and managers want business reasons to justify the
extra effort that WCAG compliance would require. I didn't start thinking
about/pushing for it until I saw a talk at a conference last year.

Education, banking, and government sites are mandated by law to be accessible
in the US, but outside of that there's no guarantee that anything will be
accessible, what I've seen?

------
player2121
> I’m a ‘frontend of the frontend’ kind of guy. My expertise is in HTML and
> CSS,

There are 2 different things: documents and applications. These days you can
find IDEs running in the browsers, excel spreadsheets, terminals and all other
things which are not HTML documents. Yes, you cannot use <ul/> </li> to style
an output of terminal `$ tree ` command. This is why you see <div/> soup when
you examine HTML of the web terminal output.

As web-assembly becomes more mature, I expect developers to abandoned the
HTML/CSS scene and leave it to HTML document template designers so there again
can be a clear understanding when you have to use HTML.

------
systematical
This is what happens. We keep abstracting away. It's amazing how far removed
we are from machine code. It's even more amazing that something as simple as
HTML was abstracted.

------
z3t4
There are four types of web sites: static sites made using HTML, dynamic web
sites that use both HTML and JS. The third type however is web apps, that like
dynamic sites use the DOM, but no HTML! And the fourth type is web apps that
only use the Canvas eg. no DOM! So its possible to make a web "site" that only
has a script element, and the only DOM interaction is to append the canvas
element and add event listeners.

------
a2x
Agree. Most of Frontend Devs doing React or Vue, don’t know the major aspects
of a frontend. Although they are speedy, the quality is low.

------
delibash___
Unfortunately, a lot of people don't care...

------
titanix88
It's kind of funny to think about how web was supposed to be extensible with
'type' attribute for script and style tags,but everyone forgot to implement
anything other than 'text/css' and 'application/javascript'. Why did it
happen?

~~~
goatlover
VBScript and Dart were a thing, but they were vendor-specific. Netscape had
Javascript Style Sheets in the 90s, where you get the full power of a PL for
styling. Then you had Java and Flash through plugins, but they weren't first
class citizens with the DOM. However, Sun and Netscape did originally intend
Java to be embedded in Netscape alongside JS, but it didn't happen, so Java
went the plugin route.

People have tried, but getting the rest of the world to agree is the hard
part.

------
jypepin
this resonates. I interviewed a front end enginner last week who had a few
years of experience, so not completely junior. He had been working with React
most of the time.

we did a simple live coding challenge that didnt require React. Only some
javascript to output some html in the document. They were confused because
they couldn't do `return <div>hello world</div>` and couldn't figure out how
to instead simply do `return "<div>hello world</div>"` (jsx vs a string of
pure html).

It was pretty painful to see but also made me realise how Vue and React can
make life easier but seems to get people to know even less how underlying
things are working.

I guess it's the fate of all technologies.

------
islon
> In descending order of importance it's the HTML, the CSS, and the behaviour.

I would argue the behavior is more important if the website does anything else
other than just show articles.

A beautiful site with no behavior is useless; an ugly site with functioning
behavior is not.

~~~
orange8
Behavior and features are two different things. Behavior is more about basic
interactivity, like clicking or scrolling. Even websites that just show
articles require some behavior to work.

------
londons_explore
Are there really people out there who know and understand Vue or React, but
not HTML?

I always found Vue and React to be not good enough abstraction layers - you
still need to tweak and fiddle with the layer below from time to time to make
anything work properly.

~~~
rgoulter
I read the article as "HTML is more than just <div> and <span> \+ CSS", rather
than "HTML is the Web" (whatever that means).

------
kowdermeister
What is the point the author is making? That the knowledge of HTML is going
away? That's obviously false.

> And it is becoming increasingly clear to me that there’s a whole swathe of
> Frontend Engineers who don’t know or understand the frontend-est of frontend
> technologies.

I would need some data on this, since it sounds like this claim is backed by
anecdotes. None of my co-workers struggle with this and there's lot of
frontenders in our company. Semantic HTML's usage is now baked into VS Code in
a tooltip.

Yes, every web developer should be at least moderately good with HTML. Can we
agree on that? Good :) Learn a bit CSS and now you have superpowers.

HTML only provides the LEGO blocks for the web, but the web is much more than
that. It's an interconnected network of information with rich media. What
matters is the information persistence, quality and accessibility.

~~~
rimliu
I would not consider knowing "a bit of CSS" as knowing and understanding
frontend-est of frontend technologies. Alas, there are more than enough
cluches available in the form of variouos frameworks so throwing enough stuff
at the wall fill finally make some of it stick hence replacing the need of
knowledge and understanding.

~~~
kowdermeister
We are talking about HTML. It's really-really easy and I don't think there is
a problem at all that the author claims.

~~~
rangerpolitic
It's easy to use. It's not easy to use well.

------
battletested
No, HTML was the web. We are building web applications now with Javascript. I
hope that Web Assembly will end the need to write any HTML tag ever again in
our web apps.

~~~
orange8
Which GUI library would you use instead of HTML?

------
guyromm
back in 2005 I recall losing a bit of faith in humanity, when a subcontractor
who was asked to turn a design into markup and "not dare deliver pages laid
out using tables" (as it was still quite common back then), delivered a pixel-
perfect design, where even those pages that literally had tables displaying
information, were laid out with stacks of divs...

------
numlock86
I recommend everyone that writes HTML to check out Pug (formerly Jade). It
makes writing HTML so much easier when it comes to handling classes,
attributes, nesting, readability ... well, basically anything. It transpiles
to HTML and when using the pretty flag (-P) you can ditch pug anytime if you
don't like it and work on the HTML output again. And please tell if you do the
latter (and why). I still wait for the person that I recommended Pug to and
preferred to keep writing vanilla HTML afterwards.

------
thibran
The web has become a compilation target.

Vue -> HTML, CSS, JS

~~~
SquareWheel
That's more literally the case with web assembly. With Vue, I guess I still
see it as a form of transpilation.

~~~
SahAssar
WebAssembly does not replace CSS or HTML unless you render everything to a
`<canvas>` which would loose most of the benefits of the web.

~~~
SquareWheel
I understand that. But wasm sure does fit the description of "compilation
target for the web".

~~~
SahAssar
For logic, yes, but not for visuals, interactions, or anything that needs to
interact with anything besides itself.

So it might be "compilation target for JS engines", but it sure as hell isn't
"compilation target for the web". The web is so much more than just running
logic in a browser.

That might come in the future, but it sure isn't the present.

------
andy_ppp
My take is; everything will always get more complicated and you can write your
nice simple articles but it will not help.

------
Pigo
Web Assembly, it might not become everything I hope it does, but it has the
potential to be a game changer.

~~~
SahAssar
WebAssembly does nothing for for CSS or DOM. If WebAssembly would change any
of this we would just start using `<canvas>` five years ago like flipboard did
for a while: [https://engineering.flipboard.com/2015/02/mobile-
web](https://engineering.flipboard.com/2015/02/mobile-web)

The Web, when properly used (and perhaps also when it's not) is much, much
more powerful and useful than just painting on a screen and running logic
underneath.

------
stevage
> Search engines need to read your content, not enjoy your swoopy animations
> or fancy gradients.

Great way to get your audience ("back end of the front end" engineers and
full-stack devs) on side, by trivialising the work we do as adding pointless
fluff. Actually in most of my work, the JavaScript is the essential part of
the app, and whether it is perfect HTML or not is not a high priority.

------
snek
Gosh please use the correct elements when you make a webpage, even if you're
in react vue jsx whatever. It makes browsing the web so much easier for people
using accessibility tools, and as the author of this article says, it's very
easy to do. There are even automated tools to help test accessibility, with
pa11y and lighthouse being the most popular.

------
germanlee
HTTP is the Web. HTML is just the superficial face of the web.

~~~
BlueTemplar
HTTP has been misused recently though, applications that really have nothing
to do with HyperText Documents using it as a communication protocol when a
lower level protocol would have been more appropriate...

------
m6g6a
<custom-html></custom-html>

~~~
rangerpolitic
You could actually do that with XHTML, and it was perfectly valid.

------
kjgkjhfkjf
HTTP is the web, not HTML.

------
sbhn
Get on with your jobs. HTML aint ever goin away.

------
revskill
I don't need to know HTMl to become a Frontend Engineer. It's the same like, i
don't need to know Assembler to be a C programmer.

HTML is the compiled format which browser could understand and run, it's not
for human to produce/read it.

We need more powerful tooling/language/framework/library just like what we see
in React, Vue,...

~~~
yunruse
That’s a very narrow view. Machine code is ran in one context – the CPU – with
the compiler worrying about this one context. Meanwhile, HTML is parsed by
much more than a browser.

Like the article says, there is literally zero drawback to being slightly more
semantic. In fact, semantic HTML probably improves your own code, making it
easier at a glance to see what components do.

~~~
richardwhiuk
> Meanwhile, HTML is parsed by much more than a browser.

Any examples?

~~~
magpi3
Bots and email clients. Microsoft word. Libre Office.

~~~
daveslash
and anyone still using an RSS reader. Anyone sharing something on Facebook or
other social media, _me_ when I'm trying to write an app to do something
interesting for which there is no existing API.

