25 ms·

HTML is the Web

561 points by mmoez 7y ago

_pmf_ 7y ago
Nobody is claiming HTML is not necessary. It's just not sufficient.
- BlueTemplar 7y ago
  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?
meerita 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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 7y ago
        By "the browser" you mean "Internet Explorer". The only browser that couldn't handle XHTML.
        ricardobeat 7y ago
        With XHTML any syntax error completely aborts rendering, there is no fallback - the browser will display a native error page instead.
        sureaboutthis 7y ago
        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 7y ago
        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.
delibash___ 7y ago
Unfortunately, a lot of people don't care...
onion2k 7y ago
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 7y ago
  > 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 7y ago
    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.
2T1Qka0rEiPr 7y ago
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.
flohofwoe 7y ago
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.
- ecmascript 7y ago
  I don't think that is an unpopular opinion, since I am of the same. I agree with you that the URL is the most important feature of the web. Without it, you could just as well deploy native apps because it wouldn't really make that much of a difference. Without javascript and a heavy client side, I wouldn't have a job today since the application I build is simply not possible to create with just html+css. Sure there are many web pages that don't need to be a SPA, but a lot of other webpages do need it. I think an increasing amount of webpages are not simply text documents but we can easily see a move from traditional applications to web applications. It's obvious why, it is truly a "write once, run everywhere" scenario, it's easy to scale on many different devices and there is little to no advantages to write a native app in most circumstances. The document web has already been done, just use wordpress or whatever framework to create those sites but the new exciting web for me is the more interactive web where we can seriously move heavy apps into the browser.
  - godshatter 7y ago
    What we need, in my opinion, is a new protocol. Leave http(s) for documents and make a new protocol designed from the ground up for interactive applications. That solves the problem of trying to shove an application into a document viewing sub-system and should allow for more creativity and efficiency, depending on what this new protocol turns out to be. What's happening now is like trying to force ftp to show documents, with markup, and forms, and so forth when it's just supposed to transfer data.
enlyth 7y ago
HTML simply does not meet the needs of the modern web. This fact makes a lot of people emotional and angry for some reason.
- lpcvoid 7y ago
  Maybe because people have vastly different opinions about what the "modern web" actually needs?
  - enlyth 7y ago
    Opinions about what the modern web "needs" are great but they're just that, opinions, and everyone is full of them. What's important is what people actually want and use. I routinely see people bashing everything about the current state of the web, saying we should go back to static HTML documents, while their whole industry only exists because of the modern web, and they use Jira and Slack and similar tools to do the job that pays their bills. I just don't understand the logic behind this kind of thinking.
- ksec 7y ago
  My usage, as well as majority of friends that are non-geek, involves around - Scrolling through IG, Facebook, other Social Media, Forums, Online Shopping and News Site. Along with Video that in itself is a category as well as well as used within the previous few categories. News is arguably the biggest addiction of the 21st century, and IG, Facebook, Forum, are all really just "news". News about your friends, family, Celebrity, Tech, etc... I would bet the above represent more than 80% ( if not 90% ) of today's Modern Web usage. And all of them works with HTML + a little Javascript for interactivity. I don't see why it doesn't meet the needs of Modern Web.
  - enlyth 7y ago
    This is grossly underestimating the complexity of IG, FB and the likes. Everyone likes to tell other people how they should build their stuff, that's the easy part. Do you think React would have been created if "HTML and a little Javascript for interactivity" was enough for Facebook to deliver the UX they wanted to? No, there was a business need, and what existed simply wasn't good enough, maintainable enough or easy enough to reason about to work.
sbhn 7y ago
Get on with your jobs. HTML aint ever goin away.
grey-area 7y ago
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.
revskill 7y ago
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 7y ago
  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.
  - revskill 7y ago
    Imagine a newscomer learn directly React and its abstraction to produce a website. He actually did it without any knowledge of "real html".
  - richardwhiuk 7y ago
    > Meanwhile, HTML is parsed by much more than a browser. Any examples?
    - magpi3 7y ago
      Bots and email clients. Microsoft word. Libre Office.
      - daveslash 7y ago
        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.
    - peterjlambert 7y ago
