Hacker News Reader

Comment by hooby | Hacker News Reader

It's definitely a great time to build websites, but saying they _NEVER_ have been easier to make... I'm not 100% sure about that.

Yes, tailwind might make css a lot easier, and github copilot might make coding a lot faster... but is this really easier than in the early 90ies, when you could just type <html> into notepad and make a website that didn't require any CSS or images or JS or even more than just the most basic html tags?

When it comes to reading a blog or article or consuming any other form of textual information on the internet - I find myself increasingly enamored with "Reader View" in Firefox, which basically ditches all the crap, and displays the web-page in a default-style, as if it was just the most basic html - just like that we did write in 90ies.

Of course this doesn't hold true for any webApps that do more than just present textual information (and the occasional image) - but why do project like ViewPure exist? There seems to be at least some demand for getting rid of all the clutter.

Is tailwind really easier to work with something like - let's say - pico.css? Of course if you want to do super-elaborate layouts, then probably yes - but if you embraced a more minimalist approach?

Isn't Hacker News itself a really great example of a website that successfully uses only very basic html with very, very little styling and fancy extra features?

View on HN

> Yes, tailwind might make css a lot easier, and github copilot might make coding a lot faster... but is this really easier than in the early 90ies, when you could just type <html> into notepad and make a website that didn't require any CSS or images or JS or even more than just the most basic html tags?

The thing is you can still do all of this. But we have since built tools and frameworks to let you still do this, while giving you superpowers. I think Svelte is the best example of this. You can create a dead simple site with it and have the result you are talking about, but the real power is now you can employ many of those advanced techniques that were reserved for large web apps in the same dead simple site.

> Is tailwind really easier to work with something like - let's say - pico.css? Of course if you want to do super-elaborate layouts, then probably yes - but if you embraced a more minimalist approach?

I've used tailwind quite a bit, it's killer feature is the fact that it's just intuitive. With most CSS frameworks, even minimal ones, I always refer back to the docs to see how they do a specific thing. With Tailwind you refer to the guide a few times but very quickly pick up how it does things. I think that's why it's so popular, I've typed out classes thinking "is this a thing", and almost every single time, it was.

> The thing is you can still do all of this. But we have since built tools and frameworks to let you still do this, while giving you superpowers. I think Svelte is the best example of this. You can create a dead simple site with it and have the result you are talking about

I don't know. I just tried to use Netlify to upload a simple static Html/Javascript page I made. Now I'm trying to figure out CORS errors. Pretty sure that didn't use to be a thing. For better and worse.

If you're trying to figure out CORS errors, it means you're either loading fonts or making XMLHttpRequests across domains. Neither of those were available in the 90s era OP is rhapsodizing about. You don't have to use the additional features/complexity of the past 15–20 years… but if you do, it's not surprising that things get a little more complex!

IE had ActiveX since 1996, which allowed for things similar to Ajax.

You actually do have to use HTTPS nowadays, and that's a non-trivial amount of complexity compared to just serving up a static page over HTTP.

No it’s not. Certs are pretty dumbed down. So much so that there is a thing called certbot that just does it for you.

Yeah, we run certbot. It fails for some reason at least once a year and we have to do something to fix it. At the very least you have to find a way to run it on the regular and you can't forget about it or else your simple static website starts looking like malware. Tell me again how trivial it is for a 15-year-old kid using their parents' Windows 10 machine to get certbot running reliably.

Eh, most static site hosting provider offer it out of the box nowadays

What if I want to run a simple but non-static website? It was a lot easier to just do CGI with a small perl script in the 2000s.

Pretty much every web provider supports PHP, so it would be as simple as changing the extension from .html to .php

I used https://neocities.org/ recently to make a simple static html website with no issues and no configuration. And I'm someone who usually uses the more "advanced" stuff. It's nice having the freedom to chase a little nostalgia sometimes.

Is that like modern geocities?

Exactly. Same in the spirit.

Welcome to CORS errors, so sorry you made the trip. :)

CORS will eventually click for you and then it will always make sense. Until then, sorry you’re going through the muck.

