6 ms·

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

by vbo 5y ago

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 quickly realise how unmanageable it is let alone, as the author says, "iffy".

eitland 5y ago
> but JS improves the user experience a lot, both in terms of interaction and speed, Except for autocomplete, do you have any examples where user experience is increased a lot?
- jenscow 5y ago
  ajax/async requests. On this site, for example, if up vote your comment.. the status will just be updated. Without JS, it causes the page to reload, and I will briefly lose my place.
- tshaddox 5y ago
  The big one is seeing the results of data modifications instantly without a full page refresh.
- MaxBarraclough 5y ago
  How about rich text editors in webmail?
  - Nextgrid 5y ago
    HTML mail is a mess that's impossible to get right; better to avoid it. Misleading users with a rich-text editor that looks like a word processor is bad because it'll pretty much never look as intended in anything but the same HTML editor that created it originally.
    - seepel 5y ago
      My experience has been the opposite at least for things like font size, bold/italic. I’m curious to hear what problems you’ve encountered.
  - cuu508 5y ago
    Annoying when pasting formatted text. Annoying when you try to delete a newline but it deletes an inline image. Sometimes tricky to add unformatted text after a formatted section (the editor assumes I want to continue the formatted section). Inline images and hyperlinks are neat though.
- vbo 5y ago
  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 (not the Instagram variety). Basically all "modern" web UI.
  - tarboreus 5y ago
    Maybe it's a niche perspective, but as a blind person the obsession with JS forms is what makes the web borderline unusable for us. While it's not impossible to make an accessible experience with JS, people mess it up so often that it may as well be. I honestly think the problem with JS reimplementations is that develoeprs assume that they are their audience, or that people like them are the only people that matter.
    - martpie 5y ago
      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 low, and the result is more visible for JS-heavy websites/webapps, but this is imho an education problem, not an ecosystem issue. Having worked in agencies, accessibility was always treated as a second-class citizen (by clients or managers, not by developers, trying to push for it), and clients would often say "let's go live without it", then would come back to us asking to finish the job once they saw their competitors got sued for having an inaccessible website. So JS may be a catalyst, but not the root of the problem. It's our job to push for the importance of it, as we pushed for responsive websites a while ago.
      - torstenvl 5y ago
        Did you really just tell a blind person they're wrong about the effect JavaScript has on web accessibility for the blind? Holy crap man.
- jakub_g 5y ago
  Side note: basic autocomplete can be done fully without JS using <datalist> https://blog.teamtreehouse.com/creating-autocomplete-dropdowns-datalist-element https://blog.teamtreehouse.com/creating-autocomplete-dropdow...
  - eitland 5y ago
    Emphasis on basic I think: once you go past what could easily be done earlier you still have to use JS to configure a datasource to load from?
throw10920 5y ago
The author already addresses this in the article: > I think the Web is great, I think interactive dynamic stuff is great, and I think the progress we’ve made in the last decade is great. I also think it’s great that the Web is and always has been inherently customizable by users, and that I can use an extension that lets me decide ahead of time what an arbitrary site can run on my computer. > What’s less great is a team of highly-paid and highly-skilled people all using Chrome on a recent Mac Pro, developing in an office half a mile from almost every server they hit, then turning around and scoffing at people who don’t have exactly the same setup. And later on: > I’m not saying that genuine web apps like Google Maps shouldn’t exist — although even Google Maps had a script-free fallback for many years, until the current WebGL version! I’m saying that something has gone very wrong when basic features that already work in plain HTML suddenly no longer work without JavaScript. 40MB of JavaScript, in fact, according to about:memory
- root_axis 5y ago
  Doesn't seem to be a JS specific criticism, testing application performance on typical user hardware is a key responsibility of QA regardless of the language or platform.
  - bcrosby95 5y ago
    What is this QA you speak of? This is a really common problem in tech. Smaller companies adopt large company strategies that require more resources than the small company has to do correctly.
    - root_axis 5y ago
      If the software development process lacks QA, performance is likely to be the least of their concerns.