okaleniuk 7y ago
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.
- onion2k 7y ago
  When you're making a site like yours (which is awesome btw) hand-coding HTML and JS works fantastically. You don't need a framework. Frameworks only really start being useful when you're working at scale either across lots of data-driven pages or with multiple developers on the same product.
  - okaleniuk 7y ago
    Yes, that's true. If you have lots of work to automate - sure, you need something to automate it.
- quickthrower2 7y ago
  As an aside, I like your blog and writing style, and the questions dropped in to make it interactive. COBOL ... I got that one. Funny!
- NohatCoder 7y ago
  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
thibran 7y ago
The web has become a compilation target. Vue -> HTML, CSS, JS
- yoz-y 7y ago
  Essentially yes. But I think the problem comes from the fact that it is at the same time a compilation target, and a pretty okay document markup format. I think people living at the edges of web apps and web pages are pretty happy, but the contention is when one is in between.
- SquareWheel 7y ago
  That's more literally the case with web assembly. With Vue, I guess I still see it as a form of transpilation.
  - SahAssar 7y ago
    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 7y ago
      I understand that. But wasm sure does fit the description of "compilation target for the web".
      - SahAssar 7y ago
        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.
kowdermeister 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      It's easy to use. It's not easy to use well.
xparco 7y ago
I still don't understand all this React tuttiness
Dowwie 7y ago
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.
gargravarr 7y ago
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 7y ago
  Web pages should be designed to load without js.
  - rimliu 7y ago
    Or rather anyone starting a new project should think long and hard "is this a page or is this an app?". Too many web pages think of themselves as apps without any real reason to do so.
    - mastre_ 7y ago
      Developers used to building apps find it much more efficient to build that way and, to an extent, it is. I've had developers straight up refuse to build "legacy" pages, and I understand their reasoning. Sometimes that is the reason, when another is not apparent.
  - dbtx 7y ago
    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
deleted 7y ago
[deleted]
T3RMINATED 7y ago
Wow you guys. Just use Wordpress or Drupal its the best.
numlock86 7y ago
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.
zemnmez 7y ago
> 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 ;)
tannhaeuser 7y ago
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
islon 7y ago
> 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 7y ago
  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.
a2x 7y ago
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.
londons_explore 7y ago
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 7y ago
  I read the article as "HTML is more than just <div> and <span> + CSS", rather than "HTML is the Web" (whatever that means).
tomxor 7y ago
> 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?
- barryhoodlum 7y ago
  I wonder how much of this is about the author's ego. They can't or don't want to delve into the (admittedly labyrinthine) world of JS, so there must be a matching lack of ability on "the other side".
- jamesgeck0 7y ago
  > 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?
ktpsns 7y ago
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 7y ago
  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 7y ago
    to be somewhat/slightly fair, the very next example talks about using a `ul` for the list.
    - notoverthere 7y ago
      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
- cjcenizal 7y ago
  “Semantic” eh? I don’t think that word means what the authors of the framework think it means. :)
- jsgo 7y ago
  This only seems beneficial if you're attempting to break compatibility with the browsers' built in understanding of ul and li tags (perhaps some concern that browsers will handle those tags differently in the future). Otherwise, they're just reinventing the wheel for the sake of doing so which may make for a fun exercise, probably shouldn't be used in a real project.
titanix88 7y ago
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 7y ago
  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.
m6g6a 7y ago
<custom-html></custom-html>
- rangerpolitic 7y ago
  You could actually do that with XHTML, and it was perfectly valid.
jypepin 7y ago
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.
snek 7y ago
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 7y ago
HTTP is the Web. HTML is just the superficial face of the web.
- BlueTemplar 7y ago
  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...
sloum 7y ago
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. :-/
CharlesW 7y ago
> 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.
andy_ppp 7y ago
My take is; everything will always get more complicated and you can write your nice simple articles but it will not help.
Lowkeyloki 7y ago
The author is right, but this comes off very much as "old man yells at cloud" to me. Sorry.
- Lowkeyloki 7y ago
  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 7y ago
    You can use React/Vue and still write semantic HTML, no?
    - Lowkeyloki 7y ago
      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 7y ago
        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.
