HTML is all you need to make a website
whitep4nth3r.com
whitep4nth3r.com
infuriatingly, if HTML had just a bit more oomph, we could make a lot better websites with it, but they haven't been moving HTML forward as a hypermedia for decades now (see https://htmx.org for what I mean, they could implement this concept in the browser in a week, and it would change web development dramatically)
the upcoming view transitions API will help:
https://github.com/WICG/view-transitions
but, still, there are some really obvious and simple things that could be done to make HTML much more compelling (maybe let's start by making PUT, PATCH and DELETE available in HTML!)
Yes. Has anyone ever purpose it?
hopefully at some point someone will notice it
Well, at least it's no trouble to include these two libraries and bring your clients into the 21st century of hypertext. But doing so without JS would be amazing.
Is this really that much better than POST http://www.mysite.com/thing/100/delete ?
GET and POST have actual client-side implementation differences. The rest is simply semantics.
I love REST but these extra verbs seem redundant.
PUT and DELETE correspond with U and D, so they make sense to include. PATCH is a little less obviously useful (partial update vs. a full update w/ a PUT.)
Regardless of our feelings about them, they are there in HTTP, the HyperText Transfer Protocol. So maybe we should make them accessible through the HyperText we are transferring.
IETF/whoever can write whatever they want, I only care about what I actually encounter. That's "standardization"
edit- All those nice looking checkboxes depend on the individual implementation. It's a nice concept but how many projects have actually implemented it to the conventions about idempotency/etc shown?
edit2- who is for-GET anyway? A random github link doesn't have much more worth than a random Medium link
It is a huge shortcut to map CRUD operations to HTTP verbs POST, GET, PUT, DELETE. By the way, the definition of HTTP verbs defined in the HTTP RFCs (from RFC 1945 to RFC 7231) and the original thesis from Roy Fielding about REST (which is defining REST principles as an architectural style) never talk about one-to-one relationship between CRUD and PUT-GET-POST-DELETE.
While I understand that it might be confusing without deep-diving in long-long-lectures, the last RFC explains clearly what is the purpose of each HTTP verb including the difference between PUT and POST:
The fundamental difference between the POST and PUT methods is
highlighted by the different intent for the enclosed representation.
The target resource in a POST request is intended to handle the
enclosed representation according to the resource's own semantics,
whereas the enclosed representation in a PUT request is defined as
replacing the state of the target resource. Hence, the intent of PUT
is idempotent and visible to intermediaries, even though the exact
effect is only known by the origin server.
Appending data to a resource's existing representation(s).
PUT /resources/xyz
The PUT method requests that the state of the target resource be
created or replaced with the state defined by the representation
enclosed in the request message payload.
They implemented an "Idempotency-Key" header that you could maybe call a "shortcut". Although it's not really deviating from HTTP standards. I guess it was easier and more pragmatic for Stripe and users to implement an "Idempotency-Key" header instead of duplicating each POST endpoint with PUT and PATCH methods since they also allow partial updates. I guess (again) that they would also have to use/implement additional header (such as ETag or If-Match) to replicate current "Idempotency-Key" header behavior.
Disclaimer: This last paragraph is full of assumptions and I most probably miss a lot of internal details from Stripe API.
The extra verbs make your URLs less redundant!
If anything I'd associate javascript with clunkyness.
I agree with you to an extent: I've had some very bad experiences with javascript applications as well, but the general sentiment is (reasonably, in my opinion) that a well done SPA will feel smoother than a well done MPA
W/ htmx or similar libraries like unpoly or hotwire, you can close this gap. The big difference is the ability to update partial bits of HTML, rather than needing to do a full page refresh.
I have done a few Angular and React apps to keep the skills sharp. The imposed workflow for the power is an interesting set of tradeoffs, never mind the magic and amount of decisions you need to make to use both.
Add on top of that the rest of npm, nvm, css compilers, the various css toolkits for layout, and the rest and it just feels so complicated, even for the most basic page which needs to pull in some data over an api.
It doesn't seem to be getting any simpler.
Lets say you want to sort all your posts by date and paginate the results (say, 20 results per page or something), as per typical blogging patterns. That's a lot of HTML cruft you gotta make for this to happen. Meanwhile, Wordpress / Jekyll / Hugo (etc. etc.) do this all automatically for you.
Personally, I prefer html with a little embedded css. It works, it's quick, it's all in one place, and it lets me produce suitably elegant pages.
Someone else said HTML-only websites are "ugly as hell." I disagree. They're beautiful."
Is the www an information system for hyperlinking and sharing information over an internet or is it something else. Is the www the software program (e.g., "browser") used to access it.
Imagine if people criticised books for the fonts they are printed in, how the paragraphs are formatted, whether they have images, and so on. Imagine if readers were forced to wear special reading glasses to see the text.
Generally, book reviews focus only on the textual content not the presentation. I wonder why.
Using a text-only browser (not Lynx, mind you), I can read content faster and easier, with less distraction, than I can using a graphical browser running Javascript provided by an advertising company. YMMV.
As it happens, I can discuss www content submitted to HN with folks who are using such graphical browsers. Yet I cannot see the same fonts, images or formatting, nor do I execute any Javascript. For example, I read the text of the OP website and I am commenting on it here, but I have no idea what it looks like in a popular, "modern" graphical browser running Javascript and controlled by an advertising company. How is this possible.
It seems to me there is a functional aspect of www content, i.e., information, that is independent of the software used to view it.
Web developers like to assume there are only a handful of software programs that can be used to view www content, and thus by manipulating those programs they can control how www content appears to the reader. In practice, given the takeover of the www by "tech" companies living off advertising and VC money, that may be true. However text is text. I can view and process it with an infinite variety of software. I can make it look however I wish on the screen.
The www can be whatever someone wants it to be, as text can be extracted and manipulated in an infinite number of ways. Users of the www can, in theory, process the information found via the www in any way they choose.1
1. For example, GPT-3 was created using a text-only corpus extracted from the www, namely Wikipedia and Common Crawl. Web developer Javascript is ignored.
You seem to be stuck in the era where the "web" was really about distributing text content - often blogs or articles.
I'd argue that's not really what the web is anymore. A good chunk of it still does that (for example - this discussion probably falls into that category). But there's a whole section that actually is distributing applications using html/css/js.
They are not distributing long form text. They are providing spreadsheets, collaborative word documents, rich monitoring and analytics solutions, custom CAD software (yes, really - https://www.tinkercad.com/), online chat applications, plus far more than I can list.
Basically - if there was a desktop app for something, there's probably a website version of it now too.
So - no, I don't agree that the web is just text. I also don't agree with your main focus comparing it to books.
Imagine the fucking gall it would take to walk into a comic conference and say this: "Imagine if people criticised books for the fonts they are printed in, how the paragraphs are formatted, whether they have images, and so on."
How out of touch would you seem?
If you don't want to run javascript - use a browser that doesn't run javascript, or turn it off in your browser of choice.
If you don't want to run js to play youtube - open the video url in VLC.
But again - I think you're glossing over the progressive nature of a lot of these applications. Ex: Youtube isn't just a video feed (despite what we'd sometimes like). It's an application with comments, streaming, voting, searching, sharing, and many more features.
Can some of those be done without JS? Yes.
Does it make since to use JS to implement many of them? Yes.
Can some of them only exist with JS? Yes.
Go click the "Go live" button in Youtube and then come back and tell me how you're planning on implementing that application feature in plain ol' HTML?
I submit they do not. Maybe YouTube has to have js for it's features but I don't accept that that's good. I don't accept that what YouTube, Twitch, Vimeo and Dailymotion provides warrants the need for each to have their own separate applications that have to be downloaded and allowed to run on my system.
In other situations - I'd argue you're just wrong. The simplest benefit of a web app vs a local app is exactly the isolation that the browser provides.
To be blunt - the applications from youtube/dailymotion/twitch/etc are NOT running on your system. They're running on the browser. They can't touch your files by default, they can't touch your other apps, they are uninstalled when you close the tab. That's incredibly powerful. It's incredibly liberating too. Users in places with fairly tight restrictions on installed software are almost always allowed to use most web apps (the limitation is usually concerns around inappropriate content - not so much security).
Basically - The browser is the OS that is literally designed around allowing you to run unknown code downloaded from other networks, from untrusted sources, with a modicum of security and consistency.
I think it's very, very hard to surpass the browser as a distribution method, and I think the possibilities it allows are, frankly, miles beyond basically anything else we've invented in the space.
Do some folks go overboard and create bloated, crappy web apps? Absolutely. Just like some desktop apps are complete pieces of garbage.
Does that mean we should throw the baby out with the bath water? My opinion is a resounding "no".
The browser runs in your system. The applications run in your system. This is as inane as saying any other interpreted language doesn't run in your system.
> they are uninstalled when you close the tab.
Except for all of the parts that aren't
There's no reason you can't achieve the same level of isolation in other runtimes. I don't think it's likely this would take off, obviously, we're already too deep into the browser-as-shitty-os rabbit hole.
I'd argue the problem is they create unnecessary web apps. Every damn corporation's and its aunt's (no matter how tiny mom-and-pop organizations they are) home page, basically just a fricking brochure, is an endlessly-scrolling blinking self-reformatting SPA nowadays, in stead of just a simple page that stays the fuck put in the browser so you'll actually the link you thought you were clicking.
(There, ya gots any more clouds for me to shake my walking stick at?)
There are code libraries and horrid Microsoft libraries for extracting information from Office documents, or API calls to Office itself to do so, but it is NOT EASY. And wow does Microsoft love this, because you end up buying office ... everywhere.
The modern web may not be so centrally owned as the Microsoft Office monopoly, but it does bury all forms of information under ludicrously bloated generated javascript / css. HTML actually is the forgotten stepchild of the javascript / css / html base of the web.
While WebAssembly offers hope for undermining the javascript monopoly, it probably won't help.
From where we are now, the data structuring and extraction is basically enabled by HTML. Javascript/CSS are obfuscators, not enablers to that. And to the point of many, that's how the tech industry likes it, because extractable / analyzable HTML pages are hackable and reformable and the tech companies lose control of "their" data (which is your data that you gave them, but that's another rant).
That is, they lose the ability to reliably get all the ad revenue.
Yup, thanks, that sums it up quite nicely...
Blogging? sure.
Making interactive content? a turing complete language helps.
Use cases, use cases.
If you really need a fancy store with shopping carts and wish lists etc., there are plenty of online services you can rent for small and medium stores. It's a wheel you shouldn't have to reinvent. But a brochure for say 25 medical devices/services shouldn't need any JavaScript.
Following John McCarthy, this HTML <b><i><u>Hello World</u></i></b> could have been written {b {i {u Hello World}}} and {* 1 2 3 4 5 6} could have been evaluated to 720. For instance: http://lambdaway.free.fr/lambdawalks
I think that would be awesome now using a modern IDE with great syntax highlighting and block editing. Back in 1997 when I was writing HTML in notepad.exe I think it would have been a bit less fun. Seeing the closing tag was incredibly useful.
1) {def b.i.u {lambda {:s} {b {i {u :s}}}}}
2) {b.i.u hello world}
3) {b.i.u anything sequence of s-expressions ...}
- http://lambdaway.free.fr/lambdawalks/?view=sierpinsky_compar...
- http://lambdaway.free.fr/lambdawalks/?view=fft
- http://lambdaway.free.fr/lambdawalks/?view=scratch
- and so on
Yes, most things don't need to be SPAs or implement cutting-edge CSS features. That doesn't mean you have to build your website in pure HTML.
PHP is incredibly easy to learn and provides immediate benefits without negatively influencing your page's performance.
For CSS, there are many prebuilt stylesheets out there that are easy to implement.
Like learning the joys of debugging missing semicolons.
Any modern IDE built within the last 20 years would not only highlight where a semicolon was missing, but would also be able to tell the difference between a semicolon and a Greek question mark.
Intellisense is a really nifty feature.
While I agree somehow, we live in 2022 with high broadband and powerful browsers/CPU.
Let's not limit ourselves for the sake of it. We can do simple javascript, lightweight images, etc...
Now if you tell me I shouldn’t because it’s less likely to make me a billionaire, I might want to listen.
Some of us do. I think it's important to keep in mind that especially those of us living in tech hubs are in a highly distorted bubble when it comes to tech — for us, things like gigabit internet and 1-3 year old top of the line phones and laptops are the norm.
Beyond that bubble however are a lot of slow internet connections (sub 1mbps DSL is still a reality for many North Americans) as are computers that are either pushing between 5 and 10 years of age or are of similar power to computers that old (think bargain bin x86 laptops and Chromebooks).
Occasionally I'll pull out my circa-2008 Dell laptop (which can still run modern operating systems fine) and use it for a few hours to remind myself of this. It mostly does fine until I have to use some unnecessarily heavy website.
But this doesn't have to limit you to html only websites. 2008 (or 2006) js was perfectly fine for most tasks.
Problem is, light JS and small/optimized images are becoming more the exception than the rule. When devs have ample bandwidth and powerful machines they're much less likely to carefully weigh every dependency and unnecessarily large image.
In my area the ATT only provides internet that runs 18 mbps maximum. Its infuriating when I am browsing a javascript-heavy website at peak hours and it takes forever to load. I don't think HTML-only is necessarily a good idea, but less javascript for basic things that HTML does well anyway is certainly welcome.
I live in a suburb outside of a large metro area. Not at all considered rural. The only internet provider we had when I moved from my old house to this new suburb was Xfinity (Comcast). The ISP I had previously did not have service in my area and after an exhaustive search, the best I company I could find that WAS NOT Xfinity was a commercial DSL line with a dedicated 5Mbps up and down line for the same cost as and Xfinity line with a 400Mbps up and 15Mbps down. It wasn't even close. I also had to have this company install the line which would've been even more money.
In the end, it was pretty surprising how many areas still only have a single choice for their internet service.
The other way around, I assume?
I don't know how many high speed connections a moving train has, but when I cannot load a simple mostly text website, then some people on board apparently are doing other things than I am doing on that shared connection. One hunch I have is, that they are downloading many megabytes of bloat JS libraries, while I am trying to just read some text on a website and have mostly JS blocked. Some more might even be watching movies or running big downloads or windows updates or whatever.
Anyway, one result of bloated websites, even if we have high speed connections in our homes, is that we struggle with the shared connection, like on a train. If every Billy needs to load Facebook, Instagram, YouTube and whatnot, it surely is not going to improve the situation for other people on the train. Of course another reason might be, that the train's connection is bad in the first place.
This should be enough to render text-based sites. E.g. HN or news sites. But the reality is, that basically no side is able besides HN is usable at that internet speed. Soo much content out there could be accessible at that speed. Sure no videos or images. But everything text based should still work.
There are probably a lot of tools in the webdev-toolbelt that would allow to allow even e.g. image heavy news-sites to be usable during images and scripts load.
Yes, let's limit ourselves a lot, I shouldn't require a modern M1 to use the web. In fact, Javascript shouldn't exist, because the industry apparently can't use a super optimised runtime correctly.
It would be nice if this were true but we're far from it. High broadband is not a given, browsers are slow (yes), CPUs stopped scaling vertically and don't compensate for bad programming anymore.
It seems to me that the choice of not using HTML-only has more to do with the inability to do so, rather than the desire to not limit oneself.
That's why I write
> Let's not limit ourselves for the sake of it. We can do simple javascript, lightweight images, etc...
There are millions of Americans who do not have this luxury. And let's not pretend it's not a luxury.
Just a couple of weeks ago there was an item in the news that a million people in New York City who do not even have cell service in their homes.
I think it was in the Times article about the 5G towers popping up everywhere.
Whether that (among other cases) creates an obligation in everyone to account for semi-failure and full failure (let alone retreat to pure markup) is another thing, of course, but the industry would be better and its practitioners more deserving of the term "engineer" if we did.
I'm not averse to javascript or to images(my site is almost all images) but the slowness of so many sites these days says the high broadband and cpus can't keep up.
And maybe someone can explain this to me but why does going back in the browser seem slower or more intensive than loading a new page? Is that because the broswer itself is trying to load the previous state?
There's plenty of situations where one or both of those statements are temporarily untrue and plenty more where they're permanently untrue.
Most users don't have flagship phones or brand new MacBooks. They don't have ultra fast WiFi or 5G. Even if they have more powerful devices they might be on shitty school/Starbucks/public/office WiFi.
You don't need to build everything like it's 1996 but it's absurd to simply assume every user is on a MacBook with gigabit Ethernet. The web is full of terribly built web pages pretending they're "apps" and using megabytes of JavaScript to show some text and images.
That's a bit smug. I live in one of the richest nations in the world, and still much of the country has only slow connections available. Even those have often become intermittent since waves of climate-change enhanced disasters have started regularly sweeping away much of our infrastructure. Those disasters have also further impoverished much of the population, making it hard enough for many to keep a roof over their heads (thousands living in tents and caravans), let alone 'powerful CPU's.
I agree with the concept of just using HTML (and CSS), but the examples people chose are so bland!
Of course we all know something like:
<?php include 'menu.php' ?>
But in order to get that working, the site can no longer be HTML-only, it will need a web server and pages must be titled .php. This assumes most people are building multi-page sites, and not those one-page "link in bio" style pages.
Here is some apache documentation: https://httpd.apache.org/docs/current/mod/mod_include.html
It didn't feel "real". I had never seen web pages with those extensions. Frankly, I hadn't even seen .html pages in several years because everybody edits the .htaccess file to prettify the URLs.
I ended up biting the bullet and going with PHP. Surprised to learn that there still isn't anything out of the box that handles this.
SSI like those from apache acting in otherwise the most privative form of server just using paths and no routing produce the kind of repetitive HLML that iframes via the client produce.
[1]: http://sgmljs.net/docs/producing-html-tutorial/producing-htm...
There really should be an <include> element. e.g. https://www.w3.org/TR/xinclude-11/
actually, scratch that. transistors.
or no wait, a mancala board.
a game of checkers, etc.
:)
- Carl Sagan
Well, we can always agree to disagree.
I started learning HTML in 2001 (or 2000) and typically plain HTML websites at that time were boring, so there were some ways to enhance it, e.g Flash.
I took a different route: DHTML, and then website development felt more fun. Perhaps the point is to use CSS/JSS libraries/frameworks sparingly.
Presumably the author of this post, with of CSS and JS? Ironically They even specifically say to not do this
> If your content is readable and accessible without the noisy bells and whistles of loading animations and a fancy-pants design, then ship it
are we counting the Tweet-embedding iframe on the page as "just" HTML?
e.g. you can build a website in pure SVG without even wrapper HTML docs. (may need a server tweak for directory indexes though).
But I'd rather not hand write content in HTML and have limited ability to change themes without editing every page, and have to update links in indexes every time I add a page to make it visible, and need my laptop or SSH client on a phone to write.... a flat file CMS does a lot.
The wholse site uses a lot of unnecessary css/design.
On the other hand, 15s pageload times seems poorly optimized.
People vastly underestimate DX, unintentionally gatekeeping technology while feeling like they "sticking it to those pesky Devs who overengineer everything!!!"
At least that's how it's supposed to be.
If you can't do it, I understand.
a) Conservatives: "HTML is just fine as it is"
b) Progressives: "HTML is a great idea but needs a little more work to be a great implementation"
It's not a little more work, it's reimplementing things browsers and servers already do with JavaScript replacements. They deliver a naked script tag and then do everything in heavy JavaScript.
The people that I want to read my content?
And yeah, lots of sites are far too bloated with CSS and JS and whoosiwhatsits. But a couple of kb of CSS will make a website much nicer to consume, and won't impact loading speed to any noticeable degree.
Assuming an average line of CSS is 30 bytes, that's 66 lines of CSS. That definitely should be enough.
I would argue that if on a diet, 20 lines of CSS should be enough to provide a very readable, aesthetically inoffenseive website.
If browsers had consistent, sane defaults which were designed for readability, then CSS wouldn't even be necessary for most information sites. The symantics of HTML tags were observed uniformly, sane defaults could be assumed.
Where are the metrics? Who is the target audience? What is the distribution of hardware among this target? A dramatic increase in performance on a potato might be imperceptible on the latest hardware, lessening or even eliminating the impact of your technology choices.
A dramatic increase in accessibility and end-user experience is also pretty hand-wavy. How did you come to this conclusion? Any examples? I don't see how HTML-only is tied to these things. You can accomplish or fail both with or without heavy CSS and JS.
None of the sites she links to make the case for these assertions. Am I missing something?
> Why all this backlash against HTML-only websites?
What backlash? I see the HTML-only rhetoric so often these days that it's clear this position is becoming rather fashionable.
They're using Eleventy and Netlify, those are not HTML either; Eleventy implies they start with markdown too I think?
I'll forgive them image formats and the .js file for Twitter. But, they follow up with a heap of "lets use tables for design" examples, always hated that ... I'm nope-ing pretty hard there.
I started writing HTML in the 90s using Pico, my roots are purist, but no, not really ... you need styles for a11y, you want styles for user comfort and engagement, even minimal things like favicons and svg. We've come a long way, yes, bloated messes like Sharepoint spews out are abysmal, but to make a website that meets any reasonable standards ... you need more than just HTML in this dinosaur's opinion.
I do agree with your points about what is necessary these days. A dash of CSS, tables only for tabular data, other small touches. Like, that's a more reasonable standard for "what is necessary". And to me, I think your comments are in line with the spirit of the original post.
You read it and if you have anything interesting to say about its content, you write that. Picking apart the implementation details of the site itself just brings the unseriousness to HN which is why the site guidelines ask you not to do that sort of thing.
If someone indulges on a beef steak while talking about something, that would be tangential in most circumstances, except when the talk is about the benefits of veganism. You're creating a strong dissonance between your message and your mode of delivery.
What the guidelines do discourage, however, is commenting on whether the article has been read.
is commenting on whether the article has been read.
They do, which is why I didn't.
One of the ideas expressed in the content is to use HTML tables for styling and aligning content - using grid and flexboxes flies in the face of that suggestion.