danShumway 5y ago
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 feel like at least scripting should make the site feel better, not worse. A lot of these sites are really unpleasant to use, Youtube swapped over to this single-page model that I'm sure was very difficult to build, but sometimes it just breaks navigation for me. What fixes it is I reload the page. So it feels like, to me, even as someone who has Javascript enabled on Youtube, we have gone from an experience where navigation never broke for me on Youtube, to a situation where sometimes Youtube loses track of the fact I'm online and I need to refresh the page, or I hit the back button and it reloads the same video. That's a lot of extra Javascript for an experience that feels like a step backwards. The old Youtube designs all used Javascript, but they also had working back buttons and felt just generally snappier. I went on Google maps recently and tried to quickly copy a number of website links for businesses into a text file: right-click copy link doesn't work. I can't copy a link for an external website, Google Maps is no longer using hrefs for literally the primary thing they were designed for. And for what? It's not faster for me to open the external websites, they don't load quicker. I don't get URL previews or some crud. It's a link that doesn't work as well, all that's happened is there's a click handler that has fewer features than the link used to have, and maybe it's easier for Google to get a pingback? This isn't an improvement.
- vbo 5y ago
  > 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 useable, keeping the current page on screen after the a new url was history.push'ed while preloading the data necessary for the next render and managing the scroll position, I can confirm it is a pain. I expect Youtube has the right kind of resources for the task but it happens, probably at a higher rate of bug incidence than regular frontend button-broke-the-site issues. Implementation issues are going to happen whether you use JS or not, but I find building with JS and with modern frameworks a joy (although a lot of things can be improved) compared to server side alternatives. As with everything though, this is a matter of preference.
KaiserPro 5y ago
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 about, small website mean faster loading. this means that more people can use them without tearing their hair out.
- vbo 5y ago
  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).
  - bdcravens 5y ago
    Slow loading server rendered would also be a slow loading API. At least with a slow server rendered app I as a user (not a developer) knows something is happening. A fully formed client with a slow backend can give the wrong impression that the app is working (unless the developer reimplements "loading" feedback that the browser implements natively)
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
smolder 5y ago
Saying JS improves the experience in terms of speed is too general. Doing async requests can result in faster interactions than whole page reloads, but big JS blobs that offload work to the client can make initial page load take forever on small pipes and can make weak CPUs struggle under the weight. More CPU utilization also drains battery, which does harm UX. Ignoring low bandwidth and underpowered hardware is fine for some products, but a common mistake with many others. People with slow internet and cheap devices are people too, ya know?
BeFlatXIII 5y ago
What are some examples of JS improving the UX in terms of speed compared with pure HTML+CSS? Are there examples that are more than submitting & updating data without the wastefulness of a full-page refresh?
zbentley 5y ago
> JS improves the user experience a lot, both in terms of interaction and speed, as well as making development more manageable Almost. Most JS (caveat Google Docs etc.) creates the kind of experience users have come to expect. That's orthogonal to "improving" the user experience. Because of the keeping-up-with-the-joneses effects of frontend engineering and design patterns as spearheaded by giant, framework-authoring, standards-setting companies, there are strong incentives to converge on bad outcomes. For example, consider the common trend of replacing built-in controls with equivalents made out of "div soup" for the sake of providing consistent styling. This is done because it is thought that styling controls is a table-stakes necessity for interactive websites. Many studies indicate this, and many users request/demand it. It's also misguided. That's not to say that the studies--or the users--are wrong. But "this is how it is done and this is how we want it" is a norm, not some objectively superior optimum, and it's a norm that was created by many years of development. Some of that development was necessary, and advanced the state of the art. But much of it was fad/hype-driven, poorly thought-through, and slipshod. The end result is a bunch of tools/patterns/user expectations that bear little relation to what actually improves user experience. In other words, JS often only improves things if you grant that the currently accepted definition of "improved" is actually an improvement over using other tools; often, it is not. > at the expense of annoying purists In other words, engineers. Engineers more interested in delivering quality than complying with norms or maximizing marginal click revenue by adding the 157th tracking library to a 50MB bundle. > CSS/HTML gymnastics Engineering.

