I sympathise with the main thrust of the post but, to nitpick, this is just plain wrong:
> But mostly css appeals to our vanity and ego.
Design isn't just about aesthetics. Good information design, clear visual hierarchy, accessibility, etc. all help with communication. The author's effective use of spacing, bold, and code tags show us that they know this intuitively, despite what they write.
I was happy to see someone finally referred to the motherfucking websites.
On the other hand, I was disappointed to see the unique one of those I think it is worth to follow the advice [1] was not cited.
For curiosity reasons, I found out about [1] on a well-known website [2] that definitely puts content in front of presentation, even though I like their website's design.
The source is on GitHub, you're basically looking at "machine code" for the browser. But if you want to verify it's the same code, it isn't obfuscated, so just run a beautifier over it and compare. Best of both worlds.
In my mind "raw browser" look corresponds with "almost insane details coming" as the only sites still using that are often run by people who are WAY more concerned with the content they want to talk about than with the presentation.
Um, shouldn't all people be WAY more concerned with the content than the presentation? I don't want to read stream of consciousness with occasional lack of spaces and random case, but I'd really prefer to only read websites by people who give zero effs to presentation, and I had prior to this moment assumed everyone agreed, but that it was fun to do presentation, so people did. There are people who care about the presentation of what they are reading on even close to the same level of the content itself?!
Totally agree. For me, the original is far easier to read than the "better" or "best" versions.
Initiate rant mode:
- The gray on gray is like a joke, except it's not. I get the theory and alleged benefits. I get that some do prefer it, especially for IDEs. I get that some are happy to see (or at least apply) it all over the web. It just does not seem to apply here. Man alive. Literally making it harder to differentiate the text.
- I don't mind adjusting the browser width to get the lines exactly the right length for my screen and reading preference. Actually, I far prefer it over all the other options. This is like a tragedy-of-the-commons or lowest-common-denominator or dumbing-down-on-the-false-premise-of-being-smart issue. Instead of utilizing what we have, and encouraging people to learn and become capable with the simple and flexible tools, it's one size fits all (or, you pick the size you think I want). Only it's not.
LaTeX predates HTML by a decade and supports pictures, charts, quotes and far more, and doesn't force me as an author to make finicky decisions about presentation. I just write the content, and then set the document class to whatever the publisher wants.
It's also a great example of how even such a little can go wrong.
The CSS of the second website is wrong, as it uses 'color' without setting 'background-color'. Assuming anything about the default background color is not possible because it is user-configurable in most browsers.
At least http://motherfuckingwebsite.com remains readable when you change your color settings (the second one is completely unreadable on my browser).
<style type="text/css"> ? what are we dinosaurs? You might as well leave out the closing <p> tags if you are going to be like that.
If the whole point of your website is to brag about code to accomplish reasonable formatting.... can we at least have code formatting? I think I have enough bandwidth to afford some line breaks.
Clicking on the first website, I can't even view it because it's asking
for captcha.
So, to extend your comment: you do not need to worry about content if your
website isn't even reachable. A GET request should never result in the client
being bombarded with captchas. Unless you have a sure fire way to determine
if said client is a human or an evil AI taking over the world (nobody does),
just serve the damn page.
I’d never seen thebestmotherfucking.website! I appreciate the nuance it adds. I don’t have any nuance of my own to add right now but I do have to share my amusement at the empty list item under contributors. I figured there would be something in the source referencing someone (similar to how some folks on Twitter make special acknowledgments for people not on Twitter), but if this was that it’s a very Inside Baseball reference:
<li><a href=""></a>
</li>
Or it could be a joke about copypasta in hand-authored HTML. Or just actual copypasta. Who knows! But I enjoyed it.
prose.sh hits a sweet spot for me. Not just in the minimal-but-rich-enough presentation of blog posts[0], but also (off-topic for this thread I guess) the simple interface: just scp your markdown to prose.sh.
You make it sound like an unequivocal truth; it isn't really so. I launched my own hobby website/blog only after I designed my content presentation. It helped me understand what I was writing. Of course I had the underlying drive to write something already, and was not coding up some CSS without a vision.
Everybody finds their writing juices differently. Push where it means you'll write more.
Could you elaborate? The first one is uncomfortable to me if you have a large browser window, because the lines of text are so long and it’s hard to follow. The second one at least fixes that problem.
The default Emacs theme is not great, but the current best practice is to stop messing with themes and just use modus (vivendi or operandi depending on your light/dark preference), especially since they are now included as part of Emacs.
Yeah, I actually like the oldest of the three best. The one with 7 css declarations was annoying to me somehow and the third option was garbage. I miss websites that were about conveying information.
I've been arguing that HTML would've been a much better information-carrier if "basic browser styling" did this. I'm quite certain that a large part of the web would need no CSS or just a few lines of it, if the basic (browser applied styles) were good. As in: designed by (information) designers. They could even differ per browser, as long as all of them were good (or really good).
But alas, base styles are a mess (yet still there!). They do have some hierarchy but accessibility and readability are bad. That's aside from aesthetics: just stuff like alignment, spacing, fonts, flow: very poor.
I am aware that more base styles would make that cursed "reset.css" even larger, but I guess if a large part wouldn't even need that, it would be fine. It would be a situation where everyone can choose "good styles" or "spend lots of effort to get even better, custom, styling", rather than everyone "spend lots of effort to get an even decent styling".
Honestly - it'd be pretty nice to be able to opt-in/out of the default user agent styles applied by browsers. If we really want to preserve compatibility - opt-in to a version.
Keep it all the same as current if there's no tag on the page, but if you add something like <meta uastyles="1.0.0"> or something, apply an improved set of default styles.
Get rid of the need for resets with <meta uastyles="none">
Basically - I'd love a way to allow browser vendors to dramatically improve the defaults without breaking everything, and also giving frameworks an easy opt out.
I agree that defaults are not perfect, but I'd like to add that the initial idea was that they are, well, defaults, and you -- as a user -- are supposed to adjust them to what you prefer. In some dashboard usually called "preferences" or "settings". And fact is that you still can: you can tell your browser "for this script, for serif, use this font family, for sans use that one" etc etc. You can set you preferred text colours. You can even write your own style that will sit between user agent styles (those "ugly defaults") and author styles (those forcing weird stuff). Initial idea was that our browsers will be truly individual tools and one of their main task will be consolidating those preferences from various sources. That's the "cascade" in the CSS.
Yes, I know. Back in the fun days when a browser was supposed to be my "user" agent. Before they became the mini-os they are today.
There's nothing here that would stop you from still doing that.
But if we're talking about practicality... I think far more people would get a benefit from improved defaults (as long as they're not breaking existing sites).
While I've modified the user styles for my chrome profile as a part of being a web developer, I'm not aware of a single non-developer acquaintance who has (literally - none). Honestly, not even many of the devs I've worked with have done it.
It's just not all that relevant when the defaults are so bad that all the sites are overriding them anyways. Makes it very hard to apply a set of user styles that's sane, so no one does.
Make the defaults better, and maybe you can end up back there.
I want to hug this whole thread. Yes, 1. browsers should improve their defaults. 2. web sites should respect user preferences over their own style, if the preferences are set. 3. browsers should make user preferences more prominent and provide an easier way to override web sites that refuse to honor them.
My browsing experience should not be determined by an artist or product designer 1000 miles away from me in an office somewhere.
My language skills and time pressure fails me here, just wanted to express general "thanks folks" for your reactions as well. Seeing that someone shares similar point of view on this topic made me surprisingly very happy, so thank you again.
I think the main point is that, balance is also a very important design decision. A bit of CSS can go a long way; a lot of CSS can become a nuisance. There is definitely some 80/20 sweet spot where you get most of the design you need from a little CSS; finding that sweet spot is the challenge.
Javascript transitions/animations, on the other hand... yeah. I won't got there.
I agree, I get the idea that a blog doesn't have to be fancy, but a simple css theme with nice spacing and good font size goes a long way. The examples they show makes me click away instantly, because it is so damn hard to read.
Also possible the typeface is compatible with the readers and the content they regularly consume.
Hell, that typeface is something anyone is subjected too if you do anything long enough.
The experience of getting to imagine how much thought goes into laying out text on a typewriter is something I think should be for everyone to try at least a few times.
In my personal, obviously anecdotal, experience it's always the "technical" guys who think things like this. This is why we have UI/UX teams and we don't let programmers create visual interfaces.
If your idea of a good site is a 3MB monster full of useless whitespace, hero images, carousels, hamburger menus and other modern design trends, maybe that's a sign we shouldn't let designers create visual interfaces.
I really dodged a bullet there huh? Since that isn't my idea of a "good" site necessarily. But if your idea of a "good" site is all function and no form, then maybe stick to designing abstract interfaces and not things actual people have to see.
Why are you even browsing websites that have any design then? Why are you even browsing in anything other than lynx? Please spare me seeing that ideologically boring site again
Like I can barely imagine what your house might look like. Just like a purely functional weathered hovel with the absolutely barest essentials. A perfect prison cell
Because reading words requires substantial styling enhancements over what the browser is already capable of? Has anyone picked up a book lately?
You need a UI team to create a page of readable text? That sounds like an expensive waste.
But it sounds like those 'UI' people think they know better and don't need suggestions from programmers about reading words, even though its what they do all day.
It's very funny that you seem to think reading code and reading a website are the exact same type of activities, and the same type of reading. They are not.
And I don't know where you've been for the last 30 some years, but the web is not a text only format, and the reason HTML was invented was specifically to be able to create a designed space where text can actually make sense and is not a gigantic wall of impossibly small black on white text.
Sounds like you ought to be doing the Richard Stallman approach to reading webpages and not commenting on whether or not CSS and design is needed. Back to the terminal with ye
Sounds like you should do less stereotyping of roles. You’re assumption that programmers don’t understand UI and need to stay away is exactly what the blog refers to when talking about ego. You think programmers output all their work in a terminal?
I understand this and that's all well and good. Many (but not enough) offer "print" versions of pages, which could and should be translated to "text only" versions of pages. This isn't my issue. My issue is these <redacted> imagining that the web outright doesn't need design at all and that CSS is a terrible waste. And to me this is just about the most dull opinion on the subject that I can think of.
> My issue is these <redacted> imagining that the web outright doesn't need design at all and that CSS is a terrible waste.
While you do have some going to that extreme, I think it's mostly pushback against the insane amount of bloat and overbusy design out there. Some CSS can be useful, to improve readability and offer a little visual appeal. But I think maybe you missed my point.
Traditional books are typeset the way they are for a reason. No or minimal pictures. Block after block of text, broken up and spaced for readability, comprehensibility, and flow. Different types of books are laid out differently, but they mostly follow this theme. It's highly effective.
You kind of broadly have 3* categories of web pages on the web, as relates back to print:
* Book-types (mostly text in nature)
* Magazine-types (more about graphic design, with content mixed in)
* Advertisement flyer-types (sales pitches, mostly about design)
These are going to have different design requirements. There's plenty to write on the subject of design for these categories, but in the interest of getting to the point: there's an awful lot of the first category on the internet, and it really requires very little in the way of CSS. It certainly doesn't require hero images and 10MB of javascript. Blogs should read like newspaper articles, technical content should be typeset with similar minimalism to technical papers or books.
* There's a fourth category: webapps. My personal stance is that these don't belong on the web at all, but given that they're going to be, they obviously have far different design requirements, and are quite outside the scope of this discussion.
I like it because it means they will never be my competition for anything but incredibly niche/domain-specific boomer software people have no choice but to begrudgingly use.
> scroll the mousewheel: giant footer section slides up taking half the viewport
> move the mouse cursor up: giant ass header slide menu drops down covering half the viewport
should be absolutely no motion on a page unless i specifically click on something, like play button or slide out button. and that includes parallax bullshit.
prefers-reduced-motion should be the DEFAULT not an override. ffs haven't we learnt anything in the last 20 years of web dev - you cant rely on web monkeys to build things right (\s).
---
and f*k you to whoever thought having mouse hover popup autoplay boxes on youtube was a good idea.
A lot of these things were handled by one typeface on a typewriter so the premise isn't entirely unfounded.
Visual communication and design predates CSS. Information architecture, design, guiding the user through the message is definitely a skill.
CSS can do as much distraction as it can enhancement. It's one appeal of Tailwind, it's more than serviceable while learning about the design, hierarchy, and flow.
100%, and calling aesthetics an appeal to vanity and ego is a reductive take. I love that individual’s websites have different styles which reflect either them personally or their brand.
That can mean going all out in design, or having an HTML-only page like nothing. Both have value in their own way, and should reflect the creator to some extent.
But, you can get all of these things from HTML. Especially visual hierarchy and accessibility. The cornerstone of accessibility on the web is: does it display legibly and is it navigable without any CSS? CSS is eye candy. It's aesthetics. Those are not without value, but the value is not in the things you list.
Well, that was what HTML was on track to give us. But once JS and CSS were introduced, semantic HTML that was actually semantic stopped developing, under the assumption that if someone needed, for example, a tab area or slide show, they could develop those themselves with CSS/JS. What we've gotten instead is extremely vague elements like "section" that don't communicate what the elements are.
If HTML were truly semantic, browsers could implement accessibility features around it, but because they're so vague, there's no real way for browsers to do that, which offloads the responsibility onto web developers, who in most cases aren't granted budget to do it. There are a handful of features such as alt properties, but these are pretty limited.
So yeah, HTML should give us that, but that's part of what users gave up when we decided it was acceptable to allow random websites to run code on our machines and tell us how our content should be displayed.
There was never a golden era like you describe (it was a time of conflicting philosophies, people saying "eh, let's add this, that would be sweet", and browser vendors competing to add as much as possible to out "innovate" each other and the limited specs), semantic HTML helps in some cases but is never going to give you automatic accessibility, and a one size fits all browser style is still not going to give you what you need even as you add increasingly unsemantic tags to try to improve it (which is exactly what was happening pre-CSS).
> There was never a golden era like you describe (it was a time of conflicting philosophies, people saying "eh, let's add this, that would be sweet", and browser vendors competing to add as much as possible to out "innovate" each other and the limited specs)
I did not describe a golden era of HTML, because a golden era of HTML never happened. Instead, it was precluded by the introduction of JS/CSS. Had JS and CSS never been invented, we might have achieved a golden era of HTML, but we would have needed web standards to mature before that could happen. What happened was, web standards did mature, but they matured to serve websites rather than users. As a result, mature web standards center around JS and CSS, leaving HTML anemic and weak.
What we have now is a time of conflicting philosophies, with websites competing to add as much as possible to out "innovate" each other. Users still suffer the same inconsistent interfaces they did in 1997, it's just that instead of browsers being inconsistent, it's websites that are inconsistent.
Well, there was a previous garbage area, when HTML was, rather than being semantic, laid out using tables and \<color\> and \<font\>. I remember telling people to not do that, especially when the first version of CSS came out, and you could make websites look nice with semantic HTML that also worked in Lynx.
Table layouts are still superior to CSS in that they achieve the Holy Grail layout. As far as I'm aware, CSS still fails to achieve the Holy Grail within any reasonable realm of effort.
Hell, the entire reason the internet moved from Holy Grail layouts to singular sidebar and vertically integrated layouts was because CSS can't into Holy Grail.
With how wide most users' monitors are ever since 16:9 became commonplace, Holy Grail should be the ideal content presentation layout because it uses all that free space on the sides for non-content (eg: navigation) so precious vertical real estate can be dedicated to content.
This doesn't add up. CSS grid, flex box, etc all do the "holy grail" layout with a couple lines. The tables mess that was early www was and remains an absolute mess of markdown to maintain for layout. Semantics and accessibility are practically out the window with table.
HCI dictates how humans use interfaces and with that comes many defacto reasons why a plain text page does not solve the problems users want to solve. Do you not think websites test into the optimal performing layouts and content distribution? If it worked better, we'd all be using it (it doesn't).
I agree with you, but also I think the section tag is one of the biggest leaps forward we've had. Putting an id on a whole section instead of a name= crap for references, and actually using nesting for hierarchy.
All the HTML5 input types are also an example of semantics impriving. It could be way better, but it's not a total stalemate
> I agree with you, but also I think the section tag is one of the biggest leaps forward we've had. Putting an id on a whole section instead of a name= crap for references, and actually using nesting for hierarchy.
How does this differ from how <div> was being used before?
I've switched to using <section> simply because it's a better name, but I'm not sure it's made any meaningful difference in my code.
Another example of the pointlessness of this issue is <em> and <strong>. I've rarely seen code where these weren't used exactly the same as <i> and <b> were before. In rare cases, I've seen someone do something like make <em> a different color rather than italic, and that's almost always been a bad idea, because when HTML authors use <em> they almost always intend for it to be italic. In fact, I'd say we should just continue using <i> and <b> because those communicate intent better, but at this point I've worked in too many codebases that decided that <i> could be hacked to mean "icon" (i.e. using FontAwesome) which is a horrible, awful, no-good, bad, hack.
> All the HTML5 input types are also an example of semantics impriving. It could be way better, but it's not a total stalemate
That's true, but I think we'd be moving forward a lot more quickly if we weren't devoting most of standards development resources toward giving companies more fine-grained control of our browsers through CSS/JS.
My e-book reader shows <em> text with teal color and I like it, it's better visible than italic and the font remains upright and readable, I doubt it will be comfortable to read lots of text in italic. I didn't notice any discrepancy with <i>. But for some reason <strong> doesn't override <em> and they multiply, though I saw it used once when an exclamation was repeated several times with increasing emphasis for extra dramatism.
It would be so great if there were more built-in interactive elements like tabs, modals, and tooltips. How many times have these incredibly basic things been re-created?
Yeah, all this time browser vendors should have been taking a "pave the cowpaths" approach to natively implementing stuff that everyone ends up reimplementing in CSS and JS. And HTML5 did a little of this, with e.g. date and color input fields. But they could have gone farther.
To disagree with my own point a bit, it’s unfortunate that the controls HTML5 added look different in every browser, and can’t be styled with CSS at all.
I'd say HTML for itself just gives us a way to give meaning or imply how something should be styled "headline of first order". In the end it's a markup language, not some magic styling tool.
How it is actually styled (in absence of CSS) is in the hands of the default rendering of your browser. That might very well be a very bad rendering, due to lack of knowledge/time/engagement of the people building/maintaining that renderer.
Also those renderes might come from a time and system where technical limitations where different, markup was different, lots of things were very different.
So I don't think we should expect HTML alone to "look nice" or work well in regards of readability.
> I'm quite certain that a large part of the web would need no CSS or just a few lines of it, if the basic (browser applied styles) were good. As in: designed
I think we would win a lot if browsers default styles were beautiful (as in: really good, not merely fancy) designed. Many websites then would need just a few lines to set some colors, style that weird-custom thing they do or make it feel just a bit more personal.
I think the bigger thing would be to have more semantic HTML. <dropdown>, <tab-area><tab>Content</tab></tab-area>, <carousel><slide>Content</slide></carousel>, <rich-text-editor>, etc. Instead we've got a million immature implementations of these that are slower because they are written in JS instead of native code, slowly break over time as they aren't maintained, and typically have terrible accessibility.
Yes. HTML gives the structure and hierarchy (if done properly) which is also what then gives the accessibility. CSS can do lovely things that will help a blind user with a screenreader not one bit unless you're kludging in "hacks" to give them extra hints for specialized use.
As a good example, his site is very readable (because of the limited width of lines), and the sites he linked to that were largely unstyled were very useful, but not very readable. It would be worth it to me, as a user, to use a browser plugin to add a few lines of CSS to those sites before I dove in.
Even folks who say content needs to be figured out before presentation... it's not so cut and dry. Your medium shapes your message - they are not mutually exclusive and for the receiver of the message, the medium matters for their reception of the message.
I understand the sentiment that TONS of CSS is probably a bad use of time. But trying to demonize or otherwise attach aesthetics the label of "meaningless" is, in my opinion, just as much egocentric as they claim CSS to be.
It's also the case that the default stylesheets for the web are terrible, for historical reasons. If the default stylesheets were reasonable, then at least 80% of the time you could just use semantic HTML5 and be sure that your presentation was at least OK in terms of visual hierarchy, accessibility, etc. As things actually stand, you need at minimum "100 bytes of CSS to Look Great Everywhere", and if that doesn't meet your needs, a classless stylesheet.
Why dismiss aesthetics out of hand like this, equating it with vanity and ego? Aesthetics are very important to people, possibly even more so than the information on the page.
FWIW, I agree with you (and I don't see where I dismissed it), but the point is that even a certain type of utilitarian-inclined programmer is wrong on their own terms.
Obviously, that depends on the purpose of the page/site. If the page is a brochure or advertisement, content is almost irrelevant; you could link to it, for buyers that wanted content. Brochures and ads are about feelings, and aesthetics are about feelings.
That's not what I think the www is for, but not everyone agrees with me.
Some years ago I was interviewing for head of automation position, and in the process was asked how'd I go about making sure a Web admin interface (to a product that by and large doesn't need a Web interface, think, in the same category as Kubernetes) is well-tested.
To which I responded that I'd not use any JavaScript. Ideally, XML with stylesheets. Very light-weight, renders extremely fast, and is extremely friendly to automation tools (doesn't even require a browser for most tests). For the kind of product this was intended for, and I still believe it to this day, it would've been perfect: nobody needs any CSS animations there or any kind of interaction beyond filling forms and submitting them.
One of the interviewers was the head of the front-end department. He hadn't for a moment considered this to not be a joke, but pretended to answer this seriously by explaining that if they don't put a fashionable JavaScript framework into job description, they will not be able to hire front-end programmers.
In reality, there are plenty of things on the Web that could, in principle, be just HTML or, as in my example, XML + stylesheet, but won't be for no reason other than to feed the echochamber of the job market. Nevermind that from the business side this makes user experience worse, costs more to host and to maintain, and yet...
> if they don't put a fashionable JavaScript framework into job description, they will not be able to hire front-end programmers.
This is exactly why we are vague with tech stack in our job reqs. Why would you want talent that is laser-focused on specific keywords? What is the average lifetime of a JS/CSS framework? The game isn't to come in knowing this crap. It's to grasp fundamentals such that you can quickly learn the next ones.
I much prefer to hire less "skilled" employees who are more interested in the problem domain or product than they are any specific tooling. Goal-oriented developers can be taught to do anything in my experience.
> I much prefer to hire less "skilled" employees who are more interested in the problem domain or product than they are any specific tooling. Goal-oriented developers can be taught to do anything in my experience.
A million times this. When I've hired, the specific languages/platforms/whatever the applicant has is of tertiary importance at best. What counts is the ability to engage in problem-solving, how well they will fit into the team, and how readily they can learn.
I agree, but here's the catch: if you're looking for this kind of employee, you won't be hiring "less skilled" people, you'll be hiring "more skilled, more expensive".
What people mean by "I will not be able to hire front-end programmers" is actually "I won't be able to hire cheap devs".
I wish it was that easy... this doesn't account for the dynamics of the job market, the particular niche of Web programming and the perverse incentives created by head-hunters.
Much in the same way how programmers (and many others) are scared of "gaps" in their resumes (and will thus accept a job even if their finances would otherwise allow them to extend the job search further, creating more leverage on the employers), Web-programmers, specifically, will be vary today of putting, say, Mootools on their resume (because, oh the horror, I think it's like a decade old tech!). In the very same way programmers, especially in popular fields, like the Web, are compelled to follow group trends more than in less popular ones (eg. HPC).
Specifically, in the case of Web programmers, this has an additional side of creating a lot of bloat for no reason other than following fashion. Similar dynamics exist (or used to?) in the world of Java, where you have to (had to?) know about EE and Spring (which are huge and bloated frameworks, most probably don't need to use to get the work done, but were made a staple of Java programming due to fashion).
Kotlin has also suffered from this. It gained its credibility due to Google annointing it as the primary language for Android development but, being so close to Java, aspired to replace Java on the server. Sadly, Kotlin's main framework - Ktor - is a joke. The default, Gradle-based Ktor project within IntelliJ doesn't even work and the docs are useless. So Kotlin's server-side aspirations shifted to Spring Boot where it is supposed to be a first-class citizen. In practice there are numerous gotchas for the unwary and if you fled to Kotlin in reaction against Java's archaic practices such as escaping regex metacharacters you'll be disappointed to discover that Spring Boot validation relies on Java-based annotations which means you have to use Java regex patterns. So much for being a first class citizen.
It shows the sad state of professional consideration in this thread, that I had to scroll down so far to see someone mention job-prospect aspect of tech-stack choices.
> Why would you want talent that is laser-focused on specific keywords?
I think it's a bit different: the head-hunter agencies screen for these keywords, so programmers are incentivized to put those keywords into their resumes. Since programming jobs are seen as short-term investments anyways, programmers are looking at the jobs as the stepping stones to their later jobs, and so they feel pressured to look for a job where they can learn / hone the skill that they believe will be valuable in the job after this, and so on.
I forgot the name of the statistician who claimed that no matter the performance metric, if it is made known to the (human) subjects being so measured will quickly become irrelevant since the measured will learn to game the system. This is the result of applying a metric that grades on the number of years of experience with technology X, where the subjects are trying to optimize for their years of experience with technology X instead of a more complex and open-ended metric of being more knowledgeable or more talented or more dedicated etc. which aren't immediately and objectively measurable.
> if they don't put a fashionable JavaScript framework into job description, they will not be able to hire front-end programmers.
This is not a "pretend answer" and it's perfectly valid for devs to be picky about it. Nobody wants to work on garbage that started out as XML+CSS and mutated into a nightmarish mess that some "backend dev" cobbled together when the product team and the rest of the real world came knocking.
It's ridiculous that there even is a distinction between backend and frontend in 2023. It's so much easier to maintain a project when the devs can't feign ignorance.
Eh, doable but you do need the JS layer for updating/changing information dynamically (unless you avoid that sort of feature altogether, or just dump ALL your data onto the page in XML). I'm not that opposed though, really. CSS stuff might get kinda ugly quick as you're essentially doing OOP with it though hmm. This all + a basic JS request/response layer to just fetch more XML (rewriting/overlaying previous data) and you're possibly in business.
The beauty of bringing html into js (eg react) is because now we have type support for the entire FE stack. Not to mention the extremely useful view is a function of state paradigm.
What you are suggesting sounds something like golang templates and css. That works fine but you can’t easily get types in your templates. It’s a game changer when you have typescript at your disposal for your templates.
That's basically how the Django admin works. It's just HTML rendered at the backend. They had to add some javascript here and there but it's very minimal.
I see you got downvoted but people don’t get that choice of technology based on who you can hire is a valid point.
I remember a guy who wanted to make company documentation in LaTeX. Well yes it is great tool and we could put it in a git repo and render nice documents for the customers easily. Downside was 15-20 sales people who were not thrilled to use it and spend time learning how to use it.
Hey, I work in a company where user-facing documentation is written in LaTeX! I even contributed few commits to it.
I'm not sure though why sales people would need to edit it.
My discontent with LaTeX for documentation is that searching it sucks. I mean, you do get literal search for words, but if you want something smarter... PDFs don't interact well with searching tools we have.
Another problem: interactive scroll. In HTML documents you can scroll sections of documents independently of each other (if you need to), so you can create ad hoc views of your documentation that could be more useful to you (eg. collapse a bunch of tables or code listings just to see the text in between).
On the other hand, if you want to print it, oh man... it's going to look so much better! :)
Because there were no dedicated people writing documentation, there were developers and sales people - that was it. Non technical documentation so "how to use the system" was going to be written by sales people.
Lots of times in a company you work with what you have and finding and hiring "technical writer who has experience or wants to work with LaTeX" I would count as hard task.
I used to be on good terms with a technical writer from a company I worked for some time ago. He later became one of the very few people who were let go as a result of a merger. Also, from what I can tell, technical writer isn't a cushy job, not anywhere near even entry-level programming jobs. Also, it's usually at companies with existing and large user-base, relatively large companies... there's not a lot of jobs on the market.
I mean, I have a feeling that if a company asked a technical writer to learn LaTeX, they would probably do it, even on their own time. It's a tough market, and learning LaTeX enough to produce something isn't a huge effort (also, there are a bunch of tools that prepare the boilerplate code for documents). But I can see how sales people might not have been impressed by such prospects.
I think a lot of devs are frustrated with the state of modern Javascript. As I speak I am waiting for "mvn install" to run for a system that has a Java back end and a Javascript front end which compiles both. I think the Java part would finish in about 20 seconds, the Javascript bit is more like 250 seconds. There would be 250 seconds of working instead of posting to HN if the system was "100% pure Java".
(To be fair I am mostly depending on an incremental build and I'd say Java turns around in 2s, Javascript in about 20s. One of those breaks my chain of thought, the other doesn't.)
I never understood why you would need to compile frontend javascript code. Yea maybe a minimizer, obfuscator, some coping etc during a build process. But thats it.
My frontend apps are running on the fly. Change in code requires a save and browser refresh. No ammoying compiling .
Well, there're things like React's JSX, CoffeeScript, TypeScript and all of the fricking Babel stuff, all require some kind of transpiling (or how babel names it, compiling), and probably that is what OP means.
So you'd write (presumably a big) admin web interface in straight XML + CSS by hand? I don't know the details, but that sounds like a very long and painful process which will end up being hellish to maintain, plus a huge amount of training time for new devs to get familiar with the system.
If you even find new devs who'd want to work on this. Who wants to acquire very niche domain knowledge that you can't apply anywhere else?
> So you'd write (presumably a big) admin web interface in straight XML + CSS by hand?
That's not what I said. I think, that what you mean when you say "by hand" is the opposite of generating XML (and in case of XML, it's not CSS, the stylesheets are XSL that transform XML into HTML).
Before JavaScript frameworks were a thing, technologies like ColdFusion, JSP, ASP Classic proliferated. You can even find remains of this approach in relatively modern frameworks like Django. The idea was to generate XML or directly HTML on the server and send it to the client ready to be displayed rather than sending JavaScript that will request more data as it interacts with the user to build the interface. The former would be called "thin client", while the later is the "thick client". The former used to be more popular because programmers didn't see JavaScript or HTML as a worthwhile to learn language, not enough to build programs in it. It was seen as a target for transpilers.
This was before single page applications, or AJAX... The perceived downside of this approach was that for sites with many very similar pages the application server would have to generate a ton of HTMLs, which would be hard to cache server-side, so, allegedly, it would work slowly (compared to AJAX, where a basic HTML page with JavaScript framework would sit in cache and communicate using XML or JSON with the server to build missing parts).
XML + stylesheets is one of the ways to address this problem: essentially it does the same thing, but without JavaScript in the middle. The function of the XML part of the equation is to transfer the data that needs to be displayed, and the stylesheet transforms the XML into HTML that the browser knows how to display. Stylesheet can be generic and reused between different XMLs. It's not as flexible as using JavaScript but a lot easier on resources, and will probably beat AJAX solution in terms of speed.
Another benefit of XML + stylesheets is good integration with the browser testing tools. With tools like Selenium, you will always struggle to catch page state changes, and will not be able to respond to change as it happens, instead needing to poll for expected condition (that might never materialize). Stylesheets take this aspect completely away because there's nothing in them that happens asynchronously or in chunks. Unlike in single page application, where "page loaded" is undefined, there's an obvious way to tell when "page loaded happens".
The problem of XML + XSL(T) is that people have some preconceived notions about it. Very few people know the tool well, and for no particular reason, most people who know anything about the tool know very little about it, but are also very angry about it. Lots of polls for the "worst programming language" would mention XSL(T)... While the truth is that it's just very different from C, and that's what irks programmers. From engineering perspective, sites like, eg. this one, or Reddit or GMail would land themselves well to XML + XSL(T), but the reality is that modern day Web programmers, well, a lot of them, don't even know they have such a tool.
> Originally this website's font-family simply requested monospace. This approach resulted in varying reading experience depending on the OS. Windows browsers got Consolas, Linux users got DejaVu Sans Mono, and macOS people got Courier.
I find it so sad that our browsers have such bad default fonts that all websites feel the need to override them to get an acceptable look. It would be great if browsers had decent defaults for both the overall default as well as serf, sans-serif and monospace so that most websites who aren't worried about font branding can just stick with the default and users can get a good fond, or even their preferred font if they bothered to customize it.
This is what you get when you prioritize companies over users.
There's no reason websites should even be able to set the font in my browser.
If it was just about websites achieving an acceptable look, you'd see people emulating industry leaders, but that's not what you see. Google, for example, uses Arial on its main page on my browsers at least--that's a font that's available on every browser I know of. If it's acceptable for Google, it seems like it's just acceptable in general.
Instead, the fonts being loaded are about websites achieving their own brand. I've built a lot of web frontends, and every time I get a rebrand contract, the designs I get contain a bunch of fonts.
As a user, I don't give a fuck about your brand. Being able to read your fonts clearly is a much higher priority for me than experiencing your brand. Fundamentally there's no reason at all that sites should be able to decide for me what font I read. I am lucky to have fairly good eyesight and no serious processing disorders, but users who have these issues are seriously negatively effected by sites overriding their browser defaults. And since few projects are given adequate accessibility budget, users are left with no recourse. Overriding a website's fonts with your browser settings doesn't really help, because sites often use pixels and other dimension units that make your site unreadable if you use a different font than what they tested with.
Firefox: Settings → Fonts → Advanced → untick Allow pages to choose their own fonts, instead of your selections above. It’ll still load web fonts for Private Use Area code points (icon fonts) and Google’s misbegotten Material Icons with its awful ASCII + ligation technique (see the browser.display.use_document_fonts.icon_font_allowlist pref in about:config), but other than that will stick with your preferred fonts.
I tried this as a two-week experiment a year ago. I’ve never gone back, it improves the web so much.
(Well, actually I also block web font downloading altogether, for no particularly good reason, at the cost of icon fonts and Material Icons breakage, but it doesn’t often matter.)
Same here, my Firefox has disabled "allow pages to use choose their own fonts" for ages. I do use Stylus to override a bunch of fonts/sizes in various sites too.
Because a lot of people don't have the technical ability. The tab is called "Advanced" for a reason.
It quickly gets more complicated for some sites, which users might use often. There are folks talking about how you can use custom CSS to fix just about any site, and that's true, but how technical are we expecting users to be?
And even as a user who develops websites for a living and can definitely do all this, I don't want to. The web should be designed to work for users by default. I shouldn't have to fix websites to use them.
> Because a lot of people don't have the technical ability. The tab is called "Advanced" for a reason.
Come now, it doesn’t take any technical ability to use the checkbox. It’s called “Advanced” because it’s more complex tweaks that most people aren’t interested in and which take a moderate amount of space so they want to keep it out of the way lest the page get too long, not because it’s hard to use in any way.
> It quickly gets more complicated for some sites, which users might use often.
It is rare for this to have any ill effect on any site (icon fonts that don’t use the PUA and aren’t Material Icons (for which Firefox has manual exceptions in place) are about the only case, and they’re distinctly rare nowadays—I only recall encountering about two cases last year, both of which were paired with labels and thus unimportant), and in those rare cases it’s unusual for it to be a real problem (they’ll almost always have labels or tooltips).
I will quite happily recommend changing this setting to completely untechnical users. It occasionally causes very mild harm, and can theoretically cause great harm for particular sites (but I haven’t found such a site for years, and any such sites were surely already broken anyway), but the rest of the time it improves matters markedly.
> Come now, it doesn’t take any technical ability to use the checkbox.
It's clear that you don't interact with average users very often if you think this.
Obviously you can direct the user through to the steps to check/uncheck a textbox, but understanding what that checkbox actually does and why they might want to check/uncheck it is far beyond the technical understanding of most users.
This is completely false. Both use images for the board and pieces, so you can play just fine.
Both do use icon fonts for some of their additional controls on the right hand side, but they all have tooltips so that you can identify them even without the icons. Chess.com uses a bad icon font that uses non-PUA code points (e.g. V = New Game, , = Move Back, … = Move Forward, g = Show Hint), so those ones will be broken. lichess.org uses PUA code points (except for “½” for “Offer draw”), so I think that those icons would even be loaded if you weren’t like me in just blocking web fonts outright.
As I said, "Overriding a website's fonts with your browser settings doesn't really help, because sites often use pixels and other dimension units that make your site unreadable if you use a different font than what they tested with."
Of course that can also be fixed, but there's only so far you can take this. I have the technical ability to edit CSS, but I don't reasonably have the time to do it for every site I visit.
It's well past time for browsers' reader modes to be the default experience for unstyled pages. The arguments for not doing this—and keeping a single set of user agent style sheets containing rules that have to match how unstyled pages looked in the 90s—come from a place of good intentions, but are ultimately poorly reasoned and result in one of the worst forms of stop energy. (The strongest argument against is: "my browser's reader mode is worse than the unstyled page", which I sometimes agree with, but is still not a very good argument at all. It's solved by fixing the reader mode itself to be less bad.)
> even their preferred font if they bothered to customize it.
Felt. I actually do adjust my user agent fonts and system fonts, and I hate it when these "system UI font stacks" aren't just "sans-serif" and I end up with Arial or Ubuntu because some guru said this is how you do it. Especially irksome though is the monospace fonts--either Courier New (which hints way too thin to be readable on my main display) or using some hard-to-decipher custom font that abuses ligatures.
At least on linux, it's not the browser that picks the font used for "monospace" but part of fontconfig. I've reconfigured my fontconfig to use a different font for monospace.
At least on Firefox it is both. By default it uses raw fontconfig for default, serif, sans-serif and monospace. But it uses an override for emoji fonts. You can also explicitly override these in the preferences and then it doesn't consult fontconfig (or probably consults it with a precise font name).
But yes, I have seen decent browser fonts for most Linux distros.
Consolas is not bad. DejaVu is not bad. Only Courier/Courier New are so bad as to be unusable, it seems Apple wants to push web developers to use font overrides.
It is a bit odd that "monospace" in a mac browser gets you Courier/Courier New, because macOS has come standard with Menlo for ages and Monaco since the OS 9 days, both of which are excellent monospace fonts that are far and away better than either Courier. Even weirder, outside of browsers requesting a monospace font will get you Menlo.
Newer releases also have San Francisco Mono that it could use instead, which is even better since it's tuned for modern displays.
Apple is notorious for wanting to push people away from portable and easy-to-use web applications to non-portable, expensive to develop, and frequently worse mobile apps.
It’s more that they don’t put the high level of refinement into the web experience that they are famous for in their native (Mac/iOS) applications.
Though of course there are plenty of discontents with that. On balance I think the apps that ship with MacOS are much worse than their Windows counterparts. I think iOS on the iPad is truly superior but the settings app is dark pattern city, particularly the notification that never goes away about the Apple TV trial that is about to expire but actually expired years ago.
DejaVu is not a websafe font, meaning you cannot rely on it being available.
Why we can't just require browsers to include DejaVu or another open font is another question - not like the size matters compared to all the other crap they ship. Heck, some even ship their own fonts already, but only for emojis.
Even having some defined meta fonts with rough metrics so that you could say font-face: monospace-standard or whatever and have the text be roughly the same size everywhere would save so much effort and wasted data.
> Why we can't just require browsers to include DejaVu or another open font is another question
Including a small set of open fonts does seem like a good idea. I'd like to see Inter UI[0] included because it's a very nice screen/UI-optimized font would serve a similar purpose as "system-ui" does now, except without some of the pitfalls[1] that comes with.
Don’t lump Courier and Courier New together. Courier (which Apple includes) is fine; it’s only Courier New (which Windows includes) that’s atrociously light, because it was digitised very badly incorrectly. It actually used to be not so bad, because they kinda patched it to make it usable with hinting, and then special-cased it in ClearType, but those don’t really go far enough and aren’t consistently reliable anyway, so it’s just an awful font.
Courier New is the most appalling piece of shit I've ever seen in my life. It's ugly at small sizes, jagged and unpleasant at medium sizes, and abhorrent at display sizes. WOW do I hate Courier. I hate it on Git Bash. I hate it in cmd, I hate that it exists. Consolas, by contrast, is lovely and beautifully-hinted at best, and inoffensive at worst.
I noticed the web site has a downloadable font, which is fine as long as it's optional, the problem is that many web sites have the bad practice of using the private unicode range for icons. Now the web site has become an accessibility problem. Downloadable fonts are optional, and there is no fallback mechanism like we have with img and alt text.
I'll happily lump JavaScript in as a major accessibility concern. JS is most often used where it shouldn't (most recent in memory is the Unreal Engine docs). Using JS for such simple presentations is like building a 5000-story building to print a sheet of paper, when all you needed was the pre-printed sheet of paper (HTML, CSS).
In my experience the default fonts on Apple devices are far and away the best fonts, period. They're better than almost every custom font, especially for readability.
I don't have an Apple device to test but does that mean that the author's point about the default `monospace` font "Courier New, is not legible" is out of date or just a rare opinion?
Probably very subjective. I, for one, am still using Courier New as my main monospace font, especially for code, and actually prefer having typewriter-y "serifs". No other serif-y monospace I've found fitted.
I don't mind Consolas, and I like what is author using now (DejaVu Sans Mono), but their stance about varying reading experience depending on the OS makes me really, really devastated, because it just reflects a sad state of IT literacy and general adoption of basic philosophy of the web, which was built on premise that how content looks like depends both on author and user (through user agent) and fact that generic font family looks ugly is in other words defaults are bad combined with users have a bad taste and set bad default values.
As was said, we are supposed to express our preferences in (through) our (user) agent's preferences.
Most probably your browser will use four distinct fonts on this page, *all* of them (and more) you can define in your browser's or operating system's settings:
Fun fact: even though author have expressed a lot of opinions in their CSS, still for me the result is probably different from what they expected: since author does not define font colour, I see it in my default (not black but dark brown), plus paragraphs are slightly indented for me, since I limit their maximum width through userstyle. Funnily enough, background colour that author chose (and set, #F5F5F0) is nearly identical to my preferred background colour.
Authors defining background colour without defining text colour is the reason we cannot effectively have default dark background and light text default in our UAs, because in this case we would see authors (light) background and ours (light) text.
I think Courier is the only one of the fonts listed above that’s not sans-serif. The retro typewriter effect is not probably not what he wants for displaying a lot of prose in a modern context. I don’t think it’s actually illegible.
They solution IMO is not to rely on default browser fonts but rather to pick a stack that’s available at the OS level.
On my site for example, I designed everything using Iowan as my main font because I know that it’s available on most Apple OS but then I manually picked a few fallback fonts that should be available on Windows, Android and the rest.
Default serif is just the last option if everything else doesn’t work.
Yes this! If I make websites as a blind person, I'd probably just have CSS give headings 20 PT font size, paragraphs line spacing 2, 16 PT. Something like that. But if browsers used good defaults I could just not worry about CSS and just go with plain HTML.
The bad fonts can be tweaked ever so slightly to remain eminently familiar and inviting, but slightly adjusted in positive ways.
It could be kerning, leading, default font size, all come together in very powerful ways before finding a very specific font to enhance the brand experience.
If we look at HN, the window we type a comment into continues to use a font when writing that can help induce more awareness of writing. Maybe it would be slightly different if it was a blinking square cursor. Or a slightly taller box.
"If you can stick to the same style long enough and also write articles for long enough, your style sheet can become your brand. But mostly css appeals to our vanity and ego."
This is blatantly incorrect or a flagrant misrepresentation. CSS can certainly improve readability without adding design.
Readability is a check list which stock HTML does not address.
You may not even need HTML. HTML is subject to different renderings on different browsers, confusing features that may not be supported on different browses, and may tempt you to use JavaScript (which can throw "errors" if written incorrectly).
If you stick to text files, you'll never have to go to caniuse.com ever. Need styles? Just make a PDF and throw that online. During the "XML HTML" phase the web went through, I never had to worry about validating my PDFs through an XML validator. Then when everyone decided using "<b>" and "<font>" tags was bad and insisting we switch to using "font-weight" CSS in a completely unrelated part of the file, guess what I had to do? Nothing! My PDF keeps rendering exactly the same way through every silly "trend" and "update" on the web, and never misses a beat on Lighthouse in Chrome.
Now if I could just convince all the browsers to implement .docx renderers out of the box, I'd really be set.
> HTML is subject to different renderings on different browsers
This only matters if you actually care about exactly how your website renders on any given browser. Most websites don't have any need to care. PDFs are the worst for this: They care, A LOT. Which means locking you in to some hideous rectangle that's a different aspect ratio than any monitors I own, locking down the fonts and colors so that I can't just rely on system defaults, etc.
If all you need is to convey text, and maybe take some input, HTML is a fantastic solution.
Good luck having your site be easy to read on both mobile and desktop with either of these approaches. text/plain may work if you use soft wrapping, but even then most desktop will need to resize their browser window to make it narrow enough to read comfortably.
Here's my weird opinion on html/css/general styling of websites:
The biggest problem with CSS is it's one language that's trying to do two things. I think that layout (grid, flex, anything that changes the shape of the page) and style (font, color, text sizes, etc...) are two separate things, and CSS makes it incredibly tempting to try to do both of those at the same time, which inevitably causes trouble.
Working on a website is easier when you can break those two things out into separate concepts. People love to praise/hate tailwind, but I think the best use for it is specifically for modifying layout. Layout changes deserve to be built right into the HTML itself because that's where you're looking when you need to reason about it, whereas style is more general and should be broken out into actual CSS rules to keep it more consistent across a site. Layout is much more directly tied to context than style is, at least as soon as you get into anything non-trivial. There really needs to be a better way to segment these two concepts.
At least, that's my hot take as a semi-passable css user.
It's both HTML and CSS, though. HTML is also bleeding over the boundary between layout and document.
HTML was mean to _be_ the document. CSS was meant to be a language for styling and re-styling those documents. That makes sense in the logic of decades past. You might have a bunch of documents, and go re-style them all when you move. Or a company might do this when they change their logo or get acquired.
But for a long time now almost every HTML document served on the web has long been a mix of design elements and one or more things that a human would call distinct documents, and CSS has kept up with styling those.
With a true "document", it's pretty sane to expect that you can readily style and re-style the same document with different stylesheets for different contexts without needing to go fiddle content. With full complex designs implemented in HTML, the HTML and CSS for at least those parts tend to be very tightly coupled and very likely to get rewritten together.
The fuzzy boundary between the content and the layout are a problem for both HTML and CSS.
It confirms my issue with using tailwind. I like it! But as you mentioned “style” typically has a global, systematic, component based notion, and not a hierarchical one.
A perfect example is typography AKA font style and color. Yes, it has a structural/hierarchical notion, but only on an abstract component level.
Typography almost _always_ comes in aggregates. Font size, line height and more, even margins - they are very rarely orthogonal and composable.
Designers typically take great care to fine tune these things as components. Ask a designer to disentangle then into tokens and you get a very weird look!
On the structural level you want meaningful component classes to refer to them and maybe one or two modifier classes, if at all.
Thankfully tailwind offers @apply, so you can still leverage some definitions where it makes sense.
It sounds like someone forgot that CSS is not some independent technology from HTML, a webpage is "HTML+CSS", it's one thing. Sure, browsers injects a shitty default style if you just need to put some plain text data out there, but HTML just semantically marks up your data, CSS is what makes it easy to read and understand.
If you proclaim that CSS is "for vanity", your stables must have an awfully big ladder for getting on your horse.
Shall we take it one step further? Why even bother with HTML, semantic markup is just as much vanity as CSS: just put .txt files on the web. People can trivially copy-and-paste links to other files anyway, they copy-and-paste text all the time. Adding <a> elements is basically just browser candy. As long as the information's high quality, people will want to read it, right?
It sounds like someone forgot that HTML and CSS are separate technologies, with one being born years before the other. In the beginning, the web was HTML.
Sure, CSS is useful. But a lot of it is over-designed. The web in general, is over-designed.
Sure, that's like, my opinion. But no, they're not "one thing".
> As long as the information's high quality, people will want to read it, right?
I do. Probably, there's a fundamental difference in what we consider readable. I don't think pure HTML as rendered by modern browsers is necessarily ideal, but it's generally readable. Most of the extra elements, styling, javascript, pictures etc. on modern pages distract from the actual content and make it harder for me to read it.
nope, it's definitely just for vanity. it will be hard to explain that on a forum dedicated to people whose work revolves around upholding this myth, though. html not being readable without css is a bug or bad positioning. i would never design a document format that requires something as complex as css to be readable. anyway i find sites that use just plain default html readable. one big mistake people make is to let their browser take up a full widescreen monitor on such pages. the fact that the browser tries to be the OS discourages them from resizing it (windows+left on windows or gnome or the equivalent on windows is enough). its mostly the tables (iirc) that look like crap, even though they didn't have to
"CSS" is as complex as you need it to be. Just because you're not a three star chef doesn't mean you can't cook at least good tasting food, and just because you have no idea how the hell to implement a fluid CSS grid with parallal and keyframe animations that work at all breakpoints for all devices in both light and dark mode doesn't mean you can't make your document better with even a modicum of dead simple basic CSS.
Don't pretend that CSS is hard.
Yes, of course crazy CSS mastery to make vanity artworks on the web is hard, and yes doing stupid things with z-layer ordering and absolute vs relative positioning is the classic "family guy trying to work the blinds" gif, but decent CSS that makes information easier to read for a wide variety of people (including ESL, visually impaired, etc.) is barely any effort, and pretending we're all worse off because of CSS and that having a document format that lets you style your content with is a terrible idea is just willfully stupid.
(on that note: oh look, something that every single DTP product ever made supports, guess those are all terrible too, and I suppose that sarcastic joke about us all just using .txt files should get repeated here)
if i was to implement a browser that could properly render CSS for some given set of real life scenarios i would be getting back to you in 100 years. paying tax, banking, trading academic literature should not rely on a magazine formatting jenga puzzle
Ah yes, the myth of rejecting nihilism. Just like my last restaurant visit where I ordered stale bread and water. Enough for survival, the rest is pure vanity.
> "This website used to be hosted by asmallorange. When I became dissatisfied, all I had to do was to open an account on hostgator, upload my html files, and change the DNS entry"
At the risk of being pendantic, asmallorange and hostgator are owned by the same entity[0].
That said, I like the premise of just writing and producing content and not necessarily worrying about setting up tooling. I think devs, and "geeks" in general, tend to enjoy tinkering with tooling, but it can be daunting for the less tech savvy. I suppose that's why things like Wordpress.com exist.
A small orange sure has changed. It used to be dirt cheap crappy shared hosting. Now it's expensive compared to just getting a full VPS nearly anywhere else.
Their VPS offering is $55/month and is comparable to digital ocean's $18/month.
Yeah that paid hosting + dns services combination is complete overkill when going for static html.
I host a bunch of files and static html on my domain and I’ve moved it to github pages. The dns services bundled with the domain at gandi are enough to set it up on top of the free github pages, so my hosting is effectively free, and if I wanted I could still run a site generator.
Static html gets even easier by using something like simplecss, because that gives a basic design with zero effort on top of semantic html. https://simplecss.org/
Articles written in 2023 should not be recommending Hostgator.
Cloudflare Pages, Github Pages, Gitlab Pages, Netlify, etc, etc. It's all free at this level. Vastly distributed and they can all use CI/CD to build static-site-generator configurations for you, if you want that.
It's not about the money. Hostgator has been a recurrently awful host over the past 21 years, cutting people off as soon as they get popular, downtime when they overoversell their service. They're a relic, alongside Dreamhost, Bluehost, GoDaddy; the type of host we just don't need any more.
The rest of the article is right: you may not need anything more than HTML+CSS, but life is a lot easier if you don't have to build it yourself. I'll take Astro + Git + Cloudflare over "gen.php" + FTP + Hostgator any day.
I am a budding woodworker. Not very good at it. Spent too much money on tools I have never used. My most used creation is a tablet stand which is basically two pieces of wood with a hinge joining them. I wish someone had given me similar sort of advice as the OP about tools when starting out. You don't need as many as you think especially as an amateur with limited space. Feels like web development is the same. I get that big companies have resources and people to maintain the fancy CMSs and SSGs but someone like me who writes one post every two years perhaps plain old HTML is best.
Yes, unfortunately it's easy to get caught up in your tools even for simple work. Go on YouTube and watch woodworking videos, you'll see shops full of 5 figures worth of tools, and probably get the idea that you need the same. And every damn tutorial and beginner blog post on web programming shows you how to set things up with this stack, or that stack, so many different stacks but always some stack. And so people feel that they must need a stack...
To be fair, the author uses the qualifier "may" and explains the desire for monospace and consistency. It's not like it's clickbait, the author makes a valid argument. Perhaps disregard sub-headings if it results in overlooking the nuance of the article's overall suggestions.
Except monospace fonts shouldn't be used for prose, so the author is actively making the reading experience worse for... aesthetics and vanity reasons?
It's hard to respect the advice of a designer whose deviations from their own rules make the design worse.
Almost any web-safe font[1] would have been a better choice.
It’s nice to see a “You don’t need X” article that isn’t just annoying snark. This actually answers some questions people had, which feels like a much better reason to write something like this, rather than the usual rage-bait “you don’t need JS/CSS/Framework/Technology considered harmful” medium articles.
There's definitely a lot of websites out there that are just super dynamic and flashy and complicated in ways they don't need to be, and I mean that to the owner's detriment, not necessarily the reader's. How many hacked Wordpress sites didn't even need to be Wordpress in the first place? If you don't have comments on your site, you probably don't really need Wordpress, and even if you do a Disqus-like solution on a static site is probably still more secure. Which, again, I mean in terms of bothering the owner, not just the users.
I think articles that are just all about how you're bothering your readers can be a bit tedious, but there are ways even the owners are hurt by the belief they need every whizbang thing, because they all have maintenance costs and general quirkiness costs associated with them too.
One problem not listed is source code syntax highlighting. If you provide source code listings in articles, then highlighting is a big help to readers. Generating it in HTML is not fun.
Alternatively, you could specify the type of the source code so the user agent could handle the syntax highlighting—just like every other source code viewer ever written aside from those with idiosyncrasies related to the fact that they that belong to a special class called "Web browsers".
Tbh <pre> + monospace font + padding already makes a lot of code snippets readable, you can also write a 10 line js function to generate highlight for only the comments (to make them lesser shade of gray), i think that solves a lot of readability with very minimal work. Also I think there's no shame in using highlight.js
Pygments does this easily, depending on the source for generating HTML pages. It has been available for a long time. For more than a decade. Some blog generators use it, not only Python blog generators.
Having written my fair share of HTML by hand, I'd say that the purpose may be better served by Markdown, or Org, or even plaintext. HTML has too much unnecessary detail if you're into low-effort content-centric stuff and cleanliness.
Learning HTML is fine, but learning HTML while avoiding CSS is not very useful, except as an esoteric hobby (like 6502 assembly, but much more complex). Using handwritten HTML if you're after content creation is unnecessary legwork.
OTOH holding an unorthodox view on a widespread technology, of course, improves one's chances to suddenly appear on the HN front page :)
> Learning HTML is fine, but learning HTML while avoiding CSS is not very useful, except as an esoteric hobby (like 6502 assembly, but much more complex). Using handwritten HTML if you're after content creation is unnecessary legwork.
Idk man. Doesn't seem at all complicated to me until you start involving CSS. Assuming you're just after basic content. Slap a <title> in <head>, a few <section>s in body, <p> your content. Maybe an <aside> for some spice! <a>, <img> and <video> might be useful if you want some hyper/multimedia.
The complications arrive when you want it to look like some designed page, regardless of user preferences, window/screen size, which browser, etc.
Agree though that Markdown and Org are good and useful tools.
Also : there is a background color specified, but other colors are not overriden, which causes the text to appear in a color very close to the background color on my browser (the default text, and background colors are user configurable).
This is another post illuminating the new minimalist trend in website design. The old minimalism was about "elegance", but this new trend is more about utility: we don't need CSS, just content, so why bother! I don't like this utilitarian take. It's fun to design a website.
Pretty sure it only comes from engineers. Not sure it’s a new trend.
I appreciate it personally. I think most styling is about UX and not communicating information (although it can improve that). But I think it’s at least jaded and probably even a terrible idea to suggest websites should generally be implemented this way.
I genuinely believe a site can be extremely minimal without sacrificing the visual component. But I also believe some people are pushing the visual part way too far to the point where sites are genuinely hard and frustrating to use.
According to the following website, the value of the product you're selling is inversely proportional to the effort (including website sugar) you need to put into selling it.
HTML + CSS for whitespacing & viewport width + SSI | Caddy's template
That combo is more than enough for almost all the websites out there, I've 3 different sites like that and they are blazingly fast, everything served from a $4 VPS (serving about 20k views per week).
I never released a production website with SSI before, but I found it when I was searching for a more bare-metal approach to make websites; then I found Caddy's template engine and it's been more than enough for what I need.
This is the way. It's great for templating with .html fragments, extremely easy to maintain and has almost no attack surface. I don't know what "Caddy's template" is but HTML/CSS + SSI for gluing the fragments together is what peak personal website performance looks like.
SSI is supported by "old battle tested" servers like Apache or Nginx, there's a "new guy on the block" that I find quite promissing: Caddy[0] however it doesn't support SSI, instead they have some built-in template engine that is a bit more powerful than old SSI but can achieve the same result.
I guess you mean because SSI is just a very limited mechanism as opposed to full blown Turing complete PHP or similar. But actually if the fragments/partials you include via SSI are user-posted content (comments) or syndicated content then of course SSI can't fence against <script> or other injections. In that case, you could use more sophisticated SGML mechanisms (other than SGML processing instructions as used by PHP or magic SGML comments as used by SSI) such as entity reference expansion that come with full type checking and context-dependent validity assessment for filtering all kind of injections (script elements, event handler attributes, image or link href injections or whatever). But you should at least use content-security-policy headers to block inline script.
As I sit here several minutes into a build powered by gigabytes of modules and package artifacts that is converting a collection of components into react-native, then converting the 30-page react-native mobile application to HTML using react-native-web.
> A host for your index.html files Hostgator $33/year plan.
- Google Cloud Firebase Hosting - free; really good tooling to deploy, automatic CDN
- AWS S3 + CloudFront - a bit more setup, but more or less free
- Azure Static Web Apps - free
No need to have any hosting plan.
Firebase Hosting in particular is really easy to get started and connect a domain to it. The Firebase CLI tooling makes it dead simple to deploy updates as well.
If you are OK with just having an IPv6 IP, you can live in a country like the Netherlands and simply use your home connection to serve your Web page. Almost like it was intended by forefathers...
But, really, in my dream world, ISPs would also act as registrars for their clients, so, once you pay them you get some automatic domain name, or maybe can pay a bit extra for a permanent one that you can take to the next ISP you sing with.
In many cases, a small amount of CSS can give you a lot of control over formatting in a way that is easy to maintain. Over the long term CSS has gotten much better in every respect but one.
That one respect is insofar as there is a "CSS specification" it is this
which itself refers to roughly 50 documents which furthermore has the mind-melting structure of "Document 17 replaces clauses 13.5 and 15.11.9 in Document 3". On top of that you need to refer to
which I'd usually advise against (you can consistently get the right answers if you look things up in the docs.)
Maintaining other people's CSS is also a bear and even maintaining my own is pretty bad for side projects that I work on sporadically for a few years (I wind up introducing a class to solve this problem and another to solve that problem and don't have much of a master plan.)
Then there are the various CSS frameworks which vary from useful to insane (the original Bootstrap which was about as easy to use as learning to paint with oils) and practices like BEM, which is the webs' answer to RAAI in C.
The opposite of a great truth is also a great truth: You may need more than HTML.
The problem is (and I believe this is what the author tries to draw attention to) that people are fighting all sorts of half-backed stacks without necessarily having a fully justified reason for every incremental complication invovled.
The web is obviously more than a "clean page of text" metaphor. How much more we don't even know yet.
What would make this journey of discovery shorter is the simple golden rule that "computational complexity should be commensurate with the result"
As someone who uses a static site generator, I agree with most points. The most important thing in a blog/website is the content. Start writing, and publish.
Yeah, the question isn't whether styling per se is needed, but whether CSS as a language doubling HTML's old presentational attributes, yet in a thousand ad-hoc, unchecked syntaxes and layout models ever made sense at all.
The author criticizes generators, but apart from those terrible mysql CMSs there's also SGML, on which HTML (and XML) is based, lending HTML authoring affordances such as text macros, shared fragments, templating, custom shortform syntax a la markdown, stylesheets, pipelines, outline generators, link decorators, with full type checking etc. etc. HTML feels incomplete without.
The Thief reference, though, I don't get - is the point that mission briefs and picked up letters are using Times New Roman? It's a terrible screen font at small sizes, and also HN could do with a modest style upgrade to improve touchable areas/distances and support for prefers-color-scheme if only to hide you're browsing the orange site ;)
Two points in support of the KISS principle for UI (user interface) programming -- keep it simple ...:
(1) With defaults, 3+ billion people already understand very well.
(2) For anything not a default, on the first day, the programmer understands and maybe no one else.
As I understand the history of UI programming, the HTML controls were built on, borrowed from, the controls in the IBM 3270 terminals heavily used in IBM's CICS (customer information control system) and originally designed for the user interface of airline reservation computing.
I don't know much about UI programming because my most important background in computing was for applied math computing for US national security where didn't use check boxes, radio buttons, single line text boxes, multi-line text boxes, links, etc. But as a user of the Internet and for the UI programming for my startup, I followed KISS, i.e., used HTML defaults.
For blog sites I tend to use a hand written site generator that converts markdown to html, typescript to js and scss to css at compile time.
This allows me to ship a static html site (S3 website) where the javascript functionality is limited to basic things, like toggling dark mode.
To build an "API", I crawl the files at compile time and generate json files in an /api folder, allowing me to fetch blog post metadata for searches that are processed on the client.
As icing on the cake, once the user has settled in, I use a service worker to pre-download/cache the all the posts in the blog site and allow for offline viewing. I have some tricks to avoid the annoyances of stuck sw caches.
Leads to a great user experience and maintainers don't need to have a backend portal - just write markdown and commit it straight to GitHub. Easy enough to teach people to use Typora and SourceTree
I'm making a few too many requests in the first iteration, no cache control headers, asset minification, etc
Since then, I have been refining it for a contract that I am working on (introducing the SW) and I am keen to release it as an open source project - including a terraform script to deploy it to S3, setup Cloudfront and all that good stuff.
I like this design less than that of Fabien Sanglard's older pages like https://fabiensanglard.net/quake2/index.php. It is more distinctive, but the text is harder to read. Justified monospace text also makes it harder to scan. I think the goal is to look kind of like a man page, but man pages have more varied indentation, which helps you scan their content.
> Inevitably, you will want to do something the framework did not forecast and will come up with convoluted ways to do it anyway.
I always find static site generators a kind of leaky abstraction. They eventually try to abstract nearly the whole functionality of the web stack, and the larger the SSG the more apparent it becomes. But, for obvious reasons, they just cannot abstract all the peculiarities of the web from you.
I write posts in Markdown, use Pandoc to convert `.md` to `.html` and a simple Go script in 200-300 LoC [1] for my https://hirrolot.github.io/.
Unrelated, but this blog is difficult to read for a few reasons: bold black text highlighted with a gray background is too intense, line height is too small if they insist on using the highlighting, fully justified text for no reason.
Also, the navbar at the top of the page might as well be invisible.
Mostly, the idea is that you write it yourself. I suppose there are things such as Markdown converters if you require some level of abstraction.
I thought Dreamweaver was great when I first encountered it. That lasted until I happened to look under the hood at the HTML it was generating. What a horrifying, bloated mess it made of everything...
AFAIK there is no free lunch here; you learn to write it yourself, or you suffer it to be written poorly for you.
An even better way to do this is to host your site on Cloudflare Pages. It's completely free, and can be deployed from GitHub or you can upload a ZIP of the HTML pages of your site.
It's served via a CDN, so it's always really quick to load.
There's literally no cost to it for static sites.
You could create a git repository for your HTML site. Then, edit the HTML using VS Code. Every time you push to your repository, your site will get updated almost instantly.
All you have to pay for or worry about is domain name.
If you use a web host like Hostgator, your site will get banned when it gets a lot of traffic. Cloudflare has no such limits whether you get 10 visitors a day or 10k a day...
Writing in HTML sucks, and it's a distraction from your writing itself. Markdown or text are better on that account. And then pushing code through FTP ain't super fun, especially given that having a pipeline that runs Jekyll or Hugo is free on github and pretty much a copy-paste.
From a consumption perspective, having some form of consistency across your blog is also pretty good, even if to satisfy your ego, especially if you get it for free.
I would argue that setting up a bit of infra on top of it, which will probably take the better part of an hour if it's your first time, is a very good way of reducing the friction and making sure you actually write.
Remember that “All you may need is HTML” is a general guideline to keep things simple—a starting point rather than a hard rule. Even OP is using a PHP generator, 113 lines of CSS, and a web font to opine about the virtues of HTML.
CSS could also solve this website's problem of a visitor reading the page title as "FABIEN SANGLARD'S WEBSITE ABOUT EMAIL RSS DONATE" … I thought it was a website about email and RSS and donations for a second.
Resoundingly, the first. The second one is full of huge tiles that take up so much screen real estate, it's hard for me to scan over what is available. Crammed at the bottom are a ton of links, in no particular organization that was immediately apparent. The entire site is plastered with huge images everywhere, that don't really add to the content and just distract from whatever it was I was theoretically there for, and really don't help me understand the site at all. Also, the zoom effect on tiles keeps grabbing my attention when I was really just trying to move my mouse across them to get to something else that I'm now distracted from.
> * Nicer to to look at?
Depends on what you mean I guess; if you came to soak up pictures of smiling faces, I guess the second. But personally, I don't dislike the first.
> We don't live in a HTML only world because no one wants to live in a HTML only world. Some techies might but 99% of ordinary people do not.
I'm afraid this is a really awkward statement. There's no way to argue against it or really say anything to the contrary. You've framed it such that anyone who disagrees with you is "a techie" who in your definition does not represent any norm.
As always, I think the custom font hate is overstated.
> Custom fonts are a waste of bandwidth
Latin subsetted fonts are generally 10-30Kb, it's really not that much. For comparison, it's unlikely you'll see blog authors get up in arms over a single PNG.
> they come with one of three evils called latency, FOUT, and FOIT
A few milliseconds of a different font appearing is truly not much of an evil, but can be addressed by exactly what the author links in their footnote.
Humorously, the author's own site is committing some sins here: both of two font files are >140kb, they don't have gzip on, and they have the fonts marked `font-display: block`. They could cut their CLS and LCP by almost 100% by addressing this: https://i.imgur.com/MOl32iS.png
Of course, it's already very fast, by virtue of having no other resources loading. This would be dramatically worse if there were scripts that needed to get downloaded.
> Latin subsetted fonts are generally 10-30Kb, it's really not that much.
Agreed. Make your own custom font files with only the characters you use, or are likely to use.
> A few milliseconds of a different font appearing is truly not much of an evil, but can be addressed by exactly what the author links in their footnote.
Browsers will wait for about 3 seconds for custom fonts to load before showing a fallback font.
> both of two font files are >140kb, they don't have gzip on
woff2 format fonts are already compressed, so gzip won't do much.
> Browsers will wait for about 3 seconds for custom fonts to load before showing a fallback font
Depends on the `font-display` value on one's `@font-face`, which is where the author's choices of "latency, FOUT, and FOIT" comes from. For instance, Google Fonts uses `swap` by default, meaning the fallback shows right away: https://web.dev/font-best-practices/#choose-an-appropriate-f... (I also think Safari's `auto` font-display never shows fallbacks, but that may have changed)
That's often enough. You can go another step further and preload the font, which I generally recommend. This especially helps if the font is otherwise discovered late by the browser.
Just so everyone is aware, the guy is not an expert in web development. Neither is he a frontend engineer.
When this hit pieces some against an entire tech-stack, always check the author's job, past expereince.
Our industry has not matured enough to split into expertise areas into solid titles, and grow respect for those titles just yet. As the author's title points it out very clearly as "Software Engineer".
Try getting a Job in any sizeable company by building your entire experience with HTML and tell me how it goes.
> It is extraordinary claims, require extraordinary evidence, or experience/proven competence.
But they don't. All they require is for you to evaluate the claims, on their own merits, without examining the speaker for their credentials. Evaluating a claim based on the credentials of the speaker is quite exactly an appeal to authority.
> And this seem to be, reactionary.
I'm not sure what you mean by this, or how to take it, so I'll try again with more words. Nobody is claiming that the best way to get a job at a large company is to build an experience base consisting solely of pure HTML websites. Nobody is even claiming that this is a good way to get a job at such, or that it will work at all. This seems rather orthogonal to the claim that, depending on what you are building and what you are trying to accomplish, "All you may need is HTML".
> This approach resulted in varying reading experience depending on the OS. Windows browsers got Consolas, Linux users got DejaVu Sans Mono, and macOS people got Courier. Using a custom DejaVU makes the reading experience consistent.
I don’t get this argument. As a reader, I’m used to the monospace font of my OS because it’s the one I see everywhere. I don’t care at all about the fonts users of other OSes see. This custom font makes _your_ experience consistent, not the readers’.
I have been writing some puppeteer/node js scripts to download invoices/statements and to scrap some data from different vendors/service providers. (ATT, Spectrum, Gas, electric, etc).
Pretty much all the sites are now a days single page or with tons of JavaScript with a lot of xhr requests. Those xhr requests are huge too. Loading screens everywhere. Some of the loading screens are 5-7 seconds long.
And I have no luck with banks sites. They put a lot of efforts to block access.
Recently made my first blog/website and used NextJS. It’s been fun adding style and bloat at this stage since everything I do is for learning. But I wonder how many years go by before I opt for something more basic?
He talks about the evolution of his blog in this post[1] and has a link to the web archive of an early version.
I was thinking about this the other day in reference to how slow reddit is compared to HN even though they are essentially achieving the same function. I get that there are images, video & volume of posts/users served difference but I'd bet if they made just a pain text version of it it would be order of magnitude faster and browsable.
if you like 'html looking' sites (for lack of a better description; maybe "html 1.0-ish") i set up something that automatically collects links posted to HN that capture this feel if anyone is interested https://news.coffee/pala
The bare html files this links to are very unergonomic for human eye motorics, due to long line length (characters per line). They are also basically illegible on mobile. Which begs the question: why is the mobile default stylesheet set up so that text is unreadable without css?
I'm all for web design brutalism. It has a place in all this mess. But when it gets preachy and over-general it often becomes condescending and dismissive of entire fields of study and practice, whole categories of use, and entire groups of users.
Yes. Yes. You can use HTML and write just fine. It's a markup language,
like old runoff, which could be used to generate nice, fancy prospectus
documents for a major gov. agency in a far northern country I worked in,
when I was a wee child. A good markup language is all you need.
It makes for better writing, because the writer focuses on content,
not the pretty presentation, which should be done after the content is
written.
I am getting my nose rubbed in this truth - about the benefits of basic
minimal website design. Most websites are useless. Mine is pretty useless.
I write it to have a web-presence, promote my consulting business, and
because I feel a need to write (maybe that is an illness? - not sure..).
I find writing forces me to think better, and the investment side of our
business, requires I think well, or we die quickly. It's a harsh world now.
I found this Hackernews post, by researching how to update critical browser
stuff, which has been borked for us, by our trading platform provider.
Updating browser on Linux - and guess what? - lose all bookmarks, all
customizations, everything. Arrrrgh!!! (happens EVERY update, of course).
Simple is often better. And the Web (most of it) has become crap, mostly.
Or dangerous, toxic vector for economic assault. Bloody awful, nasty and
sad. So it goes.
I am converting our crappy website from a provider (one.com) which bought
our simplesite.com website builder thing, which worked pretty good.
But the site had all this fancy stuff for menus and images and videos, and
a truckload of .css stuff - sure, nice and fancy. But the conversion to the
One.com builder stuff, does not work, of course. We cannot update (at all)
our site from the data-description that one.com has in it's website-builder
software. As of the forced conversion, we were complete off the air. Borked.
SO, this is stupid. Complexity and fancy design - is mostly stupid, and
it also creates contrived dependency (keeps customers locked, makes them
be forced to open their wallets and send you cash - good for providers,
bad for customers.)
I got so pissed off, I decided to do it all ourselves. We built our site
at AWS as an EC2 instance. Fucking website-building software is a scam,
mostly.
The original poster is right. All you really need is HTML (AND some stuff to
render videos and audio and maybe code to get paid for stuff, maybe...). Most
of the .css stuff is fluff. And people are getting REAL tired of being
dusted with fluff. OP is right.
Our old website is https://www.gemesyscanada.com It was a mess - a long
bunch of stuff, posted over the years, research-logs, blogs, notes, etc.
But now that it is a One.com, we cannot update it. The websitebuilder
software gets to 90%, and then hangs - and we do not even get any error
messages telling us what the problem is. Arrrgh.
We are building a simpler version - using AWS-EC2 - we have one free EC2
instance which I am experimenting with: http://35.182.107.190 and that
is it. We have not even got a domain set up yet - it's all hacking & testing
for now. But it looks like we can go this route. The whole thing is an
exercise in vanity and ego. It really is, honestly. But why not? It is
what our tiny little business does, and it is what I am. I've been doing
AI since I went to Dr. Geoff Hinton's classes, and got a copy of Xerion
working on a P/C running Linux - back in the 1990's. One must not hide
one's light under a bushel, right? So, we need a website.
And a bad one, that looks goofy, and is honest, is better than a really
fancy one, full of obfuscation, deception, dis-information and old-fashioned
lies. (Kinda like - oh - just about most things now?)
All you may need is HTML. Yup. Mostly true.
- M. Langdon, Director, Owner, Floor-cleaner, Barn-builder, Portfolio Manager
GEMESYS Ltd.
> But mostly css appeals to our vanity and ego.
Design isn't just about aesthetics. Good information design, clear visual hierarchy, accessibility, etc. all help with communication. The author's effective use of spacing, bold, and code tags show us that they know this intuitively, despite what they write.