deleted 7y ago
[deleted]
z3t4 7y ago
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.
Pigo 7y ago
Web Assembly, it might not become everything I hope it does, but it has the potential to be a game changer.
- SahAssar 7y ago
  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.
hypertexthero 7y ago
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.html https://www.thenoodleincident.com/tutorials/box_lesson/why.h... > 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 7y ago
  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.
rangerpolitic 7y ago
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-sections https://www.w3.org/TR/html52/sections.html#headings-and-sect... As the author suggests, they don't understand the tools they're using.
- SahAssar 7y ago
  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).
- icedchai 7y ago
  Or perhaps the spec is out of touch with reality...
mcgwiz 7y ago
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.
battletested 7y ago
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 7y ago
  Which GUI library would you use instead of HTML?
Slashbot 7y ago
HTML used to be the web... Now its a JavaScrap infested pile of fucking broken shit... No Thanks to the biggest fucking criminals of the web... GOOGLE Will be nice to see that useless fucking monopoly torn into shreds.
jonahrd 7y ago
> 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.
Zelphyr 7y ago
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 7y ago
  Yes! It’s about semantic HTML. For example, starting a Vue component with a <section> or <ul> as root element.
- ttflee 7y ago
  > 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. IMHO in the sense of fundamentalism all major frameworks tried to reimplement and resemble HTML (or its dialect) and browsers on existing HTML and browsers, which eliminated divergence of platforms for developers, relieving them from dealing with variations of users’ environment, i.e. the differences of browsers and HTML implementations. It was a transfer of control from client end to server end, from users to websites, implicitly.
systematical 7y ago
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.
kjgkjhfkjf 7y ago
HTTP is the web, not HTML.
gorpomon 7y ago
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 7y ago
  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 7y ago
    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.
player2121 7y ago
> 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.
stevage 7y ago
> 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.
grappler 7y ago
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.
kekeke 7y ago
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.
amw-zero 7y ago
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.
nashahg 7y ago
"HTML is not hard to learn properly, especially if you’re already accustomed to learning Javascript frameworks. I haven’t counted, but I’m pretty sure there’s only about 116 elements, and most of those you’d never normally need. Why would you not learn it?" Couldn't agree more.. https://finance.uonbi.ac.ke/node/115029 https://finance.uonbi.ac.ke/node/115029
guyromm 7y ago
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...

HTML is the Web

561 points by mmoez 7y ago

_pmf_ 7y ago

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

BlueTemplar 7y ago
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?

meerita 7y ago

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 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      By "the browser" you mean "Internet Explorer". The only browser that couldn't handle XHTML.
      - ricardobeat 7y ago
        With XHTML any syntax error completely aborts rendering, there is no fallback - the browser will display a native error page instead.
        sureaboutthis 7y ago
        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 7y ago
        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.

delibash___ 7y ago

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

onion2k 7y ago

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 7y ago
> 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 7y ago
  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.

2T1Qka0rEiPr 7y ago

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.

flohofwoe 7y ago

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.

ecmascript 7y ago
I don't think that is an unpopular opinion, since I am of the same. I agree with you that the URL is the most important feature of the web. Without it, you could just as well deploy native apps because it wouldn't really make that much of a difference. Without javascript and a heavy client side, I wouldn't have a job today since the application I build is simply not possible to create with just html+css. Sure there are many web pages that don't need to be a SPA, but a lot of other webpages do need it. I think an increasing amount of webpages are not simply text documents but we can easily see a move from traditional applications to web applications. It's obvious why, it is truly a "write once, run everywhere" scenario, it's easy to scale on many different devices and there is little to no advantages to write a native app in most circumstances. The document web has already been done, just use wordpress or whatever framework to create those sites but the new exciting web for me is the more interactive web where we can seriously move heavy apps into the browser.
- godshatter 7y ago
  What we need, in my opinion, is a new protocol. Leave http(s) for documents and make a new protocol designed from the ground up for interactive applications. That solves the problem of trying to shove an application into a document viewing sub-system and should allow for more creativity and efficiency, depending on what this new protocol turns out to be. What's happening now is like trying to force ftp to show documents, with markup, and forms, and so forth when it's just supposed to transfer data.

