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

Maybe we could tone down the JavaScript (2016)

eev.ee

Post reply on HN
Print view View original

91–100 of 237 posts

Re: Maybe we could tone down the JavaScript (2016)

#91

Post by tarboreus »

hotz wrote: post #84
martpie wrote: post #63

Earlier quoted context omitted.

While I understand the concern, I'm not really sure I buy the argument "JS makes accessibility bad". It is for sure easier to do things wrong, but if you check at most of the major libraries for front-end (drag-and-drop, routing, dropdowns...), accessibility is built-in, and a critical selling point (e.g react-router, downshift...). I think the proportion of front-end developers knowing about accessibility is just lo…

I think sites that fail the accessibility test should be shamed into compliance. Possibly like how they handle sites that aren't https. I can just imagine how frustrating it must be to have an impairment that hinders usage of a website. Especially if it might be something essential.

It's mostly fine for me, because I'm technical and can do some weird thing or use OCR tools I made myself or whatever. It's incredibly difficult for the average blind person, who is statistically likely also to be older as well.

Re: Maybe we could tone down the JavaScript (2016)

#92

Post by vbo »

KaiserPro wrote: post #48
vbo wrote: post #17

I know this is likely to be controversial, but JS improves the user experience a lot, both in terms of interaction and speed, as well as making development more manageable (if used correctly), alas at the expense of annoying purists who would prefer to enagage in all sorts of CSS/HTML gymnastics just to avoid using JS (and other kinds that would prefer vanilla JS to frameworks). Do that in a large project and you'll…

yes, and no. You could have used the same argument with flash. It looked and ran the same everywhere, offered features totally unavailable with HTML/CSS and Js. The point being is that it might work fine on your machine, but its not fine for the rest of us. I am lucky that I have a 2013 retina with a GPU, but even still, there are more and more websites that are slow as shit, for no real reason. when I'm out and abou…

I've seen server-side rendered websites that took several seconds to return a page, while not being under any particular load. How is that different?

Of course a static html file will load instantly and likely not cause any issues, but apples to apples would mean comparing dynamic server side rendered websites to dynamic client (or hybrid) websites. In both cases, inexperienced developers can make a mess of it, including by picking the wrong kind of tools to do the job.

I think JS gets part of its bad reputation because of the ads (and ad networks) it empowered and the bad practices they turned into status quo (reflows, cpu usage, to say nothing of in-your-face overlays and that kind of stuff).

Re: Maybe we could tone down the JavaScript (2016)

#93

Post by ozim »

efficax wrote: post #65

These complaints are 20 years old now and in the meantime i keep building successful JavaScript heavy applications

You see - applications. I am also developing heavy JavaScript applications where people manipulate or edit / collaborate on the content in many ways.

For me problem is with pages/documents where I simply want to read stuff, maybe have some basic filtering options and that does not require loads of JS.

Like webshops where I am customer probably don't need 80% of JS that they drop in there for browsing just products.

I understand they need JS heavy content editor side where people add/remove/modify products.

Re: Maybe we could tone down the JavaScript (2016)

#94

Post by tibbar »

ryandrake wrote: post #57
Spivak wrote: post #47

Earlier quoted context omitted.

We’re saying the same thing. The web’s current tools requires devs to reimplement all that functionality from scratch, which isn’t gonna happen, when the ideal solution would be to start with the battle tested native control and then tweak from there to fit the design.

But, once you tweak it, it is no longer the same "battle tested" thing. Even little tweaks. App developers should do themselves a favor and just stick to the standard controls that have decades, maybe centuries of tester-time working out the kinks and edge cases. A medium-size company's UX expert's "restyling tweaks" are unlikely to make the control better.

This position doesn't make sense to me. Certain customizations to the native control (which is the ask here) are already available, such as adding padding to input controls, increasing the font size, changing the width. You can even change the border color and the border radius and the background color for some controls! Some of these turn out to be necessary functional changes, and some of them -- imma say it -- are obvious and important adjustments so that your app looks consistent and everything lines up properly.

To think that there's no room for variation in the design of form controls, given the broader context of a design system for app, is just a lack of imagination. I guarantee you that the people who design the operating system form controls (which change every couple years) have all sorts of ideas, and they end putting out one possible, relatively minimal option from many good designs they considered.

Re: Maybe we could tone down the JavaScript (2016)

#95

Post by easrng »

easrng wrote: post #58
vbo wrote: post #32

Earlier quoted context omitted.

Since you mention autocomplete, dealing with forms is a lot better from both a development perspective and UX, ie complex forms being validated client side (as well as server side, of course) and getting instant feedback. Modals. Having slower things being loaded after the intial page load resulting in the page loading faster (moreso with session info being loaded less often in SPAs). Infinite scroll for search pages…