I honestly feel like CORS was invented just to get people to use reverse proxies more.

CORS enables site operators to prevent third-party sites from offloading requests for them onto clients, and conveniently reduces XSS exposure as a side-effect.

Question: Are people using tailwind for layout? Even when CSS grid is available? If so what is the benefit of tailwind layouts over modern CSS, beyond what tailwinds usually brings?

I am personally, for a couple of reasons.

(1) Tailwind uses utility classes that feel like syntactic sugar over full CSS, so I don't feel like I'm "using Tailwind for layouts" as much as "using useful CSS grid presets"

(2) Much like with margins and paddings, text sizes, and colors, Tailwind helps me "pare down" the number of different values available to me. Much like having preset "m-1", "m-2", etc. values helps me be more consistent, having preset grid columns and gap spacing helps me stay consistent and not go too crazy.

(3) Because I'm using something closer to CSS-wrapped-in-classes rather than a set of components built by someone else, and because tailwind gives both a naming convention and an easy mechanism for adding my own classes that fit right in to Tailwind's, if Tailwind doesn't give me the exact values I want for grid spacing, then I can modify theirs. If I need to add a couple new presets in addition to Tailwind's, then I can do so easily.

(4) Early on when CSS Grid was new, I got bit by some bad layout bugs that were very hard to find, and impossible to fix (they were browser bugs). So, while I'm sure the bugs I encountered have since been fixed, I'm a bit gun shy on grids. I occasionally use Grid when it makes sense (via Tailwind), but more often than not I find it easier, more flexible, and safer to just use nested flexbox cols and rows. For which I also use Tailwind, if the project is of suitable size.

To sum it all up better, I view Tailwind more as syntactic sugar over CSS that helps me build my own design system. So, I would totally use vanilla CSS for small projects that don't need a design system. But for anything more than that, I like Tailwind for the same reason I like using web frameworks on the back end: it helps me keep things structured and consistent and more maintainable, even if I could do it all on my own without the framework.

So it is basically, because you’re using tailwind anyway for styling, using it for layout is nice for consistency sake. I get that.

For (2) however I usually use CSS custom properties to reach for preset values, e.g. setting "column gap" to "var(--margin-inline-wide)", and "row-gap" to "var(--margin-block-short)" etc.

That's fair. If the question is "would I use Tailwind primarily for layouts and little else" then the answer would be "no". I would definitely use CSS variables along with grid or flexbox, because its essentially the same end with less complexity.

I would also point out that Tailwind only makes sense to me when I'm also breaking up each individual UI element like cards or buttons into reusable components, either using a reactive framework like React or Vue, or a server-side template system. I'm not sure the maintainability of Tailwind survives with more monolithic HTML pages.

Tailwind is more of a method of writing CSS than a framework. Many people are writing modern CSS layouts IN tailwind, which you can consider a dialect of inline styles.

You still use grid or flexbox but instead of writing a class adding grid:0 1 and referencing the class name you use a shortcut with predefined values.

Easier to remember and quicker to type. Centering content on a screen is class="place-content-center" which makes things easier.

This question doesn’t really make sense. Tailwind is just modern CSS, it’s just a composable shorthand for applying styles. There’s plenty of CSS grid utilities in Tailwind: https://tailwindcss.com/docs/grid-template-columns

I rarely use CSS grids like when I’m doing layout. The only times I use grid-template-{columns,rows} directly is when I’m using the auto layout (e.g. a stack of cards). Whenever I do an overall layout I use named grid areas with different sized cells (i.e. not repeat()). A layout scheme could be something like:

    .container {
      grid-template:
        "nav    .      header header header" auto
        "nav    .      .      .      .     " 1ex
        "nav    .      main   .      aside " 1fr
        ".      .      .      .      .     " 1em
        "footer footer footer footer footer" auto
        / 40ch  1em    1fr    1ex    15ch
    }

You could achieve something like this in Tailwind using nested flexboxes, but that is not the same as doing layout in CSS as you have to work with the shortcomings of the framework. Now I’m not saying it is not worth it, but saying it is the same is missing a huge aspect of how we do layout in modern CSS.