by vbo 5y ago

eitland 5y ago

> but JS improves the user experience a lot, both in terms of interaction and speed, Except for autocomplete, do you have any examples where user experience is increased a lot?

jenscow 5y ago
ajax/async requests. On this site, for example, if up vote your comment.. the status will just be updated. Without JS, it causes the page to reload, and I will briefly lose my place.
tshaddox 5y ago
The big one is seeing the results of data modifications instantly without a full page refresh.
MaxBarraclough 5y ago
How about rich text editors in webmail?
- Nextgrid 5y ago
  HTML mail is a mess that's impossible to get right; better to avoid it. Misleading users with a rich-text editor that looks like a word processor is bad because it'll pretty much never look as intended in anything but the same HTML editor that created it originally.
  - seepel 5y ago
    My experience has been the opposite at least for things like font size, bold/italic. I’m curious to hear what problems you’ve encountered.
- cuu508 5y ago
  Annoying when pasting formatted text. Annoying when you try to delete a newline but it deletes an inline image. Sometimes tricky to add unformatted text after a formatted section (the editor assumes I want to continue the formatted section). Inline images and hyperlinks are neat though.
vbo 5y ago
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 (not the Instagram variety). Basically all "modern" web UI.
- tarboreus 5y ago
  Maybe it's a niche perspective, but as a blind person the obsession with JS forms is what makes the web borderline unusable for us. While it's not impossible to make an accessible experience with JS, people mess it up so often that it may as well be. I honestly think the problem with JS reimplementations is that develoeprs assume that they are their audience, or that people like them are the only people that matter.
  - martpie 5y ago
    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 low, and the result is more visible for JS-heavy websites/webapps, but this is imho an education problem, not an ecosystem issue. Having worked in agencies, accessibility was always treated as a second-class citizen (by clients or managers, not by developers, trying to push for it), and clients would often say "let's go live without it", then would come back to us asking to finish the job once they saw their competitors got sued for having an inaccessible website. So JS may be a catalyst, but not the root of the problem. It's our job to push for the importance of it, as we pushed for responsive websites a while ago.
    - torstenvl 5y ago
      Did you really just tell a blind person they're wrong about the effect JavaScript has on web accessibility for the blind? Holy crap man.
jakub_g 5y ago
Side note: basic autocomplete can be done fully without JS using <datalist> https://blog.teamtreehouse.com/creating-autocomplete-dropdowns-datalist-element https://blog.teamtreehouse.com/creating-autocomplete-dropdow...
- eitland 5y ago
  Emphasis on basic I think: once you go past what could easily be done earlier you still have to use JS to configure a datasource to load from?

throw10920 5y ago

The author already addresses this in the article: > I think the Web is great, I think interactive dynamic stuff is great, and I think the progress we’ve made in the last decade is great. I also think it’s great that the Web is and always has been inherently customizable by users, and that I can use an extension that lets me decide ahead of time what an arbitrary site can run on my computer. > What’s less great is a team of highly-paid and highly-skilled people all using Chrome on a recent Mac Pro, developing in an office half a mile from almost every server they hit, then turning around and scoffing at people who don’t have exactly the same setup. And later on: > I’m not saying that genuine web apps like Google Maps shouldn’t exist — although even Google Maps had a script-free fallback for many years, until the current WebGL version! I’m saying that something has gone very wrong when basic features that already work in plain HTML suddenly no longer work without JavaScript. 40MB of JavaScript, in fact, according to about:memory

root_axis 5y ago
Doesn't seem to be a JS specific criticism, testing application performance on typical user hardware is a key responsibility of QA regardless of the language or platform.
- bcrosby95 5y ago
  What is this QA you speak of? This is a really common problem in tech. Smaller companies adopt large company strategies that require more resources than the small company has to do correctly.
  - root_axis 5y ago
    If the software development process lacks QA, performance is likely to be the least of their concerns.

