Hacker News Reader

Comment by azeotropic | Hacker News Reader

I don't understand why JavaScript is so ubiquitous now. There seem to be very few cases where it is actually necessary and useful (e.g. a calculator form that does computations client side that would otherwise overwhelm the server).

I am constantly surprised at the number of sites that should be totally static (e.g. a local restaurant's menu page) that display nothing at all when I visit with JavaScript disabled.

Can someone who actually makes websites explain why this has happened? Is this about varying screen resolutions and aspect ratios in the era of phones and tablets? Can't you just use CSS instead?

View on HN

It happened because most people don't build websites themselves, they contract the work out. And when you look for contractors who build websites, you'll find JS developers, because that is where the lucrative work is therefore that is what developers learn.

There is no pushback on it because as long as it works, people are happy and continue paying. And none of the clients test with js disabled.

Devs use it because the moment the client needs something somewhat dynamic, some js will need to be included anyway so you might as well use your usual stack.

Basically "why do people use js where HTML does the trick" is the same question as "why do people use python where c89 does the trick"

JS is very useful in many cases. Don't just think about documents or single blog posts in those cases static content should be sufficient.

But the web evolved to be way more than being a dumb content delivery pipe, it's an application development platform bypassing the underlying OS.

So ask yourself, if you need well behaved image galleries, do you need JS? Yes. Do you want to avoid page reloading to navigate? You need JS. Do you want login/form validation? You need JS. Need an inline calculator? Update content from the server? Monitor the progress of a long lasting server job? Add any logic to a shopping cart?

And these are very simple use cases, web apps are needless to say changed the way we ship apps and they all rely on JS.

I'm very much in support of offloading as many tasks to CSS as possible, but JS is hard to avoid if you want to do anything beyond static content delivery.

But it’s also used in completely idiotic places. Want to display a 100% static blog post? With just thirteen megabytes of JS, you can break scrolling, zooming, screen readers, and many others.

Reminds me of emails and newsletters. Yes, they have many legitimate uses, but that doesn’t change the fact that a large part of them are just plain crap.

I feel like both sides of the debate are refusing to admit the other side might also have some valid points. Which admittably seems to be the theme in all of the internet.

Authors are free to alienate their audience the way they please :)

I'm a web developer who avoids this sad trend wherever possible. I see two reasons for this: 1) the development experience for things like React is so 'smooth' that many developers use it even when it's not necessary at all (I'm referring to things like hot-reloading and custom components which are more complicated to set up with pre-processors) 2) some animations and advanced interactivity have become expected of us, but instead of tacking it on later, which makes the code objectively less clean, they build everything in JS, making it perform like shit and leading to things like the infamous gray bars placeholder.

But it can be done right. dev.to is a great example of an interactive web application with all the bells and whistles, yet it still performs better than most static sites.

An unrelated question: how many `html` and `body` tags are allowed on a web page? I just looked at the page source of https://dev.to/liquid_chickens/three-qualities-of-failed-mic..., and to my surprise noticed they have about five `html` and `body` tags on that page. They aren't even in iframes either.

One and only one of each. And having more than 1 doctype declaration is ridiculous. Browsers are very resistent to garbage markup, so by looking at the parsed tree and not the raw text, I never actually noticed that.

I have no idea why they would do that. It looks like a misconfigurated preprocessor that thinks each fragment is a doc of its own. I vaguely recall something about them open-sourcing the frontend, so I might look into that...

Yep, my guess would be that they are using a markdown parser that generates a complete html document out of submitted markdown, and then they just stitch those parsed htmls together, like here (the processed_html method on the article instance):

https://github.com/thepracticaldev/dev.to/blob/master/app/vi...

> Browsers are very resistent to garbage markup

Miraculously so! Anything I would have attempted to design would have crapped its pants at the look of this markup, but browsers heroically manage to display it as if nothing weird is happening. I take my hat off to their resilience.

Yes. And actually, this is a mistake in our processing configuration. We don’t want separate body tags, but it hasn’t been a problem so we haven’t gotten around to fixing it.

PRs welcome. :)

Can someone who actually makes websites explain why this has happened?

The cause is split pretty evenly between web developers who don't care about what they build enough to learn how to do it well, and companies who employ them letting them do that rather than pushing them to improve, and client's who don't understand what they've bought well enough to complain.

Everything is like that though. It's not limited to websites. Everything has problems, and it's always someone's fault. Developers tend to notice websites because we use them a lot and (some of us) think it's just laziness on the part of the website dev, but if you were an electrician you'd see problems with powertools, or a nurse you'd see issues with drug companies, and so on. The world is imperfect.