Modals can be done with CSS pretty easily (with either :checked and a label to activate the modal or :target and a link to activate it or with details/summary etc.), so can form validation (the required and pattern attributes), and lazy loading (add the loading="lazy" attribute for images and iframes). Infinite scroll can't really be implemented easily but in theory it's possible with server support (I'll make a demo…

Here's the promised noscript infinite scroll! https://noscript-infinite-catfacts.glitch.me/

Re: Maybe we could tone down the JavaScript (2016)

#96

Post by [deleted] »

glacials wrote: post #50

Now that it's 2021, most of the concessions the author makes are possible with CSS. You can change the styling of an element using hyperlinks with the `target` pseudo selector: #dropdown { display: none; } #dropdown:target { display: block; } Show dropdown Dropped down! Close This works for dropdowns, tooltips, modals, even navigation if you're navigating to known places (or if you use JS to pre-insert the destinatio…

[deleted]

Re: Maybe we could tone down the JavaScript (2016)

#97

Post by kaba0 »

ryandrake wrote: post #57
Spivak wrote: post #47

Earlier quoted context omitted.

We’re saying the same thing. The web’s current tools requires devs to reimplement all that functionality from scratch, which isn’t gonna happen, when the ideal solution would be to start with the battle tested native control and then tweak from there to fit the design.

But, once you tweak it, it is no longer the same "battle tested" thing. Even little tweaks. App developers should do themselves a favor and just stick to the standard controls that have decades, maybe centuries of tester-time working out the kinks and edge cases. A medium-size company's UX expert's "restyling tweaks" are unlikely to make the control better.

Please have a look at any OOP desktop framework from like the past 3 decades. It is not a difficult concept — one is free to overload the render function, while the functionality will remain the very same, like getting focus with tab, activate to space, whatever.

Re: Maybe we could tone down the JavaScript (2016)

#98

Post by AlotOfReading »

efficax wrote: post #65

These complaints are 20 years old now and in the meantime i keep building successful JavaScript heavy applications

Heavy JS is a bit like junk food. It's fine to have a bit at the county fair and the fact that you can build a successful commercial business selling it isn't terribly surprising, but there are pretty obvious social reasons we shouldn't load it up in every meal consumers eat.

That's what articles like this are pointing out: this well-intentioned thing we're doing has negative consequences. Let's do it more moderately and deliberately to mitigate the side effects.

Re: Maybe we could tone down the JavaScript (2016)

#99

Post by ljm »

root_axis wrote: post #79

This blog loads 2mb of scripts, and if you disable JS you can't leave a comment or even read any comments. Personally, I don't have a problem with this, but I'd have expected a blog hosting an anti-js essay to be less dependent on JS. The author notes in the noscript block that using disqus is part of hosting a static blog, but that definition of "static" is an implementation detail - i.e. a convenience for the devel…

I think that it's a bit of a cop-out to call your site static in instances like this. You've outsourced computation to a 3rd party as well as the user's browser, as opposed to doing it on your own server. It would be dynamic if you cobbled a comment system together with some CGI scripts and an SQLite database and some server-side includes, and it's still dynamic if you abstract that into a runtime dependency on the client, because the content of the page is going to be different whenever you refresh and new comments are made.

The difference between the server-side option and the outsourced one is that the outsourced one is probably also going to soak up and resell a lot of data that you probably wouldn't have captured yourself.

Re: Maybe we could tone down the JavaScript (2016)

#100

Post by kaba0 »

vbo wrote: post #75
danShumway wrote: post #26

Earlier quoted context omitted.

Sure it can, but is that the way these companies are using it? Are they using Javascript to improve experience and development speed? If a Twitter textbox is lagging while someone types, then that's a degradation in user experience, and a pretty fundamental one. I like autocomplete too, but I also like my text box not to lag, and maybe there's a middle ground? I wouldn't say I'm a "purist" about this stuff, but I do…

> Are they using Javascript to improve experience and development speed? Some, yes. This was in the spec sheet for a large ecommerce website I helped rebuild with modern(er) technologies. > If a Twitter textbox is lagging while someone types That's an implementation issue. re Youtube, I haven't had the experience you describe, but having had to develop the framework side of SPA navigation into something robust and us…

But what’s the whole point of rewriting the URL and rerendering in JS the whole page? I’m fairly sure that browsers are really great at caching, so no additional HTML, JS should be downloaded and the change might very well be faster with better history and UX if we drop SPAs.
Post reply on HN