The problem is that expectations changed, so now you're "required" to do more in certain contexts.

I absolutely loath frontend developments in companies with more than 5 engineers. In the past you may have found some spaghetti code and various abuses of jQuery but you could probably grasp the codebase in an afternoon. Nowadays every mid company codebase is a spaceship. For sure, you'll find a pseudo technical VP of engineering which enable whatever cool technology to be used and resume driven developers happy to pile on the latest Big Tech framework - which is likely to be an over-engineered, over complicated exercise in engineer retention and engineer roles marketing.

Then you have Pieter Levels pulling a mil per year with PHP and jQuery.

One big question: These "expectations" you are talking about, who's expectations are those?

Might it be possible that those expectations, and those requirements for doing "more", are not coming from the actual users/visitors to the websites - but rather from the companies owning the websites?

Because I, as a visitor of HN, come here for the IT news and the nerd stuff. I happily put up with the layout - because the sites actually meets my expectations for content. At the same time, the best, most modern, snazziest website ever... why would I go there (more than once), if there's no content of interest to me?

And that - to my experience - holds true for almost ALL visitors. They come for the content, and they put up with the layout. And this table-based layout with spacer gifs right here, imho is a lot easier to put up with, than some desing-heavy website that's perfectly optimized for conversion, engagement and retention rates and whatnot.

I think the actual problem is, that when we talk about "expectations" and "requirements" - we talk about what the HOST/SELLER wants - not what is best for the visitor.

> In the past you may have found some spaghetti code and various abuses of jQuery but you could probably grasp the codebase in an afternoon.

My first job out of college involved a Rails codebase littered with conditionally rendered jQuery snippets. It was a nightmare to figure out what code was even loaded on any given page. Give me a modern JS codebase over that any day.

Yeah, as someone who started out in JS with procedural jQuery, moved onto prototype overloading shenanigans with classes, and now React with functional components - the JS ecosystem and tooling is still a huge mess, but I wouldn't want to go back to jQuery or prototype class hacks. At least a modern React codebase has a whiff of engineering to it. No matter how carefully we did stuff the old way at the companies I worked for, it sooner or later became an unmaintainable mess of hacks and overrides.

C. 2000 I was able to match state-of-the-art web designs, solo, without much difficulty, writing raw HTML & JS. And get paid for it.

I was in high school.

That was the best time to build websites.