danShumway 5y ago

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 feel like at least scripting should make the site feel better, not worse. A lot of these sites are really unpleasant to use, Youtube swapped over to this single-page model that I'm sure was very difficult to build, but sometimes it just breaks navigation for me. What fixes it is I reload the page. So it feels like, to me, even as someone who has Javascript enabled on Youtube, we have gone from an experience where navigation never broke for me on Youtube, to a situation where sometimes Youtube loses track of the fact I'm online and I need to refresh the page, or I hit the back button and it reloads the same video. That's a lot of extra Javascript for an experience that feels like a step backwards. The old Youtube designs all used Javascript, but they also had working back buttons and felt just generally snappier. I went on Google maps recently and tried to quickly copy a number of website links for businesses into a text file: right-click copy link doesn't work. I can't copy a link for an external website, Google Maps is no longer using hrefs for literally the primary thing they were designed for. And for what? It's not faster for me to open the external websites, they don't load quicker. I don't get URL previews or some crud. It's a link that doesn't work as well, all that's happened is there's a click handler that has fewer features than the link used to have, and maybe it's easier for Google to get a pingback? This isn't an improvement.

vbo 5y ago
> 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 useable, keeping the current page on screen after the a new url was history.push'ed while preloading the data necessary for the next render and managing the scroll position, I can confirm it is a pain. I expect Youtube has the right kind of resources for the task but it happens, probably at a higher rate of bug incidence than regular frontend button-broke-the-site issues. Implementation issues are going to happen whether you use JS or not, but I find building with JS and with modern frameworks a joy (although a lot of things can be improved) compared to server side alternatives. As with everything though, this is a matter of preference.

KaiserPro 5y ago

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 about, small website mean faster loading. this means that more people can use them without tearing their hair out.

vbo 5y ago
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).
- bdcravens 5y ago
  Slow loading server rendered would also be a slow loading API. At least with a slow server rendered app I as a user (not a developer) knows something is happening. A fully formed client with a slow backend can give the wrong impression that the app is working (unless the developer reimplements "loading" feedback that the browser implements natively)

deleted 5y ago

[deleted]

deleted 5y ago

[deleted]

smolder 5y ago

Saying JS improves the experience in terms of speed is too general. Doing async requests can result in faster interactions than whole page reloads, but big JS blobs that offload work to the client can make initial page load take forever on small pipes and can make weak CPUs struggle under the weight. More CPU utilization also drains battery, which does harm UX. Ignoring low bandwidth and underpowered hardware is fine for some products, but a common mistake with many others. People with slow internet and cheap devices are people too, ya know?

BeFlatXIII 5y ago

What are some examples of JS improving the UX in terms of speed compared with pure HTML+CSS? Are there examples that are more than submitting & updating data without the wastefulness of a full-page refresh?

zbentley 5y ago

> JS improves the user experience a lot, both in terms of interaction and speed, as well as making development more manageable Almost. Most JS (caveat Google Docs etc.) creates the kind of experience users have come to expect. That's orthogonal to "improving" the user experience. Because of the keeping-up-with-the-joneses effects of frontend engineering and design patterns as spearheaded by giant, framework-authoring, standards-setting companies, there are strong incentives to converge on bad outcomes. For example, consider the common trend of replacing built-in controls with equivalents made out of "div soup" for the sake of providing consistent styling. This is done because it is thought that styling controls is a table-stakes necessity for interactive websites. Many studies indicate this, and many users request/demand it. It's also misguided. That's not to say that the studies--or the users--are wrong. But "this is how it is done and this is how we want it" is a norm, not some objectively superior optimum, and it's a norm that was created by many years of development. Some of that development was necessary, and advanced the state of the art. But much of it was fad/hype-driven, poorly thought-through, and slipshod. The end result is a bunch of tools/patterns/user expectations that bear little relation to what actually improves user experience. In other words, JS often only improves things if you grant that the currently accepted definition of "improved" is actually an improvement over using other tools; often, it is not. > at the expense of annoying purists In other words, engineers. Engineers more interested in delivering quality than complying with norms or maximizing marginal click revenue by adding the 157th tracking library to a 50MB bundle. > CSS/HTML gymnastics Engineering.