[vbo]

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".

[throw10920]

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]

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]

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]

If the software development process lacks QA, performance is likely to be the least of their concerns.

[danShumway]

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.

[nawgz]

> is that the way these companies are using it?

Since when do large companies do anything that isn't user-hostile and abusive? Of course FAANGs are trying to keep their walled garden more walled by reducing outgoing links, and Twitter's incompetence is legendary

The real question should be if this type of thing is improving the web at large or the capabilities we can develop "efficiently" on it, and while I would be willing to hear arguments either way, I can tell you I use JS/HTML/CSS in combination to introduce capabilities that would not be palatable without the JS component of that, putting aside whether I would be able to develop them as a bunch of standalone capabilities. Model editors, graph layouts, plugin architectures; we can leverage client machines to do more and more, and in a business setting delivering internal tools this is a great method of reducing costs across the stack - the laptops were already going to be purchased.

[johnisgood]

YouTube is super slow for me because of all the JavaScript. Plus I have to refresh because whenever I click on a link, it just takes too long to load, so I click refresh, at which point YouTube says I lost my Internet connection, which I did not. Sometimes I ended up having with some video with comments from the previous one. That, and I hate the "more space, less content" trend.

[vbo]

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

[kaba0]

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.

[vbo]

The overall experience feels (and is) faster as you only need to update the DOM, not recreate it from scratch, so you're not rerendering the whole page. There's also less processing required on the server as you're only requesting the piece of data you know will change and the response comes back faster. The history API makes going back and forth seamless, as if you were browsing the "classical" way. But this comes with additional complexity which is sometimes not dealt with correctly.

[tommek4077]

Only if you use 8k$ Macs. Not for normal people.

[johnisgood]

Perhaps it is just poorly written, or maybe it is the animations that are making it look like it is slower than it should be. I created a simple website where I update parts of the DOM, and it is super fast. I have the opposite experience on known websites.

[danShumway]

> That's an implementation issue.

Right, but like I said, I'm not a purist about this, I just think that maybe SPAs should only be rolled out if the implementation actually works.

To circle back around to Google Maps, this is an app that had working links, and the introduction of more Javascript made them worse. So I'm not saying get rid of all Javascript, I'm saying that if you swap out `<a>` tags and it results in broken browser functionality, that's a scenario where just using native tags would result in a better experience.

Twitter/Youtube/Maps are choosing to go down this route even though the implementation is worse. If they didn't have implementation bugs and navigation didn't break on sites like Youtube, and I could copy and paste links from Google Maps, and I didn't have laggy text input on Twitter -- well, then I wouldn't be complaining about any of this.

It's not really about Javascript being bad, but we can both agree that if a company tries to rewrite a website as an SPA and it results in a more buggy experience, then they should hold off on that and they shouldn't just plow forward with the implementation anyway. That has nothing to do with SPAs in general being evil, but even the act of saying "a Javascript-heavy SPA solution should only be pushed if the experience is better than the normal one" feels like I'm saying something revolutionary, and I don't really get what would be controversial about this opinion. Only push a Javascript heavy solution if your solution works, if it results in more breakage than the site had before that solution, then the engineers are moving in the wrong direction.

I don't know if this is a controversial thing to say, but I would say, "only push an SPA if you don't have a bunch of implementation issues". And I think that's where sites like Youtube and Twitter are falling over, in those cases their implementations are either broken because of tracking or just complexity, or something -- but it would have been better for them specifically to have not turned their sites into SPAs, because they can't seem to get rid of the implementation issues and their older sites didn't have as many showstopping bugs or performance issues.

I agree with you that sometimes this kind of partial updating can result in great, quick apps. But in practice, Nitter is faster Twitter is for reading tweets. So if I go to Twitter and I'm not signed in, and I'm just reading Tweets, that's an experience that Nitter is just flat-out better at providing in a more performant way. So it's not that all SPAs are evil or that they should always be avoided, but clearly in Twitter's case the introduction of an SPA didn't make the site faster or better, the low-JS solution ends up outperforming it on multiple key metrics.

[eitland]

> 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?

[jakub_g]

Side note: basic autocomplete can be done fully without JS using <datalist>

https://blog.teamtreehouse.com/creating-autocomplete-dropdow...

[eitland]

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?

[tshaddox]

The big one is seeing the results of data modifications instantly without a full page refresh.

[jenscow]

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.

[vbo]

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]

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]

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.

[tarboreus]

The reality is that the education you're talking about is never going to happen. By the time you had 80% of devs knowing how to do a11y on JS framework #271, a whole new paradigm would have come in. It's because accessibility is not a priority that accessible defaults, which almost definitionally need to be system- or browser-based, are so important.

If you make a form with HTML and style it with CSS, then you're 85% of the way there with accessibility, and chances are it will be usable if you screw the rest up. With JS, even if you're working from a checklist, you're much more likely to get somethign wrong. And then there are regressions. I kind of believe that you know what you're doing, because the kinds of people that hang out on HN often do. But will your second-generation successor, four years from now, know how to update your work without breaking accessibility? Empirically, based on the low level of accessibility on the web (improving, but still pretty tough going), I'd say "no."

[torstenvl]

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.

[hotz]

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.

[tarboreus]

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.

[eitland]

Good points.

I'm still not convinced it is worth everything we lost:

- Instant loading

- Sane page sizes

- Cross browser compatibility by default, including text based browsers

- Every page is reasonably safe by default

- CPU is idle after initial page load

- Battery life is great by default

and probably a few more.

I guess a good middle road might exist but I wonder if the current situation doesn't mostly serve ad pushers and bored developers ;-)

Edits: yes, a number to clarify my points and to make it clear that I am open to change my views, at least slightly.

[vbo]

Agree on all counts except instant loading, you can still do server-side rendering (from the same codebase as the client) and have the client library bootstrap/hydrate its state from it.

[goatlover]

I mostly dislike infinite scroll and am irritated when I see visual things load after the page loads. I also don’t see the point in SPAs for regular websites. The modern web looks better, but sometimes the experience is worse, at least for those of us who were around before. Of course by this I don’t mean actual applications or games on the web. Just standard websites.

[easrng]

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 and get back to you).

[easrng]

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

[MaxBarraclough]

How about rich text editors in webmail?

[Nextgrid]

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]

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]

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.

[KaiserPro]

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]

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]

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)

[zbentley]

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

[smolder]

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]

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?