enlyth 7y ago

HTML simply does not meet the needs of the modern web. This fact makes a lot of people emotional and angry for some reason.

lpcvoid 7y ago
Maybe because people have vastly different opinions about what the "modern web" actually needs?
- enlyth 7y ago
  Opinions about what the modern web "needs" are great but they're just that, opinions, and everyone is full of them. What's important is what people actually want and use. I routinely see people bashing everything about the current state of the web, saying we should go back to static HTML documents, while their whole industry only exists because of the modern web, and they use Jira and Slack and similar tools to do the job that pays their bills. I just don't understand the logic behind this kind of thinking.
ksec 7y ago
My usage, as well as majority of friends that are non-geek, involves around - Scrolling through IG, Facebook, other Social Media, Forums, Online Shopping and News Site. Along with Video that in itself is a category as well as well as used within the previous few categories. News is arguably the biggest addiction of the 21st century, and IG, Facebook, Forum, are all really just "news". News about your friends, family, Celebrity, Tech, etc... I would bet the above represent more than 80% ( if not 90% ) of today's Modern Web usage. And all of them works with HTML + a little Javascript for interactivity. I don't see why it doesn't meet the needs of Modern Web.
- enlyth 7y ago
  This is grossly underestimating the complexity of IG, FB and the likes. Everyone likes to tell other people how they should build their stuff, that's the easy part. Do you think React would have been created if "HTML and a little Javascript for interactivity" was enough for Facebook to deliver the UX they wanted to? No, there was a business need, and what existed simply wasn't good enough, maintainable enough or easy enough to reason about to work.

sbhn 7y ago

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

grey-area 7y ago

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.

revskill 7y ago

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 7y ago
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.
- revskill 7y ago
  Imagine a newscomer learn directly React and its abstraction to produce a website. He actually did it without any knowledge of "real html".
- richardwhiuk 7y ago
  > Meanwhile, HTML is parsed by much more than a browser. Any examples?
  - magpi3 7y ago
    Bots and email clients. Microsoft word. Libre Office.
    - daveslash 7y ago
      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.
  - peterjlambert 7y ago

okaleniuk 7y ago

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.

onion2k 7y ago
When you're making a site like yours (which is awesome btw) hand-coding HTML and JS works fantastically. You don't need a framework. Frameworks only really start being useful when you're working at scale either across lots of data-driven pages or with multiple developers on the same product.
- okaleniuk 7y ago
  Yes, that's true. If you have lots of work to automate - sure, you need something to automate it.
quickthrower2 7y ago
As an aside, I like your blog and writing style, and the questions dropped in to make it interactive. COBOL ... I got that one. Funny!
NohatCoder 7y ago
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

thibran 7y ago

The web has become a compilation target. Vue -> HTML, CSS, JS

yoz-y 7y ago
Essentially yes. But I think the problem comes from the fact that it is at the same time a compilation target, and a pretty okay document markup format. I think people living at the edges of web apps and web pages are pretty happy, but the contention is when one is in between.
SquareWheel 7y ago
That's more literally the case with web assembly. With Vue, I guess I still see it as a form of transpilation.
- SahAssar 7y ago
  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 7y ago
    I understand that. But wasm sure does fit the description of "compilation target for the web".
    - SahAssar 7y ago
      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.

kowdermeister 7y ago

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 7y ago
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 7y ago
  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 7y ago
    It's easy to use. It's not easy to use well.

xparco 7y ago

I still don't understand all this React tuttiness

Dowwie 7y ago

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.

gargravarr 7y ago

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 7y ago
Web pages should be designed to load without js.
- rimliu 7y ago
  Or rather anyone starting a new project should think long and hard "is this a page or is this an app?". Too many web pages think of themselves as apps without any real reason to do so.
  - mastre_ 7y ago
    Developers used to building apps find it much more efficient to build that way and, to an extent, it is. I've had developers straight up refuse to build "legacy" pages, and I understand their reasoning. Sometimes that is the reason, when another is not apparent.
- dbtx 7y ago
  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

deleted 7y ago

[deleted]

T3RMINATED 7y ago