A wild guess is that these days the developers tend to specialise along the front/back end line. So a user-facing Web interface of any kind is usually assigned to front-end developers, which is now mostly synonymous with "Javascript developer", or even more specifically "React/Angular/etc developer" (just like on the back end side we commonly have Django/RoR/Magento/etc developers").

I used to be a full-stack developers, trying to balance my apps/pages just right between the server and browser side. But lately it's much easier to just focus on building APIs and let the front-end devs deal with all the interaction, forms and other user-facing stuff.

A slow website has useless HTTP requests, useless bloated content in those request, inefficient or useless computations and DOM changes, and even animation delays and other types of intentional slowdown on the critical path: it is designed wrong and decent developers should try to do better, regardless of what frameworks were used or not to make it bad and whether lack of communication between front end and back end teams is behind the problems.

The interesting question, then, is what horribly wrong incentives are at work to make web developers accept slow sites (and other trends of bad design like "dark UI patterns" and data collection).

> I am constantly surprised at the number of sites that should be totally static (e.g. a local restaurant's menu page) that display nothing at all when I visit with JavaScript disabled.

I am constantly surprised at the number of people that explicitly disable JavaScript to make their lives difficult in 2018.

My point is, JavaScript makes it easy to build nice websites at scale. Plenty of CMS platforms (like Wix.com) use JavaScript by default.

If 99.9999999% of people are fine with JavaScript, then why should a website cater to your need by providing a version specific to people who disable JavaScript?

> JavaScript makes it easy to build nice websites at scale

> build nice websites at scale

> at scale

What? Might as well mention ML & blockchain while we're at it.

If site is not interactive, it doesn't _need_ JS.

If it does need JS, it more than likely needs _sprinkles_ of it.

By "at scale", I mean building abstractions on top of commonly used html elements and making them interactive, using something like "components" in React. Then you only need to write the shopping cart or image gallery once, and users of website builders can just click a button to add it to their website.

Also, interactivity almost always gives better UX than static websites, if it's done properly by a professional website builder like Wix or Squarespace. So there's not much to hate it except maybe a few MB of extra code that you need to download.

I can't think of any good use cases for static websites in 2018, except maybe blogs in pure plaintext or old fashioned forums. Even HN has JavaScript for that little bit of interactivity (collapsing comments).

> By "at scale", I mean building abstractions on top of commonly used html elements and making them interactive,

This sounds like double-speak. That's not what at scale refers to, even allowing a very loose definition.

How the HTML is generated is moot. Server side templates had re-usability at a "component" level. iFrames exist, redirects exist.

I'm not saying all JS is bad. I'm saying too may new people seem to think JS in and of itself is magic and there is no other way to generate/manipulate the DOM or talk to other computers.

I'm bailing out of this conversation now because you're heavily conflating HTML, browser functionality and www fundamentals with website builders(i don't know why you felt the need to qualify it with "professional")

> Even HN has JavaScript for that little bit of interactivity (collapsing comments).

Yeah no, "even HN" works perfectly with JS blocked. JS for HN is an enhancement, not a requirement. They understand how the web can work...

Remember when those local restaurant's menu page where build in Flash because the owner wanted some "flip like a book" animation ? Javascript is a the same cancer as Flash. Why build "simple" static and performant website when you can sell a higth price pile animated javascript shit who "don't reload the page when your click".

Developers use the tools they are familiar with. If you are a Rails developer, you will probably choose Rails when you have to build a website, even if the website doesn't strictly require Rails.

Many web developers are familiar with React, Angular, or other front-end frameworks; they are familiar with the deployment process, and the tools around it. If they need to build a website, they will use these tools, regardless of the requirements of the website.

Because of the explosive growth and fast paced advancement of the web, most developers are mostly copy/pasting and gluing modules together. When the customer asks for a "image slideshow" they are not going to write one from scratch, even though it's just 10 LOC, they are going to bring in a library/framework which already has that functionality.

Anyone who actually has written a slideshow from scratch knows that it's way more than 10 lines of code: you couldn't even do the CSS in that, let alone accessible HTML, responsiveness, etc. There's a lot of design and testing which goes into superficially simple-seeming components and it'd be irresponsible to take that on each time unless you have a really good business justification.

It may not be functionally necessary from the user's perspective, but much of this JavaScript is included because of the business model of the publisher. It has a function, even though it's not a function that's visible to the user.

It tends to be things like trackers that report back what browser versions, supported plugins, cookies for directed adverts.

I suppose I should 'view source' to check a few, but are local restaurants actually using tracking code on menu pages?

I'll by the lazy developer / uninformed business owner explanation or the flash cancer analogy, but the tracking explanation seems a little far-fetched.

I get that Facebook, Amazon, Apple, and Google are all running ad networks trying to track me, and that globally this accounts for most of the bloat.

I'm trying to understand the dynamic that causes what should be simple static websites to use JS in such a way that they display no information at all when JS is off.

Reply on news.ycombinator.com