The unreasonable effectiveness of simple HTML • Hacker News Board

Re: The unreasonable effectiveness of simple HTML

#221

Post by kaba0 » Wed, Jan 27, 2021, 11:14 PM UTC

another-dave wrote: post #11

antihero wrote: post #4

Different solutions for different problems. You have a different design requirement when you are designing something for use by the most vulnerable and those without access to reasonable technology. This absolutely needs to be factored in when choosing how to build something, however, this is a tiny subset of users, and this is for essential life-is-in-the-balance types of service. The vast majority of users will hav…

I don't think the problem is that niche though. Even outside of accessibility concerns, there are plenty of times I've tried to use websites on smartphones within intermittent internet access — e.g. on the London underground checking in to a flight on the way to the airport or ordering a pizza when coming home late from work. In both scenarios, I'm trying to complete my task as quickly as possible while I still have…

Perhaps they forgot to disable 2G on their servers /s

Re: The unreasonable effectiveness of simple HTML

#222

Post by ratww » Wed, Jan 27, 2021, 11:15 PM UTC

SulfurHexaFluri wrote: post #193

ratww wrote: post #134

Earlier quoted context omitted.

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…

Rails is an excellent choice for the backend but on the frontend its much less productive than react. Most rails apps these days would use rails as an api backend and react on the frontend.

It really depends what for. For CRUD apps or static content, Rails still has an edge. For something else, like rich apps? Sure, JS beats it.

Re: The unreasonable effectiveness of simple HTML

#223

Post by Aeolun » Wed, Jan 27, 2021, 11:18 PM UTC

ratww wrote: post #134

ziftface wrote: post #117

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…

You cannot compare those though. Rails is entirely different from plain Ruby. If you want to compare you need to take something like NestJS, which approaches Django in immediate useability.

Re: The unreasonable effectiveness of simple HTML

#224

Post by madeofpalk » Wed, Jan 27, 2021, 11:19 PM UTC

reificator wrote: post #182

madeofpalk wrote: post #148

Earlier quoted context omitted.

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

> 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-js…

Got it from the first part

> Using React or whatever does not prevent you from doing this, and in fact makes it less obvious to anyone doing a cursory review

Sure. From that level it might not be apparent, but within that component the mistake would be immediately obvious, on a cursory glance. Again, I don’t think React or whatever makes this less obvious.

But really, this just isn’t a problem I’ve seen in practice. Because of good tooling, and the ease of doing things the right way, I think the majority do it well. Those that don’t were going to fuck it up regardless of the framework or paradigm.

Re: The unreasonable effectiveness of simple HTML

#225

Post by thewakalix » Wed, Jan 27, 2021, 11:21 PM UTC

lastofthemojito wrote: post #114

ogre_codes wrote: post #10

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…

This is commonly termed the "curb cut effect".

Re: The unreasonable effectiveness of simple HTML

#226

Post by 908B64B197 » Wed, Jan 27, 2021, 11:23 PM UTC

ogre_codes wrote: post #10

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…

That was the original idea behind HTML.

It might not get rendered the same everywhere depending on the device receiving it.

If the goal was to send pixel perfect pages, the web would have settled on postscript + hyperlinks.

Re: The unreasonable effectiveness of simple HTML

#227

Post by dvdkon » Wed, Jan 27, 2021, 11:23 PM UTC

Wowfunhappy wrote: post #207

dvdkon wrote: post #176

Earlier quoted context omitted.

I find it much worse that so many sites nowadays expect users to have their browsers maximised. Noticed how most books aren't wider than an A5, and how any publications wider than this use relatively narrow columns? Because reasonably narrow text is easier to read.

My question is why so many users keep their browsers maximized! I bought a wider monitor so I could comfortably have multiple windows open at once. And by "wider" I mean from 1024x768 to 1080p, and by "bought" I mean "bought a decade ago".

Because once one site starts needing X px, most users will just keep their browser at least X px wide. At some point X became so close to the monitor's resolution that not maximising the window is just extra work. I'm not happy about having to maximise my browser, but I would be less happy about having to scroll horizontally.

There are definitely some people who just maximise everything out of habit, but I don't think there are enough to have created this trend of ultra-wide webpages.

Thankfully modern webpages being responsive at least somewhat fixes this issue, even if many sites still manage to screw this up.

Re: The unreasonable effectiveness of simple HTML

#228

Post by Aeolun » Wed, Jan 27, 2021, 11:26 PM UTC

kaba0 wrote: post #208

ratww wrote: post #119

Earlier quoted context omitted.

My memories of non-web toolkits are not as fond as yours. You mention Swing, but I remember lots of my non-programmer friends dreading having to use applications made with Java, since they were considered sluggish and resource-intensive. They also had a certain look and feel to them that made them stick like a sore thumb compared to other apps, and a lot of people knew by looking when an app was made with Java. Java…

Back then, looking native was the most important thing. Today it seems electron apps can get away with looking anything but native - so perhaps it’s time to resurrect some other desktop frameworks (I just recently started working with JavaFX and I really like it so far. Unfortunate that it is so niche)

My problem with the default Swing theme, and any theme in Java at the time, was that they were so ridiculously ugly compared to the system default.

It wasn’t exactly easy to make your own theme either. Something that HTML allows without almost without thinking.

Re: The unreasonable effectiveness of simple HTML

#229

Post by TeMPOraL » Wed, Jan 27, 2021, 11:31 PM UTC

srcreigh wrote: post #162

apabepa wrote: 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…

The two biggest rants on HN are 1) Why doesn't this site work without JavaScript? It's inaccessible. and 2) Why doesn't this app work offline? It invades my privacy. Maybe I'm wrong, but as far as I can tell, you can't have both. Sorry folks. You are right, JS is not needed if the site truly is static content. But if you try to make an interactive app that could be implemented client-side (AKA javascript) and attach…

You answered your own question:

> You are right, JS is not needed if the site truly is static content. But if you try to make an interactive app that could be implemented client-side (AKA javascript) and attach a server to it, everybody will complain that the application doesn't respect the user's privacy, since it could be offline-only but it's not.

That's the gist of it. Don't use JS if not absolutely needed (or at the very least, don't make the site break without JS enabled). If needed, consider whether there is a valid technical reason why this should be a server-dependent web app in the first place - and if there is, consider supporting off-line mode where possible anyway.

It's a perfectly valid position to hold. It's a user-respecting and waste-minimizing view.

Re: The unreasonable effectiveness of simple HTML

#230

Post by apabepa » Wed, Jan 27, 2021, 11:32 PM UTC

ratww wrote: post #68

apabepa wrote: 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…

As someone involved in hiring, this is what Bootcamps and Universities are teaching, and what companies are looking for: backend spits JSON, frontend consumes it using React. Rendering HTML on the server is not really "the default" anymore as it was 10 year ago: it's more of an optimization for when your React site is slow, and it's a black box to most people. Even static websites are "strange tech" to new graduates…

Thanks for the response, very informative, I feel it explains a lot of what I was confused about.

So maybe a simplified view for me is: massive adoption of JS + frameworks, cookie cutter development, no point learning anything else when you have the golden hammer.

I actually thought you still did learn HTML and stuff before the digging into the frameworks. But maybe it is analogous to learning assembler before python, i.e out of fashion and not needed to get the job done.

In this context what seems like the simpler and more suitable solution to me (static HTML+some minimal JS) might not be on the map for most modern web developers. What they do is overkill but it is what they know and it gets the job done.