Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think this is an exclusionary mindset. Just because it is a tiny subset of users, it is OK to exclude them?

How about when it is quite easy in many cases to support them, by using standard conform simple HTML?

Example: How many login forms have I seen, which will not show their input fields, if I do not allow their shitty scripts to run? In fact, just today I have seen it, on a VPN login, on a thing, that is supposed to give you security, I need to allow scripts, to have a login. Otherwise there is only a background picture. Thank you very much, so helpful! And then when I allowed their scripts, guess what. A text became visible, which told me, that in general scripts need to run in order to use the page. How much fail is that? They don't know the noscript tag or something?

That's only today's anecdote. I see this kind of fail every day, except for the days, when I miraculously manage to avoid all badly designed websites. It is getting worse and worse, because web developers seem to find it normal to, by default, reach for JS, instead of thinking about how they can solve the same thing using just HTML and CSS for a second or two.

I think it is still worth pursuing simplicity in web development. For the earlier example: Rendering a login using JavaScript is not simplicity. It is unnecessary, silly, and exclusionary without need.

So my message is: If your service can be done using plain simple standard conform HTML(5), then use it. It will also almost always have less bugs and be simpler code to maintain. Information display does not require dynamic pages per se. Usually it does not and many many websites are about information display, not impossible to solve via REST dynamic pages. Nowadays properly designed static websites are faster than badly designed JS heavy websites, which render on the client-side. The bloat has become this bad already.



I think reaching for JS is often a reflex because we want to avoid delving into building backends that aren't a simple REST API. If you stick to HTML and CSS you need to start building pages and managing state server-side, which a lot of people don't really want to do.

Even cheap, old smartphones support JS. You can have fast, efficient JS.


> You can have fast, efficient JS.

You know... this is true. I know this is true, because we had JS 20+ years ago on Pentium processors. It's possible to write JS that doesn't require multiple cores on a 2019 Ryzen...

But there are also the other sort of sites. You know the ones. Take a stab at which is more prevalent, and receives the majority of ire =[


> Example: How many login forms have I seen, which will not show their input fields, if I do not allow their shitty scripts to run? ... They don't know the noscript tag or something?

This is often less about the developers not knowing a technique and more about the constraints they're working under. Maybe there's a third party auth library they're using that requires JS. Maybe either they or or their management have other priorities than removing JS from the login screen. It's not that hard to believe that scriptless login would fall fairly low on a team's priority list behind features more likely to drive revenue, etc.


That doesn't explain the lack of a noscript message, which is the difference between "we really need you to turn on javascript" and "as you can plainly see, our page is broken".




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: