A day without JavaScript
151–160 of 412 posts
Re: A day without JavaScript
#152If I may, it seems to me like there are several possible points of discussion: 1) Javascript is bad (vs. Javascript is good and variations thereof) 2) The use a lot of websites make of Javascript is overcomplex, gratuitious, uncalled for, intrusive, etc. 3) Sites should provide some (even minimal) functionality to people browsing them without Javascript #1 is largely a matter of personal opinions #2 is a known, unden…
Even though I am a frequent advocate of leaning on more old school techniques for building web apps (even with new school tools), I vehemently disagree that this is a generally worthy cause. A small list of (I think non-controversial) things: 1. You browse without JS. You're a power user. You already know why the page doesn't work. A courtesy message would be nice, I guess, but it seems fairly pointless. 2. Should my…
Well, the point is that a lot of people post their site on HN as "Show HN", and the "intended audience" is then (or should be) "power users", which should also mean that "power users" (few as they might be) are potentially interested to your site, but you make sure that only a subset of these power users can access your site (not necessarily in full, sometimes a simple text summing up what the thing is about would be enough to either - as I do if the page doesn't load - discard it or get me interested enough to turn javascript on/use the "other" browser).
If you don't post your site on "Show HN" the missing "no-javascript message" is only a (small) lack of courtesy, if you do post it, it sounds (to me) like a plain lack of attention.
In the real world, you open a new shop in town, and advertise on the local newspaper "everyone is invited for the shop opening tuesday at 7:00 P.M.", than you put at the door a couple big guys that only let in those dressed "black tie". I do have a suitable attire, but I am not going home to change into it, not without having at least the possibility to peek inside your shop and see what it is about. Will I become a customer? Maybe yes, maybe not, but more likely not.
Re: A day without JavaScript
#153Earlier quoted context omitted.
Yeah. Except you need to do Ajax and fetch doesn't cut it. So new lib. And manipulate the dom with something better then the browser API or you loose your mind. So new lib. Then normalize browser events. Oh wait, you can do that manually. But you are writing a new lib. Eventually the code will grow to be the size of jQuery anyway. Only not as well tested, documented and cached.
> Yeah. Except you need to do Ajax and fetch doesn't cut it. So new lib. Ah, so this is how front-end got the way it is.
Re: A day without JavaScript
#154Earlier quoted context omitted.
No, most websites are still websites, and one of the biggest problem on the web is the plague of people who think their website should be an application instead. Actual web applications, like e.g. office suites, map applications, ect. are obviously extempt from "should work fine without JS" rule.
Are you really trying to say there's no argument to be made that SPA + prerendering is a design pattern with advantages over flat html, even for static content? Obviously there are disadvantages as well, but it's a tradeoff, and if executed correctly it's one that, as fewer people turn off JS and browsers become better at running web apps, is increasingly becoming worth the complexity for certain use cases.
Re: A day without JavaScript
#155Re: A day without JavaScript
#156Earlier quoted context omitted.
I simply will not spend time tailoring a nascent or even mature product to 0.0001% or whatever minscule percentage of the population turns off JS. If you turn off JS, you get a blank screen. Why should I accommodate your cohort? Why write unit tests for someone who takes a standardish client with above 1% market share and does something completely unstandard with it?
I find that it's at least (usually more) double the work to build the JS-free version of something for a fraction of the user experience. For example, imagine a forum where clicking the "edit post" button turns your post into a editor and saves with AJAX so that you can continue scrolling once you make your edit. To build the JS-free version, you typically need a separate endpoint, a new template, a redirect, and a l…
I think it depends on the user demographic. If you're actively developing a service that you hope to be used even in the most deprived areas with outdated equipment and poor connections, then it may be worth it. For example, outreach programs, charities, and emergency services.
If you're developing something that is more or less a needless, but useful, product -- your demographic is more than likely the upper 30% of earners in the world... yeah, probably not worth your time to develop for that 1% who won't be using JS (or have the capacity for only older versions).
Re: A day without JavaScript
#157Earlier quoted context omitted.
I simply will not spend time tailoring a nascent or even mature product to 0.0001% or whatever minscule percentage of the population turns off JS. If you turn off JS, you get a blank screen. Why should I accommodate your cohort? Why write unit tests for someone who takes a standardish client with above 1% market share and does something completely unstandard with it?
> For the same reason we build features in websites that work for blind people (aria tags everywhere), disabled people (accessible buttons), people who speak different languages (i18n), VIM users (GMail keyboard shortcuts), etc. From a comment below.
Re: A day without JavaScript
#158One thing to consider is that at larger companies, we already have a difficult enough time testing all of our site with JavaScript enabled. Netflix building a version that works without JavaScript is like asking them to build a second website, especially from a QA perspective. When you look at your users and find that .5% of them are not running JavaScript, how do you justify spending the money for that few of people…
Re: A day without JavaScript
#159Earlier quoted context omitted.
because its good engineering. you don't know what might break your JS in the future. you also don't know which user agents people will use in the future. I was quite surprised to discover that some "UC browser for Android" had quietly racked up a 9% usage[^1]. UC doesn't come without JS, but has a limited feature set, and without feature testing there's a good chance it will break your site. It broke [mine]( https://…
Nonsense. This is definitively YAGNI. Good engineering is accommodating the greatest number of people with the resources you have in the least amount of time. Thinking about some abstract future scenario is categorically not good engineering.
Case in point: car seatbelts and airbags. Most people don't crash, right? But you aren't seeing the car manufacturers remove seatbelts and airbags.
Re: A day without JavaScript
#160If I may, it seems to me like there are several possible points of discussion: 1) Javascript is bad (vs. Javascript is good and variations thereof) 2) The use a lot of websites make of Javascript is overcomplex, gratuitious, uncalled for, intrusive, etc. 3) Sites should provide some (even minimal) functionality to people browsing them without Javascript #1 is largely a matter of personal opinions #2 is a known, unden…
I simply will not spend time tailoring a nascent or even mature product to 0.0001% or whatever minscule percentage of the population turns off JS. If you turn off JS, you get a blank screen. Why should I accommodate your cohort? Why write unit tests for someone who takes a standardish client with above 1% market share and does something completely unstandard with it?