Live data from Hacker News

The unreasonable effectiveness of simple HTML

shkspr.mobi

141–150 of 387 posts

Re: The unreasonable effectiveness of simple HTML

#141

This is a fantastic article, it does miss one very key point about bog-standard HTML which is worth mentioning though. The standard widgets are all accessible, people with screen readers, limited mobility, poor vision, etc, all rely on pages being written so the devices they use to read the web can function properly. People who choose to eschew these standard components very frequently end up with a site which is unu…

One of the great things about accessibility is that it often doesn't just benefit people with disabilities. My wife and I have watched a lot of TV in the past year with the volume down and captioning on, while we enjoy some down time while our baby is sleeping. A ramped entrance to a building allows wheelchair-bound folks access, but it also helps able-bodied people using delivery dollies. Making simple, lightweight…

> One of the great things about accessibility is that it often doesn't just benefit people with disabilities.

I really love how Microsoft's design team has pushed this with their “Inclusive Design” concept[1] and highlighting how any sort of disability can be situational (holding a baby), temporary (broken arm), or permanent (missing arm) but we often only think of those in the last context despite there being orders of magnitude more people in the first two categories. Parenting is really good for showing this out since you get the need to be quiet, be able to do something using only one hand (or none), navigate sidewalks with a stroller, trying to do anything while sleep deprived, etc.

There's a great chart on page 42 (“Persona Spectrum”) of this PDF which I try to get every team I work on to go through which really gets people to think about what this means:

https://download.microsoft.com/download/b/0/d/b0d4bf87-09ce-...

1. https://www.microsoft.com/design/inclusive/

Re: The unreasonable effectiveness of simple HTML

#142

Earlier quoted context omitted.

The cost of developing in JS isn't necessarily lower, just amortized. Or in many cases, externalized to your users.

> externalized to your users You mean if you have customers with less powerful devices like the OP? I don't really see internal services or B2B products having that problem.

You original point

> the Javascript ecosystem is unmatched when it comes to very quickly creating frontend applications

Didn't hinge on whether you were creating internal tools or not. You simply used internal tools as an example of what you personally do with JS.

Re: The unreasonable effectiveness of simple HTML

#143
post #83

Earlier quoted context omitted.

What has happened in that scenario is that the designer has failed in their job. Unfortunately it’s up to engineers to catch this, which they often don’t

If the site looks correct visually, the designer has actually completed their job. You’ll find that very few businesses care how a page is implemented and happily pay for shit html if it looks right.

This painfully reminds me of ages ago, pre-ie6 even, when we would get html-tables, spacergifs and whatnots, blurped out by ancient Dreamweaver, Paint Shop Pro slices and such.

It looked good. But hardly worked.

Apparently the web hasn't really changed in that part: we're still churning out HTML that hardly works, but "looks good".

Re: The unreasonable effectiveness of simple HTML

#144
post #19

I am not a front-end developer but looking at it from a distance I really don't get modern web design. Sure some sites might need fancy javascript single page features, like if your webpage is an interactive map or realtime game, but most sites are just text and some pictures. Whats with all the javascript? Your site looks just like the next one anyway! It feels like an "Emperor's New Clothes" situation or maybe more…

I'm not either, but I've written quite a few webpages over the years, and even the occasional use of JS, but only when it's not possible to do without.

I suspect much of the superfluous JS comes from a " if you have only a hammer, everything looks like a nail" mentality.

Re: The unreasonable effectiveness of simple HTML

#145

Earlier quoted context omitted.

> Very few people have the skill to turn a div into an effective button, yet over and over I see web sites with rows of buttons which are in fact just divs with javascript behind them. What was the catalyst behind this trend? I just don’t understand the reason behind it. Hasn’t been around forever? Was there some limitation on the button tag that made the div tag more desirable?

My guess is that some learn react et al without ever really learning HTML first.

That's entirely possible. I've seen a React tutorial that shows a simple example HTML snippet, and comments on it with "We’ll get to the funny XML-like tags soon."

Re: The unreasonable effectiveness of simple HTML

#146
post #134

Earlier quoted context omitted.

The fact is, the Javascript ecosystem is unmatched when it comes to very quickly creating frontend applications. Maybe another set of tools would have been better, but that doesn't really matter. This set of tools is what everyone uses, and a lot of effort and creativity goes into making js frontend development as smooth and fast as possible. I often need to very quickly make internal services at my job and while I l…

I disagree. Rails was already faster for CRUD apps back in the mid-2000s. Batteries included, maybe a gem or two for an admin panel or for auth. Not that it matters, but rails new is probably faster than 60 seconds too. Django is pretty good too. ASP.NET Webforms was made for CRUD, and it even provided a WYSIWG designer back in the early 2000s. And it was just a matter of launching Visual Studio and creating a new pr…

I can't really speak to all the technologies you mentioned, but some of the other apps I maintain are in python using django. It is also "batteries included", and does give you more tools out of the box for backend work. It's actually really nice to work with and maintain in my opinion.

I would say though, that for very quickly creating new applications that get the job done, js has been the fastest for me. And while django and similar give you more database stuff to work with, honestly that feels like a solved problem, and it's often easier to not have to do any backend work at all, and instead use something like hasura. And next does include backend code too for functions that you need to write for the backend.

Obviously, this isn't ideal for a lot of problems. I think if you can get away with it, you can be really productive. I've made crud apps for work with this stack in very little time.

Re: The unreasonable effectiveness of simple HTML

#147

Earlier quoted context omitted.

The irony is that bettermotherfuckingwebsite is worse in almost all ways. I wonder if that was what the author was going for. I don't know what's truly satire anymore!

> worse in almost all ways How so? I dislike the text color choice, but other than that it seems perfectly fine to me.

Admittedly most is just personal preference but the line width thing is the cardinal sin. Forcing huge blocks of whitespace on either side of the text for nebulous "readability" reasons is just wasteful. Too many web sites ape this pattern too. Look at John Gruber's website [1] on a nice wide 27" monitor for an extreme example. The content takes up less than 1/5 of the width of the screen.

1: https://daringfireball.net

Re: The unreasonable effectiveness of simple HTML

#148

This is a fantastic article, it does miss one very key point about bog-standard HTML which is worth mentioning though. The standard widgets are all accessible, people with screen readers, limited mobility, poor vision, etc, all rely on pages being written so the devices they use to read the web can function properly. People who choose to eschew these standard components very frequently end up with a site which is unu…

While I agree with your message of "make things accessible" I think you're pointing the finger the wrong way. > This is a fantastic article, it does miss one very key point about bog-standard HTML which is worth mentioning though. > The standard widgets are all accessible, people with screen readers, limited mobility, poor vision, etc, all rely on pages being written so the devices they use to read the web can functi…

FWIW, using React or whatever makes it more obvious that you're making these mistakes because your event handlers are attached right on the "HTML" element. It makes it easy to spot because you see

    
and it immedaitely sticks out as a mistake. Because its easier to statically understand these mistakes, theres even tooling to automate detecting some of them as you type https://www.npmjs.com/package/eslint-plugin-jsx-a11y

Re: The unreasonable effectiveness of simple HTML

#149

Earlier quoted context omitted.

> externalized to your users You mean if you have customers with less powerful devices like the OP? I don't really see internal services or B2B products having that problem.

You original point > the Javascript ecosystem is unmatched when it comes to very quickly creating frontend applications Didn't hinge on whether you were creating internal tools or not. You simply used internal tools as an example of what you personally do with JS.

I see your point, and I agree it's definitely not a good solution to some problems. But I think it can be very productive if your constraints allow you to use it.

Re: The unreasonable effectiveness of simple HTML

#150

Earlier quoted context omitted.

From what I can tell the short answer is that you're right, there's really no good technical reason for all that weight. Which is to say, it's just bloat. Much has been written on this. Here's an article from 2018. (I realise the irony in that it's hosted on Medium.) https://medium.com/@addyosmani/the-cost-of-javascript-in-201...

The JS performance difference between high and low-end devices is stunning (9s vs 32s load times, based on the Medium article). Web devs, who are often used to using the latest and greatest devices, will have no idea how terrible their code performs on slower devices. And I fear that modern CPUs with excellent JS performance will only exacerbate this issue

It's strange as poor performance is known to be off-putting to users, which presumably translates into less traffic and thereby less profit for the site.
Post reply on HN