(Though at least "flat" trends and terrible UX out of several major companies mean my shitty designs are back to looking about as good and working about as well as "pro" designers, so that's, kind of, an improvement over ~2005-2014)

Hacker News still uses tables - for layout!

But it always loads super fast, and it just works.

We figured out how to display text on a web page decades ago. It's a shame more people aren't just doing it the direct way anymore.

(Applications are a different matter obviously)

Because of your comment I just looked at the source - yup tables. And a spacer gif too https://news.ycombinator.com/s.gif

I think it's old enough to be a retro design choice now.

I don't think any of this is "good" web-design.

But my argument never was about the layout or design of Hacker News being "better".

What I meant to argue was, that content is king, and that everything else should serve the actual content - not distract from it.

"What I meant to argue was, that content is king, and that everything else should serve the actual content - not distract from it."

Thank you! So many sites have utterly garbage contrast, making content unreadable - it's so annoying.

I spam this excellent discussion of color and usability as often as I can: https://designsystem.digital.gov/design-tokens/color/overvie...

but getting stupid 20 something designers with perfect vision to pay attention is almost impossible :p

I would have been horrified if I saw what websites would look like in 2010+ when I first started using the web. The amount of unnecessary garbage and JS added to sites goes well beyond the adtech part. Half or more of sites using frameworks probably should never have used them.

A good contrast is Reddit vs hn. Reddit’s current site is basically unusable and sluggish on modern hardware that can you could train ML models with.

Just look at all the overhead of the article‘s website… When I first clicked the link the "website" crashed, so instead of the hot take, all I could read is that "addEventListener is not a function". That tells you all about the current state of affairs

(Yes I get that webdevs' personal sites are their playground)

That website also loads 184 KB of Javascript to display a 13 KB static document

It could sit on a shit ton of interpreter too.

My favourite recent incarnation if this is when YouTube has its JavaScript go sideways and then it blames the internet being out instead of doing anything productive

And if you try it on mobile, it's mostly crap.

Let's not treat HTML tables as being some super special ability.

If HN were implemented exactly the same but with flexbox or grid for layout, it would be objectively better with no drawbacks I can think of.

HN is fantastic on mobile. Much better than Reddit, even old.reddit and i.reddit.

Yeah it's easily one of THE best mobile sites I use.

The touch targets are way too small, and I don’t even have fat fingers.

Anecdotally, I've found that iOS handles small touch targets much better than Android. I had an HTC Raider, a Moto G, and a Moto X Play, and I felt very fat-fingered on all of them. Then I switched to an iPhone 6s and now an iPhone 12 Mini and with both of them I've had zero problems with small touch targets, even ones that are close to each other like with Nonograms.

I dunno, it looks great on Firefox mobile.

Definitely works fine on mobile for me

You never miss the upvote/downvote buttons?

Quotes don't sidescroll to infinity for you?

I could go on and on...

It's okish, but it's no pinnacle for usability, that's for sure.

Eh, yeah I guess that happens, I guess I'm so used to the rest of the internet being so awful on mobile that it doesn't phase me. Which is funny, because I'm always super irritated by the rest of the internet.

What problems on mobile (small screens) do you see?

> no drawbacks

Would it be slower or use more CPU or memory to render?

Are we really worried about the CPU/memory impact of flexbox vs HTML tables?

Well, maybe we should! The site should be super smooth on my Amiga! :-p

> Would it be slower or use more CPU or memory to render?

With flexbox layout, probably (?), but likely imperceptibly (don't quote me on that, I haven't actually done the math to check if the benefits from decreased DOM elements would outweigh the increased cost of flexbox, maybe it would get faster just by virtue of shipping less HTML).

That being said, GP is being kind of extravagant, there is arguably nothing on HN that requires tables or flexbox. I always felt like inline spans and maybe a few floats/margin:autos for stuff like headers/menus would probably handle the majority of the layout.

This is part of my criticism of "HN picked the simple answer" takes; even if you go back over a decade and even if you take flexbox off the table, tables weren't really the simplest answer after CSS `margin:auto` was invented. This really isn't a website with columns of data, it almost doesn't need any layout tool at all.

I think the, "now flexbox exists so we can do it correctly" takes are also wrong in their own way; HN is a single-column reading experience with very simple menus, why bring flexbox into this? I always try to temper this claim because I haven't technically ever sat down and built a pixel-perfect replica using normal HTML, I don't technically know there's nothing that wouldn't require modern CSS. But I have poked around at different pages of the site and messed around with resolutions, and I've never seen a situation on the site that I felt required all of that extra HTML and complexity.

I almost wonder if the point of the embedded font tags and image spacers and crud is that site is trying to make it sort of render the same even with CSS turned off. But if so, that's bad practice and the site should stop doing that. Anyone who's turning off CSS is doing that for a reason and the site should just respect that and ship them the pure content.

(Semi) honest question to the commenters below parent, do you all use styluses, or do you just have small fingers, or is there some predictive touch system in the default browser for your devices that isn't present in Firefox? How big are your screens, are you running phablets?

Trying to understand how so many people are reaching the conclusion that HN works well on mobile. Maybe 25% of the time I try to upvote or downvote a comment on mobile, I fat-finger the wrong arrow. That shouldn't happen in a mobile interface.

I feel like just for the sheer number of comments I'm seeing saying that they don't know what the problem is, there must be something I'm missing. To me it's pretty straightforward, you have to zoom the screen in 20-40% to press any of the buttons or accurately target on any of the links, and when you do that you have to interrupt reading flow because the text doesn't wrap during that zoom.

When I turn off the mobile site and request the desktop version it's even worse, so I don't think it's a browser setting. I don't think I have particularly large hands, but the links on the top of the site are still only about 1/3 to 1/4 the size of my pointer finger.

What are you all seeing that I'm not? Is there a font-size setting you have checked? This is a pain to use without a precise pointer.

This button clicking issue certainly exists in Android Chrome. It's just that almost every designed-for-mobile website is missing functionality or behaves in unpredictable and terrible ways. Browsing not-designed-for-mobile web sites on mobile and zooming whenever I need to click on something is a big upgrade.

This is an interesting/illuminating comment, and it makes me wonder if some of this might be a personal bubble thing. I feel like I generally tend to have a better experience on mobile than other people describe, but I'm also running mobile adblockers, and more importantly, I also might just not be visiting all of the same sites as other people?

People complain about Reddit on mobile, and I totally agree, Reddit mobile is awful, but it's also a really small part of my life, I generally don't visit Reddit on a phone that often -- so it's easier for me to think about Reddit's mobile site(s) as being some kind of outlier?

My experience has been I read a lot of blogs on my phone, I do searches (that go through duckduckgo, which I don't really have a ton of complaints about as a mobile site), I look up quick pieces of information on the fly from random sites, I look at MDN documentation, trying to think what else...

I also spent a long time turning off Javascript entirely on my phone browser and I've only very recently started changing that practice (largely because of Gorhill deprecating uMatrix), which probably biases things even more, because a lot of the browsing I do on my phone works without Javascript, and that gets rid of a nontrivial number of annoying behaviors from more aggressive sites, and so I wonder if I'm just not giving the same amount of "credit" for HN not doing the Reddit bullcrap where it pops up a notification asking me to install an app, and that makes it easier to stare at the flaws.

If I was doing a lot of Reddit browsing on my phone, I would appreciate HN more on mobile, I will give people that HN is much better on mobile than Reddit.

One workaround would be making a new account whenever you get enough hacker news points to unlock downvoting.

> it just works.

Going to push back on this line specifically, HN has a number of issues. They're not dealbreakers, but they're also not particularly hard to fix with modern HTML. HN has generally kind of bad accessibility/semantics, it's pretty frustrating to use on mobile, and it degrades kind of poorly without Javascript (collapsing thread buttons still appear even though they don't work, also, collapsing thread buttons don't work without JS).

HN is (unironically) a great example of how kind of hacky you can make something and how little you can iterate on it while people still are mostly able to use it for its intended purpose. And (with the exception of maybe its blind accessibility problems) it should be held up as a great example of that.

But it's not a good example of "do things simply and they'll just work well." If anything, HN is a great example of why stuff like tables were abandoned. And the HTML isn't even that simple, this must have been a royal pain to build, everything everywhere is another embedded table. It's a weird dig at how bad some major websites have become that people don't see HN's HTML as bloated or convoluted.

Ever really dug into how HN threading works? Everything is a top-level comment, and it inserts transparent images to create the illusion of indentation. It's a wildly out-of-left-field solution that makes parsing out and styling threads way harder than it needs to be. Seriously, I've spent way too much time trying to figure out how to make CSS selectors for custom user-styling work on child comments/replies on a site that is supposed to be displaying a comment tree in the DOM tree. There's a one-to-one mapping there, you don't really need a complicated visual slight-of-hand to display this information; just put the comments in the tree.

Again, not to get mad at HN; but I think people use it as a positive example in the wrong situations. HN has bad HTML with obvious downsides that would be pretty easy to fix, but it turns out that creating an elegant website and filing off the rough edges is actually a really small part of running a community, and doesn't matter that much in the long run when compared to other things you could be doing to foster that community (like moderation/curation), and that is a very good lesson for tech people to learn from HN. But nobody should praise the HTML on this site, there are much better examples out there on the web of sites that use simple HTML to great effect.

----

> (Applications are a different matter obviously)

Much more minor push-back but I actually would love to see more applications embrace the interactive document model even when fully native and fully offline. Not all applications, but a bunch of them. Stuff like calculators, calendars, even bigger applications like database software/image viewers/file browsers, etc...

User-accessible stylesheets for applications, user-accessible scraping tools for applications, etc... I think there's a lot of potential for user computing hidden behind a willingness to say, "no, many applications are just text displayed in tree/table form when you think about it, and the app/document divide was always sort of nonsense."

> Ever really dug into how HN threading works? Everything is a top-level comment, and it inserts transparent images to create the illusion of indentation. It's a wildly out-of-left-field solution...

Having worked on an implementation of comment indentation before, I think it's a technical design choice rather than wildly out of left field. From the backend perspective, it's more performant (and simpler from as far as code maintainability) to have a flat db table with a number representing indentation level, rather than have each comment point to its parent, and then have to recursively build the html.

When you're getting as much traffic as HN, such design tradeoffs can make a huge difference in site responsiveness.

I might be misunderstanding what you're referring to. To be clear, I'm not really talking about recursively building anything about the HTML or fetching any additional data about other comments, or storing it in the database as a tree, a flat structure and iterative builds are fine for all of this. I'm talking about, purely off the top of my head, moving away from:

  result = reduce(comments, (result, comment) => {
    return result + build_comment(comment);
  }, '');

to:

  indent_level = 0;
  result = reduce(comments, (result, comment) => {
     missing_lvls = indent_level - comment.indent_level;
     close_str = missing_lvls > 0 ? repeat_str('</ul>', missing_lvls) : '';
     indent_level = comment.indent_level;

     return result + close_str + build_comment(comment);
  }, '');

I assume you're right and there's some kind of extra complexity somewhere, but HN isn't just storing the comments with no context other than indentation as far as I can tell. It is maintaining parent-child relationships at least well enough that the buttons to minimize/maximize threads work, so I am not sure what process is being skipped here by shipping flat HTML lists.

I guess I haven't ever read through HN's clientside Javascript, maybe it's calculating how to minimize threads on the fly completely clientside by iterating over the DOM, and maybe that's why the buttons don't work with JS disabled. But.. oof, I wouldn't hold that up as an example of good, simple clientside code if that's the case.

----

But again, I'm not going to argue with your conclusion, I assume there's something I've missed, I assume you're right.

This is still a bad example to use for "see, simple HTML is better". What you're describing is a good example of why it makes sense to say, "see, convoluted table setups that are worse on the client are faster overall than clean, simple output."

Which is not a bad lesson to learn from HN. It's a great lesson, sometimes performance requires us to do hacky things. But it is a very different lesson from where this thread started. You still would never point at that and say, "this is a good example of what HTML should look like", you would say, "these are the kinds of messy sacrifices that might be necessary to maintain a performant backend."

> maybe it's calculating how to minimize threads on the fly completely clientside by iterating over the DOM, and maybe that's why the buttons don't work with JS disabled

Holy crud, I just opened the JS up and this is actually what it's doing. Heck me and my little 'not going to contradict you' statements, you might just be completely entirely right about what's going on I guess.

  function kidvis (tr, hide) {
    var n0 = ind(tr), n = ind(kid1(tr)), coll = false;
    if (n > n0) {
      while (tr = kid1(tr)) {
        if (ind(tr) <= n0) {

I'm still going to reassert that any architecture that leads to someone doing this kind of logic every time a button is pressed is neither simple nor elegant, and at best this is an example of making architectural sacrifices and introducing complexity for the sake of performance; there's no way that this kind of page logic is easier to maintain or to understand than something built around a more semantic structure.

It's also definitely not easier on the client, I've seen some comments on here argue that HN might use all this weird stuff to save client battery life, and I feel more confident now saying that's not the reason, because if someone is somehow, someway legitimately in some incredible situation where they're actually worried about the battery drain of a browser rendering a table vs a some extra CSS, then this is not the code you would want to run every single time you press a button on the page.

But yeah, the "we just base everything off of an indentation integer and comment order" theory does seem a lot more plausible to me now, because I'm having a somewhat difficult time thinking why else collapsing comments would work this way.

I mean you still can, it's just that nobody's going to hire you to do that and nobody is going to be impressed by it. Even back in the 90s when it was that easy, it was all hobbyists. By the time the dot-com boom started taking off, it was complicated. CSS + JS, no responsive design (remember designing 3 different sites to deal with the 460x640, 600x800, and 1280x1024 resolutions? Frames and no frames? Different sites for each browser [or ones that only worked in one bc things were even less standard than now - 'this site only works in IE'?] etc.)

Now it's the tools adding the complexity, but back then it was hardware, browsers, etc.

“no responsive design (remember designing 3 different sites to deal with the 460x640, 600x800, and 1280x1024 resolutions?”

Using media queries with breakpoints, and doing exactly what you describe, was the original “responsive design”. What you have in mind (I think) is what might be called “fluid design”—responsive design without media queries. You could always do this to some extent with such things as inline blocks, auto margins, and other ancient CSS technology (and an unstyled site also reflows responsively), but flex and grid allow more elaborate fluid designs.

There is also some advantage to making separate designs carefully crafted for a variety of screen shapes, that you give up with fluid design techniques.

Thanks for the correction/deep dive here. I was a kid + don't have an official education in cs, so I mix up terminology and what things were called sometimes.

I remember when media queries came out. It was so nice. Amazing. 10/10 for the time. You can do a lot with auto-margins and other ancient CSS, but there are definitely quite a lot of limits. (Sighs in someone who does a lot of email design and academic CMS design... let's party like it's 1999...)

> There is also some advantage to making separate designs carefully crafted for a variety of screen shapes, that you give up with fluid design techniques.

I agree strongly with this from a UX/UI point of view and as an educator.

> is this really easier than in the early 90ies, when you could just type <html> into notepad and make a website that didn't require any CSS or images or JS or even more than just the most basic html tags?

Nothing is stopping someone from doing that today, but that's no longer the only option, thus it seems accurate that it is easier today than ever before.

In a way, its more difficult today because there are so many options for web development that it's paralysing to even find out where to start. Still, can't go wrong starting with the most basic option.

That's like saying "it's harder than ever to cut wood because there are 100 different types of saws in Home Depot". I don't really buy this line of reasoning, different tools exist to tackle different types of problems, if someone has no idea what they're doing then it's their responsibility to get educated, that's as true today as it ever was, except today it's much easier to get educated than ever before.

I'd like to reframe your argument around expectations. Regardless of the difficulty of building websites, the bar is dramatically higher than it used to be. Look at what Amazon was able to get away with at one point [0]. The need for good security practices is also the highest its ever been (and will continue to matter more in the future).

So, in some ways, its never been more difficult to build a website. Thankfully FOSS lets us outsource a lot of the work.

[0] https://i.imgur.com/OAyZWnZ.png

You can still hack in HTML (and CSS) in a basic editor. I do occasionally. No design or js frameworks, no elaborate build systems, just me and my editor.

I don't think I'd have been so cocky five or ten years ago. Bootstrap solved real problems with cross browser layouts, jQuery fixed serious holes in some browsers' standard libraries. But the things they did then are things I'd happily freehand now.

In short, it's easier because 99% of browsers in use aren't awful and flex and grid make the float mess of the mid-Naughties irrelevant.

I am positively confident that I could teach a bunch of art students (so definitively non tech people) how to create their basic website only using html and css (without any framework/library etc) in 2 to 3 days including the domain and hosting part.

Weird flex, but okay.

What I wanted to hint at with this was, that good old HTML and CSS is both enough and probably trivially simple to get started with for the HN crowd if they don't know how to use it yet. A lot of simple websites don't need more than that. And if you sprinkle a bit of js on top you can also dig into the land of not so simple websites.

agree it's false that it's never been easier, and like to add a few small datapoints.

20 or so years ago you had microsocft frontpage - anyone could build a site with little learning. heck microsoft word could spit out the doc as html I dunno how long ago.

some 15 years ago or so, I ran into a 'junk hauler' I found via google, asked who did his site, he said he did. I was like wow you were #1 in google organic, that's amazing - he said he opened microsoft publisher, put in the text, added a picture of his truck and clicked publish.

A lot has changed since then of course - google demands responsive layouts to rank well, and most people use a phone to surf.. which for a while made frameworks the magic since css grid was not baked into word/publisher/ie...

anyhow as far as 'easy' the are many other easier tools to use than tailwinds to make a site, and have been for more than a decade.

Now that browsers can auto fit via flex and grid - tailwind and similar are the bloat, not the easy-button.

> Isn't Hacker News itself a really great example of a website that successfully uses only very basic html with very, very little styling and fancy extra features?

Hacker News is an aesthetic that would be unacceptable to the majority of businesses in the world. The login page alone would cripple sales on any e-commerce site.

why do you think that's the case? is it because people will feel 'sketched out' by the bareness and leave?

Yes exactly. Stripe built a whole business on this concept by creating an easy to implement, trustable experience for otherwise dodgy looking small shops. Trust is huge, and a sketchy looking form destroys trust.

So... Are you trying to argue that it's easier today to make an acceptable company website than it was in the 90ies... or that it was easier in the 90ies than it is now?

Neither. I'm arguing that Hacker News is not a good example to use when discussing web development. It's easy to make a site simple when you refuse to implement any features, but that refusal is a luxury most businesses do not have.

The reader view (from any of the browsers really) has become my base performance review tool.

If a webpage is meant for presenting textual content and is actually _improved_ by a reader view, that means the design has failed.

There actually are websites out there that don’t benefit much from that view HN being a prime example.

In the 90s we didn't have the developer console or sophisticated debugging tools.

The only way to debug was "alert("foo")" placed in strategic locations!

We also had to handle significantly varied browser differences.

You can do a 90s style site today and vastly benefit from modern tech.

I remember putting border: 1px solid red around my layout "blocks" to help me build layouts (of course the extra pixels could mess with the layout). Then dev console came and you could inspect and mouse over those blocks and those red lines would appear and it was just amazing.

In terms of accessibility I’m not sure we’ve done better than GeoCities and AngelFire. WYSIWYG page design tools have gotten better, but those are only “necessary” because page designs have become more complicated and simple, less “professional” styling has fallen out of popularity outside of technical circles.

Those old page hosting services also served to get non-technical users to dip their toes into writing HTML, setting them on a path of learning, whereas newer page hosting services are either skewed no-code (e.g SquareSpace) or technical (e.g. GitHub Pages and Netlify) with little in-between, which keeps non-technical users locked into the WYSIWYG tools to a greater extent.

But all the things you mentioned are optional. The web is amazingly backwards compatible. Best example: one of Germany's most read blogs: https://blog.fefe.de

I understand the point you are making but is HN really the best example of modern web app? For better or worse web apps have replaced desktop apps. Not everything on the web is a simple list of articles and comments. Some things require extremely complex interactions and workflows. I don't think minimalism is the cure for everything, sometimes you need _some_ complexity and yes sometimes things are easier to use with a little bit of interaction instead of just text, forms, and plain html.

No, it's most definitely not the best example of a modern web app.

But everyone reading this knows it, and it does serve as proof that you can build a successful website with extremely little design & features. Therefore it seemed a good choice to illustrate my point.

I seem to recall Dreamweaver was also good at pretty websites. And it is hard to deny that flash enabled some massively interactive sites back in the day. Of a nature that I don't see much nowadays.

I suspect if you are wanting to create interactive things scratch is a gem.

Is tailwind much better than tachyons?

Tailwind seems to be more mature and better documented. Apart from that, they're pretty similar, so if you're used to one you probably won't get much of a benefit from switching to the other.

I see that the example websites from Tailwind look much better than those from Tachyons, though I'm not sure whether that's just a matter of taste.

no, but the tachoyns devs are a bit "opinionated" as to which directions the thing should go (and which ones it shouldn't) and seem to have moved on for the most part. one of the reasons why even though tachyons came before tailwind, the latter has a much wider adoption and more active development

You still can build a simple web in 1 min with Next.js and with greater speed.

Pico.css is for zero customize website. Once the website requires customization, it does not work. Tailwind is easier.

Reply on news.ycombinator.com