Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The unreasonable effectiveness of simple HTML

shkspr.mobi

Post reply on HN
Print view View original

371–380 of 387 posts

Re: The unreasonable effectiveness of simple HTML

#371

Post by ccanassa »

ziftface wrote: post #146
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…

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…

It's unbeliable how many things Django gets right out-the-box. I am talking about things like i18n and i13n which are usually are afterthought for most of these frontend frameworks but Django already includes a amazing system for it.

Re: The unreasonable effectiveness of simple HTML

#373

Post by pvorb »

labawi wrote: post #194
pvorb wrote: post #181

Earlier quoted context omitted.

I fully agree with all of your points. I just wanted to point out the irony that the manual and other documentation for this "inclusive design" toolkit come as PDFs – the worst choice you can make if you strive for accessibility.

I may be missing something obvious, but why is pdf such a bad choice? As long as it has actual text and is reasonably typeset (selecting text in this pdf seems to work properly), I don't see what's wrong. I'd take it any day over webpages with random floating content that you have to click through and use a modern browser with javascript without blockers/filters for the content to even render, in small text on 20% of…

The whole topic of this thread is reading web pages on a PSP. There's a whole universe of devices that perfectly render good old server-side HTML with CSS styling, but can't display a PDF for reasons. Or if they can, it will be annoying because it won't fit on the screen and be readable at the same time. That's its unique selling point as well as its biggest drawback.

I have to admit that many modern SPAs also won't rendet on many devices, though.

Re: The unreasonable effectiveness of simple HTML

#374

Post by sls »

acdha wrote: post #366
einpoklum wrote: post #362

Earlier quoted context omitted.

> nothing in computing is free... Luckily, that is not the case: https://en.wikipedia.org/wiki/Free_software I suggest you take a bit of time to read some Free Software philosophy. Consider starting with "Why software should be free", by Richard Stallman: https://www.gnu.org/philosophy/shouldbefree.html

Haha, that lazy troll takes me right back to Slashdot before the turn of the century. On the off chance that you actually believe what you're doing is useful, here's why this form of advocacy has singularly failed to attract converts (speaking as someone who's been using and contributing to open source software since the early 1990s): open source software is only free if your time and expertise are free. That free so…

I rarely bother to address this argument:

> open source software is only free if your time and expertise are free

but since you seem to actually be trying to discuss this in a thoughtful way, please note that we're not given a choice between free software that takes time and expertise to use and maintain vs closed software that takes no time or expertise to maintain. To mimic your original phrase, Windows 10 Pro is only $199 if your time and expertise is free. Going further, in my experience it's often been the case that the free software takes less time and less expertise to use and maintain.

Also, it's worth mentioning that you are conflating two different things, open source software and free software, a distinction that often doesn't matter but is central when the point at hand is the ethics of free-as-in-freedom software vs non-free software, a distinction the term open source was deliberately created to elide. You are also conflating free-as-in-freedom with free-as-in-beer by opposing the "software is only freedom-free" with "your time and expertise are free-as-in-beer free".

Finally it's not clear to me why you went on to address the pragmatics of non-free hardware or the fact that human effort is necessary to build computers, maintain distros, write kernels etc. Is there a claim that it's unethical to try to run free software on the hardware that you have, or that free(dom) software must always be provide without cost on hardware that is both free(dom) and without cost? If not, then computer users can still spend a small amount of money, relative to utility, to buy a computer that runs free(dom) software.

I'm not disputing your claims that accessibility software on Windows or iOS is better than that on Linux, because I don't know the space. It's an unrelated argument, afaict. To illustrate this, simply imagine that some government or corporation had decided to make high-quality accessibility software available under a free license. (I am reminded of Intel's work supporting Dr. Hawking.) You wouldn't conclude from this that all your previous thoughts about free and open source software vs closed/commerical software were wrong, I assume.

Re: The unreasonable effectiveness of simple HTML

#375

Post by ori_b »

Aeolun wrote: post #364
ori_b wrote: post #269

Earlier quoted context omitted.

When was the last time you removed a dependency due to lint errors? How about your coworkers?

If my point was to have accessible code, then I think I would care about not using components that are inaccessible.

Yes, it's certainly cheaper to ignore usability.

Re: The unreasonable effectiveness of simple HTML

#376

Post by mtrower »

callmeal wrote: post #159
ryandrake wrote: post #147

Earlier quoted context omitted.

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.n…

There's two ways of reading - scrolling your eyes from side to side, then down, or just scrolling down with your eyes (no side-to-side). Smaller widths make it easier for the "read the whole line in one glance" readers and is I think the main reason for this confusion. Sometimes I like just glancing down a page and getting the gist of the screen. Other times I prefer to let my eyes do extra work and read denser text.

It’s about the distance your eyes need to travel back to find the next line, and the angle at which they need to do so.

Re: The unreasonable effectiveness of simple HTML

#377

Post by samoa42 »

dgb23 wrote: post #93
lovelyviking wrote: post #73

Those are not ‘crappy browsers’. If we call it “Browser” it should be browser, isn’t it? It should brows pages. It was never intended to be overweighted virtal machine and not a good one by the way. Past 8 years or so Youtube has nothing really more to offer then it was offering back then. The only new things it offers for me is overweighted dumb slow shit that fails to perform what it was perfectly doing 8 years ago…

> It was never intended to be overweighted virtal machine and not a good one by the way. Citation needed. It's been two and a half decades since people started using the web as more than just a delivery mechanism for text and images.

> It's been two and a half decades since people started using the web as more than just a delivery mechanism for text and images.

I still do (mostly)

Re: The unreasonable effectiveness of simple HTML

#378

Post by trissylegs »

DCoder wrote: post #293
trissylegs wrote: post #286

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. Gahhh. I use either an or a and put style on it. Has all the same visual appeal of the equivalent div. But it already is a button.

> use either an or a Generally, it should be noted that an tag is only appropriate if it makes sense to right-click this element and get options to "open in new tab" or "add to bookmarks". All the stupid "buttons" implemented as + e.preventDefault() need to die.

Yea I use if it's a navigation button for react-router. But it still shows up like a URL because we're using the Browser history (it just updates the URL and renders the new page, each route has a URL and resource id's are in the url). As opening the URL directly should work (if authenticated) it makes sense to use tags.

Re: The unreasonable effectiveness of simple HTML

#379

Post by petepete »

moonchild wrote: post #288
petepete wrote: post #219

Earlier quoted context omitted.

I tend to write in Slim, it does an excellent job of removing most of the tag noise from HTML while giving you more flexibility than Markdown. https://slim-lang.com

Slim doesn't look particularly interesting for majority-plaintext applications. It doesn't let you add nodes inline, so things like emphasis or links become much more verbose.

Yeah, that's the main weakness. Being able to drop down to markdown from within Slim alleviates the problem to a degree.

Re: The unreasonable effectiveness of simple HTML

#380

Post by pvorb »

Stevie300 wrote: post #262
pvorb wrote: post #181

Earlier quoted context omitted.

I fully agree with all of your points. I just wanted to point out the irony that the manual and other documentation for this "inclusive design" toolkit come as PDFs – the worst choice you can make if you strive for accessibility.

What sort of file types are preferable? I'm not very familiar with accessible tech.

HTML, as demonstrated by the article, is accessible by default.
Post reply on HN