Wow you guys. Just use Wordpress or Drupal its the best.

numlock86 7y ago

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.

zemnmez 7y ago

> 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 ;)

tannhaeuser 7y ago

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

islon 7y ago

> 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 7y ago
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.

a2x 7y ago

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.

londons_explore 7y ago

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 7y ago
I read the article as "HTML is more than just <div> and <span> + CSS", rather than "HTML is the Web" (whatever that means).

tomxor 7y ago

> 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?

barryhoodlum 7y ago
I wonder how much of this is about the author's ego. They can't or don't want to delve into the (admittedly labyrinthine) world of JS, so there must be a matching lack of ability on "the other side".
jamesgeck0 7y ago
> 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?

ktpsns 7y ago

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 7y ago
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 7y ago
  to be somewhat/slightly fair, the very next example talks about using a `ul` for the list.
  - notoverthere 7y ago
    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
cjcenizal 7y ago
“Semantic” eh? I don’t think that word means what the authors of the framework think it means. :)
jsgo 7y ago
This only seems beneficial if you're attempting to break compatibility with the browsers' built in understanding of ul and li tags (perhaps some concern that browsers will handle those tags differently in the future). Otherwise, they're just reinventing the wheel for the sake of doing so which may make for a fun exercise, probably shouldn't be used in a real project.

titanix88 7y ago

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 7y ago
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.

m6g6a 7y ago

<custom-html></custom-html>

rangerpolitic 7y ago
You could actually do that with XHTML, and it was perfectly valid.

jypepin 7y ago

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.

snek 7y ago

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 7y ago

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

BlueTemplar 7y ago
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...

sloum 7y ago

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. :-/

CharlesW 7y ago

> 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.

andy_ppp 7y ago

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

Lowkeyloki 7y ago

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

Lowkeyloki 7y ago
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 7y ago
  You can use React/Vue and still write semantic HTML, no?
  - Lowkeyloki 7y ago
    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 7y ago
      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.

deleted 7y ago

[deleted]

z3t4 7y ago

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.

Pigo 7y ago

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

SahAssar 7y ago
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.

hypertexthero 7y ago

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.html https://www.thenoodleincident.com/tutorials/box_lesson/why.h... > 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 7y ago
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.

rangerpolitic 7y ago

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-sections https://www.w3.org/TR/html52/sections.html#headings-and-sect... As the author suggests, they don't understand the tools they're using.

SahAssar 7y ago
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).
icedchai 7y ago
Or perhaps the spec is out of touch with reality...

mcgwiz 7y ago

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.

battletested 7y ago

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 7y ago
Which GUI library would you use instead of HTML?

Slashbot 7y ago

HTML used to be the web... Now its a JavaScrap infested pile of fucking broken shit... No Thanks to the biggest fucking criminals of the web... GOOGLE Will be nice to see that useless fucking monopoly torn into shreds.

jonahrd 7y ago

> 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.

Zelphyr 7y ago

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 7y ago
Yes! It’s about semantic HTML. For example, starting a Vue component with a <section> or <ul> as root element.
ttflee 7y ago
> 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. IMHO in the sense of fundamentalism all major frameworks tried to reimplement and resemble HTML (or its dialect) and browsers on existing HTML and browsers, which eliminated divergence of platforms for developers, relieving them from dealing with variations of users’ environment, i.e. the differences of browsers and HTML implementations. It was a transfer of control from client end to server end, from users to websites, implicitly.

systematical 7y ago

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.

kjgkjhfkjf 7y ago

HTTP is the web, not HTML.

gorpomon 7y ago

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 7y ago
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 7y ago
  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.

player2121 7y ago

> 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.

stevage 7y ago

> 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.

grappler 7y ago

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.

kekeke 7y ago

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.

amw-zero 7y ago

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.

nashahg 7y ago

"HTML is not hard to learn properly, especially if you’re already accustomed to learning Javascript frameworks. I haven’t counted, but I’m pretty sure there’s only about 116 elements, and most of those you’d never normally need. Why would you not learn it?" Couldn't agree more.. https://finance.uonbi.ac.ke/node/115029 https://finance.uonbi.ac.ke/node/115029

guyromm 7y ago

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...